From mkosek at redhat.com Fri Mar 1 07:33:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Mar 2013 08:33:51 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <1362061706.2962.93.camel@willson.li.ssimo.org> References: <20130221152446.GS27418@localhost.localdomain> <512B84B8.7080506@redhat.com> <20130227105831.GC3633@localhost.localdomain> <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> Message-ID: <513059DF.2010403@redhat.com> On 02/28/2013 03:28 PM, Simo Sorce wrote: > On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: >> On 02/28/2013 12:42 PM, Sumit Bose wrote: >>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: >>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > >>>> Hi Sumit, >>>> >>>> This looks like a good idea and would prevent the magic default PAC type, yes. >>>> Though I would not add this service-specific setting to global IPA config object. >>>> >>>> I would rather like to see that in the service tree, for example as a >>>> configuration option of the service root which could be controlled with >>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: >>>> >>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE >>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD >>>> # ipa serviceconfig-show >>>> Default PAC Map: nfs:NONE, cifs:PAD >>> >>> Are you thinking of having this in addition to the for-all-services >>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't >>> like the first case because then three different objects needs to be >>> consulted to find out which is the right type. This wouldn't be an issue >>> for the plugin, but I think it is hard for the user/admin to follow. >> >> Hm, you are right. >> >>> >>> If the current defaults shall be dropped I think this is a major change >>> because it will require changes in the current CLI and WebUI which will >>> be visible to the users. I'm not against this change, I'm just wondering >>> if it is worth the effort for the next release? >>> >>> Maybe an argument to keep this is in global default is that the settings >>> are used for the host/*.* services as well which are in a different >>> sub-tree of the cn=accounts container. Additionally in future we might >>> want apply those setting to the user TGTs as well? >> >> Yeah, that was actually my point. That we are mixing service-specific PAC >> "rules" to the global setting. Which may be shared with host/*.* principals and >> user principals. This automatic PAC rules may require some designing so that is >> is generally usable. > > I think putting everything in the general config is more understandable > and discoverable. These per-service defaults are basically exceptions to > the general rule so it make sense to keep everything together. > > Simo. > Ok, if these are really just an exceptions to the general rule (and there will not be too many of them), I think we can leave it in config entry. But if we expect to have exceptions for other types of entries (hosts, users), I think we should rather use something like "service:nfs:NONE" do distinguish this exception. Question is, do we want to implement the interface and processing for that in current Sumit's patches or do we use that is they are? Martin From sbose at redhat.com Fri Mar 1 08:20:53 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 1 Mar 2013 09:20:53 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <513059DF.2010403@redhat.com> References: <20130221152446.GS27418@localhost.localdomain> <512B84B8.7080506@redhat.com> <20130227105831.GC3633@localhost.localdomain> <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> Message-ID: <20130301082053.GO3633@localhost.localdomain> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > On 02/28/2013 03:28 PM, Simo Sorce wrote: > > On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > >> On 02/28/2013 12:42 PM, Sumit Bose wrote: > >>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > >>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > > > >>>> Hi Sumit, > >>>> > >>>> This looks like a good idea and would prevent the magic default PAC type, yes. > >>>> Though I would not add this service-specific setting to global IPA config object. > >>>> > >>>> I would rather like to see that in the service tree, for example as a > >>>> configuration option of the service root which could be controlled with > >>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > >>>> > >>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > >>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > >>>> # ipa serviceconfig-show > >>>> Default PAC Map: nfs:NONE, cifs:PAD > >>> > >>> Are you thinking of having this in addition to the for-all-services > >>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > >>> like the first case because then three different objects needs to be > >>> consulted to find out which is the right type. This wouldn't be an issue > >>> for the plugin, but I think it is hard for the user/admin to follow. > >> > >> Hm, you are right. > >> > >>> > >>> If the current defaults shall be dropped I think this is a major change > >>> because it will require changes in the current CLI and WebUI which will > >>> be visible to the users. I'm not against this change, I'm just wondering > >>> if it is worth the effort for the next release? > >>> > >>> Maybe an argument to keep this is in global default is that the settings > >>> are used for the host/*.* services as well which are in a different > >>> sub-tree of the cn=accounts container. Additionally in future we might > >>> want apply those setting to the user TGTs as well? > >> > >> Yeah, that was actually my point. That we are mixing service-specific PAC > >> "rules" to the global setting. Which may be shared with host/*.* principals and > >> user principals. This automatic PAC rules may require some designing so that is > >> is generally usable. > > > > I think putting everything in the general config is more understandable > > and discoverable. These per-service defaults are basically exceptions to > > the general rule so it make sense to keep everything together. > > > > Simo. > > > > Ok, if these are really just an exceptions to the general rule (and there will > not be too many of them), I think we can leave it in config entry. But if we > expect to have exceptions for other types of entries (hosts, users), I think we > should rather use something like "service:nfs:NONE" do distinguish this exception. > > Question is, do we want to implement the interface and processing for that in > current Sumit's patches or do we use that is they are? I would like to update the patches so that they can handle the service:TYPE style entry and replace the current update code with just adding nfs:NONE to the global options. I will update the design page accordingly, too. I would prefer if the enhancements needed for the CLI and WebUI can be covered by other/new tickets, but I'm happy to add the needed information to the design page too. bye, Sumit > > Martin From mkosek at redhat.com Fri Mar 1 09:08:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Mar 2013 10:08:27 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <20130301082053.GO3633@localhost.localdomain> References: <20130221152446.GS27418@localhost.localdomain> <512B84B8.7080506@redhat.com> <20130227105831.GC3633@localhost.localdomain> <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> Message-ID: <5130700B.2030608@redhat.com> On 03/01/2013 09:20 AM, Sumit Bose wrote: > On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: >> On 02/28/2013 03:28 PM, Simo Sorce wrote: >>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: >>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: >>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: >>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: >>> >>>>>> Hi Sumit, >>>>>> >>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. >>>>>> Though I would not add this service-specific setting to global IPA config object. >>>>>> >>>>>> I would rather like to see that in the service tree, for example as a >>>>>> configuration option of the service root which could be controlled with >>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: >>>>>> >>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE >>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD >>>>>> # ipa serviceconfig-show >>>>>> Default PAC Map: nfs:NONE, cifs:PAD >>>>> >>>>> Are you thinking of having this in addition to the for-all-services >>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't >>>>> like the first case because then three different objects needs to be >>>>> consulted to find out which is the right type. This wouldn't be an issue >>>>> for the plugin, but I think it is hard for the user/admin to follow. >>>> >>>> Hm, you are right. >>>> >>>>> >>>>> If the current defaults shall be dropped I think this is a major change >>>>> because it will require changes in the current CLI and WebUI which will >>>>> be visible to the users. I'm not against this change, I'm just wondering >>>>> if it is worth the effort for the next release? >>>>> >>>>> Maybe an argument to keep this is in global default is that the settings >>>>> are used for the host/*.* services as well which are in a different >>>>> sub-tree of the cn=accounts container. Additionally in future we might >>>>> want apply those setting to the user TGTs as well? >>>> >>>> Yeah, that was actually my point. That we are mixing service-specific PAC >>>> "rules" to the global setting. Which may be shared with host/*.* principals and >>>> user principals. This automatic PAC rules may require some designing so that is >>>> is generally usable. >>> >>> I think putting everything in the general config is more understandable >>> and discoverable. These per-service defaults are basically exceptions to >>> the general rule so it make sense to keep everything together. >>> >>> Simo. >>> >> >> Ok, if these are really just an exceptions to the general rule (and there will >> not be too many of them), I think we can leave it in config entry. But if we >> expect to have exceptions for other types of entries (hosts, users), I think we >> should rather use something like "service:nfs:NONE" do distinguish this exception. >> >> Question is, do we want to implement the interface and processing for that in >> current Sumit's patches or do we use that is they are? > > I would like to update the patches so that they can handle the > service:TYPE style entry and replace the current update code with just > adding nfs:NONE to the global options. I will update the design page > accordingly, too. Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd be great. > > I would prefer if the enhancements needed for the CLI and WebUI can be > covered by other/new tickets, but I'm happy to add the needed > information to the design page too. > > bye, > Sumit I am OK with adding the interface for this special exception later. In that case, a ticket + note in the design as you mentioned would be enough. Thanks, Martin From simo at redhat.com Fri Mar 1 13:58:34 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Mar 2013 08:58:34 -0500 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <5130700B.2030608@redhat.com> References: <20130221152446.GS27418@localhost.localdomain> <512B84B8.7080506@redhat.com> <20130227105831.GC3633@localhost.localdomain> <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> Message-ID: <1362146314.2962.130.camel@willson.li.ssimo.org> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > On 03/01/2013 09:20 AM, Sumit Bose wrote: > > On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > >> On 02/28/2013 03:28 PM, Simo Sorce wrote: > >>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > >>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > >>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > >>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > >>> > >>>>>> Hi Sumit, > >>>>>> > >>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > >>>>>> Though I would not add this service-specific setting to global IPA config object. > >>>>>> > >>>>>> I would rather like to see that in the service tree, for example as a > >>>>>> configuration option of the service root which could be controlled with > >>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > >>>>>> > >>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > >>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > >>>>>> # ipa serviceconfig-show > >>>>>> Default PAC Map: nfs:NONE, cifs:PAD > >>>>> > >>>>> Are you thinking of having this in addition to the for-all-services > >>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > >>>>> like the first case because then three different objects needs to be > >>>>> consulted to find out which is the right type. This wouldn't be an issue > >>>>> for the plugin, but I think it is hard for the user/admin to follow. > >>>> > >>>> Hm, you are right. > >>>> > >>>>> > >>>>> If the current defaults shall be dropped I think this is a major change > >>>>> because it will require changes in the current CLI and WebUI which will > >>>>> be visible to the users. I'm not against this change, I'm just wondering > >>>>> if it is worth the effort for the next release? > >>>>> > >>>>> Maybe an argument to keep this is in global default is that the settings > >>>>> are used for the host/*.* services as well which are in a different > >>>>> sub-tree of the cn=accounts container. Additionally in future we might > >>>>> want apply those setting to the user TGTs as well? > >>>> > >>>> Yeah, that was actually my point. That we are mixing service-specific PAC > >>>> "rules" to the global setting. Which may be shared with host/*.* principals and > >>>> user principals. This automatic PAC rules may require some designing so that is > >>>> is generally usable. > >>> > >>> I think putting everything in the general config is more understandable > >>> and discoverable. These per-service defaults are basically exceptions to > >>> the general rule so it make sense to keep everything together. > >>> > >>> Simo. > >>> > >> > >> Ok, if these are really just an exceptions to the general rule (and there will > >> not be too many of them), I think we can leave it in config entry. But if we > >> expect to have exceptions for other types of entries (hosts, users), I think we > >> should rather use something like "service:nfs:NONE" do distinguish this exception. > >> > >> Question is, do we want to implement the interface and processing for that in > >> current Sumit's patches or do we use that is they are? > > > > I would like to update the patches so that they can handle the > > service:TYPE style entry and replace the current update code with just > > adding nfs:NONE to the global options. I will update the design page > > accordingly, too. > > Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > be great. If we need to distinguish between service principals and user principals I would prefer rather use a special keyword for upns service: is redundant and I do not want here to be able to say upn:martin:NONE because per principal options are available on the principal object. I actually really do not see the need for changing the default just for user principals. If we are worried that one day we might want to really have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we might add upn:NONE and the lack of / will tell us this is not a service named upn/foo.bar.baz but rather it means user principal names. However I do not see us ever really needing upn:NONE > > I would prefer if the enhancements needed for the CLI and WebUI can be > > covered by other/new tickets, but I'm happy to add the needed > > information to the design page too. > > > > bye, > > Sumit > > I am OK with adding the interface for this special exception later. In that > case, a ticket + note in the design as you mentioned would be enough. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Mar 1 14:29:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 01 Mar 2013 15:29:14 +0100 Subject: [Freeipa-devel] DNS update mechanism: news about update authorization Message-ID: <5130BB3A.2070405@redhat.com> Hello list, we would like to share some news about DNS update mechanism: - It is possible to allow particular principal to update all records in a zone. - It is possible to allow clients to update own PTR records. PTR update can be "authenticated and authorized" by source IP address of the TCP connection from the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR record with name 31.0.2.192.in-addr.arpa., nothing else. See examples in following how-to: http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy Simo pointed to fact that "TCP authenticated" update requests can be more secure than current approach with "PTR synchronization" magic (done inside bind-dyndb-ldap). Unfortunately, it is not possible to combine TCP "authentication" with GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is not possible to combine multiple requirements. 'tcp-self' rule ignores request signature completely. Implementation of (TCP && signed) requirement will require patching BIND. I don't like that idea, because we will deviate from plain BIND docs and it will cause confusion. We can propose a change and send patches to ISC. It should be possible to implement new 'tcp-signed-self' mechanism with only few lines of code. The question is how it should behave: Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed to do tcp-self update? Should we implement configurable realm check? I.e. the update will be allowed only if the update is signed by principal from specified Kerberos realm? How it should work with Kerberos trusts? Also, it should be possible to implement more strict check: Updated name in reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address and *at the same time* name stored to PTR record has to match name in client's principal. Example: - client's IP address: 192.0.2.31 - client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM This particular client is allowed only to add record: 31.0.2.192.in-addr.arpa. IN PTR client.example.com. Question is how to authorize record deletion. I tend to allow all delete operations for (reverse) name matching client's IP address. -- Petr^2 Spacek From simo at redhat.com Fri Mar 1 14:39:25 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Mar 2013 09:39:25 -0500 Subject: [Freeipa-devel] DNS update mechanism: news about update authorization In-Reply-To: <5130BB3A.2070405@redhat.com> References: <5130BB3A.2070405@redhat.com> Message-ID: <1362148765.2962.139.camel@willson.li.ssimo.org> On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote: > Hello list, > > we would like to share some news about DNS update mechanism: > > - It is possible to allow particular principal to update all records in a zone. > > - It is possible to allow clients to update own PTR records. PTR update can be > "authenticated and authorized" by source IP address of the TCP connection from > the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR > record with name 31.0.2.192.in-addr.arpa., nothing else. > > See examples in following how-to: > http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy > > > Simo pointed to fact that "TCP authenticated" update requests can be more > secure than current approach with "PTR synchronization" magic (done inside > bind-dyndb-ldap). > > Unfortunately, it is not possible to combine TCP "authentication" with > GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is > not possible to combine multiple requirements. > > 'tcp-self' rule ignores request signature completely. Implementation of (TCP > && signed) requirement will require patching BIND. I don't like that idea, > because we will deviate from plain BIND docs and it will cause confusion. > > We can propose a change and send patches to ISC. It should be possible to > implement new 'tcp-signed-self' mechanism with only few lines of code. The > question is how it should behave: > > Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed > to do tcp-self update? Should be at least a host/ principal, otherwise a mere user could change the PTR record, would be even better if we can match the fqdn int the host/ principal to the content of the PTR record. So if you sign with principal for host/foo.bar.baz and come from 10.11.22.33 then you can only create a PTR record of 10.11.22.33 -> foo.bar.baz > Should we implement configurable realm check? I.e. the update will be allowed > only if the update is signed by principal from specified Kerberos realm? This too would be nice but not as important. > How it should work with Kerberos trusts? You would prevent principals from a trusted domain to update DNS entries. Checking for the REALM part should be optional. > Also, it should be possible to implement more strict check: Updated name in > reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address > and *at the same time* name stored to PTR record has to match name in client's > principal. > > Example: > - client's IP address: 192.0.2.31 > - client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM Yeah I should have read the whole message trough before starting replying :-) > This particular client is allowed only to add record: > 31.0.2.192.in-addr.arpa. IN PTR client.example.com. > > Question is how to authorize record deletion. I tend to allow all delete > operations for (reverse) name matching client's IP address. Yes this would be ok, worst case the PTR is lost. Again I would allow only by principals of the type host/* or maybe DNS/* not from every principal. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Mar 1 15:15:07 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 01 Mar 2013 16:15:07 +0100 Subject: [Freeipa-devel] DNS update mechanism: news about update authorization In-Reply-To: <1362148765.2962.139.camel@willson.li.ssimo.org> References: <5130BB3A.2070405@redhat.com> <1362148765.2962.139.camel@willson.li.ssimo.org> Message-ID: <5130C5FB.9070205@redhat.com> On 1.3.2013 15:39, Simo Sorce wrote: > On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote: >> Hello list, >> >> we would like to share some news about DNS update mechanism: >> >> - It is possible to allow particular principal to update all records in a zone. >> >> - It is possible to allow clients to update own PTR records. PTR update can be >> "authenticated and authorized" by source IP address of the TCP connection from >> the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR >> record with name 31.0.2.192.in-addr.arpa., nothing else. >> >> See examples in following how-to: >> http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy >> >> >> Simo pointed to fact that "TCP authenticated" update requests can be more >> secure than current approach with "PTR synchronization" magic (done inside >> bind-dyndb-ldap). >> >> Unfortunately, it is not possible to combine TCP "authentication" with >> GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is >> not possible to combine multiple requirements. >> >> 'tcp-self' rule ignores request signature completely. Implementation of (TCP >> && signed) requirement will require patching BIND. I don't like that idea, >> because we will deviate from plain BIND docs and it will cause confusion. >> >> We can propose a change and send patches to ISC. It should be possible to >> implement new 'tcp-signed-self' mechanism with only few lines of code. The >> question is how it should behave: >> >> Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed >> to do tcp-self update? > > Should be at least a host/ principal, otherwise a mere user could change > the PTR record, would be even better if we can match the fqdn int the > host/ principal to the content of the PTR record. > > So if you sign with principal for host/foo.bar.baz and come from > 10.11.22.33 then you can only create a PTR record of 10.11.22.33 -> > foo.bar.baz > >> Should we implement configurable realm check? I.e. the update will be allowed >> only if the update is signed by principal from specified Kerberos realm? > > This too would be nice but not as important. > >> How it should work with Kerberos trusts? > > You would prevent principals from a trusted domain to update DNS > entries. > Checking for the REALM part should be optional. > >> Also, it should be possible to implement more strict check: Updated name in >> reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address >> and *at the same time* name stored to PTR record has to match name in client's >> principal. >> >> Example: >> - client's IP address: 192.0.2.31 >> - client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM > > Yeah I should have read the whole message trough before starting > replying :-) > >> This particular client is allowed only to add record: >> 31.0.2.192.in-addr.arpa. IN PTR client.example.com. >> >> Question is how to authorize record deletion. I tend to allow all delete >> operations for (reverse) name matching client's IP address. > > Yes this would be ok, worst case the PTR is lost. > Again I would allow only by principals of the type host/* or maybe DNS/* > not from every principal. I agree. We could imitate krb5-self semantics: Service part is hardcoded to 'host/' and REALM part is configurable: 'grant IPA.EXAMPLE.COM tcp-krb5-self;' Variant for AD machines: 'grant AD.EXAMPLE.COM tcp-ms-self;' AD variant will match names "machine$@AD.EXAMPLE.COM". -- Petr^2 Spacek From mkosek at redhat.com Fri Mar 1 16:12:11 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Mar 2013 17:12:11 +0100 Subject: [Freeipa-devel] [PATCHES] 98-101 Preserve case of LDAP attribute names In-Reply-To: <51260772.6090208@redhat.com> References: <510A8B55.70109@redhat.com> <510BA30A.4040601@redhat.com> <510FB6AF.20903@redhat.com> <510FCA84.40109@redhat.com> <5110FD62.4090006@redhat.com> <51111B1C.2010305@redhat.com> <511228A9.5060303@redhat.com> <5118EB4B.4080507@redhat.com> <5123A8C2.5000504@redhat.com> <5125E3A7.1090205@redhat.com> <51260772.6090208@redhat.com> Message-ID: <5130D35B.5020602@redhat.com> On 02/21/2013 12:39 PM, Jan Cholasta wrote: > On 21.2.2013 10:06, Jan Cholasta wrote: >> On 19.2.2013 17:30, Rob Crittenden wrote: >>> I think dropping raw=True in patch 99.3 is going to break a check later >>> where we look at the managedby attribute. Without raw this will be >>> managedby_host. >>> >> >> Fixed, thanks for the catch. >> >> I have also made 2 changes to patch 100 (made sure the entry returned by >> ldap2.get_ipa_config is using the correct IPASimpleLDAPObject and >> changed LDAPEntry.clone to be less fragile). >> >> Updated (and rebased) patches attached. >> >> Honza >> > > Whoops, wrong patches. Correct patches attached. > > Honza > > These patches were pushed to master as part of the big LDAP refactoring push. See https://fedorahosted.org/freeipa/ticket/2660 for details. Martin From mkosek at redhat.com Fri Mar 1 16:13:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Mar 2013 17:13:37 +0100 Subject: [Freeipa-devel] [PATCHES] 146-164 LDAP code refactoring (Part 4) In-Reply-To: <512E0348.2040407@redhat.com> References: <50F83498.9050104@redhat.com> <50FD7CF8.2070401@redhat.com> <50FEAA66.4010704@redhat.com> <51010252.1030200@redhat.com> <51013FD5.8030004@redhat.com> <51028E91.4070601@redhat.com> <51063804.4060507@redhat.com> <5106949D.408@redhat.com> <5107ED49.4000502@redhat.com> <5108EDAB.9040406@redhat.com> <510A40C0.5060406@redhat.com> <510AB17B.80909@redhat.com> <510B8116.9060409@redhat.com> <510B89BA.2040903@redhat.com> <510BD364.7050809@redhat.com> <512387D1.60603@redhat.com> <5124BB8F.80803@redhat.com> <512B93A6.4050602@redhat.com> <512C8859.8050001@redhat.com> <512E0348.2040407@redhat.com> Message-ID: <5130D3B1.7000901@redhat.com> On 02/27/2013 01:59 PM, Jan Cholasta wrote: > On 26.2.2013 11:03, Petr Viktorin wrote: >>> Thanks. I think you should also add a tearDown method to test_LDAPEntry >>> which disconnects self.conn if it is connected (the same thing test_ldap >>> does). >> >> Thanks for the catch, added. >> > > ACK. > These patches were pushed to master as part of the big LDAP refactoring push. See https://fedorahosted.org/freeipa/ticket/2660 for details. Martin From mkosek at redhat.com Fri Mar 1 16:14:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Mar 2013 17:14:22 +0100 Subject: [Freeipa-devel] Using the new LDAP code In-Reply-To: <512E40C8.2030809@redhat.com> References: <512DF224.7000804@redhat.com> <512E2FA3.9050601@redhat.com> <512E331C.2050106@redhat.com> <512E3EE6.8080707@redhat.com> <512E40D4.7030306@redhat.com> <512E40C8.2030809@redhat.com> Message-ID: <5130D3DE.2090600@redhat.com> On 02/27/2013 06:22 PM, John Dennis wrote: > On 02/27/2013 12:22 PM, Jan Cholasta wrote: >> On 27.2.2013 18:14, John Dennis wrote: >>> On 02/27/2013 11:23 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 27.2.2013 17:09, John Dennis wrote: >>>>>> IPA plugins traditionally use (dn, entry_attrs) pairs to represent >>>>>> entries. To make that work, iterating over an LDAPEntry will, for now, >>>>>> yield the DN and the entry itself. Always use keys() or values() when >>>>>> iterating over an entry. >>>>> >>>>> I'm trying parse what the above means, it seems to be one of the two: >>>>> >>>>> 1) There is still a bunch of code that continues to use 2-tuples in the >>>>> plugins and additional work remains to converge on a single API. >>>>> >>>>> 2) All the code that used 2-tuples has been cleaned up and expunged, >>>>> however if the old 2-tuple methodology was used it would still work. >>>>> >>>> >>>> it's the former, there is still code that uses 2-tuples. >>> >>> O.K. so we're still a ways away from completing the task. Would this be >>> a correct summary? >>> >>> Phase 1 is completed, a consistent API has been defined and implemented. >>> Phase 2 is converting all the code to use the API defined in Phase 1, a >>> task yet to be done. >>> >> >> Correct. But I don't think converting 2-tuples to the new API will be a >> huge task. > > Cool! > Just FYI, I just pushed the relevant patches to master branch. Enjoy! Thanks to Petr and Honza for doing this refactoring! Martin From jdennis at redhat.com Fri Mar 1 16:26:10 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 01 Mar 2013 11:26:10 -0500 Subject: [Freeipa-devel] Using the new LDAP code In-Reply-To: <5130D3DE.2090600@redhat.com> References: <512DF224.7000804@redhat.com> <512E2FA3.9050601@redhat.com> <512E331C.2050106@redhat.com> <512E3EE6.8080707@redhat.com> <512E40D4.7030306@redhat.com> <512E40C8.2030809@redhat.com> <5130D3DE.2090600@redhat.com> Message-ID: <5130D6A2.8060103@redhat.com> On 03/01/2013 11:14 AM, Martin Kosek wrote: > Just FYI, I just pushed the relevant patches to master branch. Enjoy! Thanks to > Petr and Honza for doing this refactoring! Yes, thanks and kudos to Petr and Honza for this work. We really needed to clean up this part of our code base and I'm confident code maintenance and robustness will benefit and serve the team and project going forward. Thanks again. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Fri Mar 1 16:54:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 01 Mar 2013 17:54:28 +0100 Subject: [Freeipa-devel] [PATCHES] 102-104 Remove DN normalization In-Reply-To: <51102123.1040209@redhat.com> References: <510FB821.6040805@redhat.com> <510FE353.5080301@redhat.com> <51102123.1040209@redhat.com> Message-ID: <5130DD44.4050307@redhat.com> On 02/04/2013 09:59 PM, Jan Cholasta wrote: > On 4.2.2013 17:35, Petr Viktorin wrote: >> On 02/04/2013 02:31 PM, Jan Cholasta wrote: >>> Hi, >>> >>> this patchset removes DN normalization code from the framework. Full DNs >>> including the configured suffix are used instead and must be used in new >>> code. >>> >>> Honza >>> >> >> Hooray for less magic! >> >> I've applied the patches on top of 98-101 (i.e. on top of the big >> refactoring). > > Right, I forgot to mention that, sorry. > >> They work well, ACK. >> > > Thanks for the review. > > Honza > FYI: these patches were pushed to master as part of the big LDAP refactoring push. See https://fedorahosted.org/freeipa/ticket/2660 for details. -- Petr? From pviktori at redhat.com Fri Mar 1 16:55:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 01 Mar 2013 17:55:06 +0100 Subject: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data In-Reply-To: <50F81627.3020703@redhat.com> References: <50F6CB11.4010008@redhat.com> <50F6EBE5.9060307@redhat.com> <50F7B134.4000201@redhat.com> <50F7E4A5.5000400@redhat.com> <50F7FF69.8010509@redhat.com> <50F81627.3020703@redhat.com> Message-ID: <5130DD6A.6060307@redhat.com> On 01/17/2013 04:17 PM, Petr Viktorin wrote: > On 01/17/2013 02:40 PM, Jan Cholasta wrote: >> On 17.1.2013 12:46, Petr Viktorin wrote: >>> On 01/17/2013 09:07 AM, Jan Cholasta wrote: >>>> >>>> While this works for dict, I'm not sure if it applies to *all* >>>> dict-like >>>> classes that we use. >>> >>> I don't think we have any classes where it doesn't apply. >>> >>>> Once we completely get rid of entry tuples, we can reintroduce a >>>> dict-like __iter__. IMO new code should not be punished (i.e. forced to >>>> use .keys()) for the crimes (i.e. tuples) of the old code. >>> >>> Yes, eventually. Though I'd like it to raise an exception for some time, >>> so any external plugins that rely on it fail rather than get bad data. >> >> OK. But I think external plugins will break either-way, as we don't >> really maintain backward compatibility in our internal APIs. >> >>> >>>> We should decided whether we want to use entry['dn'] or entry.dn and >>>> use >>>> only that in new code. I like entry.dn more, as it better >>>> corresponds to >>>> the special meaning of dn in entries. >>> >>> I also like entry.dn, at least in most cases, but if we don't >>> synchronize them then we need to remove entry['dn'] completely. Having >>> misleading/stale data in the object isn't good. >>> There are some cases where entry['dn'] makes sense, such as iterating >>> over all attributes. >>> If we're going to have validation for every attribute anyway, I don't >>> think synchronizing the two would be a major problem. Especially since >>> entry.dn is already a property. >>> >> >> OK, we will deal with that in further patches. >> >> Updated patch attached. >> >> Honza >> > > ACK. I'll start working on top of this. > FYI: this patch was pushed to master as part of the big LDAP refactoring push. See https://fedorahosted.org/freeipa/ticket/2660 for details. -- Petr? From rcritten at redhat.com Fri Mar 1 22:57:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Mar 2013 17:57:11 -0500 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master Message-ID: <51313247.1040801@redhat.com> Implement the design at http://freeipa.org/page/V3/Recover_DNA_Ranges Note that this required some new ACIs in cn=config which is not replicated so the range-set commands won't work against older instances. It should be gracefully handled though. It also doesn't work so well if you try it using a delegated administrator, see ticket https://fedorahosted.org/freeipa/ticket/3480 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1088-dnarange.patch Type: text/x-diff Size: 27466 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 1 22:58:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Mar 2013 17:58:18 -0500 Subject: [Freeipa-devel] [PATCH] 1089 fix some ipa-replica-manage error handling Message-ID: <5131328A.70801@redhat.com> I found a couple of problems in error handling in ipa-replica-manage when doing some oddball testing. See the ticket for full details. This may apply by itself but in my tree it exists after patch 1088. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1089-errors.patch Type: text/x-diff Size: 2009 bytes Desc: not available URL: From edewata at redhat.com Sat Mar 2 19:38:36 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 02 Mar 2013 13:38:36 -0600 Subject: [Freeipa-devel] [PATCH] 259 Combobox keyboard support In-Reply-To: <512E021F.5030004@redhat.com> References: <940957870.1823903.1361926213062.JavaMail.root@redhat.com> <512E021F.5030004@redhat.com> Message-ID: <5132553C.9010606@redhat.com> On 02/27/2013 06:54 AM, Petr Vobornik wrote: > On 02/27/2013 01:50 AM, Endi Sukma Dewata wrote: >> Looks good. The patch already provides improvements, so feel free to >> push. >> >>> * when CB is non-editable, user can start typing, first character >>> will open list, second will be entered into search input. Note: I >>> wanted to copy the first char to the search box as well, but I did not >>> figure out reliable method for converting keycode to char for non ASCII >>> keyboard layouts >> >> Could we use keypress() for this instead of keydown()? See >> http://api.jquery.com/keypress/. The keypress() should return the >> actual character, whereas the keydown() would return the code of the >> keyboard key so it wouldn't be able to distinguish between 'a' and >> 'A', which is not what we want. > > Weird, I could bet that I tried it and it failed. Probably I did some > stupid mistake. > > Anyway there are still limitations: > 1) Firefox behaves differently than Chrome: > * when keydown is prevented. FF raises keypress, Chrome doesn't > * FF doesn't raise keypress for '?' (Czech character), Chrome does. > (the input method is pressing 'shift', '?' and 's'. > 2) what to do on paste? We can't use input nor change event for > evaluating it - default is prevented. > > I'm inclined to leave it as is. Yeah. We can revisit this another time. It's not a blocking issue. > Mentioned cases can be tested in following fiddle: > http://jsfiddle.net/vopet/aMynp/ > >> Another minor thing, if the search box is in focus, you can use the >> Up/Down arrow to go to the list. However, from the list you cannot >> use the Up/Down arrow to go back to the search box, you'd have to use >> the Tab key. It's not really a problem, but it's not that consistent. > Up/Down keys are natural way of changing value of a list - this part > seems OK to me. So Up/Down arrow in search box might the problem, but > I consider it a feature - saves some strokes. Also, User can always > use tab to switch between search box and list. I'm OK with the Up/Down arrow in search box too, but if it's not consistent people may think it's a bug. So I'd suggest we make it such that you can use Up/Down to go back to the search box. All of the above are minor. The patch itself is ACKed. -- Endi S. Dewata From edewata at redhat.com Sat Mar 2 19:40:36 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 02 Mar 2013 13:40:36 -0600 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page Message-ID: <513255B4.8020903@redhat.com> ----- Original Message ----- > First two patches are bug fixes which are required for third patch. > Depends on my patch #259 (Combobox keyboard support) > > 1) [PATCH] Fix dirty state update of editable combobox > > Editable combobox didn't update it's dirty state correctly. CB had > it's own internal value changed event, which was incorrectly used. It was > removed and widget's value_changed event was used instead. ACK. > 2) [PATCH] Fix handling of no_update flag in Web UI > > There was an incorrect check for no_update flag. Check was performed > as if the flag was an attribute of object not an item of array. Hence, > the flag never caused any effect. ACK. > 3) [PATCH] Global trust config page > > https://fedorahosted.org/freeipa/ticket/3333 > Just two notes: > > ipantfallbackprimarygroup requires a posix group. Our API currently > doesn't support search based on object classes therefore the entity > select widget incorrectly offers non posix groups as well. Are we planning to add the missing functionality? Right now you'll get 'group not found' if you select a non-POSIX group, which is confusing because the group does exist. Possible solutions: 1. Fix the error message to say ' is not a POSIX group' or 'Fallback primary group requires a POSIX group'. 2. Execute another batch of group-show operations to get the object classes of the groups to be displayed and filter out the non-POSIX groups. > Another problem is that hidden 'Default SMB Group' is not listed. > Hence it couldn't be set again after a modification. I made the combobox > editable (first usage, so it revealed a bug) to avoid this problem. > User can enter garbage, but the framework should handle that. This is a little difficult to use. You'll need to know that you have to type 'Default SMB Group' to go back to the default and the UI doesn't show that as an acceptable value. Possible solutions: 1. Add the 'Default SMB Group' as the first entry in the drop down list so you can reselect it again. The drop down list doesn't need to be editable. 2. Use radio buttons to separate the default value from other values: Fallback primary group: (o) Default SMB Group ( ) POSIX group: [ drop down list ] Regardless, I think the server API needs to be changed to accept an empty value to go back to the default value instead of taking 'Default SMB Group'. A default value should be simple and not something that will potentially conflict with a non-default value that happens to have the same name. -- Endi S. Dewata From pspacek at redhat.com Mon Mar 4 08:12:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 Mar 2013 09:12:05 +0100 Subject: [Freeipa-devel] What about desktop policies? In-Reply-To: <1361971001.25048.15.camel@toron.pzo.lgs.com.ve> References: <1361819744.2111.48.camel@toron.pzo.lgs.com.ve> <512D16EC.7090102@redhat.com> <1361971001.25048.15.camel@toron.pzo.lgs.com.ve> Message-ID: <51345755.6000800@redhat.com> On 27.2.2013 14:16, Loris Santamaria wrote: > El mar, 26-02-2013 a las 15:11 -0500, Dmitri Pal escribi?: >> On 02/25/2013 02:15 PM, Loris Santamaria wrote: >>> Hi all, >>> >>> some customers of ours are interested in managing desktop policies for >>> their linux workstations, really nothing fancy, corporate background and >>> proxy settings are the most common requests. >>> >>> In the past I created Gnome desktop profiles using Sabayon, distributed >>> them using puppet and associated them to user accounts with a Sabayon >>> specific LDAP attribute, a process a bit convoluted, and no longer >>> possible since sabayon is no longer developed. Also it was really buggy, >>> and very gnome specific. >>> >>> I was thinking in how integrate desktop policies in freeIPA in a general >>> manner and I wanted to share my ideas with you. Hopefully some of this >>> may be incorporated in IPA at some point in the future. >>> >>> Properties of a "policy": >>> >>> * is a collection of "settings" >>> * can be associated with users or groups (desktop policy) or with >>> hosts or hostgroups (system policy) >>> * is associated with a "consumer", the client software that >>> interprets and applies the policy. This way one could define >>> policies for dconf, policies for kde, policies for WBEM. >>> >>> Properties of a "setting" >>> * is a key-value pair >>> * must conform to a "schema" >>> * may be mandatory >>> >>> The schema: >>> * indicates which attributes a policy may consist of >>> * indicates which kind of value may take an attribute. Bool, >>> string, etc. >>> * There may be more than one schema for a given "consumer". For >>> example for dconf you may have an evolution schema, a >>> gnome-games schema, etc. >>> >>> Sample policy creation process: >>> 1. The admin creates a new schema in IPA, with a command like "ipa >>> schema-add --consumer=dconf gnomeSettingsSchema" >>> 2. The admin adds some definition to the schema: "ipa >>> schema-add-setting gnomeSettingsSchema >>> --name=/schemas/desktop/gnome/background/picture_filename >>> --type=string --description='File to use for the background >>> image.'" >>> 3. He creates a new policy: "ipa policy-add corporateBackground >>> --type=desktop --consumer=dconf >>> 4. He adds a setting to the policy: "ipa policy-add-setting >>> corporateBackground >>> --name=/schemas/desktop/gnome/background/picture_filename >>> --value=file:///san/wp/wallpaper.jpg --mandatory". Ipa would >>> check that the key is defined in one of the dconf related >>> schemas and the value is acceptable for that key. >>> 5. He associates the policy with users: "ipa-policy-add-user >>> corporateBackground --groups=ipausers" >>> >>> How should the policy be applied? On the workstation, on startup, an ipa >>> related utility should check if there are any policies related to the >>> workstation, if there are any it should call a helper capable of >>> applying a specific type of policy. Then on user logon another ipa >>> related utility should check if there are any policies associated with >>> the user and call the appropriate helper, if available. >>> >>> For the policy created in the above example, on logon the ipa policy >>> utility would find that there is a policy of type dconf associated with >>> the user. It would check if there is a dconf policy helper installed and >>> if positive it would call the helper passing it the parameters defined >>> in the policy. >>> >>> Hope this is useful at least as a starting point in defining desktop >>> policies in IPA. >> >> This is great! >> Thank you for sharing some ideas. >> We sort of stayed away from centralized policy management for quite >> some time. >> Originally we thought that IPA will do policy management and did a lot >> of design around it. >> However at some point we realized that there is an overlap with the >> system management and content management for which things like puppet >> are more suitable. We said then that IdM would focus on managing >> identity related policies that are traditionally served via LDAP. >> The things that you are talking about resemble to some extent MSFT GPO >> and we felt that IdM might not be the right place for it. May be it is >> time to reassess it. >> I would however not go that route at least yet. > > Hey puppet is great and we use it a lot to install packages and to > distribute configuration files, yet it is not so great to set these > key=value kind of settings of which more and more "modern" software > consists of. When you take into consideration gconf settings for gnome > 2.x, dconf settings for gnome 3.x, mozilla settings, thunderbird > settings it quickly becomes a PITA to manage them distributing around > files with puppet. Did you look at http://augeas.net/ ? Puppet + Augeas could be very very strong combination. Petr^2 Spacek > Having those key=value pairs in an ldap would allow a helper on the > client to pull only the keys it understands and to merge them in the > configuration database in the appropriate way. > > Of course i took inspiration from AD GPOs, yet I think that IPA should > manage these key=value kind of policies in a more general way, for one > because nobody in the linux world controls all of the desktop stack and > because the end user experience is changing so fast that we can't really > know how the user will access IT resources ten year from now. >> >> If Desktop can read additional properties related to user (background, >> default language, etc.) from SSSD over a DBUS interface the SSSD >> should be able to pull this data from the IdM (eventually). On the IdM >> we probably can make these additional attributes available in the user >> entries using class of service like we do with password policies. >> >> We have plans for SSSD to handle more attributes than posix and >> integrate with Desktop. >> https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService >> >> IMO once this work is started we would be able to see how we can >> configure and serve more data from IPA for clients to consume. >> >> Meanwhile I suggest you create a ticket in IPA trac and put your ideas >> there. > > Ok I'll file the RFE. From pspacek at redhat.com Mon Mar 4 13:22:34 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 Mar 2013 14:22:34 +0100 Subject: [Freeipa-devel] [PATCH 0117] Fix crash caused by invalid query/transfer policy Message-ID: <5134A01A.7050500@redhat.com> Hello, Fix crash caused by invalid query/transfer policy. Please double-check correctness. The ISC parser is really complex beast! Thank you. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0117-Fix-crash-caused-by-invalid-query-transfer-policy.patch Type: text/x-patch Size: 3259 bytes Desc: not available URL: From atkac at redhat.com Mon Mar 4 13:58:22 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 14:58:22 +0100 Subject: [Freeipa-devel] [PATCH 0077] Refactor settings subsystem In-Reply-To: <51237F79.4020006@redhat.com> References: <5072D551.10703@redhat.com> <51237F79.4020006@redhat.com> Message-ID: <20130304135820.GA2274@redhat.com> On Tue, Feb 19, 2013 at 02:34:49PM +0100, Petr Spacek wrote: > On 8.10.2012 15:29, Petr Spacek wrote: > >Hello, > > > >this patch refactors setting subsystem. After some experimenting I chosen > >simple implementation with static arrays, no RBT trees involved. Speed can be > >improved by reordering items in arrays. > > > >Commit message: > > > > Refactor settings subsystem. > > > > Settings are stored in tree of settings_set_t structures. > > All settings should be accessed only through setting* functions. > > Mutual exclusion during write is done by switching to single > > thread mode. > > > > Setting_get() function doesn't copy strings, so changing the > > original string can lead to obscure bugs. > > This way is okay as long as strings are not changed dynamically > > at run-time. > > > > Unknown setting in configuration file leads to failure rather than > > silent ignoring it. > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/53 > > https://fedorahosted.org/bind-dyndb-ldap/ticket/81 > > Re-based & amended & tested patch is attached. The main idea is the same. > > >Adam, I'm still looking for way how to handle strings in settings. We have to > >prevent string change/deallocation as long as somebody has a pointer to the > >string (I mean pointer obtained through setting_get("name_of_setting") call). > > > >The only way which I can see is returning setting_string structure like > > > >setting_string struct { > > isc_refcount_t counter; > > isc_mem_t *mctx; > > char *str; > >}; > > After some poking to isc_task_beginexclusive() I consider the > "struct setting_string" idea redundant. > > >Caller has to call setting_string_free() when string can be freed. > >Setting_string_free() will decrement counter by one and free whole structure > >if and only if counter reaches 0. > > > >Is it meaningful? Should I separate setting_get_* for each datatype? Or just > >for setting_get_string() and let setting_get() universal for integers and > >booleans? > > I separated setting_get_bool/uint/str from the universal > setting_get() to enable type checks. Hi Peter, check my comments below, please. I found just some minor issues, the patch overally looks fine. Regards, Adam > From ecff7be859f7c53c167b7ccd4d4d0cc2dfc990a6 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 4 Oct 2012 16:44:16 +0200 > Subject: [PATCH] Refactor settings subsystem. > > Settings are stored in tree of settings_set_t structures. > All settings should be accessed only through setting* functions. > Mutual exclusion during write is done by switching to single > thread mode. > > setting_get_str() function doesn't copy strings, so original strings > have to stay unchanged. > > Unknown setting and duplicate settings in configuration file > lead to failure rather than silent ignoring them. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/53 > https://fedorahosted.org/bind-dyndb-ldap/ticket/81 > > Signed-off-by: Petr Spacek > --- > src/cache.c | 32 +- > src/cache.h | 4 +- > src/ldap_entry.c | 6 +- > src/ldap_entry.h | 2 +- > src/ldap_helper.c | 783 +++++++++++++++++++++++++++--------------------- > src/ldap_helper.h | 5 + > src/settings.c | 843 ++++++++++++++++++++++++++++++++++++++-------------- > src/settings.h | 86 ++++-- > src/zone_manager.c | 27 +- > src/zone_register.c | 82 ++++- > src/zone_register.h | 9 +- > 11 files changed, 1243 insertions(+), 636 deletions(-) > rewrite src/settings.c (60%) > > diff --git a/src/cache.c b/src/cache.c > index fd57fd92eb35dcbbd5c1e1911a93730624e30002..b475d2319137845b7f59fa6d15b21847199554cd 100644 > --- a/src/cache.c > +++ b/src/cache.c > @@ -38,11 +38,12 @@ > #include "util.h" > > struct ldap_cache { > - isc_mutex_t mutex; /* TODO: RWLOCK? */ > - isc_mem_t *mctx; > - dns_rbt_t *rbt; > - const isc_interval_t *cache_ttl; /* pointer to LDAP instance */ > - const isc_boolean_t *psearch; /* pointer to LDAP instance */ > + isc_mutex_t mutex; /* TODO: RWLOCK? */ > + isc_mem_t *mctx; > + dns_rbt_t *rbt; > + /* Values for "fast path" - copied from settings_set_t structure. */ > + isc_interval_t cache_ttl; > + isc_boolean_t psearch; > }; > > typedef struct { > @@ -78,9 +79,9 @@ cache_node_create(ldap_cache_t *cache, cache_node_t **nodep) > isc_mem_attach(cache->mctx, &node->mctx); > ZERO_PTR(&node->rdatalist); > /* Do not set the ttl when psearch is enabled. */ > - if (*cache->psearch == ISC_FALSE) > + if (cache->psearch == ISC_FALSE) > CHECK(isc_time_nowplusinterval(&node->valid_until, > - cache->cache_ttl)); > + &cache->cache_ttl)); > > *nodep = node; > return ISC_R_SUCCESS; > @@ -91,33 +92,28 @@ cleanup: > return result; > } > > -/** > - * @param[in] cache_ttl ISC interval in LDAP instance shared by all caches > - * @param[in] psearch boolean in LDAP instance shared by all caches > - */ > isc_result_t > -new_ldap_cache(isc_mem_t *mctx, const isc_interval_t *cache_ttl, > - const isc_boolean_t *psearch, ldap_cache_t **cachep) > +new_ldap_cache(isc_mem_t *mctx, settings_set_t *set, ldap_cache_t **cachep) > { > isc_result_t result; > ldap_cache_t *cache = NULL; > + isc_uint32_t cache_ttl_int; > > - REQUIRE(cache_ttl != NULL); > - REQUIRE(psearch != NULL); > REQUIRE(cachep != NULL && *cachep == NULL); > > CHECKED_MEM_GET_PTR(mctx, cache); > ZERO_PTR(cache); > isc_mem_attach(mctx, &cache->mctx); > > - cache->cache_ttl = cache_ttl; > - if (!isc_interval_iszero(cache_ttl)) { > + CHECK(setting_get_bool("psearch", set, &cache->psearch)); > + CHECK(setting_get_uint("cache_ttl", set, &cache_ttl_int)); > + isc_interval_set(&cache->cache_ttl, cache_ttl_int, 0); > + if (cache_ttl_int) { > CHECK(dns_rbt_create(mctx, cache_node_deleter, NULL, > &cache->rbt)); > CHECK(isc_mutex_init(&cache->mutex)); > } > > - cache->psearch = psearch; > *cachep = cache; > return ISC_R_SUCCESS; > > diff --git a/src/cache.h b/src/cache.h > index 7c7e69b305d3021f154ebb17d5b879ba8f34590e..567d176da0e9e31e96fdae869c10643cdc03c27c 100644 > --- a/src/cache.h > +++ b/src/cache.h > @@ -23,15 +23,15 @@ > #define _LD_CACHE_H_ > > #include "types.h" > +#include "settings.h" > > typedef struct ldap_cache ldap_cache_t; > > /* > * Create a new cache. > */ > isc_result_t > -new_ldap_cache(isc_mem_t *mctx, const isc_interval_t *cache_ttl, > - const isc_boolean_t *psearch, ldap_cache_t **cachep); > +new_ldap_cache(isc_mem_t *mctx, settings_set_t *set, ldap_cache_t **cachep); > > /* > * Free all resources used up by the cache. > diff --git a/src/ldap_entry.c b/src/ldap_entry.c > index 509995cd682956dc9afb58e04716f8bb63014f09..d32dc86ecc3af4866105bc96a6012d0ee964f4f5 100644 > --- a/src/ldap_entry.c > +++ b/src/ldap_entry.c > @@ -349,7 +349,7 @@ ldap_entry_nextrdtype(ldap_entry_t *entry, ldap_attribute_t **attrp, > } > > isc_result_t > -ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > +ldap_entry_getfakesoa(ldap_entry_t *entry, const char *fake_mname, > ld_string_t *target) > { > isc_result_t result = ISC_R_NOTFOUND; > @@ -367,9 +367,9 @@ ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > REQUIRE(target != NULL); > > str_clear(target); > - if (str_len(fake_mname) > 0) { > + if (strlen(fake_mname) > 0) { > i = 1; > - CHECK(str_cat(target, fake_mname)); > + CHECK(str_cat_char(target, fake_mname)); > CHECK(str_cat_char(target, " ")); > } > for (; soa_attrs[i] != NULL; i++) { > diff --git a/src/ldap_entry.h b/src/ldap_entry.h > index 02923a8735c20bc318fdf011b434127c9c52a53b..5a027e672b7591ae57551c175764e7517acea758 100644 > --- a/src/ldap_entry.h > +++ b/src/ldap_entry.h > @@ -107,7 +107,7 @@ ldap_entry_nextrdtype(ldap_entry_t *entry, ldap_attribute_t **attrp, > dns_rdatatype_t *rdtype); > > isc_result_t > -ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > +ldap_entry_getfakesoa(ldap_entry_t *entry, const char *fake_mname, > ld_string_t *target); > > /* > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 71b96ce5eef2a249f7d16c448c70e2c2068d271d..25a4d125adce57a533d53ea6bf71bd062aa1a8a0 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -157,32 +157,13 @@ struct ldap_instance { > /* krb5 kinit mutex */ > isc_mutex_t kinit_lock; > > - /* Settings. */ > - ld_string_t *uri; > - ld_string_t *base; > - unsigned int connections; > - unsigned int reconnect_interval; > - unsigned int timeout; > - ldap_auth_t auth_method; > - ld_string_t *bind_dn; > - ld_string_t *password; > - ld_string_t *krb5_principal; > - ld_string_t *sasl_mech; > - ld_string_t *sasl_user; > - ld_string_t *sasl_auth_name; > - ld_string_t *sasl_realm; > - ld_string_t *sasl_password; > - ld_string_t *krb5_keytab; > - ld_string_t *fake_mname; > - isc_boolean_t psearch; > - isc_interval_t cache_ttl; > - ld_string_t *ldap_hostname; > isc_task_t *task; > isc_thread_t watcher; > isc_boolean_t exiting; > - isc_boolean_t sync_ptr; > - isc_boolean_t dyn_update; > - isc_boolean_t serial_autoincrement; > + > + /* Settings. */ > + settings_set_t *local_settings; > + settings_set_t *global_settings; > dns_forwarders_t orig_global_forwarders; /* from named.conf */ > }; > > @@ -250,6 +231,47 @@ struct ldap_psearchevent { > int chgtype; > }; > > +extern const settings_set_t const settings_default_set; > + > +/** Local configuration file */ > +static const setting_t settings_local_default[] = { > + { "uri", no_default_string }, > + { "connections", no_default_uint }, > + { "reconnect_interval", no_default_uint }, > + { "timeout", no_default_uint }, > + { "cache_ttl", no_default_uint }, > + { "base", no_default_string }, > + { "auth_method", no_default_string }, > + { "auth_method_enum", no_default_uint }, > + { "bind_dn", no_default_string }, > + { "password", no_default_string }, > + { "krb5_principal", no_default_string }, > + { "sasl_mech", no_default_string }, > + { "sasl_user", no_default_string }, > + { "sasl_auth_name", no_default_string }, > + { "sasl_realm", no_default_string }, > + { "sasl_password", no_default_string }, > + { "krb5_keytab", no_default_string }, > + { "fake_mname", no_default_string }, > + { "zone_refresh", no_default_uint }, > + { "psearch", no_default_boolean }, > + { "ldap_hostname", no_default_string }, > + { "sync_ptr", no_default_boolean }, > + { "dyn_update", no_default_boolean }, > + { "serial_autoincrement", no_default_boolean }, > + { "verbose_checks", no_default_boolean }, > + end_of_settings > +}; > + > +/** Global settings from idnsConfig object. */ > +static setting_t settings_global_default[] = { > + { "dyn_update", no_default_boolean }, > + { "sync_ptr", no_default_boolean }, > + { "zone_refresh", no_default_uint }, > +/* { "psearch", no_default_boolean }, unsupported */ > + end_of_settings > +}; > + > /* > * Forward declarations. > */ > @@ -264,14 +286,14 @@ static isc_result_t findrdatatype_or_create(isc_mem_t *mctx, > dns_rdatatype_t rdtype, dns_ttl_t ttl, dns_rdatalist_t **rdlistp); > static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult, > dns_name_t *origin, ldap_entry_t *entry, > - ldapdb_rdatalist_t *rdatalist, const ld_string_t *fake_mname); > + ldapdb_rdatalist_t *rdatalist, const char *fake_mname); > static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_qresult_t *qresult, > dns_rdataclass_t rdclass, dns_rdatatype_t rdtype, > dns_name_t *origin, const char *rdata_text, > dns_rdata_t **rdatap); > static isc_result_t ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > ldap_qresult_t *qresult, dns_name_t *origin, > - const ld_string_t *fake_mname, ld_string_t *buf, > + const char *fake_mname, ld_string_t *buf, > ldapdb_rdatalist_t *rdatalist); > static inline isc_result_t ldap_get_zone_serial(ldap_instance_t *inst, > dns_name_t *zone_name, isc_uint32_t *serial); > @@ -332,43 +354,136 @@ static void psearch_update(ldap_instance_t *inst, ldap_entry_t *entry, > static isc_threadresult_t > ldap_psearch_watcher(isc_threadarg_t arg); > > +#define PRINT_BUFF_SIZE 10 /* for unsigned int 2^32 */ > +isc_result_t > +validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) { > + isc_result_t result; > + > + isc_boolean_t psearch; > + isc_boolean_t serial_autoincrement; > + isc_uint32_t uint; > + const char *sasl_mech = NULL; > + const char *sasl_user = NULL; > + const char *krb5_principal = NULL; > + ld_string_t *buff = NULL; > + > + char print_buff[PRINT_BUFF_SIZE]; > + const char *auth_method_str = NULL; > + ldap_auth_t auth_method_enum = AUTH_INVALID; > + > + /* Set timer for deadlock detection inside semaphore_wait_timed . */ > + CHECK(setting_get_uint("timeout", set, &uint)); > + if (semaphore_wait_timeout.seconds < uint*SEM_WAIT_TIMEOUT_MUL) > + semaphore_wait_timeout.seconds = uint*SEM_WAIT_TIMEOUT_MUL; > + > + CHECK(setting_get_bool("psearch", set, &psearch)); > + CHECK(setting_get_uint("connections", set, &uint)); > + if (!psearch && uint < 1) { > + log_error("zone refresh mode requires one connection at least"); > + CLEANUP_WITH(ISC_R_RANGE); > + } > + else if (psearch && uint < 2) { > + log_error("persistent search mode requires two connections " > + "at least"); > + /* watcher needs one and update_*() requests second connection */ > + CLEANUP_WITH(ISC_R_RANGE); > + } > + > + CHECK(setting_get_bool("serial_autoincrement", set, &serial_autoincrement)); > + if (serial_autoincrement && !psearch) { > + log_error("SOA serial number auto-increment feature requires " > + "persistent search"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + > + CHECK(setting_get_uint("zone_refresh", set, &uint)); > + if (uint != 0 && psearch) { > + log_error("zone refresh and persistent search " > + "cannot be enabled at same time"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + > + /* Select authentication method. */ > + CHECK(setting_get_str("auth_method", set, &auth_method_str)); > + auth_method_enum = AUTH_INVALID; > + for (int i = 0; supported_ldap_auth[i].name != NULL; i++) { > + if (!strcasecmp(auth_method_str, supported_ldap_auth[i].name)) { > + auth_method_enum = supported_ldap_auth[i].value; > + break; > + } > + } > + if (auth_method_enum == AUTH_INVALID) { > + log_error("unknown authentication method '%s'", > + auth_method_str); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + CHECK(isc_string_printf(print_buff, PRINT_BUFF_SIZE, "%u", auth_method_enum)); > + CHECK(setting_set("auth_method_enum", inst->local_settings, print_buff, > + inst->task)); > + > + /* check we have the right data when SASL/GSSAPI is selected */ > + CHECK(setting_get_str("sasl_mech", set, &sasl_mech)); > + CHECK(setting_get_str("krb5_principal", set, &krb5_principal)); > + CHECK(setting_get_str("sasl_user", set, &sasl_user)); > + > + if ((auth_method_enum == AUTH_SASL) && > + (strcasecmp(sasl_mech, "GSSAPI") == 0)) { > + if ((krb5_principal == NULL) || (strlen(krb5_principal) == 0)) { > + if ((sasl_user == NULL) || (strlen(sasl_user) == 0)) { > + char hostname[HOST_NAME_MAX]; > + if (gethostname(hostname, HOST_NAME_MAX) != 0) { > + log_error("SASL mech GSSAPI defined " > + "but krb5_principal and " > + "sasl_user are empty and" > + "gethostname() failed"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } else { > + CHECK(str_sprintf(buff, > + "DNS/%s", hostname)); > + log_debug(2, "SASL mech GSSAPI defined " > + "but krb5_principal and " > + "sasl_user are empty, using " > + "default '%s'", > + str_buf(buff)); > + CHECK(setting_set("krb5_principal", set, > + str_buf(buff), > + inst->task)); > + } > + } else { > + CHECK(setting_set("krb5_principal", set, > + sasl_user, > + inst->task)); > + } > + } > + } else if (auth_method_enum == AUTH_SASL) { > + log_info("SASL mechanisms other than GSSAPI+Kerberos " > + "are untested; expect problems"); > + } > + > + if (settings_set_isfilled(set) != ISC_TRUE) > + result = ISC_R_FAILURE; > + > +cleanup: > + if (result != ISC_R_SUCCESS) > + log_error_r("LDAP config validation failed for database '%s'", > + inst->db_name); > + return result; > +} > +#undef PRINT_BUFF_SIZE > + > +#define PRINT_BUFF_SIZE 255 > isc_result_t > new_ldap_instance(isc_mem_t *mctx, const char *db_name, > const char * const *argv, dns_dyndb_arguments_t *dyndb_args, > isc_task_t *task, ldap_instance_t **ldap_instp) > { > - unsigned int i; > isc_result_t result; > ldap_instance_t *ldap_inst; > dns_view_t *view = NULL; > - ld_string_t *auth_method_str = NULL; > dns_forwarders_t *orig_global_forwarders = NULL; > - isc_uint32_t cache_ttl_seconds; > - setting_t ldap_settings[] = { > - { "uri", no_default_string }, > - { "connections", default_uint(2) }, > - { "reconnect_interval", default_uint(60) }, > - { "timeout", default_uint(10) }, > - { "base", no_default_string }, > - { "auth_method", default_string("none") }, > - { "bind_dn", default_string("") }, > - { "password", default_string("") }, > - { "krb5_principal", default_string("") }, > - { "sasl_mech", default_string("GSSAPI") }, > - { "sasl_user", default_string("") }, > - { "sasl_auth_name", default_string("") }, > - { "sasl_realm", default_string("") }, > - { "sasl_password", default_string("") }, > - { "krb5_keytab", default_string("") }, > - { "fake_mname", default_string("") }, > - { "psearch", default_boolean(ISC_FALSE) }, > - { "cache_ttl", default_uint(120) }, > - { "ldap_hostname", default_string("") }, > - { "sync_ptr", default_boolean(ISC_FALSE) }, > - { "dyn_update", default_boolean(ISC_FALSE) }, > - { "serial_autoincrement", default_boolean(ISC_FALSE) }, > - end_of_settings > - }; > + isc_boolean_t psearch; > + isc_uint32_t connections; > + char settings_name[PRINT_BUFF_SIZE]; > > REQUIRE(ldap_instp != NULL && *ldap_instp == NULL); > > @@ -381,123 +496,35 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > dns_view_attach(view, &ldap_inst->view); > ldap_inst->zmgr = dns_dyndb_get_zonemgr(dyndb_args); > ISC_LIST_INIT(ldap_inst->orig_global_forwarders.addrs); > - > - CHECK(zr_create(mctx, &ldap_inst->zone_register)); > - > - CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > - > - CHECK(str_new(mctx, &auth_method_str)); > - CHECK(str_new(mctx, &ldap_inst->uri)); > - CHECK(str_new(mctx, &ldap_inst->base)); > - CHECK(str_new(mctx, &ldap_inst->bind_dn)); > - CHECK(str_new(mctx, &ldap_inst->password)); > - CHECK(str_new(mctx, &ldap_inst->krb5_principal)); > - CHECK(str_new(mctx, &ldap_inst->sasl_mech)); > - CHECK(str_new(mctx, &ldap_inst->sasl_user)); > - CHECK(str_new(mctx, &ldap_inst->sasl_auth_name)); > - CHECK(str_new(mctx, &ldap_inst->sasl_realm)); > - CHECK(str_new(mctx, &ldap_inst->sasl_password)); > - CHECK(str_new(mctx, &ldap_inst->krb5_keytab)); > - CHECK(str_new(mctx, &ldap_inst->fake_mname)); > - CHECK(str_new(mctx, &ldap_inst->ldap_hostname)); > - > - i = 0; > - ldap_settings[i++].target = ldap_inst->uri; > - ldap_settings[i++].target = &ldap_inst->connections; > - ldap_settings[i++].target = &ldap_inst->reconnect_interval; > - ldap_settings[i++].target = &ldap_inst->timeout; > - ldap_settings[i++].target = ldap_inst->base; > - ldap_settings[i++].target = auth_method_str; > - ldap_settings[i++].target = ldap_inst->bind_dn; > - ldap_settings[i++].target = ldap_inst->password; > - ldap_settings[i++].target = ldap_inst->krb5_principal; > - ldap_settings[i++].target = ldap_inst->sasl_mech; > - ldap_settings[i++].target = ldap_inst->sasl_user; > - ldap_settings[i++].target = ldap_inst->sasl_auth_name; > - ldap_settings[i++].target = ldap_inst->sasl_realm; > - ldap_settings[i++].target = ldap_inst->sasl_password; > - ldap_settings[i++].target = ldap_inst->krb5_keytab; > - ldap_settings[i++].target = ldap_inst->fake_mname; > - ldap_settings[i++].target = &ldap_inst->psearch; > - ldap_settings[i++].target = &cache_ttl_seconds; > - ldap_settings[i++].target = ldap_inst->ldap_hostname; > - ldap_settings[i++].target = &ldap_inst->sync_ptr; > - ldap_settings[i++].target = &ldap_inst->dyn_update; > - ldap_settings[i++].target = &ldap_inst->serial_autoincrement; > - CHECK(set_settings(ldap_settings, argv)); > - isc_interval_set(&ldap_inst->cache_ttl, cache_ttl_seconds, 0); > - > - /* Set timer for deadlock detection inside semaphore_wait_timed . */ > - if (semaphore_wait_timeout.seconds < ldap_inst->timeout*SEM_WAIT_TIMEOUT_MUL) > - semaphore_wait_timeout.seconds = ldap_inst->timeout*SEM_WAIT_TIMEOUT_MUL; > - > - /* Validate and check settings. */ > - str_toupper(ldap_inst->sasl_mech); > - if (ldap_inst->connections < 1) { > - log_error("at least one connection is required"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - /* Select authentication method. */ > - ldap_inst->auth_method = AUTH_INVALID; > - for (i = 0; supported_ldap_auth[i].name != NULL; i++) { > - if (!str_casecmp_char(auth_method_str, > - supported_ldap_auth[i].name)) { > - ldap_inst->auth_method = supported_ldap_auth[i].value; > - break; > - } > - } > - if (ldap_inst->auth_method == AUTH_INVALID) { > - log_error("unknown authentication method '%s'", > - str_buf(auth_method_str)); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - > - /* check we have the right data when SASL/GSSAPI is selected */ > - if ((ldap_inst->auth_method == AUTH_SASL) && > - (str_casecmp_char(ldap_inst->sasl_mech, "GSSAPI") == 0)) { > - if ((ldap_inst->krb5_principal == NULL) || > - (str_len(ldap_inst->krb5_principal) == 0)) { > - if ((ldap_inst->sasl_user == NULL) || > - (str_len(ldap_inst->sasl_user) == 0)) { > - char hostname[255]; > - if (gethostname(hostname, 255) != 0) { > - log_error("SASL mech GSSAPI defined but krb5_principal" > - "and sasl_user are empty. Could not get hostname"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } else { > - CHECK(str_sprintf(ldap_inst->krb5_principal, > - "DNS/%s", hostname)); > - log_debug(2, "SASL mech GSSAPI defined but krb5_principal" > - "and sasl_user are empty, using default %s", > - str_buf(ldap_inst->krb5_principal)); > - } > - } else { > - str_copy(ldap_inst->krb5_principal, ldap_inst->sasl_user); > - } > - } > - } > - > ldap_inst->task = task; > + ldap_inst->watcher = 0; > > - if (ldap_inst->psearch && ldap_inst->connections < 2) { > - /* watcher needs one and update_*() will request second */ > - log_error("psearch needs at least 2 connections, " > - "increasing limit"); > - ldap_inst->connections = 2; > - } > - if (ldap_inst->serial_autoincrement == ISC_TRUE > - && ldap_inst->psearch != ISC_TRUE) { > - log_error("SOA serial number auto-increment feature requires " > - "persistent search"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_LOCAL " for database %s", > + db_name); > + CHECK(settings_set_create(mctx, settings_local_default, > + sizeof(settings_local_default), settings_name, > + &settings_default_set, &ldap_inst->local_settings)); > > - CHECK(ldap_pool_create(mctx, ldap_inst->connections, &ldap_inst->pool)); > - CHECK(ldap_pool_connect(ldap_inst->pool, ldap_inst)); > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_GLOBAL " for database %s", > + db_name); > + CHECK(settings_set_create(mctx, settings_global_default, > + sizeof(settings_global_default), settings_name, > + ldap_inst->local_settings, &ldap_inst->global_settings)); > + > + CHECK(settings_set_fill(ldap_inst->local_settings, argv, task)); > + CHECK(validate_local_instance_settings(ldap_inst, ldap_inst->local_settings)); > + if (settings_set_isfilled(ldap_inst->global_settings) != ISC_TRUE) > + CLEANUP_WITH(ISC_R_FAILURE); > + > + CHECK(setting_get_bool("psearch", ldap_inst->local_settings, &psearch)); > + CHECK(setting_get_uint("connections", ldap_inst->local_settings, &connections)); > + > + CHECK(zr_create(mctx, ldap_inst->global_settings, > + &ldap_inst->zone_register)); > + > + CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > > /* copy global forwarders setting for configuration roll back in > * configure_zone_forwarders() */ > @@ -521,12 +548,14 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > } else if (result == ISC_R_NOTFOUND) { > /* global forwarders are not configured */ > ldap_inst->orig_global_forwarders.fwdpolicy = dns_fwdpolicy_none; > - result = ISC_R_SUCCESS; > } else { > goto cleanup; > } > > - if (ldap_inst->psearch) { > + CHECK(ldap_pool_create(mctx, connections, &ldap_inst->pool)); > + CHECK(ldap_pool_connect(ldap_inst->pool, ldap_inst)); > + > + if (psearch) { > /* Start the watcher thread */ > result = isc_thread_create(ldap_psearch_watcher, ldap_inst, > &ldap_inst->watcher); > @@ -542,10 +571,9 @@ cleanup: > else > *ldap_instp = ldap_inst; > > - str_destroy(&auth_method_str); > - > return result; > } > +#undef PRINT_BUFF_SIZE > > void > destroy_ldap_instance(ldap_instance_t **ldap_instp) > @@ -627,7 +655,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > dns_rbtnodechain_invalidate(&chain); > > /* TODO: Terminate psearch watcher sooner? */ > - if (ldap_inst->psearch && ldap_inst->watcher != 0) { > + if (ldap_inst->watcher != 0) { > ldap_inst->exiting = ISC_TRUE; > /* > * Wake up the watcher thread. This might look like a hack > @@ -644,21 +672,6 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > } > > ldap_pool_destroy(&ldap_inst->pool); > - > - str_destroy(&ldap_inst->uri); > - str_destroy(&ldap_inst->base); > - str_destroy(&ldap_inst->bind_dn); > - str_destroy(&ldap_inst->password); > - str_destroy(&ldap_inst->krb5_principal); > - str_destroy(&ldap_inst->sasl_mech); > - str_destroy(&ldap_inst->sasl_user); > - str_destroy(&ldap_inst->sasl_auth_name); > - str_destroy(&ldap_inst->sasl_realm); > - str_destroy(&ldap_inst->sasl_password); > - str_destroy(&ldap_inst->krb5_keytab); > - str_destroy(&ldap_inst->fake_mname); > - str_destroy(&ldap_inst->ldap_hostname); > - > dns_view_detach(&ldap_inst->view); > > DESTROYLOCK(&ldap_inst->kinit_lock); > @@ -671,6 +684,9 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > SAFE_MEM_PUT_PTR(ldap_inst->mctx, addr); > } > > + settings_set_free(&ldap_inst->global_settings); > + settings_set_free(&ldap_inst->local_settings); > + > MEM_PUT_AND_DETACH(ldap_inst); > > *ldap_instp = NULL; > @@ -1152,64 +1168,62 @@ static isc_result_t > ldap_parse_configentry(ldap_entry_t *entry, ldap_instance_t *inst) > { > isc_result_t result; > - ldap_valuelist_t values; > - isc_boolean_t sync_ptr_new; > isc_timer_t *timer_inst; > isc_interval_t timer_interval; > isc_uint32_t interval_sec; > isc_timertype_t timer_type; > > - /* BIND functions are thread safe, lock only ldap instance 'inst'. */ > + /* BIND functions are thread safe, ldap instance 'inst' is locked > + * inside setting* functions. */ > > log_debug(3, "Parsing configuration object"); > > /* idnsForwardPolicy change is handled by configure_zone_forwarders() */ > result = configure_zone_forwarders(entry, inst, dns_rootname); > if (result != ISC_R_SUCCESS && result != ISC_R_DISABLED) { > log_error_r("global forwarder could not be set up"); > } > > - result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > - if (result == ISC_R_SUCCESS) { > - log_debug(2, "Setting global AllowSyncPTR = %s", HEAD(values)->value); > - sync_ptr_new = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > + result = setting_update_from_ldap_entry("dyn_update", > + inst->global_settings, > + "idnsAllowDynUpdate", > + entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > > - if (inst->sync_ptr != sync_ptr_new) { /* lock BIND only if necessary */ > - result = isc_task_beginexclusive(inst->task); > - RUNTIME_CHECK(result == ISC_R_SUCCESS || > - result == ISC_R_LOCKBUSY); > - inst->sync_ptr = sync_ptr_new; > - if (result == ISC_R_SUCCESS) { > - isc_task_endexclusive(inst->task); > - } > - } > - } > + result = setting_update_from_ldap_entry("sync_ptr", > + inst->global_settings, > + "idnsAllowSyncPTR", > + entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > > - result = ldap_entry_getvalues(entry, "idnsZoneRefresh", &values); > + result = setting_update_from_ldap_entry("zone_refresh", > + inst->global_settings, > + "idnsZoneRefresh", > + entry, inst->task); > if (result == ISC_R_SUCCESS) { > - log_debug(2, "Setting global ZoneRefresh timer = %s", HEAD(values)->value); > - RUNTIME_CHECK(manager_get_db_timer(inst->db_name, &timer_inst) == ISC_R_SUCCESS); > - > - result = isc_parse_uint32(&interval_sec, HEAD(values)->value, 10); > - if (result != ISC_R_SUCCESS) { > - log_error("Could not parse ZoneRefresh interval"); > - goto cleanup; > - } > + RUNTIME_CHECK(manager_get_db_timer(inst->db_name, &timer_inst) > + == ISC_R_SUCCESS); > + CHECK(setting_get_uint("zone_refresh", inst->global_settings, > + &interval_sec)); > isc_interval_set(&timer_interval, interval_sec, 0); > /* update interval only, not timer type */ > timer_type = isc_timer_gettype(timer_inst); > result = isc_timer_reset(timer_inst, timer_type, NULL, > &timer_interval, ISC_TRUE); > if (result != ISC_R_SUCCESS) { > - log_error("Could not adjust ZoneRefresh timer"); > + log_error_r("could not adjust ZoneRefresh timer"); > goto cleanup; > } > + } else if (result != ISC_R_IGNORE) { > + goto cleanup; > } > > cleanup: > /* Configuration errors are not fatal. */ > - return ISC_R_SUCCESS; > + /* TODO: log something? */ > + return ISC_R_SUCCESS; > } > > /* Parse the zone entry */ > @@ -1232,6 +1246,8 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > ldapdb_rdatalist_t rdatalist; > isc_boolean_t zone_dynamic = ISC_FALSE; > ldap_cache_t *cache = NULL; > + settings_set_t *zone_settings = NULL; > + isc_boolean_t serial_autoincrement; > > REQUIRE(entry != NULL); > REQUIRE(inst != NULL); > @@ -1278,13 +1294,24 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > result = zr_get_zone_ptr(inst->zone_register, &name, &zone); > if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > CHECK(create_zone(inst, &name, &zone)); > - CHECK(zr_add_zone(inst->zone_register, zone, dn, > - &inst->cache_ttl, &inst->psearch)); > + CHECK(zr_add_zone(inst->zone_register, zone, dn)); > publish = ISC_TRUE; > log_debug(2, "created zone %p: %s", zone, dn); > } else if (result != ISC_R_SUCCESS) > goto cleanup; > > + CHECK(zr_get_zone_settings(inst->zone_register, &name, &zone_settings)); > + > + result = setting_update_from_ldap_entry("dyn_update", zone_settings, > + "idnsAllowDynUpdate", entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > + > + result = setting_update_from_ldap_entry("sync_ptr", zone_settings, > + "idnsAllowSyncPTR", entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > + > log_debug(2, "Setting SSU table for %p: %s", zone, dn); > /* Get the update policy and update the zone with it. */ > result = ldap_entry_getvalues(entry, "idnsUpdatePolicy", &values); > @@ -1367,7 +1394,9 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > CHECK(ldap_get_zone_serial(inst, &name, &ldap_serial)); > CHECK(zr_get_zone_serial_digest(inst->zone_register, &name, &zr_serial, > &zr_digest)); > - if (inst->serial_autoincrement) { > + CHECK(setting_get_bool("serial_autoincrement", zone_settings, > + &serial_autoincrement)); > + if (serial_autoincrement) { > CHECK(ldapdb_rdatalist_get(inst->mctx, inst, &name, > &name, &rdatalist)); > CHECK(rdatalist_digest(inst->mctx, &rdatalist, ldap_digest)); > @@ -1429,34 +1458,39 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > ldap_entry_t *entry; > dns_rbt_t *rbt = NULL; > isc_boolean_t invalidate_nodechain = ISC_FALSE; > + isc_boolean_t psearch; > + const char *base = NULL; > char *config_attrs[] = { > "idnsForwardPolicy", "idnsForwarders", > "idnsAllowSyncPTR", "idnsZoneRefresh", > "idnsPersistentSearch", NULL > }; > char *zone_attrs[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > - "idnsAllowTransfer", "idnsForwardPolicy", > - "idnsForwarders", NULL > + "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > }; > > REQUIRE(ldap_inst != NULL); > > - if (ldap_inst->psearch && !delete_only) { > + CHECK(setting_get_bool("psearch", ldap_inst->global_settings, > + &psearch)); > + if (psearch && !delete_only) { > /* Watcher does the work for us, but deletion is allowed. */ > return ISC_R_SUCCESS; > } > > log_debug(2, "refreshing list of zones for %s", ldap_inst->db_name); > > /* Query for configuration and zones from LDAP and release LDAP connection > * before processing them. It prevents deadlock in situations where > * ldap_parse_zoneentry() requests another connection. */ > + CHECK(setting_get_str("base", ldap_inst->global_settings, &base)); > CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, str_buf(ldap_inst->base), > + CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, base, > LDAP_SCOPE_SUBTREE, config_attrs, 0, > "(objectClass=idnsConfigObject)")); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, str_buf(ldap_inst->base), > + CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, base, > LDAP_SCOPE_SUBTREE, zone_attrs, 0, > "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > @@ -1684,7 +1718,7 @@ free_rdatalist(isc_mem_t *mctx, dns_rdatalist_t *rdlist) > static isc_result_t > ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > ldap_qresult_t *qresult, dns_name_t *origin, > - const ld_string_t *fake_mname, ld_string_t *buf, > + const char *fake_mname, ld_string_t *buf, > ldapdb_rdatalist_t *rdatalist) > { > isc_result_t result; > @@ -1741,6 +1775,7 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > ld_string_t *string = NULL; > ldapdb_node_t *node; > dns_name_t node_name; > + const char *fake_mname = NULL; > > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > @@ -1759,6 +1794,8 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > goto cleanup; > } > > + CHECK(setting_get_str("fake_mname", ldap_inst->local_settings, > + &fake_mname)); > for (entry = HEAD(ldap_qresult->ldap_entries); > entry != NULL; > entry = NEXT(entry, link)) { > @@ -1773,7 +1810,7 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > dns_name_free(&node_name, mctx); > if (result == ISC_R_SUCCESS) { > result = ldap_parse_rrentry(mctx, entry, ldap_qresult, > - origin, ldap_inst->fake_mname, > + origin, fake_mname, > string, &node->rdatalist); > } > if (result != ISC_R_SUCCESS) { > @@ -1805,6 +1842,7 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > ldap_entry_t *entry; > ld_string_t *string = NULL; > ldap_cache_t *cache = NULL; > + const char *fake_mname = NULL; > > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > @@ -1831,11 +1869,13 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > goto cleanup; > } > > + CHECK(setting_get_str("fake_mname", ldap_inst->local_settings, > + &fake_mname)); > for (entry = HEAD(ldap_qresult->ldap_entries); > entry != NULL; > entry = NEXT(entry, link)) { > CHECK(ldap_parse_rrentry(mctx, entry, ldap_qresult, > - origin, ldap_inst->fake_mname, > + origin, fake_mname, > string, rdatalist)); > } > > @@ -1859,7 +1899,7 @@ cleanup: > static isc_result_t > add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult, dns_name_t *origin, > ldap_entry_t *entry, ldapdb_rdatalist_t *rdatalist, > - const ld_string_t *fake_mname) > + const char *fake_mname) > { > isc_result_t result; > ld_string_t *string = NULL; > @@ -2117,6 +2157,7 @@ ldap_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *sin) > sasl_interact_t *in; > ldap_instance_t *ldap_inst = defaults; > int ret = LDAP_OTHER; > + isc_result_t result; > > REQUIRE(ldap_inst != NULL); > UNUSED(flags); > @@ -2129,36 +2170,47 @@ ldap_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *sin) > switch (in->id) { > case SASL_CB_USER: > log_debug(4, "got request for SASL_CB_USER"); > - in->result = str_buf(ldap_inst->sasl_user); > - in->len = str_len(ldap_inst->sasl_user); > + CHECK(setting_get_str("sasl_user", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_GETREALM: > log_debug(4, "got request for SASL_CB_GETREALM"); > - in->result = str_buf(ldap_inst->sasl_realm); > - in->len = str_len(ldap_inst->sasl_realm); > + CHECK(setting_get_str("sasl_realm", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_AUTHNAME: > log_debug(4, "got request for SASL_CB_AUTHNAME"); > - in->result = str_buf(ldap_inst->sasl_auth_name); > - in->len = str_len(ldap_inst->sasl_auth_name); > + CHECK(setting_get_str("sasl_auth_name", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_PASS: > log_debug(4, "got request for SASL_CB_PASS"); > - in->result = str_buf(ldap_inst->sasl_password); > - in->len = str_len(ldap_inst->sasl_password); > + CHECK(setting_get_str("sasl_password", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > default: > - in->result = NULL; > - in->len = 0; > - ret = LDAP_OTHER; > + goto cleanup; > } > } > > return ret; > + > +cleanup: > + in->result = NULL; > + in->len = 0; > + return LDAP_OTHER; > } > > /* > @@ -2169,16 +2221,20 @@ static isc_result_t > ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > isc_boolean_t force) > { > - LDAP *ld; > + LDAP *ld = NULL; > int ret; > int version; > struct timeval timeout; > isc_result_t result = ISC_R_FAILURE; > + const char *uri = NULL; > + const char *ldap_hostname = NULL; > + isc_uint32_t timeout_sec; > > REQUIRE(ldap_inst != NULL); > REQUIRE(ldap_conn != NULL); > > - ret = ldap_initialize(&ld, str_buf(ldap_inst->uri)); > + CHECK(setting_get_str("uri", ldap_inst->local_settings, &uri)); > + ret = ldap_initialize(&ld, uri); > if (ret != LDAP_SUCCESS) { > log_error("LDAP initialization failed: %s", > ldap_err2string(ret)); > @@ -2189,15 +2245,18 @@ ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > ret = ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); > LDAP_OPT_CHECK(ret, "failed to set LDAP version"); > > - timeout.tv_sec = ldap_inst->timeout; > + CHECK(setting_get_uint("timeout", ldap_inst->global_settings, > + &timeout_sec)); > + timeout.tv_sec = timeout_sec; > timeout.tv_usec = 0; > > ret = ldap_set_option(ld, LDAP_OPT_TIMEOUT, &timeout); > LDAP_OPT_CHECK(ret, "failed to set timeout"); > > - if (str_len(ldap_inst->ldap_hostname) > 0) { > - ret = ldap_set_option(ld, LDAP_OPT_HOST_NAME, > - str_buf(ldap_inst->ldap_hostname)); > + CHECK(setting_get_str("ldap_hostname", ldap_inst->local_settings, > + &ldap_hostname)); > + if (strlen(ldap_hostname) > 0) { > + ret = ldap_set_option(ld, LDAP_OPT_HOST_NAME, ldap_hostname); > LDAP_OPT_CHECK(ret, "failed to set LDAP_OPT_HOST_NAME"); > } > > @@ -2226,9 +2285,16 @@ static isc_result_t > ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > isc_boolean_t force) > { > + isc_result_t result; > int ret = 0; > const char *bind_dn = NULL; > const char *password = NULL; > + const char *uri = NULL; > + const char *sasl_mech = NULL; > + const char *krb5_principal = NULL; > + const char *krb5_keytab = NULL; > + ldap_auth_t auth_method_enum = AUTH_INVALID; > + isc_uint32_t reconnect_interval; > > if (force) > goto force_reconnect; > @@ -2246,9 +2312,11 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > > /* If either bind_dn or the password is not set, we will use > * password-less bind. */ > - if (str_len(ldap_inst->bind_dn) > 0 && str_len(ldap_inst->password) > 0) { > - bind_dn = str_buf(ldap_inst->bind_dn); > - password = str_buf(ldap_inst->password); > + CHECK(setting_get_str("bind_dn", ldap_inst->global_settings, &bind_dn)); > + CHECK(setting_get_str("password", ldap_inst->global_settings, &password)); > + if (strlen(bind_dn) == 0 || strlen(password) == 0) { > + bind_dn = NULL; > + password = NULL; > } > > /* Set the next possible reconnect time. */ > @@ -2260,39 +2328,52 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > const size_t ntimes = sizeof(intervals) / sizeof(intervals[0]); > > i = ISC_MIN(ntimes - 1, ldap_conn->tries); > - seconds = ISC_MIN(intervals[i], ldap_inst->reconnect_interval); > + CHECK(setting_get_uint("reconnect_interval", > + ldap_inst->global_settings, > + &reconnect_interval)); > + seconds = ISC_MIN(intervals[i], reconnect_interval); > isc_interval_set(&delay, seconds, 0); > isc_time_nowplusinterval(&ldap_conn->next_reconnect, &delay); > } > > ldap_conn->tries++; > force_reconnect: > - log_debug(2, "trying to establish LDAP connection to %s", > - str_buf(ldap_inst->uri)); > + CHECK(setting_get_str("uri", ldap_inst->local_settings, &uri)); > + log_debug(2, "trying to establish LDAP connection to %s", uri); > > - switch (ldap_inst->auth_method) { > + CHECK(setting_get_uint("auth_method_enum", ldap_inst->local_settings, > + &auth_method_enum)); > + switch (auth_method_enum) { > case AUTH_NONE: > ret = ldap_simple_bind_s(ldap_conn->handle, NULL, NULL); > break; > case AUTH_SIMPLE: > ret = ldap_simple_bind_s(ldap_conn->handle, bind_dn, password); > break; > case AUTH_SASL: > - if (strcmp(str_buf(ldap_inst->sasl_mech), "GSSAPI") == 0) { > + CHECK(setting_get_str("sasl_mech", ldap_inst->local_settings, > + &sasl_mech)); > + if (strcmp(sasl_mech, "GSSAPI") == 0) { > isc_result_t result; > + CHECK(setting_get_str("krb5_principal", > + ldap_inst->local_settings, > + &krb5_principal)); > + CHECK(setting_get_str("krb5_keytab", > + ldap_inst->local_settings, > + &krb5_keytab)); > LOCK(&ldap_inst->kinit_lock); > result = get_krb5_tgt(ldap_inst->mctx, > - str_buf(ldap_inst->krb5_principal), > - str_buf(ldap_inst->krb5_keytab)); > + krb5_principal, > + krb5_keytab); > UNLOCK(&ldap_inst->kinit_lock); > if (result != ISC_R_SUCCESS) > return result; > } > > - log_debug(4, "trying interactive bind using %s mechanism", > - str_buf(ldap_inst->sasl_mech)); > + log_debug(4, "trying interactive bind using '%s' mechanism", > + sasl_mech); > ret = ldap_sasl_interactive_bind_s(ldap_conn->handle, NULL, > - str_buf(ldap_inst->sasl_mech), > + sasl_mech, > NULL, NULL, LDAP_SASL_QUIET, > ldap_sasl_interact, > ldap_inst); > @@ -2331,6 +2412,9 @@ force_reconnect: > ldap_conn->tries = 0; > > return ISC_R_SUCCESS; > + > +cleanup: > + return result; > } > > static isc_result_t > @@ -2699,70 +2783,66 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_result_t result; > isc_mem_t *mctx = ldap_inst->mctx; > ldap_connection_t *ldap_conn = NULL; > - ldap_qresult_t *ldap_qresult = NULL; > ld_string_t *owner_dn = NULL; > LDAPMod *change[3] = { NULL }; > LDAPMod *change_ptr = NULL; > ldap_cache_t *cache = NULL; > - ldap_entry_t *entry; > - ldap_valuelist_t values; > - isc_boolean_t zone_dyn_update = ldap_inst->dyn_update; > - isc_boolean_t zone_sync_ptr = ldap_inst->sync_ptr; > + isc_boolean_t zone_dyn_update; > + isc_boolean_t zone_sync_ptr; > ld_string_t *owner_dn_ptr = NULL; > - char *attrs[] = {"idnsAllowSyncPTR", "idnsAllowDynUpdate", NULL}; > ld_string_t *str_ptr = NULL; > ldapdb_rdatalist_t rdlist_search; > dns_rdatalist_t *rdlist_ptr = NULL; > char **vals = NULL; > + dns_name_t zone_name; > + struct dns_fixedname ptr_name; > + char *zone_dn = NULL; > + settings_set_t *zone_settings = NULL; > > /* > * Find parent zone entry and check if Dynamic Update is allowed. > * @todo Try the cache first and improve split: SOA records are problematic. > */ > ISC_LIST_INIT(rdlist_search); > + dns_name_init(&zone_name, NULL); > + dns_fixedname_init(&ptr_name); > CHECK(str_new(mctx, &owner_dn)); > + > CHECK(dnsname_to_dn(ldap_inst->zone_register, owner, owner_dn)); > - char *zone_dn = strstr(str_buf(owner_dn),", "); > + zone_dn = strstr(str_buf(owner_dn),", "); > > if (zone_dn == NULL) { /* SOA record; owner = zone => owner_dn = zone_dn */ > zone_dn = (char *)str_buf(owner_dn); > } else { > zone_dn += 1; /* skip whitespace */ > } > > - CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_qresult, zone_dn, > - LDAP_SCOPE_BASE, attrs, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + CHECK(dn_to_dnsname(mctx, zone_dn, &zone_name, NULL)); > > - /* only 0 or 1 active zone can be returned from query */ > - entry = HEAD(ldap_qresult->ldap_entries); > - if (entry == NULL) { > - log_debug(3, "Active zone %s not found", zone_dn); > - result = DNS_R_NOTAUTH; > - goto cleanup; > - } > - > - result = ldap_entry_getvalues(entry, "idnsAllowDynUpdate", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_dyn_update = (strcmp(HEAD(values)->value, "TRUE") == 0 ) > - ? ISC_TRUE : ISC_FALSE; > + result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > + &zone_settings); > + if (result != ISC_R_SUCCESS) { > + if (result == ISC_R_NOTFOUND) > + log_debug(3, "active zone '%s' not found", zone_dn); > + CLEANUP_WITH(DNS_R_NOTAUTH); > } > > + CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); > if (!zone_dyn_update) { > - log_debug(3, "Dynamic Update is not allowed in zone %s", zone_dn); > - result = DNS_R_REFUSED; > - goto cleanup; > + log_debug(3, "dynamic update is not allowed in zone '%s'", > + zone_dn); > + CLEANUP_WITH(DNS_R_REFUSED); > } > > - if (rdlist->type == dns_rdatatype_soa && mod_op == LDAP_MOD_DELETE) { > - result = ISC_R_SUCCESS; > - goto cleanup; > - } > + if (rdlist->type == dns_rdatatype_soa && mod_op == LDAP_MOD_DELETE) > + CLEANUP_WITH(ISC_R_SUCCESS); > + > /* Flush modified record from the cache */ > CHECK(zr_get_zone_cache(ldap_inst->zone_register, owner, &cache)); > CHECK(discard_from_cache(cache, owner)); > > + CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > + > if (rdlist->type == dns_rdatatype_soa) { > result = modify_soa_record(ldap_inst, ldap_conn, str_buf(owner_dn), > HEAD(rdlist->rdata)); > @@ -2784,18 +2864,12 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * use global plugin configuration: option "sync_ptr" > */ > > - result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_sync_ptr = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > - } > - > + CHECK(setting_get_bool("sync_ptr", zone_settings, &zone_sync_ptr)); > if (!zone_sync_ptr) { > - log_debug(3, "Sync PTR is not allowed in zone %s", zone_dn); > - result = ISC_R_SUCCESS; > - goto cleanup; > + log_debug(3, "sync PTR is not allowed in zone '%s'", zone_dn); > + CLEANUP_WITH(ISC_R_SUCCESS); > } > - log_debug(3, "Sync PTR is allowed for zone %s", zone_dn); > + log_debug(3, "sync PTR is allowed for zone '%s'", zone_dn); > > /* Get string with IP address from change request > * and convert it to in_addr structure. */ > @@ -2819,26 +2893,22 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * 192.168.0.1 -> 1.0.168.192.in-addr.arpa > * > * @todo Check if it works for IPv6 correctly. > - */ > - struct dns_fixedname name; > - dns_fixedname_init(&name); > - CHECK(dns_byaddr_createptrname2(&isc_ip, 0, dns_fixedname_name(&name))); > + */ > + CHECK(dns_byaddr_createptrname2(&isc_ip, 0, dns_fixedname_name(&ptr_name))); > > /* Find PTR entry in LDAP. */ > - result = ldapdb_rdatalist_get(mctx, ldap_inst, dns_fixedname_name(&name), > + result = ldapdb_rdatalist_get(mctx, ldap_inst, dns_fixedname_name(&ptr_name), > NULL, &rdlist_search); > > /* Check the value of PTR entry. */ > if (mod_op == LDAP_MOD_DELETE && result == ISC_R_SUCCESS) { > result = ldapdb_rdatalist_findrdatatype(&rdlist_search, > dns_rdatatype_ptr, &rdlist_ptr); > } > > if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) { > - log_error("Can not synchronize PTR record, ldapdb_rdatalist_get = %d", > - result); > - result = ISC_R_FAILURE; /* Synchronization required: report error. */ > - goto cleanup; > + log_error_r("can not synchronize PTR record, ldapdb_rdatalist_get"); > + CLEANUP_WITH(ISC_R_FAILURE); /* Synchronization required: report error. */ > } > > /* > @@ -2854,46 +2924,38 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > } > > /* Get LDAP entry indentifier. */ > - CHECK(str_new(mctx, &owner_dn_ptr)); > - CHECK(dnsname_to_dn(ldap_inst->zone_register, dns_fixedname_name(&name), > - owner_dn_ptr)); > + CHECK(str_new(mctx, &owner_dn_ptr)); > + CHECK(dnsname_to_dn(ldap_inst->zone_register, dns_fixedname_name(&ptr_name), > + owner_dn_ptr)); > > /* > * @example > * owner_dn_ptr = "idnsName=100.0.168, idnsname=192.in-addr.arpa,cn=dns,$SUFFIX" > * owner_zone_dn_ptr = "idnsname=192.in-addr.arpa,cn=dns,$SUFFIX" > */ > char *owner_zone_dn_ptr = strstr(str_buf(owner_dn_ptr),", ") + 1; > > /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ > - ldap_query_free(ISC_FALSE, &ldap_qresult); > - zone_dyn_update = ldap_inst->dyn_update; > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_qresult, owner_zone_dn_ptr, > - LDAP_SCOPE_BASE, attrs, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + dns_name_free(&zone_name, mctx); > + dns_name_init(&zone_name, NULL); > + CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); > > - /* Only 0 or 1 active zone can be returned from query. */ > - entry = HEAD(ldap_qresult->ldap_entries); > - if (entry == NULL) { > - log_debug(3, "Active zone %s not found", zone_dn); > - result = ISC_R_NOTFOUND; > + zone_settings = NULL; > + result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > + &zone_settings); > + if (result != ISC_R_SUCCESS) { > + if (result == ISC_R_NOTFOUND) > + log_debug(3, "active zone '%s' not found", zone_dn); > goto cleanup; > } > > - result = ldap_entry_getvalues(entry, "idnsAllowDynUpdate", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_dyn_update = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > - } > - > + CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); > if (!zone_dyn_update) { > - log_debug(3, "Dynamic Update is not allowed in zone %s", owner_zone_dn_ptr); > - result = ISC_R_NOPERM; > - goto cleanup; > + log_debug(3, "dynamic update is not allowed in zone " > + "'%s'", zone_dn); > + CLEANUP_WITH(ISC_R_NOPERM); > } > > - log_debug(3, "Dynamic Update is allowed for zone %s", owner_zone_dn_ptr); > - > /* > * Get string representation of PTR record value. > * > @@ -2951,24 +3013,25 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > change_ptr = NULL; > > /* Modify PTR record. */ > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), change, delete_node)); > + CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), > + change, delete_node)); > cache = NULL; > CHECK(zr_get_zone_cache(ldap_inst->zone_register, > - dns_fixedname_name(&name), &cache)); > - CHECK(discard_from_cache(cache, dns_fixedname_name(&name))); > + dns_fixedname_name(&ptr_name), &cache)); > + CHECK(discard_from_cache(cache, dns_fixedname_name(&ptr_name))); > } > > cleanup: > - ldap_query_free(ISC_FALSE, &ldap_qresult); > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > str_destroy(&owner_dn_ptr); > str_destroy(&owner_dn); > str_destroy(&str_ptr); > free_ldapmod(mctx, &change[0]); > free_ldapmod(mctx, &change[1]); > if (change_ptr != NULL) free_ldapmod(mctx, &change_ptr); > ldapdb_rdatalist_destroy(mctx, &rdlist_search); > free_char_array(mctx, &vals); > + dns_name_free(&zone_name, mctx); > > return result; > } > @@ -3275,7 +3338,8 @@ update_zone(isc_task_t *task, isc_event_t *event) > dns_name_t prevname; > char *attrs_zone[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > - "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", NULL > + "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > }; > char *attrs_record[] = { > "objectClass", "dn", NULL > @@ -3412,6 +3476,7 @@ update_record(isc_task_t *task, isc_event_t *event) > isc_result_t result; > ldap_instance_t *inst = NULL; > ldap_cache_t *cache = NULL; > + isc_boolean_t serial_autoincrement; > isc_mem_t *mctx; > mctx = pevent->mctx; > > @@ -3422,6 +3487,7 @@ update_record(isc_task_t *task, isc_event_t *event) > ldapdb_rdatalist_t rdatalist; > > /* Convert domain name from text to struct dns_name_t. */ > + settings_set_t *zone_settings = NULL; > dns_name_t name; > dns_name_t origin; > dns_name_t prevname; > @@ -3483,8 +3549,12 @@ update_record(isc_task_t *task, isc_event_t *event) > } > > /* Do not bump serial during initial database dump. */ > - if (inst->serial_autoincrement && PSEARCH_ANY(pevent->chgtype)) { > - CHECK(soa_serial_increment(mctx, inst, &origin)); > + if (PSEARCH_ANY(pevent->chgtype)) { > + CHECK(zr_get_zone_settings(inst->zone_register, &origin, &zone_settings)); > + CHECK(setting_get_bool("serial_autoincrement", zone_settings, > + &serial_autoincrement)); > + if (serial_autoincrement) > + CHECK(soa_serial_increment(mctx, inst, &origin)); > } > cleanup: > if (result != ISC_R_SUCCESS) > @@ -3731,6 +3801,9 @@ ldap_psearch_watcher(isc_threadarg_t arg) > isc_result_t result; > sigset_t sigset; > isc_boolean_t flush_required; > + isc_boolean_t psearch; > + isc_uint32_t reconnect_interval; > + const char *base = NULL; > > log_debug(1, "Entering ldap_psearch_watcher"); > > @@ -3758,10 +3831,12 @@ ldap_psearch_watcher(isc_threadarg_t arg) > /* Try to connect. */ > while (conn->handle == NULL) { > CHECK_EXIT; > + CHECK(setting_get_uint("reconnect_interval", inst->global_settings, > + &reconnect_interval)); > > log_error("ldap_psearch_watcher handle is NULL. " > - "Next try in %ds", inst->reconnect_interval); > - if (!sane_sleep(inst, inst->reconnect_interval)) > + "Next try in %ds", reconnect_interval); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > handle_connection_error(inst, conn, ISC_TRUE); > } > @@ -3772,10 +3847,12 @@ restart: > /* Perform initial lookup */ > ldap_query_free(ISC_TRUE, &ldap_qresult); > flush_required = ISC_TRUE; > - if (inst->psearch) { > + CHECK(setting_get_str("base", inst->global_settings, &base)); > + CHECK(setting_get_bool("psearch", inst->global_settings, &psearch)); > + if (psearch) { > log_debug(1, "Sending initial psearch lookup"); > ret = ldap_search_ext(conn->handle, > - str_buf(inst->base), > + base, > LDAP_SCOPE_SUBTREE, > /* > * (objectClass==idnsZone AND idnsZoneActive==TRUE) > @@ -3802,10 +3879,14 @@ restart: > CHECK_EXIT; > while (handle_connection_error(inst, conn, ISC_TRUE) > != ISC_R_SUCCESS) { > - log_error("ldap_psearch_watcher failed to handle " > - "LDAP connection error. Reconnection " > - "in %ds", inst->reconnect_interval); > - if (!sane_sleep(inst, inst->reconnect_interval)) > + CHECK(setting_get_uint("reconnect_interval", > + inst->global_settings, > + &reconnect_interval)); > + log_error("ldap_psearch_watcher failed to " > + "handle LDAP connection error. " > + "Reconnection in %ds", > + reconnect_interval); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > } > goto restart; > @@ -3826,7 +3907,10 @@ restart: > } > > if (restart_needed) { > - if (!sane_sleep(inst, inst->reconnect_interval)) > + CHECK(setting_get_uint("reconnect_interval", > + inst->global_settings, > + &reconnect_interval)); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > > goto restart; > @@ -3894,3 +3978,8 @@ cleanup: > return (isc_threadresult_t)0; > } > > +settings_set_t * > +ldap_instance_getsettings_local(ldap_instance_t *ldap_inst) > +{ > + return ldap_inst->local_settings; > +} > diff --git a/src/ldap_helper.h b/src/ldap_helper.h > index a1e52f044d5e81ace7fb2d3c2ab082ad838944d1..86c3d4ec040a073df8c89d67b93cbd9e1b3bfb77 100644 > --- a/src/ldap_helper.h > +++ b/src/ldap_helper.h > @@ -90,4 +90,9 @@ isc_result_t write_to_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_result_t remove_from_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > dns_rdatalist_t *rdlist, isc_boolean_t delete_node); > > +/* Get cache associated with ldap_inst */ > +ldap_cache_t *ldap_instance_getcache(ldap_instance_t *ldap_inst); > + > +settings_set_t * ldap_instance_getsettings_local(ldap_instance_t *ldap_inst); > + > #endif /* !_LD_LDAP_HELPER_H_ */ > diff --git a/src/settings.c b/src/settings.c > dissimilarity index 60% > index 08164766172f5f915584ae51b43e3d64798eed71..0e37fc60c50d950c6f68652aafe819b3e2553864 100644 > --- a/src/settings.c > +++ b/src/settings.c > @@ -1,217 +1,626 @@ > -/* > - * Authors: Martin Nagy > - * > - * Copyright (C) 2009 Red Hat > - * see file 'COPYING' for use and warranty information > - * > - * 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; version 2 or later > - * > - * 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, write to the Free Software > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > - */ > - > -#include > -#include > -#include > - > -#include > -#include > -#include > - > -#include "log.h" > -#include "settings.h" > -#include "str.h" > -#include "util.h" > -#include "types.h" > - > -isc_boolean_t verbose_checks = ISC_FALSE; /* log each failure in CHECK() macro */ > - > -/* > - * Forward declarations. > - */ > -static int args_are_equal(const char *setting_argument, > - const char *argv_argument); > -static isc_result_t set_value(setting_t *setting, const char *value); > -static isc_result_t set_default_value(setting_t *setting); > -static const char * get_value_str(const char *arg); > - > -isc_result_t > -set_settings(setting_t settings[], const char * const* argv) > -{ > - isc_result_t result; > - int i, j; > - const char *value; > - > - for (i = 0; argv[i] != NULL; i++) { > - for (j = 0; settings[j].name != NULL; j++) { > - if (args_are_equal(settings[j].name, argv[i])) { > - value = get_value_str(argv[i]); > - CHECK(set_value(&settings[j], value)); > - break; > - } > - } > - } > - > - /* When all is done, check that all the required settings are set. */ > - for (j = 0; settings[j].name != NULL; j++) { > - if (settings[j].set != 0) > - continue; > - if (!settings[j].has_a_default) { > - log_error("argument %s must be set", settings[j].name); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - CHECK(set_default_value(&settings[j])); > - } > - > - return ISC_R_SUCCESS; > - > -cleanup: > - /* TODO: Free memory in case of error. */ > - return result; > -} > - > -/* > - * Return 1 if the argument names are equal. The argv_argument also needs to > - * contain an additional space at the end. > - */ > -static int > -args_are_equal(const char *setting_argument, const char *argv_argument) > -{ > - if (setting_argument == NULL || argv_argument == NULL) > - return 0; > - > - for (;;) { > - if (*setting_argument == '\0') > - break; > - if (*argv_argument == '\0') > - return 0; > - if (*setting_argument != *argv_argument) > - return 0; > - setting_argument++; > - argv_argument++; > - } > - > - /* Now make sure we also found a space at the end of argv_argument. */ > - if (!isspace(*argv_argument) && *argv_argument != '\0') > - return 0; > - > - return 1; > -} > - > -static isc_result_t > -set_value(setting_t *setting, const char *value) > -{ > - isc_result_t result; > - int numeric_value; > - > - switch (setting->type) { > - case ST_LD_STRING: > - CHECK(str_init_char((ld_string_t *)setting->target, value)); > - break; > - case ST_SIGNED_INTEGER: > - case ST_UNSIGNED_INTEGER: > - if (*value == '\0') { > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - /* TODO: better type checking. */ > - numeric_value = atoi(value); > - if (setting->type == ST_SIGNED_INTEGER) { > - (*(signed *)setting->target) = (signed)numeric_value; > - } else if (numeric_value < 0) { > - log_error("argument %s must be an unsigned integer", > - setting->name); > - result = ISC_R_FAILURE; > - goto cleanup; > - } else { > - (*(unsigned *)setting->target) = (unsigned)numeric_value; > - } > - break; > - case ST_BOOLEAN: > - if (strncasecmp(value, "yes", 3) == 0) > - (*(isc_boolean_t *)setting->target) = ISC_TRUE; > - else if (strncasecmp(value, "no", 2) == 0) > - (*(isc_boolean_t *)setting->target) = ISC_FALSE; > - else { > - log_error("unknown boolean expression (%s: %s)", > - setting->name, value); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - break; > - default: > - fatal_error("unknown type in function set_value()"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - > - setting->set = 1; > - > - return ISC_R_SUCCESS; > - > -cleanup: > - return result; > -} > - > -static isc_result_t > -set_default_value(setting_t *setting) > -{ > - switch (setting->type) { > - case ST_LD_STRING: > - return set_value(setting, setting->default_value.value_char); > - break; > - case ST_SIGNED_INTEGER: > - *(signed *)setting->target = setting->default_value.value_sint; > - break; > - case ST_UNSIGNED_INTEGER: > - *(unsigned *)setting->target = setting->default_value.value_uint; > - break; > - case ST_BOOLEAN: > - *(isc_boolean_t *)setting->target = > - setting->default_value.value_boolean; > - break; > - default: > - fatal_error("unknown type in function set_default_value()"); > - return ISC_R_FAILURE; > - } > - > - return ISC_R_SUCCESS; > -} > - > -static const char * > -get_value_str(const char *arg) > -{ > - while (*arg != '\0' && !isspace(*arg)) > - arg++; > - while (*arg != '\0' && isspace(*arg)) > - arg++; > - > - return arg; > -} > - > -isc_result_t > -get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc) { > - const enum_txt_assoc_t *record; > - > - REQUIRE(map != NULL); > - REQUIRE(desc != NULL && *desc == NULL); > - > - for (record = map; > - record->description != NULL && record->value != -1; > - record++) { > - if (record->value == value) { > - *desc = record->description; > - return ISC_R_SUCCESS; > - } > - } > - return ISC_R_NOTFOUND; > -} > +/* > + * Authors: Martin Nagy > + * > + * Copyright (C) 2009-2012 Red Hat > + * see file 'COPYING' for use and warranty information > + * > + * 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; version 2 or later > + * > + * 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, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#include "log.h" > +#include "settings.h" > +#include "str.h" > +#include "util.h" > +#include "types.h" > +#include "ldap_helper.h" > +#include "zone_register.h" > + > +isc_boolean_t verbose_checks = ISC_FALSE; /* log each failure in CHECK() macro */ > + > +/** Built-in defaults. */ > +static const setting_t settings_default[] = { > + { "uri", no_default_string }, /* User have to set this */ > + { "connections", default_uint(2) }, > + { "reconnect_interval", default_uint(60) }, > + { "zone_refresh", default_uint(0) }, > + { "timeout", default_uint(10) }, > + { "cache_ttl", default_uint(120) }, > + { "timeout", default_uint(10) }, > + { "base", no_default_string }, /* User have to set this */ > + { "auth_method", default_string("none") }, > + { "bind_dn", default_string("") }, > + { "password", default_string("") }, > + { "krb5_principal", default_string("") }, > + { "sasl_mech", default_string("GSSAPI") }, > + { "sasl_user", default_string("") }, > + { "sasl_auth_name", default_string("") }, > + { "sasl_realm", default_string("") }, > + { "sasl_password", default_string("") }, > + { "krb5_keytab", default_string("") }, > + { "fake_mname", default_string("") }, > + { "psearch", default_boolean(ISC_FALSE) }, > + { "ldap_hostname", default_string("") }, > + { "sync_ptr", default_boolean(ISC_FALSE) }, > + { "dyn_update", default_boolean(ISC_FALSE) }, > + { "serial_autoincrement", default_boolean(ISC_FALSE) }, > + { "verbose_checks", default_boolean(ISC_FALSE) }, > + end_of_settings > +}; > + > +/** Settings set for built-in defaults. */ > +const settings_set_t const settings_default_set = { > + NULL, > + "built-in defaults", > + NULL, > + (setting_t *) &settings_default[0] > +}; > + > +/** > + * @param[in] name Setting name. > + * @param[in] set Set of settings to start search in. > + * @param[in] recursive Continue with search in parent sets if setting was > + * not found in set passed by caller. > + * @param[in] filled_only Consider settings without value as non-existent. > + * @param[out] found Pointer to found setting_t. Ignored if found is NULL. > + * > + * @pre found == NULL || (found != NULL && *found == NULL) > + * > + * @retval ISC_R_SUCCESS > + * @retval ISC_R_NOTFOUND > + */ > +isc_result_t > +setting_find(const char *name, const settings_set_t *set, > + isc_boolean_t recursive, isc_boolean_t filled_only, > + setting_t **found) { > + > + REQUIRE(name != NULL); > + REQUIRE(found == NULL || *found == NULL); > + > + while (set != NULL) { > + log_debug(20, "examining set of settings '%s'", set->name); > + for (setting_t *setting = set->first_setting; > + setting->name; > + setting++) { > + > + if (strcmp(name, setting->name) == 0) { > + if (setting->filled || !filled_only) { > + if (found != NULL) > + *found = setting; > + log_debug(20, "setting '%s' was found " > + "in set '%s'", name, > + set->name); > + return ISC_R_SUCCESS; > + } else { > + break; /* continue with parent set */ > + } > + } > + > + } > + if (recursive) > + set = set->parent_set; > + else > + break; > + } > + return ISC_R_NOTFOUND; > +} > + > + > +/** > + * Get value associated with a setting. Search starts in set of settings > + * passed by caller and continues in parent sets until the setting with defined > + * value is found. > + * > + * @warning > + * This function is not expected to fail because all settings should > + * have default value defined (in topmost set of settings). > + * Caller should always check the return value, regardless this assumption. > + * > + * @param[out] target Type of pointer must agree with requested setting type. > + * @retval ISC_R_SUCCESS Required value was found and target was filled in. > + * @retval ISC_R_NOTFOUND Value is not defined in specified set of > + * settings either in parent sets. > + * @retval ISC_R_UNEXPECTED Type mismatch between _get_type() function and type > + * of setting in settings tree. (I.e. programming > + * error.) > + */ > +/* This hack enables type checking for setting_get_ functions. */ > +#define setting_getter(func_name, c_type, enum_type, value_name) \ > +isc_result_t \ > +setting_get_##func_name(const char * const name, \ > + const settings_set_t * const set, \ > + c_type target) \ > +{ \ > + isc_result_t result; \ > + setting_t *setting = NULL; \ > + \ > + REQUIRE(name != NULL); \ > + REQUIRE(target != NULL); \ > + \ > + CHECK(setting_find(name, set, ISC_TRUE, ISC_TRUE, &setting)); \ > + \ > + if (setting->type != enum_type) { \ > + log_bug("incompatible setting data type requested " \ > + "for name '%s' in set of settings '%s'", \ > + name, set->name); \ > + return ISC_R_UNEXPECTED; \ > + } \ > + *target = setting->value.value_name; \ > + \ > + return ISC_R_SUCCESS; \ > + \ > +cleanup: \ > + log_bug("setting '%s' was not found in settings tree", name); \ > + return result; \ > +} > + > +setting_getter(uint, isc_uint32_t *, ST_UNSIGNED_INTEGER, value_uint) > +setting_getter(str, const char **, ST_STRING, value_char) > +setting_getter(bool, isc_boolean_t *, ST_BOOLEAN, value_boolean) I don't like this part of code much. When you declare setting_get* functions this way, you end with 3 copies of nearly same code which leads to bloat of ldap.so. In my opinion just one function with switch (enum_type) {} inside which returns void* might be better. After that we can declare wrappers which will re-type void* to appropriate type. Example: isc_result_t setting_get(const char *name, const settings_set_t *set, enum_type, void *target); #define setting_get_uint(name, set, target) setting_get(name, set, ST_UNSIGNED_INTEGER, target); This way we will end with only one copy of setting_get function. > + > +/** > + * Convert and copy value to setting structure. Mutual exclusion during write > + * is ensured by isc_task_beginexclusive(task). > + * > + * @retval ISC_R_SUCCESS New value was converted and copied. > + * @retval ISC_R_IGNORE New and old values are same, no change was made. > + * @retval ISC_R_NOMEMORY > + * @retval ISC_R_UNEXPECTEDEND > + * @retval ISC_R_UNEXPECTEDTOKEN > + * @retval others Other errors from isc_parse_uint32(). > + */ > +static isc_result_t > +set_value(isc_mem_t *mctx, setting_t *setting, const char *value, > + isc_task_t *task) > +{ > + isc_result_t result; > + isc_result_t lock = ISC_R_IGNORE; > + isc_uint32_t numeric_value; > + isc_uint32_t len; > + > + REQUIRE(setting != NULL); > + REQUIRE(value != NULL); > + REQUIRE(task != NULL); > + > + /* Check and convert new values. */ > + switch (setting->type) { > + case ST_STRING: > + if (setting->filled && > + strcmp(setting->value.value_char, value) == 0) > + return ISC_R_IGNORE; > + break; > + > + case ST_UNSIGNED_INTEGER: > + if (*value == '\0') > + CLEANUP_WITH(ISC_R_UNEXPECTEDEND); > + > + result = isc_parse_uint32(&numeric_value, value, 10); > + if (result != ISC_R_SUCCESS) { > + log_error_r("setting '%s' has to be unsigned integer " > + "(base 10)", setting->name); > + goto cleanup; > + } > + if (setting->filled && > + setting->value.value_uint == numeric_value) > + CLEANUP_WITH(ISC_R_IGNORE); > + break; > + > + case ST_BOOLEAN: > + if (strcasecmp(value, "yes") == 0 || > + strcasecmp(value, "true") == 0) > + numeric_value = 1; > + else if (strcasecmp(value, "no") == 0 || > + strcasecmp(value, "false") == 0) > + numeric_value = 0; > + else { > + log_error("unknown boolean expression " > + "(setting '%s': value '%s')", > + setting->name, value); > + CLEANUP_WITH(ISC_R_UNEXPECTEDTOKEN); > + } > + if (setting->filled && > + setting->value.value_boolean == ISC_TF(numeric_value)) > + CLEANUP_WITH(ISC_R_IGNORE); > + break; > + } > + > + /* Switch to single thread mode and write new value. */ > + lock = isc_task_beginexclusive(task); > + RUNTIME_CHECK(lock == ISC_R_SUCCESS || lock == ISC_R_LOCKBUSY); > + > + switch (setting->type) { > + case ST_STRING: > + len = strlen(value) + 1; > + if (setting->allocated_dynamically) > + isc_mem_free(mctx, setting->value.value_char); > + CHECKED_MEM_ALLOCATE(mctx, setting->value.value_char, len); > + setting->allocated_dynamically = ISC_TRUE; > + CHECK(isc_string_copy(setting->value.value_char, len, value)); > + break; > + > + case ST_UNSIGNED_INTEGER: > + setting->value.value_uint = numeric_value; > + break; > + > + case ST_BOOLEAN: > + setting->value.value_boolean = ISC_TF(numeric_value); > + break; > + } > + setting->filled = 1; > + result = ISC_R_SUCCESS; > + > +cleanup: > + if (lock == ISC_R_SUCCESS) > + isc_task_endexclusive(task); > + return result; > +} > + > +/** > + * Change value in given set of settings (non-recursively, parent sets are > + * not affected in any way). Function will fail if setting with given name is > + * not a part of set of settings. > + * Mutual exclusion is ensured by set_value(). > + * > + * @warning > + * Failure in this function usually points to insufficient input validation > + * OR logic error. > + * Caller should always check the return value. > + * > + * @retval ISC_R_SUCCESS Value was changed. > + * @retval ISC_R_IGNORE Value wasn't changed because it is same as original. > + * @retval ISC_R_NOTFOUND Setting was not found in given set of settings. > + * @retval ISC_R_NOMEMORY > + * @retval Others Conversion errors. > + */ > +isc_result_t > +setting_set(const char *const name, const settings_set_t *set, > + const char *const value, isc_task_t *task) > +{ > + isc_result_t result; > + setting_t *setting = NULL; > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + > + return set_value(set->mctx, setting, value, task); > + > +cleanup: > + log_bug("setting '%s' was not found in set of settings '%s'", name, > + set->name); > + return result; > +} > + > +/** > + * Un-set value in given set of settings (non-recursively, parent sets are > + * not affected in any way). Function will fail if setting with given name is > + * not a part of set of settings. > + * Mutual exclusion is ensured by isc_task_beginexclusive(). > + * > + * @warning > + * Failure in this function usually points to logic error. > + * Caller should always check return value. > + * > + * @retval ISC_R_SUCCESS Setting was un-set. > + * @retval ISC_R_IGNORE Setting wasn't changed because wasn't set. > + * @retval ISC_R_NOTFOUND Required setting was not found > + * in given set of settings. > + */ > +isc_result_t > +setting_unset(const char *const name, const settings_set_t *set, > + isc_task_t *task) > +{ > + isc_result_t result; > + isc_result_t lock = ISC_R_IGNORE; > + setting_t *setting = NULL; > + > + REQUIRE(task != NULL); > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + > + if (!setting->filled) > + return ISC_R_IGNORE; > + > + lock = isc_task_beginexclusive(task); > + RUNTIME_CHECK(lock == ISC_R_SUCCESS || lock == ISC_R_LOCKBUSY); > + > + switch (setting->type) { > + case ST_STRING: > + if (setting->allocated_dynamically) > + isc_mem_free(set->mctx, setting->value.value_char); > + setting->allocated_dynamically = ISC_FALSE; > + break; > + > + case ST_UNSIGNED_INTEGER: > + case ST_BOOLEAN: > + break; > + } > + setting->filled = 0; > + > +cleanup: > + if (lock == ISC_R_SUCCESS) > + isc_task_endexclusive(task); > + if (result == ISC_R_NOTFOUND) > + log_bug("setting '%s' was not found in set of settings '%s'", > + name, set->name); > + > + return result; > +} > + > +/** > + * Change setting 'name' to value specified by attribute 'attr_name' in LDAP > + * entry. Setting is un-set if specified value is missing in LDAP entry. > + * > + * @warning Multi-value attributes are no supported. > + * > + * @retval ISC_R_SUCCESS Setting was changed (set or unset). > + * @retval ISC_R_IGNORE Setting wasn't changed because value in settings set > + * and LDAP entry was same. > + * @retval ISC_R_NOTFOUND Required setting was not found in given set. > + * @retval Others Memory allocation or conversion errors. > + */ > +isc_result_t > +setting_update_from_ldap_entry(const char *name, settings_set_t *set, > + const char *attr_name, ldap_entry_t *entry, > + isc_task_t *task) { > + isc_result_t result; > + setting_t *setting = NULL; > + ldap_valuelist_t values; > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + result = ldap_entry_getvalues(entry, attr_name, &values); > + if (result == ISC_R_NOTFOUND || HEAD(values) == NULL) { > + CHECK(setting_unset(name, set, task)); > + log_debug(2, "setting '%s' (%s) was deleted in object '%s'", > + name, attr_name, entry->dn); > + return ISC_R_SUCCESS; > + > + } else if (result != ISC_R_SUCCESS) { > + goto cleanup; > + } > + > + if (HEAD(values) != TAIL(values)) { > + log_bug("multi-value attributes are not supported: attribute " > + "'%s' in entry '%s'", attr_name, entry->dn); > + return ISC_R_NOTIMPLEMENTED; > + } > + > + CHECK(setting_set(name, set, HEAD(values)->value, task)); > + log_debug(2, "setting '%s' (%s) was changed to '%s' in object '%s'", > + name, attr_name, HEAD(values)->value, entry->dn); > + > +cleanup: > + if (result == ISC_R_NOTFOUND) > + log_bug("setting '%s' was not found in settings set '%s'", > + name, set->name); > + return result; > +} > + > +/** > + * Allocate new set of settings, fill it with values from specified default set > + * and (optionally) link the new set of settings to its parent set. > + * > + * @param[in] default_settings Array with pre-filled setting structures. > + * @param[in] default_set_length Default set length in bytes. > + * @param[in] set_name Human readable name for this set of settings. > + * > + * @pre target != NULL && *target == NULL > + * @pre default_settings != NULL > + * @pre default_set_length > 0, default_set_length <= sizeof(default_settings) > + * > + * @retval ISC_R_SUCCESS > + * @retval ISC_R_NOMEMORY > + * > + * @note How to create local_settings which overrides default_settings: > + * @code > + * const setting_t default_settings[] = { > + * { "connections", default_uint(2) }, > + * } > + * const settings_set_t default_settings_set = { > + * NULL, > + * NULL, > + * (setting_t *) &default_settings[0] > + * }; > + * const setting_t local_settings[] = { > + * { "connections", no_default_uint }, > + * } > + * > + * settings_set_t *local_settings = NULL; > + * result = settings_set_create(mctx, default_settings, > + * sizeof(default_settings), &default_settings_set, > + * &local_settings); > + * @endcode > + */ > +isc_result_t > +settings_set_create(isc_mem_t *mctx, const setting_t default_settings[], > + const unsigned int default_set_length, const char *set_name, > + const settings_set_t *const parent_set, > + settings_set_t **target) { > + isc_result_t result = ISC_R_FAILURE; > + settings_set_t *new_set = NULL; > + > + REQUIRE(target != NULL && *target == NULL); > + REQUIRE(default_settings != NULL); > + REQUIRE(default_set_length > 0); > + > + CHECKED_MEM_ALLOCATE(mctx, new_set, default_set_length); > + ZERO_PTR(new_set); > + isc_mem_attach(mctx, &new_set->mctx); > + new_set->parent_set = parent_set; > + > + CHECKED_MEM_ALLOCATE(mctx, new_set->first_setting, default_set_length); > + memcpy(new_set->first_setting, default_settings, default_set_length); > + > + CHECKED_MEM_ALLOCATE(mctx, new_set->name, strlen(set_name) + 1); > + strcpy(new_set->name, set_name); > + > + *target = new_set; > + result = ISC_R_SUCCESS; > + > +cleanup: > + if (result != ISC_R_SUCCESS) > + settings_set_free(&new_set); > + > + return result; > +} > + > +/** > + * Free dynamically allocated memory associated with given set of settings. > + * @pre *set is initialized set of settings, set != NULL && *set != NULL > + * @post *set == NULL > + */ > +void > +settings_set_free(settings_set_t **set) { > + isc_mem_t *mctx = NULL; > + setting_t *s = NULL; > + > + if (set == NULL || *set == NULL) > + return; > + > + if ((*set)->mctx != NULL) { > + mctx = (*set)->mctx; > + for (s = (*set)->first_setting; s->name != NULL; s++) { > + if (s->allocated_dynamically) > + isc_mem_free(mctx, s->value.value_char); > + } > + if ((*set)->first_setting != NULL) > + isc_mem_free(mctx, (*set)->first_setting); > + isc_mem_free(mctx, (*set)->name); > + isc_mem_free(mctx, *set); > + isc_mem_detach(&mctx); > + } > + *set = NULL; > +} > + > +/** > + * Set all values specified by vector of strings to setting set. Setting name > + * is separated from it's argument with one or more characters defined by > + * @link SETTING_NAME_SEPARATORS at endlink. > + * > + * @retval ISC_R_SUCCESS All strings in argument vector were processed and set. > + * @retval Others Memory or parsing errors. > + * > + * @warning One string in argument vector is limited to > + * @link SETTING_LINE_MAXLENGTH at endlink. > + * > + * @note > + * @code{.txt} > + * Calling settings_set_fill() with argument array > + * > + * {"setting1 value 1 ", > + * "bind_dn cn=Directory manager" } > + * > + * will result in setting values to two separate settings: > + * > + * "setting1" = "value 1 " > + * "bind_dn" = "cn=Directory manager" > + * > + * Please note the positions of white spaces. > + * @endcode > + */ > +isc_result_t > +settings_set_fill(settings_set_t *set, const char *const *argv, > + isc_task_t *task) > +{ > + isc_result_t result; > + int i; > + const char *name; > + char *value; > + > + for (i = 0; argv[i] != NULL; i++) { > + char buff[SETTING_LINE_MAXLENGTH] = ""; > + CHECK(isc_string_copy(buff, SETTING_LINE_MAXLENGTH, argv[i])); > + value = buff; > + name = isc_string_separate(&value, SETTING_NAME_SEPARATORS); > + if (name == NULL || value == NULL) > + CLEANUP_WITH(ISC_R_UNEXPECTEDEND); > + value += strspn(value, SETTING_NAME_SEPARATORS); > + if (setting_find(name, set, ISC_FALSE, ISC_TRUE, NULL) > + != ISC_R_NOTFOUND) { > + log_error("multiple definitions of setting '%s' in " > + "set of settings '%s'", name, set->name); > + CLEANUP_WITH(ISC_R_EXISTS); > + } > + result = setting_set(name, set, value, task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > + } > + > + return ISC_R_SUCCESS; > + > +cleanup: > + log_error_r("cannot parse settings from '%s': " > + "problematic configuration line:" > + "\n%s\n" > + "error code", set->name, argv[i]); > + /* TODO: Free memory in case of error. */ > + return result; > +} > + > +/** > + * Check if all the settings in given set of setting have defined value, > + * possibly indirectly through parent set of settings. > + * > + * Error message is logged for each setting without defined value. > + * > + * @retval ISC_TRUE All settings have value defined. > + * @retval ISC_FALSE At least one setting do not have defined value. > + */ > +isc_boolean_t > +settings_set_isfilled(settings_set_t *set) { > + isc_result_t result; > + isc_boolean_t isfiled = ISC_TRUE; > + > + REQUIRE(set != NULL); > + > + for (int i = 0; set->first_setting[i].name != NULL; i++) { > + const char *name = set->first_setting[i].name; > + result = setting_find(name, set, ISC_TRUE, ISC_TRUE, NULL); > + if (result != ISC_R_SUCCESS) { > + log_error_r("argument '%s' must be set " > + "in set of settings '%s'", name, set->name); > + isfiled = ISC_FALSE; > + } > + } > + return isfiled; > +} > + > +isc_result_t > +get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc) { > + const enum_txt_assoc_t *record; > + > + REQUIRE(map != NULL); > + REQUIRE(desc != NULL && *desc == NULL); > + > + for (record = map; > + record->description != NULL && record->value != -1; > + record++) { > + if (record->value == value) { > + *desc = record->description; > + return ISC_R_SUCCESS; > + } > + } > + return ISC_R_NOTFOUND; > +} > diff --git a/src/settings.h b/src/settings.h > index 53910ee11c2ac1f87db25fac8f24f5743f4312e4..fe86d44b5787319e3f8852081bcd36014c8a03d5 100644 > --- a/src/settings.h > +++ b/src/settings.h > @@ -1,7 +1,7 @@ > /* > * Authors: Martin Nagy > * > - * Copyright (C) 2009 Red Hat > + * Copyright (C) 2009-2012 Red Hat > * see file 'COPYING' for use and warranty information > * > * This program is free software; you can redistribute it and/or > @@ -23,28 +23,42 @@ > > #include > #include "types.h" > +#include "str.h" > +#include "ldap_entry.h" > + > +#define SETTING_LINE_MAXLENGTH 255 > +#define SETTING_NAME_SEPARATORS " \t" > +#define SETTING_SET_NAME_LOCAL "named.conf" > +#define SETTING_SET_NAME_GLOBAL "LDAP idnsConfig object" > +#define SETTING_SET_NAME_ZONE "LDAP idnsZone object" > > typedef struct setting setting_t; > +typedef struct settings_set settings_set_t; > > +/* Make sure that cases in get_value_ptr() are synchronized */ > typedef enum { > - ST_LD_STRING, > - ST_SIGNED_INTEGER, > + ST_STRING, > ST_UNSIGNED_INTEGER, > ST_BOOLEAN, > } setting_type_t; > > struct setting { > const char *name; > - int set; > - int has_a_default; > setting_type_t type; > union { > - const char *value_char; > - signed int value_sint; > - unsigned int value_uint; > + char *value_char; > + isc_uint32_t value_uint; > isc_boolean_t value_boolean; > - } default_value; > - void *target; > + } value; > + isc_boolean_t filled; > + isc_boolean_t allocated_dynamically; This is quite long name, isn't it? What about "dynamic" or "isdynamic"? > +}; > + > +struct settings_set { > + isc_mem_t *mctx; > + char *name; > + const settings_set_t *parent_set; > + setting_t *first_setting; > }; > > /* > @@ -59,24 +73,56 @@ struct setting { > * "name", no_default_string, &target_variable > * } > */ > -#define default_string(val) 0, 1, ST_LD_STRING, { .value_char = (val) }, NULL > -#define default_sint(val) 0, 1, ST_SIGNED_INTEGER, { .value_sint = (val) }, NULL > -#define default_uint(val) 0, 1, ST_UNSIGNED_INTEGER, { .value_uint = (val) }, NULL > -#define default_boolean(val) 0, 1, ST_BOOLEAN, { .value_boolean = (val) }, NULL > +#define default_string(val) ST_STRING, { .value_char = (val) }, ISC_TRUE, ISC_FALSE > +#define default_uint(val) ST_UNSIGNED_INTEGER, { .value_uint = (val) }, ISC_TRUE, ISC_FALSE > +#define default_boolean(val) ST_BOOLEAN, { .value_boolean = (val) }, ISC_TRUE, ISC_FALSE > /* No defaults. */ > -#define no_default_string 0, 0, ST_LD_STRING, { .value_char = NULL }, NULL > -#define no_default_sint 0, 0, ST_SIGNED_INTEGER, { .value_sint = 0 }, NULL > -#define no_default_uint 0, 0, ST_UNSIGNED_INTEGER, { .value_uint = 0 }, NULL > -#define no_default_boolean 0, 1, ST_BOOLEAN, { .value_boolean = ISC_FALSE }, NULL > +#define no_default_string ST_STRING, { .value_char = NULL }, ISC_FALSE, ISC_FALSE > +#define no_default_uint ST_UNSIGNED_INTEGER, { .value_uint = 0 }, ISC_FALSE, ISC_FALSE > +#define no_default_boolean ST_BOOLEAN, { .value_boolean = ISC_FALSE }, ISC_FALSE, ISC_FALSE > > /* This is used in the end of setting_t arrays. */ > -#define end_of_settings { NULL, default_sint(0) } > +#define end_of_settings { NULL, default_uint(0) } > > /* > * Prototypes. > */ > isc_result_t > -set_settings(setting_t *settings, const char * const* argv); > +settings_set_create(isc_mem_t *mctx, const setting_t default_settings[], > + const unsigned int default_set_length, const char *set_name, > + const settings_set_t *const parent_set, > + settings_set_t **target); > + > +void > +settings_set_free(settings_set_t **set); > + > +isc_result_t > +settings_set_fill(settings_set_t *set, const char *const *argv, > + isc_task_t *task); > + > +isc_boolean_t > +settings_set_isfilled(settings_set_t *set); > + > +isc_result_t > +setting_get_uint(const char * const name, const settings_set_t * const set, > + isc_uint32_t * target); > + > +isc_result_t > +setting_get_str(const char * const name, const settings_set_t * const set, > + const char ** target); > + > +isc_result_t > +setting_get_bool(const char * const name, const settings_set_t * const set, > + isc_boolean_t * target); > + > +isc_result_t > +setting_set(const char *const name, const settings_set_t *set, > + const char *const value, isc_task_t *task); > + > +isc_result_t > +setting_update_from_ldap_entry(const char *name, settings_set_t *set, > + const char *attr_name, ldap_entry_t *entry, > + isc_task_t *task); > > isc_result_t > get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc); > diff --git a/src/zone_manager.c b/src/zone_manager.c > index c19c3b6c91ff8114fcb15eacba0f74ec46047986..efc2299c4cd3280dc688d14b77d0d721e1554284 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -31,6 +31,7 @@ > #include > > #include > +#include > > #include "ldap_convert.h" > #include "ldap_helper.h" > @@ -112,18 +113,13 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > { > isc_result_t result; > db_instance_t *db_inst = NULL; > - unsigned int zone_refresh; > + isc_uint32_t zone_refresh; > isc_boolean_t psearch; > isc_timermgr_t *timer_mgr; > isc_interval_t interval; > isc_timertype_t timer_type = isc_timertype_inactive; > isc_task_t *task; > - setting_t manager_settings[] = { > - { "zone_refresh", default_uint(0) }, > - { "psearch", default_boolean(0) }, > - { "verbose_checks", default_boolean(0) }, > - end_of_settings > - }; > + settings_set_t *local_settings = NULL; > > REQUIRE(name != NULL); > REQUIRE(dyndb_args != NULL); > @@ -137,12 +133,6 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > CLEANUP_WITH(ISC_R_EXISTS); > } > > - /* Parse settings. */ > - manager_settings[0].target = &zone_refresh; > - manager_settings[1].target = &psearch; > - manager_settings[2].target = &verbose_checks; /* global variable */ > - CHECK(set_settings(manager_settings, argv)); > - > CHECKED_MEM_GET_PTR(mctx, db_inst); > ZERO_PTR(db_inst); > > @@ -157,13 +147,14 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > * > * Timer must exist before refresh_zones_from_ldap() is called. */ > timer_mgr = dns_dyndb_get_timermgr(dyndb_args); > + > + local_settings = ldap_instance_getsettings_local(db_inst->ldap_inst); > + CHECK(setting_get_uint("zone_refresh", local_settings, &zone_refresh)); > + CHECK(setting_get_bool("psearch", local_settings, &psearch)); > + CHECK(setting_get_bool("verbose_checks", local_settings, &verbose_checks)); > + > isc_interval_set(&interval, zone_refresh, 0); > > - if (zone_refresh && psearch) { > - log_error("Zone refresh and persistent search are enabled at same time! " > - "Only persistent search will be used."); > - } > - > if (zone_refresh && !psearch) { > timer_type = isc_timertype_ticker; > } else { > diff --git a/src/zone_register.c b/src/zone_register.c > index e52397357f2ef482d8dfee33f7564cd9157afa56..e8d844f7bd1de83a6c894ea18fed127af081fd0f 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -27,12 +27,14 @@ > #include > #include > > +#include > #include > > #include "log.h" > #include "util.h" > #include "zone_register.h" > #include "rdlist.h" > +#include "settings.h" > > /* > * The zone register is a red-black tree that maps a dns name of a zone to the > @@ -47,19 +49,45 @@ struct zone_register { > isc_mem_t *mctx; > isc_rwlock_t rwlock; > dns_rbt_t *rbt; > + settings_set_t *global_settings; > }; > > typedef struct { > dns_zone_t *zone; > char *dn; > isc_uint32_t serial; /* last value processed by plugin (!= value in DB) */ > unsigned char digest[RDLIST_DIGESTLENGTH]; /* MD5 digest from all RRs in zone record */ > ldap_cache_t *cache; > + settings_set_t *settings; > } zone_info_t; > > /* Callback for dns_rbt_create(). */ > static void delete_zone_info(void *arg1, void *arg2); > > +/** > + * Zone specific settings from idnsZone object: > + * NAME 'idnsZone' > + * MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $ > + * idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ > + * idnsSOAminimum > + * ) > + * MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ > + * idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders > + * ) > + * > + * These structures are templates. They will be copied for each zone instance. > + */ > +static const setting_t zone_settings[] = { > + { "dyn_update", no_default_boolean }, > + { "update_policy", no_default_string }, > + { "allow_query", no_default_string }, > + { "allow_transfer", no_default_string }, > + { "sync_ptr", no_default_boolean }, > + { "forward_policy", no_default_string }, > + { "forwarders", no_default_string }, > + end_of_settings > +}; > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr) > { > @@ -77,7 +105,7 @@ zr_get_mctx(zone_register_t *zr) { > * Create a new zone register. > */ > isc_result_t > -zr_create(isc_mem_t *mctx, zone_register_t **zrp) > +zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp) > { > isc_result_t result; > zone_register_t *zr = NULL; > @@ -89,6 +117,7 @@ zr_create(isc_mem_t *mctx, zone_register_t **zrp) > isc_mem_attach(mctx, &zr->mctx); > CHECK(dns_rbt_create(mctx, delete_zone_info, mctx, &zr->rbt)); > CHECK(isc_rwlock_init(&zr->rwlock, 0, 0)); > + zr->global_settings = glob_settings; > > *zrp = zr; > return ISC_R_SUCCESS; > @@ -128,23 +157,31 @@ zr_destroy(zone_register_t **zrp) > /* > * Create a new zone info structure. > */ > +#define PRINT_BUFF_SIZE 255 > static isc_result_t > create_zone_info(isc_mem_t *mctx, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch, > - zone_info_t **zinfop) > + settings_set_t *global_settings, zone_info_t **zinfop) > { > isc_result_t result; > zone_info_t *zinfo; > + char settings_name[PRINT_BUFF_SIZE]; > > REQUIRE(zone != NULL); > REQUIRE(dn != NULL); > REQUIRE(zinfop != NULL && *zinfop == NULL); > > CHECKED_MEM_GET_PTR(mctx, zinfo); > ZERO_PTR(zinfo); > CHECKED_MEM_STRDUP(mctx, dn, zinfo->dn); > - CHECK(new_ldap_cache(mctx, cache_ttl, psearch, &zinfo->cache)); > + CHECK(new_ldap_cache(mctx, global_settings, &zinfo->cache)); > dns_zone_attach(zone, &zinfo->zone); > + zinfo->settings = NULL; > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_ZONE " %s", > + dn); > + CHECK(settings_set_create(mctx, zone_settings, sizeof(zone_settings), > + settings_name, global_settings, > + &zinfo->settings)); > > *zinfop = zinfo; > return ISC_R_SUCCESS; > @@ -168,6 +205,7 @@ delete_zone_info(void *arg1, void *arg2) > return; > > destroy_ldap_cache(&zinfo->cache); > + settings_set_free(&zinfo->settings); > isc_mem_free(mctx, zinfo->dn); > dns_zone_detach(&zinfo->zone); > SAFE_MEM_PUT_PTR(mctx, zinfo); > @@ -178,8 +216,7 @@ delete_zone_info(void *arg1, void *arg2) > * must be absolute and the zone cannot already be in the zone register. > */ > isc_result_t > -zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch) > +zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn) > { > isc_result_t result; > dns_name_t *name; > @@ -210,7 +247,7 @@ zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > goto cleanup; > } > > - CHECK(create_zone_info(zr->mctx, zone, dn, cache_ttl, psearch, > + CHECK(create_zone_info(zr->mctx, zone, dn, zr->global_settings, > &new_zinfo)); > CHECK(dns_rbt_addname(zr->rbt, name, new_zinfo)); > > @@ -412,6 +449,37 @@ zr_get_zone_serial_digest(zone_register_t *zr, dns_name_t *name, > return result; > } > > +/* > + * Find a zone with origin 'name' within in the zone register 'zr'. If an > + * exact match is found, the pointer to the zone's settings is returned through > + * 'set'. > + */ > +isc_result_t > +zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set) > +{ > + isc_result_t result; > + void *zinfo = NULL; > + > + REQUIRE(zr != NULL); > + REQUIRE(name != NULL); > + REQUIRE(set != NULL && *set == NULL); > + > + if (!dns_name_isabsolute(name)) { > + log_bug("trying to find zone with a relative name"); > + return ISC_R_FAILURE; > + } > + > + RWLOCK(&zr->rwlock, isc_rwlocktype_read); > + > + result = dns_rbt_findname(zr->rbt, name, 0, NULL, &zinfo); > + if (result == ISC_R_SUCCESS) > + *set = ((zone_info_t *)zinfo)->settings; > + > + RWUNLOCK(&zr->rwlock, isc_rwlocktype_read); > + > + return result; > +} > + > /** > * Set last SOA serial and digest from RRs processed by autoincrement feature. > */ > diff --git a/src/zone_register.h b/src/zone_register.h > index cec7400ff893842d499d15f6897d448710ac5407..3f4114d2256c1e8af5f67c69f1829900c9c7b2e9 100644 > --- a/src/zone_register.h > +++ b/src/zone_register.h > @@ -22,18 +22,18 @@ > #define _LD_ZONE_REGISTER_H_ > > #include "cache.h" > +#include "settings.h" > > typedef struct zone_register zone_register_t; > > isc_result_t > -zr_create(isc_mem_t *mctx, zone_register_t **zrp); > +zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp); > > void > zr_destroy(zone_register_t **zrp); > > isc_result_t > -zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch); > +zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn); > > isc_result_t > zr_del_zone(zone_register_t *zr, dns_name_t *origin); > @@ -51,6 +51,9 @@ zr_get_zone_dn(zone_register_t *zr, dns_name_t *name, const char **dn, > isc_result_t > zr_get_zone_ptr(zone_register_t *zr, dns_name_t *name, dns_zone_t **zonep); > > +isc_result_t > +zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set); > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 4 14:00:23 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:00:23 +0100 Subject: [Freeipa-devel] [PATCH 0114] Log name of the zone if zone cannot be created In-Reply-To: <5124F259.8050203@redhat.com> References: <5124F259.8050203@redhat.com> Message-ID: <20130304140018.GB2274@redhat.com> On Wed, Feb 20, 2013 at 04:57:13PM +0100, Petr Spacek wrote: > Hello, > > Log name of the zone if zone cannot be created. Ack > From 9f97b85ada8d67f5422dedfb936bc75cb02dfa2c Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Wed, 20 Feb 2013 16:55:30 +0100 > Subject: [PATCH] Log name of the zone if zone cannot be created. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 17 +++++++++++------ > 1 file changed, 11 insertions(+), 6 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 71b96ce5eef2a249f7d16c448c70e2c2068d271d..19d9399ada3358c94b7d68f36b8e5147c4ae432d 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -750,12 +750,17 @@ create_zone(ldap_instance_t *ldap_inst, dns_name_t *name, dns_zone_t **zonep) > argv[1] = ldap_inst->db_name; > > result = dns_view_findzone(ldap_inst->view, name, &zone); > - if (result == ISC_R_SUCCESS) { > - result = ISC_R_EXISTS; > - log_error_r("failed to create new zone"); > - goto cleanup; > - } else if (result != ISC_R_NOTFOUND) { > - log_error_r("dns_view_findzone() failed"); > + if (result != ISC_R_NOTFOUND) { > + char zone_name[DNS_NAME_FORMATSIZE]; > + dns_name_format(name, zone_name, DNS_NAME_FORMATSIZE); > + > + if (result == ISC_R_SUCCESS) { > + result = ISC_R_EXISTS; > + log_error_r("failed to create new zone '%s'", zone_name); > + } else { > + log_error_r("dns_view_findzone() failed while " > + "searching for zone '%s'", zone_name); > + } > goto cleanup; > } > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 4 14:14:24 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:14:24 +0100 Subject: [Freeipa-devel] [PATCH 0115] Add support for DNAME substitution In-Reply-To: <51263CC7.6080900@redhat.com> References: <51263B74.9080406@redhat.com> <51263CC7.6080900@redhat.com> Message-ID: <20130304141424.GC2274@redhat.com> On Thu, Feb 21, 2013 at 04:27:03PM +0100, Petr Spacek wrote: > On 21.2.2013 16:21, Petr Spacek wrote: > >Hello, > > > > Add support for DNAME substitution. > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/63 > > > > And now the patch :-) Ack > From dc1215e8a82d3993f69436b4de9ff91ea16f4369 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 21 Feb 2013 13:34:52 +0100 > Subject: [PATCH] Add support for DNAME substitution. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/63 > > Signed-off-by: Petr Spacek > --- > src/ldap_driver.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/src/ldap_driver.c b/src/ldap_driver.c > index cde09ee8aa3c9332f3766a031030a95b0cff3229..9cae66b3950323221d3319649fc7b86ef25a5d68 100644 > --- a/src/ldap_driver.c > +++ b/src/ldap_driver.c > @@ -457,7 +457,6 @@ cleanup: > return result; > } > > -/* XXX add support for DNAME redirection */ > static isc_result_t > find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, > dns_rdatatype_t type, unsigned int options, isc_stdtime_t now, > @@ -469,6 +468,7 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, > ldapdb_node_t *node = NULL; > dns_rdatalist_t *rdlist = NULL; > isc_boolean_t is_cname = ISC_FALSE; > + isc_boolean_t is_dname = ISC_FALSE; > isc_boolean_t is_delegation = ISC_FALSE; > ldapdb_rdatalist_t rdatalist; > unsigned int labels, qlabels; > @@ -515,7 +515,20 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, > continue; > } > > - /* TODO: We should check for DNAME records right here */ > + /* RFC 6672 section 2.3.: > + Unlike a CNAME RR, a DNAME RR redirects DNS names > + subordinate to its owner name; the owner name of a DNAME > + is not redirected itself. */ > + if (qlabels > dns_name_countlabels(traversename)) { > + rdlist = NULL; > + result = ldapdb_rdatalist_findrdatatype(&rdatalist, > + dns_rdatatype_dname, > + &rdlist); > + if (result == ISC_R_SUCCESS) { > + is_dname = ISC_TRUE; > + goto skipfind; > + } > + } > > /* > * Check if there is at least one NS RR. If yes and this is not NS > @@ -527,6 +540,7 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, > if (dns_name_countlabels(&db->origin) < > dns_name_countlabels(traversename) && > (options & DNS_DBFIND_GLUEOK) == 0) { > + rdlist = NULL; > result = ldapdb_rdatalist_findrdatatype(&rdatalist, > dns_rdatatype_ns, > &rdlist); > @@ -582,7 +596,7 @@ found: > skipfind: > CHECK(dns_name_copy(traversename, foundname, NULL)); > > - if (rdataset != NULL && type != dns_rdatatype_any) { > + if (rdataset != NULL && (type != dns_rdatatype_any || is_dname)) { > /* dns_rdatalist_tordataset returns success only */ > CHECK(clone_rdatalist_to_rdataset(ldapdb->common.mctx, rdlist, > rdataset)); > @@ -600,6 +614,8 @@ skipfind: > return DNS_R_DELEGATION; > else if (is_cname) > return DNS_R_CNAME; > + else if (is_dname) > + return DNS_R_DNAME; > else > return ISC_R_SUCCESS; > > -- > 1.7.11.7 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 4 14:15:50 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:15:50 +0100 Subject: [Freeipa-devel] [PATCH 0116] Fix crash caused by invalid wildcard in update policy string In-Reply-To: <512B7529.5080506@redhat.com> References: <512B7529.5080506@redhat.com> Message-ID: <20130304141549.GD2274@redhat.com> On Mon, Feb 25, 2013 at 03:28:57PM +0100, Petr Spacek wrote: > Hello, > > Fix crash caused by invalid wildcard in update policy string. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/108 > > Question: > What we should do if update policy string contains an error? > Should we disable all updates? > Or let the old policy in place? > I vote for disallowing all updates. +1. In my opinion disallowing all updates is correct. Ack for the patch. > From 9265430d94cb4997188583b8e4c2befe7b28ba4b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 25 Feb 2013 15:24:07 +0100 > Subject: [PATCH] Fix crash caused by invalid wildcard in update policy > string. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/108 > > Signed-off-by: Petr Spacek > --- > src/acl.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/src/acl.c b/src/acl.c > index c62a8cb9e867b658b65ce05a07fc31377b2356c2..f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -420,6 +420,18 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone) > CHECK(get_fixed_name(stmt, "name", &fname)); > CHECK(get_types(mctx, stmt, &types, &n)); > > + if (match_type == DNS_SSUMATCHTYPE_WILDCARD && > + !dns_name_iswildcard(dns_fixedname_name(&fname))) { > + char name[DNS_NAME_FORMATSIZE]; > + dns_name_format(dns_fixedname_name(&fname), name, > + DNS_NAME_FORMATSIZE); > + dns_zone_log(zone, ISC_LOG_ERROR, > + "invalid update policy: " > + "name '%s' is expected to be a wildcard", > + name); > + CLEANUP_WITH(DNS_R_BADNAME); > + } > + > result = dns_ssutable_addrule(table, grant, > dns_fixedname_name(&fident), > match_type, > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 4 14:17:40 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:17:40 +0100 Subject: [Freeipa-devel] [PATCH 0112] Make log messages related to Kerberos more verbose In-Reply-To: <512E246C.7070702@redhat.com> References: <511A3C84.4020205@redhat.com> <512E246C.7070702@redhat.com> Message-ID: <20130304141739.GE2274@redhat.com> On Wed, Feb 27, 2013 at 04:21:16PM +0100, Petr Spacek wrote: > On 12.2.2013 13:58, Petr Spacek wrote: > >Hello, > > > > Make log messages related to Kerberos more verbose. > > > >This change should help people supporting bind-dyndb-ldap to figure out what > >is happening under covers. > > Added explanatory error message for case where Kerberos context > initialization failed. Ack > From 467a5d405f57e2277808c0b33b22480a3167abe4 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 12 Feb 2013 13:49:32 +0100 > Subject: [PATCH] Make log messages related to Kerberos more verbose. > > Signed-off-by: Petr Spacek > --- > src/krb5_helper.c | 38 +++++++++++++++++++++++--------------- > 1 file changed, 23 insertions(+), 15 deletions(-) > > diff --git a/src/krb5_helper.c b/src/krb5_helper.c > index ffa6938d08a37d3470dd9184be2d8ab5c604afdf..25de7f80ee56a6a2c6c6591266edf621914a10b9 100644 > --- a/src/krb5_helper.c > +++ b/src/krb5_helper.c > @@ -60,15 +60,15 @@ check_credentials(krb5_context context, > krberr = krb5_build_principal(context, &mcreds.server, > strlen(realm), realm, > "krbtgt", realm, NULL); > - CHECK_KRB5(context, krberr, "Failed to build tgt principal"); > + CHECK_KRB5(context, krberr, "Failed to build 'krbtgt/REALM' principal"); > > /* krb5_cc_retrieve_cred filters on both server and client */ > mcreds.client = service; > > krberr = krb5_cc_retrieve_cred(context, ccache, 0, &mcreds, &creds); > if (krberr) { > const char * errmsg = krb5_get_error_message(context, krberr); > - log_debug(2, "Principal not found in cred cache (%s)", > + log_debug(2, "Credentials are not present in cache (%s)", > errmsg); > krb5_free_error_message(context, errmsg); > result = ISC_R_FAILURE; > @@ -79,7 +79,7 @@ check_credentials(krb5_context context, > CHECK_KRB5(context, krberr, "Failed to get timeofday"); > > if (now > (creds.times.endtime + MIN_TIME)) { > - log_debug(2, "Credentials expired"); > + log_debug(2, "Credentials in cache expired"); > result = ISC_R_FAILURE; > goto cleanup; > } > @@ -123,42 +123,46 @@ get_krb5_tgt(isc_mem_t *mctx, const char *principal, const char *keyfile) > } > > krberr = krb5_init_context(&context); > - if (krberr) { > - log_error("Failed to init kerberos context"); > - return ISC_R_FAILURE; > - } > + /* This will blow up with older versions of Heimdal Kerberos, but > + * this kind of errors are not debuggable without any error message. > + * http://mailman.mit.edu/pipermail/kerberos/2013-February/018720.html */ > + CHECK_KRB5(NULL, krberr, "Kerberos context initialization failed"); > > /* get credentials cache */ > CHECK(str_new(mctx, &ccname)); > CHECK(str_sprintf(ccname, "MEMORY:_ld_krb5_cc_%s", principal)); > > ret = setenv("KRB5CCNAME", str_buf(ccname), 1); > if (ret == -1) { > - log_error("Failed to set KRB5CCNAME environment variable"); > + log_error("Failed to set KRB5CCNAME environment variable to " > + "'%s'", str_buf(ccname)); > result = ISC_R_FAILURE; > goto cleanup; > } > > krberr = krb5_cc_resolve(context, str_buf(ccname), &ccache); > CHECK_KRB5(context, krberr, > - "Failed to resolve ccache name %s", str_buf(ccname)); > + "Failed to resolve credentials cache name '%s'", > + str_buf(ccname)); > > /* get krb5_principal from string */ > krberr = krb5_parse_name(context, principal, &kprincpw); > CHECK_KRB5(context, krberr, > - "Failed to parse the principal name %s", principal); > + "Failed to parse the principal name '%s'", principal); > > /* check if we already have valid credentials */ > result = check_credentials(context, ccache, kprincpw); > if (result == ISC_R_SUCCESS) { > - log_debug(2, "Found valid cached credentials"); > + log_debug(2, "Found valid Kerberos credentials in cache"); > goto cleanup; > + } else { > + log_debug(2, "Attempting to acquire new Kerberos credentials"); > } > > /* open keytab */ > krberr = krb5_kt_resolve(context, keyfile, &keytab); > CHECK_KRB5(context, krberr, > - "Failed to resolve keytab file %s", keyfile); > + "Failed to resolve keytab file '%s'", keyfile); > > memset(&my_creds, 0, sizeof(my_creds)); > memset(&options, 0, sizeof(options)); > @@ -170,15 +174,19 @@ get_krb5_tgt(isc_mem_t *mctx, const char *principal, const char *keyfile) > /* get tgt */ > krberr = krb5_get_init_creds_keytab(context, &my_creds, kprincpw, > keytab, 0, NULL, &options); > - CHECK_KRB5(context, krberr, "Failed to init credentials"); > + CHECK_KRB5(context, krberr, "Failed to get initial credentials (TGT) " > + "using principal '%s' and keytab '%s'", > + principal, keyfile); > my_creds_ptr = &my_creds; > > /* store credentials in cache */ > krberr = krb5_cc_initialize(context, ccache, kprincpw); > - CHECK_KRB5(context, krberr, "Failed to initialize ccache"); > + CHECK_KRB5(context, krberr, "Failed to initialize credentials cache " > + "'%s'", str_buf(ccname)); > > krberr = krb5_cc_store_cred(context, ccache, &my_creds); > - CHECK_KRB5(context, krberr, "Failed to store ccache"); > + CHECK_KRB5(context, krberr, "Failed to store credentials " > + "in credentials cache '%s'", str_buf(ccname)); > > result = ISC_R_SUCCESS; > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pviktori at redhat.com Mon Mar 4 14:29:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 04 Mar 2013 15:29:22 +0100 Subject: [Freeipa-devel] [PATCH] 0190 Fix installing server with external CA Message-ID: <5134AFC2.5040204@redhat.com> I did not test the external CA case when we merged DS instances some time ago, so it ended up broken. Here is a fix. Our DsInstance class could only be initialized properly by calling create_instance or create_replica. Fr step 2, when the DS is not being installed, I gathered the common setup code to init_info, and called that. Ideally this will one day end up in __init__, but that's for a bigger refactoring. https://fedorahosted.org/freeipa/ticket/3459 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0190-Fix-installing-server-with-external-CA.patch Type: text/x-patch Size: 10570 bytes Desc: not available URL: From atkac at redhat.com Mon Mar 4 14:45:30 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:45:30 +0100 Subject: [Freeipa-devel] [PATCH 0111] Automatically reload invalid zone after each change in zone data In-Reply-To: <511A2E38.10006@redhat.com> References: <511A2E38.10006@redhat.com> Message-ID: <20130304144529.GA4633@redhat.com> On Tue, Feb 12, 2013 at 12:57:44PM +0100, Petr Spacek wrote: > Hello, > > Automatically reload invalid zone after each change in zone data. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 Ack > How to test: > > # create a invalid zone, e.g. zone without A records for names in NS records > > ipa dnszone-add zone.test --admin-email=blah.nonsense > --name-server=ns.zone.test. --force > > # now dig ns.zone.test. should return SERVFAIL because zone doesn't > have proper NS+A/AAAA records > > dig ns.zone.test. > > # addition of arbitrary record should not crash the server > > ipa dnsrecord-add zone.test ns --txt-rec=blah > > # after this modification some error message should appear in log > and dig ns.zone.test. should still return SERVFAIL > > dig ns.zone.test. > > # addition of valid A record should fix the problem > > ipa dnsrecord-add zone.test ns --a-rec=127.0.0.1 > > # now dig -t ANY ns.zone.test. should return NOERROR and zone should work > # TXT and also A record should be visible > > dig -t ANY ns.zone.test. > > -- > Petr^2 Spacek > From de083cd61471384ccdcc0f02303390d92928a506 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 12 Feb 2013 12:42:29 +0100 > Subject: [PATCH] Automatically reload invalid zone after each change in zone > data. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > > Signed-off-by: Petr Spacek > --- > NEWS | 3 +++ > src/ldap_helper.c | 38 ++++++++++++++++++++++++++++++++++++-- > 2 files changed, 39 insertions(+), 2 deletions(-) > > diff --git a/NEWS b/NEWS > index 9f50db12de760ccaa7f4adb5cc03534ae72c47be..6dd09c118c86c4f5daf44bfbc5978600092b3d7f 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,3 +1,6 @@ > +[1] Automatically reload invalid zone after each change in zone data. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > + > 2.5 > ===== > [1] Fix crash during per-zone cache flush. > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 71b96ce5eef2a249f7d16c448c70e2c2068d271d..491817813229f988161f3cedc6c83055040ad3ae 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3411,8 +3411,11 @@ update_record(isc_task_t *task, isc_event_t *event) > ldap_psearchevent_t *pevent = (ldap_psearchevent_t *)event; > isc_result_t result; > ldap_instance_t *inst = NULL; > - ldap_cache_t *cache = NULL; > + ldap_cache_t *cache; > isc_mem_t *mctx; > + dns_zone_t *zone_ptr = NULL; > + isc_boolean_t zone_found = ISC_FALSE; > + isc_boolean_t zone_reloaded = ISC_FALSE; > mctx = pevent->mctx; > > UNUSED(task); > @@ -3431,13 +3434,16 @@ update_record(isc_task_t *task, isc_event_t *event) > dns_name_init(&prevname, NULL); > dns_name_init(&prevorigin, NULL); > CHECK(dn_to_dnsname(mctx, pevent->dn, &name, &origin)); > + zone_found = ISC_TRUE; > > +update_restart: > if (PSEARCH_DEL(pevent->chgtype) || PSEARCH_MODDN(pevent->chgtype)) { > log_debug(5, "psearch_update: removing name from cache, dn: '%s'", > pevent->dn); > } > > /* Get cache instance & clean old record */ > + cache = NULL; > CHECK(zr_get_zone_cache(inst->zone_register, &name, &cache)); > CHECK(discard_from_cache(cache, &name)); > > @@ -3486,11 +3492,39 @@ update_record(isc_task_t *task, isc_event_t *event) > if (inst->serial_autoincrement && PSEARCH_ANY(pevent->chgtype)) { > CHECK(soa_serial_increment(mctx, inst, &origin)); > } > + > cleanup: > - if (result != ISC_R_SUCCESS) > + if (result != ISC_R_SUCCESS && zone_found && !zone_reloaded && > + (result == DNS_R_NOTLOADED || result == DNS_R_BADZONE)) { > + log_debug(1, "reloading invalid zone after a change; " > + "reload triggered by change in '%s'", > + pevent->dn); > + > + result = zr_get_zone_ptr(inst->zone_register, &origin, &zone_ptr); > + if (result == ISC_R_SUCCESS) > + result = dns_zone_load(zone_ptr); > + if (zone_ptr != NULL) > + dns_zone_detach(&zone_ptr); > + > + if (result == ISC_R_SUCCESS || result == DNS_R_UPTODATE || > + result == DNS_R_DYNAMIC || result == DNS_R_CONTINUE) { > + /* zone reload succeeded, fire current event again */ > + log_debug(1, "restarting update_record after zone reload " > + "caused by change in '%s'", pevent->dn); > + zone_reloaded = ISC_TRUE; > + goto update_restart; > + } else { > + log_error_r("unable to reload invalid zone; " > + "reload triggered by change in '%s'", > + pevent->dn); > + } > + > + } else if (result != ISC_R_SUCCESS) { > + /* error other than invalid zone */ > log_error_r("update_record (psearch) failed, dn '%s' change type 0x%x. " > "Records can be outdated, run `rndc reload`", > pevent->dn, pevent->chgtype); > + } > > if (dns_name_dynamic(&name)) > dns_name_free(&name, inst->mctx); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 4 14:46:22 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 15:46:22 +0100 Subject: [Freeipa-devel] [PATCH 0113] Periodically reconnect if Kerberos KDC is unavailable In-Reply-To: <511DF79A.4010804@redhat.com> References: <511DF79A.4010804@redhat.com> Message-ID: <20130304144622.GB4633@redhat.com> On Fri, Feb 15, 2013 at 09:53:46AM +0100, Petr Spacek wrote: > Hello, > > Periodically reconnect if Kerberos KDC is unavailable. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/100 > > At the moment, Kerberos libraries contain a memory leak which will > be triggered by periodical reconnecting implemented in this ticket. > > https://bugzilla.redhat.com/show_bug.cgi?id=911110 > https://bugzilla.redhat.com/show_bug.cgi?id=911147 > > -- > Petr^2 Spacek Ack > From bed25248a8c08c2f13027f1dcffecd5ffc60f2dd Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 15 Feb 2013 09:42:41 +0100 > Subject: [PATCH] Periodically reconnect if Kerberos KDC is unavailable. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/100 > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 491817813229f988161f3cedc6c83055040ad3ae..509b5019d1c4b8e330cf21aeefc7ef686e747c19 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -2286,7 +2286,7 @@ force_reconnect: > str_buf(ldap_inst->krb5_keytab)); > UNLOCK(&ldap_inst->kinit_lock); > if (result != ISC_R_SUCCESS) > - return result; > + return ISC_R_NOTCONNECTED; > } > > log_debug(4, "trying interactive bind using %s mechanism", > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Mon Mar 4 14:46:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 04 Mar 2013 15:46:39 +0100 Subject: [Freeipa-devel] [PATCH 0077] Refactor settings subsystem In-Reply-To: <20130304135820.GA2274@redhat.com> References: <5072D551.10703@redhat.com> <51237F79.4020006@redhat.com> <20130304135820.GA2274@redhat.com> Message-ID: <5134B3CF.9020704@redhat.com> Hello, amended patch is attached. On 4.3.2013 14:58, Adam Tkac wrote: > On Tue, Feb 19, 2013 at 02:34:49PM +0100, Petr Spacek wrote: >> >On 8.10.2012 15:29, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > >this patch refactors setting subsystem. After some experimenting I chosen >>> > >simple implementation with static arrays, no RBT trees involved. Speed can be >>> > >improved by reordering items in arrays. >>> > > >>> > >Commit message: >>> > > >>> > > Refactor settings subsystem. >>> > > >>> > > Settings are stored in tree of settings_set_t structures. >>> > > All settings should be accessed only through setting* functions. >>> > > Mutual exclusion during write is done by switching to single >>> > > thread mode. >>> > > >>> > > Setting_get() function doesn't copy strings, so changing the >>> > > original string can lead to obscure bugs. >>> > > This way is okay as long as strings are not changed dynamically >>> > > at run-time. >>> > > >>> > > Unknown setting in configuration file leads to failure rather than >>> > > silent ignoring it. >>> > > >>> > > https://fedorahosted.org/bind-dyndb-ldap/ticket/53 >>> > > https://fedorahosted.org/bind-dyndb-ldap/ticket/81 >> > >> >Re-based & amended & tested patch is attached. The main idea is the same. >> > >>> > >Adam, I'm still looking for way how to handle strings in settings. We have to >>> > >prevent string change/deallocation as long as somebody has a pointer to the >>> > >string (I mean pointer obtained through setting_get("name_of_setting") call). >>> > > >>> > >The only way which I can see is returning setting_string structure like >>> > > >>> > >setting_string struct { >>> > > isc_refcount_t counter; >>> > > isc_mem_t *mctx; >>> > > char *str; >>> > >}; >> > >> >After some poking to isc_task_beginexclusive() I consider the >> >"struct setting_string" idea redundant. >> > >>> > >Caller has to call setting_string_free() when string can be freed. >>> > >Setting_string_free() will decrement counter by one and free whole structure >>> > >if and only if counter reaches 0. >>> > > >>> > >Is it meaningful? Should I separate setting_get_* for each datatype? Or just >>> > >for setting_get_string() and let setting_get() universal for integers and >>> > >booleans? >> > >> >I separated setting_get_bool/uint/str from the universal >> >setting_get() to enable type checks. > Hi Peter, check my comments below, please. I found just some minor issues, the > patch overally looks fine. > > Regards, Adam > >> > From ecff7be859f7c53c167b7ccd4d4d0cc2dfc990a6 Mon Sep 17 00:00:00 2001 >> >From: Petr Spacek >> >Date: Thu, 4 Oct 2012 16:44:16 +0200 >> >Subject: [PATCH] Refactor settings subsystem. >> > >> >Settings are stored in tree of settings_set_t structures. >> >All settings should be accessed only through setting* functions. >> >Mutual exclusion during write is done by switching to single >> >thread mode. >> > >> >setting_get_str() function doesn't copy strings, so original strings >> >have to stay unchanged. >> > >> >Unknown setting and duplicate settings in configuration file >> >lead to failure rather than silent ignoring them. >> > >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/53 >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/81 >> > >> >Signed-off-by: Petr Spacek >> >+/** >> >+ * Get value associated with a setting. Search starts in set of settings >> >+ * passed by caller and continues in parent sets until the setting with defined >> >+ * value is found. >> >+ * >> >+ * @warning >> >+ * This function is not expected to fail because all settings should >> >+ * have default value defined (in topmost set of settings). >> >+ * Caller should always check the return value, regardless this assumption. >> >+ * >> >+ * @param[out] target Type of pointer must agree with requested setting type. >> >+ * @retval ISC_R_SUCCESS Required value was found and target was filled in. >> >+ * @retval ISC_R_NOTFOUND Value is not defined in specified set of >> >+ * settings either in parent sets. >> >+ * @retval ISC_R_UNEXPECTED Type mismatch between _get_type() function and type >> >+ * of setting in settings tree. (I.e. programming >> >+ * error.) >> >+ */ >> >+/* This hack enables type checking for setting_get_ functions. */ >> >+#define setting_getter(func_name, c_type, enum_type, value_name) \ >> >+isc_result_t \ >> >+setting_get_##func_name(const char * const name, \ >> >+ const settings_set_t * const set, \ >> >+ c_type target) \ >> >+{ \ >> >+ isc_result_t result; \ >> >+ setting_t *setting = NULL; \ >> >+ \ >> >+ REQUIRE(name != NULL); \ >> >+ REQUIRE(target != NULL); \ >> >+ \ >> >+ CHECK(setting_find(name, set, ISC_TRUE, ISC_TRUE, &setting)); \ >> >+ \ >> >+ if (setting->type != enum_type) { \ >> >+ log_bug("incompatible setting data type requested " \ >> >+ "for name '%s' in set of settings '%s'", \ >> >+ name, set->name); \ >> >+ return ISC_R_UNEXPECTED; \ >> >+ } \ >> >+ *target = setting->value.value_name; \ >> >+ \ >> >+ return ISC_R_SUCCESS; \ >> >+ \ >> >+cleanup: \ >> >+ log_bug("setting '%s' was not found in settings tree", name); \ >> >+ return result; \ >> >+} >> >+ >> >+setting_getter(uint, isc_uint32_t *, ST_UNSIGNED_INTEGER, value_uint) >> >+setting_getter(str, const char **, ST_STRING, value_char) >> >+setting_getter(bool, isc_boolean_t *, ST_BOOLEAN, value_boolean) > I don't like this part of code much. When you declare setting_get* functions > this way, you end with 3 copies of nearly same code which leads to bloat of > ldap.so. > > In my opinion just one function with switch (enum_type) {} inside which returns > void* might be better. After that we can declare wrappers which will re-type > void* to appropriate type. Example: > > isc_result_t > setting_get(const char *name, const settings_set_t *set, enum_type, void *target); > > #define setting_get_uint(name, set, target) setting_get(name, set, ST_UNSIGNED_INTEGER, target); > > This way we will end with only one copy of setting_get function. Ok. I created one generic setting_get function and added one-line function for each data type. It should allow compiler to do proper type checking and compiler will in-line it, I guess. >> > struct setting { >> > const char *name; >> >- int set; >> >- int has_a_default; >> > setting_type_t type; >> > union { >> >- const char *value_char; >> >- signed int value_sint; >> >- unsigned int value_uint; >> >+ char *value_char; >> >+ isc_uint32_t value_uint; >> > isc_boolean_t value_boolean; >> >- } default_value; >> >- void *target; >> >+ } value; >> >+ isc_boolean_t filled; >> >+ isc_boolean_t allocated_dynamically; > This is quite long name, isn't it? What about "dynamic" or "isdynamic"? I vote for is_dynamic :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0077-3-Refactor-settings-subsystem.patch Type: text/x-patch Size: 90360 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 4 14:59:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 04 Mar 2013 15:59:45 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <51313247.1040801@redhat.com> References: <51313247.1040801@redhat.com> Message-ID: <5134B6E1.7000203@redhat.com> On 03/01/2013 11:57 PM, Rob Crittenden wrote: > Implement the design at http://freeipa.org/page/V3/Recover_DNA_Ranges Could you add the link to the commit message? > Note that this required some new ACIs in cn=config which is not > replicated so the range-set commands won't work against older instances. > It should be gracefully handled though. I think noting this in the man page would be helpful. On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config is added before the entry itself. I didn't test everything as I didn't get the access. > It also doesn't work so well if you try it using a delegated > administrator, see ticket https://fedorahosted.org/freeipa/ticket/3480 > > rob It should be possible to shrink existing ranges, i.e. ones that overlap with themselves: $ ipa-replica-manage dnarange-show vm-075.idm.lab.eng.brq.redhat.com: 1401000005-1401100499 $ ipa-replica-manage dnarange-set vm-075.idm.lab.eng.brq.redhat.com 1401000005-1401100498 New range overlaps the DNA range on vm-075.idm.lab.eng.brq.redhat.com > freeipa-rcrit-1088-dnarange.patch > > >>From 9a654b0b3730f8d9058dfbf25a93a58e1f4939e7 Mon Sep 17 00:00:00 2001 > From: Rob Crittenden > Date: Fri, 1 Mar 2013 15:02:14 -0500 > Subject: [PATCH] Extend ipa-replica-manage to be able to manage DNA ranges. > > Attempt to automatically save DNA ranges when a master is removed. > This is done by trying to find a master that does not yet define > a DNA on-deck range. If one can be found then the range on the deleted > master is added. > > If one cannot be found then it is reported as an error. > > Some validation of the ranges are done to ensure that they do overlap > an IPA local range and do not overlap existing DNA ranges configured > on other masters. The patch adds some trailing whitespace, please trim it. I also found some nitpicks, see below. > > https://fedorahosted.org/freeipa/ticket/3321 > --- [...] > diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage > index 859809bf1c301913c3eb7fc92d1ed58675609b8c..6c0b45620dd2deabfc11ef2249b18205fb23b1fd 100755 > --- a/install/tools/ipa-replica-manage > +++ b/install/tools/ipa-replica-manage [...] > > +def showDNARanges(hostname, master, realm, dirman_passwd, nextrange=False): Style issue: please don't use camel case for functions. [...] > + try: > + repl = replication.ReplicationManager(realm, hostname, dirman_passwd) > + except Exception, e: > + sys.exit("Connection failed: %s" % ipautil.convert_ldap_error(e)) ipaldap should convert LDAP errors to IPA ones, there's no need to call convert_ldap_error. Same in other places. > + dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), repl.suffix) > + try: > + entries = repl.conn.get_entries(dn, repl.conn.SCOPE_ONELEVEL) > + except: Don't use a bare except. Same in other places. [...] > +def setDNARange(hostname, range, realm, dirman_passwd, next_range=False): > + """ > + Given a DNA range try to change it on the designated master. > + > + The range must not overlap with any other ranges and must be within > + one of the IPA local ranges as defined in cn=ranges. > + > + Setting an on-deck range of 0-0 removes the range. > + > + Return True if range was saved, False if not > + > + hostname: hostname of the master to set the range on > + range: The DNA range to set > + realm: our realm, needed to create a connection > + dirman_passwd: the DM password, needed to create a connection Please also mention next_range. [...] > + def range_intersection(s1, s2, r1, r2): > + overlap = xrange(max(s1, r1), min(s2, r2) + 1) > + return len(overlap) > 0 That looks complicated. How about: def ranges_intersect(s1, s2, r1, r2): return max(s1, r1) <= min(s2, r2) [...] > + # Normalize the range > + (dna_next, dna_max) = range.split('-', 1) Can this be done before validate_range, so id doesn't have to be duplicated there? [...] > + dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), ipautil.realm_to_suffix(realm)) I think you should use repl.suffix instead of generating it again. [...] > + # Verify that this is within one of the IPA domain ranges. > + dn = DN(('cn','ranges'),('cn','etc'),repl.suffix) Style issue: no spaces after commas > + try: > + entries = repl.conn.get_entries(dn, repl.conn.SCOPE_ONELEVEL, > + "(objectclass=ipaDomainIDRange)") > + except errors.NotFound, e: > + sys.exit('Unable to load IPA ranges: %s' % e.message) > + > + failed = 0 > + for ent in entries: This loops more than necessary and is somewhat hard to follow. Consider using for-else here: for ...: ... if okay: break else: raise error > + entry_start = int(ent.single_value('ipabaseid')) > + entry_max = entry_start + int(ent.single_value('ipaidrangesize')) > + if not range_intersection(dna_next, dna_max, entry_start, entry_max): I think we want the DNA range to be fully contained in the idrange, rather than just overlap a part of it. Please also adjust the man page when you change this. > + failed += 1 > + > + if failed == len(entries): > + sys.exit("New range does not fit within existing IPA ranges. See ipa help idrange command") > + # If this falls within any of the AD ranges then it fails. > + try: > + entries = repl.conn.get_entries(dn, repl.conn.SCOPE_BASE, > + "(objectclass=ipatrustedaddomainrange)") If we add more types of ranges in the future, should they also be checked? Would (!(objectclass=ipaDomainIDRange)) be more appropriate here? [...] > diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-replica-manage.1 > index 836743902278ec2273f3ce7a7fbf3992370c4828..d23e2566eb9a22c70991cbdca0140eb1d268533c 100644 > --- a/install/tools/man/ipa-replica-manage.1 > +++ b/install/tools/man/ipa-replica-manage.1 > @@ -16,13 +16,13 @@ > .\" > .\" Author: Rob Crittenden > .\" > -.TH "ipa-replica-manage" "1" "Mar 14 2008" "FreeIPA" "FreeIPA Manual Pages" > +.TH "ipa-replica-manage" "1" "Mar 1 2013" "FreeIPA" "FreeIPA Manual Pages" > .SH "NAME" > ipa\-replica\-manage \- Manage an IPA replica > .SH "SYNOPSIS" > -ipa\-replica\-manage [\fIOPTION\fR]... [connect|disconnect|del|list|re\-initialize|force\-sync] > +ipa\-replica\-manage [\fIOPTION\fR]... [COMMAND} Please straighten the curly brace at the end > .SH "DESCRIPTION" > -Manages the replication agreements of an IPA server. > +Manages the replication agreements of an IPA server. The available commands are: > .TP > \fBconnect\fR [SERVER_A] > \- Adds a new replication agreement between SERVER_A/localhost and SERVER_B > @@ -54,6 +54,18 @@ Manages the replication agreements of an IPA server. > \fBlist\-clean\-ruv\fR > \- List all running CLEANALLRUV and abort CLEANALLRUV tasks. > .TP > +\fBipadnarange\-show [SERVER]\fR The subcommand is dnarange-show, no ipa at the start. Same for the others. > +\- List the DNA ranges > +.TP > +\fBipadnarange\-set SERVER x\-y\fR I'd use START-END instead of x-y > +\- Set the DNA range on a master > +.TP > +\fBipadnanextrange\-show [SERVER]\fR > +\- List the next DNA ranges > +.TP > +\fBipadnanextrange\-set SERVER x\-y\fR here too [...] > +The DNA range and on\-deck (next) values can be managed using the dnarange\-set and dnanextrange\-set commands. The rules for managing these ranges are: > +\- The range must overlap a local range as defined by the ipa idrange command. > + > +\- The range cannot overlap the DNA range or on\-deck range on another IPA master. > + > +\- The primary DNA range cannot be removed. > + > +\- An on\-deck range range can be removed by setting it to 0\-0. The assumption is that the range will be manually moved or merged elsewhere. Also, a range can't overlap ranges of trusted AD domains. [...] > index 804d046bf2553daa4aded5c23436a98636e20da0..9076c8396041a95c7ea01ef15aa77991516d30e6 100644 > --- a/ipaserver/install/replication.py > +++ b/ipaserver/install/replication.py > @@ -1308,3 +1308,123 @@ class ReplicationManager(object): > print "This may be safely interrupted with Ctrl+C" > > wait_for_task(self.conn, dn) > + > + def getDNARange(self, hostname): Style issue: please don't use camel-case for methods. > + """ > + Return the DNA range on this server as a tuple, (next, max), or > + (None, None) if no range has been assigned yet. > + """ > + dn = DN(('cn', 'Posix IDs'), ('cn', 'Distributed Numeric Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) I'd put this in a global constant. > + try: > + entry = self.conn.get_entry(dn) > + except Exception, e: > + print "Unable to read DNA configuration: %s" % e.message I think it's better to communicate the error by raising an exception, rather than pretending the range hasn't been set yet. With prints, the error won't appear in logs, and can't be checked by the caller. Same elsewhere. [...] > + if (nextvalue > maxvalue and maxvalue == 1100 and > + nextvalue == 1101 and remaining == 0): What are the magic values? Also this redundantly checks if 1101 > 1100. I'd expect the DNS plugin to ensure that dnaRemainingValues == 0 if nextvalue > maxvalue, do we need to check explicitly? [...] > diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py > index 4a46532642013204720ba467966c59de31a92301..cb9a7e98fd0c486abe5b8b92aff711fa69f23fa9 100644 > --- a/ipaserver/ipaldap.py > +++ b/ipaserver/ipaldap.py > @@ -1775,6 +1775,8 @@ class IPAdmin(LDAPClient): > if removes: > if not force_replace: > modlist.append((ldap.MOD_DELETE, key, removes)) > + elif new_values == []: # delete an empty value > + modlist.append((ldap.MOD_DELETE, key, removes)) I don't understand this change. AFAIK updateEntry/generateModList is only used in ldapupdater now, and it's going away as soon as I can find time to remove it. If you need to change it I'd like to know why. -- Petr? From atkac at redhat.com Mon Mar 4 15:06:25 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 4 Mar 2013 16:06:25 +0100 Subject: [Freeipa-devel] [PATCH 0077] Refactor settings subsystem In-Reply-To: <5134B3CF.9020704@redhat.com> References: <5072D551.10703@redhat.com> <51237F79.4020006@redhat.com> <20130304135820.GA2274@redhat.com> <5134B3CF.9020704@redhat.com> Message-ID: <20130304150624.GA5406@redhat.com> On Mon, Mar 04, 2013 at 03:46:39PM +0100, Petr Spacek wrote: > Hello, > > amended patch is attached. Ack > > On 4.3.2013 14:58, Adam Tkac wrote: > >On Tue, Feb 19, 2013 at 02:34:49PM +0100, Petr Spacek wrote: > >>>On 8.10.2012 15:29, Petr Spacek wrote: > >>>> >Hello, > >>>> > > >>>> >this patch refactors setting subsystem. After some experimenting I chosen > >>>> >simple implementation with static arrays, no RBT trees involved. Speed can be > >>>> >improved by reordering items in arrays. > >>>> > > >>>> >Commit message: > >>>> > > >>>> > Refactor settings subsystem. > >>>> > > >>>> > Settings are stored in tree of settings_set_t structures. > >>>> > All settings should be accessed only through setting* functions. > >>>> > Mutual exclusion during write is done by switching to single > >>>> > thread mode. > >>>> > > >>>> > Setting_get() function doesn't copy strings, so changing the > >>>> > original string can lead to obscure bugs. > >>>> > This way is okay as long as strings are not changed dynamically > >>>> > at run-time. > >>>> > > >>>> > Unknown setting in configuration file leads to failure rather than > >>>> > silent ignoring it. > >>>> > > >>>> > https://fedorahosted.org/bind-dyndb-ldap/ticket/53 > >>>> > https://fedorahosted.org/bind-dyndb-ldap/ticket/81 > >>> > >>>Re-based & amended & tested patch is attached. The main idea is the same. > >>> > >>>> >Adam, I'm still looking for way how to handle strings in settings. We have to > >>>> >prevent string change/deallocation as long as somebody has a pointer to the > >>>> >string (I mean pointer obtained through setting_get("name_of_setting") call). > >>>> > > >>>> >The only way which I can see is returning setting_string structure like > >>>> > > >>>> >setting_string struct { > >>>> > isc_refcount_t counter; > >>>> > isc_mem_t *mctx; > >>>> > char *str; > >>>> >}; > >>> > >>>After some poking to isc_task_beginexclusive() I consider the > >>>"struct setting_string" idea redundant. > >>> > >>>> >Caller has to call setting_string_free() when string can be freed. > >>>> >Setting_string_free() will decrement counter by one and free whole structure > >>>> >if and only if counter reaches 0. > >>>> > > >>>> >Is it meaningful? Should I separate setting_get_* for each datatype? Or just > >>>> >for setting_get_string() and let setting_get() universal for integers and > >>>> >booleans? > >>> > >>>I separated setting_get_bool/uint/str from the universal > >>>setting_get() to enable type checks. > >Hi Peter, check my comments below, please. I found just some minor issues, the > >patch overally looks fine. > > > >Regards, Adam > > > >>> From ecff7be859f7c53c167b7ccd4d4d0cc2dfc990a6 Mon Sep 17 00:00:00 2001 > >>>From: Petr Spacek > >>>Date: Thu, 4 Oct 2012 16:44:16 +0200 > >>>Subject: [PATCH] Refactor settings subsystem. > >>> > >>>Settings are stored in tree of settings_set_t structures. > >>>All settings should be accessed only through setting* functions. > >>>Mutual exclusion during write is done by switching to single > >>>thread mode. > >>> > >>>setting_get_str() function doesn't copy strings, so original strings > >>>have to stay unchanged. > >>> > >>>Unknown setting and duplicate settings in configuration file > >>>lead to failure rather than silent ignoring them. > >>> > >>>https://fedorahosted.org/bind-dyndb-ldap/ticket/53 > >>>https://fedorahosted.org/bind-dyndb-ldap/ticket/81 > >>> > >>>Signed-off-by: Petr Spacek > > > >>>+/** > >>>+ * Get value associated with a setting. Search starts in set of settings > >>>+ * passed by caller and continues in parent sets until the setting with defined > >>>+ * value is found. > >>>+ * > >>>+ * @warning > >>>+ * This function is not expected to fail because all settings should > >>>+ * have default value defined (in topmost set of settings). > >>>+ * Caller should always check the return value, regardless this assumption. > >>>+ * > >>>+ * @param[out] target Type of pointer must agree with requested setting type. > >>>+ * @retval ISC_R_SUCCESS Required value was found and target was filled in. > >>>+ * @retval ISC_R_NOTFOUND Value is not defined in specified set of > >>>+ * settings either in parent sets. > >>>+ * @retval ISC_R_UNEXPECTED Type mismatch between _get_type() function and type > >>>+ * of setting in settings tree. (I.e. programming > >>>+ * error.) > >>>+ */ > >>>+/* This hack enables type checking for setting_get_ functions. */ > >>>+#define setting_getter(func_name, c_type, enum_type, value_name) \ > >>>+isc_result_t \ > >>>+setting_get_##func_name(const char * const name, \ > >>>+ const settings_set_t * const set, \ > >>>+ c_type target) \ > >>>+{ \ > >>>+ isc_result_t result; \ > >>>+ setting_t *setting = NULL; \ > >>>+ \ > >>>+ REQUIRE(name != NULL); \ > >>>+ REQUIRE(target != NULL); \ > >>>+ \ > >>>+ CHECK(setting_find(name, set, ISC_TRUE, ISC_TRUE, &setting)); \ > >>>+ \ > >>>+ if (setting->type != enum_type) { \ > >>>+ log_bug("incompatible setting data type requested " \ > >>>+ "for name '%s' in set of settings '%s'", \ > >>>+ name, set->name); \ > >>>+ return ISC_R_UNEXPECTED; \ > >>>+ } \ > >>>+ *target = setting->value.value_name; \ > >>>+ \ > >>>+ return ISC_R_SUCCESS; \ > >>>+ \ > >>>+cleanup: \ > >>>+ log_bug("setting '%s' was not found in settings tree", name); \ > >>>+ return result; \ > >>>+} > >>>+ > >>>+setting_getter(uint, isc_uint32_t *, ST_UNSIGNED_INTEGER, value_uint) > >>>+setting_getter(str, const char **, ST_STRING, value_char) > >>>+setting_getter(bool, isc_boolean_t *, ST_BOOLEAN, value_boolean) > >I don't like this part of code much. When you declare setting_get* functions > >this way, you end with 3 copies of nearly same code which leads to bloat of > >ldap.so. > > > >In my opinion just one function with switch (enum_type) {} inside which returns > >void* might be better. After that we can declare wrappers which will re-type > >void* to appropriate type. Example: > > > >isc_result_t > >setting_get(const char *name, const settings_set_t *set, enum_type, void *target); > > > >#define setting_get_uint(name, set, target) setting_get(name, set, ST_UNSIGNED_INTEGER, target); > > > >This way we will end with only one copy of setting_get function. > > Ok. I created one generic setting_get function and added one-line > function for each data type. It should allow compiler to do proper > type checking and compiler will in-line it, I guess. > > > >>> struct setting { > >>> const char *name; > >>>- int set; > >>>- int has_a_default; > >>> setting_type_t type; > >>> union { > >>>- const char *value_char; > >>>- signed int value_sint; > >>>- unsigned int value_uint; > >>>+ char *value_char; > >>>+ isc_uint32_t value_uint; > >>> isc_boolean_t value_boolean; > >>>- } default_value; > >>>- void *target; > >>>+ } value; > >>>+ isc_boolean_t filled; > >>>+ isc_boolean_t allocated_dynamically; > >This is quite long name, isn't it? What about "dynamic" or "isdynamic"? > > I vote for is_dynamic :-) > > -- > Petr^2 Spacek > From 7e07339b04656ea1c1f0c22f900d37937e53c475 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 4 Oct 2012 16:44:16 +0200 > Subject: [PATCH] Refactor settings subsystem. > > Settings are stored in tree of settings_set_t structures. > All settings should be accessed only through setting* functions. > Mutual exclusion during write is done by switching to single > thread mode. > > setting_get_str() function doesn't copy strings, so original strings > have to stay unchanged. > > Unknown setting and duplicate settings in configuration file > lead to failure rather than silent ignoring them. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/53 > https://fedorahosted.org/bind-dyndb-ldap/ticket/81 > > Signed-off-by: Petr Spacek > --- > src/cache.c | 32 +-- > src/cache.h | 4 +- > src/ldap_entry.c | 6 +- > src/ldap_entry.h | 2 +- > src/ldap_helper.c | 785 +++++++++++++++++++++++++++++----------------------- > src/ldap_helper.h | 5 + > src/settings.c | 673 ++++++++++++++++++++++++++++++++++++-------- > src/settings.h | 86 ++++-- > src/zone_manager.c | 27 +- > src/zone_register.c | 82 +++++- > src/zone_register.h | 9 +- > 11 files changed, 1171 insertions(+), 540 deletions(-) > > diff --git a/src/cache.c b/src/cache.c > index fd57fd92eb35dcbbd5c1e1911a93730624e30002..b475d2319137845b7f59fa6d15b21847199554cd 100644 > --- a/src/cache.c > +++ b/src/cache.c > @@ -38,11 +38,12 @@ > #include "util.h" > > struct ldap_cache { > - isc_mutex_t mutex; /* TODO: RWLOCK? */ > - isc_mem_t *mctx; > - dns_rbt_t *rbt; > - const isc_interval_t *cache_ttl; /* pointer to LDAP instance */ > - const isc_boolean_t *psearch; /* pointer to LDAP instance */ > + isc_mutex_t mutex; /* TODO: RWLOCK? */ > + isc_mem_t *mctx; > + dns_rbt_t *rbt; > + /* Values for "fast path" - copied from settings_set_t structure. */ > + isc_interval_t cache_ttl; > + isc_boolean_t psearch; > }; > > typedef struct { > @@ -78,9 +79,9 @@ cache_node_create(ldap_cache_t *cache, cache_node_t **nodep) > isc_mem_attach(cache->mctx, &node->mctx); > ZERO_PTR(&node->rdatalist); > /* Do not set the ttl when psearch is enabled. */ > - if (*cache->psearch == ISC_FALSE) > + if (cache->psearch == ISC_FALSE) > CHECK(isc_time_nowplusinterval(&node->valid_until, > - cache->cache_ttl)); > + &cache->cache_ttl)); > > *nodep = node; > return ISC_R_SUCCESS; > @@ -91,33 +92,28 @@ cleanup: > return result; > } > > -/** > - * @param[in] cache_ttl ISC interval in LDAP instance shared by all caches > - * @param[in] psearch boolean in LDAP instance shared by all caches > - */ > isc_result_t > -new_ldap_cache(isc_mem_t *mctx, const isc_interval_t *cache_ttl, > - const isc_boolean_t *psearch, ldap_cache_t **cachep) > +new_ldap_cache(isc_mem_t *mctx, settings_set_t *set, ldap_cache_t **cachep) > { > isc_result_t result; > ldap_cache_t *cache = NULL; > + isc_uint32_t cache_ttl_int; > > - REQUIRE(cache_ttl != NULL); > - REQUIRE(psearch != NULL); > REQUIRE(cachep != NULL && *cachep == NULL); > > CHECKED_MEM_GET_PTR(mctx, cache); > ZERO_PTR(cache); > isc_mem_attach(mctx, &cache->mctx); > > - cache->cache_ttl = cache_ttl; > - if (!isc_interval_iszero(cache_ttl)) { > + CHECK(setting_get_bool("psearch", set, &cache->psearch)); > + CHECK(setting_get_uint("cache_ttl", set, &cache_ttl_int)); > + isc_interval_set(&cache->cache_ttl, cache_ttl_int, 0); > + if (cache_ttl_int) { > CHECK(dns_rbt_create(mctx, cache_node_deleter, NULL, > &cache->rbt)); > CHECK(isc_mutex_init(&cache->mutex)); > } > > - cache->psearch = psearch; > *cachep = cache; > return ISC_R_SUCCESS; > > diff --git a/src/cache.h b/src/cache.h > index 7c7e69b305d3021f154ebb17d5b879ba8f34590e..567d176da0e9e31e96fdae869c10643cdc03c27c 100644 > --- a/src/cache.h > +++ b/src/cache.h > @@ -23,15 +23,15 @@ > #define _LD_CACHE_H_ > > #include "types.h" > +#include "settings.h" > > typedef struct ldap_cache ldap_cache_t; > > /* > * Create a new cache. > */ > isc_result_t > -new_ldap_cache(isc_mem_t *mctx, const isc_interval_t *cache_ttl, > - const isc_boolean_t *psearch, ldap_cache_t **cachep); > +new_ldap_cache(isc_mem_t *mctx, settings_set_t *set, ldap_cache_t **cachep); > > /* > * Free all resources used up by the cache. > diff --git a/src/ldap_entry.c b/src/ldap_entry.c > index 509995cd682956dc9afb58e04716f8bb63014f09..d32dc86ecc3af4866105bc96a6012d0ee964f4f5 100644 > --- a/src/ldap_entry.c > +++ b/src/ldap_entry.c > @@ -349,7 +349,7 @@ ldap_entry_nextrdtype(ldap_entry_t *entry, ldap_attribute_t **attrp, > } > > isc_result_t > -ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > +ldap_entry_getfakesoa(ldap_entry_t *entry, const char *fake_mname, > ld_string_t *target) > { > isc_result_t result = ISC_R_NOTFOUND; > @@ -367,9 +367,9 @@ ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > REQUIRE(target != NULL); > > str_clear(target); > - if (str_len(fake_mname) > 0) { > + if (strlen(fake_mname) > 0) { > i = 1; > - CHECK(str_cat(target, fake_mname)); > + CHECK(str_cat_char(target, fake_mname)); > CHECK(str_cat_char(target, " ")); > } > for (; soa_attrs[i] != NULL; i++) { > diff --git a/src/ldap_entry.h b/src/ldap_entry.h > index 02923a8735c20bc318fdf011b434127c9c52a53b..5a027e672b7591ae57551c175764e7517acea758 100644 > --- a/src/ldap_entry.h > +++ b/src/ldap_entry.h > @@ -107,7 +107,7 @@ ldap_entry_nextrdtype(ldap_entry_t *entry, ldap_attribute_t **attrp, > dns_rdatatype_t *rdtype); > > isc_result_t > -ldap_entry_getfakesoa(ldap_entry_t *entry, const ld_string_t *fake_mname, > +ldap_entry_getfakesoa(ldap_entry_t *entry, const char *fake_mname, > ld_string_t *target); > > /* > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 0c9e87911ef196cf89bb1f2022235b7b19609b14..c5c8245ecd664f038781fc98f4b5756ceff87c2e 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -157,32 +157,13 @@ struct ldap_instance { > /* krb5 kinit mutex */ > isc_mutex_t kinit_lock; > > - /* Settings. */ > - ld_string_t *uri; > - ld_string_t *base; > - unsigned int connections; > - unsigned int reconnect_interval; > - unsigned int timeout; > - ldap_auth_t auth_method; > - ld_string_t *bind_dn; > - ld_string_t *password; > - ld_string_t *krb5_principal; > - ld_string_t *sasl_mech; > - ld_string_t *sasl_user; > - ld_string_t *sasl_auth_name; > - ld_string_t *sasl_realm; > - ld_string_t *sasl_password; > - ld_string_t *krb5_keytab; > - ld_string_t *fake_mname; > - isc_boolean_t psearch; > - isc_interval_t cache_ttl; > - ld_string_t *ldap_hostname; > isc_task_t *task; > isc_thread_t watcher; > isc_boolean_t exiting; > - isc_boolean_t sync_ptr; > - isc_boolean_t dyn_update; > - isc_boolean_t serial_autoincrement; > + > + /* Settings. */ > + settings_set_t *local_settings; > + settings_set_t *global_settings; > dns_forwarders_t orig_global_forwarders; /* from named.conf */ > }; > > @@ -250,6 +231,47 @@ struct ldap_psearchevent { > int chgtype; > }; > > +extern const settings_set_t const settings_default_set; > + > +/** Local configuration file */ > +static const setting_t settings_local_default[] = { > + { "uri", no_default_string }, > + { "connections", no_default_uint }, > + { "reconnect_interval", no_default_uint }, > + { "timeout", no_default_uint }, > + { "cache_ttl", no_default_uint }, > + { "base", no_default_string }, > + { "auth_method", no_default_string }, > + { "auth_method_enum", no_default_uint }, > + { "bind_dn", no_default_string }, > + { "password", no_default_string }, > + { "krb5_principal", no_default_string }, > + { "sasl_mech", no_default_string }, > + { "sasl_user", no_default_string }, > + { "sasl_auth_name", no_default_string }, > + { "sasl_realm", no_default_string }, > + { "sasl_password", no_default_string }, > + { "krb5_keytab", no_default_string }, > + { "fake_mname", no_default_string }, > + { "zone_refresh", no_default_uint }, > + { "psearch", no_default_boolean }, > + { "ldap_hostname", no_default_string }, > + { "sync_ptr", no_default_boolean }, > + { "dyn_update", no_default_boolean }, > + { "serial_autoincrement", no_default_boolean }, > + { "verbose_checks", no_default_boolean }, > + end_of_settings > +}; > + > +/** Global settings from idnsConfig object. */ > +static setting_t settings_global_default[] = { > + { "dyn_update", no_default_boolean }, > + { "sync_ptr", no_default_boolean }, > + { "zone_refresh", no_default_uint }, > +/* { "psearch", no_default_boolean }, unsupported */ > + end_of_settings > +}; > + > /* > * Forward declarations. > */ > @@ -264,14 +286,14 @@ static isc_result_t findrdatatype_or_create(isc_mem_t *mctx, > dns_rdatatype_t rdtype, dns_ttl_t ttl, dns_rdatalist_t **rdlistp); > static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult, > dns_name_t *origin, ldap_entry_t *entry, > - ldapdb_rdatalist_t *rdatalist, const ld_string_t *fake_mname); > + ldapdb_rdatalist_t *rdatalist, const char *fake_mname); > static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_qresult_t *qresult, > dns_rdataclass_t rdclass, dns_rdatatype_t rdtype, > dns_name_t *origin, const char *rdata_text, > dns_rdata_t **rdatap); > static isc_result_t ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > ldap_qresult_t *qresult, dns_name_t *origin, > - const ld_string_t *fake_mname, ld_string_t *buf, > + const char *fake_mname, ld_string_t *buf, > ldapdb_rdatalist_t *rdatalist); > static inline isc_result_t ldap_get_zone_serial(ldap_instance_t *inst, > dns_name_t *zone_name, isc_uint32_t *serial); > @@ -332,43 +354,136 @@ static void psearch_update(ldap_instance_t *inst, ldap_entry_t *entry, > static isc_threadresult_t > ldap_psearch_watcher(isc_threadarg_t arg); > > +#define PRINT_BUFF_SIZE 10 /* for unsigned int 2^32 */ > +isc_result_t > +validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) { > + isc_result_t result; > + > + isc_boolean_t psearch; > + isc_boolean_t serial_autoincrement; > + isc_uint32_t uint; > + const char *sasl_mech = NULL; > + const char *sasl_user = NULL; > + const char *krb5_principal = NULL; > + ld_string_t *buff = NULL; > + > + char print_buff[PRINT_BUFF_SIZE]; > + const char *auth_method_str = NULL; > + ldap_auth_t auth_method_enum = AUTH_INVALID; > + > + /* Set timer for deadlock detection inside semaphore_wait_timed . */ > + CHECK(setting_get_uint("timeout", set, &uint)); > + if (semaphore_wait_timeout.seconds < uint*SEM_WAIT_TIMEOUT_MUL) > + semaphore_wait_timeout.seconds = uint*SEM_WAIT_TIMEOUT_MUL; > + > + CHECK(setting_get_bool("psearch", set, &psearch)); > + CHECK(setting_get_uint("connections", set, &uint)); > + if (!psearch && uint < 1) { > + log_error("zone refresh mode requires one connection at least"); > + CLEANUP_WITH(ISC_R_RANGE); > + } > + else if (psearch && uint < 2) { > + log_error("persistent search mode requires two connections " > + "at least"); > + /* watcher needs one and update_*() requests second connection */ > + CLEANUP_WITH(ISC_R_RANGE); > + } > + > + CHECK(setting_get_bool("serial_autoincrement", set, &serial_autoincrement)); > + if (serial_autoincrement && !psearch) { > + log_error("SOA serial number auto-increment feature requires " > + "persistent search"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + > + CHECK(setting_get_uint("zone_refresh", set, &uint)); > + if (uint != 0 && psearch) { > + log_error("zone refresh and persistent search " > + "cannot be enabled at same time"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + > + /* Select authentication method. */ > + CHECK(setting_get_str("auth_method", set, &auth_method_str)); > + auth_method_enum = AUTH_INVALID; > + for (int i = 0; supported_ldap_auth[i].name != NULL; i++) { > + if (!strcasecmp(auth_method_str, supported_ldap_auth[i].name)) { > + auth_method_enum = supported_ldap_auth[i].value; > + break; > + } > + } > + if (auth_method_enum == AUTH_INVALID) { > + log_error("unknown authentication method '%s'", > + auth_method_str); > + CLEANUP_WITH(ISC_R_FAILURE); > + } > + CHECK(isc_string_printf(print_buff, PRINT_BUFF_SIZE, "%u", auth_method_enum)); > + CHECK(setting_set("auth_method_enum", inst->local_settings, print_buff, > + inst->task)); > + > + /* check we have the right data when SASL/GSSAPI is selected */ > + CHECK(setting_get_str("sasl_mech", set, &sasl_mech)); > + CHECK(setting_get_str("krb5_principal", set, &krb5_principal)); > + CHECK(setting_get_str("sasl_user", set, &sasl_user)); > + > + if ((auth_method_enum == AUTH_SASL) && > + (strcasecmp(sasl_mech, "GSSAPI") == 0)) { > + if ((krb5_principal == NULL) || (strlen(krb5_principal) == 0)) { > + if ((sasl_user == NULL) || (strlen(sasl_user) == 0)) { > + char hostname[HOST_NAME_MAX]; > + if (gethostname(hostname, HOST_NAME_MAX) != 0) { > + log_error("SASL mech GSSAPI defined " > + "but krb5_principal and " > + "sasl_user are empty and" > + "gethostname() failed"); > + CLEANUP_WITH(ISC_R_FAILURE); > + } else { > + CHECK(str_sprintf(buff, > + "DNS/%s", hostname)); > + log_debug(2, "SASL mech GSSAPI defined " > + "but krb5_principal and " > + "sasl_user are empty, using " > + "default '%s'", > + str_buf(buff)); > + CHECK(setting_set("krb5_principal", set, > + str_buf(buff), > + inst->task)); > + } > + } else { > + CHECK(setting_set("krb5_principal", set, > + sasl_user, > + inst->task)); > + } > + } > + } else if (auth_method_enum == AUTH_SASL) { > + log_info("SASL mechanisms other than GSSAPI+Kerberos " > + "are untested; expect problems"); > + } > + > + if (settings_set_isfilled(set) != ISC_TRUE) > + result = ISC_R_FAILURE; > + > +cleanup: > + if (result != ISC_R_SUCCESS) > + log_error_r("LDAP config validation failed for database '%s'", > + inst->db_name); > + return result; > +} > +#undef PRINT_BUFF_SIZE > + > +#define PRINT_BUFF_SIZE 255 > isc_result_t > new_ldap_instance(isc_mem_t *mctx, const char *db_name, > const char * const *argv, dns_dyndb_arguments_t *dyndb_args, > isc_task_t *task, ldap_instance_t **ldap_instp) > { > - unsigned int i; > isc_result_t result; > ldap_instance_t *ldap_inst; > dns_view_t *view = NULL; > - ld_string_t *auth_method_str = NULL; > dns_forwarders_t *orig_global_forwarders = NULL; > - isc_uint32_t cache_ttl_seconds; > - setting_t ldap_settings[] = { > - { "uri", no_default_string }, > - { "connections", default_uint(2) }, > - { "reconnect_interval", default_uint(60) }, > - { "timeout", default_uint(10) }, > - { "base", no_default_string }, > - { "auth_method", default_string("none") }, > - { "bind_dn", default_string("") }, > - { "password", default_string("") }, > - { "krb5_principal", default_string("") }, > - { "sasl_mech", default_string("GSSAPI") }, > - { "sasl_user", default_string("") }, > - { "sasl_auth_name", default_string("") }, > - { "sasl_realm", default_string("") }, > - { "sasl_password", default_string("") }, > - { "krb5_keytab", default_string("") }, > - { "fake_mname", default_string("") }, > - { "psearch", default_boolean(ISC_FALSE) }, > - { "cache_ttl", default_uint(120) }, > - { "ldap_hostname", default_string("") }, > - { "sync_ptr", default_boolean(ISC_FALSE) }, > - { "dyn_update", default_boolean(ISC_FALSE) }, > - { "serial_autoincrement", default_boolean(ISC_FALSE) }, > - end_of_settings > - }; > + isc_boolean_t psearch; > + isc_uint32_t connections; > + char settings_name[PRINT_BUFF_SIZE]; > > REQUIRE(ldap_instp != NULL && *ldap_instp == NULL); > > @@ -381,123 +496,35 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > dns_view_attach(view, &ldap_inst->view); > ldap_inst->zmgr = dns_dyndb_get_zonemgr(dyndb_args); > ISC_LIST_INIT(ldap_inst->orig_global_forwarders.addrs); > - > - CHECK(zr_create(mctx, &ldap_inst->zone_register)); > - > - CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > - > - CHECK(str_new(mctx, &auth_method_str)); > - CHECK(str_new(mctx, &ldap_inst->uri)); > - CHECK(str_new(mctx, &ldap_inst->base)); > - CHECK(str_new(mctx, &ldap_inst->bind_dn)); > - CHECK(str_new(mctx, &ldap_inst->password)); > - CHECK(str_new(mctx, &ldap_inst->krb5_principal)); > - CHECK(str_new(mctx, &ldap_inst->sasl_mech)); > - CHECK(str_new(mctx, &ldap_inst->sasl_user)); > - CHECK(str_new(mctx, &ldap_inst->sasl_auth_name)); > - CHECK(str_new(mctx, &ldap_inst->sasl_realm)); > - CHECK(str_new(mctx, &ldap_inst->sasl_password)); > - CHECK(str_new(mctx, &ldap_inst->krb5_keytab)); > - CHECK(str_new(mctx, &ldap_inst->fake_mname)); > - CHECK(str_new(mctx, &ldap_inst->ldap_hostname)); > - > - i = 0; > - ldap_settings[i++].target = ldap_inst->uri; > - ldap_settings[i++].target = &ldap_inst->connections; > - ldap_settings[i++].target = &ldap_inst->reconnect_interval; > - ldap_settings[i++].target = &ldap_inst->timeout; > - ldap_settings[i++].target = ldap_inst->base; > - ldap_settings[i++].target = auth_method_str; > - ldap_settings[i++].target = ldap_inst->bind_dn; > - ldap_settings[i++].target = ldap_inst->password; > - ldap_settings[i++].target = ldap_inst->krb5_principal; > - ldap_settings[i++].target = ldap_inst->sasl_mech; > - ldap_settings[i++].target = ldap_inst->sasl_user; > - ldap_settings[i++].target = ldap_inst->sasl_auth_name; > - ldap_settings[i++].target = ldap_inst->sasl_realm; > - ldap_settings[i++].target = ldap_inst->sasl_password; > - ldap_settings[i++].target = ldap_inst->krb5_keytab; > - ldap_settings[i++].target = ldap_inst->fake_mname; > - ldap_settings[i++].target = &ldap_inst->psearch; > - ldap_settings[i++].target = &cache_ttl_seconds; > - ldap_settings[i++].target = ldap_inst->ldap_hostname; > - ldap_settings[i++].target = &ldap_inst->sync_ptr; > - ldap_settings[i++].target = &ldap_inst->dyn_update; > - ldap_settings[i++].target = &ldap_inst->serial_autoincrement; > - CHECK(set_settings(ldap_settings, argv)); > - isc_interval_set(&ldap_inst->cache_ttl, cache_ttl_seconds, 0); > - > - /* Set timer for deadlock detection inside semaphore_wait_timed . */ > - if (semaphore_wait_timeout.seconds < ldap_inst->timeout*SEM_WAIT_TIMEOUT_MUL) > - semaphore_wait_timeout.seconds = ldap_inst->timeout*SEM_WAIT_TIMEOUT_MUL; > - > - /* Validate and check settings. */ > - str_toupper(ldap_inst->sasl_mech); > - if (ldap_inst->connections < 1) { > - log_error("at least one connection is required"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - /* Select authentication method. */ > - ldap_inst->auth_method = AUTH_INVALID; > - for (i = 0; supported_ldap_auth[i].name != NULL; i++) { > - if (!str_casecmp_char(auth_method_str, > - supported_ldap_auth[i].name)) { > - ldap_inst->auth_method = supported_ldap_auth[i].value; > - break; > - } > - } > - if (ldap_inst->auth_method == AUTH_INVALID) { > - log_error("unknown authentication method '%s'", > - str_buf(auth_method_str)); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > - > - /* check we have the right data when SASL/GSSAPI is selected */ > - if ((ldap_inst->auth_method == AUTH_SASL) && > - (str_casecmp_char(ldap_inst->sasl_mech, "GSSAPI") == 0)) { > - if ((ldap_inst->krb5_principal == NULL) || > - (str_len(ldap_inst->krb5_principal) == 0)) { > - if ((ldap_inst->sasl_user == NULL) || > - (str_len(ldap_inst->sasl_user) == 0)) { > - char hostname[255]; > - if (gethostname(hostname, 255) != 0) { > - log_error("SASL mech GSSAPI defined but krb5_principal" > - "and sasl_user are empty. Could not get hostname"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } else { > - CHECK(str_sprintf(ldap_inst->krb5_principal, > - "DNS/%s", hostname)); > - log_debug(2, "SASL mech GSSAPI defined but krb5_principal" > - "and sasl_user are empty, using default %s", > - str_buf(ldap_inst->krb5_principal)); > - } > - } else { > - str_copy(ldap_inst->krb5_principal, ldap_inst->sasl_user); > - } > - } > - } > - > ldap_inst->task = task; > + ldap_inst->watcher = 0; > > - if (ldap_inst->psearch && ldap_inst->connections < 2) { > - /* watcher needs one and update_*() will request second */ > - log_error("psearch needs at least 2 connections, " > - "increasing limit"); > - ldap_inst->connections = 2; > - } > - if (ldap_inst->serial_autoincrement == ISC_TRUE > - && ldap_inst->psearch != ISC_TRUE) { > - log_error("SOA serial number auto-increment feature requires " > - "persistent search"); > - result = ISC_R_FAILURE; > - goto cleanup; > - } > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_LOCAL " for database %s", > + db_name); > + CHECK(settings_set_create(mctx, settings_local_default, > + sizeof(settings_local_default), settings_name, > + &settings_default_set, &ldap_inst->local_settings)); > > - CHECK(ldap_pool_create(mctx, ldap_inst->connections, &ldap_inst->pool)); > - CHECK(ldap_pool_connect(ldap_inst->pool, ldap_inst)); > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_GLOBAL " for database %s", > + db_name); > + CHECK(settings_set_create(mctx, settings_global_default, > + sizeof(settings_global_default), settings_name, > + ldap_inst->local_settings, &ldap_inst->global_settings)); > + > + CHECK(settings_set_fill(ldap_inst->local_settings, argv, task)); > + CHECK(validate_local_instance_settings(ldap_inst, ldap_inst->local_settings)); > + if (settings_set_isfilled(ldap_inst->global_settings) != ISC_TRUE) > + CLEANUP_WITH(ISC_R_FAILURE); > + > + CHECK(setting_get_bool("psearch", ldap_inst->local_settings, &psearch)); > + CHECK(setting_get_uint("connections", ldap_inst->local_settings, &connections)); > + > + CHECK(zr_create(mctx, ldap_inst->global_settings, > + &ldap_inst->zone_register)); > + > + CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > > /* copy global forwarders setting for configuration roll back in > * configure_zone_forwarders() */ > @@ -521,12 +548,14 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > } else if (result == ISC_R_NOTFOUND) { > /* global forwarders are not configured */ > ldap_inst->orig_global_forwarders.fwdpolicy = dns_fwdpolicy_none; > - result = ISC_R_SUCCESS; > } else { > goto cleanup; > } > > - if (ldap_inst->psearch) { > + CHECK(ldap_pool_create(mctx, connections, &ldap_inst->pool)); > + CHECK(ldap_pool_connect(ldap_inst->pool, ldap_inst)); > + > + if (psearch) { > /* Start the watcher thread */ > result = isc_thread_create(ldap_psearch_watcher, ldap_inst, > &ldap_inst->watcher); > @@ -542,10 +571,9 @@ cleanup: > else > *ldap_instp = ldap_inst; > > - str_destroy(&auth_method_str); > - > return result; > } > +#undef PRINT_BUFF_SIZE > > void > destroy_ldap_instance(ldap_instance_t **ldap_instp) > @@ -627,7 +655,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > dns_rbtnodechain_invalidate(&chain); > > /* TODO: Terminate psearch watcher sooner? */ > - if (ldap_inst->psearch && ldap_inst->watcher != 0) { > + if (ldap_inst->watcher != 0) { > ldap_inst->exiting = ISC_TRUE; > /* > * Wake up the watcher thread. This might look like a hack > @@ -644,21 +672,6 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > } > > ldap_pool_destroy(&ldap_inst->pool); > - > - str_destroy(&ldap_inst->uri); > - str_destroy(&ldap_inst->base); > - str_destroy(&ldap_inst->bind_dn); > - str_destroy(&ldap_inst->password); > - str_destroy(&ldap_inst->krb5_principal); > - str_destroy(&ldap_inst->sasl_mech); > - str_destroy(&ldap_inst->sasl_user); > - str_destroy(&ldap_inst->sasl_auth_name); > - str_destroy(&ldap_inst->sasl_realm); > - str_destroy(&ldap_inst->sasl_password); > - str_destroy(&ldap_inst->krb5_keytab); > - str_destroy(&ldap_inst->fake_mname); > - str_destroy(&ldap_inst->ldap_hostname); > - > dns_view_detach(&ldap_inst->view); > > DESTROYLOCK(&ldap_inst->kinit_lock); > @@ -671,6 +684,9 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > SAFE_MEM_PUT_PTR(ldap_inst->mctx, addr); > } > > + settings_set_free(&ldap_inst->global_settings); > + settings_set_free(&ldap_inst->local_settings); > + > MEM_PUT_AND_DETACH(ldap_inst); > > *ldap_instp = NULL; > @@ -1157,64 +1173,62 @@ static isc_result_t > ldap_parse_configentry(ldap_entry_t *entry, ldap_instance_t *inst) > { > isc_result_t result; > - ldap_valuelist_t values; > - isc_boolean_t sync_ptr_new; > isc_timer_t *timer_inst; > isc_interval_t timer_interval; > isc_uint32_t interval_sec; > isc_timertype_t timer_type; > > - /* BIND functions are thread safe, lock only ldap instance 'inst'. */ > + /* BIND functions are thread safe, ldap instance 'inst' is locked > + * inside setting* functions. */ > > log_debug(3, "Parsing configuration object"); > > /* idnsForwardPolicy change is handled by configure_zone_forwarders() */ > result = configure_zone_forwarders(entry, inst, dns_rootname); > if (result != ISC_R_SUCCESS && result != ISC_R_DISABLED) { > log_error_r("global forwarder could not be set up"); > } > > - result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > - if (result == ISC_R_SUCCESS) { > - log_debug(2, "Setting global AllowSyncPTR = %s", HEAD(values)->value); > - sync_ptr_new = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > + result = setting_update_from_ldap_entry("dyn_update", > + inst->global_settings, > + "idnsAllowDynUpdate", > + entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > > - if (inst->sync_ptr != sync_ptr_new) { /* lock BIND only if necessary */ > - result = isc_task_beginexclusive(inst->task); > - RUNTIME_CHECK(result == ISC_R_SUCCESS || > - result == ISC_R_LOCKBUSY); > - inst->sync_ptr = sync_ptr_new; > - if (result == ISC_R_SUCCESS) { > - isc_task_endexclusive(inst->task); > - } > - } > - } > + result = setting_update_from_ldap_entry("sync_ptr", > + inst->global_settings, > + "idnsAllowSyncPTR", > + entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > > - result = ldap_entry_getvalues(entry, "idnsZoneRefresh", &values); > + result = setting_update_from_ldap_entry("zone_refresh", > + inst->global_settings, > + "idnsZoneRefresh", > + entry, inst->task); > if (result == ISC_R_SUCCESS) { > - log_debug(2, "Setting global ZoneRefresh timer = %s", HEAD(values)->value); > - RUNTIME_CHECK(manager_get_db_timer(inst->db_name, &timer_inst) == ISC_R_SUCCESS); > - > - result = isc_parse_uint32(&interval_sec, HEAD(values)->value, 10); > - if (result != ISC_R_SUCCESS) { > - log_error("Could not parse ZoneRefresh interval"); > - goto cleanup; > - } > + RUNTIME_CHECK(manager_get_db_timer(inst->db_name, &timer_inst) > + == ISC_R_SUCCESS); > + CHECK(setting_get_uint("zone_refresh", inst->global_settings, > + &interval_sec)); > isc_interval_set(&timer_interval, interval_sec, 0); > /* update interval only, not timer type */ > timer_type = isc_timer_gettype(timer_inst); > result = isc_timer_reset(timer_inst, timer_type, NULL, > &timer_interval, ISC_TRUE); > if (result != ISC_R_SUCCESS) { > - log_error("Could not adjust ZoneRefresh timer"); > + log_error_r("could not adjust ZoneRefresh timer"); > goto cleanup; > } > + } else if (result != ISC_R_IGNORE) { > + goto cleanup; > } > > cleanup: > /* Configuration errors are not fatal. */ > - return ISC_R_SUCCESS; > + /* TODO: log something? */ > + return ISC_R_SUCCESS; > } > > /* Parse the zone entry */ > @@ -1237,6 +1251,8 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > ldapdb_rdatalist_t rdatalist; > isc_boolean_t zone_dynamic = ISC_FALSE; > ldap_cache_t *cache = NULL; > + settings_set_t *zone_settings = NULL; > + isc_boolean_t serial_autoincrement; > > REQUIRE(entry != NULL); > REQUIRE(inst != NULL); > @@ -1283,13 +1299,24 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > result = zr_get_zone_ptr(inst->zone_register, &name, &zone); > if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > CHECK(create_zone(inst, &name, &zone)); > - CHECK(zr_add_zone(inst->zone_register, zone, dn, > - &inst->cache_ttl, &inst->psearch)); > + CHECK(zr_add_zone(inst->zone_register, zone, dn)); > publish = ISC_TRUE; > log_debug(2, "created zone %p: %s", zone, dn); > } else if (result != ISC_R_SUCCESS) > goto cleanup; > > + CHECK(zr_get_zone_settings(inst->zone_register, &name, &zone_settings)); > + > + result = setting_update_from_ldap_entry("dyn_update", zone_settings, > + "idnsAllowDynUpdate", entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > + > + result = setting_update_from_ldap_entry("sync_ptr", zone_settings, > + "idnsAllowSyncPTR", entry, inst->task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > + > log_debug(2, "Setting SSU table for %p: %s", zone, dn); > /* Get the update policy and update the zone with it. */ > result = ldap_entry_getvalues(entry, "idnsUpdatePolicy", &values); > @@ -1372,7 +1399,9 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > CHECK(ldap_get_zone_serial(inst, &name, &ldap_serial)); > CHECK(zr_get_zone_serial_digest(inst->zone_register, &name, &zr_serial, > &zr_digest)); > - if (inst->serial_autoincrement) { > + CHECK(setting_get_bool("serial_autoincrement", zone_settings, > + &serial_autoincrement)); > + if (serial_autoincrement) { > CHECK(ldapdb_rdatalist_get(inst->mctx, inst, &name, > &name, &rdatalist)); > CHECK(rdatalist_digest(inst->mctx, &rdatalist, ldap_digest)); > @@ -1434,34 +1463,39 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > ldap_entry_t *entry; > dns_rbt_t *rbt = NULL; > isc_boolean_t invalidate_nodechain = ISC_FALSE; > + isc_boolean_t psearch; > + const char *base = NULL; > char *config_attrs[] = { > "idnsForwardPolicy", "idnsForwarders", > "idnsAllowSyncPTR", "idnsZoneRefresh", > "idnsPersistentSearch", NULL > }; > char *zone_attrs[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > - "idnsAllowTransfer", "idnsForwardPolicy", > - "idnsForwarders", NULL > + "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > }; > > REQUIRE(ldap_inst != NULL); > > - if (ldap_inst->psearch && !delete_only) { > + CHECK(setting_get_bool("psearch", ldap_inst->global_settings, > + &psearch)); > + if (psearch && !delete_only) { > /* Watcher does the work for us, but deletion is allowed. */ > return ISC_R_SUCCESS; > } > > log_debug(2, "refreshing list of zones for %s", ldap_inst->db_name); > > /* Query for configuration and zones from LDAP and release LDAP connection > * before processing them. It prevents deadlock in situations where > * ldap_parse_zoneentry() requests another connection. */ > + CHECK(setting_get_str("base", ldap_inst->global_settings, &base)); > CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, str_buf(ldap_inst->base), > + CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, base, > LDAP_SCOPE_SUBTREE, config_attrs, 0, > "(objectClass=idnsConfigObject)")); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, str_buf(ldap_inst->base), > + CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, base, > LDAP_SCOPE_SUBTREE, zone_attrs, 0, > "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > @@ -1689,7 +1723,7 @@ free_rdatalist(isc_mem_t *mctx, dns_rdatalist_t *rdlist) > static isc_result_t > ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > ldap_qresult_t *qresult, dns_name_t *origin, > - const ld_string_t *fake_mname, ld_string_t *buf, > + const char *fake_mname, ld_string_t *buf, > ldapdb_rdatalist_t *rdatalist) > { > isc_result_t result; > @@ -1746,6 +1780,7 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > ld_string_t *string = NULL; > ldapdb_node_t *node; > dns_name_t node_name; > + const char *fake_mname = NULL; > > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > @@ -1764,6 +1799,8 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > goto cleanup; > } > > + CHECK(setting_get_str("fake_mname", ldap_inst->local_settings, > + &fake_mname)); > for (entry = HEAD(ldap_qresult->ldap_entries); > entry != NULL; > entry = NEXT(entry, link)) { > @@ -1778,7 +1815,7 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > dns_name_free(&node_name, mctx); > if (result == ISC_R_SUCCESS) { > result = ldap_parse_rrentry(mctx, entry, ldap_qresult, > - origin, ldap_inst->fake_mname, > + origin, fake_mname, > string, &node->rdatalist); > } > if (result != ISC_R_SUCCESS) { > @@ -1810,6 +1847,7 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > ldap_entry_t *entry; > ld_string_t *string = NULL; > ldap_cache_t *cache = NULL; > + const char *fake_mname = NULL; > > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > @@ -1836,11 +1874,13 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > goto cleanup; > } > > + CHECK(setting_get_str("fake_mname", ldap_inst->local_settings, > + &fake_mname)); > for (entry = HEAD(ldap_qresult->ldap_entries); > entry != NULL; > entry = NEXT(entry, link)) { > CHECK(ldap_parse_rrentry(mctx, entry, ldap_qresult, > - origin, ldap_inst->fake_mname, > + origin, fake_mname, > string, rdatalist)); > } > > @@ -1864,7 +1904,7 @@ cleanup: > static isc_result_t > add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult, dns_name_t *origin, > ldap_entry_t *entry, ldapdb_rdatalist_t *rdatalist, > - const ld_string_t *fake_mname) > + const char *fake_mname) > { > isc_result_t result; > ld_string_t *string = NULL; > @@ -2122,6 +2162,7 @@ ldap_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *sin) > sasl_interact_t *in; > ldap_instance_t *ldap_inst = defaults; > int ret = LDAP_OTHER; > + isc_result_t result; > > REQUIRE(ldap_inst != NULL); > UNUSED(flags); > @@ -2134,36 +2175,47 @@ ldap_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *sin) > switch (in->id) { > case SASL_CB_USER: > log_debug(4, "got request for SASL_CB_USER"); > - in->result = str_buf(ldap_inst->sasl_user); > - in->len = str_len(ldap_inst->sasl_user); > + CHECK(setting_get_str("sasl_user", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_GETREALM: > log_debug(4, "got request for SASL_CB_GETREALM"); > - in->result = str_buf(ldap_inst->sasl_realm); > - in->len = str_len(ldap_inst->sasl_realm); > + CHECK(setting_get_str("sasl_realm", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_AUTHNAME: > log_debug(4, "got request for SASL_CB_AUTHNAME"); > - in->result = str_buf(ldap_inst->sasl_auth_name); > - in->len = str_len(ldap_inst->sasl_auth_name); > + CHECK(setting_get_str("sasl_auth_name", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > case SASL_CB_PASS: > log_debug(4, "got request for SASL_CB_PASS"); > - in->result = str_buf(ldap_inst->sasl_password); > - in->len = str_len(ldap_inst->sasl_password); > + CHECK(setting_get_str("sasl_password", > + ldap_inst->global_settings, > + (const char **)&in->result)); > + in->len = strlen(in->result); > ret = LDAP_SUCCESS; > break; > default: > - in->result = NULL; > - in->len = 0; > - ret = LDAP_OTHER; > + goto cleanup; > } > } > > return ret; > + > +cleanup: > + in->result = NULL; > + in->len = 0; > + return LDAP_OTHER; > } > > /* > @@ -2174,16 +2226,20 @@ static isc_result_t > ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > isc_boolean_t force) > { > - LDAP *ld; > + LDAP *ld = NULL; > int ret; > int version; > struct timeval timeout; > isc_result_t result = ISC_R_FAILURE; > + const char *uri = NULL; > + const char *ldap_hostname = NULL; > + isc_uint32_t timeout_sec; > > REQUIRE(ldap_inst != NULL); > REQUIRE(ldap_conn != NULL); > > - ret = ldap_initialize(&ld, str_buf(ldap_inst->uri)); > + CHECK(setting_get_str("uri", ldap_inst->local_settings, &uri)); > + ret = ldap_initialize(&ld, uri); > if (ret != LDAP_SUCCESS) { > log_error("LDAP initialization failed: %s", > ldap_err2string(ret)); > @@ -2194,15 +2250,18 @@ ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > ret = ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); > LDAP_OPT_CHECK(ret, "failed to set LDAP version"); > > - timeout.tv_sec = ldap_inst->timeout; > + CHECK(setting_get_uint("timeout", ldap_inst->global_settings, > + &timeout_sec)); > + timeout.tv_sec = timeout_sec; > timeout.tv_usec = 0; > > ret = ldap_set_option(ld, LDAP_OPT_TIMEOUT, &timeout); > LDAP_OPT_CHECK(ret, "failed to set timeout"); > > - if (str_len(ldap_inst->ldap_hostname) > 0) { > - ret = ldap_set_option(ld, LDAP_OPT_HOST_NAME, > - str_buf(ldap_inst->ldap_hostname)); > + CHECK(setting_get_str("ldap_hostname", ldap_inst->local_settings, > + &ldap_hostname)); > + if (strlen(ldap_hostname) > 0) { > + ret = ldap_set_option(ld, LDAP_OPT_HOST_NAME, ldap_hostname); > LDAP_OPT_CHECK(ret, "failed to set LDAP_OPT_HOST_NAME"); > } > > @@ -2231,9 +2290,16 @@ static isc_result_t > ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > isc_boolean_t force) > { > + isc_result_t result; > int ret = 0; > const char *bind_dn = NULL; > const char *password = NULL; > + const char *uri = NULL; > + const char *sasl_mech = NULL; > + const char *krb5_principal = NULL; > + const char *krb5_keytab = NULL; > + ldap_auth_t auth_method_enum = AUTH_INVALID; > + isc_uint32_t reconnect_interval; > > if (force) > goto force_reconnect; > @@ -2251,9 +2317,11 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > > /* If either bind_dn or the password is not set, we will use > * password-less bind. */ > - if (str_len(ldap_inst->bind_dn) > 0 && str_len(ldap_inst->password) > 0) { > - bind_dn = str_buf(ldap_inst->bind_dn); > - password = str_buf(ldap_inst->password); > + CHECK(setting_get_str("bind_dn", ldap_inst->global_settings, &bind_dn)); > + CHECK(setting_get_str("password", ldap_inst->global_settings, &password)); > + if (strlen(bind_dn) == 0 || strlen(password) == 0) { > + bind_dn = NULL; > + password = NULL; > } > > /* Set the next possible reconnect time. */ > @@ -2265,39 +2333,52 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > const size_t ntimes = sizeof(intervals) / sizeof(intervals[0]); > > i = ISC_MIN(ntimes - 1, ldap_conn->tries); > - seconds = ISC_MIN(intervals[i], ldap_inst->reconnect_interval); > + CHECK(setting_get_uint("reconnect_interval", > + ldap_inst->global_settings, > + &reconnect_interval)); > + seconds = ISC_MIN(intervals[i], reconnect_interval); > isc_interval_set(&delay, seconds, 0); > isc_time_nowplusinterval(&ldap_conn->next_reconnect, &delay); > } > > ldap_conn->tries++; > force_reconnect: > - log_debug(2, "trying to establish LDAP connection to %s", > - str_buf(ldap_inst->uri)); > + CHECK(setting_get_str("uri", ldap_inst->local_settings, &uri)); > + log_debug(2, "trying to establish LDAP connection to %s", uri); > > - switch (ldap_inst->auth_method) { > + CHECK(setting_get_uint("auth_method_enum", ldap_inst->local_settings, > + &auth_method_enum)); > + switch (auth_method_enum) { > case AUTH_NONE: > ret = ldap_simple_bind_s(ldap_conn->handle, NULL, NULL); > break; > case AUTH_SIMPLE: > ret = ldap_simple_bind_s(ldap_conn->handle, bind_dn, password); > break; > case AUTH_SASL: > - if (strcmp(str_buf(ldap_inst->sasl_mech), "GSSAPI") == 0) { > + CHECK(setting_get_str("sasl_mech", ldap_inst->local_settings, > + &sasl_mech)); > + if (strcmp(sasl_mech, "GSSAPI") == 0) { > isc_result_t result; > + CHECK(setting_get_str("krb5_principal", > + ldap_inst->local_settings, > + &krb5_principal)); > + CHECK(setting_get_str("krb5_keytab", > + ldap_inst->local_settings, > + &krb5_keytab)); > LOCK(&ldap_inst->kinit_lock); > result = get_krb5_tgt(ldap_inst->mctx, > - str_buf(ldap_inst->krb5_principal), > - str_buf(ldap_inst->krb5_keytab)); > + krb5_principal, > + krb5_keytab); > UNLOCK(&ldap_inst->kinit_lock); > if (result != ISC_R_SUCCESS) > return ISC_R_NOTCONNECTED; > } > > - log_debug(4, "trying interactive bind using %s mechanism", > - str_buf(ldap_inst->sasl_mech)); > + log_debug(4, "trying interactive bind using '%s' mechanism", > + sasl_mech); > ret = ldap_sasl_interactive_bind_s(ldap_conn->handle, NULL, > - str_buf(ldap_inst->sasl_mech), > + sasl_mech, > NULL, NULL, LDAP_SASL_QUIET, > ldap_sasl_interact, > ldap_inst); > @@ -2336,6 +2417,9 @@ force_reconnect: > ldap_conn->tries = 0; > > return ISC_R_SUCCESS; > + > +cleanup: > + return result; > } > > static isc_result_t > @@ -2704,70 +2788,66 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_result_t result; > isc_mem_t *mctx = ldap_inst->mctx; > ldap_connection_t *ldap_conn = NULL; > - ldap_qresult_t *ldap_qresult = NULL; > ld_string_t *owner_dn = NULL; > LDAPMod *change[3] = { NULL }; > LDAPMod *change_ptr = NULL; > ldap_cache_t *cache = NULL; > - ldap_entry_t *entry; > - ldap_valuelist_t values; > - isc_boolean_t zone_dyn_update = ldap_inst->dyn_update; > - isc_boolean_t zone_sync_ptr = ldap_inst->sync_ptr; > + isc_boolean_t zone_dyn_update; > + isc_boolean_t zone_sync_ptr; > ld_string_t *owner_dn_ptr = NULL; > - char *attrs[] = {"idnsAllowSyncPTR", "idnsAllowDynUpdate", NULL}; > ld_string_t *str_ptr = NULL; > ldapdb_rdatalist_t rdlist_search; > dns_rdatalist_t *rdlist_ptr = NULL; > char **vals = NULL; > + dns_name_t zone_name; > + struct dns_fixedname ptr_name; > + char *zone_dn = NULL; > + settings_set_t *zone_settings = NULL; > > /* > * Find parent zone entry and check if Dynamic Update is allowed. > * @todo Try the cache first and improve split: SOA records are problematic. > */ > ISC_LIST_INIT(rdlist_search); > + dns_name_init(&zone_name, NULL); > + dns_fixedname_init(&ptr_name); > CHECK(str_new(mctx, &owner_dn)); > + > CHECK(dnsname_to_dn(ldap_inst->zone_register, owner, owner_dn)); > - char *zone_dn = strstr(str_buf(owner_dn),", "); > + zone_dn = strstr(str_buf(owner_dn),", "); > > if (zone_dn == NULL) { /* SOA record; owner = zone => owner_dn = zone_dn */ > zone_dn = (char *)str_buf(owner_dn); > } else { > zone_dn += 1; /* skip whitespace */ > } > > - CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_qresult, zone_dn, > - LDAP_SCOPE_BASE, attrs, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + CHECK(dn_to_dnsname(mctx, zone_dn, &zone_name, NULL)); > > - /* only 0 or 1 active zone can be returned from query */ > - entry = HEAD(ldap_qresult->ldap_entries); > - if (entry == NULL) { > - log_debug(3, "Active zone %s not found", zone_dn); > - result = DNS_R_NOTAUTH; > - goto cleanup; > - } > - > - result = ldap_entry_getvalues(entry, "idnsAllowDynUpdate", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_dyn_update = (strcmp(HEAD(values)->value, "TRUE") == 0 ) > - ? ISC_TRUE : ISC_FALSE; > + result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > + &zone_settings); > + if (result != ISC_R_SUCCESS) { > + if (result == ISC_R_NOTFOUND) > + log_debug(3, "active zone '%s' not found", zone_dn); > + CLEANUP_WITH(DNS_R_NOTAUTH); > } > > + CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); > if (!zone_dyn_update) { > - log_debug(3, "Dynamic Update is not allowed in zone %s", zone_dn); > - result = DNS_R_REFUSED; > - goto cleanup; > + log_debug(3, "dynamic update is not allowed in zone '%s'", > + zone_dn); > + CLEANUP_WITH(DNS_R_REFUSED); > } > > - if (rdlist->type == dns_rdatatype_soa && mod_op == LDAP_MOD_DELETE) { > - result = ISC_R_SUCCESS; > - goto cleanup; > - } > + if (rdlist->type == dns_rdatatype_soa && mod_op == LDAP_MOD_DELETE) > + CLEANUP_WITH(ISC_R_SUCCESS); > + > /* Flush modified record from the cache */ > CHECK(zr_get_zone_cache(ldap_inst->zone_register, owner, &cache)); > CHECK(discard_from_cache(cache, owner)); > > + CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > + > if (rdlist->type == dns_rdatatype_soa) { > result = modify_soa_record(ldap_inst, ldap_conn, str_buf(owner_dn), > HEAD(rdlist->rdata)); > @@ -2789,18 +2869,12 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * use global plugin configuration: option "sync_ptr" > */ > > - result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_sync_ptr = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > - } > - > + CHECK(setting_get_bool("sync_ptr", zone_settings, &zone_sync_ptr)); > if (!zone_sync_ptr) { > - log_debug(3, "Sync PTR is not allowed in zone %s", zone_dn); > - result = ISC_R_SUCCESS; > - goto cleanup; > + log_debug(3, "sync PTR is not allowed in zone '%s'", zone_dn); > + CLEANUP_WITH(ISC_R_SUCCESS); > } > - log_debug(3, "Sync PTR is allowed for zone %s", zone_dn); > + log_debug(3, "sync PTR is allowed for zone '%s'", zone_dn); > > /* Get string with IP address from change request > * and convert it to in_addr structure. */ > @@ -2824,26 +2898,22 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * 192.168.0.1 -> 1.0.168.192.in-addr.arpa > * > * @todo Check if it works for IPv6 correctly. > - */ > - struct dns_fixedname name; > - dns_fixedname_init(&name); > - CHECK(dns_byaddr_createptrname2(&isc_ip, 0, dns_fixedname_name(&name))); > + */ > + CHECK(dns_byaddr_createptrname2(&isc_ip, 0, dns_fixedname_name(&ptr_name))); > > /* Find PTR entry in LDAP. */ > - result = ldapdb_rdatalist_get(mctx, ldap_inst, dns_fixedname_name(&name), > + result = ldapdb_rdatalist_get(mctx, ldap_inst, dns_fixedname_name(&ptr_name), > NULL, &rdlist_search); > > /* Check the value of PTR entry. */ > if (mod_op == LDAP_MOD_DELETE && result == ISC_R_SUCCESS) { > result = ldapdb_rdatalist_findrdatatype(&rdlist_search, > dns_rdatatype_ptr, &rdlist_ptr); > } > > if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) { > - log_error("Can not synchronize PTR record, ldapdb_rdatalist_get = %d", > - result); > - result = ISC_R_FAILURE; /* Synchronization required: report error. */ > - goto cleanup; > + log_error_r("can not synchronize PTR record, ldapdb_rdatalist_get"); > + CLEANUP_WITH(ISC_R_FAILURE); /* Synchronization required: report error. */ > } > > /* > @@ -2859,46 +2929,38 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > } > > /* Get LDAP entry indentifier. */ > - CHECK(str_new(mctx, &owner_dn_ptr)); > - CHECK(dnsname_to_dn(ldap_inst->zone_register, dns_fixedname_name(&name), > - owner_dn_ptr)); > + CHECK(str_new(mctx, &owner_dn_ptr)); > + CHECK(dnsname_to_dn(ldap_inst->zone_register, dns_fixedname_name(&ptr_name), > + owner_dn_ptr)); > > /* > * @example > * owner_dn_ptr = "idnsName=100.0.168, idnsname=192.in-addr.arpa,cn=dns,$SUFFIX" > * owner_zone_dn_ptr = "idnsname=192.in-addr.arpa,cn=dns,$SUFFIX" > */ > char *owner_zone_dn_ptr = strstr(str_buf(owner_dn_ptr),", ") + 1; > > /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ > - ldap_query_free(ISC_FALSE, &ldap_qresult); > - zone_dyn_update = ldap_inst->dyn_update; > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_qresult, owner_zone_dn_ptr, > - LDAP_SCOPE_BASE, attrs, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + dns_name_free(&zone_name, mctx); > + dns_name_init(&zone_name, NULL); > + CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); > > - /* Only 0 or 1 active zone can be returned from query. */ > - entry = HEAD(ldap_qresult->ldap_entries); > - if (entry == NULL) { > - log_debug(3, "Active zone %s not found", zone_dn); > - result = ISC_R_NOTFOUND; > + zone_settings = NULL; > + result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > + &zone_settings); > + if (result != ISC_R_SUCCESS) { > + if (result == ISC_R_NOTFOUND) > + log_debug(3, "active zone '%s' not found", zone_dn); > goto cleanup; > } > > - result = ldap_entry_getvalues(entry, "idnsAllowDynUpdate", &values); > - if (result == ISC_R_SUCCESS) { /* zone specific setting found */ > - zone_dyn_update = (strcmp(HEAD(values)->value, "TRUE") == 0) > - ? ISC_TRUE : ISC_FALSE; > - } > - > + CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); > if (!zone_dyn_update) { > - log_debug(3, "Dynamic Update is not allowed in zone %s", owner_zone_dn_ptr); > - result = ISC_R_NOPERM; > - goto cleanup; > + log_debug(3, "dynamic update is not allowed in zone " > + "'%s'", zone_dn); > + CLEANUP_WITH(ISC_R_NOPERM); > } > > - log_debug(3, "Dynamic Update is allowed for zone %s", owner_zone_dn_ptr); > - > /* > * Get string representation of PTR record value. > * > @@ -2956,24 +3018,25 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > change_ptr = NULL; > > /* Modify PTR record. */ > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), change, delete_node)); > + CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), > + change, delete_node)); > cache = NULL; > CHECK(zr_get_zone_cache(ldap_inst->zone_register, > - dns_fixedname_name(&name), &cache)); > - CHECK(discard_from_cache(cache, dns_fixedname_name(&name))); > + dns_fixedname_name(&ptr_name), &cache)); > + CHECK(discard_from_cache(cache, dns_fixedname_name(&ptr_name))); > } > > cleanup: > - ldap_query_free(ISC_FALSE, &ldap_qresult); > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > str_destroy(&owner_dn_ptr); > str_destroy(&owner_dn); > str_destroy(&str_ptr); > free_ldapmod(mctx, &change[0]); > free_ldapmod(mctx, &change[1]); > if (change_ptr != NULL) free_ldapmod(mctx, &change_ptr); > ldapdb_rdatalist_destroy(mctx, &rdlist_search); > free_char_array(mctx, &vals); > + dns_name_free(&zone_name, mctx); > > return result; > } > @@ -3280,7 +3343,8 @@ update_zone(isc_task_t *task, isc_event_t *event) > dns_name_t prevname; > char *attrs_zone[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > - "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", NULL > + "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > }; > char *attrs_record[] = { > "objectClass", "dn", NULL > @@ -3416,7 +3480,8 @@ update_record(isc_task_t *task, isc_event_t *event) > ldap_psearchevent_t *pevent = (ldap_psearchevent_t *)event; > isc_result_t result; > ldap_instance_t *inst = NULL; > - ldap_cache_t *cache; > + ldap_cache_t *cache = NULL; > + isc_boolean_t serial_autoincrement; > isc_mem_t *mctx; > dns_zone_t *zone_ptr = NULL; > isc_boolean_t zone_found = ISC_FALSE; > @@ -3430,6 +3495,7 @@ update_record(isc_task_t *task, isc_event_t *event) > ldapdb_rdatalist_t rdatalist; > > /* Convert domain name from text to struct dns_name_t. */ > + settings_set_t *zone_settings = NULL; > dns_name_t name; > dns_name_t origin; > dns_name_t prevname; > @@ -3494,8 +3560,12 @@ update_restart: > } > > /* Do not bump serial during initial database dump. */ > - if (inst->serial_autoincrement && PSEARCH_ANY(pevent->chgtype)) { > - CHECK(soa_serial_increment(mctx, inst, &origin)); > + if (PSEARCH_ANY(pevent->chgtype)) { > + CHECK(zr_get_zone_settings(inst->zone_register, &origin, &zone_settings)); > + CHECK(setting_get_bool("serial_autoincrement", zone_settings, > + &serial_autoincrement)); > + if (serial_autoincrement) > + CHECK(soa_serial_increment(mctx, inst, &origin)); > } > > cleanup: > @@ -3770,6 +3840,9 @@ ldap_psearch_watcher(isc_threadarg_t arg) > isc_result_t result; > sigset_t sigset; > isc_boolean_t flush_required; > + isc_boolean_t psearch; > + isc_uint32_t reconnect_interval; > + const char *base = NULL; > > log_debug(1, "Entering ldap_psearch_watcher"); > > @@ -3797,10 +3870,12 @@ ldap_psearch_watcher(isc_threadarg_t arg) > /* Try to connect. */ > while (conn->handle == NULL) { > CHECK_EXIT; > + CHECK(setting_get_uint("reconnect_interval", inst->global_settings, > + &reconnect_interval)); > > log_error("ldap_psearch_watcher handle is NULL. " > - "Next try in %ds", inst->reconnect_interval); > - if (!sane_sleep(inst, inst->reconnect_interval)) > + "Next try in %ds", reconnect_interval); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > handle_connection_error(inst, conn, ISC_TRUE); > } > @@ -3811,10 +3886,12 @@ restart: > /* Perform initial lookup */ > ldap_query_free(ISC_TRUE, &ldap_qresult); > flush_required = ISC_TRUE; > - if (inst->psearch) { > + CHECK(setting_get_str("base", inst->global_settings, &base)); > + CHECK(setting_get_bool("psearch", inst->global_settings, &psearch)); > + if (psearch) { > log_debug(1, "Sending initial psearch lookup"); > ret = ldap_search_ext(conn->handle, > - str_buf(inst->base), > + base, > LDAP_SCOPE_SUBTREE, > /* > * (objectClass==idnsZone AND idnsZoneActive==TRUE) > @@ -3841,10 +3918,14 @@ restart: > CHECK_EXIT; > while (handle_connection_error(inst, conn, ISC_TRUE) > != ISC_R_SUCCESS) { > - log_error("ldap_psearch_watcher failed to handle " > - "LDAP connection error. Reconnection " > - "in %ds", inst->reconnect_interval); > - if (!sane_sleep(inst, inst->reconnect_interval)) > + CHECK(setting_get_uint("reconnect_interval", > + inst->global_settings, > + &reconnect_interval)); > + log_error("ldap_psearch_watcher failed to " > + "handle LDAP connection error. " > + "Reconnection in %ds", > + reconnect_interval); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > } > goto restart; > @@ -3865,7 +3946,10 @@ restart: > } > > if (restart_needed) { > - if (!sane_sleep(inst, inst->reconnect_interval)) > + CHECK(setting_get_uint("reconnect_interval", > + inst->global_settings, > + &reconnect_interval)); > + if (!sane_sleep(inst, reconnect_interval)) > goto cleanup; > > goto restart; > @@ -3933,3 +4017,8 @@ cleanup: > return (isc_threadresult_t)0; > } > > +settings_set_t * > +ldap_instance_getsettings_local(ldap_instance_t *ldap_inst) > +{ > + return ldap_inst->local_settings; > +} > diff --git a/src/ldap_helper.h b/src/ldap_helper.h > index a1e52f044d5e81ace7fb2d3c2ab082ad838944d1..86c3d4ec040a073df8c89d67b93cbd9e1b3bfb77 100644 > --- a/src/ldap_helper.h > +++ b/src/ldap_helper.h > @@ -90,4 +90,9 @@ isc_result_t write_to_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_result_t remove_from_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > dns_rdatalist_t *rdlist, isc_boolean_t delete_node); > > +/* Get cache associated with ldap_inst */ > +ldap_cache_t *ldap_instance_getcache(ldap_instance_t *ldap_inst); > + > +settings_set_t * ldap_instance_getsettings_local(ldap_instance_t *ldap_inst); > + > #endif /* !_LD_LDAP_HELPER_H_ */ > diff --git a/src/settings.c b/src/settings.c > index 08164766172f5f915584ae51b43e3d64798eed71..8ced5fe9bff4beb70e8a6f5e8880aa34eae7c045 100644 > --- a/src/settings.c > +++ b/src/settings.c > @@ -1,7 +1,7 @@ > /* > * Authors: Martin Nagy > * > - * Copyright (C) 2009 Red Hat > + * Copyright (C) 2009-2012 Red Hat > * see file 'COPYING' for use and warranty information > * > * This program is free software; you can redistribute it and/or > @@ -20,182 +20,615 @@ > > #include > #include > +#include > #include > +#include > +#include > +#include > +#include > > #include > #include > +#include > #include > > #include "log.h" > #include "settings.h" > #include "str.h" > #include "util.h" > #include "types.h" > +#include "ldap_helper.h" > +#include "zone_register.h" > > isc_boolean_t verbose_checks = ISC_FALSE; /* log each failure in CHECK() macro */ > > -/* > - * Forward declarations. > +/** Built-in defaults. */ > +static const setting_t settings_default[] = { > + { "uri", no_default_string }, /* User have to set this */ > + { "connections", default_uint(2) }, > + { "reconnect_interval", default_uint(60) }, > + { "zone_refresh", default_uint(0) }, > + { "timeout", default_uint(10) }, > + { "cache_ttl", default_uint(120) }, > + { "timeout", default_uint(10) }, > + { "base", no_default_string }, /* User have to set this */ > + { "auth_method", default_string("none") }, > + { "bind_dn", default_string("") }, > + { "password", default_string("") }, > + { "krb5_principal", default_string("") }, > + { "sasl_mech", default_string("GSSAPI") }, > + { "sasl_user", default_string("") }, > + { "sasl_auth_name", default_string("") }, > + { "sasl_realm", default_string("") }, > + { "sasl_password", default_string("") }, > + { "krb5_keytab", default_string("") }, > + { "fake_mname", default_string("") }, > + { "psearch", default_boolean(ISC_FALSE) }, > + { "ldap_hostname", default_string("") }, > + { "sync_ptr", default_boolean(ISC_FALSE) }, > + { "dyn_update", default_boolean(ISC_FALSE) }, > + { "serial_autoincrement", default_boolean(ISC_FALSE) }, > + { "verbose_checks", default_boolean(ISC_FALSE) }, > + end_of_settings > +}; > + > +/** Settings set for built-in defaults. */ > +const settings_set_t const settings_default_set = { > + NULL, > + "built-in defaults", > + NULL, > + (setting_t *) &settings_default[0] > +}; > + > +/** > + * @param[in] name Setting name. > + * @param[in] set Set of settings to start search in. > + * @param[in] recursive Continue with search in parent sets if setting was > + * not found in set passed by caller. > + * @param[in] filled_only Consider settings without value as non-existent. > + * @param[out] found Pointer to found setting_t. Ignored if found is NULL. > + * > + * @pre found == NULL || (found != NULL && *found == NULL) > + * > + * @retval ISC_R_SUCCESS > + * @retval ISC_R_NOTFOUND > */ > -static int args_are_equal(const char *setting_argument, > - const char *argv_argument); > -static isc_result_t set_value(setting_t *setting, const char *value); > -static isc_result_t set_default_value(setting_t *setting); > -static const char * get_value_str(const char *arg); > - > isc_result_t > -set_settings(setting_t settings[], const char * const* argv) > -{ > - isc_result_t result; > - int i, j; > - const char *value; > +setting_find(const char *name, const settings_set_t *set, > + isc_boolean_t recursive, isc_boolean_t filled_only, > + setting_t **found) { > > - for (i = 0; argv[i] != NULL; i++) { > - for (j = 0; settings[j].name != NULL; j++) { > - if (args_are_equal(settings[j].name, argv[i])) { > - value = get_value_str(argv[i]); > - CHECK(set_value(&settings[j], value)); > - break; > + REQUIRE(name != NULL); > + REQUIRE(found == NULL || *found == NULL); > + > + while (set != NULL) { > + log_debug(20, "examining set of settings '%s'", set->name); > + for (setting_t *setting = set->first_setting; > + setting->name; > + setting++) { > + > + if (strcmp(name, setting->name) == 0) { > + if (setting->filled || !filled_only) { > + if (found != NULL) > + *found = setting; > + log_debug(20, "setting '%s' was found " > + "in set '%s'", name, > + set->name); > + return ISC_R_SUCCESS; > + } else { > + break; /* continue with parent set */ > + } > } > - } > - } > > - /* When all is done, check that all the required settings are set. */ > - for (j = 0; settings[j].name != NULL; j++) { > - if (settings[j].set != 0) > - continue; > - if (!settings[j].has_a_default) { > - log_error("argument %s must be set", settings[j].name); > - result = ISC_R_FAILURE; > - goto cleanup; > } > - CHECK(set_default_value(&settings[j])); > - } > - > - return ISC_R_SUCCESS; > - > -cleanup: > - /* TODO: Free memory in case of error. */ > - return result; > -} > - > -/* > - * Return 1 if the argument names are equal. The argv_argument also needs to > - * contain an additional space at the end. > - */ > -static int > -args_are_equal(const char *setting_argument, const char *argv_argument) > -{ > - if (setting_argument == NULL || argv_argument == NULL) > - return 0; > - > - for (;;) { > - if (*setting_argument == '\0') > + if (recursive) > + set = set->parent_set; > + else > break; > - if (*argv_argument == '\0') > - return 0; > - if (*setting_argument != *argv_argument) > - return 0; > - setting_argument++; > - argv_argument++; > + } > + return ISC_R_NOTFOUND; > +} > + > +/** > + * Get value associated with a setting. Search starts in set of settings > + * passed by caller and continues in parent sets until the setting with defined > + * value is found. > + * > + * @warning > + * This function is not expected to fail because all settings should > + * have default value defined (in topmost set of settings). > + * Caller should always check the return value, regardless this assumption. > + * > + * @param[in] type Data type expected by caller. > + * @param[out] target Type of pointer must agree with requested setting type. > + * @retval ISC_R_SUCCESS Required value was found and target was filled in. > + * @retval ISC_R_NOTFOUND Value is not defined in specified set of > + * settings either in parent sets. > + * @retval ISC_R_UNEXPECTED Type mismatch between expected type and type > + * of setting in settings tree. (I.e. programming > + * error.) > + */ > +static isc_result_t > +setting_get(const char *const name, const setting_type_t type, > + const settings_set_t *const set, void *target) > +{ > + isc_result_t result; > + setting_t *setting = NULL; > + > + REQUIRE(name != NULL); > + REQUIRE(target != NULL); > + > + CHECK(setting_find(name, set, isc_boolean_true, isc_boolean_true, &setting)); > + > + if (setting->type != type) { > + log_bug("incompatible setting data type requested " > + "for name '%s' in set of settings '%s'", name, set->name); \ > + return ISC_R_UNEXPECTED; > + } > + > + switch (type) { > + case ST_UNSIGNED_INTEGER: > + *(isc_uint32_t *)target = setting->value.value_uint; > + break; > + case ST_STRING: > + *(char **)target = setting->value.value_char; > + break; > + case ST_BOOLEAN: > + *(isc_boolean_t *)target = setting->value.value_boolean; > + break; > } > > - /* Now make sure we also found a space at the end of argv_argument. */ > - if (!isspace(*argv_argument) && *argv_argument != '\0') > - return 0; > + return ISC_R_SUCCESS; > > - return 1; > +cleanup: > + log_bug("setting '%s' was not found in settings tree", name); > + return result; > } > > +isc_result_t > +setting_get_uint(const char *const name, const settings_set_t *const set, > + isc_uint32_t *target) > +{ > + return setting_get(name, ST_UNSIGNED_INTEGER, set, target); > +} > + > +isc_result_t > +setting_get_str(const char *const name, const settings_set_t *const set, > + const char **target) > +{ > + return setting_get(name, ST_STRING, set, target); > +} > + > +isc_result_t > +setting_get_bool(const char *const name, const settings_set_t *const set, > + isc_boolean_t *target) > +{ > + return setting_get(name, ST_BOOLEAN, set, target); > +} > + > +/** > + * Convert and copy value to setting structure. Mutual exclusion during write > + * is ensured by isc_task_beginexclusive(task). > + * > + * @retval ISC_R_SUCCESS New value was converted and copied. > + * @retval ISC_R_IGNORE New and old values are same, no change was made. > + * @retval ISC_R_NOMEMORY > + * @retval ISC_R_UNEXPECTEDEND > + * @retval ISC_R_UNEXPECTEDTOKEN > + * @retval others Other errors from isc_parse_uint32(). > + */ > static isc_result_t > -set_value(setting_t *setting, const char *value) > +set_value(isc_mem_t *mctx, setting_t *setting, const char *value, > + isc_task_t *task) > { > isc_result_t result; > - int numeric_value; > + isc_result_t lock = ISC_R_IGNORE; > + isc_uint32_t numeric_value; > + isc_uint32_t len; > + > + REQUIRE(setting != NULL); > + REQUIRE(value != NULL); > + REQUIRE(task != NULL); > > + /* Check and convert new values. */ > switch (setting->type) { > - case ST_LD_STRING: > - CHECK(str_init_char((ld_string_t *)setting->target, value)); > + case ST_STRING: > + if (setting->filled && > + strcmp(setting->value.value_char, value) == 0) > + return ISC_R_IGNORE; > break; > - case ST_SIGNED_INTEGER: > + > case ST_UNSIGNED_INTEGER: > - if (*value == '\0') { > - result = ISC_R_FAILURE; > + if (*value == '\0') > + CLEANUP_WITH(ISC_R_UNEXPECTEDEND); > + > + result = isc_parse_uint32(&numeric_value, value, 10); > + if (result != ISC_R_SUCCESS) { > + log_error_r("setting '%s' has to be unsigned integer " > + "(base 10)", setting->name); > goto cleanup; > } > - /* TODO: better type checking. */ > - numeric_value = atoi(value); > - if (setting->type == ST_SIGNED_INTEGER) { > - (*(signed *)setting->target) = (signed)numeric_value; > - } else if (numeric_value < 0) { > - log_error("argument %s must be an unsigned integer", > - setting->name); > - result = ISC_R_FAILURE; > - goto cleanup; > - } else { > - (*(unsigned *)setting->target) = (unsigned)numeric_value; > - } > + if (setting->filled && > + setting->value.value_uint == numeric_value) > + CLEANUP_WITH(ISC_R_IGNORE); > break; > + > case ST_BOOLEAN: > - if (strncasecmp(value, "yes", 3) == 0) > - (*(isc_boolean_t *)setting->target) = ISC_TRUE; > - else if (strncasecmp(value, "no", 2) == 0) > - (*(isc_boolean_t *)setting->target) = ISC_FALSE; > + if (strcasecmp(value, "yes") == 0 || > + strcasecmp(value, "true") == 0) > + numeric_value = 1; > + else if (strcasecmp(value, "no") == 0 || > + strcasecmp(value, "false") == 0) > + numeric_value = 0; > else { > - log_error("unknown boolean expression (%s: %s)", > + log_error("unknown boolean expression " > + "(setting '%s': value '%s')", > setting->name, value); > - result = ISC_R_FAILURE; > - goto cleanup; > + CLEANUP_WITH(ISC_R_UNEXPECTEDTOKEN); > } > + if (setting->filled && > + setting->value.value_boolean == ISC_TF(numeric_value)) > + CLEANUP_WITH(ISC_R_IGNORE); > break; > - default: > - fatal_error("unknown type in function set_value()"); > - result = ISC_R_FAILURE; > + } > + > + /* Switch to single thread mode and write new value. */ > + lock = isc_task_beginexclusive(task); > + RUNTIME_CHECK(lock == ISC_R_SUCCESS || lock == ISC_R_LOCKBUSY); > + > + switch (setting->type) { > + case ST_STRING: > + len = strlen(value) + 1; > + if (setting->is_dynamic) > + isc_mem_free(mctx, setting->value.value_char); > + CHECKED_MEM_ALLOCATE(mctx, setting->value.value_char, len); > + setting->is_dynamic = ISC_TRUE; > + CHECK(isc_string_copy(setting->value.value_char, len, value)); > + break; > + > + case ST_UNSIGNED_INTEGER: > + setting->value.value_uint = numeric_value; > + break; > + > + case ST_BOOLEAN: > + setting->value.value_boolean = ISC_TF(numeric_value); > + break; > + } > + setting->filled = 1; > + result = ISC_R_SUCCESS; > + > +cleanup: > + if (lock == ISC_R_SUCCESS) > + isc_task_endexclusive(task); > + return result; > +} > + > +/** > + * Change value in given set of settings (non-recursively, parent sets are > + * not affected in any way). Function will fail if setting with given name is > + * not a part of set of settings. > + * Mutual exclusion is ensured by set_value(). > + * > + * @warning > + * Failure in this function usually points to insufficient input validation > + * OR logic error. > + * Caller should always check the return value. > + * > + * @retval ISC_R_SUCCESS Value was changed. > + * @retval ISC_R_IGNORE Value wasn't changed because it is same as original. > + * @retval ISC_R_NOTFOUND Setting was not found in given set of settings. > + * @retval ISC_R_NOMEMORY > + * @retval Others Conversion errors. > + */ > +isc_result_t > +setting_set(const char *const name, const settings_set_t *set, > + const char *const value, isc_task_t *task) > +{ > + isc_result_t result; > + setting_t *setting = NULL; > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + > + return set_value(set->mctx, setting, value, task); > + > +cleanup: > + log_bug("setting '%s' was not found in set of settings '%s'", name, > + set->name); > + return result; > +} > + > +/** > + * Un-set value in given set of settings (non-recursively, parent sets are > + * not affected in any way). Function will fail if setting with given name is > + * not a part of set of settings. > + * Mutual exclusion is ensured by isc_task_beginexclusive(). > + * > + * @warning > + * Failure in this function usually points to logic error. > + * Caller should always check return value. > + * > + * @retval ISC_R_SUCCESS Setting was un-set. > + * @retval ISC_R_IGNORE Setting wasn't changed because wasn't set. > + * @retval ISC_R_NOTFOUND Required setting was not found > + * in given set of settings. > + */ > +isc_result_t > +setting_unset(const char *const name, const settings_set_t *set, > + isc_task_t *task) > +{ > + isc_result_t result; > + isc_result_t lock = ISC_R_IGNORE; > + setting_t *setting = NULL; > + > + REQUIRE(task != NULL); > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + > + if (!setting->filled) > + return ISC_R_IGNORE; > + > + lock = isc_task_beginexclusive(task); > + RUNTIME_CHECK(lock == ISC_R_SUCCESS || lock == ISC_R_LOCKBUSY); > + > + switch (setting->type) { > + case ST_STRING: > + if (setting->is_dynamic) > + isc_mem_free(set->mctx, setting->value.value_char); > + setting->is_dynamic = ISC_FALSE; > + break; > + > + case ST_UNSIGNED_INTEGER: > + case ST_BOOLEAN: > + break; > + } > + setting->filled = 0; > + > +cleanup: > + if (lock == ISC_R_SUCCESS) > + isc_task_endexclusive(task); > + if (result == ISC_R_NOTFOUND) > + log_bug("setting '%s' was not found in set of settings '%s'", > + name, set->name); > + > + return result; > +} > + > +/** > + * Change setting 'name' to value specified by attribute 'attr_name' in LDAP > + * entry. Setting is un-set if specified value is missing in LDAP entry. > + * > + * @warning Multi-value attributes are no supported. > + * > + * @retval ISC_R_SUCCESS Setting was changed (set or unset). > + * @retval ISC_R_IGNORE Setting wasn't changed because value in settings set > + * and LDAP entry was same. > + * @retval ISC_R_NOTFOUND Required setting was not found in given set. > + * @retval Others Memory allocation or conversion errors. > + */ > +isc_result_t > +setting_update_from_ldap_entry(const char *name, settings_set_t *set, > + const char *attr_name, ldap_entry_t *entry, > + isc_task_t *task) { > + isc_result_t result; > + setting_t *setting = NULL; > + ldap_valuelist_t values; > + > + CHECK(setting_find(name, set, ISC_FALSE, ISC_FALSE, &setting)); > + result = ldap_entry_getvalues(entry, attr_name, &values); > + if (result == ISC_R_NOTFOUND || HEAD(values) == NULL) { > + CHECK(setting_unset(name, set, task)); > + log_debug(2, "setting '%s' (%s) was deleted in object '%s'", > + name, attr_name, entry->dn); > + return ISC_R_SUCCESS; > + > + } else if (result != ISC_R_SUCCESS) { > goto cleanup; > } > > - setting->set = 1; > + if (HEAD(values) != TAIL(values)) { > + log_bug("multi-value attributes are not supported: attribute " > + "'%s' in entry '%s'", attr_name, entry->dn); > + return ISC_R_NOTIMPLEMENTED; > + } > > - return ISC_R_SUCCESS; > + CHECK(setting_set(name, set, HEAD(values)->value, task)); > + log_debug(2, "setting '%s' (%s) was changed to '%s' in object '%s'", > + name, attr_name, HEAD(values)->value, entry->dn); > > cleanup: > + if (result == ISC_R_NOTFOUND) > + log_bug("setting '%s' was not found in settings set '%s'", > + name, set->name); > + return result; > +} > + > +/** > + * Allocate new set of settings, fill it with values from specified default set > + * and (optionally) link the new set of settings to its parent set. > + * > + * @param[in] default_settings Array with pre-filled setting structures. > + * @param[in] default_set_length Default set length in bytes. > + * @param[in] set_name Human readable name for this set of settings. > + * > + * @pre target != NULL && *target == NULL > + * @pre default_settings != NULL > + * @pre default_set_length > 0, default_set_length <= sizeof(default_settings) > + * > + * @retval ISC_R_SUCCESS > + * @retval ISC_R_NOMEMORY > + * > + * @note How to create local_settings which overrides default_settings: > + * @code > + * const setting_t default_settings[] = { > + * { "connections", default_uint(2) }, > + * } > + * const settings_set_t default_settings_set = { > + * NULL, > + * NULL, > + * (setting_t *) &default_settings[0] > + * }; > + * const setting_t local_settings[] = { > + * { "connections", no_default_uint }, > + * } > + * > + * settings_set_t *local_settings = NULL; > + * result = settings_set_create(mctx, default_settings, > + * sizeof(default_settings), &default_settings_set, > + * &local_settings); > + * @endcode > + */ > +isc_result_t > +settings_set_create(isc_mem_t *mctx, const setting_t default_settings[], > + const unsigned int default_set_length, const char *set_name, > + const settings_set_t *const parent_set, > + settings_set_t **target) { > + isc_result_t result = ISC_R_FAILURE; > + settings_set_t *new_set = NULL; > + > + REQUIRE(target != NULL && *target == NULL); > + REQUIRE(default_settings != NULL); > + REQUIRE(default_set_length > 0); > + > + CHECKED_MEM_ALLOCATE(mctx, new_set, default_set_length); > + ZERO_PTR(new_set); > + isc_mem_attach(mctx, &new_set->mctx); > + new_set->parent_set = parent_set; > + > + CHECKED_MEM_ALLOCATE(mctx, new_set->first_setting, default_set_length); > + memcpy(new_set->first_setting, default_settings, default_set_length); > + > + CHECKED_MEM_ALLOCATE(mctx, new_set->name, strlen(set_name) + 1); > + strcpy(new_set->name, set_name); > + > + *target = new_set; > + result = ISC_R_SUCCESS; > + > +cleanup: > + if (result != ISC_R_SUCCESS) > + settings_set_free(&new_set); > + > return result; > } > > -static isc_result_t > -set_default_value(setting_t *setting) > +/** > + * Free dynamically allocated memory associated with given set of settings. > + * @pre *set is initialized set of settings, set != NULL && *set != NULL > + * @post *set == NULL > + */ > +void > +settings_set_free(settings_set_t **set) { > + isc_mem_t *mctx = NULL; > + setting_t *s = NULL; > + > + if (set == NULL || *set == NULL) > + return; > + > + if ((*set)->mctx != NULL) { > + mctx = (*set)->mctx; > + for (s = (*set)->first_setting; s->name != NULL; s++) { > + if (s->is_dynamic) > + isc_mem_free(mctx, s->value.value_char); > + } > + if ((*set)->first_setting != NULL) > + isc_mem_free(mctx, (*set)->first_setting); > + isc_mem_free(mctx, (*set)->name); > + isc_mem_free(mctx, *set); > + isc_mem_detach(&mctx); > + } > + *set = NULL; > +} > + > +/** > + * Set all values specified by vector of strings to setting set. Setting name > + * is separated from it's argument with one or more characters defined by > + * @link SETTING_NAME_SEPARATORS at endlink. > + * > + * @retval ISC_R_SUCCESS All strings in argument vector were processed and set. > + * @retval Others Memory or parsing errors. > + * > + * @warning One string in argument vector is limited to > + * @link SETTING_LINE_MAXLENGTH at endlink. > + * > + * @note > + * @code{.txt} > + * Calling settings_set_fill() with argument array > + * > + * {"setting1 value 1 ", > + * "bind_dn cn=Directory manager" } > + * > + * will result in setting values to two separate settings: > + * > + * "setting1" = "value 1 " > + * "bind_dn" = "cn=Directory manager" > + * > + * Please note the positions of white spaces. > + * @endcode > + */ > +isc_result_t > +settings_set_fill(settings_set_t *set, const char *const *argv, > + isc_task_t *task) > { > - switch (setting->type) { > - case ST_LD_STRING: > - return set_value(setting, setting->default_value.value_char); > - break; > - case ST_SIGNED_INTEGER: > - *(signed *)setting->target = setting->default_value.value_sint; > - break; > - case ST_UNSIGNED_INTEGER: > - *(unsigned *)setting->target = setting->default_value.value_uint; > - break; > - case ST_BOOLEAN: > - *(isc_boolean_t *)setting->target = > - setting->default_value.value_boolean; > - break; > - default: > - fatal_error("unknown type in function set_default_value()"); > - return ISC_R_FAILURE; > + isc_result_t result; > + int i; > + const char *name; > + char *value; > + > + for (i = 0; argv[i] != NULL; i++) { > + char buff[SETTING_LINE_MAXLENGTH] = ""; > + CHECK(isc_string_copy(buff, SETTING_LINE_MAXLENGTH, argv[i])); > + value = buff; > + name = isc_string_separate(&value, SETTING_NAME_SEPARATORS); > + if (name == NULL || value == NULL) > + CLEANUP_WITH(ISC_R_UNEXPECTEDEND); > + value += strspn(value, SETTING_NAME_SEPARATORS); > + if (setting_find(name, set, ISC_FALSE, ISC_TRUE, NULL) > + != ISC_R_NOTFOUND) { > + log_error("multiple definitions of setting '%s' in " > + "set of settings '%s'", name, set->name); > + CLEANUP_WITH(ISC_R_EXISTS); > + } > + result = setting_set(name, set, value, task); > + if (result != ISC_R_SUCCESS && result != ISC_R_IGNORE) > + goto cleanup; > } > > return ISC_R_SUCCESS; > + > +cleanup: > + log_error_r("cannot parse settings from '%s': " > + "problematic configuration line:" > + "\n%s\n" > + "error code", set->name, argv[i]); > + /* TODO: Free memory in case of error. */ > + return result; > } > > -static const char * > -get_value_str(const char *arg) > -{ > - while (*arg != '\0' && !isspace(*arg)) > - arg++; > - while (*arg != '\0' && isspace(*arg)) > - arg++; > +/** > + * Check if all the settings in given set of setting have defined value, > + * possibly indirectly through parent set of settings. > + * > + * Error message is logged for each setting without defined value. > + * > + * @retval ISC_TRUE All settings have value defined. > + * @retval ISC_FALSE At least one setting do not have defined value. > + */ > +isc_boolean_t > +settings_set_isfilled(settings_set_t *set) { > + isc_result_t result; > + isc_boolean_t isfiled = ISC_TRUE; > + > + REQUIRE(set != NULL); > > - return arg; > + for (int i = 0; set->first_setting[i].name != NULL; i++) { > + const char *name = set->first_setting[i].name; > + result = setting_find(name, set, ISC_TRUE, ISC_TRUE, NULL); > + if (result != ISC_R_SUCCESS) { > + log_error_r("argument '%s' must be set " > + "in set of settings '%s'", name, set->name); > + isfiled = ISC_FALSE; > + } > + } > + return isfiled; > } > > isc_result_t > diff --git a/src/settings.h b/src/settings.h > index 53910ee11c2ac1f87db25fac8f24f5743f4312e4..454459692547d7481630e74f5600474e4f43d6ec 100644 > --- a/src/settings.h > +++ b/src/settings.h > @@ -1,7 +1,7 @@ > /* > * Authors: Martin Nagy > * > - * Copyright (C) 2009 Red Hat > + * Copyright (C) 2009-2012 Red Hat > * see file 'COPYING' for use and warranty information > * > * This program is free software; you can redistribute it and/or > @@ -23,28 +23,42 @@ > > #include > #include "types.h" > +#include "str.h" > +#include "ldap_entry.h" > + > +#define SETTING_LINE_MAXLENGTH 255 > +#define SETTING_NAME_SEPARATORS " \t" > +#define SETTING_SET_NAME_LOCAL "named.conf" > +#define SETTING_SET_NAME_GLOBAL "LDAP idnsConfig object" > +#define SETTING_SET_NAME_ZONE "LDAP idnsZone object" > > typedef struct setting setting_t; > +typedef struct settings_set settings_set_t; > > +/* Make sure that cases in get_value_ptr() are synchronized */ > typedef enum { > - ST_LD_STRING, > - ST_SIGNED_INTEGER, > + ST_STRING, > ST_UNSIGNED_INTEGER, > ST_BOOLEAN, > } setting_type_t; > > struct setting { > const char *name; > - int set; > - int has_a_default; > setting_type_t type; > union { > - const char *value_char; > - signed int value_sint; > - unsigned int value_uint; > + char *value_char; > + isc_uint32_t value_uint; > isc_boolean_t value_boolean; > - } default_value; > - void *target; > + } value; > + isc_boolean_t filled; > + isc_boolean_t is_dynamic; > +}; > + > +struct settings_set { > + isc_mem_t *mctx; > + char *name; > + const settings_set_t *parent_set; > + setting_t *first_setting; > }; > > /* > @@ -59,24 +73,56 @@ struct setting { > * "name", no_default_string, &target_variable > * } > */ > -#define default_string(val) 0, 1, ST_LD_STRING, { .value_char = (val) }, NULL > -#define default_sint(val) 0, 1, ST_SIGNED_INTEGER, { .value_sint = (val) }, NULL > -#define default_uint(val) 0, 1, ST_UNSIGNED_INTEGER, { .value_uint = (val) }, NULL > -#define default_boolean(val) 0, 1, ST_BOOLEAN, { .value_boolean = (val) }, NULL > +#define default_string(val) ST_STRING, { .value_char = (val) }, ISC_TRUE, ISC_FALSE > +#define default_uint(val) ST_UNSIGNED_INTEGER, { .value_uint = (val) }, ISC_TRUE, ISC_FALSE > +#define default_boolean(val) ST_BOOLEAN, { .value_boolean = (val) }, ISC_TRUE, ISC_FALSE > /* No defaults. */ > -#define no_default_string 0, 0, ST_LD_STRING, { .value_char = NULL }, NULL > -#define no_default_sint 0, 0, ST_SIGNED_INTEGER, { .value_sint = 0 }, NULL > -#define no_default_uint 0, 0, ST_UNSIGNED_INTEGER, { .value_uint = 0 }, NULL > -#define no_default_boolean 0, 1, ST_BOOLEAN, { .value_boolean = ISC_FALSE }, NULL > +#define no_default_string ST_STRING, { .value_char = NULL }, ISC_FALSE, ISC_FALSE > +#define no_default_uint ST_UNSIGNED_INTEGER, { .value_uint = 0 }, ISC_FALSE, ISC_FALSE > +#define no_default_boolean ST_BOOLEAN, { .value_boolean = ISC_FALSE }, ISC_FALSE, ISC_FALSE > > /* This is used in the end of setting_t arrays. */ > -#define end_of_settings { NULL, default_sint(0) } > +#define end_of_settings { NULL, default_uint(0) } > > /* > * Prototypes. > */ > isc_result_t > -set_settings(setting_t *settings, const char * const* argv); > +settings_set_create(isc_mem_t *mctx, const setting_t default_settings[], > + const unsigned int default_set_length, const char *set_name, > + const settings_set_t *const parent_set, > + settings_set_t **target); > + > +void > +settings_set_free(settings_set_t **set); > + > +isc_result_t > +settings_set_fill(settings_set_t *set, const char *const *argv, > + isc_task_t *task); > + > +isc_boolean_t > +settings_set_isfilled(settings_set_t *set); > + > +isc_result_t > +setting_get_uint(const char * const name, const settings_set_t * const set, > + isc_uint32_t * target); > + > +isc_result_t > +setting_get_str(const char * const name, const settings_set_t * const set, > + const char ** target); > + > +isc_result_t > +setting_get_bool(const char * const name, const settings_set_t * const set, > + isc_boolean_t * target); > + > +isc_result_t > +setting_set(const char *const name, const settings_set_t *set, > + const char *const value, isc_task_t *task); > + > +isc_result_t > +setting_update_from_ldap_entry(const char *name, settings_set_t *set, > + const char *attr_name, ldap_entry_t *entry, > + isc_task_t *task); > > isc_result_t > get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc); > diff --git a/src/zone_manager.c b/src/zone_manager.c > index c19c3b6c91ff8114fcb15eacba0f74ec46047986..efc2299c4cd3280dc688d14b77d0d721e1554284 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -31,6 +31,7 @@ > #include > > #include > +#include > > #include "ldap_convert.h" > #include "ldap_helper.h" > @@ -112,18 +113,13 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > { > isc_result_t result; > db_instance_t *db_inst = NULL; > - unsigned int zone_refresh; > + isc_uint32_t zone_refresh; > isc_boolean_t psearch; > isc_timermgr_t *timer_mgr; > isc_interval_t interval; > isc_timertype_t timer_type = isc_timertype_inactive; > isc_task_t *task; > - setting_t manager_settings[] = { > - { "zone_refresh", default_uint(0) }, > - { "psearch", default_boolean(0) }, > - { "verbose_checks", default_boolean(0) }, > - end_of_settings > - }; > + settings_set_t *local_settings = NULL; > > REQUIRE(name != NULL); > REQUIRE(dyndb_args != NULL); > @@ -137,12 +133,6 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > CLEANUP_WITH(ISC_R_EXISTS); > } > > - /* Parse settings. */ > - manager_settings[0].target = &zone_refresh; > - manager_settings[1].target = &psearch; > - manager_settings[2].target = &verbose_checks; /* global variable */ > - CHECK(set_settings(manager_settings, argv)); > - > CHECKED_MEM_GET_PTR(mctx, db_inst); > ZERO_PTR(db_inst); > > @@ -157,13 +147,14 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > * > * Timer must exist before refresh_zones_from_ldap() is called. */ > timer_mgr = dns_dyndb_get_timermgr(dyndb_args); > + > + local_settings = ldap_instance_getsettings_local(db_inst->ldap_inst); > + CHECK(setting_get_uint("zone_refresh", local_settings, &zone_refresh)); > + CHECK(setting_get_bool("psearch", local_settings, &psearch)); > + CHECK(setting_get_bool("verbose_checks", local_settings, &verbose_checks)); > + > isc_interval_set(&interval, zone_refresh, 0); > > - if (zone_refresh && psearch) { > - log_error("Zone refresh and persistent search are enabled at same time! " > - "Only persistent search will be used."); > - } > - > if (zone_refresh && !psearch) { > timer_type = isc_timertype_ticker; > } else { > diff --git a/src/zone_register.c b/src/zone_register.c > index e52397357f2ef482d8dfee33f7564cd9157afa56..e8d844f7bd1de83a6c894ea18fed127af081fd0f 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -27,12 +27,14 @@ > #include > #include > > +#include > #include > > #include "log.h" > #include "util.h" > #include "zone_register.h" > #include "rdlist.h" > +#include "settings.h" > > /* > * The zone register is a red-black tree that maps a dns name of a zone to the > @@ -47,19 +49,45 @@ struct zone_register { > isc_mem_t *mctx; > isc_rwlock_t rwlock; > dns_rbt_t *rbt; > + settings_set_t *global_settings; > }; > > typedef struct { > dns_zone_t *zone; > char *dn; > isc_uint32_t serial; /* last value processed by plugin (!= value in DB) */ > unsigned char digest[RDLIST_DIGESTLENGTH]; /* MD5 digest from all RRs in zone record */ > ldap_cache_t *cache; > + settings_set_t *settings; > } zone_info_t; > > /* Callback for dns_rbt_create(). */ > static void delete_zone_info(void *arg1, void *arg2); > > +/** > + * Zone specific settings from idnsZone object: > + * NAME 'idnsZone' > + * MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $ > + * idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ > + * idnsSOAminimum > + * ) > + * MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ > + * idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders > + * ) > + * > + * These structures are templates. They will be copied for each zone instance. > + */ > +static const setting_t zone_settings[] = { > + { "dyn_update", no_default_boolean }, > + { "update_policy", no_default_string }, > + { "allow_query", no_default_string }, > + { "allow_transfer", no_default_string }, > + { "sync_ptr", no_default_boolean }, > + { "forward_policy", no_default_string }, > + { "forwarders", no_default_string }, > + end_of_settings > +}; > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr) > { > @@ -77,7 +105,7 @@ zr_get_mctx(zone_register_t *zr) { > * Create a new zone register. > */ > isc_result_t > -zr_create(isc_mem_t *mctx, zone_register_t **zrp) > +zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp) > { > isc_result_t result; > zone_register_t *zr = NULL; > @@ -89,6 +117,7 @@ zr_create(isc_mem_t *mctx, zone_register_t **zrp) > isc_mem_attach(mctx, &zr->mctx); > CHECK(dns_rbt_create(mctx, delete_zone_info, mctx, &zr->rbt)); > CHECK(isc_rwlock_init(&zr->rwlock, 0, 0)); > + zr->global_settings = glob_settings; > > *zrp = zr; > return ISC_R_SUCCESS; > @@ -128,23 +157,31 @@ zr_destroy(zone_register_t **zrp) > /* > * Create a new zone info structure. > */ > +#define PRINT_BUFF_SIZE 255 > static isc_result_t > create_zone_info(isc_mem_t *mctx, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch, > - zone_info_t **zinfop) > + settings_set_t *global_settings, zone_info_t **zinfop) > { > isc_result_t result; > zone_info_t *zinfo; > + char settings_name[PRINT_BUFF_SIZE]; > > REQUIRE(zone != NULL); > REQUIRE(dn != NULL); > REQUIRE(zinfop != NULL && *zinfop == NULL); > > CHECKED_MEM_GET_PTR(mctx, zinfo); > ZERO_PTR(zinfo); > CHECKED_MEM_STRDUP(mctx, dn, zinfo->dn); > - CHECK(new_ldap_cache(mctx, cache_ttl, psearch, &zinfo->cache)); > + CHECK(new_ldap_cache(mctx, global_settings, &zinfo->cache)); > dns_zone_attach(zone, &zinfo->zone); > + zinfo->settings = NULL; > + isc_string_printf_truncate(settings_name, PRINT_BUFF_SIZE, > + SETTING_SET_NAME_ZONE " %s", > + dn); > + CHECK(settings_set_create(mctx, zone_settings, sizeof(zone_settings), > + settings_name, global_settings, > + &zinfo->settings)); > > *zinfop = zinfo; > return ISC_R_SUCCESS; > @@ -168,6 +205,7 @@ delete_zone_info(void *arg1, void *arg2) > return; > > destroy_ldap_cache(&zinfo->cache); > + settings_set_free(&zinfo->settings); > isc_mem_free(mctx, zinfo->dn); > dns_zone_detach(&zinfo->zone); > SAFE_MEM_PUT_PTR(mctx, zinfo); > @@ -178,8 +216,7 @@ delete_zone_info(void *arg1, void *arg2) > * must be absolute and the zone cannot already be in the zone register. > */ > isc_result_t > -zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch) > +zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn) > { > isc_result_t result; > dns_name_t *name; > @@ -210,7 +247,7 @@ zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > goto cleanup; > } > > - CHECK(create_zone_info(zr->mctx, zone, dn, cache_ttl, psearch, > + CHECK(create_zone_info(zr->mctx, zone, dn, zr->global_settings, > &new_zinfo)); > CHECK(dns_rbt_addname(zr->rbt, name, new_zinfo)); > > @@ -412,6 +449,37 @@ zr_get_zone_serial_digest(zone_register_t *zr, dns_name_t *name, > return result; > } > > +/* > + * Find a zone with origin 'name' within in the zone register 'zr'. If an > + * exact match is found, the pointer to the zone's settings is returned through > + * 'set'. > + */ > +isc_result_t > +zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set) > +{ > + isc_result_t result; > + void *zinfo = NULL; > + > + REQUIRE(zr != NULL); > + REQUIRE(name != NULL); > + REQUIRE(set != NULL && *set == NULL); > + > + if (!dns_name_isabsolute(name)) { > + log_bug("trying to find zone with a relative name"); > + return ISC_R_FAILURE; > + } > + > + RWLOCK(&zr->rwlock, isc_rwlocktype_read); > + > + result = dns_rbt_findname(zr->rbt, name, 0, NULL, &zinfo); > + if (result == ISC_R_SUCCESS) > + *set = ((zone_info_t *)zinfo)->settings; > + > + RWUNLOCK(&zr->rwlock, isc_rwlocktype_read); > + > + return result; > +} > + > /** > * Set last SOA serial and digest from RRs processed by autoincrement feature. > */ > diff --git a/src/zone_register.h b/src/zone_register.h > index cec7400ff893842d499d15f6897d448710ac5407..3f4114d2256c1e8af5f67c69f1829900c9c7b2e9 100644 > --- a/src/zone_register.h > +++ b/src/zone_register.h > @@ -22,18 +22,18 @@ > #define _LD_ZONE_REGISTER_H_ > > #include "cache.h" > +#include "settings.h" > > typedef struct zone_register zone_register_t; > > isc_result_t > -zr_create(isc_mem_t *mctx, zone_register_t **zrp); > +zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp); > > void > zr_destroy(zone_register_t **zrp); > > isc_result_t > -zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn, > - const isc_interval_t *cache_ttl, const isc_boolean_t *psearch); > +zr_add_zone(zone_register_t *zr, dns_zone_t *zone, const char *dn); > > isc_result_t > zr_del_zone(zone_register_t *zr, dns_name_t *origin); > @@ -51,6 +51,9 @@ zr_get_zone_dn(zone_register_t *zr, dns_name_t *name, const char **dn, > isc_result_t > zr_get_zone_ptr(zone_register_t *zr, dns_name_t *name, dns_zone_t **zonep); > > +isc_result_t > +zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set); > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From sbose at redhat.com Mon Mar 4 15:22:20 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 4 Mar 2013 16:22:20 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <1362146314.2962.130.camel@willson.li.ssimo.org> References: <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> Message-ID: <20130304152220.GW3633@localhost.localdomain> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: > On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > > On 03/01/2013 09:20 AM, Sumit Bose wrote: > > > On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > > >> On 02/28/2013 03:28 PM, Simo Sorce wrote: > > >>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > > >>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > > >>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > > >>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > > >>> > > >>>>>> Hi Sumit, > > >>>>>> > > >>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > > >>>>>> Though I would not add this service-specific setting to global IPA config object. > > >>>>>> > > >>>>>> I would rather like to see that in the service tree, for example as a > > >>>>>> configuration option of the service root which could be controlled with > > >>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > > >>>>>> > > >>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > > >>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > > >>>>>> # ipa serviceconfig-show > > >>>>>> Default PAC Map: nfs:NONE, cifs:PAD > > >>>>> > > >>>>> Are you thinking of having this in addition to the for-all-services > > >>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > > >>>>> like the first case because then three different objects needs to be > > >>>>> consulted to find out which is the right type. This wouldn't be an issue > > >>>>> for the plugin, but I think it is hard for the user/admin to follow. > > >>>> > > >>>> Hm, you are right. > > >>>> > > >>>>> > > >>>>> If the current defaults shall be dropped I think this is a major change > > >>>>> because it will require changes in the current CLI and WebUI which will > > >>>>> be visible to the users. I'm not against this change, I'm just wondering > > >>>>> if it is worth the effort for the next release? > > >>>>> > > >>>>> Maybe an argument to keep this is in global default is that the settings > > >>>>> are used for the host/*.* services as well which are in a different > > >>>>> sub-tree of the cn=accounts container. Additionally in future we might > > >>>>> want apply those setting to the user TGTs as well? > > >>>> > > >>>> Yeah, that was actually my point. That we are mixing service-specific PAC > > >>>> "rules" to the global setting. Which may be shared with host/*.* principals and > > >>>> user principals. This automatic PAC rules may require some designing so that is > > >>>> is generally usable. > > >>> > > >>> I think putting everything in the general config is more understandable > > >>> and discoverable. These per-service defaults are basically exceptions to > > >>> the general rule so it make sense to keep everything together. > > >>> > > >>> Simo. > > >>> > > >> > > >> Ok, if these are really just an exceptions to the general rule (and there will > > >> not be too many of them), I think we can leave it in config entry. But if we > > >> expect to have exceptions for other types of entries (hosts, users), I think we > > >> should rather use something like "service:nfs:NONE" do distinguish this exception. > > >> > > >> Question is, do we want to implement the interface and processing for that in > > >> current Sumit's patches or do we use that is they are? > > > > > > I would like to update the patches so that they can handle the > > > service:TYPE style entry and replace the current update code with just > > > adding nfs:NONE to the global options. I will update the design page > > > accordingly, too. > > > > Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > > be great. > > If we need to distinguish between service principals and user principals > I would prefer rather use a special keyword for upns > > service: is redundant and I do not want here to be able to say > upn:martin:NONE because per principal options are available on the > principal object. > > I actually really do not see the need for changing the default just for > user principals. If we are worried that one day we might want to really > have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we > might add upn:NONE and the lack of / will tell us this is not a service > named upn/foo.bar.baz but rather it means user principal names. > > However I do not see us ever really needing upn:NONE > > > > I would prefer if the enhancements needed for the CLI and WebUI can be > > > covered by other/new tickets, but I'm happy to add the needed > > > information to the design page too. > > > > > > bye, > > > Sumit > > > > I am OK with adding the interface for this special exception later. In that > > case, a ticket + note in the design as you mentioned would be enough. > > Ack. > > Simo. > Please find attached a new version of the patches. 0095 i(updating) is renamed and much simpler now. I opened https://fedorahosted.org/freeipa/ticket/3484 to added the needed change for 'service:TYPE' to CLI and WebUI. For the time being I've added patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it is not deleted accidentally when e.g. using the WebUI. If you do not like it it can simply be dropped, everything is working fine without it. bye, Sumit -------------- next part -------------- From 50c64c4db3601bba96e7aeadf6003628eea3282e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:59:00 +0100 Subject: [PATCH 094/101] Revert "MS-PAC: Special case NFS services" This reverts commit 5269458f552380759c86018cd1f30b64761be92e. With the implementation of https://fedorahosted.org/freeipa/ticket/2960 a special hardcoded handling of NFS service tickets is not needed anymore. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 36 +----------------------------------- 1 file changed, 1 insertion(+), 35 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 5071348d90dedf60f8140e0a53b07d09a947d31f..eafba97393cdda43d8a2a4616f65f2291ba08aa7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -743,24 +743,6 @@ static bool is_cross_realm_krbtgt(krb5_const_principal princ) return true; } -static bool is_service_of_type(krb5_const_principal princ, const char *type) -{ - size_t len; - - if (princ->length < 2) { - return false; - } - - len = strlen(type); - - if ((princ->data[0].length == len) || - (strncasecmp(princ->data[0].data, type, len) == 0)) { - return true; - } - - return false; -} - static char *gen_sid_string(TALLOC_CTX *memctx, struct dom_sid *dom_sid, uint32_t rid) { @@ -1555,7 +1537,6 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; - bool is_nfs = false; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1566,32 +1547,17 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } - /* NFS Server on Linux is limited and will choke on big tickets. - * So avoid attachnig the PAC to nfs/ tickets for now. - * FIXME: remove this when we have interface to support disabling - * PACs on arbitrary services */ - if (is_service_of_type(ks_client_princ, "nfs") || - is_service_of_type(server->princ, "nfs")) { - is_nfs = true; - } - is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { - if (is_nfs) { - *signed_auth_data = NULL; - kerr = 0; - goto done; - } - kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } } - if (!is_as_req & !is_nfs) { + if (!is_as_req) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 01b674384d3ac9fbfa652b9d9ed8d72cc5c9e946 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:25:43 +0100 Subject: [PATCH 095/101] Add NFS specific default for authorization data type Since the hardcoded default fpr the NFS service was removed the default authorization data type is now set in the global server configuration. --- install/updates/60-trusts.update | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index cd7a7e355230168f6ed9333505469a0aa7498ba9..454ecb745a9cf266a200f64cdea0b11872858113 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -71,6 +71,11 @@ replace:aci:'(targetattr = "userPassword || krbPrincipalKey || sambaLMPassword | dn: cn=ipaConfig,cn=etc,$SUFFIX addifnew: ipaKrbAuthzData: MS-PAC +# Add authorization data type NONE for NFS because the hardcoded default was +# removed. +dn: cn=ipaConfig,cn=etc,$SUFFIX +add: ipaKrbAuthzData: nfs:NONE + # Fix typo in some installs in the spelling of ORDERING. They were added # with a typo which was silently dropped by 389-ds-base, so add in the # proper ordering syntax now. -- 1.8.1.2 -------------- next part -------------- From 22d554cd6a2ea59229206e0eed60c7ebf631f8ad Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 11:01:11 +0100 Subject: [PATCH 096/101] ipa-kdb: Read global defaul ipaKrbAuthzData The ipaKrbAuthzData LDAP attribute is read from the ipaConfig object and the read value(s) are stored in the ipadb context. --- daemons/ipa-kdb/ipa_kdb.c | 27 ++++++++++++++++++++++++++- daemons/ipa-kdb/ipa_kdb.h | 3 +++ 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 2a344dc69158dbc3f6d0207ab0bb781676240ed9..e5c718ea9ffd38dbd49026e825d4a7f920638181 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -40,6 +40,8 @@ struct ipadb_context *ipadb_get_context(krb5_context kcontext) static void ipadb_context_free(krb5_context kcontext, struct ipadb_context **ctx) { + size_t c; + if (*ctx != NULL) { free((*ctx)->uri); free((*ctx)->base); @@ -51,6 +53,12 @@ static void ipadb_context_free(krb5_context kcontext, free((*ctx)->supp_encs); ipadb_mspac_struct_free(&(*ctx)->mspac); krb5_free_default_realm(kcontext, (*ctx)->realm); + + for (c = 0; (*ctx)->authz_data && (*ctx)->authz_data[c]; c++) { + free((*ctx)->authz_data[c]); + } + free((*ctx)->authz_data); + free(*ctx); *ctx = NULL; } @@ -167,13 +175,14 @@ done: int ipadb_get_global_configs(struct ipadb_context *ipactx) { - char *attrs[] = { "ipaConfigString", NULL }; + char *attrs[] = { "ipaConfigString", IPA_KRB_AUTHZ_DATA_ATTR, NULL }; struct berval **vals = NULL; LDAPMessage *res = NULL; LDAPMessage *first; char *base = NULL; int i; int ret; + char **authz_data_list; ret = asprintf(&base, "cn=ipaConfig,cn=etc,%s", ipactx->base); if (ret == -1) { @@ -215,6 +224,22 @@ int ipadb_get_global_configs(struct ipadb_context *ipactx) } } + ret = ipadb_ldap_attr_to_strlist(ipactx->lcontext, first, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + goto done; + } + if (ret == 0) { + if (ipactx->authz_data != NULL) { + for (i = 0; ipactx->authz_data[i]; i++) { + free(ipactx->authz_data[i]); + } + free(ipactx->authz_data); + } + + ipactx->authz_data = authz_data_list; + } + ret = 0; done: diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f472f02458e040b921b9f3f85bcc36fa954785d5..7b1576124140ae53cf28a1ed47bfa1acf31cdd59 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -74,6 +74,8 @@ #define IPA_SETUP "ipa-setup-override-restrictions" +#define IPA_KRB_AUTHZ_DATA_ATTR "ipaKrbAuthzData" + struct ipadb_mspac; struct ipadb_context { @@ -89,6 +91,7 @@ struct ipadb_context { struct ipadb_mspac *mspac; bool disable_last_success; bool disable_lockout; + char **authz_data; }; #define IPA_E_DATA_MAGIC 0x0eda7a -- 1.8.1.2 -------------- next part -------------- From 3fa054b938196925d9ce0849a02ecb26d5aa4719 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:44:32 +0100 Subject: [PATCH 097/101] ipa-kdb: Read ipaKrbAuthzData with other principal data The ipaKrbAuthzData LDAP attribute is read together with the other data of the requestedprincipal and the read value(s) are stored in the e-data of the entry for later use. --- daemons/ipa-kdb/ipa_kdb.h | 1 + daemons/ipa-kdb/ipa_kdb_principals.c | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 7b1576124140ae53cf28a1ed47bfa1acf31cdd59..9daaab80dc514dd1bb3e85775c1e284d19dac0cd 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -105,6 +105,7 @@ struct ipadb_e_data { char **pw_history; struct ipapwd_policy *pol; time_t last_admin_unlock; + char **authz_data; }; struct ipadb_context *ipadb_get_context(krb5_context kcontext); diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 13f6a21f1556668e8e9acd54f3d0e6a345eb00dc..11c155e64e20d16da98158eb4d7b8034803bf1de 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -63,6 +63,7 @@ static char *std_principal_attrs[] = { /* IPA SPECIFIC ATTRIBUTES */ "nsaccountlock", "passwordHistory", + IPA_KRB_AUTHZ_DATA_ATTR, "objectClass", NULL @@ -237,6 +238,7 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, krb5_kvno mkvno = 0; char **restrlist; char *restring; + char **authz_data_list; krb5_timestamp restime; bool resbool; int result; @@ -503,6 +505,17 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, ied->last_admin_unlock = restime; } + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + kerr = KRB5_KDB_INTERNAL_ERROR; + goto done; + } + if (ret == 0) { + ied->authz_data = authz_data_list; + } + + kerr = 0; done: @@ -831,6 +844,10 @@ void ipadb_free_principal(krb5_context kcontext, krb5_db_entry *entry) free(ied->pw_history[i]); } free(ied->pw_history); + for (i = 0; ied->authz_data && ied->authz_data[i]; i++) { + free(ied->authz_data[i]); + } + free(ied->authz_data); free(ied->pol); free(ied); } -- 1.8.1.2 -------------- next part -------------- From a408d744df3ab24e5201f9a31f50202ef315db38 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 14:02:27 +0100 Subject: [PATCH 098/101] ipa-kdb: add PAC only if requested Instead of always adding a PAC to the Kerberos ticket the global default for the authorization data and the authorization data of the service entry is evaluated and the PAC is added accordingly. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 114 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 112 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index eafba97393cdda43d8a2a4616f65f2291ba08aa7..daec6557ce95abb579f73825b386ba35f03cdc47 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -96,6 +96,10 @@ static char *memberof_pac_attrs[] = { #define SID_SUB_AUTHS 15 #define MAX(a,b) (((a)>(b))?(a):(b)) +#define AUTHZ_DATA_TYPE_PAC "MS-PAC" +#define AUTHZ_DATA_TYPE_PAD "PAD" +#define AUTHZ_DATA_TYPE_NONE "NONE" + static int string_to_sid(char *str, struct dom_sid *sid) { unsigned long val; @@ -1515,6 +1519,99 @@ done: return kerr; } +void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *_with_pac, bool *_with_pad) +{ + struct ipadb_e_data *ied = NULL; + struct ipadb_context *ipactx; + size_t c; + bool none_found = false; + char **authz_data_list; + bool with_pac = false; + bool with_pad = false; + char *sep; + krb5_data *service_type; + char *authz_data_type; + + if (entry != NULL) { + ied = (struct ipadb_e_data *) entry->e_data; + } + + if (ied == NULL || ied->authz_data == NULL) { + if (context == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing Kerberos context, no " \ + "authorization data will be added."); + goto done; + } + + ipactx = ipadb_get_context(context); + if (ipactx == NULL || ipactx->authz_data == NULL) { + krb5_klog_syslog(LOG_ERR, "No default authorization data types " \ + "available, no authorization data will " \ + "be added."); + goto done; + } + + authz_data_list = ipactx->authz_data; + } else { + authz_data_list = ied->authz_data; + } + + + for (c = 0; authz_data_list[c]; c++) { + authz_data_type = authz_data_list[c]; + sep = strchr(authz_data_list[c], ':'); + if (sep != NULL) { + if (entry->princ == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing principal in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + service_type = krb5_princ_component(context, entry->princ, 0); + if (service_type == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing service type in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + if (service_type->length == (sep - authz_data_list[c]) && + strncmp(authz_data_list[c], service_type->data, + service_type->length) == 0) { + authz_data_type = sep + 1; + } + } + + if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAC) == 0) { + with_pac = true; + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAD) == 0) { + with_pad = true; + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_NONE) == 0) { + none_found = true; + } else { + krb5_klog_syslog(LOG_ERR, "Ignoring unsupported " \ + "authorization data type [%s].", + authz_data_list[c]); + } + } + +done: + if (none_found) { + with_pac = false; + with_pad = false; + } + + if (_with_pac != NULL) { + *_with_pac = with_pac; + } + if (_with_pad != NULL) { + *_with_pad = with_pad; + } + +} + krb5_error_code ipadb_sign_authdata(krb5_context context, unsigned int flags, krb5_const_principal client_princ, @@ -1537,6 +1634,8 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; + bool with_pac; + bool with_pad; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1547,9 +1646,20 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } + /* We only need to check the server entry here, because even if the client + * is a service with a valid authorization data it will result to NONE + * because ipadb_get_pac() can only generate a pac for 'real' IPA users. + * (I assume this will be the same for PAD.) */ + get_authz_data_types(context, server, &with_pac, &with_pad); + + if (with_pad) { + krb5_klog_syslog(LOG_ERR, "PAD authorization data is requested but " \ + "currently not supported."); + } + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); - if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { + if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { @@ -1557,7 +1667,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, } } - if (!is_as_req) { + if (!is_as_req && with_pac) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 98926307294826c8f29e43a46f774cc66b7f452e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 19 Feb 2013 12:16:37 +0100 Subject: [PATCH 099/101] Add unit test for get_authz_data_types() --- daemons/ipa-kdb/Makefile.am | 29 +++++ daemons/ipa-kdb/tests/ipa_kdb_tests.c | 213 ++++++++++++++++++++++++++++++++++ 2 files changed, 242 insertions(+) create mode 100644 daemons/ipa-kdb/tests/ipa_kdb_tests.c diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am index 5f4e6e2a6a940486a0c904f737f28c476df98773..23ba1cc05ec157a0f4d9b594350ebaf10b2098dc 100644 --- a/daemons/ipa-kdb/Makefile.am +++ b/daemons/ipa-kdb/Makefile.am @@ -52,6 +52,35 @@ ipadb_la_LIBADD = \ $(NDRPAC_LIBS) \ $(NULL) +if HAVE_CHECK +TESTS = ipa_kdb_tests +check_PROGRAMS = ipa_kdb_tests +endif + +ipa_kdb_tests_SOURCES = \ + tests/ipa_kdb_tests.c \ + ipa_kdb.c \ + ipa_kdb_common.c \ + ipa_kdb_mkey.c \ + ipa_kdb_passwords.c \ + ipa_kdb_principals.c \ + ipa_kdb_pwdpolicy.c \ + ipa_kdb_mspac.c \ + ipa_kdb_delegation.c \ + ipa_kdb_audit_as.c \ + $(KRB5_UTIL_SRCS) \ + $(NULL) +ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS) +ipa_kdb_tests_LDADD = \ + $(CHECK_LIBS) \ + $(KRB5_LIBS) \ + $(LDAP_LIBS) \ + $(NDRPAC_LIBS) \ + -lnss3 \ + -lkdb5 \ + -lsss_idmap \ + $(NULL) + dist_noinst_DATA = ipa_kdb.exports EXTRA_DIST = \ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..ad30ae08fc1d941ed89c845dbd8182d8a9ad217f --- /dev/null +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -0,0 +1,213 @@ +/** 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) 2013 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#include +#include +#include +#include +#include +#include +#include + +#include "ipa-kdb/ipa_kdb.h" + +#define NFS_PRINC_STRING "nfs/fully.qualified.host.name at REALM.NAME" +#define NON_NFS_PRINC_STRING "abc/fully.qualified.host.name at REALM.NAME" + +int krb5_klog_syslog(int l, const char *format, ...) +{ + va_list ap; + char *s = NULL; + int ret; + + va_start(ap, format); + + ret = vasprintf(&s, format, ap); + va_end(ap); + if (ret < 0) { + /* ENOMEM */ + return -1; + } + + fprintf(stderr, "%s\n", s); + free(s); + + return 0; +} + +extern void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *with_pac, bool *with_pad); + +START_TEST(test_get_authz_data_types) +{ + bool with_pac; + bool with_pad; + krb5_db_entry *entry; + struct ipadb_e_data *ied; + size_t c; + char *ad_none_only[] = {"NONE", NULL}; + char *ad_pad_only[] = {"PAD", NULL}; + char *ad_pac_only[] = {"MS-PAC", NULL}; + char *ad_illegal_only[] = {"abc", NULL}; + char *ad_pac_and_pad[] = {"MS-PAC", "PAD", NULL}; + char *ad_pac_and_none[] = {"MS-PAC", "NONE", NULL}; + char *ad_none_and_pad[] = {"NONE", "PAD", NULL}; + char *ad_global_pac_nfs[] = {"MS-PAC", "nfs:NONE", NULL}; + krb5_context krb5_ctx; + krb5_error_code kerr; + struct ipadb_context *ipa_ctx; + krb5_principal nfs_princ; + krb5_principal non_nfs_princ; + + get_authz_data_types(NULL, NULL, NULL, NULL); + + with_pad = true; + get_authz_data_types(NULL, NULL, NULL, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, NULL); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + with_pad = true; + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + entry = calloc(1, sizeof(krb5_db_entry)); + fail_unless(entry != NULL, "calloc krb5_db_entry failed."); + + ied = calloc(1, sizeof(struct ipadb_e_data)); + fail_unless(ied != NULL, "calloc struct ipadb_e_data failed."); + entry->e_data = (void *) ied; + + kerr = krb5_init_context(&krb5_ctx); + fail_unless(kerr == 0, "krb5_init_context failed."); + kerr = krb5_db_setup_lib_handle(krb5_ctx); + fail_unless(kerr == 0, "krb5_db_setup_lib_handle failed.\n"); + ipa_ctx = calloc(1, sizeof(struct ipadb_context)); + fail_unless(ipa_ctx != NULL, "calloc failed.\n"); + ipa_ctx->kcontext = krb5_ctx; + kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); + fail_unless(kerr == 0, "krb5_db_set_context failed.\n"); + + kerr = krb5_parse_name(krb5_ctx, NFS_PRINC_STRING, &nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + kerr = krb5_parse_name(krb5_ctx, NON_NFS_PRINC_STRING, &non_nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + struct test_set { + char **authz_data; + char **global_authz_data; + krb5_principal princ; + bool exp_with_pac; + bool exp_with_pad; + const char *err_msg; + } test_set[] = { + {ad_none_only, NULL, NULL, false, false, "with only NONE in entry"}, + {ad_pac_only, NULL, NULL, true, false, "with only MS-PAC in entry"}, + {ad_pad_only, NULL, NULL, false, true, "with only PAD in entry"}, + {ad_illegal_only, NULL, NULL, false, false, "with only an invalid value in entry"}, + {ad_pac_and_pad, NULL, NULL, true, true, "with MS-PAC and PAD in entry"}, + {ad_pac_and_none, NULL, NULL, false, false, "with MS-PAC and NONE in entry"}, + {ad_none_and_pad, NULL, NULL, false, false, "with NONE and PAD in entry"}, + {NULL, ad_none_only, NULL, false, false, "with only NONE in global config"}, + {NULL, ad_pac_only, NULL, true, false, "with only MS-PAC in global config"}, + {NULL, ad_pad_only, NULL, false, true, "with only PAD in global config"}, + {NULL, ad_illegal_only, NULL, false, false, "with only an invalid value in global config"}, + {NULL, ad_pac_and_pad, NULL, true, true, "with MS-PAC and PAD in global config"}, + {NULL, ad_pac_and_none, NULL, false, false, "with MS-PAC and NONE in global config"}, + {NULL, ad_none_and_pad, NULL, false, false, "with NONE and PAD in global entry"}, + {NULL, ad_global_pac_nfs, NULL, true, false, "with NULL principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs, nfs_princ, false, false, "with nfs principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs, non_nfs_princ, true, false, "with non-nfs principal and PAC and nfs:NONE in global entry"}, + {ad_none_only, ad_pac_only, NULL, false, false, "with NONE overriding PAC in global entry"}, + {ad_pad_only, ad_pac_only, NULL, false, true, "with PAC overriding PAC in global entry"}, + {ad_illegal_only, ad_pac_only, NULL, false, false, "with invalid value overriding PAC in global entry"}, + {ad_pac_and_pad, ad_pac_only, NULL, true, true, "with PAC and PAD overriding PAC in global entry"}, + {ad_none_and_pad, ad_pac_only, NULL, false, false, "with NONE and PAD overriding PAC in global entry"}, + {NULL, NULL, NULL, false, false, NULL} + }; + + for (c = 0; test_set[c].authz_data != NULL || + test_set[c].global_authz_data != NULL; c++) { + ied->authz_data = test_set[c].authz_data; + ipa_ctx->authz_data = test_set[c].global_authz_data; + entry->princ = test_set[c].princ; + get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); + fail_unless(with_pad == test_set[c].exp_with_pad, "with_pad not %s %s.", + test_set[c].exp_with_pad ? "true" : "false", + test_set[c].err_msg); + fail_unless(with_pac == test_set[c].exp_with_pac, "with_pac not %s %s.", + test_set[c].exp_with_pac ? "true" : "false", + test_set[c].err_msg); + } + + krb5_free_principal(krb5_ctx, nfs_princ); + krb5_free_principal(krb5_ctx, non_nfs_princ); + krb5_db_fini(krb5_ctx); + krb5_free_context(krb5_ctx); +} +END_TEST + +Suite * ipa_kdb_suite(void) +{ + Suite *s = suite_create("IPA kdb"); + + TCase *tc_helper = tcase_create("Helper functions"); + tcase_add_test(tc_helper, test_get_authz_data_types); + suite_add_tcase(s, tc_helper); + + return s; +} + +int main(void) +{ + int number_failed; + + Suite *s = ipa_kdb_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; +} -- 1.8.1.2 -------------- next part -------------- From 82cb66279454e6c625ca409235e6b8e631eeb973 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 27 Feb 2013 10:32:40 +0100 Subject: [PATCH 100/101] Mention PAC issue with NFS in service plugin doc --- ipalib/plugins/service.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index a3d436e61eb7b7ef2958188a83055b53f52e2562..6b6634458a5980ed263e929365034a7d90bc5bb3 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -66,6 +66,11 @@ EXAMPLES: Override a default list of supported PAC types for the service: ipa service-mod HTTP/web.example.com --pac-type=MS-PAC + A typical use case where overriding the PAC type is needed is NFS. + Currently the related code in the Linux kernel can only handle Kerberos + tickets up to a maximal size. Since the PAC data can become quite large it + is recommended to set --pac-type=NONE for NFS services. + Delete an IPA service: ipa service-del HTTP/web.example.com @@ -258,7 +263,8 @@ class service(LDAPObject): cli_name='pac_type', label=_('PAC type'), doc=_("Override default list of supported PAC types." - " Use 'NONE' to disable PAC support for this service"), + " Use 'NONE' to disable PAC support for this service," + " e.g. this might be necessary for NFS services."), values=(u'MS-PAC', u'PAD', u'NONE'), csv=True, ), -- 1.8.1.2 -------------- next part -------------- From 3b61193647a1ac1dce24832260edc31f638a368b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:52:10 +0100 Subject: [PATCH 101/101] Allow 'nfs:NONE' in global configuration This patch adds 'nfs:NONE' as an allowed entry for the global authorization data type in the CLI and WebUI. This is an ad-hoc solution to make sure that the new default value for the NFS service is not removed by chance. This patch should be removed if a more generic solution is implemented to modify service:TYP style values of the authorization data type. --- API.txt | 2 +- install/ui/src/freeipa/serverconfig.js | 4 ++-- ipalib/plugins/config.py | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index a43fce596a6e01ba1fc709242ede0303994a255d..5ddda637175184d115396b1f394db1b45ae57de9 100644 --- a/API.txt +++ b/API.txt @@ -498,7 +498,7 @@ option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name=' option: Str('ipagroupobjectclasses', attribute=True, autofill=False, cli_name='groupobjectclasses', csv=True, multivalue=True, required=False) option: IA5Str('ipagroupsearchfields', attribute=True, autofill=False, cli_name='groupsearch', multivalue=False, required=False) option: IA5Str('ipahomesrootdir', attribute=True, autofill=False, cli_name='homedirectory', multivalue=False, required=False) -option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD')) +option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD', u'nfs:NONE')) option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False) option: Bool('ipamigrationenabled', attribute=True, autofill=False, cli_name='enable_migration', multivalue=False, required=False) option: Int('ipapwdexpadvnotify', attribute=True, autofill=False, cli_name='pwdexpnotify', minvalue=0, multivalue=False, required=False) diff --git a/install/ui/src/freeipa/serverconfig.js b/install/ui/src/freeipa/serverconfig.js index 347c46c1cb4daa94555c5a3272010d8a57e308de..1c6dd219bce5ba5ee010930b7e508c071680446f 100644 --- a/install/ui/src/freeipa/serverconfig.js +++ b/install/ui/src/freeipa/serverconfig.js @@ -102,7 +102,7 @@ IPA.serverconfig.entity = function(spec) { { name: 'ipakrbauthzdata', type: 'checkboxes', - options: IPA.create_options(['MS-PAC', 'PAD']) + options: IPA.create_options(['MS-PAC', 'PAD', 'nfs:NONE']) } ] } @@ -117,4 +117,4 @@ IPA.serverconfig.entity = function(spec) { IPA.register('config', IPA.serverconfig.entity); return {}; -}); \ No newline at end of file +}); diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py index db7fce7cb6ddea5e7364baf50eaa2e1a5b9f8021..33eb174ecc2c6af0463b475f3b87a734dd06f988 100644 --- a/ipalib/plugins/config.py +++ b/ipalib/plugins/config.py @@ -194,7 +194,7 @@ class config(LDAPObject): cli_name='pac_type', label=_('Default PAC types'), doc=_('Default types of PAC supported for services'), - values=(u'MS-PAC', u'PAD'), + values=(u'MS-PAC', u'PAD', u'nfs:NONE'), csv=True, ), ) -- 1.8.1.2 From rcritten at redhat.com Mon Mar 4 16:48:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Mar 2013 11:48:39 -0500 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <5134B6E1.7000203@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> Message-ID: <5134D067.3010603@redhat.com> Petr Viktorin wrote: [snip] >> --- a/ipaserver/ipaldap.py >> +++ b/ipaserver/ipaldap.py >> @@ -1775,6 +1775,8 @@ class IPAdmin(LDAPClient): >> if removes: >> if not force_replace: >> modlist.append((ldap.MOD_DELETE, key, removes)) >> + elif new_values == []: # delete an empty value >> + modlist.append((ldap.MOD_DELETE, key, removes)) > > I don't understand this change. AFAIK updateEntry/generateModList is > only used in ldapupdater now, and it's going away as soon as I can find > time to remove it. If you need to change it I'd like to know why. Things may have changed since the refactoring, I did the development against the old code then did some sanity checking. I'll take another look. This code lets one delete a single-valued attribute. If you want to delete a single-value attribute then force_replace will set so the delete will be lost. rob From edewata at redhat.com Mon Mar 4 17:14:28 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 04 Mar 2013 11:14:28 -0600 Subject: [Freeipa-devel] [PATCH] 263 Web UI: configurable SID blacklists In-Reply-To: <512258C9.5000803@redhat.com> References: <512258C9.5000803@redhat.com> Message-ID: <5134D674.4000008@redhat.com> On 2/18/2013 10:37 AM, Petr Vobornik wrote: > Added blacklists section, with ipantsidblacklistincoming and > ipantsidblacklistoutgoing multivalued textbox fields, into trust details > page. > > https://fedorahosted.org/freeipa/ticket/3289 ACK. -- Endi S. Dewata From tbabej at redhat.com Mon Mar 4 17:27:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 04 Mar 2013 18:27:22 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab Message-ID: <5134D97A.8030406@redhat.com> Hi, A host that has been previously unenrolled and does not have its host entry disabled or removed, can be re-enrolled using a previously backed up keytab file. A new option --keytab has been added to ipa-client-install. This can be used to specify path to the keytab and can be used instead of -p or -w options. A new option -f has been added to ipa-join. It forces client to join even if the host entry already exits. A new certificate, ssh keys are generated, ipaUniqueID stays the same. https://fedorahosted.org/freeipa/ticket/3374 Attaching a comparison between host entry states (enrolled using principal and reenrolled using keytab). Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0037-Add-support-for-re-enrolling-hosts-using-keytab.patch Type: text/x-patch Size: 7449 bytes Desc: not available URL: -------------- next part -------------- dn: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=br dn: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=br fqdn: vm-078.example.com fqdn: vm-078.example.com ipasshpubkey: ssh-dss AAAAB3NzaC1kc3MAAACBAOTFZwfVABE3UNjNgnSYRAMcfFPm7T/NiZ5z4VbyzrP+NJzjUdd+ | ipasshpubkey: ssh-dss AAAAB3NzaC1kc3MAAACBAOz9Jp42qxv3QvV3QoYOeLECuPpsVM1vrL4rS4MbKuSOPa6Nlu2Q ipasshpubkey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/Li43jjUraASij+4jHM9peFF0a0vXBH7252vQELhc | ipasshpubkey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDRG7ifJNlX3upFCzd6Yqmug9wVIswIj7epZyXconay has_password: False has_password: False has_keytab: True has_keytab: True subject: CN=vm-078.example.com,O=EXAMPLE.COM subject: CN=vm-078.example.com,O=EXAMPLE.COM serial_number: 15 | serial_number: 16 serial_number_hex: 0xF | serial_number_hex: 0x10 issuer: CN=Certificate Authority,O=EXAMPLE.COM issuer: CN=Certificate Authority,O=EXAMPLE.COM valid_not_before: Mon Mar 04 11:11:12 2013 UTC | valid_not_before: Mon Mar 04 11:51:11 2013 UTC valid_not_after: Thu Mar 05 11:11:12 2015 UTC | valid_not_after: Thu Mar 05 11:51:11 2015 UTC md5_fingerprint: 27:7e:df:49:1c:8a:9f:d9:ce:86:4a:eb:2b:d9:e3:63 | md5_fingerprint: d7:87:8d:7c:4f:ee:2d:27:c5:91:e5:f3:ab:4e:8c:de sha1_fingerprint: 4f:d9:45:d6:75:8b:53:1c:da:df:5c:d7:de:a5:6b:c4:70:14:92:20 | sha1_fingerprint: 15:d2:9a:81:78:b2:d7:92:91:45:70:4d:b8:ff:be:95:58:24:db:fe sshpubkeyfp: 18:0A:83:16:75:F9:79:3F:AF:F3:01:71:7D:C2:84:0B (ssh-dss) | sshpubkeyfp: 92:31:BD:3E:BF:B2:27:2A:CB:08:16:4F:BB:B8:F7:8A (ssh-dss) sshpubkeyfp: 9E:03:F0:A7:D2:B9:11:C6:44:25:40:93:3B:B1:42:33 (ssh-rsa) | sshpubkeyfp: 96:A7:2E:A3:B5:13:76:00:93:0B:0C:3A:72:59:F3:6B (ssh-rsa) cn: vm-078.example.com cn: vm-078.example.com enrolledBy: uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com enrolledBy: uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com ipaUniqueID: 37183b78-84bc-11e2-9fb3-001a4a22046a ipaUniqueID: 37183b78-84bc-11e2-9fb3-001a4a22046a krbExtraData: AAJMgTRRaG9zdC92bS0wNzguaWRtLmxhYi5lbmcuYnJxLnJlZGhhdC5jb21ASURNLkxBQi5FTkcuQlJR | krbExtraData: AAKrijRRaG9zdC92bS0wNzguaWRtLmxhYi5lbmcuYnJxLnJlZGhhdC5jb21ASURNLkxBQi5FTkcuQlJR krbLastPwdChange: 20130304111108Z | krbLastPwdChange: 20130304115107Z krbLastSuccessfulAuth: 20130304111115Z | krbLastSuccessfulAuth: 20130304115114Z krbPrincipalName: host/vm-078.example.com at EXAMPLE.COM krbPrincipalName: host/vm-078.example.com at EXAMPLE.COM managedBy: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=en managedBy: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=en managing: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng managing: fqdn=vm-078.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng objectClass: ipaobject objectClass: ipaobject objectClass: nshost objectClass: nshost objectClass: ipahost objectClass: ipahost objectClass: pkiuser objectClass: pkiuser objectClass: ipaservice objectClass: ipaservice objectClass: krbprincipalaux objectClass: krbprincipalaux objectClass: krbprincipal objectClass: krbprincipal objectClass: ieee802device objectClass: ieee802device objectClass: ipasshhost objectClass: ipasshhost objectClass: top objectClass: top objectClass: ipaSshGroupOfPubKeys objectClass: ipaSshGroupOfPubKeys serverHostName: vm-078 serverHostName: vm-078 userCertificate: MIIFHTCCBAWgAwIBAgIBDzANBgkqhkiG9w0BAQsFADBFMSMwIQYDVQQKExpJRE0uTEFCLkVORy5CU | userCertificate: MIIFHTCCBAWgAwIBAgIBEDANBgkqhkiG9w0BAQsFADBFMSMwIQYDVQQKExpJRE0uTEFCLkVORy5CU From jcholast at redhat.com Tue Mar 5 10:32:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 Mar 2013 11:32:54 +0100 Subject: [Freeipa-devel] [PATCH] 0189 Remove option to use custom SSL certificates from ipa-server-install In-Reply-To: <512CCBC9.2070407@redhat.com> References: <512CCBC9.2070407@redhat.com> Message-ID: <5135C9D6.7090204@redhat.com> Hi, On 26.2.2013 15:50, Petr Viktorin wrote: > This removes the --{dirsrv,http,pkinit}-{pkcs12,pin} options. > > https://fedorahosted.org/freeipa/ticket/3151 > > > The same options are in ipa-replica-prepare. I think we should leave > those be, so people with existing servers with custom certs can install > replicas. > Should we keep them visible, or should we make them hidden and remove them from documentation? Honza -- Jan Cholasta From pviktori at redhat.com Tue Mar 5 10:55:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 05 Mar 2013 11:55:41 +0100 Subject: [Freeipa-devel] [PATCH] 0189 Remove option to use custom SSL certificates from ipa-server-install In-Reply-To: <5135C9D6.7090204@redhat.com> References: <512CCBC9.2070407@redhat.com> <5135C9D6.7090204@redhat.com> Message-ID: <5135CF2D.2050407@redhat.com> On 03/05/2013 11:32 AM, Jan Cholasta wrote: > Hi, > > On 26.2.2013 15:50, Petr Viktorin wrote: >> This removes the --{dirsrv,http,pkinit}-{pkcs12,pin} options. >> >> https://fedorahosted.org/freeipa/ticket/3151 >> >> >> The same options are in ipa-replica-prepare. I think we should leave >> those be, so people with existing servers with custom certs can install >> replicas. >> > > Should we keep them visible, or should we make them hidden and remove > them from documentation? > > Honza > They have their own section in --help, with an explanation: SSL certificate options: Only used if the server was installed using custom SSL certificates I think that's enough. -- Petr? From mkosek at redhat.com Tue Mar 5 11:11:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Mar 2013 12:11:34 +0100 Subject: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf Message-ID: <5135D2E6.1000501@redhat.com> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential and tkey-domain and replace them with tkey-gssapi-keytab which avoids unnecessary Kerberos checks on BIND startup and can cause issues when KDC is not available. Both new and current IPA installations are updated. https://fedorahosted.org/freeipa/ticket/3429 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-376-update-named.conf-parser.patch Type: text/x-patch Size: 5421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-377-use-tkey-gssapi-keytab-in-named.conf.patch Type: text/x-patch Size: 5120 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 5 11:23:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Mar 2013 12:23:40 +0100 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation Message-ID: <5135D5BC.5030909@redhat.com> These relatively straightforward patches depend on each other, so I am sending them in bulk. Details can be found in commit messages. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-378-change-cname-and-dname-attributes-to-single-valued.patch Type: text/x-patch Size: 5397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-379-improve-cname-record-validation.patch Type: text/x-patch Size: 4875 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-380-improve-dname-record-validation.patch Type: text/x-patch Size: 7889 bytes Desc: not available URL: From tbabej at redhat.com Tue Mar 5 11:59:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 05 Mar 2013 12:59:02 +0100 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges Message-ID: <5135DE06.2080408@redhat.com> Hi, Any of the following checks: - overlap between primary RID range and secondary RID range - overlap between secondary RID range and secondary RID range is performed now only if both of the ranges involved are local domain ranges. https://fedorahosted.org/freeipa/ticket/3391 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0038-Perform-secondary-rid-range-overlap-check-for-local-.patch Type: text/x-patch Size: 3328 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 5 12:04:42 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 13:04:42 +0100 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <5135D5BC.5030909@redhat.com> References: <5135D5BC.5030909@redhat.com> Message-ID: <5135DF5A.4040902@redhat.com> Hello, please see my comments in-line. On 5.3.2013 12:23, Martin Kosek wrote: > These relatively straightforward patches depend on each other, so I am sending > them in bulk. Details can be found in commit messages. > > Martin > > > > freeipa-mkosek-379-improve-cname-record-validation.patch > > > From 5afde12a1a3d46a89af340e060fd1c687c7f4948 Mon Sep 17 00:00:00 2001 > From: Martin Kosek > Date: Mon, 4 Mar 2013 15:05:49 +0100 > Subject: [PATCH 2/3] Improve CNAME record validation > > Refacto DNS RR conflict validator so that it is better extensible in > the future. Also check that there is only one CNAME defined for > a DNS record. > > https://fedorahosted.org/freeipa/ticket/3450 > --- > ipalib/plugins/dns.py | 43 ++++++++++++++++++++++-------------- > tests/test_xmlrpc/test_dns_plugin.py | 8 +++++++ > 2 files changed, 35 insertions(+), 16 deletions(-) > > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index a23d1b8233eec14825ac6b43f509de51ad0ff1f7..a70d69fad181c90466467482a6ac604a166d728b 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -2267,23 +2267,34 @@ class dnsrecord(LDAPObject): > > def check_record_type_collisions(self, old_entry, entry_attrs): > # Test that only allowed combination of record types was created > - attrs = set(attr for attr in entry_attrs.keys() if attr in _record_attributes > - and entry_attrs[attr]) > - attrs.update(attr for attr in old_entry.keys() if attr not in entry_attrs) > + rrattrs = {} > + if old_entry is not None: > + old_rrattrs = dict((key, value) for key, value in old_entry.iteritems() > + if key in self.params and > + isinstance(self.params[key], DNSRecord)) > + rrattrs.update(old_rrattrs) > + new_rrattrs = dict((key, value) for key, value in entry_attrs.iteritems() > + if key in self.params and > + isinstance(self.params[key], DNSRecord)) > + rrattrs.update(new_rrattrs) > + > + # CNAME record validation > try: > - attrs.remove('cnamerecord') > + cnames = rrattrs['cnamerecord'] > except KeyError: > - rec_has_cname = False > + pass > else: > - rec_has_cname = True > - # CNAME and PTR record combination is allowed I remember some discussion about PTR and CNAMEs, but now I see that was silly. CNAME can't coexist with any other record (under same name). > - attrs.discard('ptrrecord') > - rec_has_other_types = True if attrs else False > - > - if rec_has_cname and rec_has_other_types: > - raise errors.ValidationError(name='cnamerecord', > - error=_('CNAME record is not allowed to coexist with any other ' > - 'records except PTR')) > + if cnames is not None: > + if len(cnames) > 1: > + raise errors.ValidationError(name='cnamerecord', > + error=_('only one CNAME record is allowed per name (RFC 6672)')) RFC 6672 defines DNAME, not CNAME. For CNAME please use "RFC 2136 section 1.1.5". RFCs are huge, so section numbers are really handy! > + if any(rrvalue is not None > + and rrattr != 'cnamerecord' > + and rrattr != 'ptrrecord' > + for rrattr, rrvalue in rrattrs.iteritems()): > + raise errors.ValidationError(name='cnamerecord', > + error=_('CNAME record is not allowed to coexist with any other ' > + 'records except PTR')) The same applies here - CNAME is not allowed to co-exist with any other type. > > api.register(dnsrecord) > > @@ -2433,7 +2444,7 @@ class dnsrecord_add(LDAPCreate): > try: > (dn_, old_entry) = ldap.get_entry(dn, _record_attributes) > except errors.NotFound: > - pass > + old_entry = None > else: > for attr in entry_attrs.keys(): > if attr not in _record_attributes: > @@ -2446,7 +2457,7 @@ class dnsrecord_add(LDAPCreate): > vals = list(entry_attrs[attr]) > entry_attrs[attr] = list(set(old_entry.get(attr, []) + vals)) > > - self.obj.check_record_type_collisions(old_entry, entry_attrs) > + self.obj.check_record_type_collisions(old_entry, entry_attrs) > return dn > > def exc_callback(self, keys, options, exc, call_func, *call_args, **call_kwargs): > diff --git a/tests/test_xmlrpc/test_dns_plugin.py b/tests/test_xmlrpc/test_dns_plugin.py > index 1902484949aeb0c96a0f2cda294fd3e6ae6e086f..7b2e5731395a52d26603d1d8fb2f061b7b7e1f8a 100644 > --- a/tests/test_xmlrpc/test_dns_plugin.py > +++ b/tests/test_xmlrpc/test_dns_plugin.py > @@ -785,6 +785,14 @@ class test_dns(Declarative): > ), > > dict( > + desc='Try to add multiple CNAME record %r using dnsrecord_add' % (dnsrescname), > + command=('dnsrecord_add', [dnszone1, dnsrescname], {'cnamerecord': > + [u'1.example.com.', u'2.example.com.']}), > + expected=errors.ValidationError(name='cnamerecord', > + error=u'only one CNAME record is allowed per name (RFC 6672)'), Please replace "RFC 6672" with "RFC 2136 section 1.1.5". > + ), > + > + dict( > desc='Add CNAME record to %r using dnsrecord_add' % (dnsrescname), > command=('dnsrecord_add', [dnszone1, dnsrescname], {'cnamerecord': u'foo-1.example.com.'}), > expected={ > -- 1.8.1.4 > freeipa-mkosek-380-improve-dname-record-validation.patch > + # DNAME record validation > + try: > + dnames = rrattrs['dnamerecord'] > + except KeyError: > + pass > + else: > + if dnames is not None: > + if len(dnames) > 1: > + raise errors.ValidationError(name='dnamerecord', > + error=_('only one DNAME record is allowed per name ' > + '(RFC 6672)')) Please replace "RFC 6672" with "?RFC 6672 section 2.4". > + # DNAME must not coexist with CNAME, but this is already checked earlier > + if rrattrs.get('nsrecord') and keys[1] != _dns_zone_record: > + raise errors.ValidationError(name='dnamerecord', > + error=_('DNAME record is not allowed to coexist with an ' > + 'NS record except when located in a zone root ' > + 'record (RFC 6672)')) Please replace "RFC 6672" with "?RFC 6672 section 2.3". Sorry for nitpicking :-) -- Petr^2 Spacek From pviktori at redhat.com Tue Mar 5 13:10:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 05 Mar 2013 14:10:17 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5134D97A.8030406@redhat.com> References: <5134D97A.8030406@redhat.com> Message-ID: <5135EEB9.6020705@redhat.com> On 03/04/2013 06:27 PM, Tomas Babej wrote: > Hi, > > A host that has been previously unenrolled and does not have its > host entry disabled or removed, can be re-enrolled using > a previously backed up keytab file. Thanks! The mechanism works, but see below. This is a RFE so it needs a design document. For context, I'll include your comment from trac: > From my investigation I would conclude that we cannot support client > install using backed-up keytab when the host has been unenrolled > (e.g. after running ipa-client-install --uninstall). When > unenrolling, we disable the host entry in LDAP and therefore > effectively disable the Kerberos key, SSL certificate and all > services of a host. > > We should only support reenrollment for clients that have not been > unenrolled, and therefore still have valid Kerberos key. I think it also makes sense from a security point of view: if the machine is compromised, I'd expect that after unenrolling it can't come back on its own. > A new option --keytab has been added to ipa-client-install. This > can be used to specify path to the keytab and can be used instead > of -p or -w options. With the patch this only works with --unatended; in interactive mode it still asks for the admin username and password. > A new option -f has been added to ipa-join. It forces client to > join even if the host entry already exits. A new certificate, > ssh keys are generated, ipaUniqueID stays the same. > https://fedorahosted.org/freeipa/ticket/3374 > > Attaching a comparison between host entry states > (enrolled using principal and reenrolled using keytab). > > Tomas > freeipa-tbabej-0037-Add-support-for-re-enrolling-hosts-using-keytab.patch > > >>From e576009bb7a93daec1cbc4ef94785017f80b2756 Mon Sep 17 00:00:00 2001 > From: Tomas Babej > Date: Tue, 26 Feb 2013 13:20:13 +0100 > Subject: [PATCH] Add support for re-enrolling hosts using keytab > > A host that has been previously unenrolled and does not have its > host entry disabled or removed, can be re-enrolled using > a previously backed up keytab file. I'd not say "unenrolled" here, unenrolling from IPA disables the host. [...] > diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install > index 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..e78b36a3c386184dc0cb1c83d8169890e3fa75da 100755 > --- a/ipa-client/ipa-install/ipa-client-install > +++ b/ipa-client/ipa-install/ipa-client-install > @@ -104,6 +104,8 @@ def parse_options(): > help="principal to use to join the IPA realm"), > basic_group.add_option("-w", "--password", dest="password", sensitive=True, > help="password to join the IPA realm (assumes bulk password unless principal is also set)"), > + basic_group.add_option("-k", "--keytab", dest="keytab", sensitive=True, > + help="path to backed up keytab from previous enrollment"), The keytab filename is not sensitive. [...] > > - if options.unattended and (options.password is None and options.principal is None and options.prompt_password is False) and not options.on_master: > + if options.unattended and (options.password is None and > + options.principal is None and > + options.keytab is None and > + options.prompt_password is False)\ > + and not options.on_master: Style issue: Wrap everything in the parentheses instead of using the backslash. [...] > + if returncode != 0: > + root_logger.error("Kerberos authentication failed " > + "using keytab: %s" % options.keytab) Use a comma instead of the % [...] I'm not a C expert but the ipa-join changes look fine. -- Petr? From jcholast at redhat.com Tue Mar 5 13:40:53 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 Mar 2013 14:40:53 +0100 Subject: [Freeipa-devel] [PATCH] 0189 Remove option to use custom SSL certificates from ipa-server-install In-Reply-To: <5135CF2D.2050407@redhat.com> References: <512CCBC9.2070407@redhat.com> <5135C9D6.7090204@redhat.com> <5135CF2D.2050407@redhat.com> Message-ID: <5135F5E5.7000406@redhat.com> On 5.3.2013 11:55, Petr Viktorin wrote: > On 03/05/2013 11:32 AM, Jan Cholasta wrote: >> Hi, >> >> On 26.2.2013 15:50, Petr Viktorin wrote: >>> This removes the --{dirsrv,http,pkinit}-{pkcs12,pin} options. >>> >>> https://fedorahosted.org/freeipa/ticket/3151 >>> >>> >>> The same options are in ipa-replica-prepare. I think we should leave >>> those be, so people with existing servers with custom certs can install >>> replicas. >>> >> >> Should we keep them visible, or should we make them hidden and remove >> them from documentation? >> >> Honza >> > > They have their own section in --help, with an explanation: > > SSL certificate options: > Only used if the server was installed using custom SSL certificates > > I think that's enough. > OK, makes sense. Please update ipa-server-install man page to reflect the changes. I think you can remove the pkcs12_info argument of {Ds,Krb}Instance.create_instance, as the only place where it was used is ipa-server-install. Honza -- Jan Cholasta From pspacek at redhat.com Tue Mar 5 14:30:36 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:30:36 +0100 Subject: [Freeipa-devel] [PATCH 0116] Fix crash caused by invalid wildcard in update policy string In-Reply-To: <20130304141549.GD2274@redhat.com> References: <512B7529.5080506@redhat.com> <20130304141549.GD2274@redhat.com> Message-ID: <5136018C.2060405@redhat.com> On 4.3.2013 15:15, Adam Tkac wrote: > On Mon, Feb 25, 2013 at 03:28:57PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Fix crash caused by invalid wildcard in update policy string. >> > >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/108 >> > >> >Question: >> >What we should do if update policy string contains an error? >> >Should we disable all updates? >> >Or let the old policy in place? >> >I vote for disallowing all updates. > +1. In my opinion disallowing all updates is correct. I will prepare separate patch for this. > Ack for the patch. Pushed to master and v2: 33bad9e66f346d40dc3510719898d03ccb79b2f4 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:30:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:30:44 +0100 Subject: [Freeipa-devel] [PATCH 0114] Log name of the zone if zone cannot be created In-Reply-To: <20130304140018.GB2274@redhat.com> References: <5124F259.8050203@redhat.com> <20130304140018.GB2274@redhat.com> Message-ID: <51360194.5000204@redhat.com> On 4.3.2013 15:00, Adam Tkac wrote: > On Wed, Feb 20, 2013 at 04:57:13PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Log name of the zone if zone cannot be created. > Ack Pushed to master and v2: 972108650e49f9070c39d7404acdfd9a8b43e263 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:30:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:30:49 +0100 Subject: [Freeipa-devel] [PATCH 0113] Periodically reconnect if Kerberos KDC is unavailable In-Reply-To: <20130304144622.GB4633@redhat.com> References: <511DF79A.4010804@redhat.com> <20130304144622.GB4633@redhat.com> Message-ID: <51360199.10801@redhat.com> On 4.3.2013 15:46, Adam Tkac wrote: > On Fri, Feb 15, 2013 at 09:53:46AM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Periodically reconnect if Kerberos KDC is unavailable. >> > >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/100 >> > >> >At the moment, Kerberos libraries contain a memory leak which will >> >be triggered by periodical reconnecting implemented in this ticket. >> > >> >https://bugzilla.redhat.com/show_bug.cgi?id=911110 >> >https://bugzilla.redhat.com/show_bug.cgi?id=911147 >> > >> >-- >> >Petr^2 Spacek > Ack Pushed to master and v2: d4db1cbc35575595b3144adf3dd7f3a885b0f5a7 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:30:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:30:54 +0100 Subject: [Freeipa-devel] [PATCH 0111] Automatically reload invalid zone after each change in zone data In-Reply-To: <20130304144529.GA4633@redhat.com> References: <511A2E38.10006@redhat.com> <20130304144529.GA4633@redhat.com> Message-ID: <5136019E.6050000@redhat.com> On 4.3.2013 15:45, Adam Tkac wrote: > On Tue, Feb 12, 2013 at 12:57:44PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Automatically reload invalid zone after each change in zone data. >> > >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > Ack Pushed to master and v2: 655f9b4afa4255c738a228038164215f3f1b91a5 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:31:01 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:31:01 +0100 Subject: [Freeipa-devel] [PATCH 0112] Make log messages related to Kerberos more verbose In-Reply-To: <20130304141739.GE2274@redhat.com> References: <511A3C84.4020205@redhat.com> <512E246C.7070702@redhat.com> <20130304141739.GE2274@redhat.com> Message-ID: <513601A5.9090102@redhat.com> On 4.3.2013 15:17, Adam Tkac wrote: > On Wed, Feb 27, 2013 at 04:21:16PM +0100, Petr Spacek wrote: >> >On 12.2.2013 13:58, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > > Make log messages related to Kerberos more verbose. >>> > > >>> > >This change should help people supporting bind-dyndb-ldap to figure out what >>> > >is happening under covers. >> > >> >Added explanatory error message for case where Kerberos context >> >initialization failed. > Ack Pushed to master and v2: 751587ea68c3b8e47a030746d11d42e497f2dfa7 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:46:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:46:21 +0100 Subject: [Freeipa-devel] [PATCH 0077] Refactor settings subsystem In-Reply-To: <20130304150624.GA5406@redhat.com> References: <5072D551.10703@redhat.com> <51237F79.4020006@redhat.com> <20130304135820.GA2274@redhat.com> <5134B3CF.9020704@redhat.com> <20130304150624.GA5406@redhat.com> Message-ID: <5136053D.8070100@redhat.com> On 4.3.2013 16:06, Adam Tkac wrote: > On Mon, Mar 04, 2013 at 03:46:39PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >amended patch is attached. > Ack Pushed to master: c74cfdaa02ccb206f40a2dff8b8ec6246d19be18 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 5 14:46:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 15:46:53 +0100 Subject: [Freeipa-devel] [PATCH 0115] Add support for DNAME substitution In-Reply-To: <20130304141424.GC2274@redhat.com> References: <51263B74.9080406@redhat.com> <51263CC7.6080900@redhat.com> <20130304141424.GC2274@redhat.com> Message-ID: <5136055D.8030005@redhat.com> On 4.3.2013 15:14, Adam Tkac wrote: > On Thu, Feb 21, 2013 at 04:27:03PM +0100, Petr Spacek wrote: >> >On 21.2.2013 16:21, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > > Add support for DNAME substitution. >>> > > >>> > > https://fedorahosted.org/bind-dyndb-ldap/ticket/63 >>> > > >> > >> >And now the patch:-) > Ack Pushed to master: e1122fde894946d5cf4aa209df4c7060bb877d0a -- Petr^2 Spacek From jcholast at redhat.com Tue Mar 5 15:12:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 Mar 2013 16:12:42 +0100 Subject: [Freeipa-devel] [PATCH] 0190 Fix installing server with external CA In-Reply-To: <5134AFC2.5040204@redhat.com> References: <5134AFC2.5040204@redhat.com> Message-ID: <51360B6A.1040004@redhat.com> Hi, On 4.3.2013 15:29, Petr Viktorin wrote: > I did not test the external CA case when we merged DS instances some > time ago, so it ended up broken. Here is a fix. > > > Our DsInstance class could only be initialized properly by calling > create_instance or create_replica. Fr step 2, when the DS is not being > installed, I gathered the common setup code to init_info, and called > that. Ideally this will one day end up in __init__, but that's for a > bigger refactoring. > > > https://fedorahosted.org/freeipa/ticket/3459 > I have tried installing IPA with external CA with your patch several times, and ipa-server-install always gets stuck while doing LDAP updates. I am not really sure how these two are connected. Can you please check if that happens to you on IPA from current master as well? Honza -- Jan Cholasta From pviktori at redhat.com Tue Mar 5 15:13:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 05 Mar 2013 16:13:48 +0100 Subject: [Freeipa-devel] [PATCH] 105 Fix remove while iterating in suppress_netgroup_memberof In-Reply-To: <512E1058.1080308@redhat.com> References: <512E1058.1080308@redhat.com> Message-ID: <51360BAC.1020305@redhat.com> On 02/27/2013 02:55 PM, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > ACK, thanks. -- Petr? From mkosek at redhat.com Tue Mar 5 16:13:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Mar 2013 17:13:58 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <20130304152220.GW3633@localhost.localdomain> References: <1361972238.2962.54.camel@willson.li.ssimo.org> <20130227174826.GF3633@localhost.localdomain> <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> Message-ID: <513619C6.8090402@redhat.com> On 03/04/2013 04:22 PM, Sumit Bose wrote: > On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: >> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: >>> On 03/01/2013 09:20 AM, Sumit Bose wrote: >>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: >>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: >>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: >>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: >>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: >>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: >>>>>> >>>>>>>>> Hi Sumit, >>>>>>>>> >>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. >>>>>>>>> Though I would not add this service-specific setting to global IPA config object. >>>>>>>>> >>>>>>>>> I would rather like to see that in the service tree, for example as a >>>>>>>>> configuration option of the service root which could be controlled with >>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: >>>>>>>>> >>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE >>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD >>>>>>>>> # ipa serviceconfig-show >>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD >>>>>>>> >>>>>>>> Are you thinking of having this in addition to the for-all-services >>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't >>>>>>>> like the first case because then three different objects needs to be >>>>>>>> consulted to find out which is the right type. This wouldn't be an issue >>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. >>>>>>> >>>>>>> Hm, you are right. >>>>>>> >>>>>>>> >>>>>>>> If the current defaults shall be dropped I think this is a major change >>>>>>>> because it will require changes in the current CLI and WebUI which will >>>>>>>> be visible to the users. I'm not against this change, I'm just wondering >>>>>>>> if it is worth the effort for the next release? >>>>>>>> >>>>>>>> Maybe an argument to keep this is in global default is that the settings >>>>>>>> are used for the host/*.* services as well which are in a different >>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might >>>>>>>> want apply those setting to the user TGTs as well? >>>>>>> >>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC >>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and >>>>>>> user principals. This automatic PAC rules may require some designing so that is >>>>>>> is generally usable. >>>>>> >>>>>> I think putting everything in the general config is more understandable >>>>>> and discoverable. These per-service defaults are basically exceptions to >>>>>> the general rule so it make sense to keep everything together. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Ok, if these are really just an exceptions to the general rule (and there will >>>>> not be too many of them), I think we can leave it in config entry. But if we >>>>> expect to have exceptions for other types of entries (hosts, users), I think we >>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. >>>>> >>>>> Question is, do we want to implement the interface and processing for that in >>>>> current Sumit's patches or do we use that is they are? >>>> >>>> I would like to update the patches so that they can handle the >>>> service:TYPE style entry and replace the current update code with just >>>> adding nfs:NONE to the global options. I will update the design page >>>> accordingly, too. >>> >>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd >>> be great. >> >> If we need to distinguish between service principals and user principals >> I would prefer rather use a special keyword for upns >> >> service: is redundant and I do not want here to be able to say >> upn:martin:NONE because per principal options are available on the >> principal object. >> >> I actually really do not see the need for changing the default just for >> user principals. If we are worried that one day we might want to really >> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we >> might add upn:NONE and the lack of / will tell us this is not a service >> named upn/foo.bar.baz but rather it means user principal names. >> >> However I do not see us ever really needing upn:NONE >> >>>> I would prefer if the enhancements needed for the CLI and WebUI can be >>>> covered by other/new tickets, but I'm happy to add the needed >>>> information to the design page too. >>>> >>>> bye, >>>> Sumit >>> >>> I am OK with adding the interface for this special exception later. In that >>> case, a ticket + note in the design as you mentioned would be enough. >> >> Ack. >> >> Simo. >> > > Please find attached a new version of the patches. 0095 i(updating) is > renamed and much simpler now. I opened > https://fedorahosted.org/freeipa/ticket/3484 to added the needed change > for 'service:TYPE' to CLI and WebUI. For the time being I've added > patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it > is not deleted accidentally when e.g. using the WebUI. If you do not > like it it can simply be dropped, everything is working fine without it. > > bye, > Sumit > Patch 0098: If this part does not match (and it will not for all non-nfs service principals): + if (service_type->length == (sep - authz_data_list[c]) && + strncmp(authz_data_list[c], service_type->data, + service_type->length) == 0) { + authz_data_type = sep + 1; + } krb5kdc.log will contain an error: Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported authorization data type [nfs:NONE]. Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for ldap/ipa.linux.ad.test at LINUX.AD.TEST I think we should just "continue" in this case. Otherwise, this looks and works fine. Martin From pspacek at redhat.com Tue Mar 5 16:24:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Mar 2013 17:24:26 +0100 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <507BEF22.8070708@redhat.com> References: <5072E75E.1050305@redhat.com> <20121009112157.GF2593@redhat.com> <50742B7B.2070205@redhat.com> <507BEF22.8070708@redhat.com> Message-ID: <51361C3A.6020606@redhat.com> On 15.10.2012 13:10, Petr Spacek wrote: > On 10/09/2012 03:49 PM, Petr Spacek wrote: >> On 10/09/2012 01:21 PM, Adam Tkac wrote: >>> On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: >>>> Hello, >>>> >>>> Use automatic connection management in LDAP modification code to >>>> prevent potential deadlock. >>>> >>>> Without this patch the plugin will deadlock when modify_ldap_common() >>>> is called with PTR synchronization enabled and only single >>>> connection is available in the connection pool. >>> >>> Nack >>> >>> If I read the patch correctly, it leaves unused ldap_conn parameters in >>> ldap_modify_do() and modify_soa_record() functions. >>> >>> Those params are always NULL so they can be safely removed. Please also remove >>> the "autoconn" variable from ldap_modify_do() >> >> My intent was to keep the same connection management abilities as are in >> ldap_query(): You can avoid repetitive ldap_pool_get/putconnection() calls by >> passing connection via parameter. >> >> I can remove it if it isn't worth. (Actually *_modify_*() functions do not use >> this capability now.) > > I forgot to send the patch after our discussion on IRC. Attached patch removes > unused parameters. Patch rebased on top of master branch. No functional changes. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0078-3-Use-automatic-connection-management-in-LDAP-modifica.patch Type: text/x-patch Size: 6334 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 5 16:27:28 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 Mar 2013 17:27:28 +0100 Subject: [Freeipa-devel] [PATCH] 0190 Fix installing server with external CA In-Reply-To: <51360B6A.1040004@redhat.com> References: <5134AFC2.5040204@redhat.com> <51360B6A.1040004@redhat.com> Message-ID: <51361CF0.30800@redhat.com> On 5.3.2013 16:12, Jan Cholasta wrote: > Hi, > > On 4.3.2013 15:29, Petr Viktorin wrote: >> I did not test the external CA case when we merged DS instances some >> time ago, so it ended up broken. Here is a fix. >> >> >> Our DsInstance class could only be initialized properly by calling >> create_instance or create_replica. Fr step 2, when the DS is not being >> installed, I gathered the common setup code to init_info, and called >> that. Ideally this will one day end up in __init__, but that's for a >> bigger refactoring. >> >> >> https://fedorahosted.org/freeipa/ticket/3459 >> > > I have tried installing IPA with external CA with your patch several > times, and ipa-server-install always gets stuck while doing LDAP > updates. I am not really sure how these two are connected. Can you > please check if that happens to you on IPA from current master as well? > > Honza > Turns out this was an error on my part. Sorry. ACK. Honza -- Jan Cholasta From mkosek at redhat.com Tue Mar 5 16:28:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Mar 2013 17:28:49 +0100 Subject: [Freeipa-devel] [PATCH] 0189 Remove option to use custom SSL certificates from ipa-server-install In-Reply-To: <5135F5E5.7000406@redhat.com> References: <512CCBC9.2070407@redhat.com> <5135C9D6.7090204@redhat.com> <5135CF2D.2050407@redhat.com> <5135F5E5.7000406@redhat.com> Message-ID: <51361D41.8060409@redhat.com> On 03/05/2013 02:40 PM, Jan Cholasta wrote: > On 5.3.2013 11:55, Petr Viktorin wrote: >> On 03/05/2013 11:32 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 26.2.2013 15:50, Petr Viktorin wrote: >>>> This removes the --{dirsrv,http,pkinit}-{pkcs12,pin} options. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3151 >>>> >>>> >>>> The same options are in ipa-replica-prepare. I think we should leave >>>> those be, so people with existing servers with custom certs can install >>>> replicas. >>>> >>> >>> Should we keep them visible, or should we make them hidden and remove >>> them from documentation? >>> >>> Honza >>> >> >> They have their own section in --help, with an explanation: >> >> SSL certificate options: >> Only used if the server was installed using custom SSL certificates >> >> I think that's enough. >> > > OK, makes sense. > > Please update ipa-server-install man page to reflect the changes. > > I think you can remove the pkcs12_info argument of > {Ds,Krb}Instance.create_instance, as the only place where it was used is > ipa-server-install. > > Honza > We had a discussion about this feature on a meeting today and we decided to not retire this feature after all and fix it instead. This decision retires patch 189 and https://fedorahosted.org/freeipa/ticket/3151. Martin From akrivoka at redhat.com Tue Mar 5 16:52:37 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 05 Mar 2013 17:52:37 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <512E2FF0.9040609@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> Message-ID: <513622D5.10705@redhat.com> On 02/27/2013 05:10 PM, Petr Vobornik wrote: > On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >> Add support for Realm Domains to web UI. >> >> https://fedorahosted.org/freeipa/ticket/3407 > > The patch looks good, but there is a issue we don't have a precedence > for. > > The mod command is doing dns check for new domains. Currently we can't > specify --force option to bypass the check. > > I see two possible implementations: > 1) On update, when user adds or modifies the values, a dialog would > pop up and ask user whether he wants to force it. > > 2) Another option is to disable edit on the list(deletion would be > still allowed) and move the add operation to separate action in action > list. > > I prefer the former. Latter might have issues with two modifications > (delete and add) at the same time at two different places (facet and > add dialog). Added force option to the error dialog. Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0007-02-Realm-Domains-page.patch Type: text/x-patch Size: 9926 bytes Desc: not available URL: From pvoborni at redhat.com Tue Mar 5 17:34:47 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Mar 2013 18:34:47 +0100 Subject: [Freeipa-devel] [WIP] Web UI Refactoring & plugins effort - current state Message-ID: <51362CB7.8000900@redhat.com> Hello, Sending current state of $subj. It's main purpose is to get rough review and design comments. Attaching patches of work done. The effort is documented at: http://pvoborni.fedorapeople.org/doc Navigation refactoring ---------------------- * http://pvoborni.fedorapeople.org/doc/navigation.html * almost implemented Plugin design ------------- * http://pvoborni.fedorapeople.org/doc/plugins.html * nothing implemented Known problems -------------- * http://pvoborni.fedorapeople.org/doc/known_problems.html Others ------ As a part of the effort I change some Web UI internals. Some of them are documented on pages: * http://pvoborni.fedorapeople.org/doc/phases.html * http://pvoborni.fedorapeople.org/doc/facet_public_state.html * http://pvoborni.fedorapeople.org/doc/registers.html NOTE: all doc pages are written in asciidoc, change extension from .html to .txt to get the source. I use it because our wiki doesn't handle source codes well. I plan to gradually create complete documentation of Web UI. I will create design page in our wiki later - should be less verbose. Update testing server with: $ util/sync.sh --host root at host.test -cC --dojo --misc --strings --restart $ util/sync.sh --host root at host.test -fc -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0444-jsl-update.patch Type: text/x-patch Size: 683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0445-update-dojo-build.patch Type: text/x-patch Size: 163722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0446-Basic-implementation-of-registers.patch Type: text/x-patch Size: 20461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0447-i18n.patch Type: text/x-patch Size: 2753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0448-phases.patch Type: text/x-patch Size: 9369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0449-Config.js.patch Type: text/x-patch Size: 2556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0450-Menu-model.patch Type: text/x-patch Size: 66991 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0451-Removed-old-navigation-code.patch Type: text/x-patch Size: 24641 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0452-Remove-IPA.nav-usage-obsolete-entity.get_primary_key.patch Type: text/x-patch Size: 63034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0453-fix-nested-facet-search.patch Type: text/x-patch Size: 2462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0454-remove-IPA.current_entity-usage.patch Type: text/x-patch Size: 9054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0455-Set-pkeys-to-add-remove-dialog.patch Type: text/x-patch Size: 5434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0456-File-dependencies-added-to-Web-UI-Makefile.patch Type: text/x-patch Size: 1080 bytes Desc: not available URL: From dpal at redhat.com Tue Mar 5 20:18:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 05 Mar 2013 15:18:19 -0500 Subject: [Freeipa-devel] [WIP] Web UI Refactoring & plugins effort - current state In-Reply-To: <51362CB7.8000900@redhat.com> References: <51362CB7.8000900@redhat.com> Message-ID: <5136530B.6070704@redhat.com> On 03/05/2013 12:34 PM, Petr Vobornik wrote: > Hello, > > Sending current state of $subj. It's main purpose is to get rough > review and design comments. > > Attaching patches of work done. > > The effort is documented at: http://pvoborni.fedorapeople.org/doc > > Navigation refactoring > ---------------------- > * http://pvoborni.fedorapeople.org/doc/navigation.html > * almost implemented > > Plugin design > ------------- > * http://pvoborni.fedorapeople.org/doc/plugins.html > * nothing implemented > > Known problems > -------------- > * http://pvoborni.fedorapeople.org/doc/known_problems.html > > Others > ------ > As a part of the effort I change some Web UI internals. Some of them > are documented on pages: > * http://pvoborni.fedorapeople.org/doc/phases.html > * http://pvoborni.fedorapeople.org/doc/facet_public_state.html > * http://pvoborni.fedorapeople.org/doc/registers.html > > NOTE: all doc pages are written in asciidoc, change extension from > .html to .txt to get the source. I use it because our wiki doesn't > handle source codes well. I plan to gradually create complete > documentation of Web UI. Please at least create a reference wiki page that has all the pointers to those pages. > > I will create design page in our wiki later - should be less verbose. > > Update testing server with: > $ util/sync.sh --host root at host.test -cC --dojo --misc --strings > --restart > $ util/sync.sh --host root at host.test -fc > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Mar 5 23:33:49 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 05 Mar 2013 17:33:49 -0600 Subject: [Freeipa-devel] [PATCH] 264-265 Web UI:Certificate pages In-Reply-To: <5127A039.6030902@redhat.com> References: <5127A039.6030902@redhat.com> Message-ID: <513680DD.3030806@redhat.com> On 2/22/2013 10:43 AM, Petr Vobornik wrote: > Note: static json files for testing and such will be updated soon (there > were several patch which changes API. I rather want to do one mass > regeneration than several minor ones in a short period of time. > > > 1) [PATCH] Web UI:Certificate pages > > Following pages were added to Web UI: > * certificated details > * certificate search > > Certificate is not regular object so it gets no metadata. Therefore > artificial metadata were created for it to allow usage of search and > details facet. > > Search and details facet were modified to allow removing of > add/remove/update/reset buttons - certificates have no mod operation and > they are not added by standard means. > > User can revoke and restore certificated in details facet. > > https://fedorahosted.org/freeipa/ticket/3419 I have some comments. Some of these can be postponed for future enhancements. 1. As previously discussed, the cert-find is only available with Dogtag CA, so the Certificates page should be disabled with self-signed CA. But if self-signed CA is dropped, then it's not necessary to disable the Certificates page. We may need to keep the ticket open until this is resolved one way or another. 2. Right now the fields in the cert details page are editable although there is no Update button. If you change the value an Undo button will appear. If you try to leave the page it will show the Unsaved Changes dialog. Since there's no cert-mod operation these fields should not be editable. 3. In the cert details page if you revoke the cert it will work but an error will appear below the revocation reason field saying 'Must be an integer'. 4. I think showing an empty revocation reason field on a valid cert is kind of weird. It might be better to create a Status section with two fields: status and revocation reason. If status is valid the revocation reason will be empty or hidden. If revoked then the reason will appear below the status. 5. In host/service details page the View link can be changed to go to the cert details page instead of showing a dialog box. 6. It would be better to organize the fields in the cert details page like the cert view dialog in host/service details page. 7. Certificate can be added/revoked/restored via certificate pages and host/service details pages. We need to make sure that if you do an operation on one page, the other pages won't show outdated information. > 2) [PATCH] Web UI:Choose different search option for cert-find > > This extends certificate search page by search option select. Therefore > the search is not restricted to 'subject'. > > It should be replaced by https://fedorahosted.org/freeipa/ticket/191 in > a future. > > https://fedorahosted.org/freeipa/ticket/3419 8. The revocation reason takes an integer. Probably the search field should change into a drop down list showing all available reasons. 9. The date options take a certain format (YYYY-MM-DD), so we should show the format probably as greyed text in the search field. 10. The current design only allows specifying one option at a time. Some of these options are meant to be used as a pair because they represent a range (min & max serial number). How about creating an Advanced Search dialog that shows all search options in separate fields so they can be combined? The basic search field can remain simple like the search field in other entities and it will search the cert subject only. 11. The list of search options is a drop down list, but it's surrounded by a rounded box like the text field next to it. This might be just a personal preference but I'm not sure if it's an appropriate look for a drop down list. -- Endi S. Dewata From mkosek at redhat.com Wed Mar 6 08:32:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 09:32:21 +0100 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <5135DF5A.4040902@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> Message-ID: <5136FF15.6080505@redhat.com> On 03/05/2013 01:04 PM, Petr Spacek wrote: > Hello, > > please see my comments in-line. > > On 5.3.2013 12:23, Martin Kosek wrote: >> These relatively straightforward patches depend on each other, so I am sending >> them in bulk. Details can be found in commit messages. >> >> Martin >> >> >> >> freeipa-mkosek-379-improve-cname-record-validation.patch >> >> >> From 5afde12a1a3d46a89af340e060fd1c687c7f4948 Mon Sep 17 00:00:00 2001 >> From: Martin Kosek >> Date: Mon, 4 Mar 2013 15:05:49 +0100 >> Subject: [PATCH 2/3] Improve CNAME record validation >> >> Refacto DNS RR conflict validator so that it is better extensible in >> the future. Also check that there is only one CNAME defined for >> a DNS record. >> >> https://fedorahosted.org/freeipa/ticket/3450 >> --- >> ipalib/plugins/dns.py | 43 ++++++++++++++++++++++-------------- >> tests/test_xmlrpc/test_dns_plugin.py | 8 +++++++ >> 2 files changed, 35 insertions(+), 16 deletions(-) >> >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index >> a23d1b8233eec14825ac6b43f509de51ad0ff1f7..a70d69fad181c90466467482a6ac604a166d728b >> 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -2267,23 +2267,34 @@ class dnsrecord(LDAPObject): >> >> def check_record_type_collisions(self, old_entry, entry_attrs): >> # Test that only allowed combination of record types was created >> - attrs = set(attr for attr in entry_attrs.keys() if attr in >> _record_attributes >> - and entry_attrs[attr]) >> - attrs.update(attr for attr in old_entry.keys() if attr not in >> entry_attrs) >> + rrattrs = {} >> + if old_entry is not None: >> + old_rrattrs = dict((key, value) for key, value in >> old_entry.iteritems() >> + if key in self.params and >> + isinstance(self.params[key], DNSRecord)) >> + rrattrs.update(old_rrattrs) >> + new_rrattrs = dict((key, value) for key, value in >> entry_attrs.iteritems() >> + if key in self.params and >> + isinstance(self.params[key], DNSRecord)) >> + rrattrs.update(new_rrattrs) >> + >> + # CNAME record validation >> try: >> - attrs.remove('cnamerecord') >> + cnames = rrattrs['cnamerecord'] >> except KeyError: >> - rec_has_cname = False >> + pass >> else: >> - rec_has_cname = True >> - # CNAME and PTR record combination is allowed > I remember some discussion about PTR and CNAMEs, but now I see that was silly. > CNAME can't coexist with any other record (under same name). > >> - attrs.discard('ptrrecord') >> - rec_has_other_types = True if attrs else False >> - >> - if rec_has_cname and rec_has_other_types: >> - raise errors.ValidationError(name='cnamerecord', >> - error=_('CNAME record is not allowed to coexist with >> any other ' >> - 'records except PTR')) >> + if cnames is not None: >> + if len(cnames) > 1: >> + raise errors.ValidationError(name='cnamerecord', >> + error=_('only one CNAME record is allowed per name >> (RFC 6672)')) > RFC 6672 defines DNAME, not CNAME. For CNAME please use "RFC 2136 section > 1.1.5". RFCs are huge, so section numbers are really handy! > >> + if any(rrvalue is not None >> + and rrattr != 'cnamerecord' >> + and rrattr != 'ptrrecord' >> + for rrattr, rrvalue in rrattrs.iteritems()): >> + raise errors.ValidationError(name='cnamerecord', >> + error=_('CNAME record is not allowed to coexist >> with any other ' >> + 'records except PTR')) > The same applies here - CNAME is not allowed to co-exist with any other type. > >> >> api.register(dnsrecord) >> >> @@ -2433,7 +2444,7 @@ class dnsrecord_add(LDAPCreate): >> try: >> (dn_, old_entry) = ldap.get_entry(dn, _record_attributes) >> except errors.NotFound: >> - pass >> + old_entry = None >> else: >> for attr in entry_attrs.keys(): >> if attr not in _record_attributes: >> @@ -2446,7 +2457,7 @@ class dnsrecord_add(LDAPCreate): >> vals = list(entry_attrs[attr]) >> entry_attrs[attr] = list(set(old_entry.get(attr, []) + vals)) >> >> - self.obj.check_record_type_collisions(old_entry, entry_attrs) >> + self.obj.check_record_type_collisions(old_entry, entry_attrs) >> return dn >> >> def exc_callback(self, keys, options, exc, call_func, *call_args, >> **call_kwargs): >> diff --git a/tests/test_xmlrpc/test_dns_plugin.py >> b/tests/test_xmlrpc/test_dns_plugin.py >> index >> 1902484949aeb0c96a0f2cda294fd3e6ae6e086f..7b2e5731395a52d26603d1d8fb2f061b7b7e1f8a >> 100644 >> --- a/tests/test_xmlrpc/test_dns_plugin.py >> +++ b/tests/test_xmlrpc/test_dns_plugin.py >> @@ -785,6 +785,14 @@ class test_dns(Declarative): >> ), >> >> dict( >> + desc='Try to add multiple CNAME record %r using dnsrecord_add' % >> (dnsrescname), >> + command=('dnsrecord_add', [dnszone1, dnsrescname], {'cnamerecord': >> + [u'1.example.com.', u'2.example.com.']}), >> + expected=errors.ValidationError(name='cnamerecord', >> + error=u'only one CNAME record is allowed per name (RFC 6672)'), > Please replace "RFC 6672" with "RFC 2136 section 1.1.5". > >> + ), >> + >> + dict( >> desc='Add CNAME record to %r using dnsrecord_add' % (dnsrescname), >> command=('dnsrecord_add', [dnszone1, dnsrescname], >> {'cnamerecord': u'foo-1.example.com.'}), >> expected={ >> -- 1.8.1.4 > > >> freeipa-mkosek-380-improve-dname-record-validation.patch >> + # DNAME record validation >> + try: >> + dnames = rrattrs['dnamerecord'] >> + except KeyError: >> + pass >> + else: >> + if dnames is not None: >> + if len(dnames) > 1: >> + raise errors.ValidationError(name='dnamerecord', >> + error=_('only one DNAME record is allowed per name ' >> + '(RFC 6672)')) > Please replace "RFC 6672" with "?RFC 6672 section 2.4". > >> + # DNAME must not coexist with CNAME, but this is already > checked earlier >> + if rrattrs.get('nsrecord') and keys[1] != _dns_zone_record: >> + raise errors.ValidationError(name='dnamerecord', >> + error=_('DNAME record is not allowed to coexist > with an ' >> + 'NS record except when located in a zone > root ' >> + 'record (RFC 6672)')) > Please replace "RFC 6672" with "?RFC 6672 section 2.3". > > Sorry for nitpicking :-) > Thanks, fixed version attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-378-2-change-cname-and-dname-attributes-to-single-valued.patch Type: text/x-patch Size: 5397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-379-2-improve-cname-record-validation.patch Type: text/x-patch Size: 7427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-380-2-improve-dname-record-validation.patch Type: text/x-patch Size: 7917 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 6 09:14:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 Mar 2013 10:14:16 +0100 Subject: [Freeipa-devel] [PATCH] 114 Remove disabled entries from sudoers compat tree Message-ID: <513708E8.1050700@redhat.com> Hi, this patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-114-Remove-disabled-entries-from-sudoers-compat-tree.patch Type: text/x-patch Size: 2133 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 6 09:31:57 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 Mar 2013 10:31:57 +0100 Subject: [Freeipa-devel] [PATCH] 115 Fix internal error in output_for_cli method of sudorule_{enable, disable} Message-ID: <51370D0D.7040207@redhat.com> Hi, this patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-115-Fix-internal-error-in-output_for_cli-method-of-sudor.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 6 09:40:39 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 10:40:39 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <513622D5.10705@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> Message-ID: <51370F17.1080802@redhat.com> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: > On 02/27/2013 05:10 PM, Petr Vobornik wrote: >> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>> Add support for Realm Domains to web UI. >>> >>> https://fedorahosted.org/freeipa/ticket/3407 >> >> The patch looks good, but there is a issue we don't have a precedence >> for. >> >> The mod command is doing dns check for new domains. Currently we can't >> specify --force option to bypass the check. >> >> I see two possible implementations: >> 1) On update, when user adds or modifies the values, a dialog would >> pop up and ask user whether he wants to force it. >> >> 2) Another option is to disable edit on the list(deletion would be >> still allowed) and move the add operation to separate action in action >> list. >> >> I prefer the former. Latter might have issues with two modifications >> (delete and add) at the same time at two different places (facet and >> add dialog). > > Added force option to the error dialog. > > Updated patch is attached. > 1) I think the dialog with the force should be shown before executing the operation. Sometimes, DNS check can take several seconds. There is no point for waiting for the error if you know that it will fail. 2) Regardless of #1. I don't think that just adding 'force' button without explaining the user what it means is the way to go. Previously (solution #1) I had in mind to show following dialog after clicking on 'update': ------------------------------------------------------- [Check DNS] ------------------------------------------------------- Do you also want to perform DNS check? [Check DNS] [Force Update] ------------------------------------------------------- Default button (confirm button) will be [Check DNS] -- Petr Vobornik From sbose at redhat.com Wed Mar 6 09:41:08 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 6 Mar 2013 10:41:08 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <513619C6.8090402@redhat.com> References: <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> Message-ID: <20130306094108.GA16010@localhost.localdomain> On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: > On 03/04/2013 04:22 PM, Sumit Bose wrote: > > On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: > >> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > >>> On 03/01/2013 09:20 AM, Sumit Bose wrote: > >>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > >>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: > >>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > >>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > >>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > >>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > >>>>>> > >>>>>>>>> Hi Sumit, > >>>>>>>>> > >>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > >>>>>>>>> Though I would not add this service-specific setting to global IPA config object. > >>>>>>>>> > >>>>>>>>> I would rather like to see that in the service tree, for example as a > >>>>>>>>> configuration option of the service root which could be controlled with > >>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > >>>>>>>>> > >>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > >>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > >>>>>>>>> # ipa serviceconfig-show > >>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD > >>>>>>>> > >>>>>>>> Are you thinking of having this in addition to the for-all-services > >>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > >>>>>>>> like the first case because then three different objects needs to be > >>>>>>>> consulted to find out which is the right type. This wouldn't be an issue > >>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. > >>>>>>> > >>>>>>> Hm, you are right. > >>>>>>> > >>>>>>>> > >>>>>>>> If the current defaults shall be dropped I think this is a major change > >>>>>>>> because it will require changes in the current CLI and WebUI which will > >>>>>>>> be visible to the users. I'm not against this change, I'm just wondering > >>>>>>>> if it is worth the effort for the next release? > >>>>>>>> > >>>>>>>> Maybe an argument to keep this is in global default is that the settings > >>>>>>>> are used for the host/*.* services as well which are in a different > >>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might > >>>>>>>> want apply those setting to the user TGTs as well? > >>>>>>> > >>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC > >>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and > >>>>>>> user principals. This automatic PAC rules may require some designing so that is > >>>>>>> is generally usable. > >>>>>> > >>>>>> I think putting everything in the general config is more understandable > >>>>>> and discoverable. These per-service defaults are basically exceptions to > >>>>>> the general rule so it make sense to keep everything together. > >>>>>> > >>>>>> Simo. > >>>>>> > >>>>> > >>>>> Ok, if these are really just an exceptions to the general rule (and there will > >>>>> not be too many of them), I think we can leave it in config entry. But if we > >>>>> expect to have exceptions for other types of entries (hosts, users), I think we > >>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. > >>>>> > >>>>> Question is, do we want to implement the interface and processing for that in > >>>>> current Sumit's patches or do we use that is they are? > >>>> > >>>> I would like to update the patches so that they can handle the > >>>> service:TYPE style entry and replace the current update code with just > >>>> adding nfs:NONE to the global options. I will update the design page > >>>> accordingly, too. > >>> > >>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > >>> be great. > >> > >> If we need to distinguish between service principals and user principals > >> I would prefer rather use a special keyword for upns > >> > >> service: is redundant and I do not want here to be able to say > >> upn:martin:NONE because per principal options are available on the > >> principal object. > >> > >> I actually really do not see the need for changing the default just for > >> user principals. If we are worried that one day we might want to really > >> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we > >> might add upn:NONE and the lack of / will tell us this is not a service > >> named upn/foo.bar.baz but rather it means user principal names. > >> > >> However I do not see us ever really needing upn:NONE > >> > >>>> I would prefer if the enhancements needed for the CLI and WebUI can be > >>>> covered by other/new tickets, but I'm happy to add the needed > >>>> information to the design page too. > >>>> > >>>> bye, > >>>> Sumit > >>> > >>> I am OK with adding the interface for this special exception later. In that > >>> case, a ticket + note in the design as you mentioned would be enough. > >> > >> Ack. > >> > >> Simo. > >> > > > > Please find attached a new version of the patches. 0095 i(updating) is > > renamed and much simpler now. I opened > > https://fedorahosted.org/freeipa/ticket/3484 to added the needed change > > for 'service:TYPE' to CLI and WebUI. For the time being I've added > > patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it > > is not deleted accidentally when e.g. using the WebUI. If you do not > > like it it can simply be dropped, everything is working fine without it. > > > > bye, > > Sumit > > > > Patch 0098: > > If this part does not match (and it will not for all non-nfs service principals): > > + if (service_type->length == (sep - authz_data_list[c]) && > + strncmp(authz_data_list[c], service_type->data, > + service_type->length) == 0) { > + authz_data_type = sep + 1; > + } > > krb5kdc.log will contain an error: > > Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported > authorization data type [nfs:NONE]. > Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 > 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 > ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for > ldap/ipa.linux.ad.test at LINUX.AD.TEST > > I think we should just "continue" in this case. good catch, fixed > > Otherwise, this looks and works fine. Thank you for the review, new version attached. I have an additional question about processing the service specific defaults. Using 'service:NONE' is unambiguous because NONE trumps all. But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think the first one where all defaults which apply to a service are added up is more clear, and this is also the way the current code works. But I wouldn't mind to change the logic if you think it makes more sense the other way round, i.e. if there is a service specific default matching the requested service only the service specific default are accounted. bye, Sumit > > Martin -------------- next part -------------- From 50c64c4db3601bba96e7aeadf6003628eea3282e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:59:00 +0100 Subject: [PATCH 094/101] Revert "MS-PAC: Special case NFS services" This reverts commit 5269458f552380759c86018cd1f30b64761be92e. With the implementation of https://fedorahosted.org/freeipa/ticket/2960 a special hardcoded handling of NFS service tickets is not needed anymore. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 36 +----------------------------------- 1 file changed, 1 insertion(+), 35 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 5071348d90dedf60f8140e0a53b07d09a947d31f..eafba97393cdda43d8a2a4616f65f2291ba08aa7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -743,24 +743,6 @@ static bool is_cross_realm_krbtgt(krb5_const_principal princ) return true; } -static bool is_service_of_type(krb5_const_principal princ, const char *type) -{ - size_t len; - - if (princ->length < 2) { - return false; - } - - len = strlen(type); - - if ((princ->data[0].length == len) || - (strncasecmp(princ->data[0].data, type, len) == 0)) { - return true; - } - - return false; -} - static char *gen_sid_string(TALLOC_CTX *memctx, struct dom_sid *dom_sid, uint32_t rid) { @@ -1555,7 +1537,6 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; - bool is_nfs = false; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1566,32 +1547,17 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } - /* NFS Server on Linux is limited and will choke on big tickets. - * So avoid attachnig the PAC to nfs/ tickets for now. - * FIXME: remove this when we have interface to support disabling - * PACs on arbitrary services */ - if (is_service_of_type(ks_client_princ, "nfs") || - is_service_of_type(server->princ, "nfs")) { - is_nfs = true; - } - is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { - if (is_nfs) { - *signed_auth_data = NULL; - kerr = 0; - goto done; - } - kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } } - if (!is_as_req & !is_nfs) { + if (!is_as_req) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 01b674384d3ac9fbfa652b9d9ed8d72cc5c9e946 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:25:43 +0100 Subject: [PATCH 095/101] Add NFS specific default for authorization data type Since the hardcoded default fpr the NFS service was removed the default authorization data type is now set in the global server configuration. --- install/updates/60-trusts.update | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index cd7a7e355230168f6ed9333505469a0aa7498ba9..454ecb745a9cf266a200f64cdea0b11872858113 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -71,6 +71,11 @@ replace:aci:'(targetattr = "userPassword || krbPrincipalKey || sambaLMPassword | dn: cn=ipaConfig,cn=etc,$SUFFIX addifnew: ipaKrbAuthzData: MS-PAC +# Add authorization data type NONE for NFS because the hardcoded default was +# removed. +dn: cn=ipaConfig,cn=etc,$SUFFIX +add: ipaKrbAuthzData: nfs:NONE + # Fix typo in some installs in the spelling of ORDERING. They were added # with a typo which was silently dropped by 389-ds-base, so add in the # proper ordering syntax now. -- 1.8.1.2 -------------- next part -------------- From 22d554cd6a2ea59229206e0eed60c7ebf631f8ad Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 11:01:11 +0100 Subject: [PATCH 096/101] ipa-kdb: Read global defaul ipaKrbAuthzData The ipaKrbAuthzData LDAP attribute is read from the ipaConfig object and the read value(s) are stored in the ipadb context. --- daemons/ipa-kdb/ipa_kdb.c | 27 ++++++++++++++++++++++++++- daemons/ipa-kdb/ipa_kdb.h | 3 +++ 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 2a344dc69158dbc3f6d0207ab0bb781676240ed9..e5c718ea9ffd38dbd49026e825d4a7f920638181 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -40,6 +40,8 @@ struct ipadb_context *ipadb_get_context(krb5_context kcontext) static void ipadb_context_free(krb5_context kcontext, struct ipadb_context **ctx) { + size_t c; + if (*ctx != NULL) { free((*ctx)->uri); free((*ctx)->base); @@ -51,6 +53,12 @@ static void ipadb_context_free(krb5_context kcontext, free((*ctx)->supp_encs); ipadb_mspac_struct_free(&(*ctx)->mspac); krb5_free_default_realm(kcontext, (*ctx)->realm); + + for (c = 0; (*ctx)->authz_data && (*ctx)->authz_data[c]; c++) { + free((*ctx)->authz_data[c]); + } + free((*ctx)->authz_data); + free(*ctx); *ctx = NULL; } @@ -167,13 +175,14 @@ done: int ipadb_get_global_configs(struct ipadb_context *ipactx) { - char *attrs[] = { "ipaConfigString", NULL }; + char *attrs[] = { "ipaConfigString", IPA_KRB_AUTHZ_DATA_ATTR, NULL }; struct berval **vals = NULL; LDAPMessage *res = NULL; LDAPMessage *first; char *base = NULL; int i; int ret; + char **authz_data_list; ret = asprintf(&base, "cn=ipaConfig,cn=etc,%s", ipactx->base); if (ret == -1) { @@ -215,6 +224,22 @@ int ipadb_get_global_configs(struct ipadb_context *ipactx) } } + ret = ipadb_ldap_attr_to_strlist(ipactx->lcontext, first, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + goto done; + } + if (ret == 0) { + if (ipactx->authz_data != NULL) { + for (i = 0; ipactx->authz_data[i]; i++) { + free(ipactx->authz_data[i]); + } + free(ipactx->authz_data); + } + + ipactx->authz_data = authz_data_list; + } + ret = 0; done: diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f472f02458e040b921b9f3f85bcc36fa954785d5..7b1576124140ae53cf28a1ed47bfa1acf31cdd59 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -74,6 +74,8 @@ #define IPA_SETUP "ipa-setup-override-restrictions" +#define IPA_KRB_AUTHZ_DATA_ATTR "ipaKrbAuthzData" + struct ipadb_mspac; struct ipadb_context { @@ -89,6 +91,7 @@ struct ipadb_context { struct ipadb_mspac *mspac; bool disable_last_success; bool disable_lockout; + char **authz_data; }; #define IPA_E_DATA_MAGIC 0x0eda7a -- 1.8.1.2 -------------- next part -------------- From 3fa054b938196925d9ce0849a02ecb26d5aa4719 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:44:32 +0100 Subject: [PATCH 097/101] ipa-kdb: Read ipaKrbAuthzData with other principal data The ipaKrbAuthzData LDAP attribute is read together with the other data of the requestedprincipal and the read value(s) are stored in the e-data of the entry for later use. --- daemons/ipa-kdb/ipa_kdb.h | 1 + daemons/ipa-kdb/ipa_kdb_principals.c | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 7b1576124140ae53cf28a1ed47bfa1acf31cdd59..9daaab80dc514dd1bb3e85775c1e284d19dac0cd 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -105,6 +105,7 @@ struct ipadb_e_data { char **pw_history; struct ipapwd_policy *pol; time_t last_admin_unlock; + char **authz_data; }; struct ipadb_context *ipadb_get_context(krb5_context kcontext); diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 13f6a21f1556668e8e9acd54f3d0e6a345eb00dc..11c155e64e20d16da98158eb4d7b8034803bf1de 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -63,6 +63,7 @@ static char *std_principal_attrs[] = { /* IPA SPECIFIC ATTRIBUTES */ "nsaccountlock", "passwordHistory", + IPA_KRB_AUTHZ_DATA_ATTR, "objectClass", NULL @@ -237,6 +238,7 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, krb5_kvno mkvno = 0; char **restrlist; char *restring; + char **authz_data_list; krb5_timestamp restime; bool resbool; int result; @@ -503,6 +505,17 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, ied->last_admin_unlock = restime; } + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + kerr = KRB5_KDB_INTERNAL_ERROR; + goto done; + } + if (ret == 0) { + ied->authz_data = authz_data_list; + } + + kerr = 0; done: @@ -831,6 +844,10 @@ void ipadb_free_principal(krb5_context kcontext, krb5_db_entry *entry) free(ied->pw_history[i]); } free(ied->pw_history); + for (i = 0; ied->authz_data && ied->authz_data[i]; i++) { + free(ied->authz_data[i]); + } + free(ied->authz_data); free(ied->pol); free(ied); } -- 1.8.1.2 -------------- next part -------------- From 81ed625953a0361651b69c988c4710d1a9cda620 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 14:02:27 +0100 Subject: [PATCH] ipa-kdb: add PAC only if requested Instead of always adding a PAC to the Kerberos ticket the global default for the authorization data and the authorization data of the service entry is evaluated and the PAC is added accordingly. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 118 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 116 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index eafba97393cdda43d8a2a4616f65f2291ba08aa7..adc4219dc47c68345a37a2fa3e6c973868080e70 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -96,6 +96,10 @@ static char *memberof_pac_attrs[] = { #define SID_SUB_AUTHS 15 #define MAX(a,b) (((a)>(b))?(a):(b)) +#define AUTHZ_DATA_TYPE_PAC "MS-PAC" +#define AUTHZ_DATA_TYPE_PAD "PAD" +#define AUTHZ_DATA_TYPE_NONE "NONE" + static int string_to_sid(char *str, struct dom_sid *sid) { unsigned long val; @@ -1515,6 +1519,103 @@ done: return kerr; } +void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *_with_pac, bool *_with_pad) +{ + struct ipadb_e_data *ied = NULL; + struct ipadb_context *ipactx; + size_t c; + bool none_found = false; + char **authz_data_list; + bool with_pac = false; + bool with_pad = false; + char *sep; + krb5_data *service_type; + char *authz_data_type; + + if (entry != NULL) { + ied = (struct ipadb_e_data *) entry->e_data; + } + + if (ied == NULL || ied->authz_data == NULL) { + if (context == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing Kerberos context, no " \ + "authorization data will be added."); + goto done; + } + + ipactx = ipadb_get_context(context); + if (ipactx == NULL || ipactx->authz_data == NULL) { + krb5_klog_syslog(LOG_ERR, "No default authorization data types " \ + "available, no authorization data will " \ + "be added."); + goto done; + } + + authz_data_list = ipactx->authz_data; + } else { + authz_data_list = ied->authz_data; + } + + + for (c = 0; authz_data_list[c]; c++) { + authz_data_type = authz_data_list[c]; + sep = strchr(authz_data_list[c], ':'); + if (sep != NULL) { + if (entry->princ == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing principal in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + service_type = krb5_princ_component(context, entry->princ, 0); + if (service_type == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing service type in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + if (service_type->length == (sep - authz_data_list[c]) && + strncmp(authz_data_list[c], service_type->data, + service_type->length) == 0) { + authz_data_type = sep + 1; + } else { + /* Service specific default does not apply, skipping this + * entry. */ + continue; + } + } + + if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAC) == 0) { + with_pac = true; + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAD) == 0) { + with_pad = true; + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_NONE) == 0) { + none_found = true; + } else { + krb5_klog_syslog(LOG_ERR, "Ignoring unsupported " \ + "authorization data type [%s].", + authz_data_list[c]); + } + } + +done: + if (none_found) { + with_pac = false; + with_pad = false; + } + + if (_with_pac != NULL) { + *_with_pac = with_pac; + } + if (_with_pad != NULL) { + *_with_pad = with_pad; + } + +} + krb5_error_code ipadb_sign_authdata(krb5_context context, unsigned int flags, krb5_const_principal client_princ, @@ -1537,6 +1638,8 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; + bool with_pac; + bool with_pad; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1547,9 +1650,20 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } + /* We only need to check the server entry here, because even if the client + * is a service with a valid authorization data it will result to NONE + * because ipadb_get_pac() can only generate a pac for 'real' IPA users. + * (I assume this will be the same for PAD.) */ + get_authz_data_types(context, server, &with_pac, &with_pad); + + if (with_pad) { + krb5_klog_syslog(LOG_ERR, "PAD authorization data is requested but " \ + "currently not supported."); + } + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); - if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { + if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { @@ -1557,7 +1671,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, } } - if (!is_as_req) { + if (!is_as_req && with_pac) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 98926307294826c8f29e43a46f774cc66b7f452e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 19 Feb 2013 12:16:37 +0100 Subject: [PATCH 099/101] Add unit test for get_authz_data_types() --- daemons/ipa-kdb/Makefile.am | 29 +++++ daemons/ipa-kdb/tests/ipa_kdb_tests.c | 213 ++++++++++++++++++++++++++++++++++ 2 files changed, 242 insertions(+) create mode 100644 daemons/ipa-kdb/tests/ipa_kdb_tests.c diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am index 5f4e6e2a6a940486a0c904f737f28c476df98773..23ba1cc05ec157a0f4d9b594350ebaf10b2098dc 100644 --- a/daemons/ipa-kdb/Makefile.am +++ b/daemons/ipa-kdb/Makefile.am @@ -52,6 +52,35 @@ ipadb_la_LIBADD = \ $(NDRPAC_LIBS) \ $(NULL) +if HAVE_CHECK +TESTS = ipa_kdb_tests +check_PROGRAMS = ipa_kdb_tests +endif + +ipa_kdb_tests_SOURCES = \ + tests/ipa_kdb_tests.c \ + ipa_kdb.c \ + ipa_kdb_common.c \ + ipa_kdb_mkey.c \ + ipa_kdb_passwords.c \ + ipa_kdb_principals.c \ + ipa_kdb_pwdpolicy.c \ + ipa_kdb_mspac.c \ + ipa_kdb_delegation.c \ + ipa_kdb_audit_as.c \ + $(KRB5_UTIL_SRCS) \ + $(NULL) +ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS) +ipa_kdb_tests_LDADD = \ + $(CHECK_LIBS) \ + $(KRB5_LIBS) \ + $(LDAP_LIBS) \ + $(NDRPAC_LIBS) \ + -lnss3 \ + -lkdb5 \ + -lsss_idmap \ + $(NULL) + dist_noinst_DATA = ipa_kdb.exports EXTRA_DIST = \ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..ad30ae08fc1d941ed89c845dbd8182d8a9ad217f --- /dev/null +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -0,0 +1,213 @@ +/** 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) 2013 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#include +#include +#include +#include +#include +#include +#include + +#include "ipa-kdb/ipa_kdb.h" + +#define NFS_PRINC_STRING "nfs/fully.qualified.host.name at REALM.NAME" +#define NON_NFS_PRINC_STRING "abc/fully.qualified.host.name at REALM.NAME" + +int krb5_klog_syslog(int l, const char *format, ...) +{ + va_list ap; + char *s = NULL; + int ret; + + va_start(ap, format); + + ret = vasprintf(&s, format, ap); + va_end(ap); + if (ret < 0) { + /* ENOMEM */ + return -1; + } + + fprintf(stderr, "%s\n", s); + free(s); + + return 0; +} + +extern void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *with_pac, bool *with_pad); + +START_TEST(test_get_authz_data_types) +{ + bool with_pac; + bool with_pad; + krb5_db_entry *entry; + struct ipadb_e_data *ied; + size_t c; + char *ad_none_only[] = {"NONE", NULL}; + char *ad_pad_only[] = {"PAD", NULL}; + char *ad_pac_only[] = {"MS-PAC", NULL}; + char *ad_illegal_only[] = {"abc", NULL}; + char *ad_pac_and_pad[] = {"MS-PAC", "PAD", NULL}; + char *ad_pac_and_none[] = {"MS-PAC", "NONE", NULL}; + char *ad_none_and_pad[] = {"NONE", "PAD", NULL}; + char *ad_global_pac_nfs[] = {"MS-PAC", "nfs:NONE", NULL}; + krb5_context krb5_ctx; + krb5_error_code kerr; + struct ipadb_context *ipa_ctx; + krb5_principal nfs_princ; + krb5_principal non_nfs_princ; + + get_authz_data_types(NULL, NULL, NULL, NULL); + + with_pad = true; + get_authz_data_types(NULL, NULL, NULL, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, NULL); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + with_pad = true; + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + entry = calloc(1, sizeof(krb5_db_entry)); + fail_unless(entry != NULL, "calloc krb5_db_entry failed."); + + ied = calloc(1, sizeof(struct ipadb_e_data)); + fail_unless(ied != NULL, "calloc struct ipadb_e_data failed."); + entry->e_data = (void *) ied; + + kerr = krb5_init_context(&krb5_ctx); + fail_unless(kerr == 0, "krb5_init_context failed."); + kerr = krb5_db_setup_lib_handle(krb5_ctx); + fail_unless(kerr == 0, "krb5_db_setup_lib_handle failed.\n"); + ipa_ctx = calloc(1, sizeof(struct ipadb_context)); + fail_unless(ipa_ctx != NULL, "calloc failed.\n"); + ipa_ctx->kcontext = krb5_ctx; + kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); + fail_unless(kerr == 0, "krb5_db_set_context failed.\n"); + + kerr = krb5_parse_name(krb5_ctx, NFS_PRINC_STRING, &nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + kerr = krb5_parse_name(krb5_ctx, NON_NFS_PRINC_STRING, &non_nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + struct test_set { + char **authz_data; + char **global_authz_data; + krb5_principal princ; + bool exp_with_pac; + bool exp_with_pad; + const char *err_msg; + } test_set[] = { + {ad_none_only, NULL, NULL, false, false, "with only NONE in entry"}, + {ad_pac_only, NULL, NULL, true, false, "with only MS-PAC in entry"}, + {ad_pad_only, NULL, NULL, false, true, "with only PAD in entry"}, + {ad_illegal_only, NULL, NULL, false, false, "with only an invalid value in entry"}, + {ad_pac_and_pad, NULL, NULL, true, true, "with MS-PAC and PAD in entry"}, + {ad_pac_and_none, NULL, NULL, false, false, "with MS-PAC and NONE in entry"}, + {ad_none_and_pad, NULL, NULL, false, false, "with NONE and PAD in entry"}, + {NULL, ad_none_only, NULL, false, false, "with only NONE in global config"}, + {NULL, ad_pac_only, NULL, true, false, "with only MS-PAC in global config"}, + {NULL, ad_pad_only, NULL, false, true, "with only PAD in global config"}, + {NULL, ad_illegal_only, NULL, false, false, "with only an invalid value in global config"}, + {NULL, ad_pac_and_pad, NULL, true, true, "with MS-PAC and PAD in global config"}, + {NULL, ad_pac_and_none, NULL, false, false, "with MS-PAC and NONE in global config"}, + {NULL, ad_none_and_pad, NULL, false, false, "with NONE and PAD in global entry"}, + {NULL, ad_global_pac_nfs, NULL, true, false, "with NULL principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs, nfs_princ, false, false, "with nfs principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs, non_nfs_princ, true, false, "with non-nfs principal and PAC and nfs:NONE in global entry"}, + {ad_none_only, ad_pac_only, NULL, false, false, "with NONE overriding PAC in global entry"}, + {ad_pad_only, ad_pac_only, NULL, false, true, "with PAC overriding PAC in global entry"}, + {ad_illegal_only, ad_pac_only, NULL, false, false, "with invalid value overriding PAC in global entry"}, + {ad_pac_and_pad, ad_pac_only, NULL, true, true, "with PAC and PAD overriding PAC in global entry"}, + {ad_none_and_pad, ad_pac_only, NULL, false, false, "with NONE and PAD overriding PAC in global entry"}, + {NULL, NULL, NULL, false, false, NULL} + }; + + for (c = 0; test_set[c].authz_data != NULL || + test_set[c].global_authz_data != NULL; c++) { + ied->authz_data = test_set[c].authz_data; + ipa_ctx->authz_data = test_set[c].global_authz_data; + entry->princ = test_set[c].princ; + get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); + fail_unless(with_pad == test_set[c].exp_with_pad, "with_pad not %s %s.", + test_set[c].exp_with_pad ? "true" : "false", + test_set[c].err_msg); + fail_unless(with_pac == test_set[c].exp_with_pac, "with_pac not %s %s.", + test_set[c].exp_with_pac ? "true" : "false", + test_set[c].err_msg); + } + + krb5_free_principal(krb5_ctx, nfs_princ); + krb5_free_principal(krb5_ctx, non_nfs_princ); + krb5_db_fini(krb5_ctx); + krb5_free_context(krb5_ctx); +} +END_TEST + +Suite * ipa_kdb_suite(void) +{ + Suite *s = suite_create("IPA kdb"); + + TCase *tc_helper = tcase_create("Helper functions"); + tcase_add_test(tc_helper, test_get_authz_data_types); + suite_add_tcase(s, tc_helper); + + return s; +} + +int main(void) +{ + int number_failed; + + Suite *s = ipa_kdb_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; +} -- 1.8.1.2 -------------- next part -------------- From 82cb66279454e6c625ca409235e6b8e631eeb973 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 27 Feb 2013 10:32:40 +0100 Subject: [PATCH 100/101] Mention PAC issue with NFS in service plugin doc --- ipalib/plugins/service.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index a3d436e61eb7b7ef2958188a83055b53f52e2562..6b6634458a5980ed263e929365034a7d90bc5bb3 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -66,6 +66,11 @@ EXAMPLES: Override a default list of supported PAC types for the service: ipa service-mod HTTP/web.example.com --pac-type=MS-PAC + A typical use case where overriding the PAC type is needed is NFS. + Currently the related code in the Linux kernel can only handle Kerberos + tickets up to a maximal size. Since the PAC data can become quite large it + is recommended to set --pac-type=NONE for NFS services. + Delete an IPA service: ipa service-del HTTP/web.example.com @@ -258,7 +263,8 @@ class service(LDAPObject): cli_name='pac_type', label=_('PAC type'), doc=_("Override default list of supported PAC types." - " Use 'NONE' to disable PAC support for this service"), + " Use 'NONE' to disable PAC support for this service," + " e.g. this might be necessary for NFS services."), values=(u'MS-PAC', u'PAD', u'NONE'), csv=True, ), -- 1.8.1.2 -------------- next part -------------- From 3b61193647a1ac1dce24832260edc31f638a368b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:52:10 +0100 Subject: [PATCH 101/101] Allow 'nfs:NONE' in global configuration This patch adds 'nfs:NONE' as an allowed entry for the global authorization data type in the CLI and WebUI. This is an ad-hoc solution to make sure that the new default value for the NFS service is not removed by chance. This patch should be removed if a more generic solution is implemented to modify service:TYP style values of the authorization data type. --- API.txt | 2 +- install/ui/src/freeipa/serverconfig.js | 4 ++-- ipalib/plugins/config.py | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index a43fce596a6e01ba1fc709242ede0303994a255d..5ddda637175184d115396b1f394db1b45ae57de9 100644 --- a/API.txt +++ b/API.txt @@ -498,7 +498,7 @@ option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name=' option: Str('ipagroupobjectclasses', attribute=True, autofill=False, cli_name='groupobjectclasses', csv=True, multivalue=True, required=False) option: IA5Str('ipagroupsearchfields', attribute=True, autofill=False, cli_name='groupsearch', multivalue=False, required=False) option: IA5Str('ipahomesrootdir', attribute=True, autofill=False, cli_name='homedirectory', multivalue=False, required=False) -option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD')) +option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD', u'nfs:NONE')) option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False) option: Bool('ipamigrationenabled', attribute=True, autofill=False, cli_name='enable_migration', multivalue=False, required=False) option: Int('ipapwdexpadvnotify', attribute=True, autofill=False, cli_name='pwdexpnotify', minvalue=0, multivalue=False, required=False) diff --git a/install/ui/src/freeipa/serverconfig.js b/install/ui/src/freeipa/serverconfig.js index 347c46c1cb4daa94555c5a3272010d8a57e308de..1c6dd219bce5ba5ee010930b7e508c071680446f 100644 --- a/install/ui/src/freeipa/serverconfig.js +++ b/install/ui/src/freeipa/serverconfig.js @@ -102,7 +102,7 @@ IPA.serverconfig.entity = function(spec) { { name: 'ipakrbauthzdata', type: 'checkboxes', - options: IPA.create_options(['MS-PAC', 'PAD']) + options: IPA.create_options(['MS-PAC', 'PAD', 'nfs:NONE']) } ] } @@ -117,4 +117,4 @@ IPA.serverconfig.entity = function(spec) { IPA.register('config', IPA.serverconfig.entity); return {}; -}); \ No newline at end of file +}); diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py index db7fce7cb6ddea5e7364baf50eaa2e1a5b9f8021..33eb174ecc2c6af0463b475f3b87a734dd06f988 100644 --- a/ipalib/plugins/config.py +++ b/ipalib/plugins/config.py @@ -194,7 +194,7 @@ class config(LDAPObject): cli_name='pac_type', label=_('Default PAC types'), doc=_('Default types of PAC supported for services'), - values=(u'MS-PAC', u'PAD'), + values=(u'MS-PAC', u'PAD', u'nfs:NONE'), csv=True, ), ) -- 1.8.1.2 From tbabej at redhat.com Wed Mar 6 12:04:31 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 06 Mar 2013 13:04:31 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5135EEB9.6020705@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> Message-ID: <513730CF.3010904@redhat.com> On 03/05/2013 02:10 PM, Petr Viktorin wrote: > Thanks! The mechanism works, but see below. > > This is a RFE so it needs a design document. > http://freeipa.org/page/V3/Client_install_using_keytab > For context, I'll include your comment from trac: > > From my investigation I would conclude that we cannot support client > > install using backed-up keytab when the host has been unenrolled > > (e.g. after running ipa-client-install --uninstall). When > > unenrolling, we disable the host entry in LDAP and therefore > > effectively disable the Kerberos key, SSL certificate and all > > services of a host. > > > > We should only support reenrollment for clients that have not been > > unenrolled, and therefore still have valid Kerberos key. > > I think it also makes sense from a security point of view: if the > machine is compromised, I'd expect that after unenrolling it can't > come back on its own. > Yes, that's also an issue here. >> A new option --keytab has been added to ipa-client-install. This >> can be used to specify path to the keytab and can be used instead >> of -p or -w options. > > With the patch this only works with --unatended; in interactive mode > it still asks for the admin username and password. Fixed. > >> A host that has been previously unenrolled and does not have its >> host entry disabled or removed, can be re-enrolled using >> a previously backed up keytab file. > > I'd not say "unenrolled" here, unenrolling from IPA disables the host. Reworded. > > [...] >> diff --git a/ipa-client/ipa-install/ipa-client-install >> b/ipa-client/ipa-install/ipa-client-install >> index >> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..e78b36a3c386184dc0cb1c83d8169890e3fa75da >> 100755 >> --- a/ipa-client/ipa-install/ipa-client-install >> +++ b/ipa-client/ipa-install/ipa-client-install >> @@ -104,6 +104,8 @@ def parse_options(): >> help="principal to use to join the IPA realm"), >> basic_group.add_option("-w", "--password", dest="password", >> sensitive=True, >> help="password to join the IPA realm (assumes >> bulk password unless principal is also set)"), >> + basic_group.add_option("-k", "--keytab", dest="keytab", >> sensitive=True, >> + help="path to backed up keytab from previous >> enrollment"), > > The keytab filename is not sensitive. Fixed. I misunderstood what the option stands for. > > [...] >> >> - if options.unattended and (options.password is None and >> options.principal is None and options.prompt_password is False) and >> not options.on_master: >> + if options.unattended and (options.password is None and >> + options.principal is None and >> + options.keytab is None and >> + options.prompt_password is False)\ >> + and not options.on_master: > > Style issue: Wrap everything in the parentheses instead of using the > backslash. Fixed. > > [...] >> + if returncode != 0: >> + root_logger.error("Kerberos authentication >> failed " >> + "using keytab: %s" % >> options.keytab) > Fixed. > Use a comma instead of the % > > [...] > > I'm not a C expert but the ipa-join changes look fine. > Thanks for the review, updated patches are attached. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0037-2-Add-support-for-re-enrolling-hosts-using-keytab.patch Type: text/x-patch Size: 8344 bytes Desc: not available URL: From pspacek at redhat.com Wed Mar 6 12:07:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 Mar 2013 13:07:38 +0100 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <5136FF15.6080505@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> Message-ID: <5137318A.2010505@redhat.com> On 6.3.2013 09:32, Martin Kosek wrote: > + error=u'CNAME record is not allowed to coexist with any other record'), Sorry for nitpicking again, but I would add note '(RFC 1034, section 3.6.2)'. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Wed Mar 6 12:30:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 Mar 2013 13:30:26 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <513730CF.3010904@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> Message-ID: <513736E2.7090104@redhat.com> On 6.3.2013 13:04, Tomas Babej wrote: > On 03/05/2013 02:10 PM, Petr Viktorin wrote: >> Thanks! The mechanism works, but see below. >> >> This is a RFE so it needs a design document. >> > http://freeipa.org/page/V3/Client_install_using_keytab I added "Security Considerations" section with couple questions inside. Please add more details about un-enrolling process, pre-requirements and so on. -- Petr^2 Spacek From pvoborni at redhat.com Wed Mar 6 12:37:06 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 13:37:06 +0100 Subject: [Freeipa-devel] [PATCH] 259 Combobox keyboard support In-Reply-To: <5132553C.9010606@redhat.com> References: <940957870.1823903.1361926213062.JavaMail.root@redhat.com> <512E021F.5030004@redhat.com> <5132553C.9010606@redhat.com> Message-ID: <51373872.2050409@redhat.com> On 03/02/2013 08:38 PM, Endi Sukma Dewata wrote: > On 02/27/2013 06:54 AM, Petr Vobornik wrote: >> On 02/27/2013 01:50 AM, Endi Sukma Dewata wrote: >> >>> Another minor thing, if the search box is in focus, you can use the >>> Up/Down arrow to go to the list. However, from the list you cannot >>> use the Up/Down arrow to go back to the search box, you'd have to use >>> the Tab key. It's not really a problem, but it's not that consistent. >> Up/Down keys are natural way of changing value of a list - this part >> seems OK to me. So Up/Down arrow in search box might the problem, but >> I consider it a feature - saves some strokes. Also, User can always >> use tab to switch between search box and list. > > I'm OK with the Up/Down arrow in search box too, but if it's not > consistent people may think it's a bug. So I'd suggest we make it such > that you can use Up/Down to go back to the search box. Up/Down doesn't just go to the list but it also changes the selected item in the list. So we might say that it's consistent - it changes selected item. I might agree that going from search box to list is wrong or misleading but I'm strongly against going back to search box using Up/Down keys. It would be redefining of implicit behavior of select element. > > All of the above are minor. The patch itself is ACKed. > Anyway, pushed to master -- Petr Vobornik From pvoborni at redhat.com Wed Mar 6 12:42:59 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 13:42:59 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513255B4.8020903@redhat.com> References: <513255B4.8020903@redhat.com> Message-ID: <513739D3.7090606@redhat.com> On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: > ----- Original Message ----- >> First two patches are bug fixes which are required for third patch. >> Depends on my patch #259 (Combobox keyboard support) >> >> 1) [PATCH] Fix dirty state update of editable combobox >> >> Editable combobox didn't update it's dirty state correctly. CB had >> it's own internal value changed event, which was incorrectly used. It was >> removed and widget's value_changed event was used instead. > > ACK. Pushed to master > >> 2) [PATCH] Fix handling of no_update flag in Web UI >> >> There was an incorrect check for no_update flag. Check was performed >> as if the flag was an attribute of object not an item of array. Hence, >> the flag never caused any effect. > > ACK. Pushed to master > >> 3) [PATCH] Global trust config page >> >> https://fedorahosted.org/freeipa/ticket/3333 > >> Just two notes: >> >> ipantfallbackprimarygroup requires a posix group. Our API currently >> doesn't support search based on object classes therefore the entity >> select widget incorrectly offers non posix groups as well. > > Are we planning to add the missing functionality? Right now you'll get > 'group not found' if you select a non-POSIX group, which is confusing > because the group does exist. Possible solutions: Waiting for "[RFE] Add option for filtering groups by type (posix,..) in group-find command" to be implemented to solve issue. > > 1. Fix the error message to say ' is not a POSIX group' or > 'Fallback primary group requires a POSIX group'. > > 2. Execute another batch of group-show operations to get the object > classes of the groups to be displayed and filter out the non-POSIX groups. > >> Another problem is that hidden 'Default SMB Group' is not listed. >> Hence it couldn't be set again after a modification. I made the combobox >> editable (first usage, so it revealed a bug) to avoid this problem. >> User can enter garbage, but the framework should handle that. > > This is a little difficult to use. You'll need to know that you have to > type 'Default SMB Group' to go back to the default and the UI doesn't > show that as an acceptable value. Possible solutions: > > 1. Add the 'Default SMB Group' as the first entry in the drop down list > so you can reselect it again. The drop down list doesn't need to be > editable. > > 2. Use radio buttons to separate the default value from other values: > > Fallback primary group: (o) Default SMB Group > ( ) POSIX group: [ drop down list ] > > Regardless, I think the server API needs to be changed to accept an > empty value to go back to the default value instead of taking 'Default > SMB Group'. A default value should be simple and not something that will > potentially conflict with a non-default value that happens to have the > same name. I agree. Martin is it feasible? > > -- > Endi S. Dewata -- Petr Vobornik From pvoborni at redhat.com Wed Mar 6 12:25:03 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 13:25:03 +0100 Subject: [Freeipa-devel] [PATCH] 263 Web UI: configurable SID blacklists In-Reply-To: <5134D674.4000008@redhat.com> References: <512258C9.5000803@redhat.com> <5134D674.4000008@redhat.com> Message-ID: <5137359F.9020801@redhat.com> On 03/04/2013 06:14 PM, Endi Sukma Dewata wrote: > On 2/18/2013 10:37 AM, Petr Vobornik wrote: >> Added blacklists section, with ipantsidblacklistincoming and >> ipantsidblacklistoutgoing multivalued textbox fields, into trust details >> page. >> >> https://fedorahosted.org/freeipa/ticket/3289 > > ACK. > Pushed to master -- Petr Vobornik From mkosek at redhat.com Wed Mar 6 13:05:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 14:05:38 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513739D3.7090606@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> Message-ID: <51373F22.6050102@redhat.com> On 03/06/2013 01:42 PM, Petr Vobornik wrote: > On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: >> ----- Original Message ----- >>> First two patches are bug fixes which are required for third patch. >>> Depends on my patch #259 (Combobox keyboard support) >>> >>> 1) [PATCH] Fix dirty state update of editable combobox >>> >>> Editable combobox didn't update it's dirty state correctly. CB had >>> it's own internal value changed event, which was incorrectly used. It was >>> removed and widget's value_changed event was used instead. >> >> ACK. > > Pushed to master >> >>> 2) [PATCH] Fix handling of no_update flag in Web UI >>> >>> There was an incorrect check for no_update flag. Check was performed >>> as if the flag was an attribute of object not an item of array. Hence, >>> the flag never caused any effect. >> >> ACK. > > Pushed to master >> >>> 3) [PATCH] Global trust config page >>> >>> https://fedorahosted.org/freeipa/ticket/3333 >> >>> Just two notes: >>> >>> ipantfallbackprimarygroup requires a posix group. Our API currently >>> doesn't support search based on object classes therefore the entity >>> select widget incorrectly offers non posix groups as well. >> >> Are we planning to add the missing functionality? Right now you'll get >> 'group not found' if you select a non-POSIX group, which is confusing >> because the group does exist. Possible solutions: > > > Waiting for "[RFE] Add option for filtering groups by type (posix,..) in > group-find command" to be implemented to solve issue. > >> >> 1. Fix the error message to say ' is not a POSIX group' or >> 'Fallback primary group requires a POSIX group'. >> >> 2. Execute another batch of group-show operations to get the object >> classes of the groups to be displayed and filter out the non-POSIX groups. >> >>> Another problem is that hidden 'Default SMB Group' is not listed. >>> Hence it couldn't be set again after a modification. I made the combobox >>> editable (first usage, so it revealed a bug) to avoid this problem. >>> User can enter garbage, but the framework should handle that. >> >> This is a little difficult to use. You'll need to know that you have to >> type 'Default SMB Group' to go back to the default and the UI doesn't >> show that as an acceptable value. Possible solutions: >> >> 1. Add the 'Default SMB Group' as the first entry in the drop down list >> so you can reselect it again. The drop down list doesn't need to be >> editable. >> >> 2. Use radio buttons to separate the default value from other values: >> >> Fallback primary group: (o) Default SMB Group >> ( ) POSIX group: [ drop down list ] >> >> Regardless, I think the server API needs to be changed to accept an >> empty value to go back to the default value instead of taking 'Default >> SMB Group'. A default value should be simple and not something that will >> potentially conflict with a non-default value that happens to have the >> same name. > > I agree. Martin is it feasible? I do not think this is something we want to have fixed FreeIPA API side, when you set some field/attribute to None, it is just set to None, i.e. removed from LDAP. No default value kicks in. If you would that to work, we would first have to update ipa-sam plugin to understand missing Fallback primary group as "use the default". If I read the code right, it currently just fails the operation. Sumit, do you think it would we feasible to change the ipa-sam operation this way? I.e. when fallback primary group DN is not present, use the value hardcoded in ipa-sam. It may have been thought about originally as ipaNTFallbackPrimaruyGroup attributeType is a MAY and not a MUST on the objectClass. Martin From pvoborni at redhat.com Wed Mar 6 13:21:00 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 14:21:00 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <51373F22.6050102@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> <51373F22.6050102@redhat.com> Message-ID: <513742BC.80009@redhat.com> On 03/06/2013 02:05 PM, Martin Kosek wrote: > On 03/06/2013 01:42 PM, Petr Vobornik wrote: >> On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: >>> ----- Original Message ----- >>>> First two patches are bug fixes which are required for third patch. >>>> Depends on my patch #259 (Combobox keyboard support) >>>> >>>> 1) [PATCH] Fix dirty state update of editable combobox >>>> >>>> Editable combobox didn't update it's dirty state correctly. CB had >>>> it's own internal value changed event, which was incorrectly used. It was >>>> removed and widget's value_changed event was used instead. >>> >>> ACK. >> >> Pushed to master >>> >>>> 2) [PATCH] Fix handling of no_update flag in Web UI >>>> >>>> There was an incorrect check for no_update flag. Check was performed >>>> as if the flag was an attribute of object not an item of array. Hence, >>>> the flag never caused any effect. >>> >>> ACK. >> >> Pushed to master >>> >>>> 3) [PATCH] Global trust config page >>>> >>>> https://fedorahosted.org/freeipa/ticket/3333 >>> >>>> Just two notes: >>>> >>>> ipantfallbackprimarygroup requires a posix group. Our API currently >>>> doesn't support search based on object classes therefore the entity >>>> select widget incorrectly offers non posix groups as well. >>> >>> Are we planning to add the missing functionality? Right now you'll get >>> 'group not found' if you select a non-POSIX group, which is confusing >>> because the group does exist. Possible solutions: >> >> >> Waiting for "[RFE] Add option for filtering groups by type (posix,..) in >> group-find command" to be implemented to solve issue. >> >>> >>> 1. Fix the error message to say ' is not a POSIX group' or >>> 'Fallback primary group requires a POSIX group'. >>> >>> 2. Execute another batch of group-show operations to get the object >>> classes of the groups to be displayed and filter out the non-POSIX groups. >>> >>>> Another problem is that hidden 'Default SMB Group' is not listed. >>>> Hence it couldn't be set again after a modification. I made the combobox >>>> editable (first usage, so it revealed a bug) to avoid this problem. >>>> User can enter garbage, but the framework should handle that. >>> >>> This is a little difficult to use. You'll need to know that you have to >>> type 'Default SMB Group' to go back to the default and the UI doesn't >>> show that as an acceptable value. Possible solutions: >>> >>> 1. Add the 'Default SMB Group' as the first entry in the drop down list >>> so you can reselect it again. The drop down list doesn't need to be >>> editable. >>> >>> 2. Use radio buttons to separate the default value from other values: >>> >>> Fallback primary group: (o) Default SMB Group >>> ( ) POSIX group: [ drop down list ] >>> >>> Regardless, I think the server API needs to be changed to accept an >>> empty value to go back to the default value instead of taking 'Default >>> SMB Group'. A default value should be simple and not something that will >>> potentially conflict with a non-default value that happens to have the >>> same name. >> >> I agree. Martin is it feasible? > > I do not think this is something we want to have fixed FreeIPA API side, when > you set some field/attribute to None, it is just set to None, i.e. removed from > LDAP. No default value kicks in. > > If you would that to work, we would first have to update ipa-sam plugin to > understand missing Fallback primary group as "use the default". If I read the > code right, it currently just fails the operation. > > Sumit, do you think it would we feasible to change the ipa-sam operation this > way? I.e. when fallback primary group DN is not present, use the value > hardcoded in ipa-sam. It may have been thought about originally as > ipaNTFallbackPrimaruyGroup attributeType is a MAY and not a MUST on the > objectClass. We might just add `default=u'default smb group'` to Str('ipantfallbackprimarygroup', cli_name='fallback_primary_group', label=_('Fallback primary group'), ), > > Martin > -- Petr Vobornik From mkosek at redhat.com Wed Mar 6 13:29:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 14:29:13 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513742BC.80009@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> <51373F22.6050102@redhat.com> <513742BC.80009@redhat.com> Message-ID: <513744A9.2000007@redhat.com> On 03/06/2013 02:21 PM, Petr Vobornik wrote: > On 03/06/2013 02:05 PM, Martin Kosek wrote: >> On 03/06/2013 01:42 PM, Petr Vobornik wrote: >>> On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: >>>> ----- Original Message ----- >>>>> First two patches are bug fixes which are required for third patch. >>>>> Depends on my patch #259 (Combobox keyboard support) >>>>> >>>>> 1) [PATCH] Fix dirty state update of editable combobox >>>>> >>>>> Editable combobox didn't update it's dirty state correctly. CB had >>>>> it's own internal value changed event, which was incorrectly used. It was >>>>> removed and widget's value_changed event was used instead. >>>> >>>> ACK. >>> >>> Pushed to master >>>> >>>>> 2) [PATCH] Fix handling of no_update flag in Web UI >>>>> >>>>> There was an incorrect check for no_update flag. Check was performed >>>>> as if the flag was an attribute of object not an item of array. Hence, >>>>> the flag never caused any effect. >>>> >>>> ACK. >>> >>> Pushed to master >>>> >>>>> 3) [PATCH] Global trust config page >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3333 >>>> >>>>> Just two notes: >>>>> >>>>> ipantfallbackprimarygroup requires a posix group. Our API currently >>>>> doesn't support search based on object classes therefore the entity >>>>> select widget incorrectly offers non posix groups as well. >>>> >>>> Are we planning to add the missing functionality? Right now you'll get >>>> 'group not found' if you select a non-POSIX group, which is confusing >>>> because the group does exist. Possible solutions: >>> >>> >>> Waiting for "[RFE] Add option for filtering groups by type (posix,..) in >>> group-find command" to be implemented to solve issue. >>> >>>> >>>> 1. Fix the error message to say ' is not a POSIX group' or >>>> 'Fallback primary group requires a POSIX group'. >>>> >>>> 2. Execute another batch of group-show operations to get the object >>>> classes of the groups to be displayed and filter out the non-POSIX groups. >>>> >>>>> Another problem is that hidden 'Default SMB Group' is not listed. >>>>> Hence it couldn't be set again after a modification. I made the combobox >>>>> editable (first usage, so it revealed a bug) to avoid this problem. >>>>> User can enter garbage, but the framework should handle that. >>>> >>>> This is a little difficult to use. You'll need to know that you have to >>>> type 'Default SMB Group' to go back to the default and the UI doesn't >>>> show that as an acceptable value. Possible solutions: >>>> >>>> 1. Add the 'Default SMB Group' as the first entry in the drop down list >>>> so you can reselect it again. The drop down list doesn't need to be >>>> editable. >>>> >>>> 2. Use radio buttons to separate the default value from other values: >>>> >>>> Fallback primary group: (o) Default SMB Group >>>> ( ) POSIX group: [ drop down list ] >>>> >>>> Regardless, I think the server API needs to be changed to accept an >>>> empty value to go back to the default value instead of taking 'Default >>>> SMB Group'. A default value should be simple and not something that will >>>> potentially conflict with a non-default value that happens to have the >>>> same name. >>> >>> I agree. Martin is it feasible? >> >> I do not think this is something we want to have fixed FreeIPA API side, when >> you set some field/attribute to None, it is just set to None, i.e. removed from >> LDAP. No default value kicks in. >> >> If you would that to work, we would first have to update ipa-sam plugin to >> understand missing Fallback primary group as "use the default". If I read the >> code right, it currently just fails the operation. >> >> Sumit, do you think it would we feasible to change the ipa-sam operation this >> way? I.e. when fallback primary group DN is not present, use the value >> hardcoded in ipa-sam. It may have been thought about originally as >> ipaNTFallbackPrimaruyGroup attributeType is a MAY and not a MUST on the >> objectClass. > > We might just add `default=u'default smb group'` to > > Str('ipantfallbackprimarygroup', > cli_name='fallback_primary_group', > label=_('Fallback primary group'), > ), > This would not work with current API. default=FOO means that FOO is used when creating an LDAP object. It is not used when modifying an LDAP object and it would anyway still return an error similar to this one ("--type" has a default set): ipa trustconfig-mod --type= ipa: ERROR: 'type' is required This is an intentional behavior, user may really want to set an attribute to None, i.e. delete it. We just error out when it is a required parameter. Martin From mkosek at redhat.com Wed Mar 6 13:49:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 14:49:50 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <20130306094108.GA16010@localhost.localdomain> References: <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> <20130306094108.GA16010@localhost.localdomain> Message-ID: <5137497E.4010204@redhat.com> On 03/06/2013 10:41 AM, Sumit Bose wrote: > On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: >> On 03/04/2013 04:22 PM, Sumit Bose wrote: >>> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: >>>> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: >>>>> On 03/01/2013 09:20 AM, Sumit Bose wrote: >>>>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: >>>>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: >>>>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: >>>>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: >>>>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: >>>>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: >>>>>>>> >>>>>>>>>>> Hi Sumit, >>>>>>>>>>> >>>>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. >>>>>>>>>>> Though I would not add this service-specific setting to global IPA config object. >>>>>>>>>>> >>>>>>>>>>> I would rather like to see that in the service tree, for example as a >>>>>>>>>>> configuration option of the service root which could be controlled with >>>>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: >>>>>>>>>>> >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD >>>>>>>>>>> # ipa serviceconfig-show >>>>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD >>>>>>>>>> >>>>>>>>>> Are you thinking of having this in addition to the for-all-services >>>>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't >>>>>>>>>> like the first case because then three different objects needs to be >>>>>>>>>> consulted to find out which is the right type. This wouldn't be an issue >>>>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. >>>>>>>>> >>>>>>>>> Hm, you are right. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If the current defaults shall be dropped I think this is a major change >>>>>>>>>> because it will require changes in the current CLI and WebUI which will >>>>>>>>>> be visible to the users. I'm not against this change, I'm just wondering >>>>>>>>>> if it is worth the effort for the next release? >>>>>>>>>> >>>>>>>>>> Maybe an argument to keep this is in global default is that the settings >>>>>>>>>> are used for the host/*.* services as well which are in a different >>>>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might >>>>>>>>>> want apply those setting to the user TGTs as well? >>>>>>>>> >>>>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC >>>>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and >>>>>>>>> user principals. This automatic PAC rules may require some designing so that is >>>>>>>>> is generally usable. >>>>>>>> >>>>>>>> I think putting everything in the general config is more understandable >>>>>>>> and discoverable. These per-service defaults are basically exceptions to >>>>>>>> the general rule so it make sense to keep everything together. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Ok, if these are really just an exceptions to the general rule (and there will >>>>>>> not be too many of them), I think we can leave it in config entry. But if we >>>>>>> expect to have exceptions for other types of entries (hosts, users), I think we >>>>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. >>>>>>> >>>>>>> Question is, do we want to implement the interface and processing for that in >>>>>>> current Sumit's patches or do we use that is they are? >>>>>> >>>>>> I would like to update the patches so that they can handle the >>>>>> service:TYPE style entry and replace the current update code with just >>>>>> adding nfs:NONE to the global options. I will update the design page >>>>>> accordingly, too. >>>>> >>>>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd >>>>> be great. >>>> >>>> If we need to distinguish between service principals and user principals >>>> I would prefer rather use a special keyword for upns >>>> >>>> service: is redundant and I do not want here to be able to say >>>> upn:martin:NONE because per principal options are available on the >>>> principal object. >>>> >>>> I actually really do not see the need for changing the default just for >>>> user principals. If we are worried that one day we might want to really >>>> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we >>>> might add upn:NONE and the lack of / will tell us this is not a service >>>> named upn/foo.bar.baz but rather it means user principal names. >>>> >>>> However I do not see us ever really needing upn:NONE >>>> >>>>>> I would prefer if the enhancements needed for the CLI and WebUI can be >>>>>> covered by other/new tickets, but I'm happy to add the needed >>>>>> information to the design page too. >>>>>> >>>>>> bye, >>>>>> Sumit >>>>> >>>>> I am OK with adding the interface for this special exception later. In that >>>>> case, a ticket + note in the design as you mentioned would be enough. >>>> >>>> Ack. >>>> >>>> Simo. >>>> >>> >>> Please find attached a new version of the patches. 0095 i(updating) is >>> renamed and much simpler now. I opened >>> https://fedorahosted.org/freeipa/ticket/3484 to added the needed change >>> for 'service:TYPE' to CLI and WebUI. For the time being I've added >>> patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it >>> is not deleted accidentally when e.g. using the WebUI. If you do not >>> like it it can simply be dropped, everything is working fine without it. >>> >>> bye, >>> Sumit >>> >> >> Patch 0098: >> >> If this part does not match (and it will not for all non-nfs service principals): >> >> + if (service_type->length == (sep - authz_data_list[c]) && >> + strncmp(authz_data_list[c], service_type->data, >> + service_type->length) == 0) { >> + authz_data_type = sep + 1; >> + } >> >> krb5kdc.log will contain an error: >> >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported >> authorization data type [nfs:NONE]. >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 >> 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 >> ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for >> ldap/ipa.linux.ad.test at LINUX.AD.TEST >> >> I think we should just "continue" in this case. > > good catch, fixed Ok, thanks. > >> >> Otherwise, this looks and works fine. > > Thank you for the review, new version attached. > > I have an additional question about processing the service specific > defaults. Using 'service:NONE' is unambiguous because NONE trumps all. > But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a > LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think > the first one where all defaults which apply to a service are added up > is more clear, and this is also the way the current code works. But I > wouldn't mind to change the logic if you think it makes more sense the > other way round, i.e. if there is a service specific default matching > the requested service only the service specific default are accounted. Hmm, that's a good question. I understand service:PACTYPE as an exclusion to the general setting, so for me it would make sense to override the global config - i.e. tje second case. Thus, if global config is MS-PAC, ldap:PAD, I think that ldap should have just PAD. If one also want MS-PAC, it should be set like "MS-PAC, ldap:PAD, ldap:MS-PAC". Otherwise you would not be able to configure that you want MS-PAC for all services and _only_ PAD for ldap... Does it make sense? We should also make sure that we update the RFE page to whatever we decide to do. Martin From simo at redhat.com Wed Mar 6 13:51:47 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 06 Mar 2013 08:51:47 -0500 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <5137497E.4010204@redhat.com> References: <512F0AE3.8080000@redhat.com> <20130228114205.GL3633@localhost.localdomain> <512F476E.9050501@redhat.com> <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> <20130306094108.GA16010@localhost.localdomain> <5137497E.4010204@redhat.com> Message-ID: <1362577907.2822.2.camel@willson.li.ssimo.org> On Wed, 2013-03-06 at 14:49 +0100, Martin Kosek wrote: > On 03/06/2013 10:41 AM, Sumit Bose wrote: > > On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: > >> On 03/04/2013 04:22 PM, Sumit Bose wrote: > >>> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: > >>>> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > >>>>> On 03/01/2013 09:20 AM, Sumit Bose wrote: > >>>>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > >>>>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: > >>>>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > >>>>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > >>>>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > >>>>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > >>>>>>>> > >>>>>>>>>>> Hi Sumit, > >>>>>>>>>>> > >>>>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > >>>>>>>>>>> Though I would not add this service-specific setting to global IPA config object. > >>>>>>>>>>> > >>>>>>>>>>> I would rather like to see that in the service tree, for example as a > >>>>>>>>>>> configuration option of the service root which could be controlled with > >>>>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > >>>>>>>>>>> > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > >>>>>>>>>>> # ipa serviceconfig-show > >>>>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD > >>>>>>>>>> > >>>>>>>>>> Are you thinking of having this in addition to the for-all-services > >>>>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > >>>>>>>>>> like the first case because then three different objects needs to be > >>>>>>>>>> consulted to find out which is the right type. This wouldn't be an issue > >>>>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. > >>>>>>>>> > >>>>>>>>> Hm, you are right. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> If the current defaults shall be dropped I think this is a major change > >>>>>>>>>> because it will require changes in the current CLI and WebUI which will > >>>>>>>>>> be visible to the users. I'm not against this change, I'm just wondering > >>>>>>>>>> if it is worth the effort for the next release? > >>>>>>>>>> > >>>>>>>>>> Maybe an argument to keep this is in global default is that the settings > >>>>>>>>>> are used for the host/*.* services as well which are in a different > >>>>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might > >>>>>>>>>> want apply those setting to the user TGTs as well? > >>>>>>>>> > >>>>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC > >>>>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and > >>>>>>>>> user principals. This automatic PAC rules may require some designing so that is > >>>>>>>>> is generally usable. > >>>>>>>> > >>>>>>>> I think putting everything in the general config is more understandable > >>>>>>>> and discoverable. These per-service defaults are basically exceptions to > >>>>>>>> the general rule so it make sense to keep everything together. > >>>>>>>> > >>>>>>>> Simo. > >>>>>>>> > >>>>>>> > >>>>>>> Ok, if these are really just an exceptions to the general rule (and there will > >>>>>>> not be too many of them), I think we can leave it in config entry. But if we > >>>>>>> expect to have exceptions for other types of entries (hosts, users), I think we > >>>>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. > >>>>>>> > >>>>>>> Question is, do we want to implement the interface and processing for that in > >>>>>>> current Sumit's patches or do we use that is they are? > >>>>>> > >>>>>> I would like to update the patches so that they can handle the > >>>>>> service:TYPE style entry and replace the current update code with just > >>>>>> adding nfs:NONE to the global options. I will update the design page > >>>>>> accordingly, too. > >>>>> > >>>>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > >>>>> be great. > >>>> > >>>> If we need to distinguish between service principals and user principals > >>>> I would prefer rather use a special keyword for upns > >>>> > >>>> service: is redundant and I do not want here to be able to say > >>>> upn:martin:NONE because per principal options are available on the > >>>> principal object. > >>>> > >>>> I actually really do not see the need for changing the default just for > >>>> user principals. If we are worried that one day we might want to really > >>>> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we > >>>> might add upn:NONE and the lack of / will tell us this is not a service > >>>> named upn/foo.bar.baz but rather it means user principal names. > >>>> > >>>> However I do not see us ever really needing upn:NONE > >>>> > >>>>>> I would prefer if the enhancements needed for the CLI and WebUI can be > >>>>>> covered by other/new tickets, but I'm happy to add the needed > >>>>>> information to the design page too. > >>>>>> > >>>>>> bye, > >>>>>> Sumit > >>>>> > >>>>> I am OK with adding the interface for this special exception later. In that > >>>>> case, a ticket + note in the design as you mentioned would be enough. > >>>> > >>>> Ack. > >>>> > >>>> Simo. > >>>> > >>> > >>> Please find attached a new version of the patches. 0095 i(updating) is > >>> renamed and much simpler now. I opened > >>> https://fedorahosted.org/freeipa/ticket/3484 to added the needed change > >>> for 'service:TYPE' to CLI and WebUI. For the time being I've added > >>> patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it > >>> is not deleted accidentally when e.g. using the WebUI. If you do not > >>> like it it can simply be dropped, everything is working fine without it. > >>> > >>> bye, > >>> Sumit > >>> > >> > >> Patch 0098: > >> > >> If this part does not match (and it will not for all non-nfs service principals): > >> > >> + if (service_type->length == (sep - authz_data_list[c]) && > >> + strncmp(authz_data_list[c], service_type->data, > >> + service_type->length) == 0) { > >> + authz_data_type = sep + 1; > >> + } > >> > >> krb5kdc.log will contain an error: > >> > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported > >> authorization data type [nfs:NONE]. > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 > >> 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 > >> ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for > >> ldap/ipa.linux.ad.test at LINUX.AD.TEST > >> > >> I think we should just "continue" in this case. > > > > good catch, fixed > > Ok, thanks. > > > > >> > >> Otherwise, this looks and works fine. > > > > Thank you for the review, new version attached. > > > > I have an additional question about processing the service specific > > defaults. Using 'service:NONE' is unambiguous because NONE trumps all. > > But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a > > LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think > > the first one where all defaults which apply to a service are added up > > is more clear, and this is also the way the current code works. But I > > wouldn't mind to change the logic if you think it makes more sense the > > other way round, i.e. if there is a service specific default matching > > the requested service only the service specific default are accounted. > > Hmm, that's a good question. I understand service:PACTYPE as an exclusion to > the general setting, so for me it would make sense to override the global > config - i.e. tje second case. > > Thus, if global config is MS-PAC, ldap:PAD, I think that ldap should have just > PAD. If one also want MS-PAC, it should be set like "MS-PAC, ldap:PAD, > ldap:MS-PAC". Otherwise you would not be able to configure that you want MS-PAC > for all services and _only_ PAD for ldap... > > Does it make sense? We should also make sure that we update the RFE page to > whatever we decide to do. +1 to Martin's choice. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Mar 6 14:06:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 15:06:39 +0100 Subject: [Freeipa-devel] [PATCH] 105 Fix remove while iterating in suppress_netgroup_memberof In-Reply-To: <51360BAC.1020305@redhat.com> References: <512E1058.1080308@redhat.com> <51360BAC.1020305@redhat.com> Message-ID: <51374D6F.6000506@redhat.com> On 03/05/2013 04:13 PM, Petr Viktorin wrote: > On 02/27/2013 02:55 PM, Jan Cholasta wrote: >> Hi, >> >> this patch fixes . >> >> Honza >> > > ACK, thanks. > > Pushed to master, ipa-3-1. Martin From abokovoy at redhat.com Wed Mar 6 14:14:23 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 Mar 2013 09:14:23 -0500 (EST) Subject: [Freeipa-devel] LDAP search without enforcing schema correctness Message-ID: <1778631017.10131628.1362579263942.JavaMail.root@redhat.com> Hi! We need to make schema validation optional for multiple cases. Recent LDAP code changes in master broke whole AD trusts because we are no longer able to talk to Global Catalog service as it is not exposing schema the way we expect it (neither we need that schema). I've pushed one-liner that forces use of raw python-ldap code as we had before in dcerpc.py:_search_in_gc(). Once a version of API that allows to disable schema validation will be added, please change the code in _search_in_gc() to use that flag. -- / Alexander Bokovoy From pviktori at redhat.com Wed Mar 6 14:39:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Mar 2013 15:39:19 +0100 Subject: [Freeipa-devel] [ACK] ipa-replica-manage break after new LDAP code merged Message-ID: <51375517.3020208@redhat.com> ACK for Alexander's two-liner fix to ipa-replica-manage, which I broke with the LDAP refactoring. Patch was posted via Trac: https://fedorahosted.org/freeipa/ticket/3490 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-replica-manage-migrate-to-single_value-after-LDA.patch Type: text/x-patch Size: 1284 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 6 15:09:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 16:09:42 +0100 Subject: [Freeipa-devel] [PATCH] 114 Remove disabled entries from sudoers compat tree In-Reply-To: <513708E8.1050700@redhat.com> References: <513708E8.1050700@redhat.com> Message-ID: <51375C36.7050700@redhat.com> On 03/06/2013 10:14 AM, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > ACK. Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Wed Mar 6 15:14:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 16:14:07 +0100 Subject: [Freeipa-devel] [PATCH] 115 Fix internal error in output_for_cli method of sudorule_{enable, disable} In-Reply-To: <51370D0D.7040207@redhat.com> References: <51370D0D.7040207@redhat.com> Message-ID: <51375D3F.6020408@redhat.com> On 03/06/2013 10:31 AM, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > ACK. Pushed to master, ipa-3-1. Martin From pviktori at redhat.com Wed Mar 6 15:29:26 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Mar 2013 16:29:26 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration Message-ID: <513760D6.9010305@redhat.com> Hello, These patches move ipaldap to ipapython, and make the client installer use it. Also password migration web-app is made to use ipaldap; they both called a shared a utility function that is converted to use ipaldap. This should fix https://fedorahosted.org/freeipa/ticket/3446 (freeipa-client-install KeyError in 'namingcontexts') and similar errors. https://fedorahosted.org/freeipa/ticket/3487 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0191-Move-ipaldap-to-ipapython.patch Type: text/x-patch Size: 71052 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0192-Remove-ipaserver-ipaldap.py.patch Type: text/x-patch Size: 12182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0193-Use-IPAdmin-rather-than-raw-python-ldap-in-ipa-clien.patch Type: text/x-patch Size: 7237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0194-Use-IPAdmin-rather-than-raw-python-ldap-in-migration.patch Type: text/x-patch Size: 15347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0195-Remove-unneeded-python-ldap-imports.patch Type: text/x-patch Size: 10722 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 6 15:47:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 16:47:49 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513760D6.9010305@redhat.com> References: <513760D6.9010305@redhat.com> Message-ID: <51376525.8000603@redhat.com> On 03/06/2013 04:29 PM, Petr Viktorin wrote: > Hello, > These patches move ipaldap to ipapython, and make the client installer use it. > Also password migration web-app is made to use ipaldap; they both called a > shared a utility function that is converted to use ipaldap. > > This should fix https://fedorahosted.org/freeipa/ticket/3446 > (freeipa-client-install KeyError in 'namingcontexts') and similar errors. > > https://fedorahosted.org/freeipa/ticket/3487 > As we discussed, a prerequisite for these patches is that IPAdmin should be able to avoid fetching remote LDAP schema. We do not want to get schema of every LDAP server we try to discover on. I did not test the patches, I just saw some strange changes when reading the patches. 0193: @@ -1645,6 +1640,7 @@ def get_ca_cert(fstore, options, server, basedn): os.unlink(ca_file) raise except Exception, e: + raise root_logger.debug(str(e)) raise errors.NoCertificateError(entry=url) @@ -2018,6 +2014,7 @@ def install(options, env, fstore, statestore): del os.environ['KRB5_CONFIG'] except Exception, e: root_logger.error("Cannot obtain CA certificate\n%s", e) + raise return CLIENT_INSTALL_ERROR # Now join the domain What is it good for? Martin From pvoborni at redhat.com Wed Mar 6 15:51:59 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 Mar 2013 16:51:59 +0100 Subject: [Freeipa-devel] [PATCH] 264-265 Web UI:Certificate pages In-Reply-To: <513680DD.3030806@redhat.com> References: <5127A039.6030902@redhat.com> <513680DD.3030806@redhat.com> Message-ID: <5137661F.1030705@redhat.com> Updated patch 264 attached. 265 was rebased. See comments below. On 03/06/2013 12:33 AM, Endi Sukma Dewata wrote: > On 2/22/2013 10:43 AM, Petr Vobornik wrote: >> Note: static json files for testing and such will be updated soon (there >> were several patch which changes API. I rather want to do one mass >> regeneration than several minor ones in a short period of time. >> >> >> 1) [PATCH] Web UI:Certificate pages >> >> Following pages were added to Web UI: >> * certificated details >> * certificate search >> >> Certificate is not regular object so it gets no metadata. Therefore >> artificial metadata were created for it to allow usage of search and >> details facet. >> >> Search and details facet were modified to allow removing of >> add/remove/update/reset buttons - certificates have no mod operation and >> they are not added by standard means. >> >> User can revoke and restore certificated in details facet. >> >> https://fedorahosted.org/freeipa/ticket/3419 > > I have some comments. Some of these can be postponed for future > enhancements. > > 1. As previously discussed, the cert-find is only available with Dogtag > CA, so the Certificates page should be disabled with self-signed CA. But > if self-signed CA is dropped, then it's not necessary to disable the > Certificates page. We may need to keep the ticket open until this is > resolved one way or another. > Seems that the drop will land in different release. I disabled it similar way as in DNS. I didn't test it. Do you have installation without dogtag? > 2. Right now the fields in the cert details page are editable although > there is no Update button. If you change the value an Undo button will > appear. If you try to leave the page it will show the Unsaved Changes > dialog. Since there's no cert-mod operation these fields should not be > editable. > > 3. In the cert details page if you revoke the cert it will work but an > error will appear below the revocation reason field saying 'Must be an > integer'. #2, #3: I forget to tell you, that this patch also depends on my patch #261 - Fix handling of no_update flag in Web UI. Sorry. It should fix it. It was pushed to master today. > > 4. I think showing an empty revocation reason field on a valid cert is > kind of weird. It might be better to create a Status section with two > fields: status and revocation reason. If status is valid the revocation > reason will be empty or hidden. If revoked then the reason will appear > below the status. Fixed it by hiding the row. Showing the status is separate issue. I would like to avoid computing it in web ui - IIUIC it depends also on valid-until and similar fields. Cert-show command doesn't include the status. > > 5. In host/service details page the View link can be changed to go to > the cert details page instead of showing a dialog box. Do we want to do it? > > 6. It would be better to organize the fields in the cert details page > like the cert view dialog in host/service details page. Switched MD5fp. with SHA1fp. Do you also want to split subject and issuer as in the dialog and moved the fields to different sections? Currently the order is the same as in dialog except serial numbers. I kept them on top because issuer and subject may be very long and they can clash with the action panel if placed on top. > > 7. Certificate can be added/revoked/restored via certificate pages and > host/service details pages. We need to make sure that if you do an > operation on one page, the other pages won't show outdated information. Fixed. > >> 2) [PATCH] Web UI:Choose different search option for cert-find >> >> This extends certificate search page by search option select. Therefore >> the search is not restricted to 'subject'. >> >> It should be replaced by https://fedorahosted.org/freeipa/ticket/191 in >> a future. >> >> https://fedorahosted.org/freeipa/ticket/3419 > > 8. The revocation reason takes an integer. Probably the search field > should change into a drop down list showing all available reasons. > > 9. The date options take a certain format (YYYY-MM-DD), so we should > show the format probably as greyed text in the search field. > > 10. The current design only allows specifying one option at a time. Some > of these options are meant to be used as a pair because they represent a > range (min & max serial number). How about creating an Advanced Search > dialog that shows all search options in separate fields so they can be > combined? The basic search field can remain simple like the search field > in other entities and it will search the cert subject only. > 8-10: I agree, but I don't want to complicate the patch. Originally this patch shouldn't really exist. Original agreement was that the search will be fixed to 'subject' field and that it should be replaced with proper implementation of #191 later. I made this patch to give users at least some options. Main obstacle is that there are more pressing issues for April release. > 11. The list of search options is a drop down list, but it's surrounded > by a rounded box like the text field next to it. This might be just a > personal preference but I'm not sure if it's an appropriate look for a > drop down list. > It's just border radius. When I disable it it looks kinda inconsistent, weirder. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0264-1-Web-UI-Certificate-pages.patch Type: text/x-patch Size: 27117 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0265-1-Web-UI-Choose-different-search-option-for-cert-find.patch Type: text/x-patch Size: 10430 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 6 15:52:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Mar 2013 16:52:15 +0100 Subject: [Freeipa-devel] [ACK] ipa-replica-manage break after new LDAP code merged In-Reply-To: <51375517.3020208@redhat.com> References: <51375517.3020208@redhat.com> Message-ID: <5137662F.3000305@redhat.com> On 03/06/2013 03:39 PM, Petr Viktorin wrote: > ACK for Alexander's two-liner fix to ipa-replica-manage, which I broke with the > LDAP refactoring. > > Patch was posted via Trac: > https://fedorahosted.org/freeipa/ticket/3490 > Pushed to master. Martin From sbose at redhat.com Wed Mar 6 16:33:43 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 6 Mar 2013 17:33:43 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <1362577907.2822.2.camel@willson.li.ssimo.org> References: <1362061706.2962.93.camel@willson.li.ssimo.org> <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> <20130306094108.GA16010@localhost.localdomain> <5137497E.4010204@redhat.com> <1362577907.2822.2.camel@willson.li.ssimo.org> Message-ID: <20130306163343.GC16010@localhost.localdomain> On Wed, Mar 06, 2013 at 08:51:47AM -0500, Simo Sorce wrote: > On Wed, 2013-03-06 at 14:49 +0100, Martin Kosek wrote: > > On 03/06/2013 10:41 AM, Sumit Bose wrote: > > > On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: > > >> On 03/04/2013 04:22 PM, Sumit Bose wrote: > > >>> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: > > >>>> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > > >>>>> On 03/01/2013 09:20 AM, Sumit Bose wrote: > > >>>>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > > >>>>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: > > >>>>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > > >>>>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > > >>>>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > > >>>>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > > >>>>>>>> > > >>>>>>>>>>> Hi Sumit, > > >>>>>>>>>>> > > >>>>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > > >>>>>>>>>>> Though I would not add this service-specific setting to global IPA config object. > > >>>>>>>>>>> > > >>>>>>>>>>> I would rather like to see that in the service tree, for example as a > > >>>>>>>>>>> configuration option of the service root which could be controlled with > > >>>>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > > >>>>>>>>>>> > > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > > >>>>>>>>>>> # ipa serviceconfig-show > > >>>>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD > > >>>>>>>>>> > > >>>>>>>>>> Are you thinking of having this in addition to the for-all-services > > >>>>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > > >>>>>>>>>> like the first case because then three different objects needs to be > > >>>>>>>>>> consulted to find out which is the right type. This wouldn't be an issue > > >>>>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. > > >>>>>>>>> > > >>>>>>>>> Hm, you are right. > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> If the current defaults shall be dropped I think this is a major change > > >>>>>>>>>> because it will require changes in the current CLI and WebUI which will > > >>>>>>>>>> be visible to the users. I'm not against this change, I'm just wondering > > >>>>>>>>>> if it is worth the effort for the next release? > > >>>>>>>>>> > > >>>>>>>>>> Maybe an argument to keep this is in global default is that the settings > > >>>>>>>>>> are used for the host/*.* services as well which are in a different > > >>>>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might > > >>>>>>>>>> want apply those setting to the user TGTs as well? > > >>>>>>>>> > > >>>>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC > > >>>>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and > > >>>>>>>>> user principals. This automatic PAC rules may require some designing so that is > > >>>>>>>>> is generally usable. > > >>>>>>>> > > >>>>>>>> I think putting everything in the general config is more understandable > > >>>>>>>> and discoverable. These per-service defaults are basically exceptions to > > >>>>>>>> the general rule so it make sense to keep everything together. > > >>>>>>>> > > >>>>>>>> Simo. > > >>>>>>>> > > >>>>>>> > > >>>>>>> Ok, if these are really just an exceptions to the general rule (and there will > > >>>>>>> not be too many of them), I think we can leave it in config entry. But if we > > >>>>>>> expect to have exceptions for other types of entries (hosts, users), I think we > > >>>>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. > > >>>>>>> > > >>>>>>> Question is, do we want to implement the interface and processing for that in > > >>>>>>> current Sumit's patches or do we use that is they are? > > >>>>>> > > >>>>>> I would like to update the patches so that they can handle the > > >>>>>> service:TYPE style entry and replace the current update code with just > > >>>>>> adding nfs:NONE to the global options. I will update the design page > > >>>>>> accordingly, too. > > >>>>> > > >>>>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > > >>>>> be great. > > >>>> > > >>>> If we need to distinguish between service principals and user principals > > >>>> I would prefer rather use a special keyword for upns > > >>>> > > >>>> service: is redundant and I do not want here to be able to say > > >>>> upn:martin:NONE because per principal options are available on the > > >>>> principal object. > > >>>> > > >>>> I actually really do not see the need for changing the default just for > > >>>> user principals. If we are worried that one day we might want to really > > >>>> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we > > >>>> might add upn:NONE and the lack of / will tell us this is not a service > > >>>> named upn/foo.bar.baz but rather it means user principal names. > > >>>> > > >>>> However I do not see us ever really needing upn:NONE > > >>>> > > >>>>>> I would prefer if the enhancements needed for the CLI and WebUI can be > > >>>>>> covered by other/new tickets, but I'm happy to add the needed > > >>>>>> information to the design page too. > > >>>>>> > > >>>>>> bye, > > >>>>>> Sumit > > >>>>> > > >>>>> I am OK with adding the interface for this special exception later. In that > > >>>>> case, a ticket + note in the design as you mentioned would be enough. > > >>>> > > >>>> Ack. > > >>>> > > >>>> Simo. > > >>>> > > >>> > > >>> Please find attached a new version of the patches. 0095 i(updating) is > > >>> renamed and much simpler now. I opened > > >>> https://fedorahosted.org/freeipa/ticket/3484 to added the needed change > > >>> for 'service:TYPE' to CLI and WebUI. For the time being I've added > > >>> patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it > > >>> is not deleted accidentally when e.g. using the WebUI. If you do not > > >>> like it it can simply be dropped, everything is working fine without it. > > >>> > > >>> bye, > > >>> Sumit > > >>> > > >> > > >> Patch 0098: > > >> > > >> If this part does not match (and it will not for all non-nfs service principals): > > >> > > >> + if (service_type->length == (sep - authz_data_list[c]) && > > >> + strncmp(authz_data_list[c], service_type->data, > > >> + service_type->length) == 0) { > > >> + authz_data_type = sep + 1; > > >> + } > > >> > > >> krb5kdc.log will contain an error: > > >> > > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported > > >> authorization data type [nfs:NONE]. > > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 > > >> 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 > > >> ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for > > >> ldap/ipa.linux.ad.test at LINUX.AD.TEST > > >> > > >> I think we should just "continue" in this case. > > > > > > good catch, fixed > > > > Ok, thanks. > > > > > > > >> > > >> Otherwise, this looks and works fine. > > > > > > Thank you for the review, new version attached. > > > > > > I have an additional question about processing the service specific > > > defaults. Using 'service:NONE' is unambiguous because NONE trumps all. > > > But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a > > > LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think > > > the first one where all defaults which apply to a service are added up > > > is more clear, and this is also the way the current code works. But I > > > wouldn't mind to change the logic if you think it makes more sense the > > > other way round, i.e. if there is a service specific default matching > > > the requested service only the service specific default are accounted. > > > > Hmm, that's a good question. I understand service:PACTYPE as an exclusion to > > the general setting, so for me it would make sense to override the global > > config - i.e. tje second case. > > > > Thus, if global config is MS-PAC, ldap:PAD, I think that ldap should have just > > PAD. If one also want MS-PAC, it should be set like "MS-PAC, ldap:PAD, > > ldap:MS-PAC". Otherwise you would not be able to configure that you want MS-PAC > > for all services and _only_ PAD for ldap... > > > > Does it make sense? We should also make sure that we update the RFE page to > > whatever we decide to do. > > +1 to Martin's choice. Martin, Simo, thank you for the feedback. I will send an new version of the patches, add a section in the design page explaining the details and add some tests for this logic. bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From sbose at redhat.com Wed Mar 6 16:45:44 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 6 Mar 2013 17:45:44 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <51373F22.6050102@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> <51373F22.6050102@redhat.com> Message-ID: <20130306164544.GD16010@localhost.localdomain> On Wed, Mar 06, 2013 at 02:05:38PM +0100, Martin Kosek wrote: > On 03/06/2013 01:42 PM, Petr Vobornik wrote: > > On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: > >> ----- Original Message ----- > >>> First two patches are bug fixes which are required for third patch. > >>> Depends on my patch #259 (Combobox keyboard support) > >>> > >>> 1) [PATCH] Fix dirty state update of editable combobox > >>> > >>> Editable combobox didn't update it's dirty state correctly. CB had > >>> it's own internal value changed event, which was incorrectly used. It was > >>> removed and widget's value_changed event was used instead. > >> > >> ACK. > > > > Pushed to master > >> > >>> 2) [PATCH] Fix handling of no_update flag in Web UI > >>> > >>> There was an incorrect check for no_update flag. Check was performed > >>> as if the flag was an attribute of object not an item of array. Hence, > >>> the flag never caused any effect. > >> > >> ACK. > > > > Pushed to master > >> > >>> 3) [PATCH] Global trust config page > >>> > >>> https://fedorahosted.org/freeipa/ticket/3333 > >> > >>> Just two notes: > >>> > >>> ipantfallbackprimarygroup requires a posix group. Our API currently > >>> doesn't support search based on object classes therefore the entity > >>> select widget incorrectly offers non posix groups as well. > >> > >> Are we planning to add the missing functionality? Right now you'll get > >> 'group not found' if you select a non-POSIX group, which is confusing > >> because the group does exist. Possible solutions: > > > > > > Waiting for "[RFE] Add option for filtering groups by type (posix,..) in > > group-find command" to be implemented to solve issue. > > > >> > >> 1. Fix the error message to say ' is not a POSIX group' or > >> 'Fallback primary group requires a POSIX group'. > >> > >> 2. Execute another batch of group-show operations to get the object > >> classes of the groups to be displayed and filter out the non-POSIX groups. > >> > >>> Another problem is that hidden 'Default SMB Group' is not listed. > >>> Hence it couldn't be set again after a modification. I made the combobox > >>> editable (first usage, so it revealed a bug) to avoid this problem. > >>> User can enter garbage, but the framework should handle that. > >> > >> This is a little difficult to use. You'll need to know that you have to > >> type 'Default SMB Group' to go back to the default and the UI doesn't > >> show that as an acceptable value. Possible solutions: > >> > >> 1. Add the 'Default SMB Group' as the first entry in the drop down list > >> so you can reselect it again. The drop down list doesn't need to be > >> editable. > >> > >> 2. Use radio buttons to separate the default value from other values: > >> > >> Fallback primary group: (o) Default SMB Group > >> ( ) POSIX group: [ drop down list ] > >> > >> Regardless, I think the server API needs to be changed to accept an > >> empty value to go back to the default value instead of taking 'Default > >> SMB Group'. A default value should be simple and not something that will > >> potentially conflict with a non-default value that happens to have the > >> same name. > > > > I agree. Martin is it feasible? > > I do not think this is something we want to have fixed FreeIPA API side, when > you set some field/attribute to None, it is just set to None, i.e. removed from > LDAP. No default value kicks in. > > If you would that to work, we would first have to update ipa-sam plugin to > understand missing Fallback primary group as "use the default". If I read the > code right, it currently just fails the operation. > > Sumit, do you think it would we feasible to change the ipa-sam operation this > way? I.e. when fallback primary group DN is not present, use the value > hardcoded in ipa-sam. It may have been thought about originally as > ipaNTFallbackPrimaruyGroup attributeType is a MAY and not a MUST on the > objectClass. In general yes, if this attribute is not set ipa_sam can search for a group with 'cn=Default SMB Group' (which is created during ipa-adtrust-install) and use this group. I'm just wondering what would be the fallback if a smart admin has deleted this group as well. Simo, Alexander, should we fallback to the well-known RID 513 for 'Domain Users' in this rare edge case, jsut to make sure that there always is a RID which can be used? bye, Sumit > > Martin From npmccallum at redhat.com Wed Mar 6 17:56:10 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 06 Mar 2013 12:56:10 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS Message-ID: <1362592570.12650.7.camel@localhost.localdomain> Patch is attached. There are currently a few security downsides to this patch: 1. The daemon (ipa-otpd) runs as root and binds anonymously 2. ipatokenRadiusSecret is readable by an anonymous bind This patch also adds some new dependencies, namely: 1. libverto (a dependency of krb5) 2. systemd 3. a krb5 patched for libk5radius support [1] In the interest of trying to meet the Fedora Features deadline, I am providing the patch in spite of the above issues. Nathaniel 1 - http://bit.ly/ZqtK79 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-krb5-1.12-s-OTP-Over-RADIUS.patch Type: text/x-patch Size: 64473 bytes Desc: not available URL: From npmccallum at redhat.com Wed Mar 6 18:04:46 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 06 Mar 2013 13:04:46 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362592570.12650.7.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> Message-ID: <1362593086.12650.8.camel@localhost.localdomain> On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > Patch is attached. > > There are currently a few security downsides to this patch: > 1. The daemon (ipa-otpd) runs as root and binds anonymously > 2. ipatokenRadiusSecret is readable by an anonymous bind > > This patch also adds some new dependencies, namely: > 1. libverto (a dependency of krb5) > 2. systemd > 3. a krb5 patched for libk5radius support [1] > > In the interest of trying to meet the Fedora Features deadline, I am > providing the patch in spite of the above issues. > > Nathaniel > > 1 - http://bit.ly/ZqtK79 Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the schema. This will need to be verified and finalized. Nathaniel From simo at redhat.com Wed Mar 6 18:15:24 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 06 Mar 2013 13:15:24 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362592570.12650.7.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> Message-ID: <1362593724.2822.18.camel@willson.li.ssimo.org> On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > Patch is attached. > > There are currently a few security downsides to this patch: > 1. The daemon (ipa-otpd) runs as root and binds anonymously > 2. ipatokenRadiusSecret is readable by an anonymous bind > > This patch also adds some new dependencies, namely: > 1. libverto (a dependency of krb5) > 2. systemd > 3. a krb5 patched for libk5radius support [1] > > In the interest of trying to meet the Fedora Features deadline, I am > providing the patch in spite of the above issues. > > Nathaniel > > 1 - http://bit.ly/ZqtK79 The actual link for those that will see this thread in future and do not want to trust a .ly redirector: https://github.com/npmccallum/krb5/commit/9cb035a01eea0494c28206bd4afbf085793fdc6d Simo. -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Wed Mar 6 19:26:56 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 06 Mar 2013 20:26:56 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <51370F17.1080802@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> Message-ID: <51379880.1080700@redhat.com> On 03/06/2013 10:40 AM, Petr Vobornik wrote: > On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>> Add support for Realm Domains to web UI. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3407 >>> >>> The patch looks good, but there is a issue we don't have a precedence >>> for. >>> >>> The mod command is doing dns check for new domains. Currently we can't >>> specify --force option to bypass the check. >>> >>> I see two possible implementations: >>> 1) On update, when user adds or modifies the values, a dialog would >>> pop up and ask user whether he wants to force it. >>> >>> 2) Another option is to disable edit on the list(deletion would be >>> still allowed) and move the add operation to separate action in action >>> list. >>> >>> I prefer the former. Latter might have issues with two modifications >>> (delete and add) at the same time at two different places (facet and >>> add dialog). >> >> Added force option to the error dialog. >> >> Updated patch is attached. >> > > 1) I think the dialog with the force should be shown before executing > the operation. Sometimes, DNS check can take several seconds. There is > no point for waiting for the error if you know that it will fail. > > 2) Regardless of #1. I don't think that just adding 'force' button > without explaining the user what it means is the way to go. > > Previously (solution #1) I had in mind to show following dialog after > clicking on 'update': > > > ------------------------------------------------------- > [Check DNS] > ------------------------------------------------------- > > Do you also want to perform DNS check? > > [Check DNS] [Force Update] > ------------------------------------------------------- > > Default button (confirm button) will be [Check DNS] > Thanks, fixed, and I also added a Cancel button, in case the user wants to back out. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0007-03-Realm-Domains-page.patch Type: text/x-patch Size: 10046 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 6 20:52:31 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Mar 2013 15:52:31 -0500 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <5134B6E1.7000203@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> Message-ID: <5137AC8F.3060204@redhat.com> Petr Viktorin wrote: > On 03/01/2013 11:57 PM, Rob Crittenden wrote: >> Implement the design at http://freeipa.org/page/V3/Recover_DNA_Ranges > > Could you add the link to the commit message? done > >> Note that this required some new ACIs in cn=config which is not >> replicated so the range-set commands won't work against older instances. >> It should be gracefully handled though. > > I think noting this in the man page would be helpful. sure > > On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric > Assignment Plugin,cn=plugins,cn=config is added before the entry itself. > I didn't test everything as I didn't get the access. It shouldn't make a difference. What isn't working? >> It also doesn't work so well if you try it using a delegated >> administrator, see ticket https://fedorahosted.org/freeipa/ticket/3480 >> >> rob > > It should be possible to shrink existing ranges, i.e. ones that overlap > with themselves: > $ ipa-replica-manage dnarange-show > vm-075.idm.lab.eng.brq.redhat.com: 1401000005-1401100499 > $ ipa-replica-manage dnarange-set vm-075.idm.lab.eng.brq.redhat.com > 1401000005-1401100498 > New range overlaps the DNA range on vm-075.idm.lab.eng.brq.redhat.com fixed > >> freeipa-rcrit-1088-dnarange.patch >> >> >>> From 9a654b0b3730f8d9058dfbf25a93a58e1f4939e7 Mon Sep 17 00:00:00 2001 >> From: Rob Crittenden >> Date: Fri, 1 Mar 2013 15:02:14 -0500 >> Subject: [PATCH] Extend ipa-replica-manage to be able to manage DNA >> ranges. >> >> Attempt to automatically save DNA ranges when a master is removed. >> This is done by trying to find a master that does not yet define >> a DNA on-deck range. If one can be found then the range on the deleted >> master is added. >> >> If one cannot be found then it is reported as an error. >> >> Some validation of the ranges are done to ensure that they do overlap >> an IPA local range and do not overlap existing DNA ranges configured >> on other masters. > > The patch adds some trailing whitespace, please trim it. > I also found some nitpicks, see below. > >> >> https://fedorahosted.org/freeipa/ticket/3321 >> --- > [...] >> diff --git a/install/tools/ipa-replica-manage >> b/install/tools/ipa-replica-manage >> index >> 859809bf1c301913c3eb7fc92d1ed58675609b8c..6c0b45620dd2deabfc11ef2249b18205fb23b1fd >> 100755 >> --- a/install/tools/ipa-replica-manage >> +++ b/install/tools/ipa-replica-manage > [...] >> >> +def showDNARanges(hostname, master, realm, dirman_passwd, >> nextrange=False): > > Style issue: please don't use camel case for functions. Sure. I kept DNA as upper. > [...] >> + try: >> + repl = replication.ReplicationManager(realm, hostname, >> dirman_passwd) >> + except Exception, e: >> + sys.exit("Connection failed: %s" % >> ipautil.convert_ldap_error(e)) > > ipaldap should convert LDAP errors to IPA ones, there's no need to call > convert_ldap_error. Same in other places. It does in some but it isn't consistent. I removed my calls though. $ ipa-replica-manage dnarange-show -p badpassword Connection failed: {'desc': 'Invalid credentials'} >> + dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), >> repl.suffix) >> + try: >> + entries = repl.conn.get_entries(dn, repl.conn.SCOPE_ONELEVEL) >> + except: > > Don't use a bare except. Same in other places. Fixed. > > [...] >> +def setDNARange(hostname, range, realm, dirman_passwd, >> next_range=False): >> + """ >> + Given a DNA range try to change it on the designated master. >> + >> + The range must not overlap with any other ranges and must be within >> + one of the IPA local ranges as defined in cn=ranges. >> + >> + Setting an on-deck range of 0-0 removes the range. >> + >> + Return True if range was saved, False if not >> + >> + hostname: hostname of the master to set the range on >> + range: The DNA range to set >> + realm: our realm, needed to create a connection >> + dirman_passwd: the DM password, needed to create a connection > > Please also mention next_range. ok. > > [...] >> + def range_intersection(s1, s2, r1, r2): >> + overlap = xrange(max(s1, r1), min(s2, r2) + 1) >> + return len(overlap) > 0 > > That looks complicated. How about: > def ranges_intersect(s1, s2, r1, r2): > return max(s1, r1) <= min(s2, r2) > > [...] Sure. My original intention was to return the overlapping range but then decided against it since it is probably fairly obvious anyway. >> + # Normalize the range >> + (dna_next, dna_max) = range.split('-', 1) > > Can this be done before validate_range, so id doesn't have to be > duplicated there? No because then we'd still have to validate things and it would be split into two places. I can live with these 3 lines of duplicated code, esp since we need no error handling around them because it is assumed correct by the time it reaches it. > > [...] >> + dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), >> ipautil.realm_to_suffix(realm)) > > I think you should use repl.suffix instead of generating it again. Done. I had missed this one. > > [...] >> + # Verify that this is within one of the IPA domain ranges. >> + dn = DN(('cn','ranges'),('cn','etc'),repl.suffix) > > Style issue: no spaces after commas > >> + try: >> + entries = repl.conn.get_entries(dn, >> repl.conn.SCOPE_ONELEVEL, >> + >> "(objectclass=ipaDomainIDRange)") >> + except errors.NotFound, e: >> + sys.exit('Unable to load IPA ranges: %s' % e.message) >> + >> + failed = 0 >> + for ent in entries: > > > This loops more than necessary and is somewhat hard to follow. Consider > using for-else here: > > for ...: > ... > if okay: > break > else: > raise error I simplified things a bit but a for/else won't work here as we need to check all ranges all the time. It is perfectly fine to not fit into a range, as long as it fits into SOME range. >> + entry_start = int(ent.single_value('ipabaseid')) >> + entry_max = entry_start + >> int(ent.single_value('ipaidrangesize')) >> + if not range_intersection(dna_next, dna_max, entry_start, >> entry_max): > > I think we want the DNA range to be fully contained in the idrange, > rather than just overlap a part of it. Good point, fixed. > Please also adjust the man page when you change this. > >> + failed += 1 >> + >> + if failed == len(entries): >> + sys.exit("New range does not fit within existing IPA >> ranges. See ipa help idrange command") >> + # If this falls within any of the AD ranges then it fails. >> + try: >> + entries = repl.conn.get_entries(dn, repl.conn.SCOPE_BASE, >> + >> "(objectclass=ipatrustedaddomainrange)") > > If we add more types of ranges in the future, should they also be > checked? Would (!(objectclass=ipaDomainIDRange)) be more appropriate here? It depends on what the other range is used for. If it isn't for POSIX values then overlap may be perfectly acceptable. > > [...] >> diff --git a/install/tools/man/ipa-replica-manage.1 >> b/install/tools/man/ipa-replica-manage.1 >> index >> 836743902278ec2273f3ce7a7fbf3992370c4828..d23e2566eb9a22c70991cbdca0140eb1d268533c >> 100644 >> --- a/install/tools/man/ipa-replica-manage.1 >> +++ b/install/tools/man/ipa-replica-manage.1 >> @@ -16,13 +16,13 @@ >> .\" >> .\" Author: Rob Crittenden >> .\" >> -.TH "ipa-replica-manage" "1" "Mar 14 2008" "FreeIPA" "FreeIPA Manual >> Pages" >> +.TH "ipa-replica-manage" "1" "Mar 1 2013" "FreeIPA" "FreeIPA Manual >> Pages" >> .SH "NAME" >> ipa\-replica\-manage \- Manage an IPA replica >> .SH "SYNOPSIS" >> -ipa\-replica\-manage [\fIOPTION\fR]... >> [connect|disconnect|del|list|re\-initialize|force\-sync] >> +ipa\-replica\-manage [\fIOPTION\fR]... [COMMAND} > > Please straighten the curly brace at the end ok > >> .SH "DESCRIPTION" >> -Manages the replication agreements of an IPA server. >> +Manages the replication agreements of an IPA server. The available >> commands are: >> .TP >> \fBconnect\fR [SERVER_A] >> \- Adds a new replication agreement between SERVER_A/localhost and >> SERVER_B >> @@ -54,6 +54,18 @@ Manages the replication agreements of an IPA server. >> \fBlist\-clean\-ruv\fR >> \- List all running CLEANALLRUV and abort CLEANALLRUV tasks. >> .TP >> +\fBipadnarange\-show [SERVER]\fR > > The subcommand is dnarange-show, no ipa at the start. Same for the others. ok > >> +\- List the DNA ranges >> +.TP >> +\fBipadnarange\-set SERVER x\-y\fR > > I'd use START-END instead of x-y ok, that's fine. > >> +\- Set the DNA range on a master >> +.TP >> +\fBipadnanextrange\-show [SERVER]\fR >> +\- List the next DNA ranges >> +.TP >> +\fBipadnanextrange\-set SERVER x\-y\fR > > here too > > [...] >> +The DNA range and on\-deck (next) values can be managed using the >> dnarange\-set and dnanextrange\-set commands. The rules for managing >> these ranges are: >> +\- The range must overlap a local range as defined by the ipa idrange >> command. >> + >> +\- The range cannot overlap the DNA range or on\-deck range on >> another IPA master. >> + >> +\- The primary DNA range cannot be removed. >> + >> +\- An on\-deck range range can be removed by setting it to 0\-0. The >> assumption is that the range will be manually moved or merged elsewhere. > > Also, a range can't overlap ranges of trusted AD domains. Added > > [...] >> index >> 804d046bf2553daa4aded5c23436a98636e20da0..9076c8396041a95c7ea01ef15aa77991516d30e6 >> 100644 >> --- a/ipaserver/install/replication.py >> +++ b/ipaserver/install/replication.py >> @@ -1308,3 +1308,123 @@ class ReplicationManager(object): >> print "This may be safely interrupted with Ctrl+C" >> >> wait_for_task(self.conn, dn) >> + >> + def getDNARange(self, hostname): > > Style issue: please don't use camel-case for methods. Stuck with upper-case DNA again. > >> + """ >> + Return the DNA range on this server as a tuple, (next, max), or >> + (None, None) if no range has been assigned yet. >> + """ >> + dn = DN(('cn', 'Posix IDs'), ('cn', 'Distributed Numeric >> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) > > I'd put this in a global constant. sure > >> + try: >> + entry = self.conn.get_entry(dn) >> + except Exception, e: >> + print "Unable to read DNA configuration: %s" % e.message > > I think it's better to communicate the error by raising an exception, > rather than pretending the range hasn't been set yet. > With prints, the error won't appear in logs, and can't be checked by the > caller. > Same elsewhere. Ok, I guess thinking forward to when this gets converted to the framework that makes sense. Currently there are no logs. > > [...] >> + if (nextvalue > maxvalue and maxvalue == 1100 and >> + nextvalue == 1101 and remaining == 0): > > What are the magic values? Also this redundantly checks if 1101 > 1100. The magic values are the default values assigned to the DNA configured. The redundant check, and the check for remaining, is just to be absolutely sure that we are dealing with a default configuration and not some custom values. I dropped the 1101 > 1100 check. > > I'd expect the DNS plugin to ensure that dnaRemainingValues == 0 if > nextvalue > maxvalue, do we need to check explicitly? > > [...] >> diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py >> index >> 4a46532642013204720ba467966c59de31a92301..cb9a7e98fd0c486abe5b8b92aff711fa69f23fa9 >> 100644 >> --- a/ipaserver/ipaldap.py >> +++ b/ipaserver/ipaldap.py >> @@ -1775,6 +1775,8 @@ class IPAdmin(LDAPClient): >> if removes: >> if not force_replace: >> modlist.append((ldap.MOD_DELETE, key, removes)) >> + elif new_values == []: # delete an empty value >> + modlist.append((ldap.MOD_DELETE, key, removes)) > > I don't understand this change. AFAIK updateEntry/generateModList is > only used in ldapupdater now, and it's going away as soon as I can find > time to remove it. If you need to change it I'd like to know why. > Ok, I'll drop this since it doesn't affect things with the new LDAP backend. I also added one change related to the LDAP core changes. In the past if you did not have a ticket it would prompt for DM password. This was broken after the updates. I added an additional except in test_connection(). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1088-2-dnarange.patch Type: text/x-diff Size: 28631 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 6 21:29:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Mar 2013 16:29:26 -0500 Subject: [Freeipa-devel] Backup and Restore design In-Reply-To: <51250586.1020305@redhat.com> References: <5124466F.9030800@redhat.com> <1361369818.12328.428.camel@willson.li.ssimo.org> <5124EDD9.7050900@redhat.com> <5124F98A.20106@redhat.com> <5124FD63.4050004@redhat.com> <51250586.1020305@redhat.com> Message-ID: <5137B536.3010701@redhat.com> I think I've captured all the changes and suggestions. Am I good to go on starting to implement this or do we need more discussion? http://freeipa.org/page/V3/Backup_and_Restore rob From rcritten at redhat.com Wed Mar 6 21:57:37 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Mar 2013 16:57:37 -0500 Subject: [Freeipa-devel] [PATCH] 1091 Don't double-encode CA cert Message-ID: <5137BBD1.4080809@redhat.com> When the CA cert was added via the update plugin we were double-encoding it. We just need to store the DER value. See the ticket for reproduction details. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1091-ldapcert.patch Type: text/x-diff Size: 1617 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 7 08:41:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 07 Mar 2013 09:41:55 +0100 Subject: [Freeipa-devel] [PATCH] 1091 Don't double-encode CA cert In-Reply-To: <5137BBD1.4080809@redhat.com> References: <5137BBD1.4080809@redhat.com> Message-ID: <513852D3.8030706@redhat.com> On 03/06/2013 10:57 PM, Rob Crittenden wrote: > When the CA cert was added via the update plugin we were double-encoding it. We > just need to store the DER value. > > See the ticket for reproduction details. > > rob This works fine. The certificate is now stored correctly in the attribute and it can be properly read by ldapsearch and also decoded by tools like Apache Directory Studio. Surprisingly, the double encoded format worked OK in the ipa-client-install... ACK. Pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Thu Mar 7 11:41:24 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 Mar 2013 12:41:24 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <51379880.1080700@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> Message-ID: <51387CE4.2040001@redhat.com> On 03/06/2013 08:26 PM, Ana Krivokapic wrote: > On 03/06/2013 10:40 AM, Petr Vobornik wrote: >> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>> Add support for Realm Domains to web UI. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>> >>>> The patch looks good, but there is a issue we don't have a precedence >>>> for. >>>> >>>> The mod command is doing dns check for new domains. Currently we can't >>>> specify --force option to bypass the check. >>>> >>>> I see two possible implementations: >>>> 1) On update, when user adds or modifies the values, a dialog would >>>> pop up and ask user whether he wants to force it. >>>> >>>> 2) Another option is to disable edit on the list(deletion would be >>>> still allowed) and move the add operation to separate action in action >>>> list. >>>> >>>> I prefer the former. Latter might have issues with two modifications >>>> (delete and add) at the same time at two different places (facet and >>>> add dialog). >>> >>> Added force option to the error dialog. >>> >>> Updated patch is attached. >>> >> >> 1) I think the dialog with the force should be shown before executing >> the operation. Sometimes, DNS check can take several seconds. There is >> no point for waiting for the error if you know that it will fail. >> >> 2) Regardless of #1. I don't think that just adding 'force' button >> without explaining the user what it means is the way to go. >> >> Previously (solution #1) I had in mind to show following dialog after >> clicking on 'update': >> >> >> ------------------------------------------------------- >> [Check DNS] >> ------------------------------------------------------- >> >> Do you also want to perform DNS check? >> >> [Check DNS] [Force Update] >> ------------------------------------------------------- >> >> Default button (confirm button) will be [Check DNS] >> > > Thanks, fixed, and I also added a Cancel button, in case the user wants > to back out. > Almost there, as discussed in person: 1. following strings should be add to and obtained from internal.py plugin: title: 'Check DNS', message: 'Do you also want to perform DNS check?', ok_label: 'Check DNS', 2. the server plugin should report all dns resolution failures, not just the first one. -- Petr Vobornik From pviktori at redhat.com Thu Mar 7 12:16:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 13:16:19 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <5137AC8F.3060204@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> Message-ID: <51388513.2040700@redhat.com> On 03/06/2013 09:52 PM, Rob Crittenden wrote: > Petr Viktorin wrote: [...] >> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >> Assignment Plugin,cn=plugins,cn=config is added before the entry itself. >> I didn't test everything as I didn't get the access. > > It shouldn't make a difference. What isn't working? I get a CRITICAL message in the log: add aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" 2013-03-07T11:01:48Z DEBUG stderr=ldap_initialize( ldap://vm-081.idm.lab.eng.brq.redhat.com:389/??base ) ldap_modify: No such object (32) 2013-03-07T11:01:48Z CRITICAL Failed to load replica-acis.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpT55upM -H ldap://vm-081.idm.lab.eng.brq.redhat.com:389 -x -D cn=Directory Manager -y /tmp/tmplFeere' returned non-zero exit status 32 This particular ACI is added later by the updater. But, after failing here the rest of the file is skipped, and the subsequent ACIs aren't added in updates. Not being able to run CLEANALLRUV prevents cleanly deleting a replica. [...] >> [...] >>> + try: >>> + repl = replication.ReplicationManager(realm, hostname, >>> dirman_passwd) >>> + except Exception, e: >>> + sys.exit("Connection failed: %s" % >>> ipautil.convert_ldap_error(e)) >> >> ipaldap should convert LDAP errors to IPA ones, there's no need to call >> convert_ldap_error. Same in other places. > > It does in some but it isn't consistent. I removed my calls though. > > $ ipa-replica-manage dnarange-show -p badpassword > Connection failed: {'desc': 'Invalid credentials'} That's a bug. My patch 0194 should fix this, I'll check after it's merged. Anyway it's not a show stopper now. [...] >>> + failed = 0 >>> + for ent in entries: >> >> >> This loops more than necessary and is somewhat hard to follow. Consider >> using for-else here: >> >> for ...: >> ... >> if okay: >> break >> else: >> raise error > > I simplified things a bit but a for/else won't work here as we need to > check all ranges all the time. It is perfectly fine to not fit into a > range, as long as it fits into SOME range. Well, that's how for's (not if's) else clause works -- it's executed after all the looping's done if you didn't `break` out. http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops Maybe I'm just used to it and it's too esoteric to the average reader, though. [...] > Ok, I'll drop this since it doesn't affect things with the new LDAP > backend. Please do, you left it in by mistake. > I also added one change related to the LDAP core changes. In the past if > you did not have a ticket it would prompt for DM password. This was > broken after the updates. I added an additional except in > test_connection(). This should also be fixed soon in ipaldap. Thanks for putting up with the changes. -- Petr? From jcholast at redhat.com Thu Mar 7 12:43:00 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Mar 2013 13:43:00 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional Message-ID: <51388B54.1090405@redhat.com> Hi, these patches add flags to LDAPClient and IPAdmin constructors which can be used to disable schema retrieval and decoding of attributes. This should make interacting with AD easier (see ). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-116-Do-not-fail-if-schema-cannot-be-retrieved-from-LDAP-.patch Type: text/x-patch Size: 1978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-117-Allow-disabling-LDAP-schema-retrieval-in-LDAPClient-.patch Type: text/x-patch Size: 2432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-118-Allow-disabling-attribute-decoding-in-LDAPClient-and.patch Type: text/x-patch Size: 2741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-119-Disable-schema-retrieval-and-attribute-decoding-when.patch Type: text/x-patch Size: 2198 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 7 12:58:18 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 13:58:18 +0100 Subject: [Freeipa-devel] Custom SSL certificates Message-ID: <51388EEA.5050304@redhat.com> Hi, I'm investigating https://fedorahosted.org/freeipa/ticket/3363 (fix --http_pkcs12 & friends). I can't find documentation on these options, and from the code I can't figure out enough about how they are/were supposed to work. Is it the case that they were last used/tested before IPA started using Dogtag, and have rotted since then? Custom certs don't make sense to use if Dogtag is installed, right? So when they're provided we should not install the CA and Certmonger? If that's the case it would be easier (development- and testing-wise) to just remove self-signed CA in the same set of patches. -- Petr? From mkosek at redhat.com Thu Mar 7 13:00:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 07 Mar 2013 14:00:55 +0100 Subject: [Freeipa-devel] [PATCH] 381 Preserve order of servers in ipa-client-install Message-ID: <51388F87.6040200@redhat.com> When multiple servers are passed via --server option, ipadiscovery module changed its order. Make sure that we preserve it. Also make sure that user is always warned when a tested server is not available as then the server will be excluded from the fixed server list. https://fedorahosted.org/freeipa/ticket/3418 ------ When working on this ticket I was thinking - do we make the right thing we deliberately remove a server from user-provided server list just because we cannot connect to it at the moment if discovery? It may just be temporarily down or something. Maybe we should preserve the original --server list in this case and use this list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other active configuration commands we would have to use only the valid servers so that the we do not hit the server that is currently down. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-381-preserve-order-of-servers-in-ipa-client-install.patch Type: text/x-patch Size: 2293 bytes Desc: not available URL: From akrivoka at redhat.com Thu Mar 7 13:19:40 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 07 Mar 2013 14:19:40 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <51387CE4.2040001@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> <51387CE4.2040001@redhat.com> Message-ID: <513893EC.2040101@redhat.com> On 03/07/2013 12:41 PM, Petr Vobornik wrote: > On 03/06/2013 08:26 PM, Ana Krivokapic wrote: >> On 03/06/2013 10:40 AM, Petr Vobornik wrote: >>> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>>> Add support for Realm Domains to web UI. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>>> >>>>> The patch looks good, but there is a issue we don't have a precedence >>>>> for. >>>>> >>>>> The mod command is doing dns check for new domains. Currently we >>>>> can't >>>>> specify --force option to bypass the check. >>>>> >>>>> I see two possible implementations: >>>>> 1) On update, when user adds or modifies the values, a dialog would >>>>> pop up and ask user whether he wants to force it. >>>>> >>>>> 2) Another option is to disable edit on the list(deletion would be >>>>> still allowed) and move the add operation to separate action in >>>>> action >>>>> list. >>>>> >>>>> I prefer the former. Latter might have issues with two modifications >>>>> (delete and add) at the same time at two different places (facet and >>>>> add dialog). >>>> >>>> Added force option to the error dialog. >>>> >>>> Updated patch is attached. >>>> >>> >>> 1) I think the dialog with the force should be shown before executing >>> the operation. Sometimes, DNS check can take several seconds. There is >>> no point for waiting for the error if you know that it will fail. >>> >>> 2) Regardless of #1. I don't think that just adding 'force' button >>> without explaining the user what it means is the way to go. >>> >>> Previously (solution #1) I had in mind to show following dialog after >>> clicking on 'update': >>> >>> >>> ------------------------------------------------------- >>> [Check DNS] >>> ------------------------------------------------------- >>> >>> Do you also want to perform DNS check? >>> >>> [Check DNS] [Force Update] >>> ------------------------------------------------------- >>> >>> Default button (confirm button) will be [Check DNS] >>> >> >> Thanks, fixed, and I also added a Cancel button, in case the user wants >> to back out. >> > > Almost there, as discussed in person: > > 1. following strings should be add to and obtained from internal.py > plugin: > title: 'Check DNS', > message: 'Do you also want to perform DNS check?', > ok_label: 'Check DNS', > > > 2. the server plugin should report all dns resolution failures, not > just the first one. Fixed, updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0007-04-Realm-Domains-page.patch Type: text/x-patch Size: 12831 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 7 13:37:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 Mar 2013 14:37:19 +0100 Subject: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE In-Reply-To: <511D093C.5090602@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> Message-ID: <5138980F.8070205@redhat.com> On 02/14/2013 04:56 PM, Endi Sukma Dewata wrote: > On 2/14/2013 6:30 AM, Petr Vobornik wrote: >>> If they are mutually exclusive, they probably should be separated using >>> radio buttons like this: >>> >>> PAC: ( ) None >>> (o) Type: >>> [x] MS-PAC >>> [ ] PAD >> >> You missed one option: nothing selected. It can be solved by adding '( >> ) Inherited' radio. > > I wouldn't have guessed that :) I agree we should add the 'Inherited' > option. > >> Anyway, this design seems more user friendly for more general audience >> than mine so I will implement it. The only problem with it is that one >> have to come with new label for each group and empty value - can't be >> inferred from metadata. > > Is there any issue adding new labels at this point? Worst case we could > hard code the label now and add a translation later. > >>> It might be better to use a composite widget of radio buttons and >>> checkboxes so we can reuse the code. Probably the definition will look >>> something like this: >>> >>> { >>> name: 'ipakrbauthzdata', >>> type: 'radio', >> >> Not sure if it should be radio, more like something new. > > Right, probably the current radio widget can't do this. So either we > improve the radio widget or create something new. > >>> label: ..., >>> options: [ >>> { >>> label: ..., >>> value: 'NONE' >>> }, >>> { >>> label: ..., >>> type: 'checkboxes', >> >> Do you expect to be there something different than checkboxes, or do you >> want it to do it this way for possible future customization. > > Ideally it should be generic enough to combine any widgets. This might > be a common scenario somewhere else: > > Something: ( ) Option 1 > ( ) Option 2 > (o) Other: [something else ] > This design has a flaw: https://fedorahosted.org/freeipa/ticket/3404#comment:5 I implemented following design: https://fedorahosted.org/freeipa/ticket/3404#comment:7 Patch attached (255-1). I have a dilemma. I practically implemented the previous design (and then I've found the flaw..). Patches attached as wip-fre... I wonder if we can use it somehow or we should ditch it. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0255-1-Added-Web-UI-support-for-service-PAC-type-option-NON.patch Type: text/x-patch Size: 7379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0457-Added-Web-UI-support-for-service-PAC-type-option-NON.patch Type: text/x-patch Size: 1268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0458-Nesteble-checkboxes-radions-initial-implementation.patch Type: text/x-patch Size: 24564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0459-Multivalued-widget.patch Type: text/x-patch Size: 5177 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 7 13:53:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 14:53:23 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <51388B54.1090405@redhat.com> References: <51388B54.1090405@redhat.com> Message-ID: <51389BD3.4000101@redhat.com> On 03/07/2013 01:43 PM, Jan Cholasta wrote: > Hi, > > these patches add flags to LDAPClient and IPAdmin constructors which can > be used to disable schema retrieval and decoding of attributes. This > should make interacting with AD easier (see > ). > > Honza The first three patches look good, except a nitpick below. In the last patch, I don't see why you added back search_s. Is get_entries inadequate in some way? >>From 33142d7e0a8508a783e1a1b4a7a22525337ce54d Mon Sep 17 00:00:00 2001 > From: Jan Cholasta > Date: Thu, 7 Mar 2013 10:50:57 +0100 > Subject: [PATCH 1/4] Do not fail if schema cannot be retrieved from LDAP > server. > > --- > ipaserver/ipaldap.py | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py [...] > + try: > + self._schema = schema_cache.get_schema( > + self.uri, self.conn, > + force_update=self._force_schema_updates) > + except: Don't use bare except. -- Petr? From pviktori at redhat.com Thu Mar 7 14:07:04 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 15:07:04 +0100 Subject: [Freeipa-devel] [PATCH] 381 Preserve order of servers in ipa-client-install In-Reply-To: <51388F87.6040200@redhat.com> References: <51388F87.6040200@redhat.com> Message-ID: <51389F08.1030607@redhat.com> On 03/07/2013 02:00 PM, Martin Kosek wrote: > When multiple servers are passed via --server option, ipadiscovery > module changed its order. Make sure that we preserve it. > > Also make sure that user is always warned when a tested server is > not available as then the server will be excluded from the fixed > server list. The message doesn't actually say that the server will be removed. It would be nice if it did. Otherwise, ACK. > ------ > > When working on this ticket I was thinking - do we make the right thing we > deliberately remove a server from user-provided server list just because we > cannot connect to it at the moment if discovery? It may just be temporarily > down or something. > > Maybe we should preserve the original --server list in this case and use this > list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other > active configuration commands we would have to use only the valid servers so > that the we do not hit the server that is currently down. > > Martin Good point, this deserves a ticket. -- Petr? From tbabej at redhat.com Thu Mar 7 14:20:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 07 Mar 2013 15:20:08 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <513736E2.7090104@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <513736E2.7090104@redhat.com> Message-ID: <5138A218.3090508@redhat.com> On 03/06/2013 01:30 PM, Petr Spacek wrote: > On 6.3.2013 13:04, Tomas Babej wrote: >> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>> Thanks! The mechanism works, but see below. >>> >>> This is a RFE so it needs a design document. >>> >> http://freeipa.org/page/V3/Client_install_using_keytab > I added "Security Considerations" section with couple questions > inside. Please add more details about un-enrolling process, > pre-requirements and so on. > I improved the design and added additional explanations to Security Considerations and elsewhere. Please have a look if anything needs more clarification. Tomas From rcritten at redhat.com Thu Mar 7 14:35:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 09:35:16 -0500 Subject: [Freeipa-devel] Custom SSL certificates In-Reply-To: <51388EEA.5050304@redhat.com> References: <51388EEA.5050304@redhat.com> Message-ID: <5138A5A4.4060605@redhat.com> Petr Viktorin wrote: > Hi, > I'm investigating https://fedorahosted.org/freeipa/ticket/3363 (fix > --http_pkcs12 & friends). > I can't find documentation on these options, and from the code I can't > figure out enough about how they are/were supposed to work. > Is it the case that they were last used/tested before IPA started using > Dogtag, and have rotted since then? > > Custom certs don't make sense to use if Dogtag is installed, right? So > when they're provided we should not install the CA and Certmonger? > If that's the case it would be easier (development- and testing-wise) to > just remove self-signed CA in the same set of patches. > I lack a little context about what was discussed on Tuesday but yeah, that sounds about right. We probably only want this if we don't have a real CA (including selfsign) behind IPA and I'm fine with dropping selfsign if we provide a no-CA option. These options come from V1 where many people didn't like our extremely limited selfsign CA and wanted to be able to provide their own certs. The bit-rot is a bit limited I think because a bunch of this code is still used, when installing replicas for example. The problem is that there are a lot of corner cases that we don't exercise because the certs we use are all of one predictable form. John added some PKCS#12 support to python-nss which should make some of this handling a lot cleaner. IIRC right now we handle everything using certutil which is very limiting. We also still tend to stomp on everything we see, and in V1 it was even more so, hence our overwriting NSS database files at will. As for how they should work... We need to stand up two SSL services, HTTP and LDAP. So we provide options for the use to present two PKCS#12 files (they can be the same) and the pins for those files. We need to: - load the PKCS#12 files into an NSS database - determine what the nickname of the server cert is so we can configure things - determine what the nickname of the CA is so we can publish *something* in /etc/ipa/ca.crt, and get the trust right I believe the assumption is that the same CA is used for both SSL and HTTP, though from a technical perspective this doesn't need to be true. And you're right, no certmonger here. There also needs to be some way to enforce that the user provide certs when running ipa-replica-prepare. What I'd propose is a new value for ra_plugin to indicate user-provided certs. I don't know if a new subclass would be desired or not, but it might be nice to provide a specific message rather than 'not implemented' for all cert commands. Be aware that a little bit of selfsign-specific code made it into the parent class in rabase.py. I suspect that pretty much all the NSS database code in __init__ can go away when selfsign is dropped. rob From mkosek at redhat.com Thu Mar 7 14:41:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 07 Mar 2013 15:41:32 +0100 Subject: [Freeipa-devel] [PATCH] 382 Do not hide idrange-add errors when adding trust Message-ID: <5138A71C.6070606@redhat.com> We catched all errors that could be raised by idrange-add command and just raised an uncomprehensible ValidationError. This could hide a real underlying problem and make the debugging harder. We should rather just let the command raise the real error (which will be already a PublicError). https://fedorahosted.org/freeipa/ticket/3288 --- NOTE: I discussed this issue with tsunamie (ticket logger). He hit this error in some early FreeIPA 3.0 release and he does not hit it any more. I also did not reproduce it with current master so I am just sending a patch to allow us/user to see the reason of the range error in case it occurs again. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-382-do-not-hide-idrange-add-errors-when-adding-trust.patch Type: text/x-patch Size: 2041 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 7 15:12:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 16:12:23 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <513730CF.3010904@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> Message-ID: <5138AE57.5010107@redhat.com> Thanks! I just have two more very minor nitpicks. On 03/06/2013 01:04 PM, Tomas Babej wrote: > On 03/05/2013 02:10 PM, Petr Viktorin wrote: >> Thanks! The mechanism works, but see below. >> >> This is a RFE so it needs a design document. >> > http://freeipa.org/page/V3/Client_install_using_keytab Please also add the link to the commit message. I think you answered Petr?'s security questions adequately. Petr, note that this is a client-side change; if the keytab is compromised the attacker can do all this manually anyway. > diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install > index 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b 100755 > --- a/ipa-client/ipa-install/ipa-client-install > +++ b/ipa-client/ipa-install/ipa-client-install > @@ -104,6 +104,8 @@ def parse_options(): [...] > @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): > except ipaclient.ntpconf.NTPConfigurationError: > pass > > - if options.unattended and (options.password is None and options.principal is None and options.prompt_password is False) and not options.on_master: > - root_logger.error("One of password and principal are required.") > + if options.unattended and ((options.password is None and > + options.principal is None and > + options.keytab is None and > + options.prompt_password is False)\ > + and not options.on_master): Please also remove the inner parentheses and the backslash. -- Petr? From tbabej at redhat.com Thu Mar 7 15:27:48 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 07 Mar 2013 16:27:48 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5138AE57.5010107@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> Message-ID: <5138B1F4.4060002@redhat.com> On 03/07/2013 04:12 PM, Petr Viktorin wrote: > Thanks! I just have two more very minor nitpicks. > > On 03/06/2013 01:04 PM, Tomas Babej wrote: >> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>> Thanks! The mechanism works, but see below. >>> >>> This is a RFE so it needs a design document. >>> >> http://freeipa.org/page/V3/Client_install_using_keytab > > Please also add the link to the commit message. > > > I think you answered Petr?'s security questions adequately. > Petr, note that this is a client-side change; if the keytab is > compromised the attacker can do all this manually anyway. > >> diff --git a/ipa-client/ipa-install/ipa-client-install >> b/ipa-client/ipa-install/ipa-client-install >> index >> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >> 100755 >> --- a/ipa-client/ipa-install/ipa-client-install >> +++ b/ipa-client/ipa-install/ipa-client-install >> @@ -104,6 +104,8 @@ def parse_options(): > [...] >> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >> except ipaclient.ntpconf.NTPConfigurationError: >> pass >> >> - if options.unattended and (options.password is None and >> options.principal is None and options.prompt_password is False) and >> not options.on_master: >> - root_logger.error("One of password and principal are >> required.") >> + if options.unattended and ((options.password is None and >> + options.principal is None and >> + options.keytab is None and >> + options.prompt_password is False)\ >> + and not options.on_master): > > Please also remove the inner parentheses and the backslash. > Both fixed, updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0037-3-Add-support-for-re-enrolling-hosts-using-keytab.patch Type: text/x-patch Size: 8406 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 7 15:33:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Mar 2013 16:33:16 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <51389BD3.4000101@redhat.com> References: <51388B54.1090405@redhat.com> <51389BD3.4000101@redhat.com> Message-ID: <5138B33C.7020409@redhat.com> On 7.3.2013 14:53, Petr Viktorin wrote: > On 03/07/2013 01:43 PM, Jan Cholasta wrote: >> Hi, >> >> these patches add flags to LDAPClient and IPAdmin constructors which can >> be used to disable schema retrieval and decoding of attributes. This >> should make interacting with AD easier (see >> ). >> >> Honza > > The first three patches look good, except a nitpick below. > > > In the last patch, I don't see why you added back search_s. Is > get_entries inadequate in some way? Nope, it's just that __search_in_gc uses it. Fixed. > > > >>> From 33142d7e0a8508a783e1a1b4a7a22525337ce54d Mon Sep 17 00:00:00 2001 >> From: Jan Cholasta >> Date: Thu, 7 Mar 2013 10:50:57 +0100 >> Subject: [PATCH 1/4] Do not fail if schema cannot be retrieved from LDAP >> server. >> >> --- >> ipaserver/ipaldap.py | 16 +++++++++++++--- >> 1 file changed, 13 insertions(+), 3 deletions(-) >> >> diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py > [...] >> + try: >> + self._schema = schema_cache.get_schema( >> + self.uri, self.conn, >> + force_update=self._force_schema_updates) >> + except: > > Don't use bare except. Fixed. Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-116.1-Do-not-fail-if-schema-cannot-be-retrieved-from-LDAP-.patch Type: text/x-patch Size: 2014 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-117.1-Allow-disabling-LDAP-schema-retrieval-in-LDAPClient-.patch Type: text/x-patch Size: 2432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-118.1-Allow-disabling-attribute-decoding-in-LDAPClient-and.patch Type: text/x-patch Size: 2741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-119.1-Disable-schema-retrieval-and-attribute-decoding-when.patch Type: text/x-patch Size: 1579 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 7 15:54:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 16:54:02 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5138B1F4.4060002@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> <5138B1F4.4060002@redhat.com> Message-ID: <5138B81A.4060700@redhat.com> On 03/07/2013 04:27 PM, Tomas Babej wrote: > On 03/07/2013 04:12 PM, Petr Viktorin wrote: >> Thanks! I just have two more very minor nitpicks. >> >> On 03/06/2013 01:04 PM, Tomas Babej wrote: >>> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>>> Thanks! The mechanism works, but see below. >>>> >>>> This is a RFE so it needs a design document. >>>> >>> http://freeipa.org/page/V3/Client_install_using_keytab >> >> Please also add the link to the commit message. >> >> >> I think you answered Petr?'s security questions adequately. >> Petr, note that this is a client-side change; if the keytab is >> compromised the attacker can do all this manually anyway. >> >>> diff --git a/ipa-client/ipa-install/ipa-client-install >>> b/ipa-client/ipa-install/ipa-client-install >>> index >>> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >>> 100755 >>> --- a/ipa-client/ipa-install/ipa-client-install >>> +++ b/ipa-client/ipa-install/ipa-client-install >>> @@ -104,6 +104,8 @@ def parse_options(): >> [...] >>> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >>> except ipaclient.ntpconf.NTPConfigurationError: >>> pass >>> >>> - if options.unattended and (options.password is None and >>> options.principal is None and options.prompt_password is False) and >>> not options.on_master: >>> - root_logger.error("One of password and principal are >>> required.") >>> + if options.unattended and ((options.password is None and >>> + options.principal is None and >>> + options.keytab is None and >>> + options.prompt_password is False)\ >>> + and not options.on_master): >> >> Please also remove the inner parentheses and the backslash. >> > Both fixed, updated patch attached. > > Tomas ACK, thanks! -- Petr? From tbabej at redhat.com Thu Mar 7 15:58:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 07 Mar 2013 16:58:04 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5138B81A.4060700@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> <5138B1F4.4060002@redhat.com> <5138B81A.4060700@redhat.com> Message-ID: <5138B90C.8000103@redhat.com> On Thu 07 Mar 2013 04:54:02 PM CET, Petr Viktorin wrote: > On 03/07/2013 04:27 PM, Tomas Babej wrote: >> On 03/07/2013 04:12 PM, Petr Viktorin wrote: >>> Thanks! I just have two more very minor nitpicks. >>> >>> On 03/06/2013 01:04 PM, Tomas Babej wrote: >>>> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>>>> Thanks! The mechanism works, but see below. >>>>> >>>>> This is a RFE so it needs a design document. >>>>> >>>> http://freeipa.org/page/V3/Client_install_using_keytab >>> >>> Please also add the link to the commit message. >>> >>> >>> I think you answered Petr?'s security questions adequately. >>> Petr, note that this is a client-side change; if the keytab is >>> compromised the attacker can do all this manually anyway. >>> >>>> diff --git a/ipa-client/ipa-install/ipa-client-install >>>> b/ipa-client/ipa-install/ipa-client-install >>>> index >>>> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >>>> >>>> 100755 >>>> --- a/ipa-client/ipa-install/ipa-client-install >>>> +++ b/ipa-client/ipa-install/ipa-client-install >>>> @@ -104,6 +104,8 @@ def parse_options(): >>> [...] >>>> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >>>> except ipaclient.ntpconf.NTPConfigurationError: >>>> pass >>>> >>>> - if options.unattended and (options.password is None and >>>> options.principal is None and options.prompt_password is False) and >>>> not options.on_master: >>>> - root_logger.error("One of password and principal are >>>> required.") >>>> + if options.unattended and ((options.password is None and >>>> + options.principal is None and >>>> + options.keytab is None and >>>> + options.prompt_password is False)\ >>>> + and not options.on_master): >>> >>> Please also remove the inner parentheses and the backslash. >>> >> Both fixed, updated patch attached. >> >> Tomas > > ACK, thanks! > With your blessing, I moved the link to the design page from V3 proposals to V3 designs. Tomas From pvoborni at redhat.com Thu Mar 7 16:32:54 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 Mar 2013 17:32:54 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <513893EC.2040101@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> <51387CE4.2040001@redhat.com> <513893EC.2040101@redhat.com> Message-ID: <5138C136.9000504@redhat.com> On 03/07/2013 02:19 PM, Ana Krivokapic wrote: > On 03/07/2013 12:41 PM, Petr Vobornik wrote: >> On 03/06/2013 08:26 PM, Ana Krivokapic wrote: >>> On 03/06/2013 10:40 AM, Petr Vobornik wrote: >>>> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>>>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>>>> Add support for Realm Domains to web UI. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>>>> 8><----------------------- >> >> Almost there, as discussed in person: >> >> 1. following strings should be add to and obtained from internal.py >> plugin: >> title: 'Check DNS', >> message: 'Do you also want to perform DNS check?', >> ok_label: 'Check DNS', >> >> >> 2. the server plugin should report all dns resolution failures, not >> just the first one. > > Fixed, updated patch is attached. > Works fine, but you forgot to update all related tests (s/domain/domains/): > ====================================================================== > FAIL: test_realmdomains[8]: realmdomains_mod: Try to replace list of realm domains with a list with an invalid domain "doesnotexist.test" > ---------------------------------------------------------------------- > 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/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 264, in > func = lambda: self.check(nice, **test) > File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 278, in check > self.check_exception(nice, cmd, args, options, expected) > File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/home/pvoborni/dev/freeipa/tests/util.py", line 343, in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'domain': no SOA or NS records found for domains: doesnotexist.test" > got = u"invalid 'domain': no SOA or NS records found for domain doesnotexist.test" > path = () > > ---------------------------------------------------------------------- -- Petr Vobornik From jcholast at redhat.com Thu Mar 7 16:42:22 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Mar 2013 17:42:22 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513760D6.9010305@redhat.com> References: <513760D6.9010305@redhat.com> Message-ID: <5138C36E.2070406@redhat.com> On 6.3.2013 16:29, Petr Viktorin wrote: > Hello, > These patches move ipaldap to ipapython, and make the client installer > use it. Also password migration web-app is made to use ipaldap; they > both called a shared a utility function that is converted to use ipaldap. > > This should fix https://fedorahosted.org/freeipa/ticket/3446 > (freeipa-client-install KeyError in 'namingcontexts') and similar errors. > > https://fedorahosted.org/freeipa/ticket/3487 > Patch 191: The patch is missing the ipapython/ipaldap.py file. I think it should go into ipalib instead of ipapython. It doesn't make sense to keep ipapython and ipalib separate if they depend on each other. We should either merge them or clean up the mess by removing ipalib imports from ipapython. I'm not saying we should do it now, just please don't add new modules to ipapython which import from ipalib. Also I am not very fond of the "ipa" prefix in "ipaldap". The module lives in the namespace of our own package, so there's no need for it to have such a prefix, is there? Patch 193: + scope=conn.SCOPE_BASE, + filter='objectclass=pkiCA', + attrs_list=[ca_cert_attr], Can we use a proper filter here please? + :param conn: Bound LDAPConnection that will be used for searching LDAPClient Patch 194: - ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, True) and - lh.set_option(ldap.OPT_X_TLS_DEMAND, True) Is removing these options safe? Honza -- Jan Cholasta From pviktori at redhat.com Thu Mar 7 16:59:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 17:59:14 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <5138B33C.7020409@redhat.com> References: <51388B54.1090405@redhat.com> <51389BD3.4000101@redhat.com> <5138B33C.7020409@redhat.com> Message-ID: <5138C762.4090405@redhat.com> On 03/07/2013 04:33 PM, Jan Cholasta wrote: > On 7.3.2013 14:53, Petr Viktorin wrote: >> On 03/07/2013 01:43 PM, Jan Cholasta wrote: >>> Hi, >>> >>> these patches add flags to LDAPClient and IPAdmin constructors which can >>> be used to disable schema retrieval and decoding of attributes. This >>> should make interacting with AD easier (see >>> ). >>> >>> >>> Honza [...] > > Updated patches attached. > > Honza > In LDAPEntry.__setitem__, schema.get_obj is used without checking if the schema is None. -- Petr? From rcritten at redhat.com Thu Mar 7 17:01:51 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 12:01:51 -0500 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <5138C36E.2070406@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> Message-ID: <5138C7FF.2070207@redhat.com> Jan Cholasta wrote: > On 6.3.2013 16:29, Petr Viktorin wrote: >> Hello, >> These patches move ipaldap to ipapython, and make the client installer >> use it. Also password migration web-app is made to use ipaldap; they >> both called a shared a utility function that is converted to use ipaldap. >> >> This should fix https://fedorahosted.org/freeipa/ticket/3446 >> (freeipa-client-install KeyError in 'namingcontexts') and similar errors. >> >> https://fedorahosted.org/freeipa/ticket/3487 >> > > Patch 191: > > The patch is missing the ipapython/ipaldap.py file. > > I think it should go into ipalib instead of ipapython. It doesn't > make sense to keep ipapython and ipalib separate if they depend on each > other. We should either merge them or clean up the mess by removing > ipalib imports from ipapython. I'm not saying we should do it now, just > please don't add new modules to ipapython which import from ipalib. There have been platforms in the past that we do not ship the framework on (e.g. RHEL 5). ipapython is supposed to be platform agnostic, though it clearly isn't, to allow a bridge for those systems that can't or won't have the framework. So I think removing the imports from ipapython is the way to go. rob From jcholast at redhat.com Thu Mar 7 17:21:51 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Mar 2013 18:21:51 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <5138C762.4090405@redhat.com> References: <51388B54.1090405@redhat.com> <51389BD3.4000101@redhat.com> <5138B33C.7020409@redhat.com> <5138C762.4090405@redhat.com> Message-ID: <5138CCAF.7090202@redhat.com> On 7.3.2013 17:59, Petr Viktorin wrote: > On 03/07/2013 04:33 PM, Jan Cholasta wrote: >> On 7.3.2013 14:53, Petr Viktorin wrote: >>> On 03/07/2013 01:43 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> these patches add flags to LDAPClient and IPAdmin constructors which >>>> can >>>> be used to disable schema retrieval and decoding of attributes. This >>>> should make interacting with AD easier (see >>>> ). >>>> >>>> >>>> >>>> Honza > [...] >> >> Updated patches attached. >> >> Honza >> > > In LDAPEntry.__setitem__, schema.get_obj is used without checking if the > schema is None. > I knew I forgot something! Thanks. Fixed. Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-116.2-Do-not-fail-if-schema-cannot-be-retrieved-from-LDAP-.patch Type: text/x-patch Size: 2580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-117.2-Allow-disabling-LDAP-schema-retrieval-in-LDAPClient-.patch Type: text/x-patch Size: 2432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-118.2-Allow-disabling-attribute-decoding-in-LDAPClient-and.patch Type: text/x-patch Size: 2741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-119.2-Disable-schema-retrieval-and-attribute-decoding-when.patch Type: text/x-patch Size: 1579 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 7 17:29:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Mar 2013 18:29:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <5138C7FF.2070207@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5138C7FF.2070207@redhat.com> Message-ID: <5138CE7A.1070809@redhat.com> On 03/07/2013 06:01 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 6.3.2013 16:29, Petr Viktorin wrote: >>> Hello, >>> These patches move ipaldap to ipapython, and make the client installer >>> use it. Also password migration web-app is made to use ipaldap; they >>> both called a shared a utility function that is converted to use >>> ipaldap. >>> >>> This should fix https://fedorahosted.org/freeipa/ticket/3446 >>> (freeipa-client-install KeyError in 'namingcontexts') and similar >>> errors. >>> >>> https://fedorahosted.org/freeipa/ticket/3487 >>> >> >> Patch 191: >> >> The patch is missing the ipapython/ipaldap.py file. It's there, it's just copied from ipaserver/ipaldap.py with a small change at the bottom. I'll respond to the other comments tomorrow. >> >> I think it should go into ipalib instead of ipapython. It doesn't >> make sense to keep ipapython and ipalib separate if they depend on each >> other. We should either merge them or clean up the mess by removing >> ipalib imports from ipapython. I'm not saying we should do it now, just >> please don't add new modules to ipapython which import from ipalib. >> > > There have been platforms in the past that we do not ship the framework > on (e.g. RHEL 5). ipapython is supposed to be platform agnostic, though > it clearly isn't, to allow a bridge for those systems that can't or > won't have the framework. So I think removing the imports from ipapython > is the way to go. > Then we need to move errors and text to ipapython, those need to be imported pretty much everywhere. -- Petr? From sbose at redhat.com Thu Mar 7 17:32:27 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 7 Mar 2013 18:32:27 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <20130306163343.GC16010@localhost.localdomain> References: <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> <20130306094108.GA16010@localhost.localdomain> <5137497E.4010204@redhat.com> <1362577907.2822.2.camel@willson.li.ssimo.org> <20130306163343.GC16010@localhost.localdomain> Message-ID: <20130307173227.GI16010@localhost.localdomain> On Wed, Mar 06, 2013 at 05:33:43PM +0100, Sumit Bose wrote: > On Wed, Mar 06, 2013 at 08:51:47AM -0500, Simo Sorce wrote: > > On Wed, 2013-03-06 at 14:49 +0100, Martin Kosek wrote: > > > On 03/06/2013 10:41 AM, Sumit Bose wrote: > > > > On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: > > > >> On 03/04/2013 04:22 PM, Sumit Bose wrote: > > > >>> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: > > > >>>> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: > > > >>>>> On 03/01/2013 09:20 AM, Sumit Bose wrote: > > > >>>>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: > > > >>>>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: > > > >>>>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: > > > >>>>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: > > > >>>>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: > > > >>>>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: > > > >>>>>>>> > > > >>>>>>>>>>> Hi Sumit, > > > >>>>>>>>>>> > > > >>>>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. > > > >>>>>>>>>>> Though I would not add this service-specific setting to global IPA config object. > > > >>>>>>>>>>> > > > >>>>>>>>>>> I would rather like to see that in the service tree, for example as a > > > >>>>>>>>>>> configuration option of the service root which could be controlled with > > > >>>>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: > > > >>>>>>>>>>> > > > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE > > > >>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD > > > >>>>>>>>>>> # ipa serviceconfig-show > > > >>>>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD > > > >>>>>>>>>> > > > >>>>>>>>>> Are you thinking of having this in addition to the for-all-services > > > >>>>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't > > > >>>>>>>>>> like the first case because then three different objects needs to be > > > >>>>>>>>>> consulted to find out which is the right type. This wouldn't be an issue > > > >>>>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. > > > >>>>>>>>> > > > >>>>>>>>> Hm, you are right. > > > >>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> If the current defaults shall be dropped I think this is a major change > > > >>>>>>>>>> because it will require changes in the current CLI and WebUI which will > > > >>>>>>>>>> be visible to the users. I'm not against this change, I'm just wondering > > > >>>>>>>>>> if it is worth the effort for the next release? > > > >>>>>>>>>> > > > >>>>>>>>>> Maybe an argument to keep this is in global default is that the settings > > > >>>>>>>>>> are used for the host/*.* services as well which are in a different > > > >>>>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might > > > >>>>>>>>>> want apply those setting to the user TGTs as well? > > > >>>>>>>>> > > > >>>>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC > > > >>>>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and > > > >>>>>>>>> user principals. This automatic PAC rules may require some designing so that is > > > >>>>>>>>> is generally usable. > > > >>>>>>>> > > > >>>>>>>> I think putting everything in the general config is more understandable > > > >>>>>>>> and discoverable. These per-service defaults are basically exceptions to > > > >>>>>>>> the general rule so it make sense to keep everything together. > > > >>>>>>>> > > > >>>>>>>> Simo. > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> Ok, if these are really just an exceptions to the general rule (and there will > > > >>>>>>> not be too many of them), I think we can leave it in config entry. But if we > > > >>>>>>> expect to have exceptions for other types of entries (hosts, users), I think we > > > >>>>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. > > > >>>>>>> > > > >>>>>>> Question is, do we want to implement the interface and processing for that in > > > >>>>>>> current Sumit's patches or do we use that is they are? > > > >>>>>> > > > >>>>>> I would like to update the patches so that they can handle the > > > >>>>>> service:TYPE style entry and replace the current update code with just > > > >>>>>> adding nfs:NONE to the global options. I will update the design page > > > >>>>>> accordingly, too. > > > >>>>> > > > >>>>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd > > > >>>>> be great. > > > >>>> > > > >>>> If we need to distinguish between service principals and user principals > > > >>>> I would prefer rather use a special keyword for upns > > > >>>> > > > >>>> service: is redundant and I do not want here to be able to say > > > >>>> upn:martin:NONE because per principal options are available on the > > > >>>> principal object. > > > >>>> > > > >>>> I actually really do not see the need for changing the default just for > > > >>>> user principals. If we are worried that one day we might want to really > > > >>>> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we > > > >>>> might add upn:NONE and the lack of / will tell us this is not a service > > > >>>> named upn/foo.bar.baz but rather it means user principal names. > > > >>>> > > > >>>> However I do not see us ever really needing upn:NONE > > > >>>> > > > >>>>>> I would prefer if the enhancements needed for the CLI and WebUI can be > > > >>>>>> covered by other/new tickets, but I'm happy to add the needed > > > >>>>>> information to the design page too. > > > >>>>>> > > > >>>>>> bye, > > > >>>>>> Sumit > > > >>>>> > > > >>>>> I am OK with adding the interface for this special exception later. In that > > > >>>>> case, a ticket + note in the design as you mentioned would be enough. > > > >>>> > > > >>>> Ack. > > > >>>> > > > >>>> Simo. > > > >>>> > > > >>> > > > >>> Please find attached a new version of the patches. 0095 i(updating) is > > > >>> renamed and much simpler now. I opened > > > >>> https://fedorahosted.org/freeipa/ticket/3484 to added the needed change > > > >>> for 'service:TYPE' to CLI and WebUI. For the time being I've added > > > >>> patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it > > > >>> is not deleted accidentally when e.g. using the WebUI. If you do not > > > >>> like it it can simply be dropped, everything is working fine without it. > > > >>> > > > >>> bye, > > > >>> Sumit > > > >>> > > > >> > > > >> Patch 0098: > > > >> > > > >> If this part does not match (and it will not for all non-nfs service principals): > > > >> > > > >> + if (service_type->length == (sep - authz_data_list[c]) && > > > >> + strncmp(authz_data_list[c], service_type->data, > > > >> + service_type->length) == 0) { > > > >> + authz_data_type = sep + 1; > > > >> + } > > > >> > > > >> krb5kdc.log will contain an error: > > > >> > > > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported > > > >> authorization data type [nfs:NONE]. > > > >> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 > > > >> 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 > > > >> ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for > > > >> ldap/ipa.linux.ad.test at LINUX.AD.TEST > > > >> > > > >> I think we should just "continue" in this case. > > > > > > > > good catch, fixed > > > > > > Ok, thanks. > > > > > > > > > > >> > > > >> Otherwise, this looks and works fine. > > > > > > > > Thank you for the review, new version attached. > > > > > > > > I have an additional question about processing the service specific > > > > defaults. Using 'service:NONE' is unambiguous because NONE trumps all. > > > > But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a > > > > LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think > > > > the first one where all defaults which apply to a service are added up > > > > is more clear, and this is also the way the current code works. But I > > > > wouldn't mind to change the logic if you think it makes more sense the > > > > other way round, i.e. if there is a service specific default matching > > > > the requested service only the service specific default are accounted. > > > > > > Hmm, that's a good question. I understand service:PACTYPE as an exclusion to > > > the general setting, so for me it would make sense to override the global > > > config - i.e. tje second case. > > > > > > Thus, if global config is MS-PAC, ldap:PAD, I think that ldap should have just > > > PAD. If one also want MS-PAC, it should be set like "MS-PAC, ldap:PAD, > > > ldap:MS-PAC". Otherwise you would not be able to configure that you want MS-PAC > > > for all services and _only_ PAD for ldap... > > > > > > Does it make sense? We should also make sure that we update the RFE page to > > > whatever we decide to do. > > > > +1 to Martin's choice. > > Martin, Simo, thank you for the feedback. I will send an new version of > the patches, add a section in the design page explaining the details and > add some tests for this logic. > > bye, > Sumit Design pages is updated and new patches attached. bye, Sumit -------------- next part -------------- From 50c64c4db3601bba96e7aeadf6003628eea3282e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:59:00 +0100 Subject: [PATCH 094/101] Revert "MS-PAC: Special case NFS services" This reverts commit 5269458f552380759c86018cd1f30b64761be92e. With the implementation of https://fedorahosted.org/freeipa/ticket/2960 a special hardcoded handling of NFS service tickets is not needed anymore. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 36 +----------------------------------- 1 file changed, 1 insertion(+), 35 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 5071348d90dedf60f8140e0a53b07d09a947d31f..eafba97393cdda43d8a2a4616f65f2291ba08aa7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -743,24 +743,6 @@ static bool is_cross_realm_krbtgt(krb5_const_principal princ) return true; } -static bool is_service_of_type(krb5_const_principal princ, const char *type) -{ - size_t len; - - if (princ->length < 2) { - return false; - } - - len = strlen(type); - - if ((princ->data[0].length == len) || - (strncasecmp(princ->data[0].data, type, len) == 0)) { - return true; - } - - return false; -} - static char *gen_sid_string(TALLOC_CTX *memctx, struct dom_sid *dom_sid, uint32_t rid) { @@ -1555,7 +1537,6 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; - bool is_nfs = false; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1566,32 +1547,17 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } - /* NFS Server on Linux is limited and will choke on big tickets. - * So avoid attachnig the PAC to nfs/ tickets for now. - * FIXME: remove this when we have interface to support disabling - * PACs on arbitrary services */ - if (is_service_of_type(ks_client_princ, "nfs") || - is_service_of_type(server->princ, "nfs")) { - is_nfs = true; - } - is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { - if (is_nfs) { - *signed_auth_data = NULL; - kerr = 0; - goto done; - } - kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } } - if (!is_as_req & !is_nfs) { + if (!is_as_req) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 01b674384d3ac9fbfa652b9d9ed8d72cc5c9e946 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:25:43 +0100 Subject: [PATCH 095/101] Add NFS specific default for authorization data type Since the hardcoded default fpr the NFS service was removed the default authorization data type is now set in the global server configuration. --- install/updates/60-trusts.update | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index cd7a7e355230168f6ed9333505469a0aa7498ba9..454ecb745a9cf266a200f64cdea0b11872858113 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -71,6 +71,11 @@ replace:aci:'(targetattr = "userPassword || krbPrincipalKey || sambaLMPassword | dn: cn=ipaConfig,cn=etc,$SUFFIX addifnew: ipaKrbAuthzData: MS-PAC +# Add authorization data type NONE for NFS because the hardcoded default was +# removed. +dn: cn=ipaConfig,cn=etc,$SUFFIX +add: ipaKrbAuthzData: nfs:NONE + # Fix typo in some installs in the spelling of ORDERING. They were added # with a typo which was silently dropped by 389-ds-base, so add in the # proper ordering syntax now. -- 1.8.1.2 -------------- next part -------------- From 22d554cd6a2ea59229206e0eed60c7ebf631f8ad Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 11:01:11 +0100 Subject: [PATCH 096/101] ipa-kdb: Read global defaul ipaKrbAuthzData The ipaKrbAuthzData LDAP attribute is read from the ipaConfig object and the read value(s) are stored in the ipadb context. --- daemons/ipa-kdb/ipa_kdb.c | 27 ++++++++++++++++++++++++++- daemons/ipa-kdb/ipa_kdb.h | 3 +++ 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 2a344dc69158dbc3f6d0207ab0bb781676240ed9..e5c718ea9ffd38dbd49026e825d4a7f920638181 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -40,6 +40,8 @@ struct ipadb_context *ipadb_get_context(krb5_context kcontext) static void ipadb_context_free(krb5_context kcontext, struct ipadb_context **ctx) { + size_t c; + if (*ctx != NULL) { free((*ctx)->uri); free((*ctx)->base); @@ -51,6 +53,12 @@ static void ipadb_context_free(krb5_context kcontext, free((*ctx)->supp_encs); ipadb_mspac_struct_free(&(*ctx)->mspac); krb5_free_default_realm(kcontext, (*ctx)->realm); + + for (c = 0; (*ctx)->authz_data && (*ctx)->authz_data[c]; c++) { + free((*ctx)->authz_data[c]); + } + free((*ctx)->authz_data); + free(*ctx); *ctx = NULL; } @@ -167,13 +175,14 @@ done: int ipadb_get_global_configs(struct ipadb_context *ipactx) { - char *attrs[] = { "ipaConfigString", NULL }; + char *attrs[] = { "ipaConfigString", IPA_KRB_AUTHZ_DATA_ATTR, NULL }; struct berval **vals = NULL; LDAPMessage *res = NULL; LDAPMessage *first; char *base = NULL; int i; int ret; + char **authz_data_list; ret = asprintf(&base, "cn=ipaConfig,cn=etc,%s", ipactx->base); if (ret == -1) { @@ -215,6 +224,22 @@ int ipadb_get_global_configs(struct ipadb_context *ipactx) } } + ret = ipadb_ldap_attr_to_strlist(ipactx->lcontext, first, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + goto done; + } + if (ret == 0) { + if (ipactx->authz_data != NULL) { + for (i = 0; ipactx->authz_data[i]; i++) { + free(ipactx->authz_data[i]); + } + free(ipactx->authz_data); + } + + ipactx->authz_data = authz_data_list; + } + ret = 0; done: diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f472f02458e040b921b9f3f85bcc36fa954785d5..7b1576124140ae53cf28a1ed47bfa1acf31cdd59 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -74,6 +74,8 @@ #define IPA_SETUP "ipa-setup-override-restrictions" +#define IPA_KRB_AUTHZ_DATA_ATTR "ipaKrbAuthzData" + struct ipadb_mspac; struct ipadb_context { @@ -89,6 +91,7 @@ struct ipadb_context { struct ipadb_mspac *mspac; bool disable_last_success; bool disable_lockout; + char **authz_data; }; #define IPA_E_DATA_MAGIC 0x0eda7a -- 1.8.1.2 -------------- next part -------------- From 3fa054b938196925d9ce0849a02ecb26d5aa4719 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 09:44:32 +0100 Subject: [PATCH 097/101] ipa-kdb: Read ipaKrbAuthzData with other principal data The ipaKrbAuthzData LDAP attribute is read together with the other data of the requestedprincipal and the read value(s) are stored in the e-data of the entry for later use. --- daemons/ipa-kdb/ipa_kdb.h | 1 + daemons/ipa-kdb/ipa_kdb_principals.c | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 7b1576124140ae53cf28a1ed47bfa1acf31cdd59..9daaab80dc514dd1bb3e85775c1e284d19dac0cd 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -105,6 +105,7 @@ struct ipadb_e_data { char **pw_history; struct ipapwd_policy *pol; time_t last_admin_unlock; + char **authz_data; }; struct ipadb_context *ipadb_get_context(krb5_context kcontext); diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 13f6a21f1556668e8e9acd54f3d0e6a345eb00dc..11c155e64e20d16da98158eb4d7b8034803bf1de 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -63,6 +63,7 @@ static char *std_principal_attrs[] = { /* IPA SPECIFIC ATTRIBUTES */ "nsaccountlock", "passwordHistory", + IPA_KRB_AUTHZ_DATA_ATTR, "objectClass", NULL @@ -237,6 +238,7 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, krb5_kvno mkvno = 0; char **restrlist; char *restring; + char **authz_data_list; krb5_timestamp restime; bool resbool; int result; @@ -503,6 +505,17 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, ied->last_admin_unlock = restime; } + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, + IPA_KRB_AUTHZ_DATA_ATTR, &authz_data_list); + if (ret != 0 && ret != ENOENT) { + kerr = KRB5_KDB_INTERNAL_ERROR; + goto done; + } + if (ret == 0) { + ied->authz_data = authz_data_list; + } + + kerr = 0; done: @@ -831,6 +844,10 @@ void ipadb_free_principal(krb5_context kcontext, krb5_db_entry *entry) free(ied->pw_history[i]); } free(ied->pw_history); + for (i = 0; ied->authz_data && ied->authz_data[i]; i++) { + free(ied->authz_data[i]); + } + free(ied->authz_data); free(ied->pol); free(ied); } -- 1.8.1.2 -------------- next part -------------- From 50ec2a090f55c76610b7cafa0addd8ce1c02d37e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 12 Feb 2013 14:02:27 +0100 Subject: [PATCH] ipa-kdb: add PAC only if requested Instead of always adding a PAC to the Kerberos ticket the global default for the authorization data and the authorization data of the service entry is evaluated and the PAC is added accordingly. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 142 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 140 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index eafba97393cdda43d8a2a4616f65f2291ba08aa7..2662b947bd589074faa1acf6a9bb97748161cb05 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -96,6 +96,10 @@ static char *memberof_pac_attrs[] = { #define SID_SUB_AUTHS 15 #define MAX(a,b) (((a)>(b))?(a):(b)) +#define AUTHZ_DATA_TYPE_PAC "MS-PAC" +#define AUTHZ_DATA_TYPE_PAD "PAD" +#define AUTHZ_DATA_TYPE_NONE "NONE" + static int string_to_sid(char *str, struct dom_sid *sid) { unsigned long val; @@ -1515,6 +1519,127 @@ done: return kerr; } +void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *_with_pac, bool *_with_pad) +{ + struct ipadb_e_data *ied = NULL; + struct ipadb_context *ipactx; + size_t c; + bool none_found = false; + bool srv_none_found = false; + char **authz_data_list; + bool with_pac = false; + bool srv_with_pac = false; + bool with_pad = false; + bool srv_with_pad = false; + char *sep; + krb5_data *service_type; + char *authz_data_type; + bool service_specific; + + if (entry != NULL) { + ied = (struct ipadb_e_data *) entry->e_data; + } + + if (ied == NULL || ied->authz_data == NULL) { + if (context == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing Kerberos context, no " \ + "authorization data will be added."); + goto done; + } + + ipactx = ipadb_get_context(context); + if (ipactx == NULL || ipactx->authz_data == NULL) { + krb5_klog_syslog(LOG_ERR, "No default authorization data types " \ + "available, no authorization data will " \ + "be added."); + goto done; + } + + authz_data_list = ipactx->authz_data; + } else { + authz_data_list = ied->authz_data; + } + + + for (c = 0; authz_data_list[c]; c++) { + service_specific = false; + authz_data_type = authz_data_list[c]; + sep = strchr(authz_data_list[c], ':'); + if (sep != NULL) { + if (entry->princ == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing principal in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + service_type = krb5_princ_component(context, entry->princ, 0); + if (service_type == NULL) { + krb5_klog_syslog(LOG_ERR, "Missing service type in database " + "entry, no authorization data will " \ + "be added."); + goto done; + } + + if (service_type->length == (sep - authz_data_list[c]) && + strncmp(authz_data_list[c], service_type->data, + service_type->length) == 0) { + service_specific = true; + authz_data_type = sep + 1; + } else { + /* Service specific default does not apply, skipping this + * entry. */ + continue; + } + } + + if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAC) == 0) { + if (service_specific) { + srv_with_pac = true; + } else { + with_pac = true; + } + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_PAD) == 0) { + if (service_specific) { + srv_with_pad = true; + } else { + with_pad = true; + } + } else if (strcmp(authz_data_type, AUTHZ_DATA_TYPE_NONE) == 0) { + if (service_specific) { + srv_none_found = true; + } else { + none_found = true; + } + } else { + krb5_klog_syslog(LOG_ERR, "Ignoring unsupported " \ + "authorization data type [%s].", + authz_data_list[c]); + } + } + +done: + if (srv_none_found || srv_with_pac || srv_with_pad) { + none_found = srv_none_found; + with_pac = srv_with_pac; + with_pad = srv_with_pad; + } + + if (none_found) { + with_pac = false; + with_pad = false; + } + + if (_with_pac != NULL) { + *_with_pac = with_pac; + } + if (_with_pad != NULL) { + *_with_pad = with_pad; + } + +} + krb5_error_code ipadb_sign_authdata(krb5_context context, unsigned int flags, krb5_const_principal client_princ, @@ -1537,6 +1662,8 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; + bool with_pac; + bool with_pad; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1547,9 +1674,20 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, ks_client_princ = client->princ; } + /* We only need to check the server entry here, because even if the client + * is a service with a valid authorization data it will result to NONE + * because ipadb_get_pac() can only generate a pac for 'real' IPA users. + * (I assume this will be the same for PAD.) */ + get_authz_data_types(context, server, &with_pac, &with_pad); + + if (with_pad) { + krb5_klog_syslog(LOG_ERR, "PAD authorization data is requested but " \ + "currently not supported."); + } + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); - if (is_as_req && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { + if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { @@ -1557,7 +1695,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, } } - if (!is_as_req) { + if (!is_as_req && with_pac) { /* find the existing PAC, if present */ kerr = krb5_find_authdata(context, tgt_auth_data, NULL, KRB5_AUTHDATA_WIN2K_PAC, &pac_auth_data); -- 1.8.1.2 -------------- next part -------------- From 89485808e16696aaea8cd10c49837caa7d57adda Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 19 Feb 2013 12:16:37 +0100 Subject: [PATCH] Add unit test for get_authz_data_types() --- daemons/ipa-kdb/Makefile.am | 29 +++++ daemons/ipa-kdb/tests/ipa_kdb_tests.c | 217 ++++++++++++++++++++++++++++++++++ 2 files changed, 246 insertions(+) create mode 100644 daemons/ipa-kdb/tests/ipa_kdb_tests.c diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am index 5f4e6e2a6a940486a0c904f737f28c476df98773..23ba1cc05ec157a0f4d9b594350ebaf10b2098dc 100644 --- a/daemons/ipa-kdb/Makefile.am +++ b/daemons/ipa-kdb/Makefile.am @@ -52,6 +52,35 @@ ipadb_la_LIBADD = \ $(NDRPAC_LIBS) \ $(NULL) +if HAVE_CHECK +TESTS = ipa_kdb_tests +check_PROGRAMS = ipa_kdb_tests +endif + +ipa_kdb_tests_SOURCES = \ + tests/ipa_kdb_tests.c \ + ipa_kdb.c \ + ipa_kdb_common.c \ + ipa_kdb_mkey.c \ + ipa_kdb_passwords.c \ + ipa_kdb_principals.c \ + ipa_kdb_pwdpolicy.c \ + ipa_kdb_mspac.c \ + ipa_kdb_delegation.c \ + ipa_kdb_audit_as.c \ + $(KRB5_UTIL_SRCS) \ + $(NULL) +ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS) +ipa_kdb_tests_LDADD = \ + $(CHECK_LIBS) \ + $(KRB5_LIBS) \ + $(LDAP_LIBS) \ + $(NDRPAC_LIBS) \ + -lnss3 \ + -lkdb5 \ + -lsss_idmap \ + $(NULL) + dist_noinst_DATA = ipa_kdb.exports EXTRA_DIST = \ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..fbee4acdbe8d6426664aef8e2d826ef6c065a514 --- /dev/null +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -0,0 +1,217 @@ +/** 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) 2013 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#include +#include +#include +#include +#include +#include +#include + +#include "ipa-kdb/ipa_kdb.h" + +#define NFS_PRINC_STRING "nfs/fully.qualified.host.name at REALM.NAME" +#define NON_NFS_PRINC_STRING "abcdef/fully.qualified.host.name at REALM.NAME" + +int krb5_klog_syslog(int l, const char *format, ...) +{ + va_list ap; + char *s = NULL; + int ret; + + va_start(ap, format); + + ret = vasprintf(&s, format, ap); + va_end(ap); + if (ret < 0) { + /* ENOMEM */ + return -1; + } + + fprintf(stderr, "%s\n", s); + free(s); + + return 0; +} + +extern void get_authz_data_types(krb5_context context, krb5_db_entry *entry, + bool *with_pac, bool *with_pad); + +START_TEST(test_get_authz_data_types) +{ + bool with_pac; + bool with_pad; + krb5_db_entry *entry; + struct ipadb_e_data *ied; + size_t c; + char *ad_none_only[] = {"NONE", NULL}; + char *ad_pad_only[] = {"PAD", NULL}; + char *ad_pac_only[] = {"MS-PAC", NULL}; + char *ad_illegal_only[] = {"abc", NULL}; + char *ad_pac_and_pad[] = {"MS-PAC", "PAD", NULL}; + char *ad_pac_and_none[] = {"MS-PAC", "NONE", NULL}; + char *ad_none_and_pad[] = {"NONE", "PAD", NULL}; + char *ad_global_pac_nfs_none[] = {"MS-PAC", "nfs:NONE", NULL}; + char *ad_global_pac_nfs_pad[] = {"MS-PAC", "nfs:PAD", NULL}; + krb5_context krb5_ctx; + krb5_error_code kerr; + struct ipadb_context *ipa_ctx; + krb5_principal nfs_princ; + krb5_principal non_nfs_princ; + + get_authz_data_types(NULL, NULL, NULL, NULL); + + with_pad = true; + get_authz_data_types(NULL, NULL, NULL, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, NULL); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + with_pad = true; + with_pac = true; + get_authz_data_types(NULL, NULL, &with_pac, &with_pad); + fail_unless(!with_pad, "with_pad not false with NULL inuput."); + fail_unless(!with_pac, "with_pac not false with NULL inuput."); + + entry = calloc(1, sizeof(krb5_db_entry)); + fail_unless(entry != NULL, "calloc krb5_db_entry failed."); + + ied = calloc(1, sizeof(struct ipadb_e_data)); + fail_unless(ied != NULL, "calloc struct ipadb_e_data failed."); + entry->e_data = (void *) ied; + + kerr = krb5_init_context(&krb5_ctx); + fail_unless(kerr == 0, "krb5_init_context failed."); + kerr = krb5_db_setup_lib_handle(krb5_ctx); + fail_unless(kerr == 0, "krb5_db_setup_lib_handle failed.\n"); + ipa_ctx = calloc(1, sizeof(struct ipadb_context)); + fail_unless(ipa_ctx != NULL, "calloc failed.\n"); + ipa_ctx->kcontext = krb5_ctx; + kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); + fail_unless(kerr == 0, "krb5_db_set_context failed.\n"); + + kerr = krb5_parse_name(krb5_ctx, NFS_PRINC_STRING, &nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + kerr = krb5_parse_name(krb5_ctx, NON_NFS_PRINC_STRING, &non_nfs_princ); + fail_unless(kerr == 0, "krb5_parse_name failed."); + + struct test_set { + char **authz_data; + char **global_authz_data; + krb5_principal princ; + bool exp_with_pac; + bool exp_with_pad; + const char *err_msg; + } test_set[] = { + {ad_none_only, NULL, NULL, false, false, "with only NONE in entry"}, + {ad_pac_only, NULL, NULL, true, false, "with only MS-PAC in entry"}, + {ad_pad_only, NULL, NULL, false, true, "with only PAD in entry"}, + {ad_illegal_only, NULL, NULL, false, false, "with only an invalid value in entry"}, + {ad_pac_and_pad, NULL, NULL, true, true, "with MS-PAC and PAD in entry"}, + {ad_pac_and_none, NULL, NULL, false, false, "with MS-PAC and NONE in entry"}, + {ad_none_and_pad, NULL, NULL, false, false, "with NONE and PAD in entry"}, + {NULL, ad_none_only, NULL, false, false, "with only NONE in global config"}, + {NULL, ad_pac_only, NULL, true, false, "with only MS-PAC in global config"}, + {NULL, ad_pad_only, NULL, false, true, "with only PAD in global config"}, + {NULL, ad_illegal_only, NULL, false, false, "with only an invalid value in global config"}, + {NULL, ad_pac_and_pad, NULL, true, true, "with MS-PAC and PAD in global config"}, + {NULL, ad_pac_and_none, NULL, false, false, "with MS-PAC and NONE in global config"}, + {NULL, ad_none_and_pad, NULL, false, false, "with NONE and PAD in global entry"}, + {NULL, ad_global_pac_nfs_none, NULL, true, false, "with NULL principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs_none, nfs_princ, false, false, "with nfs principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs_none, non_nfs_princ, true, false, "with non-nfs principal and PAC and nfs:NONE in global entry"}, + {NULL, ad_global_pac_nfs_pad, NULL, true, false, "with NULL principal and PAC and nfs:PAD in global entry"}, + {NULL, ad_global_pac_nfs_pad, nfs_princ, false, true, "with nfs principal and PAC and nfs:PAD in global entry"}, + {NULL, ad_global_pac_nfs_pad, non_nfs_princ, true, false, "with non-nfs principal and PAC and nfs:PAD in global entry"}, + {ad_none_only, ad_pac_only, NULL, false, false, "with NONE overriding PAC in global entry"}, + {ad_pad_only, ad_pac_only, NULL, false, true, "with PAC overriding PAC in global entry"}, + {ad_illegal_only, ad_pac_only, NULL, false, false, "with invalid value overriding PAC in global entry"}, + {ad_pac_and_pad, ad_pac_only, NULL, true, true, "with PAC and PAD overriding PAC in global entry"}, + {ad_none_and_pad, ad_pac_only, NULL, false, false, "with NONE and PAD overriding PAC in global entry"}, + {NULL, NULL, NULL, false, false, NULL} + }; + + for (c = 0; test_set[c].authz_data != NULL || + test_set[c].global_authz_data != NULL; c++) { + ied->authz_data = test_set[c].authz_data; + ipa_ctx->authz_data = test_set[c].global_authz_data; + entry->princ = test_set[c].princ; + get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); + fail_unless(with_pad == test_set[c].exp_with_pad, "with_pad not %s %s.", + test_set[c].exp_with_pad ? "true" : "false", + test_set[c].err_msg); + fail_unless(with_pac == test_set[c].exp_with_pac, "with_pac not %s %s.", + test_set[c].exp_with_pac ? "true" : "false", + test_set[c].err_msg); + } + + krb5_free_principal(krb5_ctx, nfs_princ); + krb5_free_principal(krb5_ctx, non_nfs_princ); + krb5_db_fini(krb5_ctx); + krb5_free_context(krb5_ctx); +} +END_TEST + +Suite * ipa_kdb_suite(void) +{ + Suite *s = suite_create("IPA kdb"); + + TCase *tc_helper = tcase_create("Helper functions"); + tcase_add_test(tc_helper, test_get_authz_data_types); + suite_add_tcase(s, tc_helper); + + return s; +} + +int main(void) +{ + int number_failed; + + Suite *s = ipa_kdb_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; +} -- 1.8.1.2 -------------- next part -------------- From 82cb66279454e6c625ca409235e6b8e631eeb973 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 27 Feb 2013 10:32:40 +0100 Subject: [PATCH 100/101] Mention PAC issue with NFS in service plugin doc --- ipalib/plugins/service.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index a3d436e61eb7b7ef2958188a83055b53f52e2562..6b6634458a5980ed263e929365034a7d90bc5bb3 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -66,6 +66,11 @@ EXAMPLES: Override a default list of supported PAC types for the service: ipa service-mod HTTP/web.example.com --pac-type=MS-PAC + A typical use case where overriding the PAC type is needed is NFS. + Currently the related code in the Linux kernel can only handle Kerberos + tickets up to a maximal size. Since the PAC data can become quite large it + is recommended to set --pac-type=NONE for NFS services. + Delete an IPA service: ipa service-del HTTP/web.example.com @@ -258,7 +263,8 @@ class service(LDAPObject): cli_name='pac_type', label=_('PAC type'), doc=_("Override default list of supported PAC types." - " Use 'NONE' to disable PAC support for this service"), + " Use 'NONE' to disable PAC support for this service," + " e.g. this might be necessary for NFS services."), values=(u'MS-PAC', u'PAD', u'NONE'), csv=True, ), -- 1.8.1.2 -------------- next part -------------- From 3b61193647a1ac1dce24832260edc31f638a368b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 4 Mar 2013 14:52:10 +0100 Subject: [PATCH 101/101] Allow 'nfs:NONE' in global configuration This patch adds 'nfs:NONE' as an allowed entry for the global authorization data type in the CLI and WebUI. This is an ad-hoc solution to make sure that the new default value for the NFS service is not removed by chance. This patch should be removed if a more generic solution is implemented to modify service:TYP style values of the authorization data type. --- API.txt | 2 +- install/ui/src/freeipa/serverconfig.js | 4 ++-- ipalib/plugins/config.py | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index a43fce596a6e01ba1fc709242ede0303994a255d..5ddda637175184d115396b1f394db1b45ae57de9 100644 --- a/API.txt +++ b/API.txt @@ -498,7 +498,7 @@ option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name=' option: Str('ipagroupobjectclasses', attribute=True, autofill=False, cli_name='groupobjectclasses', csv=True, multivalue=True, required=False) option: IA5Str('ipagroupsearchfields', attribute=True, autofill=False, cli_name='groupsearch', multivalue=False, required=False) option: IA5Str('ipahomesrootdir', attribute=True, autofill=False, cli_name='homedirectory', multivalue=False, required=False) -option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD')) +option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD', u'nfs:NONE')) option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False) option: Bool('ipamigrationenabled', attribute=True, autofill=False, cli_name='enable_migration', multivalue=False, required=False) option: Int('ipapwdexpadvnotify', attribute=True, autofill=False, cli_name='pwdexpnotify', minvalue=0, multivalue=False, required=False) diff --git a/install/ui/src/freeipa/serverconfig.js b/install/ui/src/freeipa/serverconfig.js index 347c46c1cb4daa94555c5a3272010d8a57e308de..1c6dd219bce5ba5ee010930b7e508c071680446f 100644 --- a/install/ui/src/freeipa/serverconfig.js +++ b/install/ui/src/freeipa/serverconfig.js @@ -102,7 +102,7 @@ IPA.serverconfig.entity = function(spec) { { name: 'ipakrbauthzdata', type: 'checkboxes', - options: IPA.create_options(['MS-PAC', 'PAD']) + options: IPA.create_options(['MS-PAC', 'PAD', 'nfs:NONE']) } ] } @@ -117,4 +117,4 @@ IPA.serverconfig.entity = function(spec) { IPA.register('config', IPA.serverconfig.entity); return {}; -}); \ No newline at end of file +}); diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py index db7fce7cb6ddea5e7364baf50eaa2e1a5b9f8021..33eb174ecc2c6af0463b475f3b87a734dd06f988 100644 --- a/ipalib/plugins/config.py +++ b/ipalib/plugins/config.py @@ -194,7 +194,7 @@ class config(LDAPObject): cli_name='pac_type', label=_('Default PAC types'), doc=_('Default types of PAC supported for services'), - values=(u'MS-PAC', u'PAD'), + values=(u'MS-PAC', u'PAD', u'nfs:NONE'), csv=True, ), ) -- 1.8.1.2 From pvoborni at redhat.com Thu Mar 7 18:20:50 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 Mar 2013 19:20:50 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <5138C136.9000504@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> <51387CE4.2040001@redhat.com> <513893EC.2040101@redhat.com> <5138C136.9000504@redhat.com> Message-ID: <5138DA82.1010601@redhat.com> On 03/07/2013 05:32 PM, Petr Vobornik wrote: > On 03/07/2013 02:19 PM, Ana Krivokapic wrote: >> On 03/07/2013 12:41 PM, Petr Vobornik wrote: >>> On 03/06/2013 08:26 PM, Ana Krivokapic wrote: >>>> On 03/06/2013 10:40 AM, Petr Vobornik wrote: >>>>> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>>>>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>>>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>>>>> Add support for Realm Domains to web UI. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>>>>> > > 8><----------------------- > >>> >>> Almost there, as discussed in person: >>> >>> 1. following strings should be add to and obtained from internal.py >>> plugin: >>> title: 'Check DNS', >>> message: 'Do you also want to perform DNS check?', >>> ok_label: 'Check DNS', >>> >>> >>> 2. the server plugin should report all dns resolution failures, not >>> just the first one. >> >> Fixed, updated patch is attached. >> > Works fine, but you forgot to update all related tests (s/domain/domains/): > >> ====================================================================== >> FAIL: test_realmdomains[8]: realmdomains_mod: Try to replace list of >> realm domains with a list with an invalid domain "doesnotexist.test" >> ---------------------------------------------------------------------- >> 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/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >> line 264, in >> func = lambda: self.check(nice, **test) >> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >> line 278, in check >> self.check_exception(nice, cmd, args, options, expected) >> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >> line 304, in check_exception >> assert_deepequal(expected.strerror, e.strerror) >> File "/home/pvoborni/dev/freeipa/tests/util.py", line 343, in >> assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> >> expected = u"invalid 'domain': no SOA or NS records found for >> domains: doesnotexist.test" >> got = u"invalid 'domain': no SOA or NS records found for domain >> doesnotexist.test" >> path = () >> >> ---------------------------------------------------------------------- > False alarm. It was an error on my side. ACK -- Petr Vobornik From rcritten at redhat.com Thu Mar 7 18:28:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 13:28:54 -0500 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <5138CE7A.1070809@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5138C7FF.2070207@redhat.com> <5138CE7A.1070809@redhat.com> Message-ID: <5138DC66.1050506@redhat.com> Petr Viktorin wrote: > On 03/07/2013 06:01 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 6.3.2013 16:29, Petr Viktorin wrote: >>>> Hello, >>>> These patches move ipaldap to ipapython, and make the client installer >>>> use it. Also password migration web-app is made to use ipaldap; they >>>> both called a shared a utility function that is converted to use >>>> ipaldap. >>>> >>>> This should fix https://fedorahosted.org/freeipa/ticket/3446 >>>> (freeipa-client-install KeyError in 'namingcontexts') and similar >>>> errors. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3487 >>>> >>> >>> Patch 191: >>> >>> The patch is missing the ipapython/ipaldap.py file. > > It's there, it's just copied from ipaserver/ipaldap.py with a small > change at the bottom. > > I'll respond to the other comments tomorrow. > >>> >>> I think it should go into ipalib instead of ipapython. It doesn't >>> make sense to keep ipapython and ipalib separate if they depend on each >>> other. We should either merge them or clean up the mess by removing >>> ipalib imports from ipapython. I'm not saying we should do it now, just >>> please don't add new modules to ipapython which import from ipalib. >>> >> >> There have been platforms in the past that we do not ship the framework >> on (e.g. RHEL 5). ipapython is supposed to be platform agnostic, though >> it clearly isn't, to allow a bridge for those systems that can't or >> won't have the framework. So I think removing the imports from ipapython >> is the way to go. >> > > Then we need to move errors and text to ipapython, those need to be > imported pretty much everywhere. Yup, that too is a bit of a violation, at least for errors as we really want to publish those as part of the framework. This is why I didn't raise a fuss when we starting doing minor mixing of things (and I really felt the pain when trying to do certain things in RHEL 5). The client is now using more and more from the framework (SSH uploads, for example). So maybe it is time to revisit how we package things. If we decide to go whole hog and merge ipapython and ipalib I think there'd be no going back. We'd have to carefully consider all the consequences. I tend to be rather conservative in this regard, but perhaps I'm just living in the past. rob From rcritten at redhat.com Thu Mar 7 19:27:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 14:27:49 -0500 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <51388513.2040700@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> Message-ID: <5138EA35.8040508@redhat.com> Petr Viktorin wrote: > On 03/06/2013 09:52 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: > [...] >>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>> Assignment Plugin,cn=plugins,cn=config is added before the entry itself. >>> I didn't test everything as I didn't get the access. >> >> It shouldn't make a difference. What isn't working? > > I get a CRITICAL message in the log: > > add aci: > (targetattr=dnaNextRange || dnaNextValue || > dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) > groupdn = "ldap:///cn=Modify DNA > Range,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config" > > 2013-03-07T11:01:48Z DEBUG stderr=ldap_initialize( > ldap://vm-081.idm.lab.eng.brq.redhat.com:389/??base ) > ldap_modify: No such object (32) > > 2013-03-07T11:01:48Z CRITICAL Failed to load replica-acis.ldif: Command > '/usr/bin/ldapmodify -v -f /tmp/tmpT55upM -H > ldap://vm-081.idm.lab.eng.brq.redhat.com:389 -x -D cn=Directory Manager > -y /tmp/tmplFeere' returned non-zero exit status 32 > Gotcha. I moved where the replica acis are loaded. > This particular ACI is added later by the updater. But, after failing > here the rest of the file is skipped, and the subsequent ACIs aren't > added in updates. Not being able to run CLEANALLRUV prevents cleanly > deleting a replica. > > [...] >>> [...] >>>> + try: >>>> + repl = replication.ReplicationManager(realm, hostname, >>>> dirman_passwd) >>>> + except Exception, e: >>>> + sys.exit("Connection failed: %s" % >>>> ipautil.convert_ldap_error(e)) >>> >>> ipaldap should convert LDAP errors to IPA ones, there's no need to call >>> convert_ldap_error. Same in other places. >> >> It does in some but it isn't consistent. I removed my calls though. >> >> $ ipa-replica-manage dnarange-show -p badpassword >> Connection failed: {'desc': 'Invalid credentials'} > > That's a bug. My patch 0194 should fix this, I'll check after it's > merged. Anyway it's not a show stopper now. > > [...] >>>> + failed = 0 >>>> + for ent in entries: >>> >>> >>> This loops more than necessary and is somewhat hard to follow. Consider >>> using for-else here: >>> >>> for ...: >>> ... >>> if okay: >>> break >>> else: >>> raise error >> >> I simplified things a bit but a for/else won't work here as we need to >> check all ranges all the time. It is perfectly fine to not fit into a >> range, as long as it fits into SOME range. > > Well, that's how for's (not if's) else clause works -- it's executed > after all the looping's done if you didn't `break` out. > http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops > > Maybe I'm just used to it and it's too esoteric to the average reader, > though. Thanks for the vote of confidence. Like I said, I wanted it to check all the ranges. A for/else quits on the break, which I guess is really probably ok assuming we trust that nothing else is going to stuff bad ranges in. I can go ahead and make the change. > > [...] >> Ok, I'll drop this since it doesn't affect things with the new LDAP >> backend. > > Please do, you left it in by mistake. Yeah, there it is sitting unsquashed in my tree :-( >> I also added one change related to the LDAP core changes. In the past if >> you did not have a ticket it would prompt for DM password. This was >> broken after the updates. I added an additional except in >> test_connection(). > > This should also be fixed soon in ipaldap. Thanks for putting up with > the changes. > So should I drop this in my patch then? I don't really like having to import ldap. rob From rcritten at redhat.com Thu Mar 7 20:15:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 15:15:18 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags Message-ID: <5138F556.8020504@redhat.com> Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. rob From rcritten at redhat.com Thu Mar 7 22:01:33 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 17:01:33 -0500 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5138B81A.4060700@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> <5138B1F4.4060002@redhat.com> <5138B81A.4060700@redhat.com> Message-ID: <51390E3D.6090305@redhat.com> Petr Viktorin wrote: > On 03/07/2013 04:27 PM, Tomas Babej wrote: >> On 03/07/2013 04:12 PM, Petr Viktorin wrote: >>> Thanks! I just have two more very minor nitpicks. >>> >>> On 03/06/2013 01:04 PM, Tomas Babej wrote: >>>> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>>>> Thanks! The mechanism works, but see below. >>>>> >>>>> This is a RFE so it needs a design document. >>>>> >>>> http://freeipa.org/page/V3/Client_install_using_keytab >>> >>> Please also add the link to the commit message. >>> >>> >>> I think you answered Petr?'s security questions adequately. >>> Petr, note that this is a client-side change; if the keytab is >>> compromised the attacker can do all this manually anyway. >>> >>>> diff --git a/ipa-client/ipa-install/ipa-client-install >>>> b/ipa-client/ipa-install/ipa-client-install >>>> index >>>> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >>>> >>>> 100755 >>>> --- a/ipa-client/ipa-install/ipa-client-install >>>> +++ b/ipa-client/ipa-install/ipa-client-install >>>> @@ -104,6 +104,8 @@ def parse_options(): >>> [...] >>>> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >>>> except ipaclient.ntpconf.NTPConfigurationError: >>>> pass >>>> >>>> - if options.unattended and (options.password is None and >>>> options.principal is None and options.prompt_password is False) and >>>> not options.on_master: >>>> - root_logger.error("One of password and principal are >>>> required.") >>>> + if options.unattended and ((options.password is None and >>>> + options.principal is None and >>>> + options.keytab is None and >>>> + options.prompt_password is False)\ >>>> + and not options.on_master): >>> >>> Please also remove the inner parentheses and the backslash. >>> >> Both fixed, updated patch attached. >> >> Tomas > > ACK, thanks! > This needs related man page updates before we can push it. Can you update the design to specifically include that the old certificate needs to be revoked, not just that a new certificate be issued (sort of implied, and it worked in my testing)? rob From rcritten at redhat.com Thu Mar 7 22:48:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 17:48:16 -0500 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges In-Reply-To: <5135DE06.2080408@redhat.com> References: <5135DE06.2080408@redhat.com> Message-ID: <51391930.7090108@redhat.com> Tomas Babej wrote: > Hi, > > Any of the following checks: > - overlap between primary RID range and secondary RID range > - overlap between secondary RID range and secondary RID range > > is performed now only if both of the ranges involved are local > domain ranges. > > https://fedorahosted.org/freeipa/ticket/3391 > > Tomas > So I assume in your reproduction steps the secondary range for both is 0 hence the overlap? rob From rcritten at redhat.com Thu Mar 7 23:14:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Mar 2013 18:14:50 -0500 Subject: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf In-Reply-To: <5135D2E6.1000501@redhat.com> References: <5135D2E6.1000501@redhat.com> Message-ID: <51391F6A.7000303@redhat.com> Martin Kosek wrote: > Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential > and tkey-domain and replace them with tkey-gssapi-keytab which avoids > unnecessary Kerberos checks on BIND startup and can cause issues when > KDC is not available. > > Both new and current IPA installations are updated. > > https://fedorahosted.org/freeipa/ticket/3429 > Still reviewing this but I noticed that after upgrading my 3.1.99 server pre-patch to with with-patch version the connections argument in named.conf got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 during the initial install too? rob From npmccallum at redhat.com Thu Mar 7 23:36:58 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 07 Mar 2013 18:36:58 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362593086.12650.8.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> Message-ID: <1362699418.9093.5.camel@localhost.localdomain> On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > > Patch is attached. > > > > There are currently a few security downsides to this patch: > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > > > This patch also adds some new dependencies, namely: > > 1. libverto (a dependency of krb5) > > 2. systemd > > 3. a krb5 patched for libk5radius support [1] > > > > In the interest of trying to meet the Fedora Features deadline, I am > > providing the patch in spite of the above issues. > > > > Nathaniel > > > > 1 - http://bit.ly/ZqtK79 > > Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > schema. This will need to be verified and finalized. Updated version of the patch attached. Requires libk5radius from here: https://github.com/npmccallum/krb5/commits/otp This new version fixes a bug which caused a hang in the case of no entry found during LDAP query. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-krb5-1.12-s-OTP-Over-RADIUS.patch Type: text/x-patch Size: 65774 bytes Desc: not available URL: From npmccallum at redhat.com Thu Mar 7 23:38:38 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 07 Mar 2013 18:38:38 -0500 Subject: [Freeipa-devel] Failed push to github Message-ID: <1362699518.9093.7.camel@localhost.localdomain> I tried to push my branch of FreeIPA to github and it failed with the following message. I don't know if anything can be done to fix it, but I figured I'd mention it. error: object 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db:invalid author/committer line - bad date fatal: Error in object error: pack-objects died of signal 13 error: failed to push some refs to 'git at github.com:npmccallum/freeipa.git' Nathaniel From pviktori at redhat.com Fri Mar 8 08:37:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 08 Mar 2013 09:37:17 +0100 Subject: [Freeipa-devel] Failed push to github In-Reply-To: <1362699518.9093.7.camel@localhost.localdomain> References: <1362699518.9093.7.camel@localhost.localdomain> Message-ID: <5139A33D.7050600@redhat.com> On 03/08/2013 12:38 AM, Nathaniel McCallum wrote: > I tried to push my branch of FreeIPA to github and it failed with the > following message. I don't know if anything can be done to fix it, but I > figured I'd mention it. > > error: object 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db:invalid > author/committer line - bad date > fatal: Error in object > error: pack-objects died of signal 13 > error: failed to push some refs to > 'git at github.com:npmccallum/freeipa.git' > > Nathaniel > Yes, we have some commits with invalid commit times. If you fork https://github.com/encukou/freeipa you should be fine. (I've asked Github staff to turn off the checks so I could push it initially.) -- Petr? From pspacek at redhat.com Fri Mar 8 08:49:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 08 Mar 2013 09:49:40 +0100 Subject: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf In-Reply-To: <51391F6A.7000303@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> Message-ID: <5139A624.50004@redhat.com> On 8.3.2013 00:14, Rob Crittenden wrote: > Martin Kosek wrote: >> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >> unnecessary Kerberos checks on BIND startup and can cause issues when >> KDC is not available. >> >> Both new and current IPA installations are updated. >> >> https://fedorahosted.org/freeipa/ticket/3429 >> > > Still reviewing this but I noticed that after upgrading my 3.1.99 server > pre-patch to with with-patch version the connections argument in named.conf > got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 > during the initial install too? For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections should not harm. Higher value should allow higher level of parallelism, it is one of tuning parameters. Value 4 was necessary to prevent deadlocks in some previous versions of bind-dyndb-ldap. -- Petr^2 Spacek From sbose at redhat.com Fri Mar 8 09:27:46 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 8 Mar 2013 10:27:46 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5138F556.8020504@redhat.com> References: <5138F556.8020504@redhat.com> Message-ID: <20130308092746.GJ16010@localhost.localdomain> On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: > Based on a comment from Sumit in ticket > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline > of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > There is a bit of hand waving going on around how the flags are > actually set inside the KDB plugin since I'm not at all familiar > with that code but I don't expect it to be too big a deal. > > I'm not necessarily volunteering to do this work, just trying to > keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well - it is only a minor increase the development effort - it is only a minor increase in the QE effort. Instead of doing * set/unset flag in CLI/WebUI * check with kdamin.local if the flag is in the expected state for a single attribute it has to be done for a list of attributes (maybe the steps can be added to a new 'How to test' section on the design page) - it will help to find a good solution how to handle the flags in the CLI/WebUI I think the last point is important because the flags are needed for all Kerberos principals, i.e. users, hosts and services. Instead of adding a list of new options/check boxes to each of the CLI commands/WebUI pages it might be more helpful to handle the flags separately. The CLI can get a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be shown and modified in a separate tab, I hope this will allow to use a common template to users, hosts and services. These are only rough ideas and suggestions, my point is that if we not only add a single flag but about 15 it might be easier to find a good and usable interface to modify them. bye, Sumit > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Fri Mar 8 09:31:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 08 Mar 2013 10:31:58 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5138F556.8020504@redhat.com> References: <5138F556.8020504@redhat.com> Message-ID: <5139B00E.1080000@redhat.com> Hi, On 7.3.2013 21:15, Rob Crittenden wrote: > Based on a comment from Sumit in ticket > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? > > There is a bit of hand waving going on around how the flags are actually > set inside the KDB plugin since I'm not at all familiar with that code > but I don't expect it to be too big a deal. > > I'm not necessarily volunteering to do this work, just trying to keep > the ball moving forward. > > rob > Honza -- Jan Cholasta From mkosek at redhat.com Fri Mar 8 09:50:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Mar 2013 10:50:46 +0100 Subject: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type In-Reply-To: <20130307173227.GI16010@localhost.localdomain> References: <513059DF.2010403@redhat.com> <20130301082053.GO3633@localhost.localdomain> <5130700B.2030608@redhat.com> <1362146314.2962.130.camel@willson.li.ssimo.org> <20130304152220.GW3633@localhost.localdomain> <513619C6.8090402@redhat.com> <20130306094108.GA16010@localhost.localdomain> <5137497E.4010204@redhat.com> <1362577907.2822.2.camel@willson.li.ssimo.org> <20130306163343.GC16010@localhost.localdomain> <20130307173227.GI16010@localhost.localdomain> Message-ID: <5139B476.6040907@redhat.com> On 03/07/2013 06:32 PM, Sumit Bose wrote: > On Wed, Mar 06, 2013 at 05:33:43PM +0100, Sumit Bose wrote: >> On Wed, Mar 06, 2013 at 08:51:47AM -0500, Simo Sorce wrote: >>> On Wed, 2013-03-06 at 14:49 +0100, Martin Kosek wrote: >>>> On 03/06/2013 10:41 AM, Sumit Bose wrote: >>>>> On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote: >>>>>> On 03/04/2013 04:22 PM, Sumit Bose wrote: >>>>>>> On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote: >>>>>>>> On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote: >>>>>>>>> On 03/01/2013 09:20 AM, Sumit Bose wrote: >>>>>>>>>> On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote: >>>>>>>>>>> On 02/28/2013 03:28 PM, Simo Sorce wrote: >>>>>>>>>>>> On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote: >>>>>>>>>>>>> On 02/28/2013 12:42 PM, Sumit Bose wrote: >>>>>>>>>>>>>> On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote: >>>>>>>>>>>>>>> On 02/27/2013 06:48 PM, Sumit Bose wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Sumit, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This looks like a good idea and would prevent the magic default PAC type, yes. >>>>>>>>>>>>>>> Though I would not add this service-specific setting to global IPA config object. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would rather like to see that in the service tree, for example as a >>>>>>>>>>>>>>> configuration option of the service root which could be controlled with >>>>>>>>>>>>>>> serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE >>>>>>>>>>>>>>> # ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD >>>>>>>>>>>>>>> # ipa serviceconfig-show >>>>>>>>>>>>>>> Default PAC Map: nfs:NONE, cifs:PAD >>>>>>>>>>>>>> >>>>>>>>>>>>>> Are you thinking of having this in addition to the for-all-services >>>>>>>>>>>>>> default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't >>>>>>>>>>>>>> like the first case because then three different objects needs to be >>>>>>>>>>>>>> consulted to find out which is the right type. This wouldn't be an issue >>>>>>>>>>>>>> for the plugin, but I think it is hard for the user/admin to follow. >>>>>>>>>>>>> >>>>>>>>>>>>> Hm, you are right. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the current defaults shall be dropped I think this is a major change >>>>>>>>>>>>>> because it will require changes in the current CLI and WebUI which will >>>>>>>>>>>>>> be visible to the users. I'm not against this change, I'm just wondering >>>>>>>>>>>>>> if it is worth the effort for the next release? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe an argument to keep this is in global default is that the settings >>>>>>>>>>>>>> are used for the host/*.* services as well which are in a different >>>>>>>>>>>>>> sub-tree of the cn=accounts container. Additionally in future we might >>>>>>>>>>>>>> want apply those setting to the user TGTs as well? >>>>>>>>>>>>> >>>>>>>>>>>>> Yeah, that was actually my point. That we are mixing service-specific PAC >>>>>>>>>>>>> "rules" to the global setting. Which may be shared with host/*.* principals and >>>>>>>>>>>>> user principals. This automatic PAC rules may require some designing so that is >>>>>>>>>>>>> is generally usable. >>>>>>>>>>>> >>>>>>>>>>>> I think putting everything in the general config is more understandable >>>>>>>>>>>> and discoverable. These per-service defaults are basically exceptions to >>>>>>>>>>>> the general rule so it make sense to keep everything together. >>>>>>>>>>>> >>>>>>>>>>>> Simo. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok, if these are really just an exceptions to the general rule (and there will >>>>>>>>>>> not be too many of them), I think we can leave it in config entry. But if we >>>>>>>>>>> expect to have exceptions for other types of entries (hosts, users), I think we >>>>>>>>>>> should rather use something like "service:nfs:NONE" do distinguish this exception. >>>>>>>>>>> >>>>>>>>>>> Question is, do we want to implement the interface and processing for that in >>>>>>>>>>> current Sumit's patches or do we use that is they are? >>>>>>>>>> >>>>>>>>>> I would like to update the patches so that they can handle the >>>>>>>>>> service:TYPE style entry and replace the current update code with just >>>>>>>>>> adding nfs:NONE to the global options. I will update the design page >>>>>>>>>> accordingly, too. >>>>>>>>> >>>>>>>>> Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd >>>>>>>>> be great. >>>>>>>> >>>>>>>> If we need to distinguish between service principals and user principals >>>>>>>> I would prefer rather use a special keyword for upns >>>>>>>> >>>>>>>> service: is redundant and I do not want here to be able to say >>>>>>>> upn:martin:NONE because per principal options are available on the >>>>>>>> principal object. >>>>>>>> >>>>>>>> I actually really do not see the need for changing the default just for >>>>>>>> user principals. If we are worried that one day we might want to really >>>>>>>> have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we >>>>>>>> might add upn:NONE and the lack of / will tell us this is not a service >>>>>>>> named upn/foo.bar.baz but rather it means user principal names. >>>>>>>> >>>>>>>> However I do not see us ever really needing upn:NONE >>>>>>>> >>>>>>>>>> I would prefer if the enhancements needed for the CLI and WebUI can be >>>>>>>>>> covered by other/new tickets, but I'm happy to add the needed >>>>>>>>>> information to the design page too. >>>>>>>>>> >>>>>>>>>> bye, >>>>>>>>>> Sumit >>>>>>>>> >>>>>>>>> I am OK with adding the interface for this special exception later. In that >>>>>>>>> case, a ticket + note in the design as you mentioned would be enough. >>>>>>>> >>>>>>>> Ack. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Please find attached a new version of the patches. 0095 i(updating) is >>>>>>> renamed and much simpler now. I opened >>>>>>> https://fedorahosted.org/freeipa/ticket/3484 to added the needed change >>>>>>> for 'service:TYPE' to CLI and WebUI. For the time being I've added >>>>>>> patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it >>>>>>> is not deleted accidentally when e.g. using the WebUI. If you do not >>>>>>> like it it can simply be dropped, everything is working fine without it. >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>> >>>>>> Patch 0098: >>>>>> >>>>>> If this part does not match (and it will not for all non-nfs service principals): >>>>>> >>>>>> + if (service_type->length == (sep - authz_data_list[c]) && >>>>>> + strncmp(authz_data_list[c], service_type->data, >>>>>> + service_type->length) == 0) { >>>>>> + authz_data_type = sep + 1; >>>>>> + } >>>>>> >>>>>> krb5kdc.log will contain an error: >>>>>> >>>>>> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](Error): Ignoring unsupported >>>>>> authorization data type [nfs:NONE]. >>>>>> Mar 05 10:48:50 ipa.linux.ad.test krb5kdc[26703](info): TGS_REQ (4 etypes {18 >>>>>> 17 16 23}) 10.16.78.33: ISSUE: authtime 1362482261, etypes {rep=18 tkt=18 >>>>>> ses=18}, HTTP/ipa.linux.ad.test at LINUX.AD.TEST for >>>>>> ldap/ipa.linux.ad.test at LINUX.AD.TEST >>>>>> >>>>>> I think we should just "continue" in this case. >>>>> >>>>> good catch, fixed >>>> >>>> Ok, thanks. >>>> >>>>> >>>>>> >>>>>> Otherwise, this looks and works fine. >>>>> >>>>> Thank you for the review, new version attached. >>>>> >>>>> I have an additional question about processing the service specific >>>>> defaults. Using 'service:NONE' is unambiguous because NONE trumps all. >>>>> But what do we expect if e.g. the defaults are MS-PAC and ldap:PAD for a >>>>> LDAP service ticket. Shall it contain PAC and PAD or only a PAD? I think >>>>> the first one where all defaults which apply to a service are added up >>>>> is more clear, and this is also the way the current code works. But I >>>>> wouldn't mind to change the logic if you think it makes more sense the >>>>> other way round, i.e. if there is a service specific default matching >>>>> the requested service only the service specific default are accounted. >>>> >>>> Hmm, that's a good question. I understand service:PACTYPE as an exclusion to >>>> the general setting, so for me it would make sense to override the global >>>> config - i.e. tje second case. >>>> >>>> Thus, if global config is MS-PAC, ldap:PAD, I think that ldap should have just >>>> PAD. If one also want MS-PAC, it should be set like "MS-PAC, ldap:PAD, >>>> ldap:MS-PAC". Otherwise you would not be able to configure that you want MS-PAC >>>> for all services and _only_ PAD for ldap... >>>> >>>> Does it make sense? We should also make sure that we update the RFE page to >>>> whatever we decide to do. >>> >>> +1 to Martin's choice. >> >> Martin, Simo, thank you for the feedback. I will send an new version of >> the patches, add a section in the design page explaining the details and >> add some tests for this logic. >> >> bye, >> Sumit > > Design pages is updated and new patches attached. > > bye, > Sumit > Thanks, this works great. I just updated the commit messages and added a link to the ticket. ACK. Pushed to master. Martin From sbose at redhat.com Fri Mar 8 09:55:06 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 8 Mar 2013 10:55:06 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5139B00E.1080000@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> Message-ID: <20130308095506.GK16010@localhost.localdomain> On Fri, Mar 08, 2013 at 10:31:58AM +0100, Jan Cholasta wrote: > Hi, > > On 7.3.2013 21:15, Rob Crittenden wrote: > >Based on a comment from Sumit in ticket > >https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > >how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > Can we have one multi-valued attribute which contains names of flags > to set instead of one attribute per flag? It might make adding new > flags easier. Yes, as said I think it makes sense to just add support for all flags to find a good/scalable design. This way it would be a bit harder for external applications which access the LDAP server directly to see which flags are supported, but it will keep the schema much cleaner. > > Would it make sense to add a global configuration option to turn > flags on or off for all services of a given type? In general yes, I'm just wondering if this should be handled here or tracked by a separate ticket/design because different LDAP objects will be used to manage the defaults. Additionally we might want to think a bit longer about how global defaults and individual flags will be merged. I think it is not as easy as with the authorization date (PAC type) where we said that individual setting replaces the defaults because iirc the REQUIRES_PRE_AUTH is currently always set. Please note also that tis is not only about services but hosts and users as well. bye, Sumit > > > > >There is a bit of hand waving going on around how the flags are actually > >set inside the KDB plugin since I'm not at all familiar with that code > >but I don't expect it to be too big a deal. > > > >I'm not necessarily volunteering to do this work, just trying to keep > >the ball moving forward. > > > >rob > > > > Honza > > -- > Jan Cholasta > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Fri Mar 8 11:10:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Mar 2013 12:10:00 +0100 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges In-Reply-To: <5135DE06.2080408@redhat.com> References: <5135DE06.2080408@redhat.com> Message-ID: <5139C708.6020601@redhat.com> On 03/05/2013 12:59 PM, Tomas Babej wrote: > Hi, > > Any of the following checks: > - overlap between primary RID range and secondary RID range > - overlap between secondary RID range and secondary RID range > > is performed now only if both of the ranges involved are local > domain ranges. > > https://fedorahosted.org/freeipa/ticket/3391 > I think the patch is functionally OK (I tested it), I would just change the flow of the following: @@ -194,19 +198,22 @@ static int ranges_overlap(struct range_info *r1, struct range_info *r2) r1->id_range_size, r2->id_range_size)) return 2; - /* check if secondary rid range overlaps with existing secondary rid range */ + /** + * The following 3 checks are relevant only if both ranges are local. + * Check if secondary rid range overlaps with existing secondary rid + * range. **/ if (intervals_overlap(r1->secondary_base_rid, r2->secondary_base_rid, - r1->id_range_size, r2->id_range_size)) + r1->id_range_size, r2->id_range_size) && local_ranges) return 3; ... TO something like ... /** * The following checks are relevant only if both ranges are local. * Check if secondary rid range overlaps with existing secondary rid * range. **/ if (local_ranges) { ... do the checks } ... Doing it your way, intervals_overlap() function is called 3 times when not needed + it is not so obvious that these checks are only done with "local_ranges" only. Martin From mkosek at redhat.com Fri Mar 8 12:10:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Mar 2013 13:10:43 +0100 Subject: [Freeipa-devel] [PATCH] 383 Use new 389-ds-base cleartext password API Message-ID: <5139D543.3060101@redhat.com> The way how unhashed password is stored in the entry was changed in 389-ds-base-1.3.0, it is now stored in an entry extension rather than in a magic attribute unhashed#user#password. New API using an entry extension was introduced. ipa-pwd-extop should take advantage of the new API as the old one will be removed in 389-ds-base-1.3.1. https://fedorahosted.org/freeipa/ticket/3439 --- This patch is based on Noriko's candidate patch in 389-ds-base ticket. I tested various password scenarios including migration of users with cleartext/hashed passwords, everything worked OK. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-383-use-new-389-ds-base-cleartext-password-api.patch Type: text/x-patch Size: 2791 bytes Desc: not available URL: From sbose at redhat.com Fri Mar 8 12:12:50 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 8 Mar 2013 13:12:50 +0100 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362699418.9093.5.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362699418.9093.5.camel@localhost.localdomain> Message-ID: <20130308121250.GL16010@localhost.localdomain> On Thu, Mar 07, 2013 at 06:36:58PM -0500, Nathaniel McCallum wrote: > On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > > On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > > > Patch is attached. > > > > > > There are currently a few security downsides to this patch: > > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > > > > > This patch also adds some new dependencies, namely: > > > 1. libverto (a dependency of krb5) > > > 2. systemd > > > 3. a krb5 patched for libk5radius support [1] > > > > > > In the interest of trying to meet the Fedora Features deadline, I am > > > providing the patch in spite of the above issues. > > > > > > Nathaniel > > > > > > 1 - http://bit.ly/ZqtK79 > > > > Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > > schema. This will need to be verified and finalized. > > Updated version of the patch attached. Requires libk5radius from here: > https://github.com/npmccallum/krb5/commits/otp Do you already have krb5 packages with you patches available, or can you make them available e.g. via koji scratch builds? I think this would help a lot testing and reviewing your patches. Btw, please do not fail during configure ifk5radius.h or libk5radius are not available but only check if they are present and build ipa-otpd condionally. bye, Sumit > > This new version fixes a bug which caused a hang in the case of no entry > found during LDAP query. > > Nathaniel > From pviktori at redhat.com Fri Mar 8 12:24:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 08 Mar 2013 13:24:00 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <5138EA35.8040508@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> Message-ID: <5139D860.5080507@redhat.com> On 03/07/2013 08:27 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >> [...] >>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>> itself. >>>> I didn't test everything as I didn't get the access. >>> >>> It shouldn't make a difference. What isn't working? >> >> I get a CRITICAL message in the log: >> >> add aci: >> (targetattr=dnaNextRange || dnaNextValue || >> dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) >> groupdn = "ldap:///cn=Modify DNA >> Range,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) >> >> >> modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment >> Plugin,cn=plugins,cn=config" >> >> 2013-03-07T11:01:48Z DEBUG stderr=ldap_initialize( >> ldap://vm-081.idm.lab.eng.brq.redhat.com:389/??base ) >> ldap_modify: No such object (32) >> >> 2013-03-07T11:01:48Z CRITICAL Failed to load replica-acis.ldif: Command >> '/usr/bin/ldapmodify -v -f /tmp/tmpT55upM -H >> ldap://vm-081.idm.lab.eng.brq.redhat.com:389 -x -D cn=Directory Manager >> -y /tmp/tmplFeere' returned non-zero exit status 32 >> > > Gotcha. I moved where the replica acis are loaded. Please attach the patch :) [...] >>>>> + failed = 0 >>>>> + for ent in entries: >>>> >>>> >>>> This loops more than necessary and is somewhat hard to follow. Consider >>>> using for-else here: >>>> >>>> for ...: >>>> ... >>>> if okay: >>>> break >>>> else: >>>> raise error >>> >>> I simplified things a bit but a for/else won't work here as we need to >>> check all ranges all the time. It is perfectly fine to not fit into a >>> range, as long as it fits into SOME range. >> >> Well, that's how for's (not if's) else clause works -- it's executed >> after all the looping's done if you didn't `break` out. >> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops >> >> >> Maybe I'm just used to it and it's too esoteric to the average reader, >> though. > > Thanks for the vote of confidence. Like I said, I wanted it to check all > the ranges. A for/else quits on the break, which I guess is really > probably ok assuming we trust that nothing else is going to stuff bad > ranges in. I can go ahead and make the change. Your code also breaks out as soon as a good range is found. Anyway this is a small nitpick; the loop works fine as it is. >> [...] >>> Ok, I'll drop this since it doesn't affect things with the new LDAP >>> backend. >> >> Please do, you left it in by mistake. > > Yeah, there it is sitting unsquashed in my tree :-( > >>> I also added one change related to the LDAP core changes. In the past if >>> you did not have a ticket it would prompt for DM password. This was >>> broken after the updates. I added an additional except in >>> test_connection(). >> >> This should also be fixed soon in ipaldap. Thanks for putting up with >> the changes. >> > > So should I drop this in my patch then? I don't really like having to > import ldap. You can if you're fine with waiting until my patches are pushed. Otherwise it's covered by https://fedorahosted.org/freeipa/ticket/3499 -- Petr? From pviktori at redhat.com Fri Mar 8 13:13:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 08 Mar 2013 14:13:35 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <5138CCAF.7090202@redhat.com> References: <51388B54.1090405@redhat.com> <51389BD3.4000101@redhat.com> <5138B33C.7020409@redhat.com> <5138C762.4090405@redhat.com> <5138CCAF.7090202@redhat.com> Message-ID: <5139E3FF.9080100@redhat.com> On 03/07/2013 06:21 PM, Jan Cholasta wrote: > On 7.3.2013 17:59, Petr Viktorin wrote: >> On 03/07/2013 04:33 PM, Jan Cholasta wrote: >>> On 7.3.2013 14:53, Petr Viktorin wrote: >>>> On 03/07/2013 01:43 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> these patches add flags to LDAPClient and IPAdmin constructors which >>>>> can >>>>> be used to disable schema retrieval and decoding of attributes. This >>>>> should make interacting with AD easier (see >>>>> ). >>>>> >>>>> >>>>> >>>>> >>>>> Honza >> [...] >>> >>> Updated patches attached. >>> >>> Honza >>> >> >> In LDAPEntry.__setitem__, schema.get_obj is used without checking if the >> schema is None. >> > > I knew I forgot something! Thanks. Fixed. > > Updated patches attached. > > Honza > ACK -- Petr? From pviktori at redhat.com Fri Mar 8 13:14:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 08 Mar 2013 14:14:02 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <5138C36E.2070406@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> Message-ID: <5139E41A.7020203@redhat.com> On 03/07/2013 05:42 PM, Jan Cholasta wrote: > On 6.3.2013 16:29, Petr Viktorin wrote: >> Hello, >> These patches move ipaldap to ipapython, and make the client installer >> use it. Also password migration web-app is made to use ipaldap; they >> both called a shared a utility function that is converted to use ipaldap. >> >> This should fix https://fedorahosted.org/freeipa/ticket/3446 >> (freeipa-client-install KeyError in 'namingcontexts') and similar errors. >> >> https://fedorahosted.org/freeipa/ticket/3487 >> > > Patch 191: > > The patch is missing the ipapython/ipaldap.py file. > > I think it should go into ipalib instead of ipapython. It doesn't > make sense to keep ipapython and ipalib separate if they depend on each > other. We should either merge them or clean up the mess by removing > ipalib imports from ipapython. I'm not saying we should do it now, just > please don't add new modules to ipapython which import from ipalib. This is a bigger problem. Conceptually ipaldap should be in ipapython, it just needs the problematic errors and text modules. I think we should move those rather than ipaldap. > Also I am not very fond of the "ipa" prefix in "ipaldap". The module > lives in the namespace of our own package, so there's no need for it to > have such a prefix, is there? It's nice to have a unique name for talking about it. Since "ldap" is already a package we use, having another "ldap" would be confusing, even if it is properly namespaced. > Patch 193: > > + scope=conn.SCOPE_BASE, > + filter='objectclass=pkiCA', > + attrs_list=[ca_cert_attr], > > Can we use a proper filter here please? > > + :param conn: Bound LDAPConnection that will be used for searching Fixed, thanks > LDAPClient > > Patch 194: > > - ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, True) > > and > > - lh.set_option(ldap.OPT_X_TLS_DEMAND, True) > > Is removing these options safe? I re-added them. I also removed the forgotten debugging `raise`s Martin found. Adding patch 0196, which disables downloading the schema for discovery. Updated patches attached. They now depend on Honza's patches 116-119 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0191.2-Move-ipaldap-to-ipapython.patch Type: text/x-patch Size: 71924 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0192.2-Remove-ipaserver-ipaldap.py.patch Type: text/x-patch Size: 12182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0193.2-Use-IPAdmin-rather-than-raw-python-ldap-in-ipa-clien.patch Type: text/x-patch Size: 6690 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0194.2-Use-IPAdmin-rather-than-raw-python-ldap-in-migration.patch Type: text/x-patch Size: 18320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0195.2-Remove-unneeded-python-ldap-imports.patch Type: text/x-patch Size: 11302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0196.2-Don-t-download-the-schema-in-ipadiscovery.patch Type: text/x-patch Size: 1257 bytes Desc: not available URL: From abokovoy at redhat.com Fri Mar 8 13:16:26 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 Mar 2013 15:16:26 +0200 Subject: [Freeipa-devel] [RFE] Multiple trust servers per realm Message-ID: <20130308131625.GA18359@redhat.com> Hi, http://www.freeipa.org/page/V3/MultipleTrustServers covers RFE to have multiple domain controllers exposed to trusted domains. Attached patch also implements needed changes for ipa-adtrust-install part. Global trust configuration options are already implemented and available in git master, while Web UI support for them needs to be added. The patch attached actually fixes our current (rather wrong) way of exposing all LDAP- and Kerberos-related SRV records to default site configuration and _msdcs SRV namespace. This was wrong because it assumed that all servers mentioned in SRV records could be domain controllers, that is, they are usable to contact over SMB protocol. The latter isn't true until we ran ipa-adtrust-install on them. The patch only exposes those servers which manage cifs/fqdn at REALM services and only if those services are also members of cn=adtrust agents container. This is fairly strict filter and it allows also to have other types of SMB servers as part of the realm. Below is a copy of the RFE: ================================================================== __NOTOC__ = Overview = Ticket [https://fedorahosted.org/freeipa/ticket/2189 #2189]; Each FreeIPA server in the realm has potential to serve as domain controller in the cross-forest realm trust. This page outlines design for implementing multiple servers support in FreeIPA. = Use Cases = Once ipa-adtrust-install ran on the FreeIPA server, the server can handle requests from trusted domains by means of Samba project's smbd and winbindd daemons. Hosts in FreeIPA realm may be enrolled against specific FreeIPA replica server. User from trusted domain can access these hosts and their identities will be resolved against the replica. However, if replica server does not have trust support configured, these identities will not be processed since running winbindd process is required to contact the trusted domain's domain controllers and Global Catalog servers. Domain controllers are advertised to clients via SRV records in DNS. Since replica servers may be arranged in a specific topology, adding new domain controller would need to respect the topology design. It means priority/weight of the domain controller compared to other domain controllers should be adjustable. Prime use case for this is branch office deployments. = Design= * Each domain controller uses separate identity and service key to talk to FreeIPA LDAP server. The identity is tied to the server hostname. * Service principal is cifs/hostname at REALM, identified in LDAP as krbprincipalname=cifs/hostname at REALM. * All identities are members of cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX. Thus, all replica servers can see what other servers are providing domain controller service. * Replica server only becomes domain controller when ipa-adtrust-install utility was executed on it. It means all DC setup is delivered via the ipa-adtrust-install. * ipa-adtrust-install should be able to detect other DCs by looking at existing identities as members of the cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX tree and modify list of SRV records under _msdcs and default site configuration if DNS is controlled by FreeIPA. * Domain Controller priority/weight can be modified at run time since it only affects SRV records in the DNS (if FreeIPA controls the DNS). Normal ipa dnsrecord-mod commands should be used for this purpose, operating on SRV records for _msdcs and default site configuration. * There are trust properties that are global for the realm. Some of them are modifiable, some not. Thus, ipa trustconfig-show and ipa trustconfig-mod should reflect both global and local settings (realm-wise and DC-wise). * Following properties of the trust are global for the realm: ** NetBIOS domain name (read-only, affects existing trusts) ** Domain name (read-only, affects existing trusts) ** Domain GUID (read-only, informational) ** Additional domain suffixes exposed to the trusted party, handled as black list against global list of additional domains associated with our or transitive realm, read/write ** Fallback primary group (read-write) * Following properties of the trust are per Domain Controller: ** priority of the DC and GC services (read-write, DNS SRV record) Details on ipa trustconfig commands design are available at http://www.freeipa.org/page/V3/Trust_config_command Details on additional domain suffixes handling are available at http://www.freeipa.org/page/V3/Domain_suffixes = Implementation = Implementation-wise there are three parts: * ipa-adtrust-install: ** Gather list of CIFS services that are also members of cn=adtrust agents and add SRV records for them to _msdcs in ipaserver/install/adtrustinstance.py:ADTrustInstance::__add_dns_service_records(). ** Once Global Catalog Server implementation will be ready, configure its use as one of ADTrustInstance setup steps. * IPA framework: ** Add display and modification of trust properties as ipa trustconfig-* commands, including listing DC and GC servers. ** NOTE: there is no need to modify trust creation procedure since it appears that AD DC assumes LSA CreateTrustedDomainEx2 call comes from the DC (in Windows the UI to establish trust is only on DC) and therefore does not do DNS discovery during validation step. Since smbd running on the same host that 'ipa trust-add' runs on will contact the same host's LDAP server, there is no issue in replication at this stage. * IPA Web UI ** Add support for ipa trustconfig-* to Web UI. = Major configuration options and enablement = No additional options to ipa-adtrust-install = Replication = All data is already in a replicated namespace. = Updates and Upgrades = No changes to schema, no need to run anything additional on updates or upgrades = Dependencies = No additional dependencies beyond AD trusts support = External Impact = Once ipa-adtrust-install install ran on replica, the replica will be advertised via _msdcs SRV namespace as a domain controller. ================================================================== -- / Alexander Bokovoy -------------- next part -------------- >From 8f258dd0720fc0ca451200c6cd4afa301ec5d593 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 6 Mar 2013 10:12:40 +0200 Subject: [PATCH 1/2] Enhance ipa-adtrust-install for domains with multiple IPA server As described on http://www.freeipa.org/page/V3/MultipleTrustServers, notice if FreeIPA server is a replica and adtrust agents contains members corresponding to the cifs/ services from replication partners. Only these servers will be advertised as SMB domain controllers https://fedorahosted.org/freeipa/ticket/2189 --- ipaserver/install/adtrustinstance.py | 44 +++++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 794b788..a47c80b 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -477,6 +477,9 @@ class ADTRUSTInstance(service.Service): except ipautil.CalledProcessError, e: root_logger.critical("Failed to add key for %s" % self.cifs_principal) + def srv_rec(self, host, port, prio): + return "%(prio)d 100 %(port)d %(host)s" % dict(host=host,prio=prio,port=port) + def __add_dns_service_records(self): """ Add DNS service records for Windows if DNS is enabled and the DNS zone @@ -486,11 +489,12 @@ class ADTRUSTInstance(service.Service): zone = self.domain_name host = self.fqdn.split(".")[0] + priority = 0 ipa_srv_rec = ( - ("_ldap._tcp", ["0 100 389 %s" % host]), - ("_kerberos._tcp", ["0 100 88 %s" % host]), - ("_kerberos._udp", ["0 100 88 %s" % host]) + ("_ldap._tcp", [self.srv_rec(host, 389, priority)], 389), + ("_kerberos._tcp", [self.srv_rec(host, 88, priority)], 88), + ("_kerberos._udp", [self.srv_rec(host, 88, priority)], 88), ) win_srv_suffix = (".Default-First-Site-Name._sites.dc._msdcs", ".dc._msdcs") @@ -518,10 +522,12 @@ class ADTRUSTInstance(service.Service): self.print_msg(" - %s%s" % (srv, suff)) return - for (srv, rdata) in ipa_srv_rec: - ipa_rdata = get_rr(zone, srv, "SRV") - if not ipa_rdata: - ipa_rdata = rdata + for (srv, rdata, port) in ipa_srv_rec: + cifs_rdata = list() + for fqdn in self.cifs_hosts: + cifs_srv = self.srv_rec(fqdn, port, priority) + cifs_rdata.append(cifs_srv) + cifs_rdata.extend(rdata) for suff in win_srv_suffix: win_srv = srv+suff @@ -529,7 +535,7 @@ class ADTRUSTInstance(service.Service): if win_rdata: for rec in win_rdata: del_rr(zone, win_srv, "SRV", rec) - for rec in ipa_rdata: + for rec in cifs_rdata: add_rr(zone, win_srv, "SRV", rec) def __configure_selinux_for_smbd(self): @@ -618,7 +624,27 @@ class ADTRUSTInstance(service.Service): self.print_msg("'dns_lookup_kdc' already set to 'true', " "nothing to do.") + def __check_replica(self): + try: + cifs_services = DN(api.env.container_service, self.suffix) + # Search for cifs services which also belong to adtrust agents, these are our DCs + res = self.admin_conn.get_entries(cifs_services, + ldap.SCOPE_ONELEVEL, + "(&(krbprincipalname=cifs/*@%s)(memberof=%s))" % (self.realm, str(self.smb_dn))) + if len(res) > 1: + # there are other CIFS services defined, we are not alone + for entry in res: + managedBy = entry.single_value('managedBy', None) + if managedBy: + fqdn = DN(managedBy)['fqdn'] + if fqdn != unicode(self.fqdn): + # this is CIFS service of a different host in our + # REALM, we need to remember it to announce via + # SRV records for _msdcs + self.cifs_hosts.append(fqdn.split(".")[0]) + except Exception, e: + root_logger.critical("Checking replicas for cifs principals failed with error '%s'" % e) def __start(self): try: @@ -698,6 +724,7 @@ class ADTRUSTInstance(service.Service): api.env.container_service, self.suffix) self.selinux_booleans = ["samba_portmapper"] + self.cifs_hosts = list() self.__setup_sub_dict() @@ -755,6 +782,7 @@ class ADTRUSTInstance(service.Service): self.step("creating samba config registry", self.__write_smb_registry) self.step("writing samba config file", self.__write_smb_conf) self.step("adding cifs Kerberos principal", self.__setup_principal) + self.step("check for cifs services defined on other replicas", self.__check_replica) self.step("adding cifs principal to S4U2Proxy targets", self.__add_s4u2proxy_target) self.step("adding admin(group) SIDs", self.__add_admin_sids) self.step("adding RID bases", self.__add_rid_bases) -- 1.8.1.4 From simo at redhat.com Fri Mar 8 13:41:26 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Mar 2013 08:41:26 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5139B00E.1080000@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> Message-ID: <1362750086.2822.113.camel@willson.li.ssimo.org> On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: > Hi, > > On 7.3.2013 21:15, Rob Crittenden wrote: > > Based on a comment from Sumit in ticket > > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > > how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > Can we have one multi-valued attribute which contains names of flags to > set instead of one attribute per flag? It might make adding new flags > easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? > Would it make sense to add a global configuration option to turn flags > on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Mar 8 13:43:38 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Mar 2013 08:43:38 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5138F556.8020504@redhat.com> References: <5138F556.8020504@redhat.com> Message-ID: <1362750218.2822.114.camel@willson.li.ssimo.org> On Thu, 2013-03-07 at 15:15 -0500, Rob Crittenden wrote: > Based on a comment from Sumit in ticket > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > There is a bit of hand waving going on around how the flags are actually > set inside the KDB plugin since I'm not at all familiar with that code > but I don't expect it to be too big a deal. > > I'm not necessarily volunteering to do this work, just trying to keep > the ball moving forward. How is upgrade performed ? What happens during upgrade when mixed old/new servers are around ? Please add explicitly the process in the Design page, this is crucial to decide if this design is acceptable or not. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Mar 8 13:50:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Mar 2013 14:50:21 +0100 Subject: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional In-Reply-To: <5139E3FF.9080100@redhat.com> References: <51388B54.1090405@redhat.com> <51389BD3.4000101@redhat.com> <5138B33C.7020409@redhat.com> <5138C762.4090405@redhat.com> <5138CCAF.7090202@redhat.com> <5139E3FF.9080100@redhat.com> Message-ID: <5139EC9D.6010405@redhat.com> On 03/08/2013 02:13 PM, Petr Viktorin wrote: > On 03/07/2013 06:21 PM, Jan Cholasta wrote: >> On 7.3.2013 17:59, Petr Viktorin wrote: >>> On 03/07/2013 04:33 PM, Jan Cholasta wrote: >>>> On 7.3.2013 14:53, Petr Viktorin wrote: >>>>> On 03/07/2013 01:43 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> these patches add flags to LDAPClient and IPAdmin constructors which >>>>>> can >>>>>> be used to disable schema retrieval and decoding of attributes. This >>>>>> should make interacting with AD easier (see >>>>>> ). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Honza >>> [...] >>>> >>>> Updated patches attached. >>>> >>>> Honza >>>> >>> >>> In LDAPEntry.__setitem__, schema.get_obj is used without checking if the >>> schema is None. >>> >> >> I knew I forgot something! Thanks. Fixed. >> >> Updated patches attached. >> >> Honza >> > > ACK > Pushed to master. Martin From tbabej at redhat.com Fri Mar 8 14:01:45 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 08 Mar 2013 15:01:45 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <51390E3D.6090305@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> <5138B1F4.4060002@redhat.com> <5138B81A.4060700@redhat.com> <51390E3D.6090305@redhat.com> Message-ID: <5139EF49.50308@redhat.com> On Thu 07 Mar 2013 11:01:33 PM CET, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/07/2013 04:27 PM, Tomas Babej wrote: >>> On 03/07/2013 04:12 PM, Petr Viktorin wrote: >>>> Thanks! I just have two more very minor nitpicks. >>>> >>>> On 03/06/2013 01:04 PM, Tomas Babej wrote: >>>>> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>>>>> Thanks! The mechanism works, but see below. >>>>>> >>>>>> This is a RFE so it needs a design document. >>>>>> >>>>> http://freeipa.org/page/V3/Client_install_using_keytab >>>> >>>> Please also add the link to the commit message. >>>> >>>> >>>> I think you answered Petr?'s security questions adequately. >>>> Petr, note that this is a client-side change; if the keytab is >>>> compromised the attacker can do all this manually anyway. >>>> >>>>> diff --git a/ipa-client/ipa-install/ipa-client-install >>>>> b/ipa-client/ipa-install/ipa-client-install >>>>> index >>>>> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >>>>> >>>>> >>>>> 100755 >>>>> --- a/ipa-client/ipa-install/ipa-client-install >>>>> +++ b/ipa-client/ipa-install/ipa-client-install >>>>> @@ -104,6 +104,8 @@ def parse_options(): >>>> [...] >>>>> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >>>>> except ipaclient.ntpconf.NTPConfigurationError: >>>>> pass >>>>> >>>>> - if options.unattended and (options.password is None and >>>>> options.principal is None and options.prompt_password is False) and >>>>> not options.on_master: >>>>> - root_logger.error("One of password and principal are >>>>> required.") >>>>> + if options.unattended and ((options.password is None and >>>>> + options.principal is None and >>>>> + options.keytab is None and >>>>> + options.prompt_password is False)\ >>>>> + and not options.on_master): >>>> >>>> Please also remove the inner parentheses and the backslash. >>>> >>> Both fixed, updated patch attached. >>> >>> Tomas >> >> ACK, thanks! >> > > This needs related man page updates before we can push it. > Man pages updated: [tbabej at thinkpad7 freeipa]$ git diff diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-ins [...] +\fB\-k\fR, \fB\-\-keytab\fR +Path to backed up host keytab from previous enrollment. +.TP [...] diff --git a/ipa-client/man/ipa-join.1 b/ipa-client/man/ipa-join.1 [...] +\fB\-f,\-\-force\fR +Force enrolling the host even if host entry exists. +.TP > Can you update the design to specifically include that the old > certificate needs to be revoked, not just that a new certificate be > issued (sort of implied, and it worked in my testing)? I updated the design page accordingly. However, shouldn't be this handled by server side automatically? > rob Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0037-4-Add-support-for-re-enrolling-hosts-using-keytab.patch Type: text/x-patch Size: 9878 bytes Desc: not available URL: From tbabej at redhat.com Fri Mar 8 14:39:03 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 08 Mar 2013 15:39:03 +0100 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges In-Reply-To: <51391930.7090108@redhat.com> References: <5135DE06.2080408@redhat.com> <51391930.7090108@redhat.com> Message-ID: <5139F807.2030500@redhat.com> On 03/07/2013 11:48 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> Any of the following checks: >> - overlap between primary RID range and secondary RID range >> - overlap between secondary RID range and secondary RID range >> >> is performed now only if both of the ranges involved are local >> domain ranges. >> >> https://fedorahosted.org/freeipa/ticket/3391 >> >> Tomas >> > > So I assume in your reproduction steps the secondary range for both is > 0 hence the overlap? Yes, that causes the issue. > > rob Tomas From mkosek at redhat.com Fri Mar 8 14:44:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Mar 2013 15:44:42 +0100 Subject: [Freeipa-devel] [PATCH] 0190 Fix installing server with external CA In-Reply-To: <51361CF0.30800@redhat.com> References: <5134AFC2.5040204@redhat.com> <51360B6A.1040004@redhat.com> <51361CF0.30800@redhat.com> Message-ID: <5139F95A.4000904@redhat.com> On 03/05/2013 05:27 PM, Jan Cholasta wrote: > On 5.3.2013 16:12, Jan Cholasta wrote: >> Hi, >> >> On 4.3.2013 15:29, Petr Viktorin wrote: >>> I did not test the external CA case when we merged DS instances some >>> time ago, so it ended up broken. Here is a fix. >>> >>> >>> Our DsInstance class could only be initialized properly by calling >>> create_instance or create_replica. Fr step 2, when the DS is not being >>> installed, I gathered the common setup code to init_info, and called >>> that. Ideally this will one day end up in __init__, but that's for a >>> bigger refactoring. >>> >>> >>> https://fedorahosted.org/freeipa/ticket/3459 >>> >> >> I have tried installing IPA with external CA with your patch several >> times, and ipa-server-install always gets stuck while doing LDAP >> updates. I am not really sure how these two are connected. Can you >> please check if that happens to you on IPA from current master as well? >> >> Honza >> > > Turns out this was an error on my part. Sorry. > > ACK. > > Honza > Pushed to master, ipa-3.1. Martin From simo at redhat.com Fri Mar 8 14:50:17 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Mar 2013 09:50:17 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362593086.12650.8.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> Message-ID: <1362754217.2822.121.camel@willson.li.ssimo.org> On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > > Patch is attached. > > > > There are currently a few security downsides to this patch: > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > > > This patch also adds some new dependencies, namely: > > 1. libverto (a dependency of krb5) > > 2. systemd > > 3. a krb5 patched for libk5radius support [1] > > > > In the interest of trying to meet the Fedora Features deadline, I am > > providing the patch in spite of the above issues. > > > > Nathaniel > > > > 1 - http://bit.ly/ZqtK79 > > Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > schema. This will need to be verified and finalized. I reserved this OID space for ipa OTP schema. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Mar 8 14:57:09 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 08 Mar 2013 09:57:09 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362754217.2822.121.camel@willson.li.ssimo.org> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> Message-ID: <1362754629.9093.10.camel@localhost.localdomain> On Fri, 2013-03-08 at 09:50 -0500, Simo Sorce wrote: > On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > > On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > > > Patch is attached. > > > > > > There are currently a few security downsides to this patch: > > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > > > > > This patch also adds some new dependencies, namely: > > > 1. libverto (a dependency of krb5) > > > 2. systemd > > > 3. a krb5 patched for libk5radius support [1] > > > > > > In the interest of trying to meet the Fedora Features deadline, I am > > > providing the patch in spite of the above issues. > > > > > > Nathaniel > > > > > > 1 - http://bit.ly/ZqtK79 > > > > Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > > schema. This will need to be verified and finalized. > > I reserved this OID space for ipa OTP schema. Thanks! For posterity, where is this documented? Nathaniel From simo at redhat.com Fri Mar 8 14:59:59 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Mar 2013 09:59:59 -0500 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362754629.9093.10.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> Message-ID: <1362754799.2822.122.camel@willson.li.ssimo.org> On Fri, 2013-03-08 at 09:57 -0500, Nathaniel McCallum wrote: > On Fri, 2013-03-08 at 09:50 -0500, Simo Sorce wrote: > > On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > > > On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > > > > Patch is attached. > > > > > > > > There are currently a few security downsides to this patch: > > > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > > > > > > > This patch also adds some new dependencies, namely: > > > > 1. libverto (a dependency of krb5) > > > > 2. systemd > > > > 3. a krb5 patched for libk5radius support [1] > > > > > > > > In the interest of trying to meet the Fedora Features deadline, I am > > > > providing the patch in spite of the above issues. > > > > > > > > Nathaniel > > > > > > > > 1 - http://bit.ly/ZqtK79 > > > > > > Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > > > schema. This will need to be verified and finalized. > > > > I reserved this OID space for ipa OTP schema. > > Thanks! For posterity, where is this documented? In the previous mail to the list ;-) Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Fri Mar 8 15:41:29 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 08 Mar 2013 16:41:29 +0100 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges In-Reply-To: <5139C708.6020601@redhat.com> References: <5135DE06.2080408@redhat.com> <5139C708.6020601@redhat.com> Message-ID: <513A06A9.7090106@redhat.com> On 03/08/2013 12:10 PM, Martin Kosek wrote: > On 03/05/2013 12:59 PM, Tomas Babej wrote: >> Hi, >> >> Any of the following checks: >> - overlap between primary RID range and secondary RID range >> - overlap between secondary RID range and secondary RID range >> >> is performed now only if both of the ranges involved are local >> domain ranges. >> >> https://fedorahosted.org/freeipa/ticket/3391 >> > > I think the patch is functionally OK (I tested it), I would just > change the flow of the following: > > @@ -194,19 +198,22 @@ static int ranges_overlap(struct range_info *r1, > struct range_info *r2) > r1->id_range_size, r2->id_range_size)) > return 2; > > - /* check if secondary rid range overlaps with existing > secondary rid range */ > + /** > + * The following 3 checks are relevant only if both ranges > are local. > + * Check if secondary rid range overlaps with existing > secondary rid > + * range. **/ > if (intervals_overlap(r1->secondary_base_rid, > r2->secondary_base_rid, > - r1->id_range_size, r2->id_range_size)) > + r1->id_range_size, r2->id_range_size) && local_ranges) > return 3; > ... > > > TO something like > > ... > /** > * The following checks are relevant only if both ranges are > local. > * Check if secondary rid range overlaps with existing > secondary rid > * range. **/ > if (local_ranges) { > ... do the checks > } > ... > > Doing it your way, intervals_overlap() function is called 3 times when > not needed + it is not so obvious that these checks are only done with > "local_ranges" only. > > Martin Refactored. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0038-2-Perform-secondary-rid-range-overlap-check-for-local-.patch Type: text/x-patch Size: 3823 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 8 15:45:40 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Mar 2013 10:45:40 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <20130308092746.GJ16010@localhost.localdomain> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> Message-ID: <513A07A4.9030302@redhat.com> Sumit Bose wrote: > On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: >> Based on a comment from Sumit in ticket >> https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline >> of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags >> >> There is a bit of hand waving going on around how the flags are >> actually set inside the KDB plugin since I'm not at all familiar >> with that code but I don't expect it to be too big a deal. >> >> I'm not necessarily volunteering to do this work, just trying to >> keep the ball moving forward. > > Thank you for setting up the design page. I would like to suggest that > we should try to include all currently available flags in one run, > because: > - some flags related to OTP would be needed as well > - it is only a minor increase the development effort > - it is only a minor increase in the QE effort. Instead of doing > * set/unset flag in CLI/WebUI > * check with kdamin.local if the flag is in the expected state > for a single attribute it has to be done for a list of attributes > (maybe the steps can be added to a new 'How to test' section on the > design page) > - it will help to find a good solution how to handle the flags in the > CLI/WebUI > > I think the last point is important because the flags are needed for all > Kerberos principals, i.e. users, hosts and services. Instead of adding a > list of new options/check boxes to each of the CLI commands/WebUI pages > it might be more helpful to handle the flags separately. The CLI can get > a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be > shown and modified in a separate tab, I hope this will allow to use a > common template to users, hosts and services. These are only rough ideas > and suggestions, my point is that if we not only add a single flag but > about 15 it might be easier to find a good and usable interface to > modify them. I'll update the page with these comments as well, eventually... Ok, a new plugin makes sense, so we don't have to pollute all the other plugins with these flags. One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). As for setting all these flags, is this going to introduce oddball support issues if people start experimenting with turning somethings on and off? I really don't know. They can do it now using kadmin.local I suppose, and we aren't hearing any complaints. Simo asked about upgrades. An interesting question. So we'd have to sift through all the krbextradata to see if any of the flags we want to set are actually set and update LDAP. We may end up requiring a C tool to do this. Mixing old and new backends could be supported during a transition period by setting the value both in the attribute and within krbextradata but we lack a way to do that in python AFAIK. Doing this in a 398-ds plugin might be an easy way to support forwards and backwards compatibility, and it'd be C so we'd avoid all the python issues. Adding the new schema and plugin should be the easy part. rob From npmccallum at redhat.com Fri Mar 8 17:28:03 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 08 Mar 2013 12:28:03 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <20130308092746.GJ16010@localhost.localdomain> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> Message-ID: <1362763683.9093.22.camel@localhost.localdomain> On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: > On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: > > Based on a comment from Sumit in ticket > > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline > > of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > > > There is a bit of hand waving going on around how the flags are > > actually set inside the KDB plugin since I'm not at all familiar > > with that code but I don't expect it to be too big a deal. > > > > I'm not necessarily volunteering to do this work, just trying to > > keep the ball moving forward. > > Thank you for setting up the design page. I would like to suggest that > we should try to include all currently available flags in one run, > because: > - some flags related to OTP would be needed as well I'm not aware of any. Are you? I may very well be missing something obvious. Nathaniel From pspacek at redhat.com Fri Mar 8 17:52:31 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 08 Mar 2013 18:52:31 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513A07A4.9030302@redhat.com> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <513A07A4.9030302@redhat.com> Message-ID: <513A255F.7030500@redhat.com> On 8.3.2013 16:45, Rob Crittenden wrote: > One would need to pass in the object type they are dealing with: > > ipa krbflags --type=user --ok-as-delegate=false sbose > ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com > > We *could* avoid type potentially but it would expand our search base and > could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) > We could search on the accounts > container using (objectclass=ipaKrbPrincipal) and > (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like > that. I think I'd prefer specifying a type to avoid the case where someone has > a hostname the same as a uid (we typically allow specifying non-fqdn when > managing hosts). Would it be possible define some reasonable default value for "--type"? I don't like typing "--service" all the time ... -- Petr^2 Spacek From sbose at redhat.com Fri Mar 8 17:53:52 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 8 Mar 2013 18:53:52 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1362763683.9093.22.camel@localhost.localdomain> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <1362763683.9093.22.camel@localhost.localdomain> Message-ID: <20130308175352.GM16010@localhost.localdomain> On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote: > On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: > > On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: > > > Based on a comment from Sumit in ticket > > > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline > > > of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > > > > > There is a bit of hand waving going on around how the flags are > > > actually set inside the KDB plugin since I'm not at all familiar > > > with that code but I don't expect it to be too big a deal. > > > > > > I'm not necessarily volunteering to do this work, just trying to > > > keep the ball moving forward. > > > > Thank you for setting up the design page. I would like to suggest that > > we should try to include all currently available flags in one run, > > because: > > - some flags related to OTP would be needed as well > > I'm not aware of any. Are you? I may very well be missing something > obvious. iirc you once mentioned that requires_hwauth is used to signal the client that an OTP is needed. But I haven't checked your recent code if the flag is added behind the scenes or if it needs to be set for the principal. bye, Sumit > > Nathaniel > > From npmccallum at redhat.com Fri Mar 8 18:17:11 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 08 Mar 2013 13:17:11 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <20130308175352.GM16010@localhost.localdomain> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <1362763683.9093.22.camel@localhost.localdomain> <20130308175352.GM16010@localhost.localdomain> Message-ID: <1362766631.9093.26.camel@localhost.localdomain> On Fri, 2013-03-08 at 18:53 +0100, Sumit Bose wrote: > On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote: > > On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: > > > On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: > > > > Based on a comment from Sumit in ticket > > > > https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline > > > > of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > > > > > > > There is a bit of hand waving going on around how the flags are > > > > actually set inside the KDB plugin since I'm not at all familiar > > > > with that code but I don't expect it to be too big a deal. > > > > > > > > I'm not necessarily volunteering to do this work, just trying to > > > > keep the ball moving forward. > > > > > > Thank you for setting up the design page. I would like to suggest that > > > we should try to include all currently available flags in one run, > > > because: > > > - some flags related to OTP would be needed as well > > > > I'm not aware of any. Are you? I may very well be missing something > > obvious. > > iirc you once mentioned that requires_hwauth is used to signal the > client that an OTP is needed. But I haven't checked your recent code if > the flag is added behind the scenes or if it needs to be set for the > principal. We chose to abandon this since this flag is passed to the recipients of the ticket and since OTP doesn't necessarily provide hardware guarantee. Note that requires_hwauth is an RFC defined flag and admins may wish to use it, so support for it should probably be present. However, it is unrelated to OTP at this point. Nathaniel From rcritten at redhat.com Fri Mar 8 19:09:40 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Mar 2013 14:09:40 -0500 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513A255F.7030500@redhat.com> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <513A07A4.9030302@redhat.com> <513A255F.7030500@redhat.com> Message-ID: <513A3774.1060101@redhat.com> Petr Spacek wrote: > On 8.3.2013 16:45, Rob Crittenden wrote: >> One would need to pass in the object type they are dealing with: >> >> ipa krbflags --type=user --ok-as-delegate=false sbose >> ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com >> >> We *could* avoid type potentially but it would expand our search base and >> could slow things down with lots of entries. > Correct me if I'm wrong, but our KDC driver usually does sub-tree search > with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. > > We could search on the accounts >> container using (objectclass=ipaKrbPrincipal) and >> (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or >> something like >> that. I think I'd prefer specifying a type to avoid the case where >> someone has >> a hostname the same as a uid (we typically allow specifying non-fqdn when >> managing hosts). > Would it be possible define some reasonable default value for "--type"? > I don't like typing "--service" all the time ... > Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. rob From mkosek at redhat.com Mon Mar 11 08:09:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 09:09:42 +0100 Subject: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf In-Reply-To: <5139A624.50004@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> Message-ID: <513D9146.6080604@redhat.com> On 03/08/2013 09:49 AM, Petr Spacek wrote: > On 8.3.2013 00:14, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>> unnecessary Kerberos checks on BIND startup and can cause issues when >>> KDC is not available. >>> >>> Both new and current IPA installations are updated. >>> >>> https://fedorahosted.org/freeipa/ticket/3429 >>> >> >> Still reviewing this but I noticed that after upgrading my 3.1.99 server >> pre-patch to with with-patch version the connections argument in named.conf >> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >> during the initial install too? > > For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections > should not harm. > > Higher value should allow higher level of parallelism, it is one of tuning > parameters. Value 4 was necessary to prevent deadlocks in some previous > versions of bind-dyndb-ldap. > Previously, when I implemented the upgrade script, I set connections arg only if it was present in named.conf and thus bind-dyndb-ldap could not use a reasonable default on its own decision. This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections is set always. Rob is correct, that in that case we might want to add it to named.conf by default to make it consistent... or we could also fix upgrade script to change connections only if it is present in named.conf. Petr, what does make more sense bind-dyndb-ldap wise? Thanks, Martin From pspacek at redhat.com Mon Mar 11 08:39:18 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 Mar 2013 09:39:18 +0100 Subject: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf In-Reply-To: <513D9146.6080604@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> <513D9146.6080604@redhat.com> Message-ID: <513D9836.3060601@redhat.com> On 11.3.2013 09:09, Martin Kosek wrote: > On 03/08/2013 09:49 AM, Petr Spacek wrote: >> On 8.3.2013 00:14, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>>> unnecessary Kerberos checks on BIND startup and can cause issues when >>>> KDC is not available. >>>> >>>> Both new and current IPA installations are updated. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3429 >>>> >>> >>> Still reviewing this but I noticed that after upgrading my 3.1.99 server >>> pre-patch to with with-patch version the connections argument in named.conf >>> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >>> during the initial install too? >> >> For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections >> should not harm. >> >> Higher value should allow higher level of parallelism, it is one of tuning >> parameters. Value 4 was necessary to prevent deadlocks in some previous >> versions of bind-dyndb-ldap. >> > > Previously, when I implemented the upgrade script, I set connections arg only > if it was present in named.conf and thus bind-dyndb-ldap could not use a > reasonable default on its own decision. > > This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections > is set always. Rob is correct, that in that case we might want to add it to > named.conf by default to make it consistent... or we could also fix upgrade > script to change connections only if it is present in named.conf. > > Petr, what does make more sense bind-dyndb-ldap wise? Default values should work. Personally I would include only "override" values in named.conf, but technically it doesn't matter. Note: Latest bind-dyndb-ldap versions refuse to start if configuration is insane. Fatal error will point admin to errors in configuration and should prevent surprises from auto-magically changed values. Invalid configurations - examples: connections < 1 connections < 2 && psearch is enabled serial_autoincrement enabled && psearch disabled -- Petr^2 Spacek From mkosek at redhat.com Mon Mar 11 09:26:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 10:26:31 +0100 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <5137318A.2010505@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> <5137318A.2010505@redhat.com> Message-ID: <513DA347.8040100@redhat.com> On 03/06/2013 01:07 PM, Petr Spacek wrote: > On 6.3.2013 09:32, Martin Kosek wrote: >> + error=u'CNAME record is not allowed to coexist with any >> other record'), > > Sorry for nitpicking again, but I would add note '(RFC 1034, section 3.6.2)'. > > Thank you! > Fixed. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-378-3-change-cname-and-dname-attributes-to-single-valued.patch Type: text/x-patch Size: 5397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-379-3-improve-cname-record-validation.patch Type: text/x-patch Size: 7614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-380-3-improve-dname-record-validation.patch Type: text/x-patch Size: 7997 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 11 11:40:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 12:40:43 +0100 Subject: [Freeipa-devel] [PATCH] 381 Preserve order of servers in ipa-client-install In-Reply-To: <51389F08.1030607@redhat.com> References: <51388F87.6040200@redhat.com> <51389F08.1030607@redhat.com> Message-ID: <513DC2BB.4020905@redhat.com> On 03/07/2013 03:07 PM, Petr Viktorin wrote: > On 03/07/2013 02:00 PM, Martin Kosek wrote: >> When multiple servers are passed via --server option, ipadiscovery >> module changed its order. Make sure that we preserve it. >> >> Also make sure that user is always warned when a tested server is >> not available as then the server will be excluded from the fixed >> server list. > > The message doesn't actually say that the server will be removed. It would be > nice if it did. > > Otherwise, ACK. Sending a patch with improved logging. User should now be more clear what server is failing to verify (and why). > >> ------ >> >> When working on this ticket I was thinking - do we make the right thing we >> deliberately remove a server from user-provided server list just because we >> cannot connect to it at the moment if discovery? It may just be temporarily >> down or something. >> >> Maybe we should preserve the original --server list in this case and use this >> list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other >> active configuration commands we would have to use only the valid servers so >> that the we do not hit the server that is currently down. >> >> Martin > > Good point, this deserves a ticket. > Rob, do you think this deserves to be changed? Or is this behavior indeed intended? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-381-2-preserve-order-of-servers-in-ipa-client-install.patch Type: text/x-patch Size: 5193 bytes Desc: not available URL: From akrivoka at redhat.com Mon Mar 11 12:02:34 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 11 Mar 2013 13:02:34 +0100 Subject: [Freeipa-devel] [PATCH] 0006 Remove check for alphabetic only characters from domain name validation In-Reply-To: <512DD8BC.2080904@redhat.com> References: <511E44A9.9090509@redhat.com> <51221027.7050803@redhat.com> <20130218114750.GC27418@localhost.localdomain> <512219D7.9000909@redhat.com> <51249F6E.7030005@redhat.com> <51273810.9060800@redhat.com> <5127889F.9020202@redhat.com> <512DD8BC.2080904@redhat.com> Message-ID: <513DC7DA.1000003@redhat.com> On 02/27/2013 10:58 AM, Martin Kosek wrote: > On 02/22/2013 04:02 PM, Ana Krivokapic wrote: >> On 02/22/2013 10:19 AM, Petr Spacek wrote: >>> On 20.2.2013 11:03, Ana Krivokapic wrote: >>>> On 02/18/2013 01:08 PM, Martin Kosek wrote: >>>>> On 02/18/2013 12:47 PM, Sumit Bose wrote: >>>>>> On Mon, Feb 18, 2013 at 12:27:35PM +0100, Petr Spacek wrote: >>>>>>> On 15.2.2013 15:22, Ana Krivokapic wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> The .isalpha() check in validate_domain_name() was too strict, >>>>>>>> causing some commands like ipa dnsrecord-add to fail. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3385 >>>>>>> I would add --force option rather than removing whole check, if >>>>>>> it's possible. >>>>>>> >>>>>>> Would it be possible to mention RFC in the error message? Something >>>>>>> like _('top level domain label must be alphabetic (RFC 1123 section >>>>>>> 2.1)') >>>>>>> ? >>>>>>> >>>>>>> IMHO it is handy, because it educates users. >>>>>> The problem is that this check is always done on the last component of >>>>>> the domain_name even if it is just a sub-domain of the FreeIPA domain, >>>>>> where e.g. numbers are valid characters. >>>>>> >>>>>> At the beginning of validate_domain_name() a trailing '.' is stripped >>>>>> away. iirc the trailing '.' is an indication for a complete, fully >>>>>> qualified name. Would it work if the presence of the trailing '.' is >>>>>> saved and the check is only done if there was a '.'? >>>>>> >>>>>> bye, >>>>>> Sumit >>>>>> >>>>> Sure. Though I am now not 100% sure that some IPA functions do not >>>>> use this >>>>> validator with a fqdn hostname without trailing dot. If not, I am >>>>> for fixing >>>>> this function as Sumit and Petr suggested. >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> After some thought, I decided to change the approach. >>>> >>>> As pointed out by Sumit, the problem was that the validate_domain_name() >>>> function did not distinguish between fqdn and non-fqdn domains >>>> (subdomains of the IPA domain). The trailing dot is not a clear >>>> indication either, because some IPA functions use this validator with an >>>> fqdn without the trailing dot. >>>> >>>> To fix this, I introduced an additional parameter to this function - a >>>> flag which indicates whether the domain name is an fqdn or not. The is >>>> .isalpha() check is then performed only in the case of an fqdn. >>>> >>>> I also improved the error message to mention the relevant RFC, as >>>> suggested by Petr. >>> Please don't forget to add --force switch. It could be handy. >>> >> I added the --force switch to ipa dnsrecord-add and opened a new ticket >> to handle the rest of the ipa commands that use domain name validation: >> https://fedorahosted.org/freeipa/ticket/3455 >> >> Updated patch is attached. >> > This patch fixed validation only partially. The --force flag you made available > will not allow admin to for example add a zone "example.zone1" which > technically will be resolvable, it is just not a good practice: > > # ipa dnszone-add example.zone1 --name-server `hostname`. --force > ipa: ERROR: invalid 'name': top level domain label must be alphabetic (RFC 1123 > section 2.1) > > To enable this, I think you would need to not postpone the validation to DNS > zone pre_callback as you could not check --force flag presence right in the > idnsname parameter validator. > > We may also want to change --force flag label, it now talks only about NS > record validation, but we now expanded it a bit, so the label would need to be > more general. > > Martin I added the fix for dnszone-add and edited the label of the --force flag to make it more general. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0006-04-Improve-domain-name-validation.patch Type: text/x-patch Size: 4092 bytes Desc: not available URL: From jcholast at redhat.com Mon Mar 11 12:13:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Mar 2013 13:13:16 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <5139E41A.7020203@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> Message-ID: <513DCA5C.3050901@redhat.com> On 8.3.2013 14:14, Petr Viktorin wrote: > On 03/07/2013 05:42 PM, Jan Cholasta wrote: >> Patch 191: >> >> The patch is missing the ipapython/ipaldap.py file. On 7.3.2013 18:29, Petr Viktorin wrote: > It's there, it's just copied from ipaserver/ipaldap.py with a small > change at the bottom. There is no sign of the file, except in the patch header and the patch cannot be applied with git am nor with git apply. But perhaps I'm doing something wrong. >> >> I think it should go into ipalib instead of ipapython. It doesn't >> make sense to keep ipapython and ipalib separate if they depend on each >> other. We should either merge them or clean up the mess by removing >> ipalib imports from ipapython. I'm not saying we should do it now, just >> please don't add new modules to ipapython which import from ipalib. >> > > This is a bigger problem. > Conceptually ipaldap should be in ipapython, it just needs the > problematic errors and text modules. I think we should move those rather > than ipaldap. Moving test to ipapython makes sense. I think we should have a separate set of errors for ipaldap and translate them to framework errors in ipalib. > >> Also I am not very fond of the "ipa" prefix in "ipaldap". The module >> lives in the namespace of our own package, so there's no need for it to >> have such a prefix, is there? > > It's nice to have a unique name for talking about it. > Since "ldap" is already a package we use, having another "ldap" would be > confusing, even if it is properly namespaced. Since ipaldap should be the sole user of python-ldap after the refactoring is done, I don't think there would be any confusion. But whatever, I'm fine with both. > >> Patch 193: >> >> + scope=conn.SCOPE_BASE, >> + filter='objectclass=pkiCA', >> + attrs_list=[ca_cert_attr], >> >> Can we use a proper filter here please? >> >> + :param conn: Bound LDAPConnection that will be used for searching > > Fixed, thanks > >> LDAPClient >> >> Patch 194: >> >> - ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, True) >> >> and >> >> - lh.set_option(ldap.OPT_X_TLS_DEMAND, True) >> >> Is removing these options safe? > > I re-added them. > > I also removed the forgotten debugging `raise`s Martin found. > > Adding patch 0196, which disables downloading the schema for discovery. > > Updated patches attached. They now depend on Honza's patches 116-119 > ACK. Honza -- Jan Cholasta From pviktori at redhat.com Mon Mar 11 12:43:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 11 Mar 2013 13:43:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513DCA5C.3050901@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> Message-ID: <513DD180.60903@redhat.com> On 03/11/2013 01:13 PM, Jan Cholasta wrote: > On 8.3.2013 14:14, Petr Viktorin wrote: >> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>> Patch 191: >>> >>> The patch is missing the ipapython/ipaldap.py file. > > On 7.3.2013 18:29, Petr Viktorin wrote: > > It's there, it's just copied from ipaserver/ipaldap.py with a small > > change at the bottom. > > There is no sign of the file, except in the patch header and the patch > cannot be applied with git am nor with git apply. But perhaps I'm doing > something wrong. Attaching a re-formatted version of the patch. [...] > ACK. > > Honza > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0191.3-Move-ipaldap-to-ipapython.patch Type: text/x-patch Size: 140395 bytes Desc: not available URL: From jcholast at redhat.com Mon Mar 11 12:48:33 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Mar 2013 13:48:33 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513DD180.60903@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> Message-ID: <513DD2A1.7080409@redhat.com> On 11.3.2013 13:43, Petr Viktorin wrote: > On 03/11/2013 01:13 PM, Jan Cholasta wrote: >> On 8.3.2013 14:14, Petr Viktorin wrote: >>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>> Patch 191: >>>> >>>> The patch is missing the ipapython/ipaldap.py file. >> >> On 7.3.2013 18:29, Petr Viktorin wrote: >> > It's there, it's just copied from ipaserver/ipaldap.py with a small >> > change at the bottom. >> >> There is no sign of the file, except in the patch header and the patch >> cannot be applied with git am nor with git apply. But perhaps I'm doing >> something wrong. > > Attaching a re-formatted version of the patch. > > [...] >> ACK. >> >> Honza >> > > ACK for real. Honza -- Jan Cholasta From mkosek at redhat.com Mon Mar 11 12:59:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 13:59:34 +0100 Subject: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges In-Reply-To: <513A06A9.7090106@redhat.com> References: <5135DE06.2080408@redhat.com> <5139C708.6020601@redhat.com> <513A06A9.7090106@redhat.com> Message-ID: <513DD536.5080309@redhat.com> On 03/08/2013 04:41 PM, Tomas Babej wrote: > On 03/08/2013 12:10 PM, Martin Kosek wrote: >> On 03/05/2013 12:59 PM, Tomas Babej wrote: >>> Hi, >>> >>> Any of the following checks: >>> - overlap between primary RID range and secondary RID range >>> - overlap between secondary RID range and secondary RID range >>> >>> is performed now only if both of the ranges involved are local >>> domain ranges. >>> >>> https://fedorahosted.org/freeipa/ticket/3391 >>> >> >> I think the patch is functionally OK (I tested it), I would just change the >> flow of the following: >> >> @@ -194,19 +198,22 @@ static int ranges_overlap(struct range_info *r1, struct >> range_info *r2) >> r1->id_range_size, r2->id_range_size)) >> return 2; >> >> - /* check if secondary rid range overlaps with existing secondary rid >> range */ >> + /** >> + * The following 3 checks are relevant only if both ranges are local. >> + * Check if secondary rid range overlaps with existing secondary rid >> + * range. **/ >> if (intervals_overlap(r1->secondary_base_rid, r2->secondary_base_rid, >> - r1->id_range_size, r2->id_range_size)) >> + r1->id_range_size, r2->id_range_size) && local_ranges) >> return 3; >> ... >> >> >> TO something like >> >> ... >> /** >> * The following checks are relevant only if both ranges are local. >> * Check if secondary rid range overlaps with existing secondary rid >> * range. **/ >> if (local_ranges) { >> ... do the checks >> } >> ... >> >> Doing it your way, intervals_overlap() function is called 3 times when not >> needed + it is not so obvious that these checks are only done with >> "local_ranges" only. >> >> Martin > Refactored. > > Tomas ACK. Pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Mon Mar 11 13:27:56 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 11 Mar 2013 14:27:56 +0100 Subject: [Freeipa-devel] [PATCH] 266 Fixed Web UI build error caused by rhino changes in F19 Message-ID: <513DDBDC.1040901@redhat.com> rhino-1.7R4-2.fc19.noarch dropped -main flag which made the build fail in rawhide (F19). We can't use the same command for rhino-1.7R3-6 (F18) and rhino-1.7R4-2 (F19). This patch adds check if rhino supports '-require' option. If so it calls rhino with it if not it calls rhino with -main option. https://fedorahosted.org/freeipa/ticket/3501 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0266-Fixed-Web-UI-build-error-caused-by-rhino-changes-in-.patch Type: text/x-patch Size: 1390 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 11 13:51:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Mar 2013 09:51:50 -0400 Subject: [Freeipa-devel] Failed push to github In-Reply-To: <5139A33D.7050600@redhat.com> References: <1362699518.9093.7.camel@localhost.localdomain> <5139A33D.7050600@redhat.com> Message-ID: <513DE176.8010709@redhat.com> Petr Viktorin wrote: > On 03/08/2013 12:38 AM, Nathaniel McCallum wrote: >> I tried to push my branch of FreeIPA to github and it failed with the >> following message. I don't know if anything can be done to fix it, but I >> figured I'd mention it. >> >> error: object 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db:invalid >> author/committer line - bad date >> fatal: Error in object >> error: pack-objects died of signal 13 >> error: failed to push some refs to >> 'git at github.com:npmccallum/freeipa.git' >> >> Nathaniel >> > > Yes, we have some commits with invalid commit times. > If you fork https://github.com/encukou/freeipa you should be fine. > (I've asked Github staff to turn off the checks so I could push it > initially.) > Apparently when we migrated from mercurial to git a bunch of dates got horked. We've had requests to fix up the dates in our tree so github will work but apparently this would change all our commit ids so is not something we're interested in. rob From mkosek at redhat.com Mon Mar 11 13:56:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 14:56:05 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513DD2A1.7080409@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> <513DD2A1.7080409@redhat.com> Message-ID: <513DE275.40709@redhat.com> On 03/11/2013 01:48 PM, Jan Cholasta wrote: > On 11.3.2013 13:43, Petr Viktorin wrote: >> On 03/11/2013 01:13 PM, Jan Cholasta wrote: >>> On 8.3.2013 14:14, Petr Viktorin wrote: >>>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>>> Patch 191: >>>>> >>>>> The patch is missing the ipapython/ipaldap.py file. >>> >>> On 7.3.2013 18:29, Petr Viktorin wrote: >>> > It's there, it's just copied from ipaserver/ipaldap.py with a small >>> > change at the bottom. >>> >>> There is no sign of the file, except in the patch header and the patch >>> cannot be applied with git am nor with git apply. But perhaps I'm doing >>> something wrong. >> >> Attaching a re-formatted version of the patch. >> >> [...] >>> ACK. >>> >>> Honza >>> >> >> > > ACK for real. > > Honza > I would not want to rush this, I still see errors: 1) ipa-ldap-updater is broken: # ipa-ldap-updater --upgrade Upgrading IPA: [1/8]: stopping directory server [2/8]: saving configuration [3/8]: disabling listeners [4/8]: starting directory server [5/8]: upgrading server Upgrade failed with 'NameSpace' object has no attribute 'ldap2' [6/8]: stopping directory server [7/8]: restoring configuration [8/8]: starting directory server Done. IPA upgrade failed. 2) What's the purpose of this new error? +class DatabaseTimeout(DatabaseError): + """ + **4211** Raised when an LDAP call times out + + For example: + + >>> raise DatabaseTimeout() + Traceback (most recent call last): + ... + DatabaseTimeout: LDAP timeout + """ + + errno = 4211 + format = _('LDAP timeout') It is not raised anywhere (as far as I can see). BTW I assume it is not related to errors.LimitsExceeded in any way, right? 3) Client installation no longer works if the server has disabled anonymous authentication: # ipa-client-install Error checking LDAP: Inappropriate authentication: Anonymous access is not allowed. DNS discovery failed to determine your DNS domain Provide the domain name of your IPA server (ex: example.com): ^C 4) I suddenly cannot run some tests, looks like import loop: # ./make-test tests/test_xmlrpc/test_host_plugin.py /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins tests/test_xmlrpc/test_host_plugin.py Failure: ImportError (cannot import name ipautil) ... ERROR ====================================================================== ERROR: Failure: ImportError (cannot import name ipautil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 390, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py", line 27, in from ipapython import ipautil File "/root/freeipa-master/ipapython/ipautil.py", line 52, in from ipalib import errors File "/root/freeipa-master/ipalib/__init__.py", line 930, in api.finalize() File "/root/freeipa-master/ipalib/plugable.py", line 674, in finalize self.__do_if_not_done('load_plugins') File "/root/freeipa-master/ipalib/plugable.py", line 454, in __do_if_not_done getattr(self, name)() File "/root/freeipa-master/ipalib/plugable.py", line 613, in load_plugins self.import_plugins('ipalib') File "/root/freeipa-master/ipalib/plugable.py", line 655, in import_plugins __import__(fullname) File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in from ipalib import pkcs10 File "/root/freeipa-master/ipalib/pkcs10.py", line 24, in from ipapython import ipautil ImportError: cannot import name ipautil ---------------------------------------------------------------------- Ran 1 test in 0.002s FAILED (errors=1) ====================================================================== FAILED under '/usr/bin/python2.7' ** FAIL ** Martin From pspacek at redhat.com Mon Mar 11 15:58:28 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 Mar 2013 16:58:28 +0100 Subject: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling Message-ID: <513DFF24.40408@redhat.com> Hello list! My first patch for FreeIPA is attached :-) I managed to add new 389 DS plugin to build system, but the LDAP magic in installer and updater is too much for my brain. Could somebody show me how installer and updater should add new object to cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). This patch implements minimal necessary support for idnsSOASerial replication. I investigating more advanced techniques, but I still see problems with locking and so on. Anyway, this patch should be sufficient for now. Commit message: Add 389 DS plugin for special idnsSOASerial attribute handling Default value "1" is added to replicated idnsZone objects if idnsSOASerial attribute is missing. https://fedorahosted.org/freeipa/ticket/3347 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0118-Add-389-DS-plugin-for-special-idnsSOASerial-attribut.patch Type: text/x-patch Size: 10326 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 11 16:00:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Mar 2013 12:00:30 -0400 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <5139D860.5080507@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> Message-ID: <513DFF9E.6090404@redhat.com> Petr Viktorin wrote: > On 03/07/2013 08:27 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>> [...] >>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>> itself. >>>>> I didn't test everything as I didn't get the access. >>>> >>>> It shouldn't make a difference. What isn't working? >>> >>> I get a CRITICAL message in the log: >>> >>> add aci: >>> (targetattr=dnaNextRange || dnaNextValue || >>> dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) >>> groupdn = "ldap:///cn=Modify DNA >>> Range,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) >>> >>> >>> >>> modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config" >>> >>> 2013-03-07T11:01:48Z DEBUG stderr=ldap_initialize( >>> ldap://vm-081.idm.lab.eng.brq.redhat.com:389/??base ) >>> ldap_modify: No such object (32) >>> >>> 2013-03-07T11:01:48Z CRITICAL Failed to load replica-acis.ldif: Command >>> '/usr/bin/ldapmodify -v -f /tmp/tmpT55upM -H >>> ldap://vm-081.idm.lab.eng.brq.redhat.com:389 -x -D cn=Directory Manager >>> -y /tmp/tmplFeere' returned non-zero exit status 32 >>> >> >> Gotcha. I moved where the replica acis are loaded. > > Please attach the patch :) > > [...] >>>>>> + failed = 0 >>>>>> + for ent in entries: >>>>> >>>>> >>>>> This loops more than necessary and is somewhat hard to follow. >>>>> Consider >>>>> using for-else here: >>>>> >>>>> for ...: >>>>> ... >>>>> if okay: >>>>> break >>>>> else: >>>>> raise error >>>> >>>> I simplified things a bit but a for/else won't work here as we need to >>>> check all ranges all the time. It is perfectly fine to not fit into a >>>> range, as long as it fits into SOME range. >>> >>> Well, that's how for's (not if's) else clause works -- it's executed >>> after all the looping's done if you didn't `break` out. >>> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops >>> >>> >>> >>> Maybe I'm just used to it and it's too esoteric to the average reader, >>> though. >> >> Thanks for the vote of confidence. Like I said, I wanted it to check all >> the ranges. A for/else quits on the break, which I guess is really >> probably ok assuming we trust that nothing else is going to stuff bad >> ranges in. I can go ahead and make the change. > > Your code also breaks out as soon as a good range is found. > Anyway this is a small nitpick; the loop works fine as it is. > >>> [...] >>>> Ok, I'll drop this since it doesn't affect things with the new LDAP >>>> backend. >>> >>> Please do, you left it in by mistake. >> >> Yeah, there it is sitting unsquashed in my tree :-( > > >>>> I also added one change related to the LDAP core changes. In the >>>> past if >>>> you did not have a ticket it would prompt for DM password. This was >>>> broken after the updates. I added an additional except in >>>> test_connection(). >>> >>> This should also be fixed soon in ipaldap. Thanks for putting up with >>> the changes. >>> >> >> So should I drop this in my patch then? I don't really like having to >> import ldap. > > You can if you're fine with waiting until my patches are pushed. > Otherwise it's covered by https://fedorahosted.org/freeipa/ticket/3499 > I left it in for now. Updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1088-4-dnarange.patch Type: text/x-diff Size: 30356 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 11 16:09:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Mar 2013 17:09:52 +0100 Subject: [Freeipa-devel] [PATCH] 0186 Change DNA magic value to -1 to make UID 999 usable In-Reply-To: <51275376.8020509@redhat.com> References: <51274569.3000700@redhat.com> <51275376.8020509@redhat.com> Message-ID: <513E01D0.7010209@redhat.com> On 02/22/2013 12:16 PM, Petr Viktorin wrote: > On 02/22/2013 11:16 AM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/2886 >> >> This changes the DNA magic value to -1, and the corresponding IPA's >> parameters (gidnumber, uidnumber) to be optional (instead of autofill). >> >> Since the old clients still say "999" when they mean "pick one I don't >> care", we need to detect them and change 999 to -1. For that there's a >> new capability, optional_uid_params. >> >> >> Behavior summary: >> >> With --uid 999: >> old client, old server: sends 999, creates random UID >> old client, new server: sends 999, creates random UID >> new client, old server: incompatible >> new client, new server: sends 999, creates UID 999 >> >> Without --uid: >> old client, old server: sends 999, creates random UID >> old client, new server: sends 999, creates random UID >> new client, old server: incompatible >> new client, new server: doesn't send UID, creates random UID >> >> Upgrade should work fine. >> >> I didn't test winsync as I don't have a Windows machine. >> > > The patch is here > Works like a charm for both old clients and the new ones. ACK, pushed to master. Martin From rcritten at redhat.com Mon Mar 11 21:07:08 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Mar 2013 17:07:08 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin Message-ID: <513E477C.6050505@redhat.com> Fixed a number of issues applying password policy against LDAP binds. See patch for details. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-lockout.patch Type: text/x-diff Size: 4195 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 12 09:10:08 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 12 Mar 2013 10:10:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513DE275.40709@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> <513DD2A1.7080409@redhat.com> <513DE275.40709@redhat.com> Message-ID: <513EF0F0.1010809@redhat.com> On 03/11/2013 02:56 PM, Martin Kosek wrote: > On 03/11/2013 01:48 PM, Jan Cholasta wrote: >> On 11.3.2013 13:43, Petr Viktorin wrote: >>> On 03/11/2013 01:13 PM, Jan Cholasta wrote: >>>> On 8.3.2013 14:14, Petr Viktorin wrote: >>>>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>>>> Patch 191: >>>>>> >>>>>> The patch is missing the ipapython/ipaldap.py file. >>>> >>>> On 7.3.2013 18:29, Petr Viktorin wrote: >>>> > It's there, it's just copied from ipaserver/ipaldap.py with a small >>>> > change at the bottom. >>>> >>>> There is no sign of the file, except in the patch header and the patch >>>> cannot be applied with git am nor with git apply. But perhaps I'm doing >>>> something wrong. >>> >>> Attaching a re-formatted version of the patch. >>> >>> [...] >>>> ACK. >>>> >>>> Honza >>>> >>> >>> >> >> ACK for real. >> >> Honza >> > > I would not want to rush this, I still see errors: > > 1) ipa-ldap-updater is broken: > > # ipa-ldap-updater --upgrade > Upgrading IPA: > [1/8]: stopping directory server > [2/8]: saving configuration > [3/8]: disabling listeners > [4/8]: starting directory server > [5/8]: upgrading server > Upgrade failed with 'NameSpace' object has no attribute 'ldap2' > [6/8]: stopping directory server > [7/8]: restoring configuration > [8/8]: starting directory server > Done. > IPA upgrade failed. Thanks for the catch! This is a symptom of the fact the plugins attach themselves to the default API object as soon as they're imported. Before, ipaldap imported ldap2, so the ldap2 server plugin was magically available whenever ipaldap was imported before. Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be available. > 2) What's the purpose of this new error? > > +class DatabaseTimeout(DatabaseError): > + """ > + **4211** Raised when an LDAP call times out > + > + For example: > + > + >>> raise DatabaseTimeout() > + Traceback (most recent call last): > + ... > + DatabaseTimeout: LDAP timeout > + """ > + > + errno = 4211 > + format = _('LDAP timeout') Thanks for this catch too, I mis-squashed the code to raise it. > It is not raised anywhere (as far as I can see). BTW I assume it is not > related to errors.LimitsExceeded in any way, right? No, it's timeout in the client?server communication rather than the LDAP operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED. > 3) Client installation no longer works if the server has disabled > anonymous authentication: > > # ipa-client-install > Error checking LDAP: Inappropriate authentication: Anonymous access is > not allowed. > DNS discovery failed to determine your DNS domain > Provide the domain name of your IPA server (ex: example.com): ^C I couldn't reproduce this. But I did find some misleading log messages in this case. It work well now. > 4) I suddenly cannot run some tests, looks like import loop: > > # ./make-test tests/test_xmlrpc/test_host_plugin.py > /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins > tests/test_xmlrpc/test_host_plugin.py > Failure: ImportError (cannot import name ipautil) ... ERROR > > ====================================================================== > ERROR: Failure: ImportError (cannot import name ipautil) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/loader.py", line 390, in > loadTestsFromName > addr.filename, addr.module) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 39, in > importFromPath > return self.importFromDir(dir_path, fqname) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 86, in > importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File "/root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py", > line 27, in > from ipapython import ipautil > File "/root/freeipa-master/ipapython/ipautil.py", line 52, in > from ipalib import errors > File "/root/freeipa-master/ipalib/__init__.py", line 930, in > api.finalize() > File "/root/freeipa-master/ipalib/plugable.py", line 674, in finalize > self.__do_if_not_done('load_plugins') > File "/root/freeipa-master/ipalib/plugable.py", line 454, in > __do_if_not_done > getattr(self, name)() > File "/root/freeipa-master/ipalib/plugable.py", line 613, in > load_plugins > self.import_plugins('ipalib') > File "/root/freeipa-master/ipalib/plugable.py", line 655, in > import_plugins > __import__(fullname) > File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in > from ipalib import pkcs10 > File "/root/freeipa-master/ipalib/pkcs10.py", line 24, in > from ipapython import ipautil > ImportError: cannot import name ipautil Gasp... I have no idea how we didn't catch this earlier. Simplifying a bit, it's partly due to the fact that ipalib does a lot of work on import in __init__ -- including loading plugins that assume ipalib's already set up. I've deferred the import, and added a FIXME. Thank you for retesting! Updated patches attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0191.3-Move-ipaldap-to-ipapython.patch Type: text/x-patch Size: 140395 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0192.3-Remove-ipaserver-ipaldap.py.patch Type: text/x-patch Size: 12374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0193.3-Use-IPAdmin-rather-than-raw-python-ldap-in-ipa-clien.patch Type: text/x-patch Size: 6690 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0194.3-Use-IPAdmin-rather-than-raw-python-ldap-in-migration.patch Type: text/x-patch Size: 20118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0195.3-Remove-unneeded-python-ldap-imports.patch Type: text/x-patch Size: 11302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0196.3-Don-t-download-the-schema-in-ipadiscovery.patch Type: text/x-patch Size: 1257 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 12 09:13:47 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Mar 2013 10:13:47 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513A3774.1060101@redhat.com> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <513A07A4.9030302@redhat.com> <513A255F.7030500@redhat.com> <513A3774.1060101@redhat.com> Message-ID: <513EF1CB.8040902@redhat.com> On 8.3.2013 20:09, Rob Crittenden wrote: > Petr Spacek wrote: >> On 8.3.2013 16:45, Rob Crittenden wrote: >>> One would need to pass in the object type they are dealing with: >>> >>> ipa krbflags --type=user --ok-as-delegate=false sbose >>> ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com >>> >>> We *could* avoid type potentially but it would expand our search base >>> and >>> could slow things down with lots of entries. >> Correct me if I'm wrong, but our KDC driver usually does sub-tree search >> with base dc=example,dc=com. (Except some special cases.) Or not? :-) > > Yes but when we do that search we've got a full principal. > > Consider the host plugin. If we are given a non-fully-qualified hostname > we add the IPA domain by default when looking for things. > > It is not uncommon for people to name their laptop after themselves. > > So if we are told to add a flag to the pspacek principal, which one is > it? The user pspacek or the host pspacek.example.com? Or we could > require that hostnames are fully-qualified, it would just be a > difference from other plugins. > > >> > We could search on the accounts >>> container using (objectclass=ipaKrbPrincipal) and >>> (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or >>> something like >>> that. I think I'd prefer specifying a type to avoid the case where >>> someone has >>> a hostname the same as a uid (we typically allow specifying non-fqdn >>> when >>> managing hosts). >> Would it be possible define some reasonable default value for "--type"? >> I don't like typing "--service" all the time ... >> > > Maybe, if we can assume what type of principal is most likely to be > updated. Remember that the host/ principal is stored in a host, not a > service record. > > Then again, I don't know how often one is going to be adding flags to > principals, so perhaps a required switch wouldn't be too onerous. Since the plugin would be used to manage Kerberos specifics, I think it is fair to require a valid principal as the argument. So it's either or host/ (or /), there's no ambiguity in that and no --type option is required. If you insist on using arbitrary names, I think we better do this in user/host/service plugins, as suggested originally. Setting PAC type is done in the usual place in service plugin after all, even when it is Kerberos-specific. > > rob > Honza -- Jan Cholasta From pspacek at redhat.com Tue Mar 12 09:21:04 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Mar 2013 10:21:04 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513EF1CB.8040902@redhat.com> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <513A07A4.9030302@redhat.com> <513A255F.7030500@redhat.com> <513A3774.1060101@redhat.com> <513EF1CB.8040902@redhat.com> Message-ID: <513EF380.90807@redhat.com> On 12.3.2013 10:13, Jan Cholasta wrote: > On 8.3.2013 20:09, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 8.3.2013 16:45, Rob Crittenden wrote: >>>> One would need to pass in the object type they are dealing with: >>>> >>>> ipa krbflags --type=user --ok-as-delegate=false sbose >>>> ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com >>>> >>>> We *could* avoid type potentially but it would expand our search base >>>> and >>>> could slow things down with lots of entries. >>> Correct me if I'm wrong, but our KDC driver usually does sub-tree search >>> with base dc=example,dc=com. (Except some special cases.) Or not? :-) >> >> Yes but when we do that search we've got a full principal. >> >> Consider the host plugin. If we are given a non-fully-qualified hostname >> we add the IPA domain by default when looking for things. >> >> It is not uncommon for people to name their laptop after themselves. >> >> So if we are told to add a flag to the pspacek principal, which one is >> it? The user pspacek or the host pspacek.example.com? Or we could >> require that hostnames are fully-qualified, it would just be a >> difference from other plugins. >> >> >>> > We could search on the accounts >>>> container using (objectclass=ipaKrbPrincipal) and >>>> (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or >>>> something like >>>> that. I think I'd prefer specifying a type to avoid the case where >>>> someone has >>>> a hostname the same as a uid (we typically allow specifying non-fqdn >>>> when >>>> managing hosts). >>> Would it be possible define some reasonable default value for "--type"? >>> I don't like typing "--service" all the time ... >>> >> >> Maybe, if we can assume what type of principal is most likely to be >> updated. Remember that the host/ principal is stored in a host, not a >> service record. >> >> Then again, I don't know how often one is going to be adding flags to >> principals, so perhaps a required switch wouldn't be too onerous. > > Since the plugin would be used to manage Kerberos specifics, I think it is > fair to require a valid principal as the argument. So it's either or > host/ (or /), there's no ambiguity in that and no --type > option is required. +1 > If you insist on using arbitrary names, I think we better do this in > user/host/service plugins, as suggested originally. Setting PAC type is done > in the usual place in service plugin after all, even when it is > Kerberos-specific. -- Petr^2 Spacek From jcholast at redhat.com Tue Mar 12 09:23:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Mar 2013 10:23:12 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1362750086.2822.113.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> Message-ID: <513EF400.4030408@redhat.com> On 8.3.2013 14:41, Simo Sorce wrote: > On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: >> Hi, >> >> On 7.3.2013 21:15, Rob Crittenden wrote: >>> Based on a comment from Sumit in ticket >>> https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of >>> how one might do it: http://freeipa.org/page/V3/Kerberos_Flags >> >> Can we have one multi-valued attribute which contains names of flags to >> set instead of one attribute per flag? It might make adding new flags >> easier. > > if you are cramming everything in one attribute then we can keep using > krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. > >> Would it make sense to add a global configuration option to turn flags >> on or off for all services of a given type? > > We might, but how do you check for the global value ? > An additional search for every KDC operation is simply not going to > happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. > > Simo. > Honza -- Jan Cholasta From mkosek at redhat.com Tue Mar 12 09:40:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Mar 2013 10:40:06 +0100 Subject: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling In-Reply-To: <513DFF24.40408@redhat.com> References: <513DFF24.40408@redhat.com> Message-ID: <513EF7F6.9030903@redhat.com> On 03/11/2013 04:58 PM, Petr Spacek wrote: > Hello list! > > My first patch for FreeIPA is attached :-) > > I managed to add new 389 DS plugin to build system, but the LDAP magic in > installer and updater is too much for my brain. > > Could somebody show me how installer and updater should add new object to > cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). > > This patch implements minimal necessary support for idnsSOASerial replication. > I investigating more advanced techniques, but I still see problems with locking > and so on. > > Anyway, this patch should be sufficient for now. > > Commit message: > > Add 389 DS plugin for special idnsSOASerial attribute handling > > Default value "1" is added to replicated idnsZone objects > if idnsSOASerial attribute is missing. > > https://fedorahosted.org/freeipa/ticket/3347 > I did not review the actual plugin yet, I just added a code to configure this plugin during new install and upgrade. Patch attached. Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copy&paste errors: +libipa_uuid_la_LIBADD = \ <<< libipa_uuid?? + $(LDAP_LIBS) \ + $(UUID_LIBS) \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ <<< not defined, not needed (I will add it in my patch) + $(NULL) + Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-384-configure-ipa_dns-ds-plugin-on-install-and-upgrade.patch Type: text/x-patch Size: 5053 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 12 11:51:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 12 Mar 2013 12:51:47 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <513DFF9E.6090404@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> <513DFF9E.6090404@redhat.com> Message-ID: <513F16D3.8070300@redhat.com> On 03/11/2013 05:00 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/07/2013 08:27 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>> [...] >>>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>>> itself. >>>>>> I didn't test everything as I didn't get the access. >>>>> [...] >>> Gotcha. I moved where the replica acis are loaded. Thanks! Everything works now, I just found two issues in error reporting. I set up three masters like this: $ ipa-replica-manage dnarange-show vm-084.idm.lab.eng.brq.redhat.com: 1109050002-1109099999 vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999 vm-079.idm.lab.eng.brq.redhat.com: 1109025001-1109049999 $ ipa-replica-manage dnanextrange-show vm-084.idm.lab.eng.brq.redhat.com: 1109000000-1109012499 vm-081.idm.lab.eng.brq.redhat.com: 1109190000-1109190001 vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set vm-079 is git master, the other two have the patch applied. Now when I deleted vm-081, there was no indication which ranges I lost: vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.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 Deleting replication agreements between vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com ipa: INFO: Setting agreement cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com: Insufficient access: Insufficient 'write' privilege to the 'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config'. Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com' Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com' to 'vm-081.idm.lab.eng.brq.redhat.com' Background task created to clean replication data. This may take a while. This may be safely interrupted with Ctrl+C One more detail: Ranges where start==end are invalid. We should fail the same way as for start>end. $ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com 677100401-677100401 ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid DNA configuration.', 'desc': 'Server is unwilling to perform'} Updating next range failed: Server is unwilling to perform: Changes result in an invalid DNA configuration. -- Petr? From rcritten at redhat.com Tue Mar 12 12:12:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Mar 2013 08:12:30 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513EF1CB.8040902@redhat.com> References: <5138F556.8020504@redhat.com> <20130308092746.GJ16010@localhost.localdomain> <513A07A4.9030302@redhat.com> <513A255F.7030500@redhat.com> <513A3774.1060101@redhat.com> <513EF1CB.8040902@redhat.com> Message-ID: <513F1BAE.6080507@redhat.com> Jan Cholasta wrote: > On 8.3.2013 20:09, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 8.3.2013 16:45, Rob Crittenden wrote: >>>> One would need to pass in the object type they are dealing with: >>>> >>>> ipa krbflags --type=user --ok-as-delegate=false sbose >>>> ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com >>>> >>>> We *could* avoid type potentially but it would expand our search base >>>> and >>>> could slow things down with lots of entries. >>> Correct me if I'm wrong, but our KDC driver usually does sub-tree search >>> with base dc=example,dc=com. (Except some special cases.) Or not? :-) >> >> Yes but when we do that search we've got a full principal. >> >> Consider the host plugin. If we are given a non-fully-qualified hostname >> we add the IPA domain by default when looking for things. >> >> It is not uncommon for people to name their laptop after themselves. >> >> So if we are told to add a flag to the pspacek principal, which one is >> it? The user pspacek or the host pspacek.example.com? Or we could >> require that hostnames are fully-qualified, it would just be a >> difference from other plugins. >> >> >>> > We could search on the accounts >>>> container using (objectclass=ipaKrbPrincipal) and >>>> (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or >>>> something like >>>> that. I think I'd prefer specifying a type to avoid the case where >>>> someone has >>>> a hostname the same as a uid (we typically allow specifying non-fqdn >>>> when >>>> managing hosts). >>> Would it be possible define some reasonable default value for "--type"? >>> I don't like typing "--service" all the time ... >>> >> >> Maybe, if we can assume what type of principal is most likely to be >> updated. Remember that the host/ principal is stored in a host, not a >> service record. >> >> Then again, I don't know how often one is going to be adding flags to >> principals, so perhaps a required switch wouldn't be too onerous. > > Since the plugin would be used to manage Kerberos specifics, I think it > is fair to require a valid principal as the argument. So it's either > or host/ (or /), there's no ambiguity in > that and no --type option is required. > > If you insist on using arbitrary names, I think we better do this in > user/host/service plugins, as suggested originally. Setting PAC type is > done in the usual place in service plugin after all, even when it is > Kerberos-specific. I cam to the same conclusion and updated the proposal yesterday this way. rob From mkosek at redhat.com Tue Mar 12 12:37:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Mar 2013 13:37:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513EF0F0.1010809@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> <513DD2A1.7080409@redhat.com> <513DE275.40709@redhat.com> <513EF0F0.1010809@redhat.com> Message-ID: <513F218A.8020603@redhat.com> On 03/12/2013 10:10 AM, Petr Viktorin wrote: > On 03/11/2013 02:56 PM, Martin Kosek wrote: >> On 03/11/2013 01:48 PM, Jan Cholasta wrote: >>> On 11.3.2013 13:43, Petr Viktorin wrote: >>>> On 03/11/2013 01:13 PM, Jan Cholasta wrote: >>>>> On 8.3.2013 14:14, Petr Viktorin wrote: >>>>>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>>>>> Patch 191: >>>>>>> >>>>>>> The patch is missing the ipapython/ipaldap.py file. >>>>> >>>>> On 7.3.2013 18:29, Petr Viktorin wrote: >>>>> > It's there, it's just copied from ipaserver/ipaldap.py with a small >>>>> > change at the bottom. >>>>> >>>>> There is no sign of the file, except in the patch header and the patch >>>>> cannot be applied with git am nor with git apply. But perhaps I'm doing >>>>> something wrong. >>>> >>>> Attaching a re-formatted version of the patch. >>>> >>>> [...] >>>>> ACK. >>>>> >>>>> Honza >>>>> >>>> >>>> >>> >>> ACK for real. >>> >>> Honza >>> >> >> I would not want to rush this, I still see errors: >> >> 1) ipa-ldap-updater is broken: >> >> # ipa-ldap-updater --upgrade >> Upgrading IPA: >> [1/8]: stopping directory server >> [2/8]: saving configuration >> [3/8]: disabling listeners >> [4/8]: starting directory server >> [5/8]: upgrading server >> Upgrade failed with 'NameSpace' object has no attribute 'ldap2' >> [6/8]: stopping directory server >> [7/8]: restoring configuration >> [8/8]: starting directory server >> Done. >> IPA upgrade failed. > > Thanks for the catch! > > This is a symptom of the fact the plugins attach themselves to the default API > object as soon as they're imported. > Before, ipaldap imported ldap2, so the ldap2 server plugin was magically > available whenever ipaldap was imported before. > Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be > available. > >> 2) What's the purpose of this new error? >> >> +class DatabaseTimeout(DatabaseError): >> + """ >> + **4211** Raised when an LDAP call times out >> + >> + For example: >> + >> + >>> raise DatabaseTimeout() >> + Traceback (most recent call last): >> + ... >> + DatabaseTimeout: LDAP timeout >> + """ >> + >> + errno = 4211 >> + format = _('LDAP timeout') > > Thanks for this catch too, I mis-squashed the code to raise it. > >> It is not raised anywhere (as far as I can see). BTW I assume it is not >> related to errors.LimitsExceeded in any way, right? > > No, it's timeout in the client?server communication rather than the LDAP > operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED. > >> 3) Client installation no longer works if the server has disabled >> anonymous authentication: >> >> # ipa-client-install >> Error checking LDAP: Inappropriate authentication: Anonymous access is >> not allowed. >> DNS discovery failed to determine your DNS domain >> Provide the domain name of your IPA server (ex: example.com): ^C > > I couldn't reproduce this. But I did find some misleading log messages in this > case. It work well now. > >> 4) I suddenly cannot run some tests, looks like import loop: >> >> # ./make-test tests/test_xmlrpc/test_host_plugin.py >> /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins >> tests/test_xmlrpc/test_host_plugin.py >> Failure: ImportError (cannot import name ipautil) ... ERROR >> >> ====================================================================== >> ERROR: Failure: ImportError (cannot import name ipautil) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 390, in >> loadTestsFromName >> addr.filename, addr.module) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 39, in >> importFromPath >> return self.importFromDir(dir_path, fqname) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 86, in >> importFromDir >> mod = load_module(part_fqname, fh, filename, desc) >> File "/root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py", >> line 27, in >> from ipapython import ipautil >> File "/root/freeipa-master/ipapython/ipautil.py", line 52, in >> from ipalib import errors >> File "/root/freeipa-master/ipalib/__init__.py", line 930, in >> api.finalize() >> File "/root/freeipa-master/ipalib/plugable.py", line 674, in finalize >> self.__do_if_not_done('load_plugins') >> File "/root/freeipa-master/ipalib/plugable.py", line 454, in >> __do_if_not_done >> getattr(self, name)() >> File "/root/freeipa-master/ipalib/plugable.py", line 613, in >> load_plugins >> self.import_plugins('ipalib') >> File "/root/freeipa-master/ipalib/plugable.py", line 655, in >> import_plugins >> __import__(fullname) >> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >> from ipalib import pkcs10 >> File "/root/freeipa-master/ipalib/pkcs10.py", line 24, in >> from ipapython import ipautil >> ImportError: cannot import name ipautil > > Gasp... I have no idea how we didn't catch this earlier. > Simplifying a bit, it's partly due to the fact that ipalib does a lot of work > on import in __init__ -- including loading plugins that assume ipalib's already > set up. > > I've deferred the import, and added a FIXME. > > > Thank you for retesting! > Updated patches attached. > I tested our basic scenarios and everything seems to work fine, so I think we can push this soon if no one objects. I just hit two more places in the patch set which look suspicious: 1) In 193.3, one more unexpected raise: except Exception, e: - root_logger.debug("get_ca_cert_from_ldap() error: %s", - convert_ldap_error(e)) + raise + root_logger.debug("get_ca_cert_from_ldap() error: %s", e) 2) In 194.3, redundant section: + try: + self.__wait_for_connection(timeout) + except: + raise Martin From simo at redhat.com Tue Mar 12 12:34:33 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Mar 2013 08:34:33 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513EF400.4030408@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> Message-ID: <1363091673.2822.166.camel@willson.li.ssimo.org> On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: > On 8.3.2013 14:41, Simo Sorce wrote: > > On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: > >> Hi, > >> > >> On 7.3.2013 21:15, Rob Crittenden wrote: > >>> Based on a comment from Sumit in ticket > >>> https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > >>> how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > >> > >> Can we have one multi-valued attribute which contains names of flags to > >> set instead of one attribute per flag? It might make adding new flags > >> easier. > > > > if you are cramming everything in one attribute then we can keep using > > krbExtraData, no ? > > I'm not sure if that can be done from Python. > > Can we use krbTicketFlags for this? Support for this attribute is > already in ipa-kdb and I have checked that setting it to the right value > results in tickets with OK_AS_DELEGATE set. > > > > >> Would it make sense to add a global configuration option to turn flags > >> on or off for all services of a given type? > > > > We might, but how do you check for the global value ? > > An additional search for every KDC operation is simply not going to > > happen. > > Can we do that extra search only when the KDC is initialized and when > configuration is refreshed? I don't think the default values would > change too often, so this might be OK. How do you know when the configuration changes ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Mar 12 14:14:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Mar 2013 15:14:23 +0100 Subject: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab In-Reply-To: <5139EF49.50308@redhat.com> References: <5134D97A.8030406@redhat.com> <5135EEB9.6020705@redhat.com> <513730CF.3010904@redhat.com> <5138AE57.5010107@redhat.com> <5138B1F4.4060002@redhat.com> <5138B81A.4060700@redhat.com> <51390E3D.6090305@redhat.com> <5139EF49.50308@redhat.com> Message-ID: <513F383F.7060704@redhat.com> On 03/08/2013 03:01 PM, Tomas Babej wrote: > On Thu 07 Mar 2013 11:01:33 PM CET, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/07/2013 04:27 PM, Tomas Babej wrote: >>>> On 03/07/2013 04:12 PM, Petr Viktorin wrote: >>>>> Thanks! I just have two more very minor nitpicks. >>>>> >>>>> On 03/06/2013 01:04 PM, Tomas Babej wrote: >>>>>> On 03/05/2013 02:10 PM, Petr Viktorin wrote: >>>>>>> Thanks! The mechanism works, but see below. >>>>>>> >>>>>>> This is a RFE so it needs a design document. >>>>>>> >>>>>> http://freeipa.org/page/V3/Client_install_using_keytab >>>>> >>>>> Please also add the link to the commit message. >>>>> >>>>> >>>>> I think you answered Petr?'s security questions adequately. >>>>> Petr, note that this is a client-side change; if the keytab is >>>>> compromised the attacker can do all this manually anyway. >>>>> >>>>>> diff --git a/ipa-client/ipa-install/ipa-client-install >>>>>> b/ipa-client/ipa-install/ipa-client-install >>>>>> index >>>>>> 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b >>>>>> >>>>>> >>>>>> >>>>>> 100755 >>>>>> --- a/ipa-client/ipa-install/ipa-client-install >>>>>> +++ b/ipa-client/ipa-install/ipa-client-install >>>>>> @@ -104,6 +104,8 @@ def parse_options(): >>>>> [...] >>>>>> @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): >>>>>> except ipaclient.ntpconf.NTPConfigurationError: >>>>>> pass >>>>>> >>>>>> - if options.unattended and (options.password is None and >>>>>> options.principal is None and options.prompt_password is False) and >>>>>> not options.on_master: >>>>>> - root_logger.error("One of password and principal are >>>>>> required.") >>>>>> + if options.unattended and ((options.password is None and >>>>>> + options.principal is None and >>>>>> + options.keytab is None and >>>>>> + options.prompt_password is False)\ >>>>>> + and not options.on_master): >>>>> >>>>> Please also remove the inner parentheses and the backslash. >>>>> >>>> Both fixed, updated patch attached. >>>> >>>> Tomas >>> >>> ACK, thanks! >>> >> >> This needs related man page updates before we can push it. >> > > Man pages updated: > > [tbabej at thinkpad7 freeipa]$ git diff > diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-ins > [...] > +\fB\-k\fR, \fB\-\-keytab\fR > +Path to backed up host keytab from previous enrollment. > +.TP > [...] > diff --git a/ipa-client/man/ipa-join.1 b/ipa-client/man/ipa-join.1 > [...] > +\fB\-f,\-\-force\fR > +Force enrolling the host even if host entry exists. > +.TP > >> Can you update the design to specifically include that the old >> certificate needs to be revoked, not just that a new certificate be >> issued (sort of implied, and it worked in my testing)? > > I updated the design page accordingly. However, shouldn't be this handled by > server side automatically? > >> rob > > Updated patch attached. > I see the requested man page is there, the patches look OK now. Thus, second ACK, pushed to master. Martin From pspacek at redhat.com Tue Mar 12 14:31:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Mar 2013 15:31:33 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1363091673.2822.166.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> Message-ID: <513F3C45.4040206@redhat.com> On 12.3.2013 13:34, Simo Sorce wrote: >>> > >We might, but how do you check for the global value ? >>> > >An additional search for every KDC operation is simply not going to >>> > >happen. >> > >> >Can we do that extra search only when the KDC is initialized and when >> >configuration is refreshed? I don't think the default values would >> >change too often, so this might be OK. > How do you know when the configuration changes ? Persistent search? -- Petr^2 Spacek From pviktori at redhat.com Tue Mar 12 14:34:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 12 Mar 2013 15:34:45 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513F218A.8020603@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> <513DD2A1.7080409@redhat.com> <513DE275.40709@redhat.com> <513EF0F0.1010809@redhat.com> <513F218A.8020603@redhat.com> Message-ID: <513F3D05.5090500@redhat.com> On 03/12/2013 01:37 PM, Martin Kosek wrote: > On 03/12/2013 10:10 AM, Petr Viktorin wrote: >> On 03/11/2013 02:56 PM, Martin Kosek wrote: >>> On 03/11/2013 01:48 PM, Jan Cholasta wrote: >>>> On 11.3.2013 13:43, Petr Viktorin wrote: >>>>> On 03/11/2013 01:13 PM, Jan Cholasta wrote: >>>>>> On 8.3.2013 14:14, Petr Viktorin wrote: >>>>>>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>>>>>> Patch 191: >>>>>>>> >>>>>>>> The patch is missing the ipapython/ipaldap.py file. >>>>>> >>>>>> On 7.3.2013 18:29, Petr Viktorin wrote: >>>>>> > It's there, it's just copied from ipaserver/ipaldap.py with a small >>>>>> > change at the bottom. >>>>>> >>>>>> There is no sign of the file, except in the patch header and the patch >>>>>> cannot be applied with git am nor with git apply. But perhaps I'm doing >>>>>> something wrong. >>>>> >>>>> Attaching a re-formatted version of the patch. >>>>> >>>>> [...] >>>>>> ACK. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> >>>> >>>> ACK for real. >>>> >>>> Honza >>>> >>> >>> I would not want to rush this, I still see errors: >>> >>> 1) ipa-ldap-updater is broken: >>> >>> # ipa-ldap-updater --upgrade >>> Upgrading IPA: >>> [1/8]: stopping directory server >>> [2/8]: saving configuration >>> [3/8]: disabling listeners >>> [4/8]: starting directory server >>> [5/8]: upgrading server >>> Upgrade failed with 'NameSpace' object has no attribute 'ldap2' >>> [6/8]: stopping directory server >>> [7/8]: restoring configuration >>> [8/8]: starting directory server >>> Done. >>> IPA upgrade failed. >> >> Thanks for the catch! >> >> This is a symptom of the fact the plugins attach themselves to the default API >> object as soon as they're imported. >> Before, ipaldap imported ldap2, so the ldap2 server plugin was magically >> available whenever ipaldap was imported before. >> Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be >> available. >> >>> 2) What's the purpose of this new error? >>> >>> +class DatabaseTimeout(DatabaseError): >>> + """ >>> + **4211** Raised when an LDAP call times out >>> + >>> + For example: >>> + >>> + >>> raise DatabaseTimeout() >>> + Traceback (most recent call last): >>> + ... >>> + DatabaseTimeout: LDAP timeout >>> + """ >>> + >>> + errno = 4211 >>> + format = _('LDAP timeout') >> >> Thanks for this catch too, I mis-squashed the code to raise it. >> >>> It is not raised anywhere (as far as I can see). BTW I assume it is not >>> related to errors.LimitsExceeded in any way, right? >> >> No, it's timeout in the client?server communication rather than the LDAP >> operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED. >> >>> 3) Client installation no longer works if the server has disabled >>> anonymous authentication: >>> >>> # ipa-client-install >>> Error checking LDAP: Inappropriate authentication: Anonymous access is >>> not allowed. >>> DNS discovery failed to determine your DNS domain >>> Provide the domain name of your IPA server (ex: example.com): ^C >> >> I couldn't reproduce this. But I did find some misleading log messages in this >> case. It work well now. >> >>> 4) I suddenly cannot run some tests, looks like import loop: >>> >>> # ./make-test tests/test_xmlrpc/test_host_plugin.py >>> /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins >>> tests/test_xmlrpc/test_host_plugin.py >>> Failure: ImportError (cannot import name ipautil) ... ERROR >>> >>> ====================================================================== >>> ERROR: Failure: ImportError (cannot import name ipautil) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 390, in >>> loadTestsFromName >>> addr.filename, addr.module) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 39, in >>> importFromPath >>> return self.importFromDir(dir_path, fqname) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 86, in >>> importFromDir >>> mod = load_module(part_fqname, fh, filename, desc) >>> File "/root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py", >>> line 27, in >>> from ipapython import ipautil >>> File "/root/freeipa-master/ipapython/ipautil.py", line 52, in >>> from ipalib import errors >>> File "/root/freeipa-master/ipalib/__init__.py", line 930, in >>> api.finalize() >>> File "/root/freeipa-master/ipalib/plugable.py", line 674, in finalize >>> self.__do_if_not_done('load_plugins') >>> File "/root/freeipa-master/ipalib/plugable.py", line 454, in >>> __do_if_not_done >>> getattr(self, name)() >>> File "/root/freeipa-master/ipalib/plugable.py", line 613, in >>> load_plugins >>> self.import_plugins('ipalib') >>> File "/root/freeipa-master/ipalib/plugable.py", line 655, in >>> import_plugins >>> __import__(fullname) >>> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >>> from ipalib import pkcs10 >>> File "/root/freeipa-master/ipalib/pkcs10.py", line 24, in >>> from ipapython import ipautil >>> ImportError: cannot import name ipautil >> >> Gasp... I have no idea how we didn't catch this earlier. >> Simplifying a bit, it's partly due to the fact that ipalib does a lot of work >> on import in __init__ -- including loading plugins that assume ipalib's already >> set up. >> >> I've deferred the import, and added a FIXME. >> >> >> Thank you for retesting! >> Updated patches attached. >> > > I tested our basic scenarios and everything seems to work fine, so I think we > can push this soon if no one objects. I just hit two more places in the patch > set which look suspicious: > > 1) In 193.3, one more unexpected raise: > > except Exception, e: > - root_logger.debug("get_ca_cert_from_ldap() error: %s", > - convert_ldap_error(e)) > + raise > + root_logger.debug("get_ca_cert_from_ldap() error: %s", e) > > > 2) In 194.3, redundant section: > > + try: > + self.__wait_for_connection(timeout) > + except: > + raise > > Martin > Fixed, thanks. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0191.4-Move-ipaldap-to-ipapython.patch Type: text/x-patch Size: 140395 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0192.4-Remove-ipaserver-ipaldap.py.patch Type: text/x-patch Size: 12374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0193.4-Use-IPAdmin-rather-than-raw-python-ldap-in-ipa-clien.patch Type: text/x-patch Size: 6675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0194.4-Use-IPAdmin-rather-than-raw-python-ldap-in-migration.patch Type: text/x-patch Size: 19985 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0195.4-Remove-unneeded-python-ldap-imports.patch Type: text/x-patch Size: 11302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0196.4-Don-t-download-the-schema-in-ipadiscovery.patch Type: text/x-patch Size: 1257 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 12 14:38:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Mar 2013 15:38:33 +0100 Subject: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling In-Reply-To: <513EF7F6.9030903@redhat.com> References: <513DFF24.40408@redhat.com> <513EF7F6.9030903@redhat.com> Message-ID: <513F3DE9.2050900@redhat.com> On 12.3.2013 10:40, Martin Kosek wrote: > On 03/11/2013 04:58 PM, Petr Spacek wrote: >> Hello list! >> >> My first patch for FreeIPA is attached :-) >> >> I managed to add new 389 DS plugin to build system, but the LDAP magic in >> installer and updater is too much for my brain. >> >> Could somebody show me how installer and updater should add new object to >> cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). >> >> This patch implements minimal necessary support for idnsSOASerial replication. >> I investigating more advanced techniques, but I still see problems with locking >> and so on. >> >> Anyway, this patch should be sufficient for now. >> >> Commit message: >> >> Add 389 DS plugin for special idnsSOASerial attribute handling >> >> Default value "1" is added to replicated idnsZone objects >> if idnsSOASerial attribute is missing. >> >> https://fedorahosted.org/freeipa/ticket/3347 >> > > I did not review the actual plugin yet, I just added a code to configure this > plugin during new install and upgrade. Patch attached. > > > Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copy&paste > errors: > > > +libipa_uuid_la_LIBADD = \ <<< libipa_uuid?? > + $(LDAP_LIBS) \ > + $(UUID_LIBS) \ > + $(NULL) > + > > +EXTRA_DIST = \ > + $(app_DATA) \ <<< not defined, not needed (I will add it in my patch) > + $(NULL) > + Fixed version is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0001-2-Add-389-DS-plugin-for-special-idnsSOASerial-attribut.patch Type: text/x-patch Size: 10290 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 12 14:39:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Mar 2013 10:39:48 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F3C45.4040206@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> Message-ID: <513F3E34.9000400@redhat.com> Petr Spacek wrote: > On 12.3.2013 13:34, Simo Sorce wrote: >>>> > >We might, but how do you check for the global value ? >>>> > >An additional search for every KDC operation is simply not going to >>>> > >happen. >>> > >>> >Can we do that extra search only when the KDC is initialized and when >>> >configuration is refreshed? I don't think the default values would >>> >change too often, so this might be OK. >> How do you know when the configuration changes ? > Persistent search? > Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. rob From pspacek at redhat.com Tue Mar 12 14:55:55 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Mar 2013 15:55:55 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F3E34.9000400@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> Message-ID: <513F41FB.7030108@redhat.com> On 12.3.2013 15:39, Rob Crittenden wrote: > Petr Spacek wrote: >> On 12.3.2013 13:34, Simo Sorce wrote: >>>>> > >We might, but how do you check for the global value ? >>>>> > >An additional search for every KDC operation is simply not going to >>>>> > >happen. >>>> > >>>> >Can we do that extra search only when the KDC is initialized and when >>>> >configuration is refreshed? I don't think the default values would >>>> >change too often, so this might be OK. >>> How do you know when the configuration changes ? >> Persistent search? >> > > Well, this is where we might do well with a 389-ds plugin that monitors flag > changes so we can catch changes made directly by kadmin.local as well. This > would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). -- Petr^2 Spacek From rcritten at redhat.com Tue Mar 12 15:00:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Mar 2013 11:00:39 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F41FB.7030108@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> Message-ID: <513F4317.8010004@redhat.com> Petr Spacek wrote: > On 12.3.2013 15:39, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 12.3.2013 13:34, Simo Sorce wrote: >>>>>> > >We might, but how do you check for the global value ? >>>>>> > >An additional search for every KDC operation is simply not >>>>>> going to >>>>>> > >happen. >>>>> > >>>>> >Can we do that extra search only when the KDC is initialized and when >>>>> >configuration is refreshed? I don't think the default values would >>>>> >change too often, so this might be OK. >>>> How do you know when the configuration changes ? >>> Persistent search? >>> >> >> Well, this is where we might do well with a 389-ds plugin that >> monitors flag >> changes so we can catch changes made directly by kadmin.local as well. >> This >> would be similar to the password plugin in keeping several attributes >> in sync. > > I didn't understand your note about DS plugin. > > kadmin.local does all changes in LDAP, or not? All changes in LDAP DB > are sent via persistent search (if the persistent search was issued with > appropriate parameters). > Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. kadmin.local changes things in LDAP because we use our own backend driver. It doesn't speak LDAP natively. rob From sbose at redhat.com Tue Mar 12 15:03:49 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 12 Mar 2013 16:03:49 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1363091673.2822.166.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> Message-ID: <20130312150349.GT16010@localhost.localdomain> On Tue, Mar 12, 2013 at 08:34:33AM -0400, Simo Sorce wrote: > On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: > > On 8.3.2013 14:41, Simo Sorce wrote: > > > On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: > > >> Hi, > > >> > > >> On 7.3.2013 21:15, Rob Crittenden wrote: > > >>> Based on a comment from Sumit in ticket > > >>> https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of > > >>> how one might do it: http://freeipa.org/page/V3/Kerberos_Flags > > >> > > >> Can we have one multi-valued attribute which contains names of flags to > > >> set instead of one attribute per flag? It might make adding new flags > > >> easier. > > > > > > if you are cramming everything in one attribute then we can keep using > > > krbExtraData, no ? > > > > I'm not sure if that can be done from Python. > > > > Can we use krbTicketFlags for this? Support for this attribute is > > already in ipa-kdb and I have checked that setting it to the right value > > results in tickets with OK_AS_DELEGATE set. > > > > > > > >> Would it make sense to add a global configuration option to turn flags > > >> on or off for all services of a given type? > > > > > > We might, but how do you check for the global value ? > > > An additional search for every KDC operation is simply not going to > > > happen. > > > > Can we do that extra search only when the KDC is initialized and when > > configuration is refreshed? I don't think the default values would > > change too often, so this might be OK. > > How do you know when the configuration changes ? iirc Martin introduced a reload of the configuration if it is older than a certain time with the SID blacklist work. bye, Sumit > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Tue Mar 12 16:02:25 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Mar 2013 17:02:25 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F4317.8010004@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> Message-ID: <513F5191.5080807@redhat.com> On 12.3.2013 16:00, Rob Crittenden wrote: > Petr Spacek wrote: >> On 12.3.2013 15:39, Rob Crittenden wrote: >>> Petr Spacek wrote: >>>> On 12.3.2013 13:34, Simo Sorce wrote: >>>>>>> > >We might, but how do you check for the global value ? >>>>>>> > >An additional search for every KDC operation is simply not >>>>>>> going to >>>>>>> > >happen. >>>>>> > >>>>>> >Can we do that extra search only when the KDC is initialized and >>>>>> when >>>>>> >configuration is refreshed? I don't think the default values would >>>>>> >change too often, so this might be OK. >>>>> How do you know when the configuration changes ? >>>> Persistent search? >>>> >>> >>> Well, this is where we might do well with a 389-ds plugin that >>> monitors flag >>> changes so we can catch changes made directly by kadmin.local as well. >>> This >>> would be similar to the password plugin in keeping several attributes >>> in sync. >> >> I didn't understand your note about DS plugin. >> >> kadmin.local does all changes in LDAP, or not? All changes in LDAP DB >> are sent via persistent search (if the persistent search was issued with >> appropriate parameters). >> > > Let me step back and say I know next to nothing about how the KDB > backend works. > > What would be nice is one place to notice changes to these proposed > flags and the flag bitfield. Whether that is best done in the backend or > via a 389-ds plugin I don't know. So whatever we do, we need one place > to notice changes in either the flag(s) or bitfield and keep the values > in sync. Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) > > kadmin.local changes things in LDAP because we use our own backend > driver. It doesn't speak LDAP natively. > > rob > -- Jan Cholasta From simo at redhat.com Tue Mar 12 16:01:18 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Mar 2013 12:01:18 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F3C45.4040206@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> Message-ID: <1363104078.2822.179.camel@willson.li.ssimo.org> On Tue, 2013-03-12 at 15:31 +0100, Petr Spacek wrote: > On 12.3.2013 13:34, Simo Sorce wrote: > >>> > >We might, but how do you check for the global value ? > >>> > >An additional search for every KDC operation is simply not going to > >>> > >happen. > >> > > >> >Can we do that extra search only when the KDC is initialized and when > >> >configuration is refreshed? I don't think the default values would > >> >change too often, so this might be OK. > > How do you know when the configuration changes ? > Persistent search? No for 3 reasons. 1. Persistent searches are expensive for the server. 2. The KDC is not threaded so it has no way to react to data being sent down the pipe. It may accumulate for hours and then the KDC would be swamped processing all that data on the first request it gets from a client. 3. The KDC is configured to spawn multiple processes on multi-CPU machines, and that would mean tons of duplication with one persistent search per process, and the associated heavy load on DS would increase even more. We might have a dirty way to do something like this with inotify and a common file we agree upon to 'touch' from DS plugins. The the KDC would be able to reload the configuration only when inotify signals there is a change in the underlying file. It's not really elegant and will probably also require changes to the selinux policy but it would be less heavy weight. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Mar 12 16:24:33 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Mar 2013 12:24:33 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F5191.5080807@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> Message-ID: <1363105473.2822.183.camel@willson.li.ssimo.org> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: > On 12.3.2013 16:00, Rob Crittenden wrote: > > Petr Spacek wrote: > >> On 12.3.2013 15:39, Rob Crittenden wrote: > >>> Petr Spacek wrote: > >>>> On 12.3.2013 13:34, Simo Sorce wrote: > >>>>>>> > >We might, but how do you check for the global value ? > >>>>>>> > >An additional search for every KDC operation is simply not > >>>>>>> going to > >>>>>>> > >happen. > >>>>>> > > >>>>>> >Can we do that extra search only when the KDC is initialized and > >>>>>> when > >>>>>> >configuration is refreshed? I don't think the default values would > >>>>>> >change too often, so this might be OK. > >>>>> How do you know when the configuration changes ? > >>>> Persistent search? > >>>> > >>> > >>> Well, this is where we might do well with a 389-ds plugin that > >>> monitors flag > >>> changes so we can catch changes made directly by kadmin.local as well. > >>> This > >>> would be similar to the password plugin in keeping several attributes > >>> in sync. > >> > >> I didn't understand your note about DS plugin. > >> > >> kadmin.local does all changes in LDAP, or not? All changes in LDAP DB > >> are sent via persistent search (if the persistent search was issued with > >> appropriate parameters). > >> > > > > Let me step back and say I know next to nothing about how the KDB > > backend works. > > > > What would be nice is one place to notice changes to these proposed > > flags and the flag bitfield. Whether that is best done in the backend or > > via a 389-ds plugin I don't know. So whatever we do, we need one place > > to notice changes in either the flag(s) or bitfield and keep the values > > in sync. > > Why can't we set the bitfield (krbTicketFlags) directly? (There is an > ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Mar 12 16:28:41 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Mar 2013 17:28:41 +0100 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) Message-ID: <513F57B9.9010405@redhat.com> Here's a patch for filtering groups by type. Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type The interface is: > StrEnum('type?', > cli_name='type', > label=_('Type'), > doc=_('Group type'), > values=(u'posix', u'normal', u'external'), > ), I have two design questions. 1. Is --type the right option name? 2. Is `normal` the right name for non-posix, non-external group? The default group type (when adding group) is posix. Should the name be something else: `simple`, `plain`, `ordinary`? I didn't want to create an option for each type. IMO it brings more complexity. https://fedorahosted.org/freeipa/ticket/3483 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0267-Filter-groups-by-type-normal-posix-external.patch Type: text/x-patch Size: 11018 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 12 16:31:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Mar 2013 17:31:58 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1363105473.2822.183.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> Message-ID: <513F587E.4070500@redhat.com> On 12.3.2013 17:24, Simo Sorce wrote: > On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: >> Why can't we set the bitfield (krbTicketFlags) directly? (There is an >> ACI preventing that, I'm just wondering what is the reason for this.) > > If you tell me who 'we' is (as in what user would set it) I can tell you > why it is/isn't possible. Why no IPA user (including admins) can set the attribute? > > Simo. > -- Jan Cholasta From pvoborni at redhat.com Tue Mar 12 16:35:13 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Mar 2013 17:35:13 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513739D3.7090606@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> Message-ID: <513F5941.6060301@redhat.com> On 03/06/2013 01:42 PM, Petr Vobornik wrote: > On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: >> ----- Original Message ----- >>> First two patches are bug fixes which are required for third patch. >>> Depends on my patch #259 (Combobox keyboard support) >>> >>> 1) [PATCH] Fix dirty state update of editable combobox >>> >>> Editable combobox didn't update it's dirty state correctly. CB had >>> it's own internal value changed event, which was incorrectly used. It >>> was >>> removed and widget's value_changed event was used instead. >> >> ACK. > > Pushed to master >> >>> 2) [PATCH] Fix handling of no_update flag in Web UI >>> >>> There was an incorrect check for no_update flag. Check was performed >>> as if the flag was an attribute of object not an item of array. Hence, >>> the flag never caused any effect. >> >> ACK. > > Pushed to master >> >>> 3) [PATCH] Global trust config page >>> >>> https://fedorahosted.org/freeipa/ticket/3333 >> >>> Just two notes: >>> >>> ipantfallbackprimarygroup requires a posix group. Our API currently >>> doesn't support search based on object classes therefore the entity >>> select widget incorrectly offers non posix groups as well. >> >> Are we planning to add the missing functionality? Right now you'll get >> 'group not found' if you select a non-POSIX group, which is confusing >> because the group does exist. Possible solutions: > > > Waiting for "[RFE] Add option for filtering groups by type (posix,..) in > group-find command" to be implemented to solve issue. > Triaged to march and implemented. Patch 267 is on review. This patch is modified accordingly. 8><----- >>> Another problem is that hidden 'Default SMB Group' is not listed. >>> Hence it couldn't be set again after a modification. I made the combobox >>> editable (first usage, so it revealed a bug) to avoid this problem. >>> User can enter garbage, but the framework should handle that. >> >> This is a little difficult to use. You'll need to know that you have to >> type 'Default SMB Group' to go back to the default and the UI doesn't >> show that as an acceptable value. Possible solutions: >> >> 1. Add the 'Default SMB Group' as the first entry in the drop down list >> so you can reselect it again. The drop down list doesn't need to be >> editable. >> >> 2. Use radio buttons to separate the default value from other values: >> >> Fallback primary group: (o) Default SMB Group >> ( ) POSIX group: [ drop down list ] >> >> Regardless, I think the server API needs to be changed to accept an >> empty value to go back to the default value instead of taking 'Default >> SMB Group'. A default value should be simple and not something that will >> potentially conflict with a non-default value that happens to have the >> same name. > > I agree. Martin is it feasible? From other emails: Apparently its not worth the time. So I implemented #1. 3. Found an issue: trusctconfig-show will raise 'not found' error when trusts are not configured on a system. It's fixed separately in attached patch #268. It has similar behavior as dns pages. Also I added data .json files to patch 262 and 268, so the static version can be used. >> -- >> Endi S. Dewata -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0268-Don-t-show-trusts-pages-when-trust-is-not-configured.patch Type: text/x-patch Size: 3731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0262-1-Global-trust-config-page.patch Type: text/x-patch Size: 13795 bytes Desc: not available URL: From simo at redhat.com Tue Mar 12 17:01:00 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Mar 2013 13:01:00 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F587E.4070500@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> <513F587E.4070500@redhat.com> Message-ID: <1363107660.2822.187.camel@willson.li.ssimo.org> On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: > On 12.3.2013 17:24, Simo Sorce wrote: > > On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: > >> Why can't we set the bitfield (krbTicketFlags) directly? (There is an > >> ACI preventing that, I'm just wondering what is the reason for this.) > > > > If you tell me who 'we' is (as in what user would set it) I can tell you > > why it is/isn't possible. > > Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Mar 12 17:31:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Mar 2013 18:31:54 +0100 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1363107660.2822.187.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> <513F587E.4070500@redhat.com> <1363107660.2822.187.camel@willson.li.ssimo.org> Message-ID: <513F668A.4090500@redhat.com> On 12.3.2013 18:01, Simo Sorce wrote: > On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: >> On 12.3.2013 17:24, Simo Sorce wrote: >>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: >>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an >>>> ACI preventing that, I'm just wondering what is the reason for this.) >>> >>> If you tell me who 'we' is (as in what user would set it) I can tell you >>> why it is/isn't possible. >> >> Why no IPA user (including admins) can set the attribute? > > I guess admins should be allowed to. > > Users can't, as ticket flags change the behavior of the principal in > ways only admins should allowed to. (preauth required or not, AS > requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? Honza -- Jan Cholasta From rcritten at redhat.com Tue Mar 12 17:50:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Mar 2013 13:50:05 -0400 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <513F16D3.8070300@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> <513DFF9E.6090404@redhat.com> <513F16D3.8070300@redhat.com> Message-ID: <513F6ACD.6010500@redhat.com> Petr Viktorin wrote: > On 03/11/2013 05:00 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/07/2013 08:27 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>> [...] >>>>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>>>> itself. >>>>>>> I didn't test everything as I didn't get the access. >>>>>> > [...] >>>> Gotcha. I moved where the replica acis are loaded. > > Thanks! Everything works now, I just found two issues in error reporting. > > I set up three masters like this: > > $ ipa-replica-manage dnarange-show > vm-084.idm.lab.eng.brq.redhat.com: 1109050002-1109099999 > vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999 > vm-079.idm.lab.eng.brq.redhat.com: 1109025001-1109049999 > $ ipa-replica-manage dnanextrange-show > vm-084.idm.lab.eng.brq.redhat.com: 1109000000-1109012499 > vm-081.idm.lab.eng.brq.redhat.com: 1109190000-1109190001 > vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set > > vm-079 is git master, the other two have the patch applied. > > Now when I deleted vm-081, there was no indication which ranges I lost: > > vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.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 > Deleting replication agreements between > vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com > ipa: INFO: Setting agreement > cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping > tree,cn=config > ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica > acquired successfully: Incremental update succeeded: start: 0: end: 0 > Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com: > Insufficient access: Insufficient 'write' privilege to the > 'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric > assignment plugin,cn=plugins,cn=config'. > Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com' > Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost > Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com' > to 'vm-081.idm.lab.eng.brq.redhat.com' > Background task created to clean replication data. This may take a while. > This may be safely interrupted with Ctrl+C Fixed. > One more detail: Ranges where start==end are invalid. We should fail the > same way as for start>end. > > $ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com > 677100401-677100401 > ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid > DNA configuration.', 'desc': 'Server is unwilling to perform'} > Updating next range failed: Server is unwilling to perform: Changes > result in an invalid DNA configuration. > > done rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1088-5-dnarange.patch Type: text/x-diff Size: 30467 bytes Desc: not available URL: From simo at redhat.com Tue Mar 12 18:02:23 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Mar 2013 14:02:23 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <513F668A.4090500@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> <513F587E.4070500@redhat.com> <1363107660.2822.187.camel@willson.li.ssimo.org> <513F668A.4090500@redhat.com> Message-ID: <1363111343.2822.195.camel@willson.li.ssimo.org> On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: > On 12.3.2013 18:01, Simo Sorce wrote: > > On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: > >> On 12.3.2013 17:24, Simo Sorce wrote: > >>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: > >>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an > >>>> ACI preventing that, I'm just wondering what is the reason for this.) > >>> > >>> If you tell me who 'we' is (as in what user would set it) I can tell you > >>> why it is/isn't possible. > >> > >> Why no IPA user (including admins) can set the attribute? > > > > I guess admins should be allowed to. > > > > Users can't, as ticket flags change the behavior of the principal in > > ways only admins should allowed to. (preauth required or not, AS > > requests disabled or not, etc...) > > Thanks. For normal users it's obvious, but it seemed a little bit > strange to disallow admins to set the flags. > > So, can the krbTicketFlags attribute be used internally in IPA plugins > to set/unset the flags, given that the ACI is changed to allow admins to > modify the attribute? The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Wed Mar 13 08:47:09 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Mar 2013 09:47:09 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range Message-ID: <51403D0D.5040307@redhat.com> Hi, SID validation in idrange.py now enforces exact match on SIDs, thus one can no longer use SID of an object in a trusted domain as a trusted domain SID. https://fedorahosted.org/freeipa/ticket/3432 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0039-Enforce-exact-SID-match-when-adding-or-modifying-a-I.patch Type: text/x-patch Size: 5415 bytes Desc: not available URL: From tbabej at redhat.com Wed Mar 13 08:50:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Mar 2013 09:50:46 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range In-Reply-To: <51403D0D.5040307@redhat.com> References: <51403D0D.5040307@redhat.com> Message-ID: <51403DE6.3050304@redhat.com> On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote: > Hi, > > SID validation in idrange.py now enforces exact match on SIDs, thus > one can no longer use SID of an object in a trusted domain as a > trusted domain SID. > > https://fedorahosted.org/freeipa/ticket/3432 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Just renamed the patch filename to follow the convention. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0039-Enforce-exact-SID-match-when-adding-or-modifying-a-I.patch Type: text/x-patch Size: 5415 bytes Desc: not available URL: From pspacek at redhat.com Wed Mar 13 10:00:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Mar 2013 11:00:33 +0100 Subject: [Freeipa-devel] OID assignment request: new objectClass idnsForwardZone Message-ID: <51404E41.3080607@redhat.com> Hello list, I would like to obtain new OID for new objectClass idnsForwardZone, as planed in https://fedorahosted.org/bind-dyndb-ldap/ticket/99 . idnsForwardZone is meant as sane subset of existing idnsZone. Currently, IPA uses idnsZone for master and forward zones at the same time. The result of this situation is a mess. Users are forced to fill in non-senses like fake SOA records for forward zones etc. IPAv3 uses OID space 2.16.840.1.113730.3.8.12.x for objectClasses, right? New objectClass proposal: objectClasses: ( 2.16.840.1.113730.3.8.12.x NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsForwarders ) MAY idnsForwardPolicy ) -- Petr^2 Spacek From mkosek at redhat.com Wed Mar 13 10:00:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 11:00:42 +0100 Subject: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf In-Reply-To: <513D9836.3060601@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> <513D9146.6080604@redhat.com> <513D9836.3060601@redhat.com> Message-ID: <51404E4A.6050106@redhat.com> On 03/11/2013 09:39 AM, Petr Spacek wrote: > On 11.3.2013 09:09, Martin Kosek wrote: >> On 03/08/2013 09:49 AM, Petr Spacek wrote: >>> On 8.3.2013 00:14, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>>>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>>>> unnecessary Kerberos checks on BIND startup and can cause issues when >>>>> KDC is not available. >>>>> >>>>> Both new and current IPA installations are updated. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3429 >>>>> >>>> >>>> Still reviewing this but I noticed that after upgrading my 3.1.99 server >>>> pre-patch to with with-patch version the connections argument in named.conf >>>> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >>>> during the initial install too? >>> >>> For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections >>> should not harm. >>> >>> Higher value should allow higher level of parallelism, it is one of tuning >>> parameters. Value 4 was necessary to prevent deadlocks in some previous >>> versions of bind-dyndb-ldap. >>> >> >> Previously, when I implemented the upgrade script, I set connections arg only >> if it was present in named.conf and thus bind-dyndb-ldap could not use a >> reasonable default on its own decision. >> >> This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections >> is set always. Rob is correct, that in that case we might want to add it to >> named.conf by default to make it consistent... or we could also fix upgrade >> script to change connections only if it is present in named.conf. >> >> Petr, what does make more sense bind-dyndb-ldap wise? > > Default values should work. Personally I would include only "override" values > in named.conf, but technically it doesn't matter. > > Note: Latest bind-dyndb-ldap versions refuse to start if configuration is > insane. Fatal error will point admin to errors in configuration and should > prevent surprises from auto-magically changed values. > > Invalid configurations - examples: > connections < 1 > connections < 2 && psearch is enabled > serial_autoincrement enabled && psearch disabled > Ok, lets set the connections argument only if it is in named.conf _and_ it is lower than the required minimum. All patches attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-376-update-named.conf-parser.patch Type: text/x-patch Size: 5421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-377-use-tkey-gssapi-keytab-in-named.conf.patch Type: text/x-patch Size: 5120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-385-do-not-force-named-connections-on-upgrades.patch Type: text/x-patch Size: 1184 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 13 10:03:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 13 Mar 2013 11:03:33 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <513F6ACD.6010500@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> <513DFF9E.6090404@redhat.com> <513F16D3.8070300@redhat.com> <513F6ACD.6010500@redhat.com> Message-ID: <51404EF5.8010209@redhat.com> On 03/12/2013 06:50 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/11/2013 05:00 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/07/2013 08:27 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>> [...] >>>>>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>>>>> itself. >>>>>>>> I didn't test everything as I didn't get the access. >>>>>>> >> [...] >>>>> Gotcha. I moved where the replica acis are loaded. >> >> Thanks! Everything works now, I just found two issues in error reporting. >> >> I set up three masters like this: >> >> $ ipa-replica-manage dnarange-show >> vm-084.idm.lab.eng.brq.redhat.com: 1109050002-1109099999 >> vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999 >> vm-079.idm.lab.eng.brq.redhat.com: 1109025001-1109049999 >> $ ipa-replica-manage dnanextrange-show >> vm-084.idm.lab.eng.brq.redhat.com: 1109000000-1109012499 >> vm-081.idm.lab.eng.brq.redhat.com: 1109190000-1109190001 >> vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set >> >> vm-079 is git master, the other two have the patch applied. >> >> Now when I deleted vm-081, there was no indication which ranges I lost: >> >> vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.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 >> Deleting replication agreements between >> vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com >> ipa: INFO: Setting agreement >> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >> >> tree,cn=config schedule to 2358-2359 0 to force synch >> ipa: INFO: Deleting schedule 2358-2359 0 from agreement >> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >> >> tree,cn=config >> ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica >> acquired successfully: Incremental update succeeded: start: 0: end: 0 >> Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com: >> Insufficient access: Insufficient 'write' privilege to the >> 'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric >> assignment plugin,cn=plugins,cn=config'. >> Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com' >> Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost >> Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com' >> to 'vm-081.idm.lab.eng.brq.redhat.com' >> Background task created to clean replication data. This may take a while. >> This may be safely interrupted with Ctrl+C > > Fixed. > >> One more detail: Ranges where start==end are invalid. We should fail the >> same way as for start>end. >> >> $ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com >> 677100401-677100401 >> ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid >> DNA configuration.', 'desc': 'Server is unwilling to perform'} >> Updating next range failed: Server is unwilling to perform: Changes >> result in an invalid DNA configuration. >> >> > > done > > rob ACK -- Petr? From tbabej at redhat.com Wed Mar 13 11:28:03 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Mar 2013 12:28:03 +0100 Subject: [Freeipa-devel] [PATCHES 0031-0032] Improve HBAC rule handling in selinuxusermap-add/mod/find In-Reply-To: <512DD1A6.3070504@redhat.com> References: <511294EB.9050805@redhat.com> <5112A797.805@redhat.com> <511519C4.30907@redhat.com> <5123EFC7.9020708@redhat.com> <5124B3FE.7000407@redhat.com> <512DD1A6.3070504@redhat.com> Message-ID: <514062C3.1030400@redhat.com> On 02/27/2013 10:28 AM, Martin Kosek wrote: > On 02/20/2013 12:31 PM, Tomas Babej wrote: >> On 02/19/2013 10:33 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 02/06/2013 07:57 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> this pair of patches improves HBAC rule handling in selinuxusermap >>>>>> commands. >>>>>> >>>>>> Patch 0031 deals with: >>>>>> https://fedorahosted.org/freeipa/ticket/3349 >>>>>> >>>>>> Patch 0032 takes care of: >>>>>> https://fedorahosted.org/freeipa/ticket/3348 >>>>>> >>>>>> and is to be applied on top of Patch 0031. >>>>>> >>>>>> See commit messages for detailed info. >>>>>> >>>>>> Tomas >>>>>> >>>>> ACK for patch 0032. >>>>> >>>>> For patch 0031 we can't change the data type of an existing attribute. >>>>> It will break backwards compatibility. Can you test with an older >>>>> client to see if it cares (it may not care about the name of the >>>>> type). If older clients will work then this is probably ok. >>>>> >>>>> I gather that seealso detected as a DN attribute and converted into a >>>>> DN class and this is blowing up the Str validator? >>>>> >>>> Yes, that was exactly the case. >>>>> rob >>>> I added a workaround for older client versions, tested it with >>>> freeipa-client/admintools 2.2, works as expeceted. >>>> However, this only should be issue if there is older admintools package >>>> on the client than on the server. >>>> >>>> Outline is such as follows: I added a new flag for DNParam seelalso >>>> attribute, called 'allow_malformed' that allows any string to be passed >>>> to DNParam. Its value gets wrapped in 'malformed=yes,value='. >>>> This allows to parse out the string in selinuxusermap-add/mod >>>> pre_callback out of the DN and search for the rule with such name so >>>> that it's DN gets in LDAP instead. >>>> >>>> Updated patch attached. >>>> >>>> Tomas >>> I like where you're going with this, just a couple of comments: >>> >>> 1. Should we come up with a more universal name for allow_malformed? Is this >>> something that we should allow at a higher level? I was thinking allow_raw, >>> or allow_non_dn, or something like that. >> To me, allow_non_dn sounds is just as specific as allow_malformed, >> they both refer to DN specifically. >> >> I'd go with allow_raw, if need for such pattern may eventually arise for >> other parameter classes than DNParam. >> >> What do you mean by higher level, turning this hack into a feature >> Param class? I don't see how this would work, each parameter >> class that implements its own type validation as DNParam needs >> to override _convert_scalar(). And in every such class we would need >> to wrap our raw value so that it is represented in the type of this parameter, >> as we do with DN(('malformed','yes'),('value',value)) now. >> >> Maybe we could skip type validation in _convert_scalar default >> implementation or catch the error raised somehow, and let the type be >> invalid, but I'm not aware of the consenquences. I would need to investigate. >> Wouldn't it cause failure deeper in the framework? >> >> Or did you by higher level mean simply picking a more general name for the >> flag so it can be reused in other parameter classes with the same name? >>> 2. I think that if a bad dn is passed in as a Str the conversion into a DN >>> won't be handled: >>> >>> + if 'allow_malformed' in self.flags: >>> + dn = DN(('malformed','yes'),('value',value)) >>> >>> Should this be wrapped in a try/except to raise a ConversionError if it fails? >> Yes, thanks for that catch. >>> rob >> Tomas > Is it just me, or does the 0031 look overengineered? I think this is a general > problem for each Str parameter which we then process/convert to DN in our > pre_callbacks. > > selinuxusermap is one example where this does not work. This fix leaves other > examples not working: > > # ipa trustconfig-mod --setattr "ipantfallbackprimarygroup=cn=Default SMB > Group,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" > ipa: ERROR: invalid 'ipantfallbackprimarygroup': must be Unicode text > > I would rather propose to not automatically encode DN of known attributes set > by *attr: > > diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > index 1ebbe7a..e4b9834 100644 > --- a/ipalib/plugins/baseldap.py > +++ b/ipalib/plugins/baseldap.py > @@ -768,12 +768,6 @@ last, after all sets and adds."""), > # None means "delete this attribute" > value = None > > - if ldap.has_dn_syntax(attr): > - try: > - value = DN(value) > - except ValueError: > - raise errors.InvalidSyntax(attr=attr) > - > if attr in newdict: > if type(value) in (tuple,): > newdict[attr] += list(value) > > I think this conversion is just done too early as this Str param is processed > and converted later in the pre_callback, when needed. The code above introduced > inconsistent processing of IPA attributes with DN syntax coming from regular > option and from *attr option - Str > > When I did this change, both selinuxusermap-mod and trustconfig-mod started > working: > > # ipa selinuxusermap-mod foo > --setattr=seealso=ipaUniqueID=70e42636-75db-11e2-9df6-001a4a104edc,cn=hbac,dc=rhel64,dc=ad,dc=test > ------------------------------- > Modified SELinux User Map "foo" > ------------------------------- > Rule name: foo > SELinux User: unconfined_u:s0-s0:c0.c1023 > HBAC Rule: allow_all > Enabled: TRUE > # ipa selinuxusermap-mod foo --setattr=seealso=allow_all > ipa: ERROR: no modifications to be performed > # ipa selinuxusermap-mod foo --hbacrule=allow_all > ipa: ERROR: no modifications to be performed > > You would just need to investigate if this change would not have other > consequences. > > Martin Attaching a version of the patch based on the Martin's proposition. This is indeed a simpler solution, that solves both problems. I investigated whether removing conversion into DN would have any consenquences. However, it turns out that DNParam is only used in contexts where usage of --*attr options is not allowed: - cosentry class (no CLI) - migration (no *attr options) - ipacertificatesubjectbase in ipa config class (has no_update flag) I refactored the patch and retained the unit tests. Please note that pushing this renders 0032 invalid. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0031-Remove-implicit-Str-to-DN-conversion-using-attr.patch Type: text/x-patch Size: 25965 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 13 11:48:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 12:48:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration In-Reply-To: <513F3D05.5090500@redhat.com> References: <513760D6.9010305@redhat.com> <5138C36E.2070406@redhat.com> <5139E41A.7020203@redhat.com> <513DCA5C.3050901@redhat.com> <513DD180.60903@redhat.com> <513DD2A1.7080409@redhat.com> <513DE275.40709@redhat.com> <513EF0F0.1010809@redhat.com> <513F218A.8020603@redhat.com> <513F3D05.5090500@redhat.com> Message-ID: <51406778.40200@redhat.com> On 03/12/2013 03:34 PM, Petr Viktorin wrote: > On 03/12/2013 01:37 PM, Martin Kosek wrote: >> On 03/12/2013 10:10 AM, Petr Viktorin wrote: >>> On 03/11/2013 02:56 PM, Martin Kosek wrote: >>>> On 03/11/2013 01:48 PM, Jan Cholasta wrote: >>>>> On 11.3.2013 13:43, Petr Viktorin wrote: >>>>>> On 03/11/2013 01:13 PM, Jan Cholasta wrote: >>>>>>> On 8.3.2013 14:14, Petr Viktorin wrote: >>>>>>>> On 03/07/2013 05:42 PM, Jan Cholasta wrote: >>>>>>>>> Patch 191: >>>>>>>>> >>>>>>>>> The patch is missing the ipapython/ipaldap.py file. >>>>>>> >>>>>>> On 7.3.2013 18:29, Petr Viktorin wrote: >>>>>>> > It's there, it's just copied from ipaserver/ipaldap.py with a small >>>>>>> > change at the bottom. >>>>>>> >>>>>>> There is no sign of the file, except in the patch header and the patch >>>>>>> cannot be applied with git am nor with git apply. But perhaps I'm doing >>>>>>> something wrong. >>>>>> >>>>>> Attaching a re-formatted version of the patch. >>>>>> >>>>>> [...] >>>>>>> ACK. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> >>>>> >>>>> ACK for real. >>>>> >>>>> Honza >>>>> >>>> >>>> I would not want to rush this, I still see errors: >>>> >>>> 1) ipa-ldap-updater is broken: >>>> >>>> # ipa-ldap-updater --upgrade >>>> Upgrading IPA: >>>> [1/8]: stopping directory server >>>> [2/8]: saving configuration >>>> [3/8]: disabling listeners >>>> [4/8]: starting directory server >>>> [5/8]: upgrading server >>>> Upgrade failed with 'NameSpace' object has no attribute 'ldap2' >>>> [6/8]: stopping directory server >>>> [7/8]: restoring configuration >>>> [8/8]: starting directory server >>>> Done. >>>> IPA upgrade failed. >>> >>> Thanks for the catch! >>> >>> This is a symptom of the fact the plugins attach themselves to the default API >>> object as soon as they're imported. >>> Before, ipaldap imported ldap2, so the ldap2 server plugin was magically >>> available whenever ipaldap was imported before. >>> Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be >>> available. >>> >>>> 2) What's the purpose of this new error? >>>> >>>> +class DatabaseTimeout(DatabaseError): >>>> + """ >>>> + **4211** Raised when an LDAP call times out >>>> + >>>> + For example: >>>> + >>>> + >>> raise DatabaseTimeout() >>>> + Traceback (most recent call last): >>>> + ... >>>> + DatabaseTimeout: LDAP timeout >>>> + """ >>>> + >>>> + errno = 4211 >>>> + format = _('LDAP timeout') >>> >>> Thanks for this catch too, I mis-squashed the code to raise it. >>> >>>> It is not raised anywhere (as far as I can see). BTW I assume it is not >>>> related to errors.LimitsExceeded in any way, right? >>> >>> No, it's timeout in the client?server communication rather than the LDAP >>> operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED. >>> >>>> 3) Client installation no longer works if the server has disabled >>>> anonymous authentication: >>>> >>>> # ipa-client-install >>>> Error checking LDAP: Inappropriate authentication: Anonymous access is >>>> not allowed. >>>> DNS discovery failed to determine your DNS domain >>>> Provide the domain name of your IPA server (ex: example.com): ^C >>> >>> I couldn't reproduce this. But I did find some misleading log messages in this >>> case. It work well now. >>> >>>> 4) I suddenly cannot run some tests, looks like import loop: >>>> >>>> # ./make-test tests/test_xmlrpc/test_host_plugin.py >>>> /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins >>>> tests/test_xmlrpc/test_host_plugin.py >>>> Failure: ImportError (cannot import name ipautil) ... ERROR >>>> >>>> ====================================================================== >>>> ERROR: Failure: ImportError (cannot import name ipautil) >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 390, in >>>> loadTestsFromName >>>> addr.filename, addr.module) >>>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 39, in >>>> importFromPath >>>> return self.importFromDir(dir_path, fqname) >>>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 86, in >>>> importFromDir >>>> mod = load_module(part_fqname, fh, filename, desc) >>>> File "/root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py", >>>> line 27, in >>>> from ipapython import ipautil >>>> File "/root/freeipa-master/ipapython/ipautil.py", line 52, in >>>> from ipalib import errors >>>> File "/root/freeipa-master/ipalib/__init__.py", line 930, in >>>> api.finalize() >>>> File "/root/freeipa-master/ipalib/plugable.py", line 674, in finalize >>>> self.__do_if_not_done('load_plugins') >>>> File "/root/freeipa-master/ipalib/plugable.py", line 454, in >>>> __do_if_not_done >>>> getattr(self, name)() >>>> File "/root/freeipa-master/ipalib/plugable.py", line 613, in >>>> load_plugins >>>> self.import_plugins('ipalib') >>>> File "/root/freeipa-master/ipalib/plugable.py", line 655, in >>>> import_plugins >>>> __import__(fullname) >>>> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >>>> from ipalib import pkcs10 >>>> File "/root/freeipa-master/ipalib/pkcs10.py", line 24, in >>>> from ipapython import ipautil >>>> ImportError: cannot import name ipautil >>> >>> Gasp... I have no idea how we didn't catch this earlier. >>> Simplifying a bit, it's partly due to the fact that ipalib does a lot of work >>> on import in __init__ -- including loading plugins that assume ipalib's already >>> set up. >>> >>> I've deferred the import, and added a FIXME. >>> >>> >>> Thank you for retesting! >>> Updated patches attached. >>> >> >> I tested our basic scenarios and everything seems to work fine, so I think we >> can push this soon if no one objects. I just hit two more places in the patch >> set which look suspicious: >> >> 1) In 193.3, one more unexpected raise: >> >> except Exception, e: >> - root_logger.debug("get_ca_cert_from_ldap() error: %s", >> - convert_ldap_error(e)) >> + raise >> + root_logger.debug("get_ca_cert_from_ldap() error: %s", e) >> >> >> 2) In 194.3, redundant section: >> >> + try: >> + self.__wait_for_connection(timeout) >> + except: >> + raise >> >> Martin >> > > Fixed, thanks. > This looks OK, thanks. ACK, pushed to master. Martin From mkosek at redhat.com Wed Mar 13 12:02:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 13:02:00 +0100 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <51404EF5.8010209@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> <513DFF9E.6090404@redhat.com> <513F16D3.8070300@redhat.com> <513F6ACD.6010500@redhat.com> <51404EF5.8010209@redhat.com> Message-ID: <51406AB8.7000806@redhat.com> On 03/13/2013 11:03 AM, Petr Viktorin wrote: > On 03/12/2013 06:50 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/11/2013 05:00 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/07/2013 08:27 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>> [...] >>>>>>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>>>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>>>>>> itself. >>>>>>>>> I didn't test everything as I didn't get the access. >>>>>>>> >>> [...] >>>>>> Gotcha. I moved where the replica acis are loaded. >>> >>> Thanks! Everything works now, I just found two issues in error reporting. >>> >>> I set up three masters like this: >>> >>> $ ipa-replica-manage dnarange-show >>> vm-084.idm.lab.eng.brq.redhat.com: 1109050002-1109099999 >>> vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999 >>> vm-079.idm.lab.eng.brq.redhat.com: 1109025001-1109049999 >>> $ ipa-replica-manage dnanextrange-show >>> vm-084.idm.lab.eng.brq.redhat.com: 1109000000-1109012499 >>> vm-081.idm.lab.eng.brq.redhat.com: 1109190000-1109190001 >>> vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set >>> >>> vm-079 is git master, the other two have the patch applied. >>> >>> Now when I deleted vm-081, there was no indication which ranges I lost: >>> >>> vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.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 >>> Deleting replication agreements between >>> vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com >>> ipa: INFO: Setting agreement >>> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >>> >>> >>> tree,cn=config schedule to 2358-2359 0 to force synch >>> ipa: INFO: Deleting schedule 2358-2359 0 from agreement >>> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >>> >>> >>> tree,cn=config >>> ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica >>> acquired successfully: Incremental update succeeded: start: 0: end: 0 >>> Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com: >>> Insufficient access: Insufficient 'write' privilege to the >>> 'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric >>> assignment plugin,cn=plugins,cn=config'. >>> Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com' >>> Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost >>> Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com' >>> to 'vm-081.idm.lab.eng.brq.redhat.com' >>> Background task created to clean replication data. This may take a while. >>> This may be safely interrupted with Ctrl+C >> >> Fixed. >> >>> One more detail: Ranges where start==end are invalid. We should fail the >>> same way as for start>end. >>> >>> $ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com >>> 677100401-677100401 >>> ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid >>> DNA configuration.', 'desc': 'Server is unwilling to perform'} >>> Updating next range failed: Server is unwilling to perform: Changes >>> result in an invalid DNA configuration. >>> >>> >> >> done >> >> rob > > ACK > Btw Rob you will likely need to rebase the patch a bit before pushing as ipaldap is now in ipapython module (see Petr^3's patches 0191-0195). Martin From simo at redhat.com Wed Mar 13 12:57:42 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Mar 2013 08:57:42 -0400 Subject: [Freeipa-devel] OID assignment request: new objectClass idnsForwardZone In-Reply-To: <51404E41.3080607@redhat.com> References: <51404E41.3080607@redhat.com> Message-ID: <1363179462.2822.311.camel@willson.li.ssimo.org> On Wed, 2013-03-13 at 11:00 +0100, Petr Spacek wrote: > Hello list, > > I would like to obtain new OID for new objectClass idnsForwardZone, as planed > in https://fedorahosted.org/bind-dyndb-ldap/ticket/99 . > > idnsForwardZone is meant as sane subset of existing idnsZone. Currently, IPA > uses idnsZone for master and forward zones at the same time. The result of > this situation is a mess. Users are forced to fill in non-senses like fake SOA > records for forward zones etc. > > > IPAv3 uses OID space 2.16.840.1.113730.3.8.12.x for objectClasses, right? > > New objectClass proposal: > > objectClasses: ( 2.16.840.1.113730.3.8.12.x NAME 'idnsForwardZone' DESC > 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive $ > idnsForwarders ) MAY idnsForwardPolicy ) > ACK, use 2.16.840.1.113730.3.8.12.19 Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Mar 13 13:00:57 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Mar 2013 09:00:57 -0400 Subject: [Freeipa-devel] OID assignment request: new objectClass idnsForwardZone In-Reply-To: <1363179462.2822.311.camel@willson.li.ssimo.org> References: <51404E41.3080607@redhat.com> <1363179462.2822.311.camel@willson.li.ssimo.org> Message-ID: <1363179657.2822.313.camel@willson.li.ssimo.org> On Wed, 2013-03-13 at 08:57 -0400, Simo Sorce wrote: > On Wed, 2013-03-13 at 11:00 +0100, Petr Spacek wrote: > > Hello list, > > > > I would like to obtain new OID for new objectClass idnsForwardZone, as planed > > in https://fedorahosted.org/bind-dyndb-ldap/ticket/99 . > > > > idnsForwardZone is meant as sane subset of existing idnsZone. Currently, IPA > > uses idnsZone for master and forward zones at the same time. The result of > > this situation is a mess. Users are forced to fill in non-senses like fake SOA > > records for forward zones etc. > > > > > > IPAv3 uses OID space 2.16.840.1.113730.3.8.12.x for objectClasses, right? > > > > New objectClass proposal: > > > > objectClasses: ( 2.16.840.1.113730.3.8.12.x NAME 'idnsForwardZone' DESC > > 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive $ > > idnsForwarders ) MAY idnsForwardPolicy ) > > > > ACK, use 2.16.840.1.113730.3.8.12.19 Sorry, cancel this. I just remembered we have a whole oid sub-space specific for DNS objects. Please use: 2.16.840.1.113730.3.8.6.3 Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Mar 13 12:30:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 13:30:51 +0100 Subject: [Freeipa-devel] [PATCH] 386 Fix client discovery crash Message-ID: <5140717B.5010302@redhat.com> Client discovery LDAP search assumes that the remote LDAP server will send an entry with lowercase attribute names. When it discovers for example on openldap which sends it in CamelCase, the discovery crashes. Convert retrieved entry to CIDict to avoid this error. Also add a fallback to ipa-client-install server discovery process so that it rather skips the faulty server instead of crashing. https://fedorahosted.org/freeipa/ticket/3446 ------- NOTE: this is just a hotfix for IPA 3.1.x (ipa-3-1 branch). Proper fix was done by Petr Viktorin (patches 0191-0195). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-386-fix-client-discovery-crash.patch Type: text/x-patch Size: 3007 bytes Desc: not available URL: From tbabej at redhat.com Wed Mar 13 13:34:13 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Mar 2013 14:34:13 +0100 Subject: [Freeipa-devel] [PATCH 0040] Make sure uninstall script prompts for reboot as last Message-ID: <51408055.3020906@redhat.com> Hi, Parts of client uninstall logic could be skipped in attended uninstallation if user agreed to reboot the machine. Particulary, the uninstall script would not try to remove /etc/ipa/default.conf and therefore subsequent installation would fail, client being detected as already configured. https://fedorahosted.org/freeipa/ticket/3462 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0040-Make-sure-uninstall-script-prompts-for-reboot-as-las.patch Type: text/x-patch Size: 4554 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 13 13:58:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 14:58:33 +0100 Subject: [Freeipa-devel] [PATCH] 381, 386 Preserve order of servers in ipa-client-install In-Reply-To: <513DC2BB.4020905@redhat.com> References: <51388F87.6040200@redhat.com> <51389F08.1030607@redhat.com> <513DC2BB.4020905@redhat.com> Message-ID: <51408609.9030701@redhat.com> On 03/11/2013 12:40 PM, Martin Kosek wrote: > On 03/07/2013 03:07 PM, Petr Viktorin wrote: >> On 03/07/2013 02:00 PM, Martin Kosek wrote: >>> When multiple servers are passed via --server option, ipadiscovery >>> module changed its order. Make sure that we preserve it. >>> >>> Also make sure that user is always warned when a tested server is >>> not available as then the server will be excluded from the fixed >>> server list. >> >> The message doesn't actually say that the server will be removed. It would be >> nice if it did. >> >> Otherwise, ACK. > > Sending a patch with improved logging. User should now be more clear what > server is failing to verify (and why). > >> >>> ------ >>> >>> When working on this ticket I was thinking - do we make the right thing we >>> deliberately remove a server from user-provided server list just because we >>> cannot connect to it at the moment if discovery? It may just be temporarily >>> down or something. >>> >>> Maybe we should preserve the original --server list in this case and use this >>> list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other >>> active configuration commands we would have to use only the valid servers so >>> that the we do not hit the server that is currently down. >>> >>> Martin >> >> Good point, this deserves a ticket. >> > > Rob, do you think this deserves to be changed? Or is this behavior indeed > intended? > > Martin > Sending a rebased patch 381, logging was also improved. Client discovery logging now looks like that: # ipa-client-install Skip vm-024.idm.lab.bos.redhat.com: not an IPA server Skip doesnotexist.test: cannot verify if this is an IPA server Discovery was successful! Hostname: vm-148.idm.lab.bos.redhat.com Realm: IDM.LAB.BOS.REDHAT.COM DNS Domain: idm.lab.bos.redhat.com IPA Server: vm-037.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]: ... I also attached a related fix for redundant discoveries with fixed server list (found that when testing logging), details are in the patch description. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-381-3-preserve-order-of-servers-in-ipa-client-install.patch Type: text/x-patch Size: 3944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-386-multiple-client-discovery.patch Type: text/x-patch Size: 1992 bytes Desc: not available URL: From tbabej at redhat.com Wed Mar 13 14:05:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Mar 2013 15:05:04 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command Message-ID: <51408790.8040903@redhat.com> Hi, The following is mentioned in the server log now: - existence of host entry (if it already does exist) - missing krbprincipalname and its new value (if there was no principal name set) https://fedorahosted.org/freeipa/ticket/3481 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0041-Add-logging-to-join-command.patch Type: text/x-patch Size: 3870 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 13 14:12:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 15:12:59 +0100 Subject: [Freeipa-devel] [PATCH] 381, 387 Preserve order of servers in ipa-client-install In-Reply-To: <51408609.9030701@redhat.com> References: <51388F87.6040200@redhat.com> <51389F08.1030607@redhat.com> <513DC2BB.4020905@redhat.com> <51408609.9030701@redhat.com> Message-ID: <5140896B.9010506@redhat.com> On 03/13/2013 02:58 PM, Martin Kosek wrote: > On 03/11/2013 12:40 PM, Martin Kosek wrote: >> On 03/07/2013 03:07 PM, Petr Viktorin wrote: >>> On 03/07/2013 02:00 PM, Martin Kosek wrote: >>>> When multiple servers are passed via --server option, ipadiscovery >>>> module changed its order. Make sure that we preserve it. >>>> >>>> Also make sure that user is always warned when a tested server is >>>> not available as then the server will be excluded from the fixed >>>> server list. >>> >>> The message doesn't actually say that the server will be removed. It would be >>> nice if it did. >>> >>> Otherwise, ACK. >> >> Sending a patch with improved logging. User should now be more clear what >> server is failing to verify (and why). >> >>> >>>> ------ >>>> >>>> When working on this ticket I was thinking - do we make the right thing we >>>> deliberately remove a server from user-provided server list just because we >>>> cannot connect to it at the moment if discovery? It may just be temporarily >>>> down or something. >>>> >>>> Maybe we should preserve the original --server list in this case and use this >>>> list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other >>>> active configuration commands we would have to use only the valid servers so >>>> that the we do not hit the server that is currently down. >>>> >>>> Martin >>> >>> Good point, this deserves a ticket. >>> >> >> Rob, do you think this deserves to be changed? Or is this behavior indeed >> intended? >> >> Martin >> > > Sending a rebased patch 381, logging was also improved. Client discovery > logging now looks like that: > > # ipa-client-install > Skip vm-024.idm.lab.bos.redhat.com: not an IPA server > Skip doesnotexist.test: cannot verify if this is an IPA server > Discovery was successful! > Hostname: vm-148.idm.lab.bos.redhat.com > Realm: IDM.LAB.BOS.REDHAT.COM > DNS Domain: idm.lab.bos.redhat.com > IPA Server: vm-037.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]: > ... > > I also attached a related fix for redundant discoveries with fixed server list > (found that when testing logging), details are in the patch description. > > Martin > I just creating a conflict in my patch numbering, renaming 386 to 387... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-381-3-preserve-order-of-servers-in-ipa-client-install.patch Type: text/x-patch Size: 3944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-387-multiple-client-discovery.patch Type: text/x-patch Size: 1992 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 13 14:48:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Mar 2013 10:48:41 -0400 Subject: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master In-Reply-To: <51406AB8.7000806@redhat.com> References: <51313247.1040801@redhat.com> <5134B6E1.7000203@redhat.com> <5137AC8F.3060204@redhat.com> <51388513.2040700@redhat.com> <5138EA35.8040508@redhat.com> <5139D860.5080507@redhat.com> <513DFF9E.6090404@redhat.com> <513F16D3.8070300@redhat.com> <513F6ACD.6010500@redhat.com> <51404EF5.8010209@redhat.com> <51406AB8.7000806@redhat.com> Message-ID: <514091C9.90208@redhat.com> Martin Kosek wrote: > On 03/13/2013 11:03 AM, Petr Viktorin wrote: >> On 03/12/2013 06:50 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/11/2013 05:00 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/07/2013 08:27 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 03/06/2013 09:52 PM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>> [...] >>>>>>>>>> On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric >>>>>>>>>> Assignment Plugin,cn=plugins,cn=config is added before the entry >>>>>>>>>> itself. >>>>>>>>>> I didn't test everything as I didn't get the access. >>>>>>>>> >>>> [...] >>>>>>> Gotcha. I moved where the replica acis are loaded. >>>> >>>> Thanks! Everything works now, I just found two issues in error reporting. >>>> >>>> I set up three masters like this: >>>> >>>> $ ipa-replica-manage dnarange-show >>>> vm-084.idm.lab.eng.brq.redhat.com: 1109050002-1109099999 >>>> vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999 >>>> vm-079.idm.lab.eng.brq.redhat.com: 1109025001-1109049999 >>>> $ ipa-replica-manage dnanextrange-show >>>> vm-084.idm.lab.eng.brq.redhat.com: 1109000000-1109012499 >>>> vm-081.idm.lab.eng.brq.redhat.com: 1109190000-1109190001 >>>> vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set >>>> >>>> vm-079 is git master, the other two have the patch applied. >>>> >>>> Now when I deleted vm-081, there was no indication which ranges I lost: >>>> >>>> vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.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 >>>> Deleting replication agreements between >>>> vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com >>>> ipa: INFO: Setting agreement >>>> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >>>> >>>> >>>> tree,cn=config schedule to 2358-2359 0 to force synch >>>> ipa: INFO: Deleting schedule 2358-2359 0 from agreement >>>> cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping >>>> >>>> >>>> tree,cn=config >>>> ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica >>>> acquired successfully: Incremental update succeeded: start: 0: end: 0 >>>> Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com: >>>> Insufficient access: Insufficient 'write' privilege to the >>>> 'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric >>>> assignment plugin,cn=plugins,cn=config'. >>>> Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com' >>>> Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost >>>> Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com' >>>> to 'vm-081.idm.lab.eng.brq.redhat.com' >>>> Background task created to clean replication data. This may take a while. >>>> This may be safely interrupted with Ctrl+C >>> >>> Fixed. >>> >>>> One more detail: Ranges where start==end are invalid. We should fail the >>>> same way as for start>end. >>>> >>>> $ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com >>>> 677100401-677100401 >>>> ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid >>>> DNA configuration.', 'desc': 'Server is unwilling to perform'} >>>> Updating next range failed: Server is unwilling to perform: Changes >>>> result in an invalid DNA configuration. >>>> >>>> >>> >>> done >>> >>> rob >> >> ACK >> > > Btw Rob you will likely need to rebase the patch a bit before pushing as > ipaldap is now in ipapython module (see Petr^3's patches 0191-0195). > > Martin > Yup, was actually the least painful merge I've done in a while :-) pushed to master rob From mkosek at redhat.com Wed Mar 13 15:50:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 16:50:55 +0100 Subject: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling In-Reply-To: <513F3DE9.2050900@redhat.com> References: <513DFF24.40408@redhat.com> <513EF7F6.9030903@redhat.com> <513F3DE9.2050900@redhat.com> Message-ID: <5140A05F.90401@redhat.com> On 03/12/2013 03:38 PM, Petr Spacek wrote: > On 12.3.2013 10:40, Martin Kosek wrote: >> On 03/11/2013 04:58 PM, Petr Spacek wrote: >>> Hello list! >>> >>> My first patch for FreeIPA is attached :-) >>> >>> I managed to add new 389 DS plugin to build system, but the LDAP magic in >>> installer and updater is too much for my brain. >>> >>> Could somebody show me how installer and updater should add new object to >>> cn=config ? Plugin configuration is static (example is in comments in >>> ipa_dns.c). >>> >>> This patch implements minimal necessary support for idnsSOASerial replication. >>> I investigating more advanced techniques, but I still see problems with locking >>> and so on. >>> >>> Anyway, this patch should be sufficient for now. >>> >>> Commit message: >>> >>> Add 389 DS plugin for special idnsSOASerial attribute handling >>> >>> Default value "1" is added to replicated idnsZone objects >>> if idnsSOASerial attribute is missing. >>> >>> https://fedorahosted.org/freeipa/ticket/3347 >>> >> >> I did not review the actual plugin yet, I just added a code to configure this >> plugin during new install and upgrade. Patch attached. >> >> >> Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copy&paste >> errors: >> >> >> +libipa_uuid_la_LIBADD = \ <<< libipa_uuid?? >> + $(LDAP_LIBS) \ >> + $(UUID_LIBS) \ >> + $(NULL) >> + >> >> +EXTRA_DIST = \ >> + $(app_DATA) \ <<< not defined, not needed (I will add it in my >> patch) >> + $(NULL) >> + > > Fixed version is attached. > Sending a rebased version of my installer/updater patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-384-2-configure-ipa_dns-ds-plugin-on-install-and-upgrade.patch Type: text/x-patch Size: 5082 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 13 15:59:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 16:59:25 +0100 Subject: [Freeipa-devel] [PATCH 0040] Make sure uninstall script prompts for reboot as last In-Reply-To: <51408055.3020906@redhat.com> References: <51408055.3020906@redhat.com> Message-ID: <5140A25D.2000202@redhat.com> On 03/13/2013 02:34 PM, Tomas Babej wrote: > Hi, > > Parts of client uninstall logic could be skipped in attended > uninstallation if user agreed to reboot the machine. Particulary, > the uninstall script would not try to remove /etc/ipa/default.conf > and therefore subsequent installation would fail, client being > detected as already configured. > > https://fedorahosted.org/freeipa/ticket/3462 > > Tomas > ACK. Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Wed Mar 13 16:23:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 17:23:22 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range In-Reply-To: <51403DE6.3050304@redhat.com> References: <51403D0D.5040307@redhat.com> <51403DE6.3050304@redhat.com> Message-ID: <5140A7FA.4070003@redhat.com> On 03/13/2013 09:50 AM, Tomas Babej wrote: > On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote: >> Hi, >> >> SID validation in idrange.py now enforces exact match on SIDs, thus >> one can no longer use SID of an object in a trusted domain as a >> trusted domain SID. >> >> https://fedorahosted.org/freeipa/ticket/3432 >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Just renamed the patch filename to follow the convention. > > Tomas > I do not think that the debug message is needed: + root_logger.error('No trusted domain with given SID found, ' + 'listing SIDS for all the trusted domains:') + for domain in self._domains: + root_logger.error('SID: %s' % self._domains[domain][1]) User will not see it anyway and he can easily get list of SIDs/domains with "ipa trust-find". Otherwise the patch looks and works fine. I would just consider renaming the method from is_trusted_sid_valid_domain to is_trusted_domain_sid_valid. Sounds better to me, but I have no strong feelings about that. Martin From mkosek at redhat.com Wed Mar 13 16:36:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Mar 2013 17:36:32 +0100 Subject: [Freeipa-devel] [PATCHES 0031-0032] Improve HBAC rule handling in selinuxusermap-add/mod/find In-Reply-To: <514062C3.1030400@redhat.com> References: <511294EB.9050805@redhat.com> <5112A797.805@redhat.com> <511519C4.30907@redhat.com> <5123EFC7.9020708@redhat.com> <5124B3FE.7000407@redhat.com> <512DD1A6.3070504@redhat.com> <514062C3.1030400@redhat.com> Message-ID: <5140AB10.3050302@redhat.com> On 03/13/2013 12:28 PM, Tomas Babej wrote: > On 02/27/2013 10:28 AM, Martin Kosek wrote: >> On 02/20/2013 12:31 PM, Tomas Babej wrote: >>> On 02/19/2013 10:33 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On 02/06/2013 07:57 PM, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this pair of patches improves HBAC rule handling in selinuxusermap >>>>>>> commands. >>>>>>> >>>>>>> Patch 0031 deals with: >>>>>>> https://fedorahosted.org/freeipa/ticket/3349 >>>>>>> >>>>>>> Patch 0032 takes care of: >>>>>>> https://fedorahosted.org/freeipa/ticket/3348 >>>>>>> >>>>>>> and is to be applied on top of Patch 0031. >>>>>>> >>>>>>> See commit messages for detailed info. >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> ACK for patch 0032. >>>>>> >>>>>> For patch 0031 we can't change the data type of an existing attribute. >>>>>> It will break backwards compatibility. Can you test with an older >>>>>> client to see if it cares (it may not care about the name of the >>>>>> type). If older clients will work then this is probably ok. >>>>>> >>>>>> I gather that seealso detected as a DN attribute and converted into a >>>>>> DN class and this is blowing up the Str validator? >>>>>> >>>>> Yes, that was exactly the case. >>>>>> rob >>>>> I added a workaround for older client versions, tested it with >>>>> freeipa-client/admintools 2.2, works as expeceted. >>>>> However, this only should be issue if there is older admintools package >>>>> on the client than on the server. >>>>> >>>>> Outline is such as follows: I added a new flag for DNParam seelalso >>>>> attribute, called 'allow_malformed' that allows any string to be passed >>>>> to DNParam. Its value gets wrapped in 'malformed=yes,value='. >>>>> This allows to parse out the string in selinuxusermap-add/mod >>>>> pre_callback out of the DN and search for the rule with such name so >>>>> that it's DN gets in LDAP instead. >>>>> >>>>> Updated patch attached. >>>>> >>>>> Tomas >>>> I like where you're going with this, just a couple of comments: >>>> >>>> 1. Should we come up with a more universal name for allow_malformed? Is this >>>> something that we should allow at a higher level? I was thinking allow_raw, >>>> or allow_non_dn, or something like that. >>> To me, allow_non_dn sounds is just as specific as allow_malformed, >>> they both refer to DN specifically. >>> >>> I'd go with allow_raw, if need for such pattern may eventually arise for >>> other parameter classes than DNParam. >>> >>> What do you mean by higher level, turning this hack into a feature >>> Param class? I don't see how this would work, each parameter >>> class that implements its own type validation as DNParam needs >>> to override _convert_scalar(). And in every such class we would need >>> to wrap our raw value so that it is represented in the type of this parameter, >>> as we do with DN(('malformed','yes'),('value',value)) now. >>> >>> Maybe we could skip type validation in _convert_scalar default >>> implementation or catch the error raised somehow, and let the type be >>> invalid, but I'm not aware of the consenquences. I would need to investigate. >>> Wouldn't it cause failure deeper in the framework? >>> >>> Or did you by higher level mean simply picking a more general name for the >>> flag so it can be reused in other parameter classes with the same name? >>>> 2. I think that if a bad dn is passed in as a Str the conversion into a DN >>>> won't be handled: >>>> >>>> + if 'allow_malformed' in self.flags: >>>> + dn = DN(('malformed','yes'),('value',value)) >>>> >>>> Should this be wrapped in a try/except to raise a ConversionError if it fails? >>> Yes, thanks for that catch. >>>> rob >>> Tomas >> Is it just me, or does the 0031 look overengineered? I think this is a general >> problem for each Str parameter which we then process/convert to DN in our >> pre_callbacks. >> >> selinuxusermap is one example where this does not work. This fix leaves other >> examples not working: >> >> # ipa trustconfig-mod --setattr "ipantfallbackprimarygroup=cn=Default SMB >> Group,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" >> ipa: ERROR: invalid 'ipantfallbackprimarygroup': must be Unicode text >> >> I would rather propose to not automatically encode DN of known attributes set >> by *attr: >> >> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >> index 1ebbe7a..e4b9834 100644 >> --- a/ipalib/plugins/baseldap.py >> +++ b/ipalib/plugins/baseldap.py >> @@ -768,12 +768,6 @@ last, after all sets and adds."""), >> # None means "delete this attribute" >> value = None >> >> - if ldap.has_dn_syntax(attr): >> - try: >> - value = DN(value) >> - except ValueError: >> - raise errors.InvalidSyntax(attr=attr) >> - >> if attr in newdict: >> if type(value) in (tuple,): >> newdict[attr] += list(value) >> >> I think this conversion is just done too early as this Str param is processed >> and converted later in the pre_callback, when needed. The code above introduced >> inconsistent processing of IPA attributes with DN syntax coming from regular >> option and from *attr option - Str >> >> When I did this change, both selinuxusermap-mod and trustconfig-mod started >> working: >> >> # ipa selinuxusermap-mod foo >> --setattr=seealso=ipaUniqueID=70e42636-75db-11e2-9df6-001a4a104edc,cn=hbac,dc=rhel64,dc=ad,dc=test >> >> ------------------------------- >> Modified SELinux User Map "foo" >> ------------------------------- >> Rule name: foo >> SELinux User: unconfined_u:s0-s0:c0.c1023 >> HBAC Rule: allow_all >> Enabled: TRUE >> # ipa selinuxusermap-mod foo --setattr=seealso=allow_all >> ipa: ERROR: no modifications to be performed >> # ipa selinuxusermap-mod foo --hbacrule=allow_all >> ipa: ERROR: no modifications to be performed >> >> You would just need to investigate if this change would not have other >> consequences. >> >> Martin > Attaching a version of the patch based on the Martin's proposition. > > This is indeed a simpler solution, that solves both problems. I investigated > whether removing > conversion into DN would have any consenquences. However, it turns out that > DNParam is > only used in contexts where usage of --*attr options is not allowed: > - cosentry class (no CLI) > - migration (no *attr options) > - ipacertificatesubjectbase in ipa config class (has no_update flag) > > I refactored the patch and retained the unit tests. > Please note that pushing this renders 0032 invalid. > > Tomas I think this approach is OK, I also did not discover any bug that it would be causing. ACK. Pushed to master, ipa-3-1. Martin From rcritten at redhat.com Wed Mar 13 17:06:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Mar 2013 13:06:24 -0400 Subject: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf In-Reply-To: <51404E4A.6050106@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> <513D9146.6080604@redhat.com> <513D9836.3060601@redhat.com> <51404E4A.6050106@redhat.com> Message-ID: <5140B210.905@redhat.com> Martin Kosek wrote: > On 03/11/2013 09:39 AM, Petr Spacek wrote: >> On 11.3.2013 09:09, Martin Kosek wrote: >>> On 03/08/2013 09:49 AM, Petr Spacek wrote: >>>> On 8.3.2013 00:14, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>>>>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>>>>> unnecessary Kerberos checks on BIND startup and can cause issues when >>>>>> KDC is not available. >>>>>> >>>>>> Both new and current IPA installations are updated. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3429 >>>>>> >>>>> >>>>> Still reviewing this but I noticed that after upgrading my 3.1.99 server >>>>> pre-patch to with with-patch version the connections argument in named.conf >>>>> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >>>>> during the initial install too? >>>> >>>> For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections >>>> should not harm. >>>> >>>> Higher value should allow higher level of parallelism, it is one of tuning >>>> parameters. Value 4 was necessary to prevent deadlocks in some previous >>>> versions of bind-dyndb-ldap. >>>> >>> >>> Previously, when I implemented the upgrade script, I set connections arg only >>> if it was present in named.conf and thus bind-dyndb-ldap could not use a >>> reasonable default on its own decision. >>> >>> This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections >>> is set always. Rob is correct, that in that case we might want to add it to >>> named.conf by default to make it consistent... or we could also fix upgrade >>> script to change connections only if it is present in named.conf. >>> >>> Petr, what does make more sense bind-dyndb-ldap wise? >> >> Default values should work. Personally I would include only "override" values >> in named.conf, but technically it doesn't matter. >> >> Note: Latest bind-dyndb-ldap versions refuse to start if configuration is >> insane. Fatal error will point admin to errors in configuration and should >> prevent surprises from auto-magically changed values. >> >> Invalid configurations - examples: >> connections < 1 >> connections < 2 && psearch is enabled >> serial_autoincrement enabled && psearch disabled >> > > Ok, lets set the connections argument only if it is in named.conf _and_ it is > lower than the required minimum. All patches attached. > > Martin > This works ok if the format of named.conf is stable. If, for example, there are extra spaces between options and { then the values are not updated. This is nothing new with this patch, our previous code was also space dependent (augeas will address this eventually) I just wonder: Should we log if a warning if a change has not been applied? rob From rcritten at redhat.com Wed Mar 13 17:43:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Mar 2013 13:43:27 -0400 Subject: [Freeipa-devel] [PATCH] 381, 387 Preserve order of servers in ipa-client-install In-Reply-To: <5140896B.9010506@redhat.com> References: <51388F87.6040200@redhat.com> <51389F08.1030607@redhat.com> <513DC2BB.4020905@redhat.com> <51408609.9030701@redhat.com> <5140896B.9010506@redhat.com> Message-ID: <5140BABF.3000404@redhat.com> Martin Kosek wrote: > On 03/13/2013 02:58 PM, Martin Kosek wrote: >> On 03/11/2013 12:40 PM, Martin Kosek wrote: >>> On 03/07/2013 03:07 PM, Petr Viktorin wrote: >>>> On 03/07/2013 02:00 PM, Martin Kosek wrote: >>>>> When multiple servers are passed via --server option, ipadiscovery >>>>> module changed its order. Make sure that we preserve it. >>>>> >>>>> Also make sure that user is always warned when a tested server is >>>>> not available as then the server will be excluded from the fixed >>>>> server list. >>>> >>>> The message doesn't actually say that the server will be removed. It would be >>>> nice if it did. >>>> >>>> Otherwise, ACK. >>> >>> Sending a patch with improved logging. User should now be more clear what >>> server is failing to verify (and why). >>> >>>> >>>>> ------ >>>>> >>>>> When working on this ticket I was thinking - do we make the right thing we >>>>> deliberately remove a server from user-provided server list just because we >>>>> cannot connect to it at the moment if discovery? It may just be temporarily >>>>> down or something. >>>>> >>>>> Maybe we should preserve the original --server list in this case and use this >>>>> list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other >>>>> active configuration commands we would have to use only the valid servers so >>>>> that the we do not hit the server that is currently down. >>>>> >>>>> Martin >>>> >>>> Good point, this deserves a ticket. >>>> >>> >>> Rob, do you think this deserves to be changed? Or is this behavior indeed >>> intended? >>> >>> Martin >>> >> >> Sending a rebased patch 381, logging was also improved. Client discovery >> logging now looks like that: >> >> # ipa-client-install >> Skip vm-024.idm.lab.bos.redhat.com: not an IPA server >> Skip doesnotexist.test: cannot verify if this is an IPA server >> Discovery was successful! >> Hostname: vm-148.idm.lab.bos.redhat.com >> Realm: IDM.LAB.BOS.REDHAT.COM >> DNS Domain: idm.lab.bos.redhat.com >> IPA Server: vm-037.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]: >> ... >> >> I also attached a related fix for redundant discoveries with fixed server list >> (found that when testing logging), details are in the patch description. >> >> Martin >> > > I just creating a conflict in my patch numbering, renaming 386 to 387... > > Martin > ACK. I think we probably want this in the 3-1 branch too but some merging is needed, so I'll leave that up to you Martin :-) rob From rcritten at redhat.com Wed Mar 13 18:07:21 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Mar 2013 14:07:21 -0400 Subject: [Freeipa-devel] [PATCH] 383 Use new 389-ds-base cleartext password API In-Reply-To: <5139D543.3060101@redhat.com> References: <5139D543.3060101@redhat.com> Message-ID: <5140C059.70004@redhat.com> Martin Kosek wrote: > The way how unhashed password is stored in the entry was changed in > 389-ds-base-1.3.0, it is now stored in an entry extension rather than > in a magic attribute unhashed#user#password. New API using an entry > extension was introduced. ipa-pwd-extop should take advantage of the > new API as the old one will be removed in 389-ds-base-1.3.1. > > https://fedorahosted.org/freeipa/ticket/3439 > > --- > This patch is based on Noriko's candidate patch in 389-ds-base ticket. I > tested various password scenarios including migration of users with > cleartext/hashed passwords, everything worked OK. > ACK, pushed to master rob From rcritten at redhat.com Wed Mar 13 19:12:09 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Mar 2013 15:12:09 -0400 Subject: [Freeipa-devel] [PATCH] 382 Do not hide idrange-add errors when adding trust In-Reply-To: <5138A71C.6070606@redhat.com> References: <5138A71C.6070606@redhat.com> Message-ID: <5140CF89.9070707@redhat.com> Martin Kosek wrote: > We catched all errors that could be raised by idrange-add command and > just raised an uncomprehensible ValidationError. This could hide > a real underlying problem and make the debugging harder. > > We should rather just let the command raise the real error (which > will be already a PublicError). > > https://fedorahosted.org/freeipa/ticket/3288 > > --- > > NOTE: I discussed this issue with tsunamie (ticket logger). He hit this error > in some early FreeIPA 3.0 release and he does not hit it any more. I also did > not reproduce it with current master so I am just sending a patch to allow > us/user to see the reason of the range error in case it occurs again. > > Martin Seems reasonable to me. I wasn't able to reproduce this either and it makes sense to just raise whatever ValidationErrors were discovered. ACK. Pushed to master rob From mkosek at redhat.com Thu Mar 14 08:48:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 09:48:52 +0100 Subject: [Freeipa-devel] [PATCH] 381, 387 Preserve order of servers in ipa-client-install In-Reply-To: <5140BABF.3000404@redhat.com> References: <51388F87.6040200@redhat.com> <51389F08.1030607@redhat.com> <513DC2BB.4020905@redhat.com> <51408609.9030701@redhat.com> <5140896B.9010506@redhat.com> <5140BABF.3000404@redhat.com> Message-ID: <51418EF4.8090405@redhat.com> On 03/13/2013 06:43 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/13/2013 02:58 PM, Martin Kosek wrote: >>> On 03/11/2013 12:40 PM, Martin Kosek wrote: >>>> On 03/07/2013 03:07 PM, Petr Viktorin wrote: >>>>> On 03/07/2013 02:00 PM, Martin Kosek wrote: >>>>>> When multiple servers are passed via --server option, ipadiscovery >>>>>> module changed its order. Make sure that we preserve it. >>>>>> >>>>>> Also make sure that user is always warned when a tested server is >>>>>> not available as then the server will be excluded from the fixed >>>>>> server list. >>>>> >>>>> The message doesn't actually say that the server will be removed. It would be >>>>> nice if it did. >>>>> >>>>> Otherwise, ACK. >>>> >>>> Sending a patch with improved logging. User should now be more clear what >>>> server is failing to verify (and why). >>>> >>>>> >>>>>> ------ >>>>>> >>>>>> When working on this ticket I was thinking - do we make the right thing we >>>>>> deliberately remove a server from user-provided server list just because we >>>>>> cannot connect to it at the moment if discovery? It may just be temporarily >>>>>> down or something. >>>>>> >>>>>> Maybe we should preserve the original --server list in this case and use >>>>>> this >>>>>> list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other >>>>>> active configuration commands we would have to use only the valid servers so >>>>>> that the we do not hit the server that is currently down. >>>>>> >>>>>> Martin >>>>> >>>>> Good point, this deserves a ticket. >>>>> >>>> >>>> Rob, do you think this deserves to be changed? Or is this behavior indeed >>>> intended? >>>> >>>> Martin >>>> >>> >>> Sending a rebased patch 381, logging was also improved. Client discovery >>> logging now looks like that: >>> >>> # ipa-client-install >>> Skip vm-024.idm.lab.bos.redhat.com: not an IPA server >>> Skip doesnotexist.test: cannot verify if this is an IPA server >>> Discovery was successful! >>> Hostname: vm-148.idm.lab.bos.redhat.com >>> Realm: IDM.LAB.BOS.REDHAT.COM >>> DNS Domain: idm.lab.bos.redhat.com >>> IPA Server: vm-037.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]: >>> ... >>> >>> I also attached a related fix for redundant discoveries with fixed server list >>> (found that when testing logging), details are in the patch description. >>> >>> Martin >>> >> >> I just creating a conflict in my patch numbering, renaming 386 to 387... >> >> Martin >> > > ACK. > > I think we probably want this in the 3-1 branch too but some merging is needed, > so I'll leave that up to you Martin :-) > > rob > Thanks. I rebased that for ipa-3-1 (and did some smoke-testing), it works OK there too. Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Thu Mar 14 09:32:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 10:32:25 +0100 Subject: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf In-Reply-To: <5140B210.905@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> <513D9146.6080604@redhat.com> <513D9836.3060601@redhat.com> <51404E4A.6050106@redhat.com> <5140B210.905@redhat.com> Message-ID: <51419929.8060107@redhat.com> On 03/13/2013 06:06 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/11/2013 09:39 AM, Petr Spacek wrote: >>> On 11.3.2013 09:09, Martin Kosek wrote: >>>> On 03/08/2013 09:49 AM, Petr Spacek wrote: >>>>> On 8.3.2013 00:14, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>>>>>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>>>>>> unnecessary Kerberos checks on BIND startup and can cause issues when >>>>>>> KDC is not available. >>>>>>> >>>>>>> Both new and current IPA installations are updated. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3429 >>>>>>> >>>>>> >>>>>> Still reviewing this but I noticed that after upgrading my 3.1.99 server >>>>>> pre-patch to with with-patch version the connections argument in named.conf >>>>>> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >>>>>> during the initial install too? >>>>> >>>>> For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections >>>>> should not harm. >>>>> >>>>> Higher value should allow higher level of parallelism, it is one of tuning >>>>> parameters. Value 4 was necessary to prevent deadlocks in some previous >>>>> versions of bind-dyndb-ldap. >>>>> >>>> >>>> Previously, when I implemented the upgrade script, I set connections arg only >>>> if it was present in named.conf and thus bind-dyndb-ldap could not use a >>>> reasonable default on its own decision. >>>> >>>> This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections >>>> is set always. Rob is correct, that in that case we might want to add it to >>>> named.conf by default to make it consistent... or we could also fix upgrade >>>> script to change connections only if it is present in named.conf. >>>> >>>> Petr, what does make more sense bind-dyndb-ldap wise? >>> >>> Default values should work. Personally I would include only "override" values >>> in named.conf, but technically it doesn't matter. >>> >>> Note: Latest bind-dyndb-ldap versions refuse to start if configuration is >>> insane. Fatal error will point admin to errors in configuration and should >>> prevent surprises from auto-magically changed values. >>> >>> Invalid configurations - examples: >>> connections < 1 >>> connections < 2 && psearch is enabled >>> serial_autoincrement enabled && psearch disabled >>> >> >> Ok, lets set the connections argument only if it is in named.conf _and_ it is >> lower than the required minimum. All patches attached. >> >> Martin >> > > This works ok if the format of named.conf is stable. > > If, for example, there are extra spaces between options and { then the values > are not updated. This is nothing new with this patch, our previous code was > also space dependent (augeas will address this eventually) > > I just wonder: Should we log if a warning if a change has not been applied? > > rob There is already a warning if we could not match tkey-gssapi-credential, tkey-domain or tkey-gssapi-keytab. It would look like that: # ipa-upgradeconfig --quiet Either tkey-gssapi-credential or tkey-domain is missing in /etc/named.conf. Skip update. At least I made our crappy named.conf parser more resilient to spaces in section start (i.e. it should now work with "options {" and made the regular expression object naming more consistent. But you are right, this will be eventually improved by augueas. Important thing for now is, that our updater works fine with our template named.conf we ship with freeipa including user changes, if user does not go too wild into breaking what's already there... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-376-2-update-named.conf-parser.patch Type: text/x-patch Size: 5978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-377-2-use-tkey-gssapi-keytab-in-named.conf.patch Type: text/x-patch Size: 5121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-385-2-do-not-force-named-connections-on-upgrades.patch Type: text/x-patch Size: 1188 bytes Desc: not available URL: From tbabej at redhat.com Thu Mar 14 09:48:58 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 14 Mar 2013 10:48:58 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range In-Reply-To: <5140A7FA.4070003@redhat.com> References: <51403D0D.5040307@redhat.com> <51403DE6.3050304@redhat.com> <5140A7FA.4070003@redhat.com> Message-ID: <51419D0A.9090509@redhat.com> On 03/13/2013 05:23 PM, Martin Kosek wrote: > On 03/13/2013 09:50 AM, Tomas Babej wrote: >> On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote: >>> Hi, >>> >>> SID validation in idrange.py now enforces exact match on SIDs, thus >>> one can no longer use SID of an object in a trusted domain as a >>> trusted domain SID. >>> >>> https://fedorahosted.org/freeipa/ticket/3432 >>> >>> Tomas >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Just renamed the patch filename to follow the convention. >> >> Tomas >> > I do not think that the debug message is needed: > > + root_logger.error('No trusted domain with given SID found, ' > + 'listing SIDS for all the trusted domains:') > + for domain in self._domains: > + root_logger.error('SID: %s' % self._domains[domain][1]) > > User will not see it anyway and he can easily get list of SIDs/domains with > "ipa trust-find". > > Otherwise the patch looks and works fine. I would just consider renaming the > method from is_trusted_sid_valid_domain to is_trusted_domain_sid_valid. Sounds > better to me, but I have no strong feelings about that. > > Martin Both fixed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0039-2-Enforce-exact-SID-match-when-adding-or-modifying-a-I.patch Type: text/x-patch Size: 5148 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 14 13:41:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 14:41:08 +0100 Subject: [Freeipa-devel] [PATCH] 388-389 Improve client install LDAP cert retrieval fallback Message-ID: <5141D374.5090306@redhat.com> [freeipa-mkosek-388-use-temporary-ccache-in-ipa-client-install.patch]: ipa-client-install failed if user had set his own KRB5CCNAME in his environment. Use a temporary CCACHE for the installer to avoid these kind of errors. [freeipa-mkosek-389-improve-client-install-ldap-cert-retrieval-fallback.patch]: CA certificate retrieval function did not fallback from LDAP to HTTP based retrieval in case of an LDAP error, when for example GSSAPI authentication failed. ------------- Sending Fedora 18 client installation fixes as per https://bugzilla.redhat.com/show_bug.cgi?id=920716#c10 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-388-use-temporary-ccache-in-ipa-client-install.patch Type: text/x-patch Size: 1829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-389-improve-client-install-ldap-cert-retrieval-fallback.patch Type: text/x-patch Size: 1244 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 14 14:08:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 15:08:09 +0100 Subject: [Freeipa-devel] [PATCH] 0006 Remove check for alphabetic only characters from domain name validation In-Reply-To: <513DC7DA.1000003@redhat.com> References: <511E44A9.9090509@redhat.com> <51221027.7050803@redhat.com> <20130218114750.GC27418@localhost.localdomain> <512219D7.9000909@redhat.com> <51249F6E.7030005@redhat.com> <51273810.9060800@redhat.com> <5127889F.9020202@redhat.com> <512DD8BC.2080904@redhat.com> <513DC7DA.1000003@redhat.com> Message-ID: <5141D9C9.5030208@redhat.com> On 03/11/2013 01:02 PM, Ana Krivokapic wrote: > On 02/27/2013 10:58 AM, Martin Kosek wrote: >> On 02/22/2013 04:02 PM, Ana Krivokapic wrote: >>> On 02/22/2013 10:19 AM, Petr Spacek wrote: >>>> On 20.2.2013 11:03, Ana Krivokapic wrote: >>>>> On 02/18/2013 01:08 PM, Martin Kosek wrote: >>>>>> On 02/18/2013 12:47 PM, Sumit Bose wrote: >>>>>>> On Mon, Feb 18, 2013 at 12:27:35PM +0100, Petr Spacek wrote: >>>>>>>> On 15.2.2013 15:22, Ana Krivokapic wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> The .isalpha() check in validate_domain_name() was too strict, >>>>>>>>> causing some commands like ipa dnsrecord-add to fail. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3385 >>>>>>>> I would add --force option rather than removing whole check, if >>>>>>>> it's possible. >>>>>>>> >>>>>>>> Would it be possible to mention RFC in the error message? Something >>>>>>>> like _('top level domain label must be alphabetic (RFC 1123 section >>>>>>>> 2.1)') >>>>>>>> ? >>>>>>>> >>>>>>>> IMHO it is handy, because it educates users. >>>>>>> The problem is that this check is always done on the last component of >>>>>>> the domain_name even if it is just a sub-domain of the FreeIPA domain, >>>>>>> where e.g. numbers are valid characters. >>>>>>> >>>>>>> At the beginning of validate_domain_name() a trailing '.' is stripped >>>>>>> away. iirc the trailing '.' is an indication for a complete, fully >>>>>>> qualified name. Would it work if the presence of the trailing '.' is >>>>>>> saved and the check is only done if there was a '.'? >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>> Sure. Though I am now not 100% sure that some IPA functions do not >>>>>> use this >>>>>> validator with a fqdn hostname without trailing dot. If not, I am >>>>>> for fixing >>>>>> this function as Sumit and Petr suggested. >>>>>> >>>>>> Martin >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> After some thought, I decided to change the approach. >>>>> >>>>> As pointed out by Sumit, the problem was that the validate_domain_name() >>>>> function did not distinguish between fqdn and non-fqdn domains >>>>> (subdomains of the IPA domain). The trailing dot is not a clear >>>>> indication either, because some IPA functions use this validator with an >>>>> fqdn without the trailing dot. >>>>> >>>>> To fix this, I introduced an additional parameter to this function - a >>>>> flag which indicates whether the domain name is an fqdn or not. The is >>>>> .isalpha() check is then performed only in the case of an fqdn. >>>>> >>>>> I also improved the error message to mention the relevant RFC, as >>>>> suggested by Petr. >>>> Please don't forget to add --force switch. It could be handy. >>>> >>> I added the --force switch to ipa dnsrecord-add and opened a new ticket >>> to handle the rest of the ipa commands that use domain name validation: >>> https://fedorahosted.org/freeipa/ticket/3455 >>> >>> Updated patch is attached. >>> >> This patch fixed validation only partially. The --force flag you made available >> will not allow admin to for example add a zone "example.zone1" which >> technically will be resolvable, it is just not a good practice: >> >> # ipa dnszone-add example.zone1 --name-server `hostname`. --force >> ipa: ERROR: invalid 'name': top level domain label must be alphabetic (RFC 1123 >> section 2.1) >> >> To enable this, I think you would need to not postpone the validation to DNS >> zone pre_callback as you could not check --force flag presence right in the >> idnsname parameter validator. >> >> We may also want to change --force flag label, it now talks only about NS >> record validation, but we now expanded it a bit, so the label would need to be >> more general. >> >> Martin > > I added the fix for dnszone-add and edited the label of the --force flag > to make it more general. > The zone with this name can be created even without the --force flag. # ipa dnszone-add example.zone1 --name-server `hostname`. Administrator e-mail address [hostmaster.example.zone1.]: >>> Administrator e-mail address: top level domain label must be alphabetic (RFC 1123 section 2.1) Administrator e-mail address [hostmaster.example.zone1.]: hostmaster.example.zone. Zone name: example.zone1 Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.example.zone. SOA serial: 1363268183 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant IDM.LAB.BOS.REDHAT.COM krb5-self * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; I thought that the check would only be surpassed with the --force flag. All this struggle with this patch makes me thinking if we are not making it too complicated. I am rather inclined to drop this particular check altogether. I do not see that much harm if user creates an IPA managed zone "example.zone1". Petr, what is your opinion on dropping this check in IPA? Is it OK to drop it? Martin From mkosek at redhat.com Thu Mar 14 14:22:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 15:22:06 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range In-Reply-To: <51419D0A.9090509@redhat.com> References: <51403D0D.5040307@redhat.com> <51403DE6.3050304@redhat.com> <5140A7FA.4070003@redhat.com> <51419D0A.9090509@redhat.com> Message-ID: <5141DD0E.5080700@redhat.com> On 03/14/2013 10:48 AM, Tomas Babej wrote: > On 03/13/2013 05:23 PM, Martin Kosek wrote: >> On 03/13/2013 09:50 AM, Tomas Babej wrote: >>> On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote: >>>> Hi, >>>> >>>> SID validation in idrange.py now enforces exact match on SIDs, thus >>>> one can no longer use SID of an object in a trusted domain as a >>>> trusted domain SID. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3432 >>>> >>>> Tomas >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Just renamed the patch filename to follow the convention. >>> >>> Tomas >>> >> I do not think that the debug message is needed: >> >> + root_logger.error('No trusted domain with given SID found, ' >> + 'listing SIDS for all the trusted domains:') >> + for domain in self._domains: >> + root_logger.error('SID: %s' % self._domains[domain][1]) >> >> User will not see it anyway and he can easily get list of SIDs/domains with >> "ipa trust-find". >> >> Otherwise the patch looks and works fine. I would just consider renaming the >> method from is_trusted_sid_valid_domain to is_trusted_domain_sid_valid. Sounds >> better to me, but I have no strong feelings about that. >> >> Martin > Both fixed. > > Tomas > ACK. Pushed to master, ipa-3-1. Martin From rcritten at redhat.com Thu Mar 14 14:47:07 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 10:47:07 -0400 Subject: [Freeipa-devel] [PATCH] 0002 Add missing error message when adding duplicate external member to group In-Reply-To: <51264F5F.10209@redhat.com> References: <50EEE184.6080804@redhat.com> <5123E4B5.2060702@redhat.com> <51264F5F.10209@redhat.com> Message-ID: <5141E2EB.7030509@redhat.com> Ana Krivokapic wrote: > On 02/19/2013 09:46 PM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> When adding a duplicate member to a group, an error message is issued, >>> informing the user that the entry is already a member of the group. This >>> message was missing in case of an external member. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/3254 >> >> This works ok but the sister command, group-remove-member, has the >> same problem. Can you add a fix there as well? >> >> I don't know if there is a way to add a unit test for this since the >> external member is validated meaning we'd need to set up trusts as >> well. It might be nice to have an optional test that can be run when a >> trust is configured to avoid regressions. >> >> rob >> > I fixed the group-remove-member command and added unit tests which can > be run when the trust is established (they will be skipped when the > trust is not established). > > I also noticed that, in contrast to group-add-member, > group-remove-member did not allow the format 'AD\name' or > 'name at ad.domain.com' for the --external option. I included this fix in > the patch, so the two user friendly formats are now supported. > > Updated patch is attached. > Remove member is still not working for me: $ ipa group-remove-member ad_admins_external --external 'AD\Domain Admins' [member user]: [member group]: Group name: ad_admins_external Description: ad.greyoak.com admins external map External member: S-1-5-21-2065961537-1042332738-1594543940-512 $ ipa group-remove-member ad_admins_external --external 'S-1-5-21-2065961537-1042332738-1594543940-512' [member user]: [member group]: Group name: ad_admins_external Description: ad.greyoak.com admins external map External member: --------------------------- Number of members removed 1 --------------------------- Removing it again doesn't return an error: $ ipa group-remove-member ad_admins_external --external 'S-1-5-21-2065961537-1042332738-1594543940-512' [member user]: [member group]: Group name: ad_admins_external Description: ad.greyoak.com admins external map --------------------------- Number of members removed 0 --------------------------- rob From rcritten at redhat.com Thu Mar 14 14:51:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 10:51:10 -0400 Subject: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf In-Reply-To: <51419929.8060107@redhat.com> References: <5135D2E6.1000501@redhat.com> <51391F6A.7000303@redhat.com> <5139A624.50004@redhat.com> <513D9146.6080604@redhat.com> <513D9836.3060601@redhat.com> <51404E4A.6050106@redhat.com> <5140B210.905@redhat.com> <51419929.8060107@redhat.com> Message-ID: <5141E3DE.6050507@redhat.com> Martin Kosek wrote: > On 03/13/2013 06:06 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/11/2013 09:39 AM, Petr Spacek wrote: >>>> On 11.3.2013 09:09, Martin Kosek wrote: >>>>> On 03/08/2013 09:49 AM, Petr Spacek wrote: >>>>>> On 8.3.2013 00:14, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential >>>>>>>> and tkey-domain and replace them with tkey-gssapi-keytab which avoids >>>>>>>> unnecessary Kerberos checks on BIND startup and can cause issues when >>>>>>>> KDC is not available. >>>>>>>> >>>>>>>> Both new and current IPA installations are updated. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3429 >>>>>>>> >>>>>>> >>>>>>> Still reviewing this but I noticed that after upgrading my 3.1.99 server >>>>>>> pre-patch to with with-patch version the connections argument in named.conf >>>>>>> got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4 >>>>>>> during the initial install too? >>>>>> >>>>>> For 3.2 it doesn't matter. Anything >= 2 should be okay, but more connections >>>>>> should not harm. >>>>>> >>>>>> Higher value should allow higher level of parallelism, it is one of tuning >>>>>> parameters. Value 4 was necessary to prevent deadlocks in some previous >>>>>> versions of bind-dyndb-ldap. >>>>>> >>>>> >>>>> Previously, when I implemented the upgrade script, I set connections arg only >>>>> if it was present in named.conf and thus bind-dyndb-ldap could not use a >>>>> reasonable default on its own decision. >>>>> >>>>> This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections >>>>> is set always. Rob is correct, that in that case we might want to add it to >>>>> named.conf by default to make it consistent... or we could also fix upgrade >>>>> script to change connections only if it is present in named.conf. >>>>> >>>>> Petr, what does make more sense bind-dyndb-ldap wise? >>>> >>>> Default values should work. Personally I would include only "override" values >>>> in named.conf, but technically it doesn't matter. >>>> >>>> Note: Latest bind-dyndb-ldap versions refuse to start if configuration is >>>> insane. Fatal error will point admin to errors in configuration and should >>>> prevent surprises from auto-magically changed values. >>>> >>>> Invalid configurations - examples: >>>> connections < 1 >>>> connections < 2 && psearch is enabled >>>> serial_autoincrement enabled && psearch disabled >>>> >>> >>> Ok, lets set the connections argument only if it is in named.conf _and_ it is >>> lower than the required minimum. All patches attached. >>> >>> Martin >>> >> >> This works ok if the format of named.conf is stable. >> >> If, for example, there are extra spaces between options and { then the values >> are not updated. This is nothing new with this patch, our previous code was >> also space dependent (augeas will address this eventually) >> >> I just wonder: Should we log if a warning if a change has not been applied? >> >> rob > > There is already a warning if we could not match tkey-gssapi-credential, > tkey-domain or tkey-gssapi-keytab. It would look like that: > > # ipa-upgradeconfig --quiet > Either tkey-gssapi-credential or tkey-domain is missing in /etc/named.conf. > Skip update. > > At least I made our crappy named.conf parser more resilient to spaces in > section start (i.e. it should now work with "options {" and made the > regular expression object naming more consistent. But you are right, this will > be eventually improved by augueas. > > Important thing for now is, that our updater works fine with our template > named.conf we ship with freeipa including user changes, if user does not go too > wild into breaking what's already there... > > Martin > ACK, pushed to master x 3. rob From pvoborni at redhat.com Thu Mar 14 15:08:54 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 14 Mar 2013 16:08:54 +0100 Subject: [Freeipa-devel] [WIP] Web UI Refactoring & plugins effort - current state In-Reply-To: <51362CB7.8000900@redhat.com> References: <51362CB7.8000900@redhat.com> Message-ID: <5141E806.2020001@redhat.com> Update of the effort: Current state in git://fedorapeople.org/~pvoborni/freeipa.git branch menu. Patches will be squashed later. Fixed regressions: * facet refreshed only when pkeys and args are changed * menu has 'memory'. One will return to previously selected facet of entity. * fixed displaying of 3rd level of navigation in dns, automember * singleton objects (config, dnsconfig) update doesn't raise error + Some internal changes -mostly removal of get_primary_key calls. + Fixed error message while adding group external member - this might not be regression caused by these patches (didn't check). Known problems: * dirty dialog is displayed twice On 03/05/2013 06:34 PM, Petr Vobornik wrote: > Hello, > > Sending current state of $subj. It's main purpose is to get rough review > and design comments. > > Attaching patches of work done. > > The effort is documented at: http://pvoborni.fedorapeople.org/doc > > Navigation refactoring > ---------------------- > * http://pvoborni.fedorapeople.org/doc/navigation.html > * almost implemented > > Plugin design > ------------- > * http://pvoborni.fedorapeople.org/doc/plugins.html > * nothing implemented > > Known problems > -------------- > * http://pvoborni.fedorapeople.org/doc/known_problems.html > > Others > ------ > As a part of the effort I change some Web UI internals. Some of them are > documented on pages: > * http://pvoborni.fedorapeople.org/doc/phases.html > * http://pvoborni.fedorapeople.org/doc/facet_public_state.html > * http://pvoborni.fedorapeople.org/doc/registers.html > > NOTE: all doc pages are written in asciidoc, change extension from .html > to .txt to get the source. I use it because our wiki doesn't handle > source codes well. I plan to gradually create complete documentation of > Web UI. > > I will create design page in our wiki later - should be less verbose. > > Update testing server with: > $ util/sync.sh --host root at host.test -cC --dojo --misc --strings --restart > $ util/sync.sh --host root at host.test -fc > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr Vobornik From rcritten at redhat.com Thu Mar 14 15:33:55 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 11:33:55 -0400 Subject: [Freeipa-devel] [PATCH] 386 Fix client discovery crash In-Reply-To: <5140717B.5010302@redhat.com> References: <5140717B.5010302@redhat.com> Message-ID: <5141EDE3.5080704@redhat.com> Martin Kosek wrote: > Client discovery LDAP search assumes that the remote LDAP server will > send an entry with lowercase attribute names. When it discovers for > example on openldap which sends it in CamelCase, the discovery > crashes. > > Convert retrieved entry to CIDict to avoid this error. Also add > a fallback to ipa-client-install server discovery process so that > it rather skips the faulty server instead of crashing. > > https://fedorahosted.org/freeipa/ticket/3446 > > ------- > > NOTE: this is just a hotfix for IPA 3.1.x (ipa-3-1 branch). Proper fix was done > by Petr Viktorin (patches 0191-0195). > > Martin ACK. I'll let you push this, it didn't apply cleanly to my 3-1 branch. rob From mkosek at redhat.com Thu Mar 14 15:35:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Mar 2013 16:35:32 +0100 Subject: [Freeipa-devel] [PATCH] 1089 fix some ipa-replica-manage error handling In-Reply-To: <5131328A.70801@redhat.com> References: <5131328A.70801@redhat.com> Message-ID: <5141EE44.1090408@redhat.com> On 03/01/2013 11:58 PM, Rob Crittenden wrote: > I found a couple of problems in error handling in ipa-replica-manage when doing > some oddball testing. See the ticket for full details. > > This may apply by itself but in my tree it exists after patch 1088. > > rob > Looks and works OK, ACK! I think it would make sense to also rebase it for ipa-3-1 and thus for future Fedora 18 release. In your first diff chunk, you would just need to catch for NO_SUCH_OBJECT instead of errors.NotFound... Martin From rcritten at redhat.com Thu Mar 14 15:45:51 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 11:45:51 -0400 Subject: [Freeipa-devel] [PATCH] 0002 Add missing error message when adding duplicate external member to group In-Reply-To: <5141E2EB.7030509@redhat.com> References: <50EEE184.6080804@redhat.com> <5123E4B5.2060702@redhat.com> <51264F5F.10209@redhat.com> <5141E2EB.7030509@redhat.com> Message-ID: <5141F0AF.6060605@redhat.com> Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 02/19/2013 09:46 PM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> When adding a duplicate member to a group, an error message is issued, >>>> informing the user that the entry is already a member of the group. >>>> This >>>> message was missing in case of an external member. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3254 >>> >>> This works ok but the sister command, group-remove-member, has the >>> same problem. Can you add a fix there as well? >>> >>> I don't know if there is a way to add a unit test for this since the >>> external member is validated meaning we'd need to set up trusts as >>> well. It might be nice to have an optional test that can be run when a >>> trust is configured to avoid regressions. >>> >>> rob >>> >> I fixed the group-remove-member command and added unit tests which can >> be run when the trust is established (they will be skipped when the >> trust is not established). >> >> I also noticed that, in contrast to group-add-member, >> group-remove-member did not allow the format 'AD\name' or >> 'name at ad.domain.com' for the --external option. I included this fix in >> the patch, so the two user friendly formats are now supported. >> >> Updated patch is attached. >> Actually applying the patch makes testing it a lot easier. Ignore my previous e-mail. Things are working fine, including tests (both with and without trust). ACK pushed to master rob From rcritten at redhat.com Thu Mar 14 18:00:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 14:00:03 -0400 Subject: [Freeipa-devel] [PATCH] 1089 fix some ipa-replica-manage error handling In-Reply-To: <5141EE44.1090408@redhat.com> References: <5131328A.70801@redhat.com> <5141EE44.1090408@redhat.com> Message-ID: <51421023.1020903@redhat.com> Martin Kosek wrote: > On 03/01/2013 11:58 PM, Rob Crittenden wrote: >> I found a couple of problems in error handling in ipa-replica-manage when doing >> some oddball testing. See the ticket for full details. >> >> This may apply by itself but in my tree it exists after patch 1088. >> >> rob >> > > Looks and works OK, ACK! > > I think it would make sense to also rebase it for ipa-3-1 and thus for future > Fedora 18 release. In your first diff chunk, you would just need to catch for > NO_SUCH_OBJECT instead of errors.NotFound... I ended up catching both, to be consistent with similar excepts. In my testing though getList returned errors.NotFound on failure. Pushed to master and ipa-3-1 rob From rcritten at redhat.com Thu Mar 14 18:32:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Mar 2013 14:32:49 -0400 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <5138DA82.1010601@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> <51387CE4.2040001@redhat.com> <513893EC.2040101@redhat.com> <5138C136.9000504@redhat.com> <5138DA82.1010601@redhat.com> Message-ID: <514217D1.2080001@redhat.com> Petr Vobornik wrote: > On 03/07/2013 05:32 PM, Petr Vobornik wrote: >> On 03/07/2013 02:19 PM, Ana Krivokapic wrote: >>> On 03/07/2013 12:41 PM, Petr Vobornik wrote: >>>> On 03/06/2013 08:26 PM, Ana Krivokapic wrote: >>>>> On 03/06/2013 10:40 AM, Petr Vobornik wrote: >>>>>> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>>>>>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>>>>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>>>>>> Add support for Realm Domains to web UI. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>>>>>> >> >> 8><----------------------- >> >>>> >>>> Almost there, as discussed in person: >>>> >>>> 1. following strings should be add to and obtained from internal.py >>>> plugin: >>>> title: 'Check DNS', >>>> message: 'Do you also want to perform DNS check?', >>>> ok_label: 'Check DNS', >>>> >>>> >>>> 2. the server plugin should report all dns resolution failures, not >>>> just the first one. >>> >>> Fixed, updated patch is attached. >>> >> Works fine, but you forgot to update all related tests >> (s/domain/domains/): >> >>> ====================================================================== >>> FAIL: test_realmdomains[8]: realmdomains_mod: Try to replace list of >>> realm domains with a list with an invalid domain "doesnotexist.test" >>> ---------------------------------------------------------------------- >>> 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/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>> line 264, in >>> func = lambda: self.check(nice, **test) >>> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>> line 278, in check >>> self.check_exception(nice, cmd, args, options, expected) >>> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>> line 304, in check_exception >>> assert_deepequal(expected.strerror, e.strerror) >>> File "/home/pvoborni/dev/freeipa/tests/util.py", line 343, in >>> assert_deepequal >>> VALUE % (doc, expected, got, stack) >>> AssertionError: assert_deepequal: expected != got. >>> >>> expected = u"invalid 'domain': no SOA or NS records found for >>> domains: doesnotexist.test" >>> got = u"invalid 'domain': no SOA or NS records found for domain >>> doesnotexist.test" >>> path = () >>> >>> ---------------------------------------------------------------------- >> > > False alarm. It was an error on my side. > > ACK Is this ready to be pushed? Do we need an ACK from Kyle too? rob From mkosek at redhat.com Fri Mar 15 10:19:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Mar 2013 11:19:12 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <513E477C.6050505@redhat.com> References: <513E477C.6050505@redhat.com> Message-ID: <5142F5A0.6090100@redhat.com> On 03/11/2013 10:07 PM, Rob Crittenden wrote: > Fixed a number of issues applying password policy against LDAP binds. See patch > for details. > > rob > I see some issues with this fix: 1) Shouldn't group password policy serve only as an override to the main policy? I.e. if I have this policy: # ipa pwpolicy-show test Group: test Priority: 10 Max failures: 2 We should still follow settings other than "Max failures" configured in global policy, right? At least the Kerberos seem to do it. I think we should be consistent in this case. Now, other values just seem to be zero. I think we will need to fix both the pre-op and the post-op to make this working really consistently. 2) The lockout post-op still counts failed logins even though we are in lockout time, is this expected? It is another point if inconsistency with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max failures". 3) Sometimes, I get into a state when I lockout a new user with Kerberos and then wait some time until the lockout time passes (no admin unlock), I am able to run as many LDAP binds as I want. This is all I found so far. Honza is also reviewing it, so I will let him post hist findings too. Martin From pspacek at redhat.com Fri Mar 15 11:08:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 Mar 2013 12:08:57 +0100 Subject: [Freeipa-devel] [PATCH] 0006 Remove check for alphabetic only characters from domain name validation In-Reply-To: <5141D9C9.5030208@redhat.com> References: <511E44A9.9090509@redhat.com> <51221027.7050803@redhat.com> <20130218114750.GC27418@localhost.localdomain> <512219D7.9000909@redhat.com> <51249F6E.7030005@redhat.com> <51273810.9060800@redhat.com> <5127889F.9020202@redhat.com> <512DD8BC.2080904@redhat.com> <513DC7DA.1000003@redhat.com> <5141D9C9.5030208@redhat.com> Message-ID: <51430149.1000006@redhat.com> On 14.3.2013 15:08, Martin Kosek wrote: > On 03/11/2013 01:02 PM, Ana Krivokapic wrote: >> On 02/27/2013 10:58 AM, Martin Kosek wrote: >>> On 02/22/2013 04:02 PM, Ana Krivokapic wrote: >>>> On 02/22/2013 10:19 AM, Petr Spacek wrote: >>>>> On 20.2.2013 11:03, Ana Krivokapic wrote: >>>>>> On 02/18/2013 01:08 PM, Martin Kosek wrote: >>>>>>> On 02/18/2013 12:47 PM, Sumit Bose wrote: >>>>>>>> On Mon, Feb 18, 2013 at 12:27:35PM +0100, Petr Spacek wrote: >>>>>>>>> On 15.2.2013 15:22, Ana Krivokapic wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> The .isalpha() check in validate_domain_name() was too strict, >>>>>>>>>> causing some commands like ipa dnsrecord-add to fail. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3385 >>>>>>>>> I would add --force option rather than removing whole check, if >>>>>>>>> it's possible. >>>>>>>>> >>>>>>>>> Would it be possible to mention RFC in the error message? Something >>>>>>>>> like _('top level domain label must be alphabetic (RFC 1123 section >>>>>>>>> 2.1)') >>>>>>>>> ? >>>>>>>>> >>>>>>>>> IMHO it is handy, because it educates users. >>>>>>>> The problem is that this check is always done on the last component of >>>>>>>> the domain_name even if it is just a sub-domain of the FreeIPA domain, >>>>>>>> where e.g. numbers are valid characters. >>>>>>>> >>>>>>>> At the beginning of validate_domain_name() a trailing '.' is stripped >>>>>>>> away. iirc the trailing '.' is an indication for a complete, fully >>>>>>>> qualified name. Would it work if the presence of the trailing '.' is >>>>>>>> saved and the check is only done if there was a '.'? >>>>>>>> >>>>>>>> bye, >>>>>>>> Sumit >>>>>>>> >>>>>>> Sure. Though I am now not 100% sure that some IPA functions do not >>>>>>> use this >>>>>>> validator with a fqdn hostname without trailing dot. If not, I am >>>>>>> for fixing >>>>>>> this function as Sumit and Petr suggested. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> After some thought, I decided to change the approach. >>>>>> >>>>>> As pointed out by Sumit, the problem was that the validate_domain_name() >>>>>> function did not distinguish between fqdn and non-fqdn domains >>>>>> (subdomains of the IPA domain). The trailing dot is not a clear >>>>>> indication either, because some IPA functions use this validator with an >>>>>> fqdn without the trailing dot. >>>>>> >>>>>> To fix this, I introduced an additional parameter to this function - a >>>>>> flag which indicates whether the domain name is an fqdn or not. The is >>>>>> .isalpha() check is then performed only in the case of an fqdn. >>>>>> >>>>>> I also improved the error message to mention the relevant RFC, as >>>>>> suggested by Petr. >>>>> Please don't forget to add --force switch. It could be handy. >>>>> >>>> I added the --force switch to ipa dnsrecord-add and opened a new ticket >>>> to handle the rest of the ipa commands that use domain name validation: >>>> https://fedorahosted.org/freeipa/ticket/3455 >>>> >>>> Updated patch is attached. >>>> >>> This patch fixed validation only partially. The --force flag you made available >>> will not allow admin to for example add a zone "example.zone1" which >>> technically will be resolvable, it is just not a good practice: >>> >>> # ipa dnszone-add example.zone1 --name-server `hostname`. --force >>> ipa: ERROR: invalid 'name': top level domain label must be alphabetic (RFC 1123 >>> section 2.1) >>> >>> To enable this, I think you would need to not postpone the validation to DNS >>> zone pre_callback as you could not check --force flag presence right in the >>> idnsname parameter validator. >>> >>> We may also want to change --force flag label, it now talks only about NS >>> record validation, but we now expanded it a bit, so the label would need to be >>> more general. >>> >>> Martin >> >> I added the fix for dnszone-add and edited the label of the --force flag >> to make it more general. >> > > The zone with this name can be created even without the --force flag. > > # ipa dnszone-add example.zone1 --name-server `hostname`. > Administrator e-mail address [hostmaster.example.zone1.]: >>>> Administrator e-mail address: top level domain label must be alphabetic > (RFC 1123 section 2.1) > Administrator e-mail address [hostmaster.example.zone1.]: hostmaster.example.zone. > Zone name: example.zone1 > Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. > Administrator e-mail address: hostmaster.example.zone. > SOA serial: 1363268183 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant > IDM.LAB.BOS.REDHAT.COM krb5-self > * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; > Active zone: TRUE > Dynamic update: FALSE > Allow query: any; > Allow transfer: none; > > I thought that the check would only be surpassed with the --force flag. > > All this struggle with this patch makes me thinking if we are not making it too > complicated. I am rather inclined to drop this particular check altogether. I > do not see that much harm if user creates an IPA managed zone "example.zone1". > Petr, what is your opinion on dropping this check in IPA? Is it OK to drop it? IMHO we can drop the whole check, it should be safe. I did some basic tests with latest bind-dyndb-ldap and it worked for me. -- Petr^2 Spacek From mkosek at redhat.com Fri Mar 15 11:11:36 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Mar 2013 12:11:36 +0100 Subject: [Freeipa-devel] [PATCH] 0006 Remove check for alphabetic only characters from domain name validation In-Reply-To: <51430149.1000006@redhat.com> References: <511E44A9.9090509@redhat.com> <51221027.7050803@redhat.com> <20130218114750.GC27418@localhost.localdomain> <512219D7.9000909@redhat.com> <51249F6E.7030005@redhat.com> <51273810.9060800@redhat.com> <5127889F.9020202@redhat.com> <512DD8BC.2080904@redhat.com> <513DC7DA.1000003@redhat.com> <5141D9C9.5030208@redhat.com> <51430149.1000006@redhat.com> Message-ID: <514301E8.6080101@redhat.com> On 03/15/2013 12:08 PM, Petr Spacek wrote: > On 14.3.2013 15:08, Martin Kosek wrote: >> On 03/11/2013 01:02 PM, Ana Krivokapic wrote: >>> On 02/27/2013 10:58 AM, Martin Kosek wrote: >>>> On 02/22/2013 04:02 PM, Ana Krivokapic wrote: >>>>> On 02/22/2013 10:19 AM, Petr Spacek wrote: >>>>>> On 20.2.2013 11:03, Ana Krivokapic wrote: >>>>>>> On 02/18/2013 01:08 PM, Martin Kosek wrote: >>>>>>>> On 02/18/2013 12:47 PM, Sumit Bose wrote: >>>>>>>>> On Mon, Feb 18, 2013 at 12:27:35PM +0100, Petr Spacek wrote: >>>>>>>>>> On 15.2.2013 15:22, Ana Krivokapic wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> The .isalpha() check in validate_domain_name() was too strict, >>>>>>>>>>> causing some commands like ipa dnsrecord-add to fail. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3385 >>>>>>>>>> I would add --force option rather than removing whole check, if >>>>>>>>>> it's possible. >>>>>>>>>> >>>>>>>>>> Would it be possible to mention RFC in the error message? Something >>>>>>>>>> like _('top level domain label must be alphabetic (RFC 1123 section >>>>>>>>>> 2.1)') >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> IMHO it is handy, because it educates users. >>>>>>>>> The problem is that this check is always done on the last component of >>>>>>>>> the domain_name even if it is just a sub-domain of the FreeIPA domain, >>>>>>>>> where e.g. numbers are valid characters. >>>>>>>>> >>>>>>>>> At the beginning of validate_domain_name() a trailing '.' is stripped >>>>>>>>> away. iirc the trailing '.' is an indication for a complete, fully >>>>>>>>> qualified name. Would it work if the presence of the trailing '.' is >>>>>>>>> saved and the check is only done if there was a '.'? >>>>>>>>> >>>>>>>>> bye, >>>>>>>>> Sumit >>>>>>>>> >>>>>>>> Sure. Though I am now not 100% sure that some IPA functions do not >>>>>>>> use this >>>>>>>> validator with a fqdn hostname without trailing dot. If not, I am >>>>>>>> for fixing >>>>>>>> this function as Sumit and Petr suggested. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> After some thought, I decided to change the approach. >>>>>>> >>>>>>> As pointed out by Sumit, the problem was that the validate_domain_name() >>>>>>> function did not distinguish between fqdn and non-fqdn domains >>>>>>> (subdomains of the IPA domain). The trailing dot is not a clear >>>>>>> indication either, because some IPA functions use this validator with an >>>>>>> fqdn without the trailing dot. >>>>>>> >>>>>>> To fix this, I introduced an additional parameter to this function - a >>>>>>> flag which indicates whether the domain name is an fqdn or not. The is >>>>>>> .isalpha() check is then performed only in the case of an fqdn. >>>>>>> >>>>>>> I also improved the error message to mention the relevant RFC, as >>>>>>> suggested by Petr. >>>>>> Please don't forget to add --force switch. It could be handy. >>>>>> >>>>> I added the --force switch to ipa dnsrecord-add and opened a new ticket >>>>> to handle the rest of the ipa commands that use domain name validation: >>>>> https://fedorahosted.org/freeipa/ticket/3455 >>>>> >>>>> Updated patch is attached. >>>>> >>>> This patch fixed validation only partially. The --force flag you made >>>> available >>>> will not allow admin to for example add a zone "example.zone1" which >>>> technically will be resolvable, it is just not a good practice: >>>> >>>> # ipa dnszone-add example.zone1 --name-server `hostname`. --force >>>> ipa: ERROR: invalid 'name': top level domain label must be alphabetic (RFC >>>> 1123 >>>> section 2.1) >>>> >>>> To enable this, I think you would need to not postpone the validation to DNS >>>> zone pre_callback as you could not check --force flag presence right in the >>>> idnsname parameter validator. >>>> >>>> We may also want to change --force flag label, it now talks only about NS >>>> record validation, but we now expanded it a bit, so the label would need to be >>>> more general. >>>> >>>> Martin >>> >>> I added the fix for dnszone-add and edited the label of the --force flag >>> to make it more general. >>> >> >> The zone with this name can be created even without the --force flag. >> >> # ipa dnszone-add example.zone1 --name-server `hostname`. >> Administrator e-mail address [hostmaster.example.zone1.]: >>>>> Administrator e-mail address: top level domain label must be alphabetic >> (RFC 1123 section 2.1) >> Administrator e-mail address [hostmaster.example.zone1.]: >> hostmaster.example.zone. >> Zone name: example.zone1 >> Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. >> Administrator e-mail address: hostmaster.example.zone. >> SOA serial: 1363268183 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant >> IDM.LAB.BOS.REDHAT.COM krb5-self >> * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; >> Active zone: TRUE >> Dynamic update: FALSE >> Allow query: any; >> Allow transfer: none; >> >> I thought that the check would only be surpassed with the --force flag. >> >> All this struggle with this patch makes me thinking if we are not making it too >> complicated. I am rather inclined to drop this particular check altogether. I >> do not see that much harm if user creates an IPA managed zone "example.zone1". >> Petr, what is your opinion on dropping this check in IPA? Is it OK to drop it? > > IMHO we can drop the whole check, it should be safe. I did some basic tests > with latest bind-dyndb-ldap and it worked for me. > Ok, I agree. Ana, can you please send a revised patch which rather drops this check altogether? Thanks, Martin From jcholast at redhat.com Fri Mar 15 11:18:06 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 Mar 2013 12:18:06 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <5142F5A0.6090100@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> Message-ID: <5143036E.6050608@redhat.com> On 15.3.2013 11:19, Martin Kosek wrote: > I see some issues with this fix: > > 1) Shouldn't group password policy serve only as an override to the main > policy? I.e. if I have this policy: > > # ipa pwpolicy-show test > Group: test > Priority: 10 > Max failures: 2 > > We should still follow settings other than "Max failures" configured in > global policy, right? At least the Kerberos seem to do it. I think we > should be consistent in this case. Now, other values just seem to be zero. > > I think we will need to fix both the pre-op and the post-op to make this > working really consistently. +1, noticed this as well. > > 2) The lockout post-op still counts failed logins even though we are in > lockout time, is this expected? It is another point if inconsistency > with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max > failures". > > 3) Sometimes, I get into a state when I lockout a new user with Kerberos > and then wait some time until the lockout time passes (no admin unlock), > I am able to run as many LDAP binds as I want. > > This is all I found so far. Honza is also reviewing it, so I will let > him post hist findings too. The commit message says "was being applied properly", when it should say "was being applied improperly". I have added steps to reproduce the issues the patch fixes to the ticket: Honza -- Jan Cholasta From mkosek at redhat.com Fri Mar 15 11:54:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Mar 2013 12:54:55 +0100 Subject: [Freeipa-devel] [PATCH] 0006 Remove check for alphabetic only characters from domain name validation In-Reply-To: <514301E8.6080101@redhat.com> References: <511E44A9.9090509@redhat.com> <51221027.7050803@redhat.com> <20130218114750.GC27418@localhost.localdomain> <512219D7.9000909@redhat.com> <51249F6E.7030005@redhat.com> <51273810.9060800@redhat.com> <5127889F.9020202@redhat.com> <512DD8BC.2080904@redhat.com> <513DC7DA.1000003@redhat.com> <5141D9C9.5030208@redhat.com> <51430149.1000006@redhat.com> <514301E8.6080101@redhat.com> Message-ID: <51430C0F.9020805@redhat.com> On 03/15/2013 12:11 PM, Martin Kosek wrote: > On 03/15/2013 12:08 PM, Petr Spacek wrote: >> On 14.3.2013 15:08, Martin Kosek wrote: >>> On 03/11/2013 01:02 PM, Ana Krivokapic wrote: >>>> On 02/27/2013 10:58 AM, Martin Kosek wrote: >>>>> On 02/22/2013 04:02 PM, Ana Krivokapic wrote: >>>>>> On 02/22/2013 10:19 AM, Petr Spacek wrote: >>>>>>> On 20.2.2013 11:03, Ana Krivokapic wrote: >>>>>>>> On 02/18/2013 01:08 PM, Martin Kosek wrote: >>>>>>>>> On 02/18/2013 12:47 PM, Sumit Bose wrote: >>>>>>>>>> On Mon, Feb 18, 2013 at 12:27:35PM +0100, Petr Spacek wrote: >>>>>>>>>>> On 15.2.2013 15:22, Ana Krivokapic wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> The .isalpha() check in validate_domain_name() was too strict, >>>>>>>>>>>> causing some commands like ipa dnsrecord-add to fail. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3385 >>>>>>>>>>> I would add --force option rather than removing whole check, if >>>>>>>>>>> it's possible. >>>>>>>>>>> >>>>>>>>>>> Would it be possible to mention RFC in the error message? Something >>>>>>>>>>> like _('top level domain label must be alphabetic (RFC 1123 section >>>>>>>>>>> 2.1)') >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> IMHO it is handy, because it educates users. >>>>>>>>>> The problem is that this check is always done on the last component of >>>>>>>>>> the domain_name even if it is just a sub-domain of the FreeIPA domain, >>>>>>>>>> where e.g. numbers are valid characters. >>>>>>>>>> >>>>>>>>>> At the beginning of validate_domain_name() a trailing '.' is stripped >>>>>>>>>> away. iirc the trailing '.' is an indication for a complete, fully >>>>>>>>>> qualified name. Would it work if the presence of the trailing '.' is >>>>>>>>>> saved and the check is only done if there was a '.'? >>>>>>>>>> >>>>>>>>>> bye, >>>>>>>>>> Sumit >>>>>>>>>> >>>>>>>>> Sure. Though I am now not 100% sure that some IPA functions do not >>>>>>>>> use this >>>>>>>>> validator with a fqdn hostname without trailing dot. If not, I am >>>>>>>>> for fixing >>>>>>>>> this function as Sumit and Petr suggested. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> After some thought, I decided to change the approach. >>>>>>>> >>>>>>>> As pointed out by Sumit, the problem was that the validate_domain_name() >>>>>>>> function did not distinguish between fqdn and non-fqdn domains >>>>>>>> (subdomains of the IPA domain). The trailing dot is not a clear >>>>>>>> indication either, because some IPA functions use this validator with an >>>>>>>> fqdn without the trailing dot. >>>>>>>> >>>>>>>> To fix this, I introduced an additional parameter to this function - a >>>>>>>> flag which indicates whether the domain name is an fqdn or not. The is >>>>>>>> .isalpha() check is then performed only in the case of an fqdn. >>>>>>>> >>>>>>>> I also improved the error message to mention the relevant RFC, as >>>>>>>> suggested by Petr. >>>>>>> Please don't forget to add --force switch. It could be handy. >>>>>>> >>>>>> I added the --force switch to ipa dnsrecord-add and opened a new ticket >>>>>> to handle the rest of the ipa commands that use domain name validation: >>>>>> https://fedorahosted.org/freeipa/ticket/3455 >>>>>> >>>>>> Updated patch is attached. >>>>>> >>>>> This patch fixed validation only partially. The --force flag you made >>>>> available >>>>> will not allow admin to for example add a zone "example.zone1" which >>>>> technically will be resolvable, it is just not a good practice: >>>>> >>>>> # ipa dnszone-add example.zone1 --name-server `hostname`. --force >>>>> ipa: ERROR: invalid 'name': top level domain label must be alphabetic (RFC >>>>> 1123 >>>>> section 2.1) >>>>> >>>>> To enable this, I think you would need to not postpone the validation to DNS >>>>> zone pre_callback as you could not check --force flag presence right in the >>>>> idnsname parameter validator. >>>>> >>>>> We may also want to change --force flag label, it now talks only about NS >>>>> record validation, but we now expanded it a bit, so the label would need >>>>> to be >>>>> more general. >>>>> >>>>> Martin >>>> >>>> I added the fix for dnszone-add and edited the label of the --force flag >>>> to make it more general. >>>> >>> >>> The zone with this name can be created even without the --force flag. >>> >>> # ipa dnszone-add example.zone1 --name-server `hostname`. >>> Administrator e-mail address [hostmaster.example.zone1.]: >>>>>> Administrator e-mail address: top level domain label must be alphabetic >>> (RFC 1123 section 2.1) >>> Administrator e-mail address [hostmaster.example.zone1.]: >>> hostmaster.example.zone. >>> Zone name: example.zone1 >>> Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. >>> Administrator e-mail address: hostmaster.example.zone. >>> SOA serial: 1363268183 >>> SOA refresh: 3600 >>> SOA retry: 900 >>> SOA expire: 1209600 >>> SOA minimum: 3600 >>> BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant >>> IDM.LAB.BOS.REDHAT.COM krb5-self >>> * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; >>> Active zone: TRUE >>> Dynamic update: FALSE >>> Allow query: any; >>> Allow transfer: none; >>> >>> I thought that the check would only be surpassed with the --force flag. >>> >>> All this struggle with this patch makes me thinking if we are not making it too >>> complicated. I am rather inclined to drop this particular check altogether. I >>> do not see that much harm if user creates an IPA managed zone "example.zone1". >>> Petr, what is your opinion on dropping this check in IPA? Is it OK to drop it? >> >> IMHO we can drop the whole check, it should be safe. I did some basic tests >> with latest bind-dyndb-ldap and it worked for me. >> > > Ok, I agree. Ana, can you please send a revised patch which rather drops this > check altogether? > > Thanks, > Martin > As Ana pointed out on IRC, this is actually what her first revision did. ACK for the first incarnation of the patch, pushed to master, ipa-3-1. Thanks, Martin From rcritten at redhat.com Fri Mar 15 13:34:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Mar 2013 09:34:47 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <5142F5A0.6090100@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> Message-ID: <51432377.6050003@redhat.com> Martin Kosek wrote: > On 03/11/2013 10:07 PM, Rob Crittenden wrote: >> Fixed a number of issues applying password policy against LDAP binds. >> See patch >> for details. >> >> rob >> > > I see some issues with this fix: > > 1) Shouldn't group password policy serve only as an override to the main > policy? I.e. if I have this policy: > > # ipa pwpolicy-show test > Group: test > Priority: 10 > Max failures: 2 > > We should still follow settings other than "Max failures" configured in > global policy, right? At least the Kerberos seem to do it. I think we > should be consistent in this case. Now, other values just seem to be zero. There should be only one policy. It isn't supposed to merge policies together (there is only one krbPwdPolicyReference per principal). How is the KDC acting differently? > I think we will need to fix both the pre-op and the post-op to make this > working really consistently. > > 2) The lockout post-op still counts failed logins even though we are in > lockout time, is this expected? It is another point if inconsistency > with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max > failures". Ok. > > 3) Sometimes, I get into a state when I lockout a new user with Kerberos > and then wait some time until the lockout time passes (no admin unlock), > I am able to run as many LDAP binds as I want. Can you clarify? Successful or unsuccessful binds? > This is all I found so far. Honza is also reviewing it, so I will let > him post hist findings too. > > Martin rob From rcritten at redhat.com Fri Mar 15 15:42:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Mar 2013 11:42:41 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51432377.6050003@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> Message-ID: <51434171.1090802@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>> Fixed a number of issues applying password policy against LDAP binds. >>> See patch >>> for details. >>> >>> rob >>> >> >> I see some issues with this fix: >> >> 1) Shouldn't group password policy serve only as an override to the main >> policy? I.e. if I have this policy: >> >> # ipa pwpolicy-show test >> Group: test >> Priority: 10 >> Max failures: 2 >> >> We should still follow settings other than "Max failures" configured in >> global policy, right? At least the Kerberos seem to do it. I think we >> should be consistent in this case. Now, other values just seem to be >> zero. > > There should be only one policy. It isn't supposed to merge policies > together (there is only one krbPwdPolicyReference per principal). > > How is the KDC acting differently? > >> I think we will need to fix both the pre-op and the post-op to make this >> working really consistently. >> >> 2) The lockout post-op still counts failed logins even though we are in >> lockout time, is this expected? It is another point if inconsistency >> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >> failures". > > Ok. > >> >> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >> and then wait some time until the lockout time passes (no admin unlock), >> I am able to run as many LDAP binds as I want. > > Can you clarify? Successful or unsuccessful binds? > >> This is all I found so far. Honza is also reviewing it, so I will let >> him post hist findings too. >> >> Martin Here is an updated patch to not increment past the max failures on LDAP binds. I couldn't reproduce your 3rd point. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-2-lockout.patch Type: text/x-diff Size: 11105 bytes Desc: not available URL: From abokovoy at redhat.com Fri Mar 15 16:56:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 15 Mar 2013 12:56:27 -0400 (EDT) Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <476374900.1590972.1363366321570.JavaMail.root@redhat.com> Message-ID: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> Hi! I was investigating why installing master fails on F18 + updates-testing and found out that install fails with freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from ipa-devel repo 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -R -s CN=jano.ipa.team,O=IPA.TEAM -o /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG stderr= Generating key. This may take a few moments... 2013-03-15T16:17:41Z DEBUG request 'https://jano.ipa.team:8443/ca/ee/ca/profileSubmitSSLClient' 2013-03-15T16:17:41Z DEBUG request body 'profileId=caIPAserviceCert&requestor_name=IPA+Installer&cert_request=MIICcDCCAVgCAQAwKzERMA8GA1UEChMISVBBLlRFQU0xFjAUBgNVBAMTDWphbm8u%0D%0AaXBhLnRlYW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOaJLU2s6L%0D%0A5Dxvmmc8fNsYDV760P1zyK69NjcNgx1oeSLY97AgWHdLh6hihAChgHN5ZFI0paQl%0D%0A%2B2J9tED41JnUHrHjBaqivBzUpYNGeyjquGeqk8cB7owGR5Rylu%2FKeaCqR8r3Kzc5%0D%0AUuCyG%2FLjFlD%2FGCqjxuqmjyBfcZxXGz6L72DaB9IZq0uX6Q4rYbK7DzP3va1%2B4UnZ%0D%0AqqgHZwDe73TTjuw9PiKvSvI2ocHCk6ui4YT4qr1YOol7Z18woYIwnukHQygD1iAT%0D%0ApZzHZJ191XD0k5vD3wCaOGJsYGF4q1kPeFewBIB6fMuydWX09kVNgqiWmGcsz83o%0D%0ASQrLQNU72H5VAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAFyT4t5oH894tDfuP%0D%0Abf0dqkDA%2F%2Fk738MI98GyyciRDhFFr18YizBtWNOx8Bl8c28O4J2Y9N%2BkmA%2BzPsKm%0D%0AC1W3Np%2Bh%2BqY5lNgK9XfQU5RXmlqPcqz588mHQgzjxePQP7od4fOVbFV03CCXjb9G%0D%0AtovS6wRrq909IxWSQ%2BNFM4S0OogCClihCy0%2FyDylpn4pYOvJCFl5xfGO3o4vrZC9%0D%0AM5tGhUIeD7H2dvMApRFKu6N7xI%2BmHfYiCKWGl8i2Mo%2FmQRX5zaHAyzrNMgqO2lNm%0D%0AjR%2B8U0HJc%2B8ujeJq9JYCGFDpi3SW93U4E15pBHfwr31UWjtOiqgypBtUlVwdEKFu%0D%0A6QIHIA%3D%3D%0A&cert_request_type=pkcs10&xmlOutput=true' 2013-03-15T16:17:41Z DEBUG NSSConnection init jano.ipa.team 2013-03-15T16:17:41Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 612, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1088, in main http.create_instance(realm_name, host_name, domain_name, dm_password, autoconfig=True, self_signed_ca=options.selfsign, subject_base=options.subject, auto_redirect=options.ui_redirect) File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 101, in create_instance self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 359, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/httpinstance.py", line 259, in __setup_ssl self.dercert = db.create_server_cert("Server-Cert", self.fqdn, ca_db) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 565, in create_server_cert cdb.issue_server_cert(self.certreq_fname, self.certder_fname) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 661, in issue_server_cert self.secdir, password, "ipaCert", **params) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 236, in https_request 'https', host, port, url, connection_factory, body) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 295, in _httplib_request raise NetworkError(uri=uri, error=str(e)) 2013-03-15T16:17:41Z INFO The ipa-server-install command failed, exception: NetworkError: cannot connect to 'https://jano.ipa.team:8443/ca/ee/ca/profileSubmitSSLClient': (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. while installing a build before 4152c36 does not fail. So, something from following patches fails: $ git log --oneline 4152c36^..HEAD 8de6c3f Remove check for alphabetic only characters from domain name validation c8846ba Improve some error handling in ipa-replica-manage 66356f0 Improve error messages for external group members c4ab8da Do not force named connections on upgrades 7a2d380 Use tkey-gssapi-keytab in named.conf ca6f7f2 Update named.conf parser 04a17f0 Enforce exact SID match when adding or modifying a ID range 354a5db Avoid multiple client discovery with fixed server list 452ffa1 Preserve order of servers in ipa-client-install 158bf45 Do not hide idrange-add errors when adding trust dcc6f13 Use new 389-ds-base cleartext password API 99b62aa Remove implicit Str to DN conversion using *-attr ade4aae Make sure uninstall script prompts for reboot as last 9005b9b Extend ipa-replica-manage to be able to manage DNA ranges. 63407ed Don't download the schema in ipadiscovery cf4b521 Remove unneeded python-ldap imports 664248d Use IPAdmin rather than raw python-ldap in migration.py and ipadiscovery.py a024233 Use IPAdmin rather than raw python-ldap in ipa-client-install 91a63cc Remove ipaserver/ipaldap.py 4e6a2a9 Move ipaldap to ipapython a38d93f Add support for re-enrolling hosts using keytab 91606e6 Change DNA magic value to -1 to make UID 999 usable 8d43235 Perform secondary rid range overlap check for local ranges only 6ff20ca Fix installing server with external CA 9955ba0 Disable schema retrieval and attribute decoding when talking to AD GC. f423364 Allow disabling attribute decoding in LDAPClient and IPAdmin. fffd2eb Allow disabling LDAP schema retrieval in LDAPClient and IPAdmin. 4152c36 Do not fail if schema cannot be retrieved from LDAP server. Please note that it is reproducible -- Adam was able to generate the same exception in his OpenStack-based instance of F18+updates-testing. -- / Alexander Bokovoy From jdennis at redhat.com Fri Mar 15 20:07:09 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Mar 2013 16:07:09 -0400 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> Message-ID: <51437F6D.6080605@redhat.com> On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: > Hi! > > I was investigating why installing master fails on F18 + > updates-testing and found out that install fails with > freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from > ipa-devel repo > > 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias > -R -s CN=jano.ipa.team,O=IPA.TEAM -o > /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z > /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a > 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 > 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG > stderr= > > Generating key. This may take a few moments... I believe this is a known problem in certutil where it writes data to the wrong file descriptor. The problem was fixed upstream about 10 days ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've added him on the cc list. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From edewata at redhat.com Fri Mar 15 21:12:38 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Mar 2013 16:12:38 -0500 Subject: [Freeipa-devel] [PATCH] 264-265 Web UI:Certificate pages In-Reply-To: <5137661F.1030705@redhat.com> References: <5127A039.6030902@redhat.com> <513680DD.3030806@redhat.com> <5137661F.1030705@redhat.com> Message-ID: <51438EC6.8080805@redhat.com> On 3/6/2013 9:51 AM, Petr Vobornik wrote: >> 1. As previously discussed, the cert-find is only available with Dogtag >> CA, so the Certificates page should be disabled with self-signed CA. But >> if self-signed CA is dropped, then it's not necessary to disable the >> Certificates page. We may need to keep the ticket open until this is >> resolved one way or another. > > Seems that the drop will land in different release. I disabled it > similar way as in DNS. I didn't test it. Do you have installation > without dogtag? Yes, the cert page now doesn't appear in the self-sign mode. >> 2. Right now the fields in the cert details page are editable although >> there is no Update button. If you change the value an Undo button will >> appear. If you try to leave the page it will show the Unsaved Changes >> dialog. Since there's no cert-mod operation these fields should not be >> editable. The certificate field is still editable. There's an undo button and you'll get a 'page dirty' dialog. Could we make it read-only text field? >> 3. In the cert details page if you revoke the cert it will work but an >> error will appear below the revocation reason field saying 'Must be an >> integer'. > > #2, #3: I forget to tell you, that this patch also depends on my patch > #261 - Fix handling of no_update flag in Web UI. Sorry. It should fix > it. It was pushed to master today. Everything else is fixed except for the certificate field above. >> 4. I think showing an empty revocation reason field on a valid cert is >> kind of weird. It might be better to create a Status section with two >> fields: status and revocation reason. If status is valid the revocation >> reason will be empty or hidden. If revoked then the reason will appear >> below the status. > > Fixed it by hiding the row. > > Showing the status is separate issue. I would like to avoid computing it > in web ui - IIUIC it depends also on valid-until and similar fields. > Cert-show command doesn't include the status. OK, let's address this separately. The search page shows the status, so it would make sense if the details page also shows the status. >> 5. In host/service details page the View link can be changed to go to >> the cert details page instead of showing a dialog box. > > Do we want to do it? That's probably a question for UXD whether we should stay in the host/service page or move to the cert page (and probably not having a link back to the host/service page). Also, in self-sign mode there won't be a cert page to link to. Let's leave it as is for now. >> 6. It would be better to organize the fields in the cert details page >> like the cert view dialog in host/service details page. > > Switched MD5fp. with SHA1fp. > > Do you also want to split subject and issuer as in the dialog and moved > the fields to different sections? > > Currently the order is the same as in dialog except serial numbers. I > kept them on top because issuer and subject may be very long and they > can clash with the action panel if placed on top. I'm OK with the current page, but maybe UXD has a different opinion. This can be addressed separately. >> 7. Certificate can be added/revoked/restored via certificate pages and >> host/service details pages. We need to make sure that if you do an >> operation on one page, the other pages won't show outdated information. > > Fixed. I added a cert via host details page. When I go to the cert search page the new cert doesn't appear until I click Refresh. The revoke/restore works though, the status are updated automatically in all pages. >> 8. The revocation reason takes an integer. Probably the search field >> should change into a drop down list showing all available reasons. >> >> 9. The date options take a certain format (YYYY-MM-DD), so we should >> show the format probably as greyed text in the search field. >> >> 10. The current design only allows specifying one option at a time. Some >> of these options are meant to be used as a pair because they represent a >> range (min & max serial number). How about creating an Advanced Search >> dialog that shows all search options in separate fields so they can be >> combined? The basic search field can remain simple like the search field >> in other entities and it will search the cert subject only. > > 8-10: I agree, but I don't want to complicate the patch. Originally this > patch shouldn't really exist. Original agreement was that the search > will be fixed to 'subject' field and that it should be replaced with > proper implementation of #191 later. I made this patch to give users at > least some options. Main obstacle is that there are more pressing issues > for April release. OK, let leave it as is for now, but some people might be reporting usability issue. >> 11. The list of search options is a drop down list, but it's surrounded >> by a rounded box like the text field next to it. This might be just a >> personal preference but I'm not sure if it's an appropriate look for a >> drop down list. > > It's just border radius. When I disable it it looks kinda inconsistent, > weirder. OK, this is fine. So the remaining issues are #2 and #7. Other than that it's ACKed. Feel free to fix and push. -- Endi S. Dewata From edewata at redhat.com Fri Mar 15 22:47:31 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Mar 2013 17:47:31 -0500 Subject: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE In-Reply-To: <5138980F.8070205@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> <5138980F.8070205@redhat.com> Message-ID: <5143A503.4020409@redhat.com> On 3/7/2013 7:37 AM, Petr Vobornik wrote: >> Ideally it should be generic enough to combine any widgets. This might >> be a common scenario somewhere else: >> >> Something: ( ) Option 1 >> ( ) Option 2 >> (o) Other: [something else ] > > This design has a flaw: > https://fedorahosted.org/freeipa/ticket/3404#comment:5 I think this one makes the most sense to me: PAC Types: ( ) Inherited setting: ... ... (o) Override inherited setting [ ] MS-PAC [ ] PAD It looks like the NONE option is identical to not using the inherited values but also not selecting any new values, so we don't actually need a separate radio button for NONE because it can be represented by the above UI without redundancy. We just need better labels to explain the radio buttons. Maybe someone can come up with better labels than these. > I implemented following design: > https://fedorahosted.org/freeipa/ticket/3404#comment:7 It works but I can't imagine how it would look if we have more than two PAC types. I don't think we want to list every possible combinations. The above design is more future proof. > Patch attached (255-1). > > I have a dilemma. I practically implemented the previous design (and > then I've found the flaw..). Patches attached as wip-fre... I wonder if > we can use it somehow or we should ditch it. -- Endi S. Dewata From edewata at redhat.com Fri Mar 15 23:22:23 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Mar 2013 18:22:23 -0500 Subject: [Freeipa-devel] [PATCH] 266 Fixed Web UI build error caused by rhino changes in F19 In-Reply-To: <513DDBDC.1040901@redhat.com> References: <513DDBDC.1040901@redhat.com> Message-ID: <5143AD2F.8020305@redhat.com> On 3/11/2013 8:27 AM, Petr Vobornik wrote: > rhino-1.7R4-2.fc19.noarch dropped -main flag which made the build fail > in rawhide (F19). > > We can't use the same command for rhino-1.7R3-6 (F18) and rhino-1.7R4-2 > (F19). > This patch adds check if rhino supports '-require' option. If so it > calls rhino with it if not it calls rhino with -main option. > > https://fedorahosted.org/freeipa/ticket/3501 Would it be better to check /etc/fedora-release or the actual rhino version? Regardless, this patch is ACKed. I don't have an F19 to test it though. -- Endi S. Dewata From edewata at redhat.com Sat Mar 16 02:32:07 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Mar 2013 21:32:07 -0500 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <513F57B9.9010405@redhat.com> References: <513F57B9.9010405@redhat.com> Message-ID: <5143D9A7.3000803@redhat.com> On 3/12/2013 11:28 AM, Petr Vobornik wrote: > Here's a patch for filtering groups by type. > Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type > > The interface is: >> StrEnum('type?', >> cli_name='type', >> label=_('Type'), >> doc=_('Group type'), >> values=(u'posix', u'normal', u'external'), >> ), > > I have two design questions. > 1. Is --type the right option name? Fine by me, it matches the label and description. > 2. Is `normal` the right name for non-posix, non-external group? The > default group type (when adding group) is posix. Should the name be > something else: `simple`, `plain`, `ordinary`? We also use 'normal' in the group adder dialog, so it's consistent. Other options are 'basic', 'standard', 'regular'. > I didn't want to create an option for each type. IMO it brings more > complexity. Maybe the group-add/mod command should use the same --type option? > https://fedorahosted.org/freeipa/ticket/3483 ACK from me, but maybe others might have some comments. -- Endi S. Dewata From edewata at redhat.com Sat Mar 16 03:06:14 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Mar 2013 22:06:14 -0500 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513F5941.6060301@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> <513F5941.6060301@redhat.com> Message-ID: <5143E1A6.9020103@redhat.com> On 3/12/2013 11:35 AM, Petr Vobornik wrote: >>>> Another problem is that hidden 'Default SMB Group' is not listed. >>>> Hence it couldn't be set again after a modification. I made the >>>> combobox >>>> editable (first usage, so it revealed a bug) to avoid this problem. >>>> User can enter garbage, but the framework should handle that. >>> >>> This is a little difficult to use. You'll need to know that you have to >>> type 'Default SMB Group' to go back to the default and the UI doesn't >>> show that as an acceptable value. Possible solutions: >>> >>> 1. Add the 'Default SMB Group' as the first entry in the drop down list >>> so you can reselect it again. The drop down list doesn't need to be >>> editable. >>> >>> 2. Use radio buttons to separate the default value from other values: >>> >>> Fallback primary group: (o) Default SMB Group >>> ( ) POSIX group: [ drop down list ] >>> >>> Regardless, I think the server API needs to be changed to accept an >>> empty value to go back to the default value instead of taking 'Default >>> SMB Group'. A default value should be simple and not something that will >>> potentially conflict with a non-default value that happens to have the >>> same name. >> >> I agree. Martin is it feasible? > > From other emails: Apparently its not worth the time. So I implemented #1. OK. > 3. Found an issue: trusctconfig-show will raise 'not found' error when > trusts are not configured on a system. It's fixed separately in attached > patch #268. It has similar behavior as dns pages. > > Also I added data .json files to patch 262 and 268, so the static > version can be used. The static page and the code looks good, but do you have a live server that I could take a look at? There are some other issues with the static page: When loading the UI, cert entity initialization fails saying "entity is undefined". Also, the trust details page has 2 sections, but the second section has a blank title and 'undefined' fields. Did I miss a patch? -- Endi S. Dewata From abokovoy at redhat.com Sat Mar 16 10:45:50 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 16 Mar 2013 12:45:50 +0200 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <51437F6D.6080605@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> Message-ID: <20130316104550.GG24679@redhat.com> On Fri, 15 Mar 2013, John Dennis wrote: >On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: >>Hi! >> >>I was investigating why installing master fails on F18 + >>updates-testing and found out that install fails with >>freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from >>ipa-devel repo >> >>2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>-R -s CN=jano.ipa.team,O=IPA.TEAM -o >>/var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z >>/etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a >>2013-03-15T16:17:41Z DEBUG Process finished, return code=0 >>2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG >>stderr= >> >>Generating key. This may take a few moments... > >I believe this is a known problem in certutil where it writes data to >the wrong file descriptor. The problem was fixed upstream about 10 days >ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've >added him on the cc list. The reason why I'm thinking it is wider than certutil is because FreeIPA master is installable for the code before 4152c36 using exactly same environment, with the same certutil. I think it is important to fix our own issue as well as update certutil. -- / Alexander Bokovoy From dpal at redhat.com Sat Mar 16 20:46:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 16 Mar 2013 16:46:17 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <1363111343.2822.195.camel@willson.li.ssimo.org> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> <513F587E.4070500@redhat.com> <1363107660.2822.187.camel@willson.li.ssimo.org> <513F668A.4090500@redhat.com> <1363111343.2822.195.camel@willson.li.ssimo.org> Message-ID: <5144DA19.5090804@redhat.com> On 03/12/2013 02:02 PM, Simo Sorce wrote: > On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: >> On 12.3.2013 18:01, Simo Sorce wrote: >>> On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: >>>> On 12.3.2013 17:24, Simo Sorce wrote: >>>>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: >>>>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an >>>>>> ACI preventing that, I'm just wondering what is the reason for this.) >>>>> If you tell me who 'we' is (as in what user would set it) I can tell you >>>>> why it is/isn't possible. >>>> Why no IPA user (including admins) can set the attribute? >>> I guess admins should be allowed to. >>> >>> Users can't, as ticket flags change the behavior of the principal in >>> ways only admins should allowed to. (preauth required or not, AS >>> requests disabled or not, etc...) >> Thanks. For normal users it's obvious, but it seemed a little bit >> strange to disallow admins to set the flags. >> >> So, can the krbTicketFlags attribute be used internally in IPA plugins >> to set/unset the flags, given that the ACI is changed to allow admins to >> modify the attribute? > The problem is determining if all the flags can be set by the same set > of admins or if we need to be able to delegate some of them. In the > second case we have only 2 options: > 1) break the flags out in multiple attributes so we can set separate > ACIs > 2) create a plugin that can intercept and filter modifications to the > attribute so only the allowed flags are changed > > The first option has the problem that we are going to change the schema. > The second option has the problem that the check will be less flexible > than with regular ACIs (unless we use some sort of virtual ACI) and > duplicates access control points. > > Anyway we need to find out if we really need fine grained access control > per flags or not before wrapping our heads. > > Simo. > Do we have a decision on this? Have we determined that the flags actually have to be delegated and have different access privileges? Can we start with allowing admins to change them all and reconsider when anyone actually asks for a finer grain access control? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kaie at redhat.com Sat Mar 16 21:19:50 2013 From: kaie at redhat.com (Kai Engert) Date: Sat, 16 Mar 2013 22:19:50 +0100 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <51437F6D.6080605@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> Message-ID: <1363468790.10244.44.camel@localhost> On Fri, 2013-03-15 at 16:07 -0400, John Dennis wrote: > On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: > > Hi! > > > > I was investigating why installing master fails on F18 + > > updates-testing and found out that install fails with > > freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from > > ipa-devel repo > > > > 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias > > -R -s CN=jano.ipa.team,O=IPA.TEAM -o > > /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z > > /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a > > 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 > > 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG > > stderr= > > > > Generating key. This may take a few moments... > > I believe this is a known problem in certutil where it writes data to > the wrong file descriptor. The problem was fixed upstream about 10 days > ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've > added him on the cc list. Hi John, in the above cited message, you didn't include the failure you were seeing, so I have to guess. This one is the only functional patch to certutil during the last 8-9 weeks that I could find. Do you refer to this one? Bug 840714 - certutil -a does not produce ASCII output https://bugzilla.mozilla.org/show_bug.cgi?id=840714 It was a regression in NSS 3.14.2, and it got fixed in 3.14.3. Fedora 18 apparently received that update on Feb 24. http://tinyurl.com/bym4rlh If the above didn't help, please send more details or ping me on IRC. Regards Kai From jdennis at redhat.com Sun Mar 17 13:42:50 2013 From: jdennis at redhat.com (John Dennis) Date: Sun, 17 Mar 2013 09:42:50 -0400 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <1363468790.10244.44.camel@localhost> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> <1363468790.10244.44.camel@localhost> Message-ID: <5145C85A.7080307@redhat.com> On 03/16/2013 05:19 PM, Kai Engert wrote: > On Fri, 2013-03-15 at 16:07 -0400, John Dennis wrote: >> On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> I was investigating why installing master fails on F18 + >>> updates-testing and found out that install fails with >>> freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from >>> ipa-devel repo >>> >>> 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>> -R -s CN=jano.ipa.team,O=IPA.TEAM -o >>> /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z >>> /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a >>> 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 >>> 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG >>> stderr= >>> >>> Generating key. This may take a few moments... >> >> I believe this is a known problem in certutil where it writes data to >> the wrong file descriptor. The problem was fixed upstream about 10 days >> ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've >> added him on the cc list. > > > Hi John, > > in the above cited message, you didn't include the failure you were > seeing, so I have to guess. > > This one is the only functional patch to certutil during the last 8-9 > weeks that I could find. Do you refer to this one? > > Bug 840714 - certutil -a does not produce ASCII output > https://bugzilla.mozilla.org/show_bug.cgi?id=840714 > > It was a regression in NSS 3.14.2, and it got fixed in 3.14.3. Fedora 18 > apparently received that update on Feb 24. > http://tinyurl.com/bym4rlh > > If the above didn't help, please send more details or ping me on IRC. Thank you Kai. Yes, that was the regression I was referring to. It's good to know when the fix appeared because we've had a number of folks report problems due to it. However Alexander's issue may be something else. In any event, thank you. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Mar 18 09:08:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Mar 2013 10:08:16 +0100 Subject: [Freeipa-devel] [PATCH] 266 Fixed Web UI build error caused by rhino changes in F19 In-Reply-To: <5143AD2F.8020305@redhat.com> References: <513DDBDC.1040901@redhat.com> <5143AD2F.8020305@redhat.com> Message-ID: <5146D980.4080001@redhat.com> On 03/16/2013 12:22 AM, Endi Sukma Dewata wrote: > On 3/11/2013 8:27 AM, Petr Vobornik wrote: >> rhino-1.7R4-2.fc19.noarch dropped -main flag which made the build fail >> in rawhide (F19). >> >> We can't use the same command for rhino-1.7R3-6 (F18) and rhino-1.7R4-2 >> (F19). >> This patch adds check if rhino supports '-require' option. If so it >> calls rhino with it if not it calls rhino with -main option. >> >> https://fedorahosted.org/freeipa/ticket/3501 > > Would it be better to check /etc/fedora-release or the actual rhino version? Checking /etc/fedora-release would introduce another unnecessary Fedora platform build dependency, I would not do that. As for the rhino version, I would also not like calling "rpm -q rhino" to get the package version as we would then have to parse it properly and it also adds yet another platform specific dependency. Thus, I think that current Petr approach should be OK for now. Martin > > Regardless, this patch is ACKed. I don't have an F19 to test it though. > From mkosek at redhat.com Mon Mar 18 09:21:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Mar 2013 10:21:01 +0100 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <5145C85A.7080307@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> <1363468790.10244.44.camel@localhost> <5145C85A.7080307@redhat.com> Message-ID: <5146DC7D.3090808@redhat.com> On 03/17/2013 02:42 PM, John Dennis wrote: > On 03/16/2013 05:19 PM, Kai Engert wrote: >> On Fri, 2013-03-15 at 16:07 -0400, John Dennis wrote: >>> On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> I was investigating why installing master fails on F18 + >>>> updates-testing and found out that install fails with >>>> freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from >>>> ipa-devel repo >>>> >>>> 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>>> -R -s CN=jano.ipa.team,O=IPA.TEAM -o >>>> /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z >>>> /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a >>>> 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 >>>> 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG >>>> stderr= >>>> >>>> Generating key. This may take a few moments... >>> >>> I believe this is a known problem in certutil where it writes data to >>> the wrong file descriptor. The problem was fixed upstream about 10 days >>> ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've >>> added him on the cc list. >> >> >> Hi John, >> >> in the above cited message, you didn't include the failure you were >> seeing, so I have to guess. >> >> This one is the only functional patch to certutil during the last 8-9 >> weeks that I could find. Do you refer to this one? >> >> Bug 840714 - certutil -a does not produce ASCII output >> https://bugzilla.mozilla.org/show_bug.cgi?id=840714 >> >> It was a regression in NSS 3.14.2, and it got fixed in 3.14.3. Fedora 18 >> apparently received that update on Feb 24. >> http://tinyurl.com/bym4rlh >> >> If the above didn't help, please send more details or ping me on IRC. > > Thank you Kai. Yes, that was the regression I was referring to. It's good to > know when the fix appeared because we've had a number of folks report problems > due to it. However Alexander's issue may be something else. In any event, thank > you. > Alexander, any luck with resolving this issue? I just tested current Freeipa master branch with up-to-date Fedora 18 and installation worked for me. I do not have updates-testing enabled though. I am still not convinced this is caused by latest patches that were pushed. Martin From jcholast at redhat.com Mon Mar 18 11:38:35 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Mar 2013 12:38:35 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins Message-ID: <5146FCBB.4000500@redhat.com> Hi, this patch implements . Because the design is not finished yet, this is a minimal implementation - it uses the krbTicketFlags attribute directly (which means no delegation of rights to modify specific flags to specific admins) and there is no support for per-service type default values. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-120-Add-Kerberos-ticket-flags-management-to-service-and-.patch Type: text/x-patch Size: 22501 bytes Desc: not available URL: From abokovoy at redhat.com Mon Mar 18 11:48:39 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 Mar 2013 13:48:39 +0200 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <5146DC7D.3090808@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> <1363468790.10244.44.camel@localhost> <5145C85A.7080307@redhat.com> <5146DC7D.3090808@redhat.com> Message-ID: <20130318114838.GH24679@redhat.com> On Mon, 18 Mar 2013, Martin Kosek wrote: >On 03/17/2013 02:42 PM, John Dennis wrote: >> On 03/16/2013 05:19 PM, Kai Engert wrote: >>> On Fri, 2013-03-15 at 16:07 -0400, John Dennis wrote: >>>> On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> I was investigating why installing master fails on F18 + >>>>> updates-testing and found out that install fails with >>>>> freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from >>>>> ipa-devel repo >>>>> >>>>> 2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>>>> -R -s CN=jano.ipa.team,O=IPA.TEAM -o >>>>> /var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z >>>>> /etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a >>>>> 2013-03-15T16:17:41Z DEBUG Process finished, return code=0 >>>>> 2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG >>>>> stderr= >>>>> >>>>> Generating key. This may take a few moments... >>>> >>>> I believe this is a known problem in certutil where it writes data to >>>> the wrong file descriptor. The problem was fixed upstream about 10 days >>>> ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've >>>> added him on the cc list. >>> >>> >>> Hi John, >>> >>> in the above cited message, you didn't include the failure you were >>> seeing, so I have to guess. >>> >>> This one is the only functional patch to certutil during the last 8-9 >>> weeks that I could find. Do you refer to this one? >>> >>> Bug 840714 - certutil -a does not produce ASCII output >>> https://bugzilla.mozilla.org/show_bug.cgi?id=840714 >>> >>> It was a regression in NSS 3.14.2, and it got fixed in 3.14.3. Fedora 18 >>> apparently received that update on Feb 24. >>> http://tinyurl.com/bym4rlh >>> >>> If the above didn't help, please send more details or ping me on IRC. >> >> Thank you Kai. Yes, that was the regression I was referring to. It's good to >> know when the fix appeared because we've had a number of folks report problems >> due to it. However Alexander's issue may be something else. In any event, thank >> you. >> > >Alexander, any luck with resolving this issue? I just tested current Freeipa >master branch with up-to-date Fedora 18 and installation worked for me. I do >not have updates-testing enabled though. I am still not convinced this is >caused by latest patches that were pushed. No, there is no change in behavior. Even with latest updates to tomcat6 from updates-testing HEAD on master fails when installing on F18+updates-testing. The same machine happily installs code before LDAP restructuring patches applied. Unfortunately, I cannot experiment to find out exact failing patch right now but we should aim for working F18+updates-testing setup if possible. -- / Alexander Bokovoy From pviktori at redhat.com Mon Mar 18 11:58:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 18 Mar 2013 12:58:33 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs Message-ID: <51470169.1090308@redhat.com> Hello, While the work is not complete, these patches allowed me to install an IPA server without a CA, using PKCS#12 files for the server certs. The patches don't break normal installation. The --selfsign option (but not yet the code behind it) is removed. The absence of a CA is indicated by `enable_ra=False` in the IPA config. ipa-replica-install will still refuse to run; I'll look into that next. I removed some unused code that got in my way: Dogtag 9 installation (we can run a Dogtag 9-style CA, but we never *install* it), and ipapython.certdb.CertDB (unused, not to be confused with ipaserver's CertDB). I tried using python-nss, but unfortunately found that it's not yet usable here. John filed https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our conversation. Parsing certutil output, while dirty, is more reliable in my limited experience. I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper around certdb operations. We have a CertDB class for it but that one is too tied to the current code paths: when I used it I found myself re-implementing a lot of methods to get rid of some assumption or other. The new NSSDatabase is not tied to IPA configuration. From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0197-ipa-server-install-Make-temporary-pin-files-availabl.patch Type: text/x-patch Size: 6412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0198-ipa-server-install-Remove-the-selfsign-option.patch Type: text/x-patch Size: 9465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0199-Remove-code-to-install-Dogtag-9.patch Type: text/x-patch Size: 18751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0200-Remove-unused-ipapython.certdb.CertDB-class.patch Type: text/x-patch Size: 6425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0201-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch Type: text/x-patch Size: 13843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0202-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0203-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch Type: text/x-patch Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 11067 bytes Desc: not available URL: From akrivoka at redhat.com Mon Mar 18 13:34:57 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 18 Mar 2013 14:34:57 +0100 Subject: [Freeipa-devel] [PATCH] 0008 Fix internal error for ipa show-mappings Message-ID: <51471801.3030902@redhat.com> Hello, I found a bug in the ipa show-mappings command. The attached patch fixes it. Can we push it under the "one-liner rule"? -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0008-Fix-internal-error-for-ipa-show-mappings.patch Type: text/x-patch Size: 956 bytes Desc: not available URL: From pvoborni at redhat.com Mon Mar 18 13:38:13 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 Mar 2013 14:38:13 +0100 Subject: [Freeipa-devel] [PATCH] 263 Web UI: configurable SID blacklists In-Reply-To: <5137359F.9020801@redhat.com> References: <512258C9.5000803@redhat.com> <5134D674.4000008@redhat.com> <5137359F.9020801@redhat.com> Message-ID: <514718C5.407@redhat.com> On 03/06/2013 01:25 PM, Petr Vobornik wrote: > On 03/04/2013 06:14 PM, Endi Sukma Dewata wrote: >> On 2/18/2013 10:37 AM, Petr Vobornik wrote: >>> Added blacklists section, with ipantsidblacklistincoming and >>> ipantsidblacklistoutgoing multivalued textbox fields, into trust details >>> page. >>> >>> https://fedorahosted.org/freeipa/ticket/3289 >> >> ACK. >> > Pushed to master > Pushed to ipa-3-1 (CLI in 3-1). -- Petr Vobornik From mkosek at redhat.com Mon Mar 18 13:42:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Mar 2013 14:42:05 +0100 Subject: [Freeipa-devel] [PATCH] 0008 Fix internal error for ipa show-mappings In-Reply-To: <51471801.3030902@redhat.com> References: <51471801.3030902@redhat.com> Message-ID: <514719AD.5070303@redhat.com> On 03/18/2013 02:34 PM, Ana Krivokapic wrote: > Hello, > > I found a bug in the ipa show-mappings command. The attached patch fixes it. > > Can we push it under the "one-liner rule"? > Yeah, this is regression caused by ticket 2732. Thanks for the fix. one-liner ACK, pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Mon Mar 18 13:43:36 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 Mar 2013 14:43:36 +0100 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <513739D3.7090606@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> Message-ID: <51471A08.8090206@redhat.com> On 03/06/2013 01:42 PM, Petr Vobornik wrote: > On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote: >> ----- Original Message ----- >>> First two patches are bug fixes which are required for third patch. >>> Depends on my patch #259 (Combobox keyboard support) >>> >>> 1) [PATCH] Fix dirty state update of editable combobox >>> >>> Editable combobox didn't update it's dirty state correctly. CB had >>> it's own internal value changed event, which was incorrectly used. It >>> was >>> removed and widget's value_changed event was used instead. >> >> ACK. > > Pushed to master pushed to ipa-3-1. Prerequisite for other 3-1 stuff. >> >>> 2) [PATCH] Fix handling of no_update flag in Web UI >>> >>> There was an incorrect check for no_update flag. Check was performed >>> as if the flag was an attribute of object not an item of array. Hence, >>> the flag never caused any effect. >> >> ACK. > > Pushed to master pushed to ipa-3-1. Prerequisite for other 3-1 stuff. >> >>> 3) [PATCH] Global trust config page >>> >>> https://fedorahosted.org/freeipa/ticket/3333 >> 8><-------- -- Petr Vobornik From tbabej at redhat.com Mon Mar 18 13:46:31 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 18 Mar 2013 14:46:31 +0100 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation Message-ID: <51471AB7.90108@redhat.com> Hi, A new option --force-join has been added to ipa-client-install. It forces the host enrollment even if the host entry exists. Old certificate is revoked, new certificate and ssh key pair generated. See the relevant design for the re-enrollment part: http://freeipa.org/page/V3/Client_install_using_keytab https://fedorahosted.org/freeipa/ticket/3482 Tomas From pvoborni at redhat.com Mon Mar 18 13:48:02 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 Mar 2013 14:48:02 +0100 Subject: [Freeipa-devel] [PATCH] 259 Combobox keyboard support In-Reply-To: <51373872.2050409@redhat.com> References: <940957870.1823903.1361926213062.JavaMail.root@redhat.com> <512E021F.5030004@redhat.com> <5132553C.9010606@redhat.com> <51373872.2050409@redhat.com> Message-ID: <51471B12.2090905@redhat.com> On 03/06/2013 01:37 PM, Petr Vobornik wrote: > On 03/02/2013 08:38 PM, Endi Sukma Dewata wrote: >> On 02/27/2013 06:54 AM, Petr Vobornik wrote: >>> On 02/27/2013 01:50 AM, Endi Sukma Dewata wrote: > >>> >>>> Another minor thing, if the search box is in focus, you can use the >>>> Up/Down arrow to go to the list. However, from the list you cannot >>>> use the Up/Down arrow to go back to the search box, you'd have to use >>>> the Tab key. It's not really a problem, but it's not that consistent. >>> Up/Down keys are natural way of changing value of a list - this part >>> seems OK to me. So Up/Down arrow in search box might the problem, but >>> I consider it a feature - saves some strokes. Also, User can always >>> use tab to switch between search box and list. >> >> I'm OK with the Up/Down arrow in search box too, but if it's not >> consistent people may think it's a bug. So I'd suggest we make it such >> that you can use Up/Down to go back to the search box. > > Up/Down doesn't just go to the list but it also changes the selected > item in the list. So we might say that it's consistent - it changes > selected item. > > I might agree that going from search box to list is wrong or misleading > but I'm strongly against going back to search box using Up/Down keys. It > would be redefining of implicit behavior of select element. > >> >> All of the above are minor. The patch itself is ACKed. >> > Anyway, pushed to master > Pushed to ipa-3-1 (prerequisite of other patches). -- Petr Vobornik From tbabej at redhat.com Mon Mar 18 13:49:01 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 18 Mar 2013 14:49:01 +0100 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation In-Reply-To: <51471AB7.90108@redhat.com> References: <51471AB7.90108@redhat.com> Message-ID: <51471B4D.9090101@redhat.com> On 03/18/2013 02:46 PM, Tomas Babej wrote: > Hi, > > A new option --force-join has been added to ipa-client-install. > It forces the host enrollment even if the host entry exists. > Old certificate is revoked, new certificate and ssh key pair > generated. See the relevant design for the re-enrollment part: > http://freeipa.org/page/V3/Client_install_using_keytab > > https://fedorahosted.org/freeipa/ticket/3482 > > Tomas A-and the patch itself. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0042-Allow-host-re-enrollment-using-delegation.patch Type: text/x-patch Size: 3387 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 18 12:43:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Mar 2013 13:43:27 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51434171.1090802@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> Message-ID: <51470BEF.1080108@redhat.com> On 03/15/2013 04:42 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>> Fixed a number of issues applying password policy against LDAP binds. >>>> See patch >>>> for details. >>>> >>>> rob >>>> >>> >>> I see some issues with this fix: >>> >>> 1) Shouldn't group password policy serve only as an override to the main >>> policy? I.e. if I have this policy: >>> >>> # ipa pwpolicy-show test >>> Group: test >>> Priority: 10 >>> Max failures: 2 >>> >>> We should still follow settings other than "Max failures" configured in >>> global policy, right? At least the Kerberos seem to do it. I think we >>> should be consistent in this case. Now, other values just seem to be >>> zero. >> >> There should be only one policy. It isn't supposed to merge policies >> together (there is only one krbPwdPolicyReference per principal). That's a good point. >> >> How is the KDC acting differently? For example, if you set only maximal number of bad password guesses, it does not allow any more (user fbar1 is a member of test group): # ipa pwpolicy-mod test --maxfail 3 Group: test Priority: 10 Max failures: 3 # kinit fbar1 Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: kinit: Password incorrect while getting initial credentials # kinit fbar1 Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: kinit: Password incorrect while getting initial credentials # kinit fbar1 Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: kinit: Password incorrect while getting initial credentials # kinit fbar1 kinit: Clients credentials have been revoked while getting initial credentials But LDAP binds are still allowed # ldapsearch -h localhost -D uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo -s base -b "" ldap_bind: Invalid credentials (49) I think this is just caused by different processing of krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, max auth tries checks are pretty much disabled). >> >>> I think we will need to fix both the pre-op and the post-op to make this >>> working really consistently. >>> >>> 2) The lockout post-op still counts failed logins even though we are in >>> lockout time, is this expected? It is another point if inconsistency >>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>> failures". >> >> Ok. >> >>> >>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>> and then wait some time until the lockout time passes (no admin unlock), >>> I am able to run as many LDAP binds as I want. >> >> Can you clarify? Successful or unsuccessful binds? Unsuccessful binds. I will try to reproduce it again when you fix the crash, it is hard to investigate it with this crash around. >> >>> This is all I found so far. Honza is also reviewing it, so I will let >>> him post hist findings too. >>> >>> Martin > > Here is an updated patch to not increment past the max failures on LDAP binds. The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a user with no group policy assigned (Stacktrace attached). Martin > > I couldn't reproduce your 3rd point. > > rob > -------------- next part -------------- Thread 1 (Thread 0x7fdde4ff9700 (LWP 7617)): #0 __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 No locals. #1 0x00007fddfe4b15bc in slapi_mods_add_string (smods=0x7fddc8001c70, modtype=modtype at entry=1, type=type at entry=0x7fddf4b9cf21 "krbLastFailedAuth", val=0x0) at ldap/servers/slapd/modutil.c:370 No locals. #2 0x00007fddf4b9c833 in ipalockout_postop (pb=0x1cad1b0) at ipa_lockout.c:544 dn = 0x7fddc8000dd0 "uid=fbar1b,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" policy_dn = 0x7fddc8005390 "cn=test,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" target_entry = 0x7fddc8008620 policy_entry = 0x7fddc80026e0 sdn = 0x7fddc80018c0 pbtm = 0x0 smods = 0x0 objectclass = 0x0 errstr = 0x0 ldrc = rc = 49 ret = 0 failedcount = 1 failedcountstr = "1\000?\001\000\000\000\000\200$\224\001\000\000\000\000?\233?\001\000\000\000\000?Cz\001\000\000\000" failed_bind = 1 max_fail = 3 utctime = {tm_sec = 0, tm_min = 0, tm_hour = -453022896, tm_mday = 32733, tm_mon = -453022936, tm_year = 32733, tm_wday = 0, tm_yday = 0, tm_isdst = 26485888, tm_gmtoff = 140591433548788, tm_zone = 0x17a4488 ""} time_now = 1363608767 timestr = "34633-453022935" failcnt_interval = lastfail = 0x0 tries = 0 failure = 1 actual_type_name = 0x7fddc8007c20 "krbPwdPolicyReference" attr_free_flags = 2 values = 0x7fddc8008560 __func__ = "ipalockout_postop" #3 0x00007fddfe4bd8e1 in plugin_call_func (list=0x17a4b20, operation=operation at entry=501, pb=pb at entry=0x1cad1b0, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7fddf4b9c280 rc = return_value = 0 count = 1 #4 0x00007fddfe4bdb07 in plugin_call_list (pb=0x1cad1b0, operation=501, list=) at ldap/servers/slapd/plugin.c:1415 No locals. #5 plugin_call_plugins (pb=pb at entry=0x1cad1b0, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:398 p = plugin_list_number = 2 rc = 0 do_op = #6 0x000000000041172e in do_bind (pb=0x1cad1b0) at ldap/servers/slapd/bind.c:818 ber = err = isroot = 0 method = 128 version = 3 auth_response_requested = 0 pw_response_requested = 0 rawdn = 0x7fddc8000d50 "uid=fbar1b,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" dn = saslmech = 0x0 cred = {bv_len = 3, bv_val = 0x7fddc8000ea0 "foo"} be = 0x191e730 ber_rc = rc = 2 sdn = 0x7fddc8000da0 referral = 0x0 errorbuf = '\000' , "?6t??\177\000\000\000\000\000\000\000\000\000\000\033\237?\000\000\000\000 \212???\177\000\000\020\000\000\000\000\000\000\000!\000\000\000\000\000\000\000?>t??\177\000\000\033\000\000\000\000\000\000\000\000\212???\177\000\000|Z?\002\000\000\000\000?6t??\177\000\000\034\071\n??\177\000\000\220u\202\r\000\000\000\000p\212???\177\000\000\020\000\000\000\000\000\000\000!\000\000\000\000\000\000\000?>t??\177\000\000\020\000\000\000\000\000\000\000P\212???\177\000\000?\t6\000\000\000\000\000?<\n??\177\000\000?+\n??\177\000\000\032m@\000\000\000\000\000\t6\000\000\000\000\000\000"... supported = pmech = authtypebuf = '\000' bind_target_entry = 0x7fddc8001c90 auto_bind = minssf = minssf_exclude_rootdse = #7 0x0000000000417113 in connection_dispatch_operation (pb=, op=0x1cad4b0, conn=0x7fddec156e10) at ldap/servers/slapd/connection.c:568 minssf = 0 minssf_exclude_rootdse = #8 connection_threadmain () at ldap/servers/slapd/connection.c:2345 is_timedout = 0 curtime = pb = 0x1cad1b0 interval = 10000 conn = 0x7fddec156e10 op = 0x1cad4b0 tag = 96 need_wakeup = 0 need_conn_release = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #9 0x00007fddfcabce23 in _pt_root (arg=0x1ca5020) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:156 thred = 0x1ca5020 detached = 1 #10 0x00007fddfc45fd15 in start_thread (arg=0x7fdde4ff9700) at pthread_create.c:308 __res = pd = 0x7fdde4ff9700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140591006455552, -7801243002481506053, 1, 140591435722752, 140591006455552, 0, 7784369896572750075, 7784351394420001019}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 pagesize_m1 = sp = freesize = #11 0x00007fddfc19246d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 No locals. From pvoborni at redhat.com Mon Mar 18 14:15:45 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 Mar 2013 15:15:45 +0100 Subject: [Freeipa-devel] [PATCH] 264-265 Web UI:Certificate pages In-Reply-To: <51438EC6.8080805@redhat.com> References: <5127A039.6030902@redhat.com> <513680DD.3030806@redhat.com> <5137661F.1030705@redhat.com> <51438EC6.8080805@redhat.com> Message-ID: <51472191.6020904@redhat.com> On 03/15/2013 10:12 PM, Endi Sukma Dewata wrote: > On 3/6/2013 9:51 AM, Petr Vobornik wrote: 8><------ >>> 2. Right now the fields in the cert details page are editable although >>> there is no Update button. If you change the value an Undo button will >>> appear. If you try to leave the page it will show the Unsaved Changes >>> dialog. Since there's no cert-mod operation these fields should not be >>> editable. > > The certificate field is still editable. There's an undo button and > you'll get a 'page dirty' dialog. Could we make it read-only text field? > >>> 3. In the cert details page if you revoke the cert it will work but an >>> error will appear below the revocation reason field saying 'Must be an >>> integer'. >> >> #2, #3: I forget to tell you, that this patch also depends on my patch >> #261 - Fix handling of no_update flag in Web UI. Sorry. It should fix >> it. It was pushed to master today. > > Everything else is fixed except for the certificate field above. > 8><------ >>> 7. Certificate can be added/revoked/restored via certificate pages and >>> host/service details pages. We need to make sure that if you do an >>> operation on one page, the other pages won't show outdated information. >> >> Fixed. > > I added a cert via host details page. When I go to the cert search page > the new cert doesn't appear until I click Refresh. The revoke/restore > works though, the status are updated automatically in all pages. > 8><------ > > So the remaining issues are #2 and #7. Other than that it's ACKed. Feel > free to fix and push. > Fixed (#2, #7). Also metadata updated,added. Pushed to master, ipa-3-1. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0264-2-Web-UI-Certificate-pages.patch Type: text/x-patch Size: 38307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0265-1-Web-UI-Choose-different-search-option-for-cert-find.patch Type: text/x-patch Size: 10430 bytes Desc: not available URL: From pvoborni at redhat.com Mon Mar 18 14:17:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 Mar 2013 15:17:19 +0100 Subject: [Freeipa-devel] [PATCH] 0007 Web UI: Realm Domains page In-Reply-To: <514217D1.2080001@redhat.com> References: <512E2446.5060802@redhat.com> <512E2FF0.9040609@redhat.com> <513622D5.10705@redhat.com> <51370F17.1080802@redhat.com> <51379880.1080700@redhat.com> <51387CE4.2040001@redhat.com> <513893EC.2040101@redhat.com> <5138C136.9000504@redhat.com> <5138DA82.1010601@redhat.com> <514217D1.2080001@redhat.com> Message-ID: <514721EF.6020403@redhat.com> On 03/14/2013 07:32 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 03/07/2013 05:32 PM, Petr Vobornik wrote: >>> On 03/07/2013 02:19 PM, Ana Krivokapic wrote: >>>> On 03/07/2013 12:41 PM, Petr Vobornik wrote: >>>>> On 03/06/2013 08:26 PM, Ana Krivokapic wrote: >>>>>> On 03/06/2013 10:40 AM, Petr Vobornik wrote: >>>>>>> On 03/05/2013 05:52 PM, Ana Krivokapic wrote: >>>>>>>> On 02/27/2013 05:10 PM, Petr Vobornik wrote: >>>>>>>>> On 02/27/2013 04:20 PM, Ana Krivokapic wrote: >>>>>>>>>> Add support for Realm Domains to web UI. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3407 >>>>>>>>> >>> >>> 8><----------------------- >>> >>>>> >>>>> Almost there, as discussed in person: >>>>> >>>>> 1. following strings should be add to and obtained from internal.py >>>>> plugin: >>>>> title: 'Check DNS', >>>>> message: 'Do you also want to perform DNS check?', >>>>> ok_label: 'Check DNS', >>>>> >>>>> >>>>> 2. the server plugin should report all dns resolution failures, not >>>>> just the first one. >>>> >>>> Fixed, updated patch is attached. >>>> >>> Works fine, but you forgot to update all related tests >>> (s/domain/domains/): >>> >>>> ====================================================================== >>>> FAIL: test_realmdomains[8]: realmdomains_mod: Try to replace list of >>>> realm domains with a list with an invalid domain "doesnotexist.test" >>>> ---------------------------------------------------------------------- >>>> 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/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>>> line 264, in >>>> func = lambda: self.check(nice, **test) >>>> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>>> line 278, in check >>>> self.check_exception(nice, cmd, args, options, expected) >>>> File "/home/pvoborni/dev/freeipa/tests/test_xmlrpc/xmlrpc_test.py", >>>> line 304, in check_exception >>>> assert_deepequal(expected.strerror, e.strerror) >>>> File "/home/pvoborni/dev/freeipa/tests/util.py", line 343, in >>>> assert_deepequal >>>> VALUE % (doc, expected, got, stack) >>>> AssertionError: assert_deepequal: expected != got. >>>> >>>> expected = u"invalid 'domain': no SOA or NS records found for >>>> domains: doesnotexist.test" >>>> got = u"invalid 'domain': no SOA or NS records found for domain >>>> doesnotexist.test" >>>> path = () >>>> >>>> ---------------------------------------------------------------------- >>> >> >> False alarm. It was an error on my side. >> >> ACK > > Is this ready to be pushed? Do we need an ACK from Kyle too? > > rob Pushed to master, ipa-3-1. Originally I waited for other patches to push it at once, but it takes more time then expected. -- Petr Vobornik From simo at redhat.com Mon Mar 18 15:07:24 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 18 Mar 2013 11:07:24 -0400 Subject: [Freeipa-devel] [PROPOSAL] Kerberos flags In-Reply-To: <5144DA19.5090804@redhat.com> References: <5138F556.8020504@redhat.com> <5139B00E.1080000@redhat.com> <1362750086.2822.113.camel@willson.li.ssimo.org> <513EF400.4030408@redhat.com> <1363091673.2822.166.camel@willson.li.ssimo.org> <513F3C45.4040206@redhat.com> <513F3E34.9000400@redhat.com> <513F41FB.7030108@redhat.com> <513F4317.8010004@redhat.com> <513F5191.5080807@redhat.com> <1363105473.2822.183.camel@willson.li.ssimo.org> <513F587E.4070500@redhat.com> <1363107660.2822.187.camel@willson.li.ssimo.org> <513F668A.4090500@redhat.com> <1363111343.2822.195.camel@willson.li.ssimo.org> <5144DA19.5090804@redhat.com> Message-ID: <1363619244.2822.697.camel@willson.li.ssimo.org> On Sat, 2013-03-16 at 16:46 -0400, Dmitri Pal wrote: > On 03/12/2013 02:02 PM, Simo Sorce wrote: > > On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: > >> On 12.3.2013 18:01, Simo Sorce wrote: > >>> On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: > >>>> On 12.3.2013 17:24, Simo Sorce wrote: > >>>>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: > >>>>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an > >>>>>> ACI preventing that, I'm just wondering what is the reason for this.) > >>>>> If you tell me who 'we' is (as in what user would set it) I can tell you > >>>>> why it is/isn't possible. > >>>> Why no IPA user (including admins) can set the attribute? > >>> I guess admins should be allowed to. > >>> > >>> Users can't, as ticket flags change the behavior of the principal in > >>> ways only admins should allowed to. (preauth required or not, AS > >>> requests disabled or not, etc...) > >> Thanks. For normal users it's obvious, but it seemed a little bit > >> strange to disallow admins to set the flags. > >> > >> So, can the krbTicketFlags attribute be used internally in IPA plugins > >> to set/unset the flags, given that the ACI is changed to allow admins to > >> modify the attribute? > > The problem is determining if all the flags can be set by the same set > > of admins or if we need to be able to delegate some of them. In the > > second case we have only 2 options: > > 1) break the flags out in multiple attributes so we can set separate > > ACIs > > 2) create a plugin that can intercept and filter modifications to the > > attribute so only the allowed flags are changed > > > > The first option has the problem that we are going to change the schema. > > The second option has the problem that the check will be less flexible > > than with regular ACIs (unless we use some sort of virtual ACI) and > > duplicates access control points. > > > > Anyway we need to find out if we really need fine grained access control > > per flags or not before wrapping our heads. > > > > Simo. > > > Do we have a decision on this? > Have we determined that the flags actually have to be delegated and have > different access privileges? > Can we start with allowing admins to change them all and reconsider when > anyone actually asks for a finer grain access control? We decided there is no flag that should ever be delegated to less powerful admins. So we can proceed with allowing the admins group access to this whole attribute w/o need to break it down into parts. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 18 15:07:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Mar 2013 11:07:39 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51470BEF.1080108@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> Message-ID: <51472DBB.5020900@redhat.com> Martin Kosek wrote: > On 03/15/2013 04:42 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>> See patch >>>>> for details. >>>>> >>>>> rob >>>>> >>>> >>>> I see some issues with this fix: >>>> >>>> 1) Shouldn't group password policy serve only as an override to the main >>>> policy? I.e. if I have this policy: >>>> >>>> # ipa pwpolicy-show test >>>> Group: test >>>> Priority: 10 >>>> Max failures: 2 >>>> >>>> We should still follow settings other than "Max failures" configured in >>>> global policy, right? At least the Kerberos seem to do it. I think we >>>> should be consistent in this case. Now, other values just seem to be >>>> zero. >>> >>> There should be only one policy. It isn't supposed to merge policies >>> together (there is only one krbPwdPolicyReference per principal). > > That's a good point. > >>> >>> How is the KDC acting differently? > > For example, if you set only maximal number of bad password guesses, it does > not allow any more (user fbar1 is a member of test group): > > # ipa pwpolicy-mod test --maxfail 3 > Group: test > Priority: 10 > Max failures: 3 > > # kinit fbar1 > Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: > kinit: Password incorrect while getting initial credentials > # kinit fbar1 > Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: > kinit: Password incorrect while getting initial credentials > # kinit fbar1 > Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: > kinit: Password incorrect while getting initial credentials > # kinit fbar1 > kinit: Clients credentials have been revoked while getting initial credentials > > But LDAP binds are still allowed > > # ldapsearch -h localhost -D > uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo > -s base -b "" > ldap_bind: Invalid credentials (49) > > I think this is just caused by different processing of > krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, > max auth tries checks are pretty much disabled). We can't examine things until a successful bind is done. If it is done and we determine that they should be locked out we refuse to continue. > >>> >>>> I think we will need to fix both the pre-op and the post-op to make this >>>> working really consistently. >>>> >>>> 2) The lockout post-op still counts failed logins even though we are in >>>> lockout time, is this expected? It is another point if inconsistency >>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>> failures". >>> >>> Ok. >>> >>>> >>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>> and then wait some time until the lockout time passes (no admin unlock), >>>> I am able to run as many LDAP binds as I want. >>> >>> Can you clarify? Successful or unsuccessful binds? > > Unsuccessful binds. I will try to reproduce it again when you fix the crash, it > is hard to investigate it with this crash around. > >>> >>>> This is all I found so far. Honza is also reviewing it, so I will let >>>> him post hist findings too. >>>> >>>> Martin >> >> Here is an updated patch to not increment past the max failures on LDAP binds. > > The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a > user with no group policy assigned (Stacktrace attached). Stupid mistake on my part. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-3-lockout.patch Type: text/x-diff Size: 11226 bytes Desc: not available URL: From abokovoy at redhat.com Mon Mar 18 15:32:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 Mar 2013 17:32:05 +0200 Subject: [Freeipa-devel] master is broken on F18 In-Reply-To: <20130318114838.GH24679@redhat.com> References: <1755733905.1591956.1363366587361.JavaMail.root@redhat.com> <51437F6D.6080605@redhat.com> <1363468790.10244.44.camel@localhost> <5145C85A.7080307@redhat.com> <5146DC7D.3090808@redhat.com> <20130318114838.GH24679@redhat.com> Message-ID: <20130318153204.GI24679@redhat.com> On Mon, 18 Mar 2013, Alexander Bokovoy wrote: >On Mon, 18 Mar 2013, Martin Kosek wrote: >>On 03/17/2013 02:42 PM, John Dennis wrote: >>>On 03/16/2013 05:19 PM, Kai Engert wrote: >>>>On Fri, 2013-03-15 at 16:07 -0400, John Dennis wrote: >>>>>On 03/15/2013 12:56 PM, Alexander Bokovoy wrote: >>>>>>Hi! >>>>>> >>>>>>I was investigating why installing master fails on F18 + >>>>>>updates-testing and found out that install fails with >>>>>>freeipa-server-3.1.99-0.20130313T1838Zgit158bf45.fc18.x86_64 from >>>>>>ipa-devel repo >>>>>> >>>>>>2013-03-15T16:17:40Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>>>>>-R -s CN=jano.ipa.team,O=IPA.TEAM -o >>>>>>/var/lib/ipa/ipa-aza7Wg/tmpcertreq -k rsa -g 2048 -z >>>>>>/etc/httpd/alias/noise.txt -f /etc/httpd/alias/pwdfile.txt -a >>>>>>2013-03-15T16:17:41Z DEBUG Process finished, return code=0 >>>>>>2013-03-15T16:17:41Z DEBUG stdout= 2013-03-15T16:17:41Z DEBUG >>>>>>stderr= >>>>>> >>>>>>Generating key. This may take a few moments... >>>>> >>>>>I believe this is a known problem in certutil where it writes data to >>>>>the wrong file descriptor. The problem was fixed upstream about 10 days >>>>>ago, I'm not sure if Fedora has the fix yet or not. Kai would know, I've >>>>>added him on the cc list. >>>> >>>> >>>>Hi John, >>>> >>>>in the above cited message, you didn't include the failure you were >>>>seeing, so I have to guess. >>>> >>>>This one is the only functional patch to certutil during the last 8-9 >>>>weeks that I could find. Do you refer to this one? >>>> >>>>Bug 840714 - certutil -a does not produce ASCII output >>>>https://bugzilla.mozilla.org/show_bug.cgi?id=840714 >>>> >>>>It was a regression in NSS 3.14.2, and it got fixed in 3.14.3. Fedora 18 >>>>apparently received that update on Feb 24. >>>>http://tinyurl.com/bym4rlh >>>> >>>>If the above didn't help, please send more details or ping me on IRC. >>> >>>Thank you Kai. Yes, that was the regression I was referring to. It's good to >>>know when the fix appeared because we've had a number of folks report problems >>>due to it. However Alexander's issue may be something else. In any event, thank >>>you. >>> >> >>Alexander, any luck with resolving this issue? I just tested current Freeipa >>master branch with up-to-date Fedora 18 and installation worked for me. I do >>not have updates-testing enabled though. I am still not convinced this is >>caused by latest patches that were pushed. >No, there is no change in behavior. > >Even with latest updates to tomcat6 from updates-testing HEAD on master >fails when installing on F18+updates-testing. The same machine happily >installs code before LDAP restructuring patches applied. > >Unfortunately, I cannot experiment to find out exact failing patch right >now but we should aim for working F18+updates-testing setup if possible. Now I did create fresh VM with F18 and applied all updates-testing + updates repo changes, enabled ipa-devel and installed the server successfully. I guess there is something we mess in existing install and don't remove properly data from certificate databases during uninstall after package upgrades. This is just a guess, though. I have working F18 machine and can continue trust work in master... -- / Alexander Bokovoy From dpal at redhat.com Mon Mar 18 17:45:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 18 Mar 2013 13:45:38 -0400 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <51470169.1090308@redhat.com> References: <51470169.1090308@redhat.com> Message-ID: <514752C2.5080104@redhat.com> On 03/18/2013 07:58 AM, Petr Viktorin wrote: > Hello, > While the work is not complete, these patches allowed me to install an > IPA server without a CA, using PKCS#12 files for the server certs. > > The patches don't break normal installation. > The --selfsign option (but not yet the code behind it) is removed. > > The absence of a CA is indicated by `enable_ra=False` in the IPA config. > > ipa-replica-install will still refuse to run; I'll look into that next. > > I removed some unused code that got in my way: Dogtag 9 installation > (we can run a Dogtag 9-style CA, but we never *install* it), and > ipapython.certdb.CertDB (unused, not to be confused with ipaserver's > CertDB). > > I tried using python-nss, but unfortunately found that it's not yet > usable here. John filed > https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our > conversation. Parsing certutil output, while dirty, is more reliable > in my limited experience. > I added ipaserver.install.certs.NSSDatabase as a general-purpose > wrapper around certdb operations. We have a CertDB class for it but > that one is too tied to the current code paths: when I used it I found > myself re-implementing a lot of methods to get rid of some assumption > or other. The new NSSDatabase is not tied to IPA configuration. > > > From what I've learned, PKCS#12 files are just a bag of certificates; > there are basically no restrictions on their contents. But we assume > there's only one cert inside that has a private key, and use that for > the server cert. We also pretty much assume that there's one CA cert: > if not we pick the first one and trust it as root CA. > In short, I think --http_pkcs & friends are too vague for PKCS#12s we > don't control; we should have the user name the certs more explicitly. > Am I wrong here? Is this the usual way to import server certs? If we do not do anything about this now we should at least clearly document the assumptions and how things work to avoid surprises. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 18 21:24:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Mar 2013 17:24:49 -0400 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <51470169.1090308@redhat.com> References: <51470169.1090308@redhat.com> Message-ID: <51478621.9090503@redhat.com> Petr Viktorin wrote: > Hello, > While the work is not complete, these patches allowed me to install an > IPA server without a CA, using PKCS#12 files for the server certs. > > The patches don't break normal installation. > The --selfsign option (but not yet the code behind it) is removed. > > The absence of a CA is indicated by `enable_ra=False` in the IPA config. > > ipa-replica-install will still refuse to run; I'll look into that next. > > I removed some unused code that got in my way: Dogtag 9 installation (we > can run a Dogtag 9-style CA, but we never *install* it), and > ipapython.certdb.CertDB (unused, not to be confused with ipaserver's > CertDB). > > I tried using python-nss, but unfortunately found that it's not yet > usable here. John filed > https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our > conversation. Parsing certutil output, while dirty, is more reliable in > my limited experience. > I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper > around certdb operations. We have a CertDB class for it but that one is > too tied to the current code paths: when I used it I found myself > re-implementing a lot of methods to get rid of some assumption or other. > The new NSSDatabase is not tied to IPA configuration. > > > From what I've learned, PKCS#12 files are just a bag of certificates; > there are basically no restrictions on their contents. But we assume > there's only one cert inside that has a private key, and use that for > the server cert. We also pretty much assume that there's one CA cert: if > not we pick the first one and trust it as root CA. > In short, I think --http_pkcs & friends are too vague for PKCS#12s we > don't control; we should have the user name the certs more explicitly. > Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. Or we can add a new option to pass in the CA bundle in PEM format. I'm not sure that order is guaranteed so I'm not sure your comparison that the DS and HTTP certs are signed by the same issuer will be true. In any case it may not matter, as long as they are trusted. It does raise the issue of what CA to put into /etc/ipa and LDAP but if it is an existing root cert there should be no issues. So there are really 2 use cases here: - They got certs from an upstream CA like Verisign, Thawte, etc. - They got certs from an internal CA. For case #1 there is probably nothing to do as the CAs are likely already trusted by the world. The second case needs to be handled more carefully. There was a time, and it still may be the case, where we loosely handled the format of certificates. In some cases it was PEM, in others it was DER, and the only way you'd know is if you coded it or happened to look at the contents of the variable. We decided on trying to keep all certs internally in DER format, at least for the framework CA code. We typically use the variable dercert in that case. I didn't notice any inconsistencies, just something for you to be aware of. For find_server_certs() I wonder what happens if you pass in a PKCS#12 file with no CA's. It may not set any u flags if the cert comes from an unknown issuer, so we would report no server certificates found, but the real problem is no CA's found. I'm not sure the dogtag 9 removal code really fits in the context of these changes. It makes sense, but has nothing to do with this. You can probably simplify the imports of certdb.py along with the code removal. rob From mkosek at redhat.com Tue Mar 19 08:11:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Mar 2013 09:11:39 +0100 Subject: [Freeipa-devel] [PATCH] 390 ipa-client discovery with anonymous access off Message-ID: <51481DBB.7010401@redhat.com> When RootDSE could be read (nsslapd-allow-anonymous-access set to "rootdse"), autodiscovery module failed to report success to the client installer. Remove faulty "verified_servers" flag from autodiscovery module as it has no point since we consider both scenarios (IPA server with anonymous access on and unknown LDAP server with anonymous access off) as success. https://fedorahosted.org/freeipa/ticket/3519 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-390-ipa-client-discovery-with-anonymous-access-off.patch Type: text/x-patch Size: 2757 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 19 09:20:50 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Mar 2013 10:20:50 +0100 Subject: [Freeipa-devel] [PATCH] 390 ipa-client discovery with anonymous access off In-Reply-To: <51481DBB.7010401@redhat.com> References: <51481DBB.7010401@redhat.com> Message-ID: <51482DF2.3050605@redhat.com> On 03/19/2013 09:11 AM, Martin Kosek wrote: > When RootDSE could be read (nsslapd-allow-anonymous-access set to > "rootdse"), autodiscovery module failed to report success to the > client installer. > > Remove faulty "verified_servers" flag from autodiscovery module as > it has no point since we consider both scenarios (IPA server with > anonymous access on and unknown LDAP server with anonymous access > off) as success. > > https://fedorahosted.org/freeipa/ticket/3519 > ACK, this fixes the problem -- Petr? From mkosek at redhat.com Tue Mar 19 09:57:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Mar 2013 10:57:57 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51472DBB.5020900@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> Message-ID: <514836A5.2010600@redhat.com> On 03/18/2013 04:07 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>> See patch >>>>>> for details. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> I see some issues with this fix: >>>>> >>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>> policy? I.e. if I have this policy: >>>>> >>>>> # ipa pwpolicy-show test >>>>> Group: test >>>>> Priority: 10 >>>>> Max failures: 2 >>>>> >>>>> We should still follow settings other than "Max failures" configured in >>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>> should be consistent in this case. Now, other values just seem to be >>>>> zero. >>>> >>>> There should be only one policy. It isn't supposed to merge policies >>>> together (there is only one krbPwdPolicyReference per principal). >> >> That's a good point. >> >>>> >>>> How is the KDC acting differently? >> >> For example, if you set only maximal number of bad password guesses, it does >> not allow any more (user fbar1 is a member of test group): >> >> # ipa pwpolicy-mod test --maxfail 3 >> Group: test >> Priority: 10 >> Max failures: 3 >> >> # kinit fbar1 >> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >> kinit: Password incorrect while getting initial credentials >> # kinit fbar1 >> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >> kinit: Password incorrect while getting initial credentials >> # kinit fbar1 >> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >> kinit: Password incorrect while getting initial credentials >> # kinit fbar1 >> kinit: Clients credentials have been revoked while getting initial credentials >> >> But LDAP binds are still allowed >> >> # ldapsearch -h localhost -D >> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >> -s base -b "" >> ldap_bind: Invalid credentials (49) >> >> I think this is just caused by different processing of >> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >> max auth tries checks are pretty much disabled). > > We can't examine things until a successful bind is done. If it is done and we > determine that they should be locked out we refuse to continue. I am not sure I follow - what do you mean by "examine things"? The bind preop plugin can check current policy with unsuccessful login, right? I just thought that when the custom policy has krbpwdmaxfailure set, but does not have krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure "somehow", as ipa-kdb does. If not, I think we should either mark those params in pwpolicy plugin as required or at least add a note to ipa help mentioning this limitation for LDAP binds.... > >> >>>> >>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>> working really consistently. >>>>> >>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>> lockout time, is this expected? It is another point if inconsistency >>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>> failures". >>>> >>>> Ok. >>>> >>>>> >>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>> I am able to run as many LDAP binds as I want. >>>> >>>> Can you clarify? Successful or unsuccessful binds? >> >> Unsuccessful binds. I will try to reproduce it again when you fix the crash, it >> is hard to investigate it with this crash around. >> >>>> >>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>> him post hist findings too. >>>>> >>>>> Martin >>> >>> Here is an updated patch to not increment past the max failures on LDAP binds. >> >> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >> user with no group policy assigned (Stacktrace attached). > > Stupid mistake on my part. > > rob > Fixed now :) I found one more issue. When you add a new user with a password, wrong LDAP binds do not increase failure count until the latest failure timestamp is set, for example via failed Kerberos login: # ipa user-status fbar2 ----------------------- Account disabled: False ----------------------- Server: vm-037.idm.lab.bos.redhat.com Failed logins: 0 Last successful authentication: N/A Last failed authentication: N/A Time now: 2013-03-19T09:01:35Z ---------------------------- Number of entries returned 1 ---------------------------- # ldapsearch -h localhost -D uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo -s base -b "" ldap_bind: Invalid credentials (49) # ipa user-status fbar2 ----------------------- Account disabled: False ----------------------- Server: vm-037.idm.lab.bos.redhat.com Failed logins: 0 Last successful authentication: N/A Last failed authentication: N/A Time now: 2013-03-19T09:01:54Z ---------------------------- Number of entries returned 1 ---------------------------- # kinit fbar2 Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: kinit: Password incorrect while getting initial credentials # ipa user-status fbar2 ----------------------- Account disabled: False ----------------------- Server: vm-037.idm.lab.bos.redhat.com Failed logins: 1 Last successful authentication: N/A Last failed authentication: 2013-03-19T09:02:14Z Time now: 2013-03-19T09:02:16Z ---------------------------- Number of entries returned 1 ---------------------------- # ldapsearch -h localhost -D uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo -s base -b "" ldap_bind: Invalid credentials (49) # ipa user-status fbar2 ----------------------- Account disabled: False ----------------------- Server: vm-037.idm.lab.bos.redhat.com Failed logins: 2 <<<<<< It increased now Last successful authentication: N/A Last failed authentication: 2013-03-19T09:02:20Z Time now: 2013-03-19T09:02:24Z ---------------------------- Number of entries returned 1 ---------------------------- As for the issue you could not reproduce, it is also quite difficult to reproduce it for me, I usually have to combine same failed/successful logins, waits for lockouts etc. I need to look at that more closely. Just for the record, attaching an LDIF of a user in such a state when I can do as many failing ldapsearches as I want. This is the password policy: # ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 30 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: failing-user.ldif Type: text/x-ldif Size: 2291 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 19 11:09:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Mar 2013 12:09:27 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <51478621.9090503@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> Message-ID: <51484767.1080602@redhat.com> On 03/18/2013 10:24 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello, >> While the work is not complete, these patches allowed me to install an >> IPA server without a CA, using PKCS#12 files for the server certs. >> >> The patches don't break normal installation. >> The --selfsign option (but not yet the code behind it) is removed. >> >> The absence of a CA is indicated by `enable_ra=False` in the IPA config. >> >> ipa-replica-install will still refuse to run; I'll look into that next. >> >> I removed some unused code that got in my way: Dogtag 9 installation (we >> can run a Dogtag 9-style CA, but we never *install* it), and >> ipapython.certdb.CertDB (unused, not to be confused with ipaserver's >> CertDB). >> >> I tried using python-nss, but unfortunately found that it's not yet >> usable here. John filed >> https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our >> conversation. Parsing certutil output, while dirty, is more reliable in >> my limited experience. >> I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper >> around certdb operations. We have a CertDB class for it but that one is >> too tied to the current code paths: when I used it I found myself >> re-implementing a lot of methods to get rid of some assumption or other. >> The new NSSDatabase is not tied to IPA configuration. >> >> >> From what I've learned, PKCS#12 files are just a bag of certificates; >> there are basically no restrictions on their contents. But we assume >> there's only one cert inside that has a private key, and use that for >> the server cert. We also pretty much assume that there's one CA cert: if >> not we pick the first one and trust it as root CA. >> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >> don't control; we should have the user name the certs more explicitly. >> Am I wrong here? Is this the usual way to import server certs? > > We can impose a requirement that the CA be included in the PKCS#12 > files. At least with NSS this happens automatically, I can't recall with > openssl. I think most tools will at least give you the option to export the whole trust chain. > Or we can add a new option to pass in the CA bundle in PEM format. I guess we could reuse --external_ca_file for it. > I'm not sure that order is guaranteed so I'm not sure your comparison > that the DS and HTTP certs are signed by the same issuer will be true. > In any case it may not matter, as long as they are trusted. It does > raise the issue of what CA to put into /etc/ipa and LDAP but if it is an > existing root cert there should be no issues. The real problem here is that since the order is not guaranteed, if there is more than one CA it might end up picking the wrong one to give root trust to. Receiving the CA cert explicitly would solve the issue. > So there are really 2 use cases here: > > - They got certs from an upstream CA like Verisign, Thawte, etc. > - They got certs from an internal CA. > > For case #1 there is probably nothing to do as the CAs are likely > already trusted by the world. The second case needs to be handled more > carefully. Even for case #1 we still need to put something in /etc/ipa/ca.crt. I guess in this case it would be the globally trusted root cert? > There was a time, and it still may be the case, where we loosely handled > the format of certificates. In some cases it was PEM, in others it was > DER, and the only way you'd know is if you coded it or happened to look > at the contents of the variable. > > We decided on trying to keep all certs internally in DER format, at > least for the framework CA code. We typically use the variable dercert > in that case. I didn't notice any inconsistencies, just something for > you to be aware of. I'll keep it in mind. In my patch I mostly operate with nssdb names, because when the certs are imported I can check the flags. > For find_server_certs() I wonder what happens if you pass in a PKCS#12 > file with no CA's. It may not set any u flags if the cert comes from an > unknown issuer, so we would report no server certificates found, but the > real problem is no CA's found. AFAIK, "u" just means that we have the corresponding private key, so in this case you should get an error about CAs found. > I'm not sure the dogtag 9 removal code really fits in the context of > these changes. It makes sense, but has nothing to do with this. I had that patch almost ready. When I was doing the certs and some Dogtag 9 code got in my way I just took the patch, cleaned it up and included it. So yes, it touches a more than certs. Should I make a separate review thread for it? > You can probably simplify the imports of certdb.py along with the code > removal. Will do. -- Petr? From mkosek at redhat.com Tue Mar 19 12:05:36 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Mar 2013 13:05:36 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <514836A5.2010600@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> Message-ID: <51485490.2050507@redhat.com> On 03/19/2013 10:57 AM, Martin Kosek wrote: > On 03/18/2013 04:07 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>> See patch >>>>>>> for details. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> I see some issues with this fix: >>>>>> >>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>> policy? I.e. if I have this policy: >>>>>> >>>>>> # ipa pwpolicy-show test >>>>>> Group: test >>>>>> Priority: 10 >>>>>> Max failures: 2 >>>>>> >>>>>> We should still follow settings other than "Max failures" configured in >>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>> should be consistent in this case. Now, other values just seem to be >>>>>> zero. >>>>> >>>>> There should be only one policy. It isn't supposed to merge policies >>>>> together (there is only one krbPwdPolicyReference per principal). >>> >>> That's a good point. >>> >>>>> >>>>> How is the KDC acting differently? >>> >>> For example, if you set only maximal number of bad password guesses, it does >>> not allow any more (user fbar1 is a member of test group): >>> >>> # ipa pwpolicy-mod test --maxfail 3 >>> Group: test >>> Priority: 10 >>> Max failures: 3 >>> >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> kinit: Clients credentials have been revoked while getting initial credentials >>> >>> But LDAP binds are still allowed >>> >>> # ldapsearch -h localhost -D >>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>> -s base -b "" >>> ldap_bind: Invalid credentials (49) >>> >>> I think this is just caused by different processing of >>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >>> max auth tries checks are pretty much disabled). >> >> We can't examine things until a successful bind is done. If it is done and we >> determine that they should be locked out we refuse to continue. > > I am not sure I follow - what do you mean by "examine things"? The bind preop > plugin can check current policy with unsuccessful login, right? I just thought > that when the custom policy has krbpwdmaxfailure set, but does not have > krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure > "somehow", as ipa-kdb does. > > If not, I think we should either mark those params in pwpolicy plugin as > required or at least add a note to ipa help mentioning this limitation for LDAP > binds.... > >> >>> >>>>> >>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>> working really consistently. >>>>>> >>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>> failures". >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>> I am able to run as many LDAP binds as I want. >>>>> >>>>> Can you clarify? Successful or unsuccessful binds? >>> >>> Unsuccessful binds. I will try to reproduce it again when you fix the crash, it >>> is hard to investigate it with this crash around. >>> >>>>> >>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>> him post hist findings too. >>>>>> >>>>>> Martin >>>> >>>> Here is an updated patch to not increment past the max failures on LDAP binds. >>> >>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>> user with no group policy assigned (Stacktrace attached). >> >> Stupid mistake on my part. >> >> rob >> > > Fixed now :) I found one more issue. When you add a new user with a password, > wrong LDAP binds do not increase failure count until the latest failure > timestamp is set, for example via failed Kerberos login: > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 0 > Last successful authentication: N/A > Last failed authentication: N/A > Time now: 2013-03-19T09:01:35Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # ldapsearch -h localhost -D > uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo > -s base -b "" > ldap_bind: Invalid credentials (49) > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 0 > Last successful authentication: N/A > Last failed authentication: N/A > Time now: 2013-03-19T09:01:54Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # kinit fbar2 > Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: > kinit: Password incorrect while getting initial credentials > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 1 > Last successful authentication: N/A > Last failed authentication: 2013-03-19T09:02:14Z > Time now: 2013-03-19T09:02:16Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # ldapsearch -h localhost -D > uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo > -s base -b "" > ldap_bind: Invalid credentials (49) > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 2 <<<<<< It increased now > Last successful authentication: N/A > Last failed authentication: 2013-03-19T09:02:20Z > Time now: 2013-03-19T09:02:24Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > > As for the issue you could not reproduce, it is also quite difficult to > reproduce it for me, I usually have to combine same failed/successful logins, > waits for lockouts etc. I need to look at that more closely. Just for the > record, attaching an LDIF of a user in such a state when I can do as many > failing ldapsearches as I want. This is the password policy: > > # ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 8 > Max failures: 6 > Failure reset interval: 60 > Lockout duration: 30 > > Martin > I discovered that the issue is in the postop: + if (failedcount < max_fail) { + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", failedcount); + slapi_mods_add_string(smods, LDAP_MOD_DELETE, "krbLoginFailedCount", failedcountstr); + failedcount += 1; + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", failedcount); + slapi_mods_add_string(smods, LDAP_MOD_ADD, "krbLoginFailedCount", failedcountstr); } We try to delete failedcount and add failedcount+1, but this operation may fail if the failedcount was set to 0 previously due to exceeded krbpwdfailurecountinterval. This also makes the succeeding last failed auth timestamp update to fail too and cause this vulnerability. I was able to fix it with this change: @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) */ if (failed_bind) { if (failedcount < max_fail) { - PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", failedcount); - slapi_mods_add_string(smods, LDAP_MOD_DELETE, "krbLoginFailedCount", failedcountstr); failedcount += 1; PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", failedcount); - slapi_mods_add_string(smods, LDAP_MOD_ADD, "krbLoginFailedCount", failedcountstr); + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, "krbLoginFailedCount", failedcountstr); } if (lastfail) { if (!gmtime_r(&(time_now), &utctime)) { Martin From rcritten at redhat.com Tue Mar 19 14:27:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Mar 2013 10:27:18 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <514836A5.2010600@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> Message-ID: <514875C6.3070002@redhat.com> Martin Kosek wrote: > On 03/18/2013 04:07 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>> See patch >>>>>>> for details. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> I see some issues with this fix: >>>>>> >>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>> policy? I.e. if I have this policy: >>>>>> >>>>>> # ipa pwpolicy-show test >>>>>> Group: test >>>>>> Priority: 10 >>>>>> Max failures: 2 >>>>>> >>>>>> We should still follow settings other than "Max failures" configured in >>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>> should be consistent in this case. Now, other values just seem to be >>>>>> zero. >>>>> >>>>> There should be only one policy. It isn't supposed to merge policies >>>>> together (there is only one krbPwdPolicyReference per principal). >>> >>> That's a good point. >>> >>>>> >>>>> How is the KDC acting differently? >>> >>> For example, if you set only maximal number of bad password guesses, it does >>> not allow any more (user fbar1 is a member of test group): >>> >>> # ipa pwpolicy-mod test --maxfail 3 >>> Group: test >>> Priority: 10 >>> Max failures: 3 >>> >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> # kinit fbar1 >>> kinit: Clients credentials have been revoked while getting initial credentials >>> >>> But LDAP binds are still allowed >>> >>> # ldapsearch -h localhost -D >>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>> -s base -b "" >>> ldap_bind: Invalid credentials (49) >>> >>> I think this is just caused by different processing of >>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >>> max auth tries checks are pretty much disabled). >> >> We can't examine things until a successful bind is done. If it is done and we >> determine that they should be locked out we refuse to continue. > > I am not sure I follow - what do you mean by "examine things"? The bind preop > plugin can check current policy with unsuccessful login, right? I just thought > that when the custom policy has krbpwdmaxfailure set, but does not have > krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure > "somehow", as ipa-kdb does. > > If not, I think we should either mark those params in pwpolicy plugin as > required or at least add a note to ipa help mentioning this limitation for LDAP > binds.... Ok, I think I explained things wrongly before. This is already registered as a pre_bind plugin. I'll see if I can figure out what its doing. This should already be happening as you described. It could be that the bad auth return value is overriding the unwilling to perform. I'd think the bind wouldn't be attempted at all if we return an error in a pre-bind plugin. >> >>>>> >>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>> working really consistently. >>>>>> >>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>> failures". >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>> I am able to run as many LDAP binds as I want. >>>>> >>>>> Can you clarify? Successful or unsuccessful binds? >>> >>> Unsuccessful binds. I will try to reproduce it again when you fix the crash, it >>> is hard to investigate it with this crash around. >>> >>>>> >>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>> him post hist findings too. >>>>>> >>>>>> Martin >>>> >>>> Here is an updated patch to not increment past the max failures on LDAP binds. >>> >>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>> user with no group policy assigned (Stacktrace attached). >> >> Stupid mistake on my part. >> >> rob >> > > Fixed now :) I found one more issue. When you add a new user with a password, > wrong LDAP binds do not increase failure count until the latest failure > timestamp is set, for example via failed Kerberos login: > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 0 > Last successful authentication: N/A > Last failed authentication: N/A > Time now: 2013-03-19T09:01:35Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # ldapsearch -h localhost -D > uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo > -s base -b "" > ldap_bind: Invalid credentials (49) > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 0 > Last successful authentication: N/A > Last failed authentication: N/A > Time now: 2013-03-19T09:01:54Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # kinit fbar2 > Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: > kinit: Password incorrect while getting initial credentials > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 1 > Last successful authentication: N/A > Last failed authentication: 2013-03-19T09:02:14Z > Time now: 2013-03-19T09:02:16Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # ldapsearch -h localhost -D > uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo > -s base -b "" > ldap_bind: Invalid credentials (49) > > # ipa user-status fbar2 > ----------------------- > Account disabled: False > ----------------------- > Server: vm-037.idm.lab.bos.redhat.com > Failed logins: 2 <<<<<< It increased now > Last successful authentication: N/A > Last failed authentication: 2013-03-19T09:02:20Z > Time now: 2013-03-19T09:02:24Z > ---------------------------- > Number of entries returned 1 > ---------------------------- Yikes. > > As for the issue you could not reproduce, it is also quite difficult to > reproduce it for me, I usually have to combine same failed/successful logins, > waits for lockouts etc. I need to look at that more closely. Just for the > record, attaching an LDIF of a user in such a state when I can do as many > failing ldapsearches as I want. This is the password policy: > > # ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 8 > Max failures: 6 > Failure reset interval: 60 > Lockout duration: 30 > > Martin > We specifically don't want to use REPLACE. It is supposed to loop up to 5 times trying to clean things up. I'll see if I can figure out why the loop is failing. It may be due to other changes I made here. rob From tbabej at redhat.com Tue Mar 19 14:42:49 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 19 Mar 2013 15:42:49 +0100 Subject: [Freeipa-devel] [PATCH] 388-389 Improve client install LDAP cert retrieval fallback In-Reply-To: <5141D374.5090306@redhat.com> References: <5141D374.5090306@redhat.com> Message-ID: <51487969.4090705@redhat.com> On 03/14/2013 02:41 PM, Martin Kosek wrote: > [freeipa-mkosek-388-use-temporary-ccache-in-ipa-client-install.patch]: > > ipa-client-install failed if user had set his own KRB5CCNAME in his > environment. Use a temporary CCACHE for the installer to avoid these > kind of errors. > > [freeipa-mkosek-389-improve-client-install-ldap-cert-retrieval-fallback.patch]: > > CA certificate retrieval function did not fallback from LDAP to > HTTP based retrieval in case of an LDAP error, when for example > GSSAPI authentication failed. > > ------------- > > Sending Fedora 18 client installation fixes as per > https://bugzilla.redhat.com/show_bug.cgi?id=920716#c10 > > Martin > Fixes the issue just fine. Ack. Just a nitpick, only patch 389 is linked in Trac. I uploaded the second part as well, for consistency's sake. Tomas From rcritten at redhat.com Tue Mar 19 16:09:34 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Mar 2013 12:09:34 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51485490.2050507@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> Message-ID: <51488DBE.4000802@redhat.com> Martin Kosek wrote: > On 03/19/2013 10:57 AM, Martin Kosek wrote: >> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>>> See patch >>>>>>>> for details. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> I see some issues with this fix: >>>>>>> >>>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>>> policy? I.e. if I have this policy: >>>>>>> >>>>>>> # ipa pwpolicy-show test >>>>>>> Group: test >>>>>>> Priority: 10 >>>>>>> Max failures: 2 >>>>>>> >>>>>>> We should still follow settings other than "Max failures" configured in >>>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>>> should be consistent in this case. Now, other values just seem to be >>>>>>> zero. >>>>>> >>>>>> There should be only one policy. It isn't supposed to merge policies >>>>>> together (there is only one krbPwdPolicyReference per principal). >>>> >>>> That's a good point. >>>> >>>>>> >>>>>> How is the KDC acting differently? >>>> >>>> For example, if you set only maximal number of bad password guesses, it does >>>> not allow any more (user fbar1 is a member of test group): >>>> >>>> # ipa pwpolicy-mod test --maxfail 3 >>>> Group: test >>>> Priority: 10 >>>> Max failures: 3 >>>> >>>> # kinit fbar1 >>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>> kinit: Password incorrect while getting initial credentials >>>> # kinit fbar1 >>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>> kinit: Password incorrect while getting initial credentials >>>> # kinit fbar1 >>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>> kinit: Password incorrect while getting initial credentials >>>> # kinit fbar1 >>>> kinit: Clients credentials have been revoked while getting initial credentials >>>> >>>> But LDAP binds are still allowed >>>> >>>> # ldapsearch -h localhost -D >>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>>> -s base -b "" >>>> ldap_bind: Invalid credentials (49) >>>> >>>> I think this is just caused by different processing of >>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >>>> max auth tries checks are pretty much disabled). >>> >>> We can't examine things until a successful bind is done. If it is done and we >>> determine that they should be locked out we refuse to continue. >> >> I am not sure I follow - what do you mean by "examine things"? The bind preop >> plugin can check current policy with unsuccessful login, right? I just thought >> that when the custom policy has krbpwdmaxfailure set, but does not have >> krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure >> "somehow", as ipa-kdb does. >> >> If not, I think we should either mark those params in pwpolicy plugin as >> required or at least add a note to ipa help mentioning this limitation for LDAP >> binds.... >> >>> >>>> >>>>>> >>>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>>> working really consistently. >>>>>>> >>>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>>> failures". >>>>>> >>>>>> Ok. >>>>>> >>>>>>> >>>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>>> I am able to run as many LDAP binds as I want. >>>>>> >>>>>> Can you clarify? Successful or unsuccessful binds? >>>> >>>> Unsuccessful binds. I will try to reproduce it again when you fix the crash, it >>>> is hard to investigate it with this crash around. >>>> >>>>>> >>>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>>> him post hist findings too. >>>>>>> >>>>>>> Martin >>>>> >>>>> Here is an updated patch to not increment past the max failures on LDAP binds. >>>> >>>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>>> user with no group policy assigned (Stacktrace attached). >>> >>> Stupid mistake on my part. >>> >>> rob >>> >> >> Fixed now :) I found one more issue. When you add a new user with a password, >> wrong LDAP binds do not increase failure count until the latest failure >> timestamp is set, for example via failed Kerberos login: >> >> # ipa user-status fbar2 >> ----------------------- >> Account disabled: False >> ----------------------- >> Server: vm-037.idm.lab.bos.redhat.com >> Failed logins: 0 >> Last successful authentication: N/A >> Last failed authentication: N/A >> Time now: 2013-03-19T09:01:35Z >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> # ldapsearch -h localhost -D >> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >> -s base -b "" >> ldap_bind: Invalid credentials (49) >> >> # ipa user-status fbar2 >> ----------------------- >> Account disabled: False >> ----------------------- >> Server: vm-037.idm.lab.bos.redhat.com >> Failed logins: 0 >> Last successful authentication: N/A >> Last failed authentication: N/A >> Time now: 2013-03-19T09:01:54Z >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> # kinit fbar2 >> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >> kinit: Password incorrect while getting initial credentials >> >> # ipa user-status fbar2 >> ----------------------- >> Account disabled: False >> ----------------------- >> Server: vm-037.idm.lab.bos.redhat.com >> Failed logins: 1 >> Last successful authentication: N/A >> Last failed authentication: 2013-03-19T09:02:14Z >> Time now: 2013-03-19T09:02:16Z >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> # ldapsearch -h localhost -D >> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >> -s base -b "" >> ldap_bind: Invalid credentials (49) >> >> # ipa user-status fbar2 >> ----------------------- >> Account disabled: False >> ----------------------- >> Server: vm-037.idm.lab.bos.redhat.com >> Failed logins: 2 <<<<<< It increased now >> Last successful authentication: N/A >> Last failed authentication: 2013-03-19T09:02:20Z >> Time now: 2013-03-19T09:02:24Z >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> As for the issue you could not reproduce, it is also quite difficult to >> reproduce it for me, I usually have to combine same failed/successful logins, >> waits for lockouts etc. I need to look at that more closely. Just for the >> record, attaching an LDIF of a user in such a state when I can do as many >> failing ldapsearches as I want. This is the password policy: >> >> # ipa pwpolicy-show >> Group: global_policy >> Max lifetime (days): 90 >> Min lifetime (hours): 1 >> History size: 0 >> Character classes: 0 >> Min length: 8 >> Max failures: 6 >> Failure reset interval: 60 >> Lockout duration: 30 >> >> Martin >> > > I discovered that the issue is in the postop: > > + if (failedcount < max_fail) { > + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", > failedcount); > + slapi_mods_add_string(smods, LDAP_MOD_DELETE, > "krbLoginFailedCount", failedcountstr); > + failedcount += 1; > + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", > failedcount); > + slapi_mods_add_string(smods, LDAP_MOD_ADD, > "krbLoginFailedCount", failedcountstr); > } > > We try to delete failedcount and add failedcount+1, but this operation may fail > if the failedcount was set to 0 previously due to exceeded > krbpwdfailurecountinterval. This also makes the succeeding last failed auth > timestamp update to fail too and cause this vulnerability. > > I was able to fix it with this change: > > @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) > */ > if (failed_bind) { > if (failedcount < max_fail) { > - PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", > failedcount); > - slapi_mods_add_string(smods, LDAP_MOD_DELETE, > "krbLoginFailedCount", failedcountstr); > failedcount += 1; > PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", > failedcount); > - slapi_mods_add_string(smods, LDAP_MOD_ADD, > "krbLoginFailedCount", failedcountstr); > + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, > "krbLoginFailedCount", failedcountstr); > } > if (lastfail) { > if (!gmtime_r(&(time_now), &utctime)) { > > Martin > I cam to a similar conclusion. We want to be careful when deleting values so we can handle the case where multiple bind attempts are happening at once so we try to avoid using REPLACE. I changed it so we save the value of failedcount when the lockout expires. I also added a chance to handle the case where there is no failedcount at all. I was trying to delete a non-existent 0 value. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-4-lockout.patch Type: text/x-patch Size: 12284 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 20 09:47:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Mar 2013 10:47:07 +0100 Subject: [Freeipa-devel] [PATCH] 390 ipa-client discovery with anonymous access off In-Reply-To: <51482DF2.3050605@redhat.com> References: <51481DBB.7010401@redhat.com> <51482DF2.3050605@redhat.com> Message-ID: <5149859B.7030302@redhat.com> On 03/19/2013 10:20 AM, Petr Viktorin wrote: > On 03/19/2013 09:11 AM, Martin Kosek wrote: >> When RootDSE could be read (nsslapd-allow-anonymous-access set to >> "rootdse"), autodiscovery module failed to report success to the >> client installer. >> >> Remove faulty "verified_servers" flag from autodiscovery module as >> it has no point since we consider both scenarios (IPA server with >> anonymous access on and unknown LDAP server with anonymous access >> off) as success. >> >> https://fedorahosted.org/freeipa/ticket/3519 >> > > ACK, this fixes the problem > Pushed to master, ipa-3-1. Martin From pspacek at redhat.com Wed Mar 20 12:10:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 Mar 2013 13:10:58 +0100 Subject: [Freeipa-devel] [PATCH 0119] Prevent crash caused by race condition during plugin initialization Message-ID: <5149A752.3000406@redhat.com> Hello, Prevent crash caused by race condition during plugin initialization. Processing of global configuration was postponed. Now the persistent search watcher thread doesn't change configuration directly. The problem was that isc_task_beginexclusive() was called before task associated with psearch watcher thread was fully initialized. Now the watcher enqueues a new configuration change event and this event is processed later by another thread. https://fedorahosted.org/bind-dyndb-ldap/ticket/110 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0119-Prevent-crash-caused-by-race-condition-during-plugin.patch Type: text/x-patch Size: 2534 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 20 12:40:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Mar 2013 13:40:41 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <51488DBE.4000802@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> Message-ID: <5149AE49.7010209@redhat.com> On 03/19/2013 05:09 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/19/2013 10:57 AM, Martin Kosek wrote: >>> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>>>> See patch >>>>>>>>> for details. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> >>>>>>>> I see some issues with this fix: >>>>>>>> >>>>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>>>> policy? I.e. if I have this policy: >>>>>>>> >>>>>>>> # ipa pwpolicy-show test >>>>>>>> Group: test >>>>>>>> Priority: 10 >>>>>>>> Max failures: 2 >>>>>>>> >>>>>>>> We should still follow settings other than "Max failures" configured in >>>>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>>>> should be consistent in this case. Now, other values just seem to be >>>>>>>> zero. >>>>>>> >>>>>>> There should be only one policy. It isn't supposed to merge policies >>>>>>> together (there is only one krbPwdPolicyReference per principal). >>>>> >>>>> That's a good point. >>>>> >>>>>>> >>>>>>> How is the KDC acting differently? >>>>> >>>>> For example, if you set only maximal number of bad password guesses, it does >>>>> not allow any more (user fbar1 is a member of test group): >>>>> >>>>> # ipa pwpolicy-mod test --maxfail 3 >>>>> Group: test >>>>> Priority: 10 >>>>> Max failures: 3 >>>>> >>>>> # kinit fbar1 >>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>> kinit: Password incorrect while getting initial credentials >>>>> # kinit fbar1 >>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>> kinit: Password incorrect while getting initial credentials >>>>> # kinit fbar1 >>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>> kinit: Password incorrect while getting initial credentials >>>>> # kinit fbar1 >>>>> kinit: Clients credentials have been revoked while getting initial >>>>> credentials >>>>> >>>>> But LDAP binds are still allowed >>>>> >>>>> # ldapsearch -h localhost -D >>>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w >>>>> foo >>>>> -s base -b "" >>>>> ldap_bind: Invalid credentials (49) >>>>> >>>>> I think this is just caused by different processing of >>>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >>>>> max auth tries checks are pretty much disabled). >>>> >>>> We can't examine things until a successful bind is done. If it is done and we >>>> determine that they should be locked out we refuse to continue. >>> >>> I am not sure I follow - what do you mean by "examine things"? The bind preop >>> plugin can check current policy with unsuccessful login, right? I just thought >>> that when the custom policy has krbpwdmaxfailure set, but does not have >>> krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure >>> "somehow", as ipa-kdb does. >>> >>> If not, I think we should either mark those params in pwpolicy plugin as >>> required or at least add a note to ipa help mentioning this limitation for LDAP >>> binds.... >>> >>>> >>>>> >>>>>>> >>>>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>>>> working really consistently. >>>>>>>> >>>>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>>>> failures". >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>>> >>>>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>>>> I am able to run as many LDAP binds as I want. >>>>>>> >>>>>>> Can you clarify? Successful or unsuccessful binds? >>>>> >>>>> Unsuccessful binds. I will try to reproduce it again when you fix the >>>>> crash, it >>>>> is hard to investigate it with this crash around. >>>>> >>>>>>> >>>>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>>>> him post hist findings too. >>>>>>>> >>>>>>>> Martin >>>>>> >>>>>> Here is an updated patch to not increment past the max failures on LDAP >>>>>> binds. >>>>> >>>>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>>>> user with no group policy assigned (Stacktrace attached). >>>> >>>> Stupid mistake on my part. >>>> >>>> rob >>>> >>> >>> Fixed now :) I found one more issue. When you add a new user with a password, >>> wrong LDAP binds do not increase failure count until the latest failure >>> timestamp is set, for example via failed Kerberos login: >>> >>> # ipa user-status fbar2 >>> ----------------------- >>> Account disabled: False >>> ----------------------- >>> Server: vm-037.idm.lab.bos.redhat.com >>> Failed logins: 0 >>> Last successful authentication: N/A >>> Last failed authentication: N/A >>> Time now: 2013-03-19T09:01:35Z >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> # ldapsearch -h localhost -D >>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>> -s base -b "" >>> ldap_bind: Invalid credentials (49) >>> >>> # ipa user-status fbar2 >>> ----------------------- >>> Account disabled: False >>> ----------------------- >>> Server: vm-037.idm.lab.bos.redhat.com >>> Failed logins: 0 >>> Last successful authentication: N/A >>> Last failed authentication: N/A >>> Time now: 2013-03-19T09:01:54Z >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> # kinit fbar2 >>> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >>> kinit: Password incorrect while getting initial credentials >>> >>> # ipa user-status fbar2 >>> ----------------------- >>> Account disabled: False >>> ----------------------- >>> Server: vm-037.idm.lab.bos.redhat.com >>> Failed logins: 1 >>> Last successful authentication: N/A >>> Last failed authentication: 2013-03-19T09:02:14Z >>> Time now: 2013-03-19T09:02:16Z >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> # ldapsearch -h localhost -D >>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>> -s base -b "" >>> ldap_bind: Invalid credentials (49) >>> >>> # ipa user-status fbar2 >>> ----------------------- >>> Account disabled: False >>> ----------------------- >>> Server: vm-037.idm.lab.bos.redhat.com >>> Failed logins: 2 <<<<<< It increased now >>> Last successful authentication: N/A >>> Last failed authentication: 2013-03-19T09:02:20Z >>> Time now: 2013-03-19T09:02:24Z >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> >>> As for the issue you could not reproduce, it is also quite difficult to >>> reproduce it for me, I usually have to combine same failed/successful logins, >>> waits for lockouts etc. I need to look at that more closely. Just for the >>> record, attaching an LDIF of a user in such a state when I can do as many >>> failing ldapsearches as I want. This is the password policy: >>> >>> # ipa pwpolicy-show >>> Group: global_policy >>> Max lifetime (days): 90 >>> Min lifetime (hours): 1 >>> History size: 0 >>> Character classes: 0 >>> Min length: 8 >>> Max failures: 6 >>> Failure reset interval: 60 >>> Lockout duration: 30 >>> >>> Martin >>> >> >> I discovered that the issue is in the postop: >> >> + if (failedcount < max_fail) { >> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >> failedcount); >> + slapi_mods_add_string(smods, LDAP_MOD_DELETE, >> "krbLoginFailedCount", failedcountstr); >> + failedcount += 1; >> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >> failedcount); >> + slapi_mods_add_string(smods, LDAP_MOD_ADD, >> "krbLoginFailedCount", failedcountstr); >> } >> >> We try to delete failedcount and add failedcount+1, but this operation may fail >> if the failedcount was set to 0 previously due to exceeded >> krbpwdfailurecountinterval. This also makes the succeeding last failed auth >> timestamp update to fail too and cause this vulnerability. >> >> I was able to fix it with this change: >> >> @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) >> */ >> if (failed_bind) { >> if (failedcount < max_fail) { >> - PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >> failedcount); >> - slapi_mods_add_string(smods, LDAP_MOD_DELETE, >> "krbLoginFailedCount", failedcountstr); >> failedcount += 1; >> PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >> failedcount); >> - slapi_mods_add_string(smods, LDAP_MOD_ADD, >> "krbLoginFailedCount", failedcountstr); >> + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, >> "krbLoginFailedCount", failedcountstr); >> } >> if (lastfail) { >> if (!gmtime_r(&(time_now), &utctime)) { >> >> Martin >> > > I cam to a similar conclusion. We want to be careful when deleting values so we > can handle the case where multiple bind attempts are happening at once so we > try to avoid using REPLACE. I changed it so we save the value of failedcount > when the lockout expires. > > I also added a chance to handle the case where there is no failedcount at all. > I was trying to delete a non-existent 0 value. > > rob Ok, the updated version works well. I think we are getting close to finish this. I now also tried krbPwdLockoutDuration=0 and it does not/cannot work properly as we are still reseting failedcount to zero even though the account is locked out. Shouldn't we do it only if the account is not in lockout period? I.e. like this: ... if (failedcount >= max_fail) { if (lockout_duration == 0) { errstr = "Entry permanently locked.\n"; ret = LDAP_UNWILLING_TO_PERFORM; goto done; } if (time_now < last_failed + lockout_duration) { /* Too many failures */ LOG_TRACE("Too many failed logins. %lu out of %d\n", failedcount, max_fail); errstr = "Too many failed logins.\n"; ret = LDAP_UNWILLING_TO_PERFORM; } } else if (lastfail != NULL) { /* Do failedcount processing */ } ... Same in postop, we reset failedcount to 0 even though we may be in lockout period. Martin From atkac at redhat.com Wed Mar 20 13:28:42 2013 From: atkac at redhat.com (Adam Tkac) Date: Wed, 20 Mar 2013 14:28:42 +0100 Subject: [Freeipa-devel] [PATCH 0119] Prevent crash caused by race condition during plugin initialization In-Reply-To: <5149A752.3000406@redhat.com> References: <5149A752.3000406@redhat.com> Message-ID: <20130320132842.GA6103@redhat.com> On Wed, Mar 20, 2013 at 01:10:58PM +0100, Petr Spacek wrote: > Hello, > > Prevent crash caused by race condition during plugin initialization. > > Processing of global configuration was postponed. Now the persistent > search watcher thread doesn't change configuration directly. > > The problem was that isc_task_beginexclusive() > was called before task associated with psearch watcher thread > was fully initialized. > > Now the watcher enqueues a new configuration change event > and this event is processed later by another thread. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/110 Ack > From edd7efd2dbea3f40ec4c2c849a0646d47abf201b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Wed, 20 Mar 2013 12:58:09 +0100 > Subject: [PATCH] Prevent crash caused by race condition during plugin > initialization. > > Processing of global configuration was postponed. Now the persistent > search watcher thread doesn't change configuration directly. > > The problem was that isc_task_beginexclusive() > was called before task associated with psearch watcher thread > was fully initialized. > > Now the watcher enqueues a new configuration change event > and this event is processed later by another thread. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/110 > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 22 +++++++++++++++------- > 1 file changed, 15 insertions(+), 7 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 0c9e87911ef196cf89bb1f2022235b7b19609b14..b4162bbabd294224513e4957e5eee01100dae70c 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1458,18 +1458,26 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > * before processing them. It prevents deadlock in situations where > * ldap_parse_zoneentry() requests another connection. */ > CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, str_buf(ldap_inst->base), > - LDAP_SCOPE_SUBTREE, config_attrs, 0, > - "(objectClass=idnsConfigObject)")); > CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, str_buf(ldap_inst->base), > LDAP_SCOPE_SUBTREE, zone_attrs, 0, > "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + > + /* Do not touch configuration from psearch watcher thread, otherwise > + * BIND will crash. The problem is that isc_task_beginexclusive() > + * is called before task associated with psearch watcher thread > + * is fully initialized. */ > + if (!delete_only) > + CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_config_qresult, > + str_buf(ldap_inst->base), LDAP_SCOPE_SUBTREE, > + config_attrs, 0, "(objectClass=idnsConfigObject)")); > + > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > > - for (entry = HEAD(ldap_config_qresult->ldap_entries); > - entry != NULL; > - entry = NEXT(entry, link)) { > - CHECK(ldap_parse_configentry(entry, ldap_inst)); > + if (!delete_only) { > + for (entry = HEAD(ldap_config_qresult->ldap_entries); > + entry != NULL; > + entry = NEXT(entry, link)) > + CHECK(ldap_parse_configentry(entry, ldap_inst)); > } > > /* > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Wed Mar 20 14:04:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 Mar 2013 15:04:39 +0100 Subject: [Freeipa-devel] [PATCH 0119] Prevent crash caused by race condition during plugin initialization In-Reply-To: <20130320132842.GA6103@redhat.com> References: <5149A752.3000406@redhat.com> <20130320132842.GA6103@redhat.com> Message-ID: <5149C1F7.4080202@redhat.com> On 20.3.2013 14:28, Adam Tkac wrote: > On Wed, Mar 20, 2013 at 01:10:58PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Prevent crash caused by race condition during plugin initialization. >> > >> > Processing of global configuration was postponed. Now the persistent >> > search watcher thread doesn't change configuration directly. >> > >> > The problem was that isc_task_beginexclusive() >> > was called before task associated with psearch watcher thread >> > was fully initialized. >> > >> > Now the watcher enqueues a new configuration change event >> > and this event is processed later by another thread. >> > >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/110 > Ack > Pushed to v2: 554e57558bf00c6764686917acd4892217d78960 Rebased version pushed to master: 1ccf6097682abf0d135e53dc9a809a125aa55d14 -- Petr^2 Spacek From rcritten at redhat.com Wed Mar 20 15:52:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Mar 2013 11:52:10 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <5149AE49.7010209@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> <5149AE49.7010209@redhat.com> Message-ID: <5149DB2A.6020505@redhat.com> Martin Kosek wrote: > On 03/19/2013 05:09 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/19/2013 10:57 AM, Martin Kosek wrote: >>>> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>>>>> See patch >>>>>>>>>> for details. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> >>>>>>>>> I see some issues with this fix: >>>>>>>>> >>>>>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>>>>> policy? I.e. if I have this policy: >>>>>>>>> >>>>>>>>> # ipa pwpolicy-show test >>>>>>>>> Group: test >>>>>>>>> Priority: 10 >>>>>>>>> Max failures: 2 >>>>>>>>> >>>>>>>>> We should still follow settings other than "Max failures" configured in >>>>>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>>>>> should be consistent in this case. Now, other values just seem to be >>>>>>>>> zero. >>>>>>>> >>>>>>>> There should be only one policy. It isn't supposed to merge policies >>>>>>>> together (there is only one krbPwdPolicyReference per principal). >>>>>> >>>>>> That's a good point. >>>>>> >>>>>>>> >>>>>>>> How is the KDC acting differently? >>>>>> >>>>>> For example, if you set only maximal number of bad password guesses, it does >>>>>> not allow any more (user fbar1 is a member of test group): >>>>>> >>>>>> # ipa pwpolicy-mod test --maxfail 3 >>>>>> Group: test >>>>>> Priority: 10 >>>>>> Max failures: 3 >>>>>> >>>>>> # kinit fbar1 >>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>> kinit: Password incorrect while getting initial credentials >>>>>> # kinit fbar1 >>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>> kinit: Password incorrect while getting initial credentials >>>>>> # kinit fbar1 >>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>> kinit: Password incorrect while getting initial credentials >>>>>> # kinit fbar1 >>>>>> kinit: Clients credentials have been revoked while getting initial >>>>>> credentials >>>>>> >>>>>> But LDAP binds are still allowed >>>>>> >>>>>> # ldapsearch -h localhost -D >>>>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w >>>>>> foo >>>>>> -s base -b "" >>>>>> ldap_bind: Invalid credentials (49) >>>>>> >>>>>> I think this is just caused by different processing of >>>>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set, >>>>>> max auth tries checks are pretty much disabled). >>>>> >>>>> We can't examine things until a successful bind is done. If it is done and we >>>>> determine that they should be locked out we refuse to continue. >>>> >>>> I am not sure I follow - what do you mean by "examine things"? The bind preop >>>> plugin can check current policy with unsuccessful login, right? I just thought >>>> that when the custom policy has krbpwdmaxfailure set, but does not have >>>> krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure >>>> "somehow", as ipa-kdb does. >>>> >>>> If not, I think we should either mark those params in pwpolicy plugin as >>>> required or at least add a note to ipa help mentioning this limitation for LDAP >>>> binds.... >>>> >>>>> >>>>>> >>>>>>>> >>>>>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>>>>> working really consistently. >>>>>>>>> >>>>>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>>>>> failures". >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>>> >>>>>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>>>>> I am able to run as many LDAP binds as I want. >>>>>>>> >>>>>>>> Can you clarify? Successful or unsuccessful binds? >>>>>> >>>>>> Unsuccessful binds. I will try to reproduce it again when you fix the >>>>>> crash, it >>>>>> is hard to investigate it with this crash around. >>>>>> >>>>>>>> >>>>>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>>>>> him post hist findings too. >>>>>>>>> >>>>>>>>> Martin >>>>>>> >>>>>>> Here is an updated patch to not increment past the max failures on LDAP >>>>>>> binds. >>>>>> >>>>>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>>>>> user with no group policy assigned (Stacktrace attached). >>>>> >>>>> Stupid mistake on my part. >>>>> >>>>> rob >>>>> >>>> >>>> Fixed now :) I found one more issue. When you add a new user with a password, >>>> wrong LDAP binds do not increase failure count until the latest failure >>>> timestamp is set, for example via failed Kerberos login: >>>> >>>> # ipa user-status fbar2 >>>> ----------------------- >>>> Account disabled: False >>>> ----------------------- >>>> Server: vm-037.idm.lab.bos.redhat.com >>>> Failed logins: 0 >>>> Last successful authentication: N/A >>>> Last failed authentication: N/A >>>> Time now: 2013-03-19T09:01:35Z >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> # ldapsearch -h localhost -D >>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>>> -s base -b "" >>>> ldap_bind: Invalid credentials (49) >>>> >>>> # ipa user-status fbar2 >>>> ----------------------- >>>> Account disabled: False >>>> ----------------------- >>>> Server: vm-037.idm.lab.bos.redhat.com >>>> Failed logins: 0 >>>> Last successful authentication: N/A >>>> Last failed authentication: N/A >>>> Time now: 2013-03-19T09:01:54Z >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> # kinit fbar2 >>>> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >>>> kinit: Password incorrect while getting initial credentials >>>> >>>> # ipa user-status fbar2 >>>> ----------------------- >>>> Account disabled: False >>>> ----------------------- >>>> Server: vm-037.idm.lab.bos.redhat.com >>>> Failed logins: 1 >>>> Last successful authentication: N/A >>>> Last failed authentication: 2013-03-19T09:02:14Z >>>> Time now: 2013-03-19T09:02:16Z >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> # ldapsearch -h localhost -D >>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo >>>> -s base -b "" >>>> ldap_bind: Invalid credentials (49) >>>> >>>> # ipa user-status fbar2 >>>> ----------------------- >>>> Account disabled: False >>>> ----------------------- >>>> Server: vm-037.idm.lab.bos.redhat.com >>>> Failed logins: 2 <<<<<< It increased now >>>> Last successful authentication: N/A >>>> Last failed authentication: 2013-03-19T09:02:20Z >>>> Time now: 2013-03-19T09:02:24Z >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> >>>> As for the issue you could not reproduce, it is also quite difficult to >>>> reproduce it for me, I usually have to combine same failed/successful logins, >>>> waits for lockouts etc. I need to look at that more closely. Just for the >>>> record, attaching an LDIF of a user in such a state when I can do as many >>>> failing ldapsearches as I want. This is the password policy: >>>> >>>> # ipa pwpolicy-show >>>> Group: global_policy >>>> Max lifetime (days): 90 >>>> Min lifetime (hours): 1 >>>> History size: 0 >>>> Character classes: 0 >>>> Min length: 8 >>>> Max failures: 6 >>>> Failure reset interval: 60 >>>> Lockout duration: 30 >>>> >>>> Martin >>>> >>> >>> I discovered that the issue is in the postop: >>> >>> + if (failedcount < max_fail) { >>> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>> failedcount); >>> + slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>> "krbLoginFailedCount", failedcountstr); >>> + failedcount += 1; >>> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>> failedcount); >>> + slapi_mods_add_string(smods, LDAP_MOD_ADD, >>> "krbLoginFailedCount", failedcountstr); >>> } >>> >>> We try to delete failedcount and add failedcount+1, but this operation may fail >>> if the failedcount was set to 0 previously due to exceeded >>> krbpwdfailurecountinterval. This also makes the succeeding last failed auth >>> timestamp update to fail too and cause this vulnerability. >>> >>> I was able to fix it with this change: >>> >>> @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) >>> */ >>> if (failed_bind) { >>> if (failedcount < max_fail) { >>> - PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>> failedcount); >>> - slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>> "krbLoginFailedCount", failedcountstr); >>> failedcount += 1; >>> PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>> failedcount); >>> - slapi_mods_add_string(smods, LDAP_MOD_ADD, >>> "krbLoginFailedCount", failedcountstr); >>> + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, >>> "krbLoginFailedCount", failedcountstr); >>> } >>> if (lastfail) { >>> if (!gmtime_r(&(time_now), &utctime)) { >>> >>> Martin >>> >> >> I cam to a similar conclusion. We want to be careful when deleting values so we >> can handle the case where multiple bind attempts are happening at once so we >> try to avoid using REPLACE. I changed it so we save the value of failedcount >> when the lockout expires. >> >> I also added a chance to handle the case where there is no failedcount at all. >> I was trying to delete a non-existent 0 value. >> >> rob > > Ok, the updated version works well. I think we are getting close to finish this. > > I now also tried krbPwdLockoutDuration=0 and it does not/cannot work properly > as we are still reseting failedcount to zero even though the account is locked out. > > Shouldn't we do it only if the account is not in lockout period? Yup. Now skip that calculation if lockout_duration == 0. I also tested that things work if user has a strong policy and is locked out due to duration = 0, delete that policy and then user can try to authenticate again b/c default policy has a lockout timeout. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-5-lockout.patch Type: text/x-patch Size: 13438 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 20 16:11:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Mar 2013 17:11:10 +0100 Subject: [Freeipa-devel] [RFE] Drop --selfsign Message-ID: <5149DF9E.7080209@redhat.com> Here is a RFE for https://fedorahosted.org/freeipa/ticket/3494. It's for dropping the --selfsign option from ipa-server-install. The functionality itself stays in for now (on upgraded self-signed masters). http://freeipa.org/page/V3/Drop_selfsign -- Petr? __NOTOC__ = Overview = Ticket [https://fedorahosted.org/freeipa/ticket/3352 3352] Drop --selfsign server functionality: In a future, we would like to support 2 flavors of certificate management in IPA: * IPA with pki-ca (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option) * IPA with no pki-ca installed with certificates signed and provided by an external CA. Installation with --selfsign (selfsigned certificate managed in local NSS database on server) is rather troublesome and not even supported - it should be dropped. = Use Cases = # User tries passing the --selfsign option to ipa-server-install. # The install fails as there is no such option. # User upgrades a server that uses the self-signed CA # The CA continues to work normally = Design= The --selfsign option to ipa-server-install will be removed. Existing self-signed CAs should continue working for now, but the functionality is untested, and may be removed entirely in the near future. = Implementation = No additional requirements or changes discovered during the implementation phase. = Feature Managment = N/A = Major configuration options and enablement = N/A = Replication = No impact, self-signed CAs are incapable of replication = Updates and Upgrades = Self-signed CAs should continue to work after upgrading to the new version. As before, they are neither tested nor supported. = Dependencies = N/A = External Impact = QE will need to drop tests for the self-signed CA, if they have any. Documentation may need updating. From pviktori at redhat.com Wed Mar 20 16:19:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Mar 2013 17:19:54 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <51478621.9090503@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> Message-ID: <5149E1AA.3020701@redhat.com> On 03/18/2013 10:24 PM, Rob Crittenden wrote: > Petr Viktorin wrote: [...] >> From what I've learned, PKCS#12 files are just a bag of certificates; >> there are basically no restrictions on their contents. But we assume >> there's only one cert inside that has a private key, and use that for >> the server cert. We also pretty much assume that there's one CA cert: if >> not we pick the first one and trust it as root CA. >> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >> don't control; we should have the user name the certs more explicitly. >> Am I wrong here? Is this the usual way to import server certs? > > We can impose a requirement that the CA be included in the PKCS#12 > files. At least with NSS this happens automatically, I can't recall with > openssl. > > Or we can add a new option to pass in the CA bundle in PEM format. After thinking about it, this is the way I want to go. It's a bit more typing for the user, but it reduces the amount of guesswork the installer needs to do. When deciding who to trust I'd rather be explicit. There's also a bit less validation to do and corner cases to watch out for. The root CA certificate will be given by --external-ca-file. The trust chains for both servers (dirsrv, http) must lead to that CA. This CA will be trusted, and put in /etc/ipa/ca.crt. Each PKCS#12 file must contain exactly one cert with a private key. This cert will be used for the corresponding server. Of course you can use the same cert for both servers. The --external_ca_file must contain exactly one cert. Certs for any intermediate CAs must be in the PKCS#12. Does that look good? Does it need a design page? I have some patches for this and for replication, but it'll take another day to polish and test them. [...] > I'm not sure the dogtag 9 removal code really fits in the context of > these changes. It makes sense, but has nothing to do with this. I'll retire that patch for now. -- Petr? From rcritten at redhat.com Wed Mar 20 17:28:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Mar 2013 13:28:42 -0400 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <5149E1AA.3020701@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> Message-ID: <5149F1CA.6080904@redhat.com> Petr Viktorin wrote: > On 03/18/2013 10:24 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: > [...] >>> From what I've learned, PKCS#12 files are just a bag of certificates; >>> there are basically no restrictions on their contents. But we assume >>> there's only one cert inside that has a private key, and use that for >>> the server cert. We also pretty much assume that there's one CA cert: if >>> not we pick the first one and trust it as root CA. >>> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >>> don't control; we should have the user name the certs more explicitly. >>> Am I wrong here? Is this the usual way to import server certs? >> >> We can impose a requirement that the CA be included in the PKCS#12 >> files. At least with NSS this happens automatically, I can't recall with >> openssl. >> >> Or we can add a new option to pass in the CA bundle in PEM format. > > After thinking about it, this is the way I want to go. It's a bit more > typing for the user, but it reduces the amount of guesswork the > installer needs to do. When deciding who to trust I'd rather be explicit. > There's also a bit less validation to do and corner cases to watch out for. Yeah, I think this will simplify things a lot. The only downside is the requirement that both certs come from the same CA, but we have to draw the line somewhere. We can always look into extending things later on as needed. > > The root CA certificate will be given by --external-ca-file. The trust > chains for both servers (dirsrv, http) must lead to that CA. This CA > will be trusted, and put in /etc/ipa/ca.crt. Just thinking out loud here, but will that cause any confusion, using an existing option? I don't think so but I may be too used to this. > > Each PKCS#12 file must contain exactly one cert with a private key. This > cert will be used for the corresponding server. > Of course you can use the same cert for both servers. I'm ok with that assuming we have an effective way of enforcing it. We'll need to provide some good documentation on how to create, or re-create, a PKCS#12 file to fit this format. > > The --external_ca_file must contain exactly one cert. Certs for any > intermediate CAs must be in the PKCS#12. It would be a lot easier to include all the CAs in a single PEM. This is not unprecedented, and just catting a bunch of certs together into a single file is easy and should not be error-prone. I think too we'll need to be able to handle the case of any Built-in certs. There is a chance we will need to simply drop on the floor any CA certs provided because some or all of them are already in NSS (all we really care about for this, I think). > Does that look good? Does it need a design page? I think a design page would be particularly helpful in this case. I think this is going to be rather complex, and whatever choices we make to simplify things are going to be important. > > I have some patches for this and for replication, but it'll take another > day to polish and test them. Sounds great. > > [...] >> I'm not sure the dogtag 9 removal code really fits in the context of >> these changes. It makes sense, but has nothing to do with this. > > I'll retire that patch for now. It would probably be a good idea to open a ticket and attach your current work. thanks rob From dpal at redhat.com Wed Mar 20 17:34:49 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Mar 2013 13:34:49 -0400 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <5149F1CA.6080904@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> Message-ID: <5149F339.5070802@redhat.com> On 03/20/2013 01:28 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/18/2013 10:24 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >> [...] >>>> From what I've learned, PKCS#12 files are just a bag of certificates; >>>> there are basically no restrictions on their contents. But we assume >>>> there's only one cert inside that has a private key, and use that for >>>> the server cert. We also pretty much assume that there's one CA >>>> cert: if >>>> not we pick the first one and trust it as root CA. >>>> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >>>> don't control; we should have the user name the certs more explicitly. >>>> Am I wrong here? Is this the usual way to import server certs? >>> >>> We can impose a requirement that the CA be included in the PKCS#12 >>> files. At least with NSS this happens automatically, I can't recall >>> with >>> openssl. >>> >>> Or we can add a new option to pass in the CA bundle in PEM format. >> >> After thinking about it, this is the way I want to go. It's a bit more >> typing for the user, but it reduces the amount of guesswork the >> installer needs to do. When deciding who to trust I'd rather be >> explicit. >> There's also a bit less validation to do and corner cases to watch >> out for. > > Yeah, I think this will simplify things a lot. The only downside is > the requirement that both certs come from the same CA, but we have to > draw the line somewhere. We can always look into extending things > later on as needed. > >> >> The root CA certificate will be given by --external-ca-file. The trust >> chains for both servers (dirsrv, http) must lead to that CA. This CA >> will be trusted, and put in /etc/ipa/ca.crt. > > Just thinking out loud here, but will that cause any confusion, using > an existing option? I don't think so but I may be too used to this. > >> >> Each PKCS#12 file must contain exactly one cert with a private key. This >> cert will be used for the corresponding server. >> Of course you can use the same cert for both servers. > > I'm ok with that assuming we have an effective way of enforcing it. > We'll need to provide some good documentation on how to create, or > re-create, a PKCS#12 file to fit this format. > >> >> The --external_ca_file must contain exactly one cert. Certs for any >> intermediate CAs must be in the PKCS#12. > > It would be a lot easier to include all the CAs in a single PEM. This > is not unprecedented, and just catting a bunch of certs together into > a single file is easy and should not be error-prone. > > I think too we'll need to be able to handle the case of any Built-in > certs. There is a chance we will need to simply drop on the floor any > CA certs provided because some or all of them are already in NSS (all > we really care about for this, I think). > >> Does that look good? Does it need a design page? > > I think a design page would be particularly helpful in this case. I > think this is going to be rather complex, and whatever choices we make > to simplify things are going to be important. Yes the design is needed with the content of this thread plus some examples of the command line plus some hints & guidance on how to prepare files to be in the right format. This includes: How to check what format the files are? How many are there in the file? How to extact certs or or combine certs into files? How to save in the format we want/need? Explain why we require all this "more typing". We want to be explicit but we also want people to understand why we want them to be explicit. This is a very complex area and if we can explain why we ware requiring what we are requiring it would go a long way to helping people understand what they are doing and what would the implication be. > >> >> I have some patches for this and for replication, but it'll take another >> day to polish and test them. > > Sounds great. > >> >> [...] >>> I'm not sure the dogtag 9 removal code really fits in the context of >>> these changes. It makes sense, but has nothing to do with this. >> >> I'll retire that patch for now. > > It would probably be a good idea to open a ticket and attach your > current work. > > thanks > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Mar 20 18:41:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Mar 2013 19:41:35 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <5149DB2A.6020505@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> <5149AE49.7010209@redhat.com> <5149DB2A.6020505@redhat.com> Message-ID: <514A02DF.80001@redhat.com> On 03/20/2013 04:52 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/19/2013 05:09 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 03/19/2013 10:57 AM, Martin Kosek wrote: >>>>> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>>>>> Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>>>>> Fixed a number of issues applying password policy against LDAP binds. >>>>>>>>>>> See patch >>>>>>>>>>> for details. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see some issues with this fix: >>>>>>>>>> >>>>>>>>>> 1) Shouldn't group password policy serve only as an override to the main >>>>>>>>>> policy? I.e. if I have this policy: >>>>>>>>>> >>>>>>>>>> # ipa pwpolicy-show test >>>>>>>>>> Group: test >>>>>>>>>> Priority: 10 >>>>>>>>>> Max failures: 2 >>>>>>>>>> >>>>>>>>>> We should still follow settings other than "Max failures" configured in >>>>>>>>>> global policy, right? At least the Kerberos seem to do it. I think we >>>>>>>>>> should be consistent in this case. Now, other values just seem to be >>>>>>>>>> zero. >>>>>>>>> >>>>>>>>> There should be only one policy. It isn't supposed to merge policies >>>>>>>>> together (there is only one krbPwdPolicyReference per principal). >>>>>>> >>>>>>> That's a good point. >>>>>>> >>>>>>>>> >>>>>>>>> How is the KDC acting differently? >>>>>>> >>>>>>> For example, if you set only maximal number of bad password guesses, it >>>>>>> does >>>>>>> not allow any more (user fbar1 is a member of test group): >>>>>>> >>>>>>> # ipa pwpolicy-mod test --maxfail 3 >>>>>>> Group: test >>>>>>> Priority: 10 >>>>>>> Max failures: 3 >>>>>>> >>>>>>> # kinit fbar1 >>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>> # kinit fbar1 >>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>> # kinit fbar1 >>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>> # kinit fbar1 >>>>>>> kinit: Clients credentials have been revoked while getting initial >>>>>>> credentials >>>>>>> >>>>>>> But LDAP binds are still allowed >>>>>>> >>>>>>> # ldapsearch -h localhost -D >>>>>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w >>>>>>> foo >>>>>>> -s base -b "" >>>>>>> ldap_bind: Invalid credentials (49) >>>>>>> >>>>>>> I think this is just caused by different processing of >>>>>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not >>>>>>> set, >>>>>>> max auth tries checks are pretty much disabled). >>>>>> >>>>>> We can't examine things until a successful bind is done. If it is done >>>>>> and we >>>>>> determine that they should be locked out we refuse to continue. >>>>> >>>>> I am not sure I follow - what do you mean by "examine things"? The bind preop >>>>> plugin can check current policy with unsuccessful login, right? I just >>>>> thought >>>>> that when the custom policy has krbpwdmaxfailure set, but does not have >>>>> krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure >>>>> "somehow", as ipa-kdb does. >>>>> >>>>> If not, I think we should either mark those params in pwpolicy plugin as >>>>> required or at least add a note to ipa help mentioning this limitation for >>>>> LDAP >>>>> binds.... >>>>> >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> I think we will need to fix both the pre-op and the post-op to make this >>>>>>>>>> working really consistently. >>>>>>>>>> >>>>>>>>>> 2) The lockout post-op still counts failed logins even though we are in >>>>>>>>>> lockout time, is this expected? It is another point if inconsistency >>>>>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max >>>>>>>>>> failures". >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) Sometimes, I get into a state when I lockout a new user with Kerberos >>>>>>>>>> and then wait some time until the lockout time passes (no admin unlock), >>>>>>>>>> I am able to run as many LDAP binds as I want. >>>>>>>>> >>>>>>>>> Can you clarify? Successful or unsuccessful binds? >>>>>>> >>>>>>> Unsuccessful binds. I will try to reproduce it again when you fix the >>>>>>> crash, it >>>>>>> is hard to investigate it with this crash around. >>>>>>> >>>>>>>>> >>>>>>>>>> This is all I found so far. Honza is also reviewing it, so I will let >>>>>>>>>> him post hist findings too. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>> >>>>>>>> Here is an updated patch to not increment past the max failures on LDAP >>>>>>>> binds. >>>>>>> >>>>>>> The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a >>>>>>> user with no group policy assigned (Stacktrace attached). >>>>>> >>>>>> Stupid mistake on my part. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Fixed now :) I found one more issue. When you add a new user with a password, >>>>> wrong LDAP binds do not increase failure count until the latest failure >>>>> timestamp is set, for example via failed Kerberos login: >>>>> >>>>> # ipa user-status fbar2 >>>>> ----------------------- >>>>> Account disabled: False >>>>> ----------------------- >>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>> Failed logins: 0 >>>>> Last successful authentication: N/A >>>>> Last failed authentication: N/A >>>>> Time now: 2013-03-19T09:01:35Z >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> # ldapsearch -h localhost -D >>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w >>>>> foo >>>>> -s base -b "" >>>>> ldap_bind: Invalid credentials (49) >>>>> >>>>> # ipa user-status fbar2 >>>>> ----------------------- >>>>> Account disabled: False >>>>> ----------------------- >>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>> Failed logins: 0 >>>>> Last successful authentication: N/A >>>>> Last failed authentication: N/A >>>>> Time now: 2013-03-19T09:01:54Z >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> # kinit fbar2 >>>>> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >>>>> kinit: Password incorrect while getting initial credentials >>>>> >>>>> # ipa user-status fbar2 >>>>> ----------------------- >>>>> Account disabled: False >>>>> ----------------------- >>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>> Failed logins: 1 >>>>> Last successful authentication: N/A >>>>> Last failed authentication: 2013-03-19T09:02:14Z >>>>> Time now: 2013-03-19T09:02:16Z >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> # ldapsearch -h localhost -D >>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w >>>>> foo >>>>> -s base -b "" >>>>> ldap_bind: Invalid credentials (49) >>>>> >>>>> # ipa user-status fbar2 >>>>> ----------------------- >>>>> Account disabled: False >>>>> ----------------------- >>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>> Failed logins: 2 <<<<<< It increased now >>>>> Last successful authentication: N/A >>>>> Last failed authentication: 2013-03-19T09:02:20Z >>>>> Time now: 2013-03-19T09:02:24Z >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> >>>>> As for the issue you could not reproduce, it is also quite difficult to >>>>> reproduce it for me, I usually have to combine same failed/successful logins, >>>>> waits for lockouts etc. I need to look at that more closely. Just for the >>>>> record, attaching an LDIF of a user in such a state when I can do as many >>>>> failing ldapsearches as I want. This is the password policy: >>>>> >>>>> # ipa pwpolicy-show >>>>> Group: global_policy >>>>> Max lifetime (days): 90 >>>>> Min lifetime (hours): 1 >>>>> History size: 0 >>>>> Character classes: 0 >>>>> Min length: 8 >>>>> Max failures: 6 >>>>> Failure reset interval: 60 >>>>> Lockout duration: 30 >>>>> >>>>> Martin >>>>> >>>> >>>> I discovered that the issue is in the postop: >>>> >>>> + if (failedcount < max_fail) { >>>> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>>> failedcount); >>>> + slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>> "krbLoginFailedCount", failedcountstr); >>>> + failedcount += 1; >>>> + PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>>> failedcount); >>>> + slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>> "krbLoginFailedCount", failedcountstr); >>>> } >>>> >>>> We try to delete failedcount and add failedcount+1, but this operation may >>>> fail >>>> if the failedcount was set to 0 previously due to exceeded >>>> krbpwdfailurecountinterval. This also makes the succeeding last failed auth >>>> timestamp update to fail too and cause this vulnerability. >>>> >>>> I was able to fix it with this change: >>>> >>>> @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) >>>> */ >>>> if (failed_bind) { >>>> if (failedcount < max_fail) { >>>> - PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>>> failedcount); >>>> - slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>> "krbLoginFailedCount", failedcountstr); >>>> failedcount += 1; >>>> PR_snprintf(failedcountstr, sizeof(failedcountstr), "%lu", >>>> failedcount); >>>> - slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>> "krbLoginFailedCount", failedcountstr); >>>> + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, >>>> "krbLoginFailedCount", failedcountstr); >>>> } >>>> if (lastfail) { >>>> if (!gmtime_r(&(time_now), &utctime)) { >>>> >>>> Martin >>>> >>> >>> I cam to a similar conclusion. We want to be careful when deleting values so we >>> can handle the case where multiple bind attempts are happening at once so we >>> try to avoid using REPLACE. I changed it so we save the value of failedcount >>> when the lockout expires. >>> >>> I also added a chance to handle the case where there is no failedcount at all. >>> I was trying to delete a non-existent 0 value. >>> >>> rob >> >> Ok, the updated version works well. I think we are getting close to finish this. >> >> I now also tried krbPwdLockoutDuration=0 and it does not/cannot work properly >> as we are still reseting failedcount to zero even though the account is >> locked out. >> >> Shouldn't we do it only if the account is not in lockout period? > > Yup. Now skip that calculation if lockout_duration == 0. > > I also tested that things work if user has a strong policy and is locked out > due to duration = 0, delete that policy and then user can try to authenticate > again b/c default policy has a lockout timeout. > > rob > This is not what I meant, sorry for not being clear previously. This patch still lets user to override lockout and try to login if "Failure reset interval" already passed even though account is still in lockout phase. Consider this policy: # ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 3 Failure reset interval: 30 <<<< Lockout duration: 300 <<<< After 3 tries by Kerberos/LDAP auth, account is locked out. However, after 30 seconds, LDAP binds are allowed again due to "Failure reset interval". Kerberos auth is not allowed until 300 seconds pass (as I would expect). This is what I think that needs to be done when user is in lockout phase: - do not care about "Failure reset interval" in preop/postop - do not update failed login count/last failed login timestamp in postop. We currently update last failed login timestamp, but Kerberos does not do it. Otherwise, this would practically make the lockout phase longer as we count it based on the last failed timestamp. Martin From rcritten at redhat.com Wed Mar 20 22:20:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Mar 2013 18:20:43 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <514A02DF.80001@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> <5149AE49.7010209@redhat.com> <5149DB2A.6020505@redhat.com> <514A02DF.80001@redhat.com> Message-ID: <514A363B.8050600@redhat.com> Martin Kosek wrote: > On 03/20/2013 04:52 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 03/19/2013 05:09 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 03/19/2013 10:57 AM, Martin Kosek wrote: >>>>>> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>>>>>> Rob Crittenden wrote: >>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>>>>>> Fixed a number of issues applying password policy against >>>>>>>>>>>> LDAP binds. >>>>>>>>>>>> See patch >>>>>>>>>>>> for details. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see some issues with this fix: >>>>>>>>>>> >>>>>>>>>>> 1) Shouldn't group password policy serve only as an override >>>>>>>>>>> to the main >>>>>>>>>>> policy? I.e. if I have this policy: >>>>>>>>>>> >>>>>>>>>>> # ipa pwpolicy-show test >>>>>>>>>>> Group: test >>>>>>>>>>> Priority: 10 >>>>>>>>>>> Max failures: 2 >>>>>>>>>>> >>>>>>>>>>> We should still follow settings other than "Max failures" >>>>>>>>>>> configured in >>>>>>>>>>> global policy, right? At least the Kerberos seem to do it. I >>>>>>>>>>> think we >>>>>>>>>>> should be consistent in this case. Now, other values just >>>>>>>>>>> seem to be >>>>>>>>>>> zero. >>>>>>>>>> >>>>>>>>>> There should be only one policy. It isn't supposed to merge >>>>>>>>>> policies >>>>>>>>>> together (there is only one krbPwdPolicyReference per principal). >>>>>>>> >>>>>>>> That's a good point. >>>>>>>> >>>>>>>>>> >>>>>>>>>> How is the KDC acting differently? >>>>>>>> >>>>>>>> For example, if you set only maximal number of bad password >>>>>>>> guesses, it >>>>>>>> does >>>>>>>> not allow any more (user fbar1 is a member of test group): >>>>>>>> >>>>>>>> # ipa pwpolicy-mod test --maxfail 3 >>>>>>>> Group: test >>>>>>>> Priority: 10 >>>>>>>> Max failures: 3 >>>>>>>> >>>>>>>> # kinit fbar1 >>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>> # kinit fbar1 >>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>> # kinit fbar1 >>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>> # kinit fbar1 >>>>>>>> kinit: Clients credentials have been revoked while getting initial >>>>>>>> credentials >>>>>>>> >>>>>>>> But LDAP binds are still allowed >>>>>>>> >>>>>>>> # ldapsearch -h localhost -D >>>>>>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>>> -x -w >>>>>>>> foo >>>>>>>> -s base -b "" >>>>>>>> ldap_bind: Invalid credentials (49) >>>>>>>> >>>>>>>> I think this is just caused by different processing of >>>>>>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it >>>>>>>> is not >>>>>>>> set, >>>>>>>> max auth tries checks are pretty much disabled). >>>>>>> >>>>>>> We can't examine things until a successful bind is done. If it is >>>>>>> done >>>>>>> and we >>>>>>> determine that they should be locked out we refuse to continue. >>>>>> >>>>>> I am not sure I follow - what do you mean by "examine things"? The >>>>>> bind preop >>>>>> plugin can check current policy with unsuccessful login, right? I >>>>>> just >>>>>> thought >>>>>> that when the custom policy has krbpwdmaxfailure set, but does not >>>>>> have >>>>>> krbpwdfailurecountinterval set, we should still enforce the >>>>>> krbpwdmaxfailure >>>>>> "somehow", as ipa-kdb does. >>>>>> >>>>>> If not, I think we should either mark those params in pwpolicy >>>>>> plugin as >>>>>> required or at least add a note to ipa help mentioning this >>>>>> limitation for >>>>>> LDAP >>>>>> binds.... >>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>>> I think we will need to fix both the pre-op and the post-op >>>>>>>>>>> to make this >>>>>>>>>>> working really consistently. >>>>>>>>>>> >>>>>>>>>>> 2) The lockout post-op still counts failed logins even though >>>>>>>>>>> we are in >>>>>>>>>>> lockout time, is this expected? It is another point if >>>>>>>>>>> inconsistency >>>>>>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay >>>>>>>>>>> on "Max >>>>>>>>>>> failures". >>>>>>>>>> >>>>>>>>>> Ok. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) Sometimes, I get into a state when I lockout a new user >>>>>>>>>>> with Kerberos >>>>>>>>>>> and then wait some time until the lockout time passes (no >>>>>>>>>>> admin unlock), >>>>>>>>>>> I am able to run as many LDAP binds as I want. >>>>>>>>>> >>>>>>>>>> Can you clarify? Successful or unsuccessful binds? >>>>>>>> >>>>>>>> Unsuccessful binds. I will try to reproduce it again when you >>>>>>>> fix the >>>>>>>> crash, it >>>>>>>> is hard to investigate it with this crash around. >>>>>>>> >>>>>>>>>> >>>>>>>>>>> This is all I found so far. Honza is also reviewing it, so I >>>>>>>>>>> will let >>>>>>>>>>> him post hist findings too. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>> >>>>>>>>> Here is an updated patch to not increment past the max failures >>>>>>>>> on LDAP >>>>>>>>> binds. >>>>>>>> >>>>>>>> The new patch now causes 389-ds to crash with SIGSEGV if I try >>>>>>>> to bind as a >>>>>>>> user with no group policy assigned (Stacktrace attached). >>>>>>> >>>>>>> Stupid mistake on my part. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Fixed now :) I found one more issue. When you add a new user with >>>>>> a password, >>>>>> wrong LDAP binds do not increase failure count until the latest >>>>>> failure >>>>>> timestamp is set, for example via failed Kerberos login: >>>>>> >>>>>> # ipa user-status fbar2 >>>>>> ----------------------- >>>>>> Account disabled: False >>>>>> ----------------------- >>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>> Failed logins: 0 >>>>>> Last successful authentication: N/A >>>>>> Last failed authentication: N/A >>>>>> Time now: 2013-03-19T09:01:35Z >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> # ldapsearch -h localhost -D >>>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>> -x -w >>>>>> foo >>>>>> -s base -b "" >>>>>> ldap_bind: Invalid credentials (49) >>>>>> >>>>>> # ipa user-status fbar2 >>>>>> ----------------------- >>>>>> Account disabled: False >>>>>> ----------------------- >>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>> Failed logins: 0 >>>>>> Last successful authentication: N/A >>>>>> Last failed authentication: N/A >>>>>> Time now: 2013-03-19T09:01:54Z >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> # kinit fbar2 >>>>>> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >>>>>> kinit: Password incorrect while getting initial credentials >>>>>> >>>>>> # ipa user-status fbar2 >>>>>> ----------------------- >>>>>> Account disabled: False >>>>>> ----------------------- >>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>> Failed logins: 1 >>>>>> Last successful authentication: N/A >>>>>> Last failed authentication: 2013-03-19T09:02:14Z >>>>>> Time now: 2013-03-19T09:02:16Z >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> # ldapsearch -h localhost -D >>>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>> -x -w >>>>>> foo >>>>>> -s base -b "" >>>>>> ldap_bind: Invalid credentials (49) >>>>>> >>>>>> # ipa user-status fbar2 >>>>>> ----------------------- >>>>>> Account disabled: False >>>>>> ----------------------- >>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>> Failed logins: 2 <<<<<< It increased now >>>>>> Last successful authentication: N/A >>>>>> Last failed authentication: 2013-03-19T09:02:20Z >>>>>> Time now: 2013-03-19T09:02:24Z >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> >>>>>> As for the issue you could not reproduce, it is also quite >>>>>> difficult to >>>>>> reproduce it for me, I usually have to combine same >>>>>> failed/successful logins, >>>>>> waits for lockouts etc. I need to look at that more closely. Just >>>>>> for the >>>>>> record, attaching an LDIF of a user in such a state when I can do >>>>>> as many >>>>>> failing ldapsearches as I want. This is the password policy: >>>>>> >>>>>> # ipa pwpolicy-show >>>>>> Group: global_policy >>>>>> Max lifetime (days): 90 >>>>>> Min lifetime (hours): 1 >>>>>> History size: 0 >>>>>> Character classes: 0 >>>>>> Min length: 8 >>>>>> Max failures: 6 >>>>>> Failure reset interval: 60 >>>>>> Lockout duration: 30 >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I discovered that the issue is in the postop: >>>>> >>>>> + if (failedcount < max_fail) { >>>>> + PR_snprintf(failedcountstr, >>>>> sizeof(failedcountstr), "%lu", >>>>> failedcount); >>>>> + slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>>> "krbLoginFailedCount", failedcountstr); >>>>> + failedcount += 1; >>>>> + PR_snprintf(failedcountstr, >>>>> sizeof(failedcountstr), "%lu", >>>>> failedcount); >>>>> + slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>>> "krbLoginFailedCount", failedcountstr); >>>>> } >>>>> >>>>> We try to delete failedcount and add failedcount+1, but this >>>>> operation may >>>>> fail >>>>> if the failedcount was set to 0 previously due to exceeded >>>>> krbpwdfailurecountinterval. This also makes the succeeding last >>>>> failed auth >>>>> timestamp update to fail too and cause this vulnerability. >>>>> >>>>> I was able to fix it with this change: >>>>> >>>>> @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) >>>>> */ >>>>> if (failed_bind) { >>>>> if (failedcount < max_fail) { >>>>> - PR_snprintf(failedcountstr, >>>>> sizeof(failedcountstr), "%lu", >>>>> failedcount); >>>>> - slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>>> "krbLoginFailedCount", failedcountstr); >>>>> failedcount += 1; >>>>> PR_snprintf(failedcountstr, >>>>> sizeof(failedcountstr), "%lu", >>>>> failedcount); >>>>> - slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>>> "krbLoginFailedCount", failedcountstr); >>>>> + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, >>>>> "krbLoginFailedCount", failedcountstr); >>>>> } >>>>> if (lastfail) { >>>>> if (!gmtime_r(&(time_now), &utctime)) { >>>>> >>>>> Martin >>>>> >>>> >>>> I cam to a similar conclusion. We want to be careful when deleting >>>> values so we >>>> can handle the case where multiple bind attempts are happening at >>>> once so we >>>> try to avoid using REPLACE. I changed it so we save the value of >>>> failedcount >>>> when the lockout expires. >>>> >>>> I also added a chance to handle the case where there is no >>>> failedcount at all. >>>> I was trying to delete a non-existent 0 value. >>>> >>>> rob >>> >>> Ok, the updated version works well. I think we are getting close to >>> finish this. >>> >>> I now also tried krbPwdLockoutDuration=0 and it does not/cannot work >>> properly >>> as we are still reseting failedcount to zero even though the account is >>> locked out. >>> >>> Shouldn't we do it only if the account is not in lockout period? >> >> Yup. Now skip that calculation if lockout_duration == 0. >> >> I also tested that things work if user has a strong policy and is >> locked out >> due to duration = 0, delete that policy and then user can try to >> authenticate >> again b/c default policy has a lockout timeout. >> >> rob >> > > This is not what I meant, sorry for not being clear previously. This > patch still lets user to override lockout and try to login if "Failure > reset interval" already passed even though account is still in lockout > phase. > > Consider this policy: > # ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 8 > Max failures: 3 > Failure reset interval: 30 <<<< > Lockout duration: 300 <<<< > > After 3 tries by Kerberos/LDAP auth, account is locked out. However, > after 30 seconds, LDAP binds are allowed again due to "Failure reset > interval". Kerberos auth is not allowed until 300 seconds pass (as I > would expect). > > This is what I think that needs to be done when user is in lockout phase: > - do not care about "Failure reset interval" in preop/postop > - do not update failed login count/last failed login timestamp in > postop. We currently update last failed login timestamp, but Kerberos > does not do it. Otherwise, this would practically make the lockout phase > longer as we count it based on the last failed timestamp. We need to consider the interval because all the failures have to occur within it. I reordered a bit of the evaluation code and added consideration for lockout period so it is properly enforced now both for duration == 0 (permanent lockout) and for a duration. I confirmed that administrative unlock works as well, also both in the case of a duration lockout and a permanent lockout. Hopefully I tested better this go-around. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1092-6-lockout.patch Type: text/x-patch Size: 15514 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 21 08:32:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 09:32:41 +0100 Subject: [Freeipa-devel] [PATCH] 266 Fixed Web UI build error caused by rhino changes in F19 In-Reply-To: <5146D980.4080001@redhat.com> References: <513DDBDC.1040901@redhat.com> <5143AD2F.8020305@redhat.com> <5146D980.4080001@redhat.com> Message-ID: <514AC5A9.8080505@redhat.com> On 03/18/2013 10:08 AM, Martin Kosek wrote: > On 03/16/2013 12:22 AM, Endi Sukma Dewata wrote: >> On 3/11/2013 8:27 AM, Petr Vobornik wrote: >>> rhino-1.7R4-2.fc19.noarch dropped -main flag which made the build fail >>> in rawhide (F19). >>> >>> We can't use the same command for rhino-1.7R3-6 (F18) and rhino-1.7R4-2 >>> (F19). >>> This patch adds check if rhino supports '-require' option. If so it >>> calls rhino with it if not it calls rhino with -main option. >>> >>> https://fedorahosted.org/freeipa/ticket/3501 >> >> Would it be better to check /etc/fedora-release or the actual rhino version? > > Checking /etc/fedora-release would introduce another unnecessary Fedora > platform build dependency, I would not do that. As for the rhino version, I > would also not like calling "rpm -q rhino" to get the package version as we > would then have to parse it properly and it also adds yet another platform > specific dependency. Thus, I think that current Petr approach should be OK for now. > > Martin > >> >> Regardless, this patch is ACKed. I don't have an F19 to test it though. >> Second ACK (I tested on Fedora 19), pushed to master. Martin From mkosek at redhat.com Thu Mar 21 08:59:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 09:59:34 +0100 Subject: [Freeipa-devel] patch for trac 2575 In-Reply-To: <5126239C.2050507@redhat.com> References: <478729079.1780206.1360894041401.JavaMail.root@redhat.com> <5126239C.2050507@redhat.com> Message-ID: <514ACBF6.5060209@redhat.com> On 02/21/2013 02:39 PM, Martin Kosek wrote: > Thanks Brian. I still see few issues though: > > 1) The patch adds a whitespace error: > > $ git apply ~/freeipa-bcook-0001-Add-DNS-Setup-Prompt-to-Install.patch > /home/mkosek/freeipa-bcook-0001-Add-DNS-Setup-Prompt-to-Install.patch:41: > trailing whitespace. > > warning: 1 line adds whitespace errors > > 2) It does unrelated and unnecessary changes to the main function: > > --- a/install/tools/ipa-server-install > +++ b/install/tools/ipa-server-install > @@ -560,10 +560,16 @@ def set_subject_in_config(realm_name, dm_password, > suffix, subject_base): > conn.disconnect() > > def main(): > + """ > + > + > + :return: > + """ > global ds > global pw_name > global uninstalling > global installation_cleanup > + > ds = None > > safe_options, options = parse_options() > > 3) In the question, I would replace "bind" with "BIND" as this is how the > project should be spelled. I see that few lines above we also refer to BIND > with "bind" (it may have caused the confusion), I think this can be fixed too. > > Martin Hello Brian, I did not see any response to my mail below so I went ahead and made these fixes myself as we want this in our next release (updated patch attached). ACK. Pushed to master. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-bcook-0001-2-Add-DNS-Setup-Prompt-to-Install.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 21 09:27:50 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Mar 2013 10:27:50 +0100 Subject: [Freeipa-devel] New RFC: An Information Model for Kerberos Version 5 Message-ID: <514AD296.7030303@redhat.com> Hello list, a new RFC "An Information Model for Kerberos Version 5" was published: http://tools.ietf.org/html/rfc6880 RFC status and other metadata: https://datatracker.ietf.org/doc/rfc6880/ Kerberos experts, is it interesting for FreeIPA? -- Petr^2 Spacek From mkosek at redhat.com Thu Mar 21 10:59:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 11:59:51 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes Message-ID: <514AE827.2080909@redhat.com> This set of patches (details in commit messages) allow build and installation of FreeIPA in Fedora 19. I tested server and replica install (master on f18, replica on f19) and both worked fine. The patches are compatible with Fedora 18 (I tested). If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need to get that from koji: Bug 920713 - named timeouts when started via systemd Also, to fix trusts and ipa-adtrust-install, I had to use my custom build of 389-ds-base as current builds do not accepts Kerberos tickets greater than 2048 bytes. This is the bug I filed: Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-391-remove-conflict-with-krb5-1.11.patch Type: text/x-patch Size: 1907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-392-remove-build-warnings.patch Type: text/x-patch Size: 13797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-393-remove-syslog.target-from-ipa.server.patch Type: text/x-patch Size: 1843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-394-put-pid-file-to-named.conf.patch Type: text/x-patch Size: 3802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-395-update-mod_wsgi-socket-directory.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 21 12:00:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Mar 2013 13:00:46 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <5149F339.5070802@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> Message-ID: <514AF66E.2070901@redhat.com> On 03/20/2013 06:34 PM, Dmitri Pal wrote: > On 03/20/2013 01:28 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/18/2013 10:24 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>> [...] >>>>> From what I've learned, PKCS#12 files are just a bag of certificates; >>>>> there are basically no restrictions on their contents. But we assume >>>>> there's only one cert inside that has a private key, and use that for >>>>> the server cert. We also pretty much assume that there's one CA >>>>> cert: if >>>>> not we pick the first one and trust it as root CA. >>>>> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >>>>> don't control; we should have the user name the certs more explicitly. >>>>> Am I wrong here? Is this the usual way to import server certs? >>>> >>>> We can impose a requirement that the CA be included in the PKCS#12 >>>> files. At least with NSS this happens automatically, I can't recall >>>> with >>>> openssl. >>>> >>>> Or we can add a new option to pass in the CA bundle in PEM format. >>> >>> After thinking about it, this is the way I want to go. It's a bit more >>> typing for the user, but it reduces the amount of guesswork the >>> installer needs to do. When deciding who to trust I'd rather be >>> explicit. >>> There's also a bit less validation to do and corner cases to watch >>> out for. >> >> Yeah, I think this will simplify things a lot. The only downside is >> the requirement that both certs come from the same CA, but we have to >> draw the line somewhere. We can always look into extending things >> later on as needed. Well, if we allow more than one CA in the PEM we can lift this restriction. More below. >>> The root CA certificate will be given by --external-ca-file. The trust >>> chains for both servers (dirsrv, http) must lead to that CA. This CA >>> will be trusted, and put in /etc/ipa/ca.crt. >> >> Just thinking out loud here, but will that cause any confusion, using >> an existing option? I don't think so but I may be too used to this. I don't think it would, but if we allow more than one CA (possibly in the future) there is a bigger chance of confusion after all. I'll use --root-ca-file instead. >>> Each PKCS#12 file must contain exactly one cert with a private key. This >>> cert will be used for the corresponding server. >>> Of course you can use the same cert for both servers. >> >> I'm ok with that assuming we have an effective way of enforcing it. >> We'll need to provide some good documentation on how to create, or >> re-create, a PKCS#12 file to fit this format. Yes, enforcing this isn't hard. Creating is them easy too, it's the default (if not only) option in most tools. PKCS#12s with more than one cert chain are fairly exotic, from what I've read some Java tools that can use them but they run into interoperability problems. >>> The --external_ca_file must contain exactly one cert. Certs for any >>> intermediate CAs must be in the PKCS#12. >> >> It would be a lot easier to include all the CAs in a single PEM. This >> is not unprecedented, and just catting a bunch of certs together into >> a single file is easy and should not be error-prone. I don't want the whole chain in the PEM, because then it's not obvious which cert(s) to trust. We certainly don't want to give root trust to every cert in the chain. So if we allow more CAs here they'd have to be different *root* CAs. That would allow the server certs to be signed by different CAs, so I guess we want to do this. I don't know of a robust way to know that we have separate root CAs and not a chain (or several partial chains, etc.), so we'd have to document this well. But more importantly, this would mean we'd have to put several certs in /etc/ipa/ca.crt, and in LDAP. This is rather invasive so I'd like to stay out of this for now (but design so it's possible in the future). >> I think too we'll need to be able to handle the case of any Built-in >> certs. There is a chance we will need to simply drop on the floor any >> CA certs provided because some or all of them are already in NSS (all >> we really care about for this, I think). We still need to put something in /etc/ipa/ca.crt. I'll investigate what happens when I try to import and trust a cert that's already trusted, but I don't think it will cause any trouble? >>> Does that look good? Does it need a design page? >> >> I think a design page would be particularly helpful in this case. I >> think this is going to be rather complex, and whatever choices we make >> to simplify things are going to be important. > > Yes the design is needed with the content of this thread plus some > examples of the command line plus some hints & guidance on how to > prepare files to be in the right format. > This includes: > How to check what format the files are? > How many are there in the file? > How to extact certs or or combine certs into files? > How to save in the format we want/need? > > Explain why we require all this "more typing". We want to be explicit > but we also want people to understand why we want them to be explicit. > This is a very complex area and if we can explain why we ware requiring > what we are requiring it would go a long way to helping people > understand what they are doing and what would the implication be. OK. I'll just finish this informal discussion first so I don't have to re-type everything. >>> I have some patches for this and for replication, but it'll take another >>> day to polish and test them. >> >> Sounds great. >> >>> >>> [...] >>>> I'm not sure the dogtag 9 removal code really fits in the context of >>>> these changes. It makes sense, but has nothing to do with this. >>> >>> I'll retire that patch for now. >> >> It would probably be a good idea to open a ticket and attach your >> current work. Let's see if Trac lets me do that :) Thanks, Petr? From akrivoka at redhat.com Thu Mar 21 12:58:33 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 21 Mar 2013 13:58:33 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Use default NETBIOS name in unattended ipa-adtrust-install Message-ID: <514B03F9.7070900@redhat.com> Hello, Unattended ipa-adtrust-install used to fail if --netbios option was not provided. This patches fixes this, so that instead of failing the default NETBIOS name is used. https://fedorahosted.org/freeipa/ticket/3497 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0009-Use-default-NETBIOS-name-in-unattended-ipa-adtrust-i.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 21 13:00:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 14:00:40 +0100 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <514A363B.8050600@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> <5149AE49.7010209@redhat.com> <5149DB2A.6020505@redhat.com> <514A02DF.80001@redhat.com> <514A363B.8050600@redhat.com> Message-ID: <514B0478.7040903@redhat.com> On 03/20/2013 11:20 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 03/20/2013 04:52 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 03/19/2013 05:09 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 03/19/2013 10:57 AM, Martin Kosek wrote: >>>>>>> On 03/18/2013 04:07 PM, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 03/15/2013 04:42 PM, Rob Crittenden wrote: >>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>>> On 03/11/2013 10:07 PM, Rob Crittenden wrote: >>>>>>>>>>>>> Fixed a number of issues applying password policy against >>>>>>>>>>>>> LDAP binds. >>>>>>>>>>>>> See patch >>>>>>>>>>>>> for details. >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I see some issues with this fix: >>>>>>>>>>>> >>>>>>>>>>>> 1) Shouldn't group password policy serve only as an override >>>>>>>>>>>> to the main >>>>>>>>>>>> policy? I.e. if I have this policy: >>>>>>>>>>>> >>>>>>>>>>>> # ipa pwpolicy-show test >>>>>>>>>>>> Group: test >>>>>>>>>>>> Priority: 10 >>>>>>>>>>>> Max failures: 2 >>>>>>>>>>>> >>>>>>>>>>>> We should still follow settings other than "Max failures" >>>>>>>>>>>> configured in >>>>>>>>>>>> global policy, right? At least the Kerberos seem to do it. I >>>>>>>>>>>> think we >>>>>>>>>>>> should be consistent in this case. Now, other values just >>>>>>>>>>>> seem to be >>>>>>>>>>>> zero. >>>>>>>>>>> >>>>>>>>>>> There should be only one policy. It isn't supposed to merge >>>>>>>>>>> policies >>>>>>>>>>> together (there is only one krbPwdPolicyReference per principal). >>>>>>>>> >>>>>>>>> That's a good point. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> How is the KDC acting differently? >>>>>>>>> >>>>>>>>> For example, if you set only maximal number of bad password >>>>>>>>> guesses, it >>>>>>>>> does >>>>>>>>> not allow any more (user fbar1 is a member of test group): >>>>>>>>> >>>>>>>>> # ipa pwpolicy-mod test --maxfail 3 >>>>>>>>> Group: test >>>>>>>>> Priority: 10 >>>>>>>>> Max failures: 3 >>>>>>>>> >>>>>>>>> # kinit fbar1 >>>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>>> # kinit fbar1 >>>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>>> # kinit fbar1 >>>>>>>>> Password for fbar1 at IDM.LAB.BOS.REDHAT.COM: >>>>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>>>> # kinit fbar1 >>>>>>>>> kinit: Clients credentials have been revoked while getting initial >>>>>>>>> credentials >>>>>>>>> >>>>>>>>> But LDAP binds are still allowed >>>>>>>>> >>>>>>>>> # ldapsearch -h localhost -D >>>>>>>>> uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>>>> -x -w >>>>>>>>> foo >>>>>>>>> -s base -b "" >>>>>>>>> ldap_bind: Invalid credentials (49) >>>>>>>>> >>>>>>>>> I think this is just caused by different processing of >>>>>>>>> krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it >>>>>>>>> is not >>>>>>>>> set, >>>>>>>>> max auth tries checks are pretty much disabled). >>>>>>>> >>>>>>>> We can't examine things until a successful bind is done. If it is >>>>>>>> done >>>>>>>> and we >>>>>>>> determine that they should be locked out we refuse to continue. >>>>>>> >>>>>>> I am not sure I follow - what do you mean by "examine things"? The >>>>>>> bind preop >>>>>>> plugin can check current policy with unsuccessful login, right? I >>>>>>> just >>>>>>> thought >>>>>>> that when the custom policy has krbpwdmaxfailure set, but does not >>>>>>> have >>>>>>> krbpwdfailurecountinterval set, we should still enforce the >>>>>>> krbpwdmaxfailure >>>>>>> "somehow", as ipa-kdb does. >>>>>>> >>>>>>> If not, I think we should either mark those params in pwpolicy >>>>>>> plugin as >>>>>>> required or at least add a note to ipa help mentioning this >>>>>>> limitation for >>>>>>> LDAP >>>>>>> binds.... >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I think we will need to fix both the pre-op and the post-op >>>>>>>>>>>> to make this >>>>>>>>>>>> working really consistently. >>>>>>>>>>>> >>>>>>>>>>>> 2) The lockout post-op still counts failed logins even though >>>>>>>>>>>> we are in >>>>>>>>>>>> lockout time, is this expected? It is another point if >>>>>>>>>>>> inconsistency >>>>>>>>>>>> with Kerberos auth. It leaves user's krbloginfailedcount stay >>>>>>>>>>>> on "Max >>>>>>>>>>>> failures". >>>>>>>>>>> >>>>>>>>>>> Ok. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) Sometimes, I get into a state when I lockout a new user >>>>>>>>>>>> with Kerberos >>>>>>>>>>>> and then wait some time until the lockout time passes (no >>>>>>>>>>>> admin unlock), >>>>>>>>>>>> I am able to run as many LDAP binds as I want. >>>>>>>>>>> >>>>>>>>>>> Can you clarify? Successful or unsuccessful binds? >>>>>>>>> >>>>>>>>> Unsuccessful binds. I will try to reproduce it again when you >>>>>>>>> fix the >>>>>>>>> crash, it >>>>>>>>> is hard to investigate it with this crash around. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This is all I found so far. Honza is also reviewing it, so I >>>>>>>>>>>> will let >>>>>>>>>>>> him post hist findings too. >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> Here is an updated patch to not increment past the max failures >>>>>>>>>> on LDAP >>>>>>>>>> binds. >>>>>>>>> >>>>>>>>> The new patch now causes 389-ds to crash with SIGSEGV if I try >>>>>>>>> to bind as a >>>>>>>>> user with no group policy assigned (Stacktrace attached). >>>>>>>> >>>>>>>> Stupid mistake on my part. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Fixed now :) I found one more issue. When you add a new user with >>>>>>> a password, >>>>>>> wrong LDAP binds do not increase failure count until the latest >>>>>>> failure >>>>>>> timestamp is set, for example via failed Kerberos login: >>>>>>> >>>>>>> # ipa user-status fbar2 >>>>>>> ----------------------- >>>>>>> Account disabled: False >>>>>>> ----------------------- >>>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>>> Failed logins: 0 >>>>>>> Last successful authentication: N/A >>>>>>> Last failed authentication: N/A >>>>>>> Time now: 2013-03-19T09:01:35Z >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> >>>>>>> # ldapsearch -h localhost -D >>>>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>> -x -w >>>>>>> foo >>>>>>> -s base -b "" >>>>>>> ldap_bind: Invalid credentials (49) >>>>>>> >>>>>>> # ipa user-status fbar2 >>>>>>> ----------------------- >>>>>>> Account disabled: False >>>>>>> ----------------------- >>>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>>> Failed logins: 0 >>>>>>> Last successful authentication: N/A >>>>>>> Last failed authentication: N/A >>>>>>> Time now: 2013-03-19T09:01:54Z >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> >>>>>>> # kinit fbar2 >>>>>>> Password for fbar2 at IDM.LAB.BOS.REDHAT.COM: >>>>>>> kinit: Password incorrect while getting initial credentials >>>>>>> >>>>>>> # ipa user-status fbar2 >>>>>>> ----------------------- >>>>>>> Account disabled: False >>>>>>> ----------------------- >>>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>>> Failed logins: 1 >>>>>>> Last successful authentication: N/A >>>>>>> Last failed authentication: 2013-03-19T09:02:14Z >>>>>>> Time now: 2013-03-19T09:02:16Z >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> >>>>>>> # ldapsearch -h localhost -D >>>>>>> uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>> -x -w >>>>>>> foo >>>>>>> -s base -b "" >>>>>>> ldap_bind: Invalid credentials (49) >>>>>>> >>>>>>> # ipa user-status fbar2 >>>>>>> ----------------------- >>>>>>> Account disabled: False >>>>>>> ----------------------- >>>>>>> Server: vm-037.idm.lab.bos.redhat.com >>>>>>> Failed logins: 2 <<<<<< It increased now >>>>>>> Last successful authentication: N/A >>>>>>> Last failed authentication: 2013-03-19T09:02:20Z >>>>>>> Time now: 2013-03-19T09:02:24Z >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> >>>>>>> >>>>>>> As for the issue you could not reproduce, it is also quite >>>>>>> difficult to >>>>>>> reproduce it for me, I usually have to combine same >>>>>>> failed/successful logins, >>>>>>> waits for lockouts etc. I need to look at that more closely. Just >>>>>>> for the >>>>>>> record, attaching an LDIF of a user in such a state when I can do >>>>>>> as many >>>>>>> failing ldapsearches as I want. This is the password policy: >>>>>>> >>>>>>> # ipa pwpolicy-show >>>>>>> Group: global_policy >>>>>>> Max lifetime (days): 90 >>>>>>> Min lifetime (hours): 1 >>>>>>> History size: 0 >>>>>>> Character classes: 0 >>>>>>> Min length: 8 >>>>>>> Max failures: 6 >>>>>>> Failure reset interval: 60 >>>>>>> Lockout duration: 30 >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I discovered that the issue is in the postop: >>>>>> >>>>>> + if (failedcount < max_fail) { >>>>>> + PR_snprintf(failedcountstr, >>>>>> sizeof(failedcountstr), "%lu", >>>>>> failedcount); >>>>>> + slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>>>> "krbLoginFailedCount", failedcountstr); >>>>>> + failedcount += 1; >>>>>> + PR_snprintf(failedcountstr, >>>>>> sizeof(failedcountstr), "%lu", >>>>>> failedcount); >>>>>> + slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>>>> "krbLoginFailedCount", failedcountstr); >>>>>> } >>>>>> >>>>>> We try to delete failedcount and add failedcount+1, but this >>>>>> operation may >>>>>> fail >>>>>> if the failedcount was set to 0 previously due to exceeded >>>>>> krbpwdfailurecountinterval. This also makes the succeeding last >>>>>> failed auth >>>>>> timestamp update to fail too and cause this vulnerability. >>>>>> >>>>>> I was able to fix it with this change: >>>>>> >>>>>> @@ -526,11 +535,9 @@ static int ipalockout_postop(Slapi_PBlock *pb) >>>>>> */ >>>>>> if (failed_bind) { >>>>>> if (failedcount < max_fail) { >>>>>> - PR_snprintf(failedcountstr, >>>>>> sizeof(failedcountstr), "%lu", >>>>>> failedcount); >>>>>> - slapi_mods_add_string(smods, LDAP_MOD_DELETE, >>>>>> "krbLoginFailedCount", failedcountstr); >>>>>> failedcount += 1; >>>>>> PR_snprintf(failedcountstr, >>>>>> sizeof(failedcountstr), "%lu", >>>>>> failedcount); >>>>>> - slapi_mods_add_string(smods, LDAP_MOD_ADD, >>>>>> "krbLoginFailedCount", failedcountstr); >>>>>> + slapi_mods_add_string(smods, LDAP_MOD_REPLACE, >>>>>> "krbLoginFailedCount", failedcountstr); >>>>>> } >>>>>> if (lastfail) { >>>>>> if (!gmtime_r(&(time_now), &utctime)) { >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I cam to a similar conclusion. We want to be careful when deleting >>>>> values so we >>>>> can handle the case where multiple bind attempts are happening at >>>>> once so we >>>>> try to avoid using REPLACE. I changed it so we save the value of >>>>> failedcount >>>>> when the lockout expires. >>>>> >>>>> I also added a chance to handle the case where there is no >>>>> failedcount at all. >>>>> I was trying to delete a non-existent 0 value. >>>>> >>>>> rob >>>> >>>> Ok, the updated version works well. I think we are getting close to >>>> finish this. >>>> >>>> I now also tried krbPwdLockoutDuration=0 and it does not/cannot work >>>> properly >>>> as we are still reseting failedcount to zero even though the account is >>>> locked out. >>>> >>>> Shouldn't we do it only if the account is not in lockout period? >>> >>> Yup. Now skip that calculation if lockout_duration == 0. >>> >>> I also tested that things work if user has a strong policy and is >>> locked out >>> due to duration = 0, delete that policy and then user can try to >>> authenticate >>> again b/c default policy has a lockout timeout. >>> >>> rob >>> >> >> This is not what I meant, sorry for not being clear previously. This >> patch still lets user to override lockout and try to login if "Failure >> reset interval" already passed even though account is still in lockout >> phase. >> >> Consider this policy: >> # ipa pwpolicy-show >> Group: global_policy >> Max lifetime (days): 90 >> Min lifetime (hours): 1 >> History size: 0 >> Character classes: 0 >> Min length: 8 >> Max failures: 3 >> Failure reset interval: 30 <<<< >> Lockout duration: 300 <<<< >> >> After 3 tries by Kerberos/LDAP auth, account is locked out. However, >> after 30 seconds, LDAP binds are allowed again due to "Failure reset >> interval". Kerberos auth is not allowed until 300 seconds pass (as I >> would expect). >> >> This is what I think that needs to be done when user is in lockout phase: >> - do not care about "Failure reset interval" in preop/postop >> - do not update failed login count/last failed login timestamp in >> postop. We currently update last failed login timestamp, but Kerberos >> does not do it. Otherwise, this would practically make the lockout phase >> longer as we count it based on the last failed timestamp. > > We need to consider the interval because all the failures have to occur within it. > > I reordered a bit of the evaluation code and added consideration for lockout > period so it is properly enforced now both for duration == 0 (permanent > lockout) and for a duration. > > I confirmed that administrative unlock works as well, also both in the case of > a duration lockout and a permanent lockout. > > Hopefully I tested better this go-around. > > rob > Good job! I noticed just one last case when there is inconsistency with Kerberos auth. If you have Lockout duration set to 0, "Failure reset interval" does not work in postop. Also, following errors in 389-ds-base error log are printed: [21/Mar/2013:07:54:01 -0400] - slapi_modify_internal_set_pb: NULL parameter [21/Mar/2013:07:54:01 -0400] - allow_operation: component identity is NULL I also saw that we sometimes set krbLoginFailedCount to 0 even though it was already zero. I think this could create unnecessary replication events or at least unnecessary mod call. Attaching a patch for both. If you found the patch OK, you can squash it and push the whole beast. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixes-for-1092.patch Type: text/x-patch Size: 5412 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 21 13:19:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Mar 2013 14:19:10 +0100 Subject: [Freeipa-devel] [PATCH 0121] Fix crash during invalid zone reload process Message-ID: <514B08CE.7080708@redhat.com> Hello, Fix crash during invalid zone reload process. This bug was created during settings refactoring and is present only in master, not in v2 branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0121-Fix-crash-during-invalid-zone-reload-process.patch Type: text/x-patch Size: 1193 bytes Desc: not available URL: From simo at redhat.com Thu Mar 21 13:21:47 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 21 Mar 2013 09:21:47 -0400 Subject: [Freeipa-devel] New RFC: An Information Model for Kerberos Version 5 In-Reply-To: <514AD296.7030303@redhat.com> References: <514AD296.7030303@redhat.com> Message-ID: <1363872107.28488.69.camel@willson.li.ssimo.org> On Thu, 2013-03-21 at 10:27 +0100, Petr Spacek wrote: > Hello list, > > a new RFC "An Information Model for Kerberos Version 5" was published: > http://tools.ietf.org/html/rfc6880 > > RFC status and other metadata: > https://datatracker.ietf.org/doc/rfc6880/ > > Kerberos experts, is it interesting for FreeIPA? I have review it in the WG, it is just a formalization of the data model. It is useful for someone that needs to understand the issue and gives guidelines. We also have an LDAP schema document that was waiting for this RFC to be standardized in order to reference it, we'll see if that effort gets revived now. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Mar 21 12:38:42 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Mar 2013 13:38:42 +0100 Subject: [Freeipa-devel] [PATCH 0120] Fix automatic reloading of invalid zone after each change in zone data Message-ID: <514AFF52.1080305@redhat.com> Hello, Fix automatic reloading of invalid zone after each change in zone data. Reload wasn't done when serial_autoincrement feature was disabled. https://fedorahosted.org/bind-dyndb-ldap/ticket/102 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0120-Fix-automatic-reloading-of-invalid-zone-after-each-c.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 21 13:45:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Mar 2013 14:45:11 +0100 Subject: [Freeipa-devel] [PATCH 0122] Log successful zone reload after record change. Message-ID: <514B0EE7.2040109@redhat.com> Hello, Log successful zone reload after record change. This should be last piece of https://fedorahosted.org/bind-dyndb-ldap/ticket/102 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0122-Log-successful-zone-reload-after-record-change.patch Type: text/x-patch Size: 2347 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 21 14:01:10 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 15:01:10 +0100 Subject: [Freeipa-devel] [PATCH] 396 Fix structured DNS record output Message-ID: <514B12A6.6050701@redhat.com> Recent LDAP refactoring replaced entry_attrs regular dict with normalized keys (i.e. lowercase) with LDAPEntry instance which keys may not be normalized. This broke CND command output when --structured and --all options were used. Force lowercase normalization of the LDAPEntry keys in DNS plugin structured format postprocessing. Also add a missing test for DNS record structured output. https://fedorahosted.org/freeipa/ticket/3526 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-396-fix-structured-dns-record-output.patch Type: text/x-patch Size: 3040 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 21 14:11:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 15:11:08 +0100 Subject: [Freeipa-devel] [PATCH] 397 Bump selinux-policy requires Message-ID: <514B14FC.9020704@redhat.com> The higher version is reported to fix a Fedora 17 to 18 upgrade issue. https://fedorahosted.org/freeipa/ticket/3399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-397-bump-selinux-policy-requires.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 21 15:23:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 16:23:25 +0100 Subject: [Freeipa-devel] [PATCH] 388-389 Improve client install LDAP cert retrieval fallback In-Reply-To: <51487969.4090705@redhat.com> References: <5141D374.5090306@redhat.com> <51487969.4090705@redhat.com> Message-ID: <514B25ED.2030109@redhat.com> On 03/19/2013 03:42 PM, Tomas Babej wrote: > On 03/14/2013 02:41 PM, Martin Kosek wrote: >> [freeipa-mkosek-388-use-temporary-ccache-in-ipa-client-install.patch]: >> >> ipa-client-install failed if user had set his own KRB5CCNAME in his >> environment. Use a temporary CCACHE for the installer to avoid these >> kind of errors. >> >> [freeipa-mkosek-389-improve-client-install-ldap-cert-retrieval-fallback.patch]: >> >> CA certificate retrieval function did not fallback from LDAP to >> HTTP based retrieval in case of an LDAP error, when for example >> GSSAPI authentication failed. >> >> ------------- >> >> Sending Fedora 18 client installation fixes as per >> https://bugzilla.redhat.com/show_bug.cgi?id=920716#c10 >> >> Martin >> > Fixes the issue just fine. Ack. > > Just a nitpick, only patch 389 is linked in Trac. > I uploaded the second part as well, for consistency's sake. > > Tomas Pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Thu Mar 21 15:34:27 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Mar 2013 16:34:27 +0100 Subject: [Freeipa-devel] [PATCH] 269 Run permission target switch action only for visible widgets Message-ID: <514B2883.7090702@redhat.com> Permission details page was incorrectly evaluated as dirty (update button enabled) right after load when permission type={subtree,filter} and some attrs are set. Can be reproduced by opening 'Modify Automount maps' permission. The culprit is that attrs widget is populated and dirty-checked even targets where it doesn't belong. Fixed by running target_mapping action only for visible targets. https://fedorahosted.org/freeipa/ticket/3527 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0269-Run-permission-target-switch-action-only-for-visible.patch Type: text/x-patch Size: 1256 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 21 15:56:20 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Mar 2013 16:56:20 +0100 Subject: [Freeipa-devel] [PATCH] 270 Load extension.js after UI AMD modules. Message-ID: <514B2DA4.1020107@redhat.com> This patch is a fix for upcoming ipa-3-1 minor release. Loading of extension.js was removed with introduction of AMD modules. This patch returns the feature to avoid regressions. In 3.2 it will be handled differently (multiple plugins). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0270-Load-extension.js-after-UI-AMD-modules.patch Type: text/x-patch Size: 1295 bytes Desc: not available URL: From abokovoy at redhat.com Thu Mar 21 16:07:19 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 Mar 2013 18:07:19 +0200 Subject: [Freeipa-devel] [PATCH] Dogtag exception handling Message-ID: <20130321160719.GF6823@redhat.com> Hi, Martin asked me to update the patch I've attached to ticket https://fedorahosted.org/freeipa/ticket/3492 and here we go. Process exceptions when talking to Dogtag The problem is the ca_status() uses an HTTP GET operation to check Dogtag's status. Under some circumstances Dogtag may take a long time to respond, so the HTTP GET may time out much earlier than 2 minutes. And since the above code doesn't catch the exception, the whole loop fails immediately, so it doesn't wait for a full 2 minutes as expected. -- / Alexander Bokovoy -------------- next part -------------- >From 15b60ee4f1dd39ccb406c3e35be086158eab782e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 6 Mar 2013 10:17:58 +0200 Subject: [PATCH 2/2] Process exceptions when talking to Dogtag The problem is the ca_status() uses an HTTP GET operation to check Dogtag's status. Under some circumstances Dogtag may take a long time to respond, so the HTTP GET may time out much earlier than 2 minutes. And since the above code doesn't catch the exception, the whole loop fails immediately, so it doesn't wait for a full 2 minutes as expected. https://fedorahosted.org/freeipa/ticket/3492 --- ipapython/platform/fedora16/service.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ipapython/platform/fedora16/service.py b/ipapython/platform/fedora16/service.py index c2e35d3..dac8c00 100644 --- a/ipapython/platform/fedora16/service.py +++ b/ipapython/platform/fedora16/service.py @@ -136,7 +136,10 @@ class Fedora16CAService(Fedora16Service): timeout = api.env.startup_timeout op_timeout = time.time() + timeout while time.time() < op_timeout: - status = dogtag.ca_status() + try: + status = dogtag.ca_status() + except Exception: + status = 'check interrupted' root_logger.debug('The CA status is: %s' % status) if status == 'running': break -- 1.8.1.4 From mkosek at redhat.com Thu Mar 21 16:10:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 17:10:49 +0100 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <5143D9A7.3000803@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> Message-ID: <514B3109.2010307@redhat.com> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: > On 3/12/2013 11:28 AM, Petr Vobornik wrote: >> Here's a patch for filtering groups by type. >> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >> >> The interface is: >>> StrEnum('type?', >>> cli_name='type', >>> label=_('Type'), >>> doc=_('Group type'), >>> values=(u'posix', u'normal', u'external'), >>> ), >> >> I have two design questions. >> 1. Is --type the right option name? > > Fine by me, it matches the label and description. > >> 2. Is `normal` the right name for non-posix, non-external group? The >> default group type (when adding group) is posix. Should the name be >> something else: `simple`, `plain`, `ordinary`? > > We also use 'normal' in the group adder dialog, so it's consistent. Other > options are 'basic', 'standard', 'regular'. > >> I didn't want to create an option for each type. IMO it brings more >> complexity. > > Maybe the group-add/mod command should use the same --type option? > >> https://fedorahosted.org/freeipa/ticket/3483 > > ACK from me, but maybe others might have some comments. > I am just thinking about if the new API is right. For example, when we add an external group, we use ipa group-add --external. But when we search for external groups, we suddenly use # ipa group-find --type=external and not # ipa group-find --external or # ipa group-find --nonposix Wouldn't that cause confusion? I am looking for same second opinion on this one. I also did not like "normal" group type very much, maybe we should just call it "nonposix"? As that's the option you use when you are creating such group: # ipa group-add --nonposix foo Otherwise, the patch looks good functionally. Martin From akrivoka at redhat.com Thu Mar 21 16:19:45 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 21 Mar 2013 17:19:45 +0100 Subject: [Freeipa-devel] [PATCH] 269 Run permission target switch action only for visible widgets In-Reply-To: <514B2883.7090702@redhat.com> References: <514B2883.7090702@redhat.com> Message-ID: <514B3321.3010904@redhat.com> On 03/21/2013 04:34 PM, Petr Vobornik wrote: > Permission details page was incorrectly evaluated as dirty (update > button enabled) right after load when permission type={subtree,filter} > and some attrs are set. > > Can be reproduced by opening 'Modify Automount maps' permission. > > The culprit is that attrs widget is populated and dirty-checked even > targets where it doesn't belong. > > Fixed by running target_mapping action only for visible targets. > > https://fedorahosted.org/freeipa/ticket/3527 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The patch fixes the issue. ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Mar 21 16:22:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Mar 2013 17:22:17 +0100 Subject: [Freeipa-devel] [PATCH] Dogtag exception handling In-Reply-To: <20130321160719.GF6823@redhat.com> References: <20130321160719.GF6823@redhat.com> Message-ID: <514B33B9.1050001@redhat.com> On 03/21/2013 05:07 PM, Alexander Bokovoy wrote: > Hi, > > Martin asked me to update the patch I've attached to ticket > https://fedorahosted.org/freeipa/ticket/3492 and here we go. > > Process exceptions when talking to > Dogtag > > The problem is the ca_status() uses an HTTP GET operation to check > Dogtag's status. Under some circumstances Dogtag may take a long time to > respond, so the HTTP GET may time out much earlier than 2 minutes. And > since the above code doesn't catch the exception, the whole loop fails > immediately, so it doesn't wait for a full 2 minutes as expected. > ACK, along with higher startup_timeout, this fixes the issue in my VM. Pushed to master, ipa-3-1 (rebased). I just could not close the ticket yet as the Trac is malfunctioning again. Will do that later. Martin From pviktori at redhat.com Thu Mar 21 16:39:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Mar 2013 17:39:17 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <514AF66E.2070901@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> Message-ID: <514B37B5.3050906@redhat.com> [...] another thing: When drafting the feature page, I realized the --{http,dirsrv}_pin options are unfortunate. Giving the passwords in command line options is unsafe. I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if they're not given. -- Petr? From pviktori at redhat.com Thu Mar 21 17:05:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Mar 2013 18:05:22 +0100 Subject: [Freeipa-devel] IPA Git mirror Message-ID: <514B3DD2.2020502@redhat.com> Hello, Since our git repo has gotten extremely slow, I've been asked about my Github mirror. Since it might benefit others I'm sharing on the list. The pull URL is git://github.com/encukou/freeipa.git, and it's updated twice an hour*. I'd like to ask people that push patches to include the HEAD SHA1 in the notification e-mail, so we can pull from untrusted mirrors safely. The current master is 41031fe121d6ec8bc9a6bb48b62068a9af905dc3 (Process exceptions when talking to Dogtag). -- Petr? *the sync script only runs when my work machine is on (can't put it in the lab because it uses personal credentials). I'll leave it on until the official repo gets better. From pvoborni at redhat.com Thu Mar 21 17:10:57 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Mar 2013 18:10:57 +0100 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <514B3109.2010307@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> Message-ID: <514B3F21.2030103@redhat.com> On 03/21/2013 05:10 PM, Martin Kosek wrote: > On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>> Here's a patch for filtering groups by type. >>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>> >>> The interface is: >>>> StrEnum('type?', >>>> cli_name='type', >>>> label=_('Type'), >>>> doc=_('Group type'), >>>> values=(u'posix', u'normal', u'external'), >>>> ), >>> >>> I have two design questions. >>> 1. Is --type the right option name? >> >> Fine by me, it matches the label and description. >> >>> 2. Is `normal` the right name for non-posix, non-external group? The >>> default group type (when adding group) is posix. Should the name be >>> something else: `simple`, `plain`, `ordinary`? >> >> We also use 'normal' in the group adder dialog, so it's consistent. Other >> options are 'basic', 'standard', 'regular'. >> >>> I didn't want to create an option for each type. IMO it brings more >>> complexity. >> >> Maybe the group-add/mod command should use the same --type option? >> >>> https://fedorahosted.org/freeipa/ticket/3483 >> >> ACK from me, but maybe others might have some comments. >> > > I am just thinking about if the new API is right. For example, when we add an > external group, we use ipa group-add --external. But when we search for > external groups, we suddenly use > # ipa group-find --type=external > and not > # ipa group-find --external > or > # ipa group-find --nonposix > > Wouldn't that cause confusion? I am looking for same second opinion on this one. > > I also did not like "normal" group type very much, maybe we should just call it > "nonposix"? As that's the option you use when you are creating such group: > # ipa group-add --nonposix foo > > Otherwise, the patch looks good functionally. > > Martin > I have to note that external group is also non-posix. Following command is valid: # ipa group-add foo --desc=a --external --nonposix By that logic # ipa group-find --nonposix Would also list external groups. I fine with renaming 'normal' to something better (will also require Web UI change), but it is not 'nonposix'. -- Petr Vobornik From rcritten at redhat.com Thu Mar 21 19:49:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Mar 2013 15:49:18 -0400 Subject: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin In-Reply-To: <514B0478.7040903@redhat.com> References: <513E477C.6050505@redhat.com> <5142F5A0.6090100@redhat.com> <51432377.6050003@redhat.com> <51434171.1090802@redhat.com> <51470BEF.1080108@redhat.com> <51472DBB.5020900@redhat.com> <514836A5.2010600@redhat.com> <51485490.2050507@redhat.com> <51488DBE.4000802@redhat.com> <5149AE49.7010209@redhat.com> <5149DB2A.6020505@redhat.com> <514A02DF.80001@redhat.com> <514A363B.8050600@redhat.com> <514B0478.7040903@redhat.com> Message-ID: <514B643E.6070308@redhat.com> Martin Kosek wrote: > > Good job! I noticed just one last case when there is inconsistency with > Kerberos auth. > > If you have Lockout duration set to 0, "Failure reset interval" does not work > in postop. Also, following errors in 389-ds-base error log are printed: > > [21/Mar/2013:07:54:01 -0400] - slapi_modify_internal_set_pb: NULL parameter > [21/Mar/2013:07:54:01 -0400] - allow_operation: component identity is NULL > > I also saw that we sometimes set krbLoginFailedCount to 0 even though it was > already zero. I think this could create unnecessary replication events or at > least unnecessary mod call. > > Attaching a patch for both. If you found the patch OK, you can squash it and > push the whole beast. > > Martin > This data isn't replicated anyway, but not doing an empty mod makes sense. Thanks for the suggestions. I squashed this and pushed to master. rob From mkosek at redhat.com Fri Mar 22 08:19:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 09:19:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <514B37B5.3050906@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514B37B5.3050906@redhat.com> Message-ID: <514C1420.3070408@redhat.com> On 03/21/2013 05:39 PM, Petr Viktorin wrote: > [...] > > another thing: When drafting the feature page, I realized the > --{http,dirsrv}_pin options are unfortunate. Giving the passwords in command > line options is unsafe. > > I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if > they're not given. > How is that different from -p DM_PASSWORD and -a ADMIN_PASSWORD? They also cannot be read from file. I think these options would cause inconsistency with the rest of our password options in ipa-{server,client,replica}-install. It also seems as inconvenience to me as you need to prepare this artificial file before running ipa-server-install... I think it would be better to address this consistently in the future with configuration file instead of options, something like pkispawn uses. Martin From pspacek at redhat.com Fri Mar 22 09:04:00 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Mar 2013 10:04:00 +0100 Subject: [Freeipa-devel] DNS update mechanism: news about update authorization In-Reply-To: <5130C5FB.9070205@redhat.com> References: <5130BB3A.2070405@redhat.com> <1362148765.2962.139.camel@willson.li.ssimo.org> <5130C5FB.9070205@redhat.com> Message-ID: <514C1E80.8060505@redhat.com> On 1.3.2013 16:15, Petr Spacek wrote: > On 1.3.2013 15:39, Simo Sorce wrote: >> On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote: >>> Hello list, >>> >>> we would like to share some news about DNS update mechanism: >>> >>> - It is possible to allow particular principal to update all records in a >>> zone. >>> >>> - It is possible to allow clients to update own PTR records. PTR update can be >>> "authenticated and authorized" by source IP address of the TCP connection from >>> the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR >>> record with name 31.0.2.192.in-addr.arpa., nothing else. >>> >>> See examples in following how-to: >>> http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy >>> >>> >>> Simo pointed to fact that "TCP authenticated" update requests can be more >>> secure than current approach with "PTR synchronization" magic (done inside >>> bind-dyndb-ldap). >>> >>> Unfortunately, it is not possible to combine TCP "authentication" with >>> GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is >>> not possible to combine multiple requirements. >>> >>> 'tcp-self' rule ignores request signature completely. Implementation of (TCP >>> && signed) requirement will require patching BIND. I don't like that idea, >>> because we will deviate from plain BIND docs and it will cause confusion. >>> >>> We can propose a change and send patches to ISC. It should be possible to >>> implement new 'tcp-signed-self' mechanism with only few lines of code. The >>> question is how it should behave: >>> >>> Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed >>> to do tcp-self update? >> >> Should be at least a host/ principal, otherwise a mere user could change >> the PTR record, would be even better if we can match the fqdn int the >> host/ principal to the content of the PTR record. >> >> So if you sign with principal for host/foo.bar.baz and come from >> 10.11.22.33 then you can only create a PTR record of 10.11.22.33 -> >> foo.bar.baz >> >>> Should we implement configurable realm check? I.e. the update will be allowed >>> only if the update is signed by principal from specified Kerberos realm? >> >> This too would be nice but not as important. >> >>> How it should work with Kerberos trusts? >> >> You would prevent principals from a trusted domain to update DNS >> entries. >> Checking for the REALM part should be optional. >> >>> Also, it should be possible to implement more strict check: Updated name in >>> reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address >>> and *at the same time* name stored to PTR record has to match name in client's >>> principal. >>> >>> Example: >>> - client's IP address: 192.0.2.31 >>> - client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM >> >> Yeah I should have read the whole message trough before starting >> replying :-) >> >>> This particular client is allowed only to add record: >>> 31.0.2.192.in-addr.arpa. IN PTR client.example.com. >>> >>> Question is how to authorize record deletion. I tend to allow all delete >>> operations for (reverse) name matching client's IP address. >> >> Yes this would be ok, worst case the PTR is lost. >> Again I would allow only by principals of the type host/* or maybe DNS/* >> not from every principal. > > I agree. We could imitate krb5-self semantics: > Service part is hardcoded to 'host/' and REALM part is configurable: > 'grant IPA.EXAMPLE.COM tcp-krb5-self;' > > Variant for AD machines: > 'grant AD.EXAMPLE.COM tcp-ms-self;' > AD variant will match names "machine$@AD.EXAMPLE.COM". News from ISC: Evan Hunt replied that ISC can include our patches with this functionality. I created ticket covering this task: https://fedorahosted.org/bind-dyndb-ldap/ticket/112 -- Petr^2 Spacek From pspacek at redhat.com Fri Mar 22 12:03:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Mar 2013 13:03:12 +0100 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) Message-ID: <514C4880.6000203@redhat.com> Hello, this patch set separates master zones (idnsZone objectClass) from forward zones (idnsForwardZone objectClass). Support for forward zones in idnsZone objectClass is still present to ease upgrades. See each commit message for all the gory details. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: 0123-Add-helper-functions-for-generic-iteration-over-RBT.patch Type: text/x-patch Size: 6225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0124-Add-missing-includes-to-util.h.patch Type: text/x-patch Size: 975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0125-Use-new-RBT-iterators-for-zone-deletion.patch Type: text/x-patch Size: 10930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0126-Add-support-for-pure-forward-zones-idnsForwardZone-o.patch Type: text/x-patch Size: 30278 bytes Desc: not available URL: From pspacek at redhat.com Fri Mar 22 12:06:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Mar 2013 13:06:12 +0100 Subject: [Freeipa-devel] [PATCH 0127] Remove orphaned function declaration from ldap_helper.h Message-ID: <514C4934.1000105@redhat.com> Hello, Remove orphaned function declaration from ldap_helper.h. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0127-Remove-orphaned-function-declaration-from-ldap_helpe.patch Type: text/x-patch Size: 999 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 22 12:10:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 13:10:29 +0100 Subject: [Freeipa-devel] [RFE] CA-less install Message-ID: <514C4A35.2060200@redhat.com> The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? -- Petr? __NOTOC__ = Overview = IPA will support installing without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. = Use Cases = # User installs IPA using the --http_pkcs, --dirsrv_pkcs, --http_pin, --dirsrv_pin, --root-ca-file options, giving appropriate certificates. # IPA installs and works normally, excluding the certificate management operaions # User creates a replica using --http_pkcs, --dirsrv_pkcs, --http_pin, --dirsrv_pin options to ipa-replica-prepare # Replica works normally, excluding certificate management operaions = Design= To install without a CA, the following options must be provided to ipa-server-install: * --http_pkcs: a PKCS#12 file containing the HTTP server certificate * --dirsrv_pkcs: a PKCS#12 file containing the Directory server certificate * --http_pin: password for the file given in --http_pkcs * --dirsrv_pin: password for the file given in --dirsrv_pkcs * --root-ca-file: a PEM file containing the root CA certificate Each of the PKCS#12 files must contain exactly one certificate with a private key. This will be used as the server certificate. It must also contain certificates of any intermediate CAs. It may contain any number of other certificates without matching private keys. The two PKCS#12 files may (and often will) be the same. The certificates must be valid as server certs for the given host. The PEM file given by --root-ca-file must contain exactly one certificate. This cert will be trusted as a root CA on the IPA server and all clients. Both server certs must be signed by this CA (possibly via a trust chain). It will be available in /etc/ipa/ca.crt and in the cACertificate attribute of cn=CACert,cn=ipa,cn=etc,$SUFFIX in LDAP, just like the IPA CA cert in Dogtag-based installations. These options are incompatible with --external-ca. To install a replica, following options must be provided to ipa-replica-prepare: * --http_pkcs * --dirsrv_pkcs * --http_pin * --dirsrv_pin The root CA is taken from the existing master. All apply as in the ipa-server-install case. == Why --root-ca-file? == IPA requires the user to specify the root CA to be trusted. This done to ensure that all replicas and clients trust the IPA certificates, no matter what their initial configuration is. Theoretically the CA certificate could be extracted from PKCS#12 files, but to ensure transparency and the administrator's control when it comes to trusting a root CA, it must always be specified explicitly. In the future it might be possible to trust more than one CA in this way. = Certificate management FAQ = == How to check what format files are? == Use the handy file command. PEM files show up as such: $ file /etc/ipa/ca.crt /etc/ipa/ca.crt: PEM certificate PKCS#12 files show up as just "data": $ file dirsrv.p12 dirsrv.p12: data To check a PKCS#12 file, you need to know the password: $ pk12util -l dirsrv.p12 Enter password for PKCS12 file: Certificate(has private key): <...> Certificate: <...> Key(shrouded): <...> == How many certs are there in a file? == For PKCS#12 files, use pk12util -l (see previous section). For PEM files, simply open the file in a pager or text editor and count the number of blocks. A certificate will look like this: $ cat /etc/ipa/ca.crt -----BEGIN CERTIFICATE----- MIIDuzCCAqOgAwIBAgIBATANBgkqhkiG9w0BAQsFADBFMSMwIQYDVQQKExpJRE0u TEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MB4XDTEzMDMyMDE3MDQxNFoXDTMzMDMyMDE3MDQxNFowRTEjMCEGA1UE ChMaSURNLkxBQi5FTkcuQlJRLlJFREhBVC5DT00xHjAcBgNVBAMTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZi pF9Dz5O1rVTRnwIdttHl0sKpHeRqzi/S7bnAFh3Jb2UxzFmHTpgQFKqq72mYatpL O0BPc47IGh9gwGZNLcEaNCf7zYCbqBJso8RV6SxbHSEdo+JuSYhMxVasKQcojqeY /wx11A4NSQAco6mBZz255llZqMQcJVMW4T8aioUd19Yh35CM9vr6l6dgUnvA9fAF TOl144yfF8AjvF1hIAePjLyl+Y/xxh1U2j5hF4z7ZeUGHKVZR9pQ62kbM7TgAR6Y YLGpis44JPfgRVkDGEkc7Vzpct1D4Iz7/oGMV+0kbJbz+9DSIHWY10QTtf9mNQNn xKGa3wCf5u8ctfmms8cCAwEAAaOBtTCBsjAfBgNVHSMEGDAWgBQCHF1DVeHg3kUG VRm/j0f9eji6nzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNV HQ4EFgQUAhxdQ1Xh4N5FBlUZv49H/Xo4up8wTwYIKwYBBQUHAQEEQzBBMD8GCCsG AQUFBzABhjNodHRwOi8vdm0tMDg0LmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29t OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAB3+or2Q/aPO4ZMBE4Q6xCMV 09ESAXXT/0DLakAt28ljy1wWKVR3d54TxZJ4DEcYgbxDa1A87DZW8sn+LM4Uwap9 DUyHA0mhBjROe6NXgJQl9aZ7IeE1ht+pw/n+JR2sg3ccYHvQjRcEZj2OPQuavyPn hwokDc3FVarlsQcrtfePG3e8TQXAnpSxV+KAMBEp4yib5nrkNZZoU+nqMI0ftXrk rP5q0SaEBEjC4+AoYje4Bv3+8RKT1kwBMkTL8eRRuWZmKvOy9sCnnFfU4HMMkPTK NJg9Gt8a/xU6GK239M1keCKct87VqWN1unXaD51bgotK1UJWj1q8H262mSYzfRg= -----END CERTIFICATE----- == How to extact certs or or combine certs into files? == === PEM Files === PEM files are plain text; manipulate them using a text editor === Using a NSS database === NSS databases can be manipulated using certutil and pk12util. In a NSS database, each certificate is identified using a "nickname". The nickname can be set with -n option, or taken from the "Friendly name" entry in a PKCS#12 file, or from the Subject of the certificate. Note that nicknames and Friendly Names are *not* part of the cert itself. Create a temporary NSS database using: certutil -N -d /path/to/nssdb Remember to set appropriate permissions if you're working with sensitive data. To list nicknames and trust flags in of the certs in the database, enter: certutil -L -d /path/to/nssdb/ To import a PKCS#12 file to a database: pk12util -i /path/to/pkcs12file.p12 -d /path/to/nssdb To export a PKCS#12 file from a database (this will export the certificate chain and private key(s), if available): pk12util -o /path/to/pkcs12file.p12 -d /path/to/nssdb -n To import a PEM file: certutil -A -d /path/to/nssdb -n -a -t -i For an explicitly trusted (root) CA, use "CT,C,C" for flags. Otherwise use ",," To export a PEM file (to stdout): certutil -L -d /path/to/nssdb -n -a Note that PEM is referred to as "ASCII" in certutil documentation. To create a self-signed root CA certificate and private key: certutil -S -d /path/to/nssdb -s "CN=$(hostname)" -m $RANDOM -n RootCA -t CT,C,C -x You should substitute a unique serial number for $RANDOM. To generate a Certificate Signing Request for a server: certutil -R -d /path/to/nssdb -s "CN=$(hostname)" -1 -a -o request.csr Select Digital Signature, Non-Repudiation and Key Encipherment for the extension. To sign the CSR, and get a PEM file with the cert: certutil -C -d /path/to/nssdb -m $RANDOM -a -i request.csr -c RootCA Again, substitute a unique serial number for $RANDOM. == How to check that my certificates will be usable? == To inspect PKCS#12 files, use pk12util -l. For other files, import them in a NSS database and use certutil -L. See above for details. For the servers, you will need certs with a private key. These show up as "Certificate(has private key):" in pk12util output, and with "u" flags in certutil -L without -n The certs will need Digital Signature, Non-Repudiation and Key Encipherment in the "Certificate Key Usage" extension (visible in pk12util -l and certutil -L -n output). Also, server certs must have "CN=" in the Subject. The server certs will need a valid trust chain leading up to the CA certificate. You can check the trust chain following the "Subject" and "Issuer" lines in the pk12util -l output. CAs should have Certificate Signing and CRL Signing in their "Certificate Key Usage" extension. = Implementation = No additional requirements or changes discovered during the implementation phase. = Feature Managment = === UI === N/A === CLI === The --http_pkcs, --dirsrv_pkcs, --http_pin, --dirsrv_pin options to ipa-server-install and ipa-replica-prepare work again. The --root-ca-file option was added to ipa-server-install. = Major configuration options and enablement = The feature can be installed as detailed above. There is no supported way to enable a CA once a CA-less IPA is installed, or to revert to CA-less from a Dogtag installation. = Replication = When creating a replica file, certificates for that replica must be specified. These must be signed by the CA given as --root-ca-file to the original master (a copy of this CA cert is in /etc/ipa/ca.crt). = Updates and Upgrades = Existing installs are not affected. Upgrading CA-less instances should work normally. = Dependencies = None = External Impact = Tests will need to be written. Documentation will need to be updated. From simo at redhat.com Fri Mar 22 12:19:21 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 22 Mar 2013 08:19:21 -0400 Subject: [Freeipa-devel] DNS update mechanism: news about update authorization In-Reply-To: <514C1E80.8060505@redhat.com> References: <5130BB3A.2070405@redhat.com> <1362148765.2962.139.camel@willson.li.ssimo.org> <5130C5FB.9070205@redhat.com> <514C1E80.8060505@redhat.com> Message-ID: <1363954761.2660.2.camel@willson.li.ssimo.org> On Fri, 2013-03-22 at 10:04 +0100, Petr Spacek wrote: > News from ISC: Evan Hunt replied that ISC can include our patches with > this > functionality. > > I created ticket covering this task: > https://fedorahosted.org/bind-dyndb-ldap/ticket/112 > > Excellent! Thanks a lot. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Mar 22 12:20:58 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 22 Mar 2013 08:20:58 -0400 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <514C1420.3070408@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514B37B5.3050906@redhat.com> <514C1420.3070408@redhat.com> Message-ID: <1363954858.2660.3.camel@willson.li.ssimo.org> On Fri, 2013-03-22 at 09:19 +0100, Martin Kosek wrote: > On 03/21/2013 05:39 PM, Petr Viktorin wrote: > > [...] > > > > another thing: When drafting the feature page, I realized the > > --{http,dirsrv}_pin options are unfortunate. Giving the passwords in command > > line options is unsafe. > > > > I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if > > they're not given. > > > > How is that different from -p DM_PASSWORD and -a ADMIN_PASSWORD? They also > cannot be read from file. I think these options would cause inconsistency with > the rest of our password options in ipa-{server,client,replica}-install. It > also seems as inconvenience to me as you need to prepare this artificial file > before running ipa-server-install... > > I think it would be better to address this consistently in the future with > configuration file instead of options, something like pkispawn uses. Ack, I would defer securing the command line by introducing the ability to pass in a configuration file. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Mar 22 12:32:12 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 22 Mar 2013 08:32:12 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4A35.2060200@redhat.com> References: <514C4A35.2060200@redhat.com> Message-ID: <514C4F4C.3020509@redhat.com> On 03/22/2013 08:10 AM, Petr Viktorin wrote: > The design page for CA-less installation with user-provided SSL certs > is available at http://freeipa.org/page/V3/CA-less_install. I've also > copied it to this mail. > > Does it answer all your questions? > Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. Page misses you as an author. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Mar 22 12:53:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Mar 2013 08:53:10 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4F4C.3020509@redhat.com> References: <514C4A35.2060200@redhat.com> <514C4F4C.3020509@redhat.com> Message-ID: <514C5436.2050501@redhat.com> Dmitri Pal wrote: > On 03/22/2013 08:10 AM, Petr Viktorin wrote: >> The design page for CA-less installation with user-provided SSL certs >> is available at http://freeipa.org/page/V3/CA-less_install. I've also >> copied it to this mail. >> >> Does it answer all your questions? >> > Petr, > > It answers a lot of questions. > However isn't the whole goal to be able to use external CA we do not > have control of as a part of the trust chain? > > I might very well confuse things so bear with me. > > Say I have a public CA X I want to use as the root of my trust chain so > that I do not need to distribute certificates to all my clients. > I can't create a sub CA using externa-ca because it will cost me a lot > of money. > > But I can create a PKI pair for just two servers (HTTP and DS) much > cheaper. Is this the assumption? > Is this really how this works? Is it really easy to get a CRS signed by > a public CA X? Yes, it really can be that easy. Most of the requests in this area have involved using wildcard certs which are slightly more complex to get, but you can get free SSL server certs from StartSSL in less than 30 minutes (providing you can prove you manage the domain you're requesting certs for). I imagine that most will use the same cert for both services, rather than getting separate certs. > Other comments: what are the implications on the certmonger and cert > rotation. I assume certmonger will be turn off. It should then be > documented that we will not track or warn about the cert expiration. Right, we won't be able to leverage certmonger. Users will be on their own to handle renewal. > In future for the KDC pkinit support we will need yet another cert for > the KDC, you do nto need to implement it now but please consider this in > the design. This is a grey area. I don't know if the public CAs will issue this kind of cert. A survey would be required to find out. rob From pviktori at redhat.com Fri Mar 22 13:04:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 14:04:17 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4F4C.3020509@redhat.com> References: <514C4A35.2060200@redhat.com> <514C4F4C.3020509@redhat.com> Message-ID: <514C56D1.2030505@redhat.com> On 03/22/2013 01:32 PM, Dmitri Pal wrote: > On 03/22/2013 08:10 AM, Petr Viktorin wrote: >> The design page for CA-less installation with user-provided SSL certs >> is available at http://freeipa.org/page/V3/CA-less_install. I've also >> copied it to this mail. >> >> Does it answer all your questions? >> > Petr, > > It answers a lot of questions. > However isn't the whole goal to be able to use external CA we do not > have control of as a part of the trust chain? > > I might very well confuse things so bear with me. > > Say I have a public CA X I want to use as the root of my trust chain so > that I do not need to distribute certificates to all my clients. > I can't create a sub CA using externa-ca because it will cost me a lot > of money. > > But I can create a PKI pair for just two servers (HTTP and DS) much > cheaper. Is this the assumption? > Is this really how this works? Is it really easy to get a CRS signed by > a public CA X? IMO one case is that there's a single corporate (not necessarily public) CA, with a policy that it will not sign subordinate CA certs, but it can sign server certs? Your case works too. Yes, server CSRs are easier to get signed than CA ones. (Do you mean "globally trusted" when you say public? With a globally trusted CA you can pretty much impersonate anybody on the Internet.) Someone familiar with certification policies should chime in if you need more details. I've learned a lot about the technical details but policies are another thing. > Other comments: what are the implications on the certmonger and cert > rotation. I assume certmonger will be turn off. It should then be > documented that we will not track or warn about the cert expiration. Yes, Certmonger is not installed, cert rotation must be handled manually. I've udated the page. > In future for the KDC pkinit support we will need yet another cert for > the KDC, you do nto need to implement it now but please consider this in > the design. Added to the page. > Page misses you as an author. Added. I've also added an author section to [[Feature template]] so I remember next time. -- Petr? From pviktori at redhat.com Fri Mar 22 13:22:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 14:22:12 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <514AF66E.2070901@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> Message-ID: <514C5B04.4010101@redhat.com> On 03/21/2013 01:00 PM, Petr Viktorin wrote: > On 03/20/2013 06:34 PM, Dmitri Pal wrote: >> On 03/20/2013 01:28 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/18/2013 10:24 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>> [...] >>>>>> From what I've learned, PKCS#12 files are just a bag of >>>>>> certificates; >>>>>> there are basically no restrictions on their contents. But we assume >>>>>> there's only one cert inside that has a private key, and use that for >>>>>> the server cert. We also pretty much assume that there's one CA >>>>>> cert: if >>>>>> not we pick the first one and trust it as root CA. >>>>>> In short, I think --http_pkcs & friends are too vague for PKCS#12s we >>>>>> don't control; we should have the user name the certs more >>>>>> explicitly. >>>>>> Am I wrong here? Is this the usual way to import server certs? >>>>> >>>>> We can impose a requirement that the CA be included in the PKCS#12 >>>>> files. At least with NSS this happens automatically, I can't recall >>>>> with >>>>> openssl. >>>>> >>>>> Or we can add a new option to pass in the CA bundle in PEM format. >>>> >>>> After thinking about it, this is the way I want to go. It's a bit more >>>> typing for the user, but it reduces the amount of guesswork the >>>> installer needs to do. When deciding who to trust I'd rather be >>>> explicit. >>>> There's also a bit less validation to do and corner cases to watch >>>> out for. >>> >>> Yeah, I think this will simplify things a lot. The only downside is >>> the requirement that both certs come from the same CA, but we have to >>> draw the line somewhere. We can always look into extending things >>> later on as needed. > > Well, if we allow more than one CA in the PEM we can lift this > restriction. More below. > >>>> The root CA certificate will be given by --external-ca-file. The trust >>>> chains for both servers (dirsrv, http) must lead to that CA. This CA >>>> will be trusted, and put in /etc/ipa/ca.crt. >>> >>> Just thinking out loud here, but will that cause any confusion, using >>> an existing option? I don't think so but I may be too used to this. > > I don't think it would, but if we allow more than one CA (possibly in > the future) there is a bigger chance of confusion after all. > I'll use --root-ca-file instead. > >>>> Each PKCS#12 file must contain exactly one cert with a private key. >>>> This >>>> cert will be used for the corresponding server. >>>> Of course you can use the same cert for both servers. >>> >>> I'm ok with that assuming we have an effective way of enforcing it. >>> We'll need to provide some good documentation on how to create, or >>> re-create, a PKCS#12 file to fit this format. > > Yes, enforcing this isn't hard. > Creating is them easy too, it's the default (if not only) option in most > tools. PKCS#12s with more than one cert chain are fairly exotic, from > what I've read some Java tools that can use them but they run into > interoperability problems. > >>>> The --external_ca_file must contain exactly one cert. Certs for any >>>> intermediate CAs must be in the PKCS#12. >>> >>> It would be a lot easier to include all the CAs in a single PEM. This >>> is not unprecedented, and just catting a bunch of certs together into >>> a single file is easy and should not be error-prone. > > I don't want the whole chain in the PEM, because then it's not obvious > which cert(s) to trust. We certainly don't want to give root trust to > every cert in the chain. > So if we allow more CAs here they'd have to be different *root* CAs. > That would allow the server certs to be signed by different CAs, so I > guess we want to do this. > > I don't know of a robust way to know that we have separate root CAs and > not a chain (or several partial chains, etc.), so we'd have to document > this well. > > But more importantly, this would mean we'd have to put several certs in > /etc/ipa/ca.crt, and in LDAP. This is rather invasive so I'd like to > stay out of this for now (but design so it's possible in the future). > >>> I think too we'll need to be able to handle the case of any Built-in >>> certs. There is a chance we will need to simply drop on the floor any >>> CA certs provided because some or all of them are already in NSS (all >>> we really care about for this, I think). > > We still need to put something in /etc/ipa/ca.crt. > I'll investigate what happens when I try to import and trust a cert > that's already trusted, but I don't think it will cause any trouble? > >>>> Does that look good? Does it need a design page? >>> >>> I think a design page would be particularly helpful in this case. I >>> think this is going to be rather complex, and whatever choices we make >>> to simplify things are going to be important. >> >> Yes the design is needed with the content of this thread plus some >> examples of the command line plus some hints & guidance on how to >> prepare files to be in the right format. >> This includes: >> How to check what format the files are? >> How many are there in the file? >> How to extact certs or or combine certs into files? >> How to save in the format we want/need? >> >> Explain why we require all this "more typing". We want to be explicit >> but we also want people to understand why we want them to be explicit. >> This is a very complex area and if we can explain why we ware requiring >> what we are requiring it would go a long way to helping people >> understand what they are doing and what would the implication be. > > OK. I'll just finish this informal discussion first so I don't have to > re-type everything. > Design is now at: http://freeipa.org/page/V3/CA-less_install Patch 199 deferred to https://fedorahosted.org/freeipa/ticket/3529 Updated patches attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0197.2-ipa-server-install-Make-temporary-pin-files-availabl.patch Type: text/x-patch Size: 6412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0198.2-ipa-server-install-Remove-the-selfsign-option.patch Type: text/x-patch Size: 10328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0200.2-Remove-unused-ipapython.certdb.CertDB-class.patch Type: text/x-patch Size: 6266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0201.2-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch Type: text/x-patch Size: 13843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0202.2-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0203.2-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch Type: text/x-patch Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204.2-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 20370 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 22 12:40:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 13:40:19 +0100 Subject: [Freeipa-devel] [PATCH] 270 Load extension.js after UI AMD modules. In-Reply-To: <514B2DA4.1020107@redhat.com> References: <514B2DA4.1020107@redhat.com> Message-ID: <514C5133.1040207@redhat.com> On 03/21/2013 04:56 PM, Petr Vobornik wrote: > This patch is a fix for upcoming ipa-3-1 minor release. > > Loading of extension.js was removed with introduction of AMD modules. This > patch returns the feature to avoid regressions. > > In 3.2 it will be handled differently (multiple plugins). > ACK, works fine. Pushed to ipa-3-1. Martin From mkosek at redhat.com Fri Mar 22 12:39:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 13:39:39 +0100 Subject: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE In-Reply-To: <5114FD48.3070104@redhat.com> References: <5114FD48.3070104@redhat.com> Message-ID: <514C510B.4030804@redhat.com> On 02/08/2013 02:27 PM, Petr Vobornik wrote: > Checkbox for NONE option was added. > > https://fedorahosted.org/freeipa/ticket/3404 > > Patches for master and 3.1 branch attached. > I pushed this version to ipa-3-1 branch only as a hotfix for upcoming 3.1 release so that users can set NONE option via UI. The "right" solution should be chosen and pushed to master branch. Martin From pspacek at redhat.com Fri Mar 22 13:26:30 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Mar 2013 14:26:30 +0100 Subject: [Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL Message-ID: <514C5C06.9090307@redhat.com> Hello, Fix crash caused by 'zonesub' match-type in update ACL. Next patchset will improve overall error handling in ACL processing. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0128-Fix-crash-caused-by-zonesub-match-type-in-update-ACL.patch Type: text/x-patch Size: 2049 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 22 13:42:36 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 14:42:36 +0100 Subject: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling In-Reply-To: <5140A05F.90401@redhat.com> References: <513DFF24.40408@redhat.com> <513EF7F6.9030903@redhat.com> <513F3DE9.2050900@redhat.com> <5140A05F.90401@redhat.com> Message-ID: <514C5FCC.3040406@redhat.com> On 03/13/2013 04:50 PM, Martin Kosek wrote: > On 03/12/2013 03:38 PM, Petr Spacek wrote: >> On 12.3.2013 10:40, Martin Kosek wrote: >>> On 03/11/2013 04:58 PM, Petr Spacek wrote: >>>> Hello list! >>>> >>>> My first patch for FreeIPA is attached :-) >>>> >>>> I managed to add new 389 DS plugin to build system, but the LDAP magic in >>>> installer and updater is too much for my brain. >>>> >>>> Could somebody show me how installer and updater should add new object to >>>> cn=config ? Plugin configuration is static (example is in comments in >>>> ipa_dns.c). >>>> >>>> This patch implements minimal necessary support for idnsSOASerial replication. >>>> I investigating more advanced techniques, but I still see problems with locking >>>> and so on. >>>> >>>> Anyway, this patch should be sufficient for now. >>>> >>>> Commit message: >>>> >>>> Add 389 DS plugin for special idnsSOASerial attribute handling >>>> >>>> Default value "1" is added to replicated idnsZone objects >>>> if idnsSOASerial attribute is missing. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3347 >>>> >>> >>> I did not review the actual plugin yet, I just added a code to configure this >>> plugin during new install and upgrade. Patch attached. >>> >>> >>> Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copy&paste >>> errors: >>> >>> >>> +libipa_uuid_la_LIBADD = \ <<< libipa_uuid?? >>> + $(LDAP_LIBS) \ >>> + $(UUID_LIBS) \ >>> + $(NULL) >>> + >>> >>> +EXTRA_DIST = \ >>> + $(app_DATA) \ <<< not defined, not needed (I will add it in my >>> patch) >>> + $(NULL) >>> + >> >> Fixed version is attached. >> > > Sending a rebased version of my installer/updater patch. > > Martin > ACK for the DS plugin. My patch 384-2 was acked on IRC by Rob. Pushed both to master, ipa-3-1. Thanks, Martin From pspacek at redhat.com Fri Mar 22 13:51:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Mar 2013 14:51:03 +0100 Subject: [Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL In-Reply-To: <514C5C06.9090307@redhat.com> References: <514C5C06.9090307@redhat.com> Message-ID: <514C61C7.5010103@redhat.com> On 22.3.2013 14:26, Petr Spacek wrote: > Hello, > > Fix crash caused by 'zonesub' match-type in update ACL. > > Next patchset will improve overall error handling in ACL processing. I forgot to check return value from dns_name_copy(). Fixed patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0128-2-Fix-crash-caused-by-zonesub-match-type-in-update-ACL.patch Type: text/x-patch Size: 2054 bytes Desc: not available URL: From tbabej at redhat.com Fri Mar 22 14:03:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 Mar 2013 15:03:08 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Use default NETBIOS name in unattended ipa-adtrust-install In-Reply-To: <514B03F9.7070900@redhat.com> References: <514B03F9.7070900@redhat.com> Message-ID: <514C649C.2040103@redhat.com> On 03/21/2013 01:58 PM, Ana Krivokapic wrote: > Hello, > > Unattended ipa-adtrust-install used to fail if --netbios option was not > provided. This patches fixes this, so that instead of failing the > default NETBIOS name is used. > > https://fedorahosted.org/freeipa/ticket/3497 ACK, works as expected. Tomas From mkosek at redhat.com Fri Mar 22 14:03:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 15:03:32 +0100 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <514B3F21.2030103@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> Message-ID: <514C64B4.1020004@redhat.com> On 03/21/2013 06:10 PM, Petr Vobornik wrote: > On 03/21/2013 05:10 PM, Martin Kosek wrote: >> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>> Here's a patch for filtering groups by type. >>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>> >>>> The interface is: >>>>> StrEnum('type?', >>>>> cli_name='type', >>>>> label=_('Type'), >>>>> doc=_('Group type'), >>>>> values=(u'posix', u'normal', u'external'), >>>>> ), >>>> >>>> I have two design questions. >>>> 1. Is --type the right option name? >>> >>> Fine by me, it matches the label and description. >>> >>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>> default group type (when adding group) is posix. Should the name be >>>> something else: `simple`, `plain`, `ordinary`? >>> >>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>> options are 'basic', 'standard', 'regular'. >>> >>>> I didn't want to create an option for each type. IMO it brings more >>>> complexity. >>> >>> Maybe the group-add/mod command should use the same --type option? >>> >>>> https://fedorahosted.org/freeipa/ticket/3483 >>> >>> ACK from me, but maybe others might have some comments. >>> >> >> I am just thinking about if the new API is right. For example, when we add an >> external group, we use ipa group-add --external. But when we search for >> external groups, we suddenly use >> # ipa group-find --type=external >> and not >> # ipa group-find --external >> or >> # ipa group-find --nonposix >> >> Wouldn't that cause confusion? I am looking for same second opinion on this one. >> >> I also did not like "normal" group type very much, maybe we should just call it >> "nonposix"? As that's the option you use when you are creating such group: >> # ipa group-add --nonposix foo >> >> Otherwise, the patch looks good functionally. >> >> Martin >> > > I have to note that external group is also non-posix. Following command is valid: > # ipa group-add foo --desc=a --external --nonposix > > By that logic > # ipa group-find --nonposix > > Would also list external groups. > > I fine with renaming 'normal' to something better (will also require Web UI > change), but it is not 'nonposix'. I think this logic is flawed as well. Then you could say that posix group is also nonposix, because it contains the same objectclasses as nonpoxis group + posixGroup objectclass. "nonposix" is the term we already use (see --nonposix), not something artificial or new, so I would not be afraid of it. Martin From pviktori at redhat.com Fri Mar 22 14:04:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 15:04:47 +0100 Subject: [Freeipa-devel] [PATCH] 396 Fix structured DNS record output In-Reply-To: <514B12A6.6050701@redhat.com> References: <514B12A6.6050701@redhat.com> Message-ID: <514C64FF.1040504@redhat.com> On 03/21/2013 03:01 PM, Martin Kosek wrote: > Recent LDAP refactoring replaced entry_attrs regular dict with > normalized keys (i.e. lowercase) with LDAPEntry instance which keys > may not be normalized. This broke CND command output when > --structured and --all options were used. > > Force lowercase normalization of the LDAPEntry keys in DNS plugin > structured format postprocessing. Also add a missing test for > DNS record structured output. > > https://fedorahosted.org/freeipa/ticket/3526 > ACK, it works well now. The test is critical to prevent future regressions. The planned DNSEntry type-checking will prevent putting dicts in entries; we may need to use plain dicts for the output. The question will be where to convert them from entries. -- Petr? From mkosek at redhat.com Fri Mar 22 14:09:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 15:09:12 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Use default NETBIOS name in unattended ipa-adtrust-install In-Reply-To: <514C649C.2040103@redhat.com> References: <514B03F9.7070900@redhat.com> <514C649C.2040103@redhat.com> Message-ID: <514C6608.3090004@redhat.com> On 03/22/2013 03:03 PM, Tomas Babej wrote: > On 03/21/2013 01:58 PM, Ana Krivokapic wrote: >> Hello, >> >> Unattended ipa-adtrust-install used to fail if --netbios option was not >> provided. This patches fixes this, so that instead of failing the >> default NETBIOS name is used. >> >> https://fedorahosted.org/freeipa/ticket/3497 > ACK, works as expected. > > Tomas > Pushed to master, ipa-3-1. Martin From jcholast at redhat.com Fri Mar 22 14:14:22 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 22 Mar 2013 15:14:22 +0100 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback Message-ID: <514C673E.70800@redhat.com> Hi, this patch enables SASL mapping fallback in IPA DS instance, see . Automated replication recovery and external user mapping is not part of the patch. In order to test this, you need 389-ds-base 1.3.1 packages with patches from including the last patch, which is not yet in git. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-122-Enable-SASL-mapping-fallback.patch Type: text/x-patch Size: 5286 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 22 14:12:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Mar 2013 15:12:42 +0100 Subject: [Freeipa-devel] [PATCH] 396 Fix structured DNS record output In-Reply-To: <514C64FF.1040504@redhat.com> References: <514B12A6.6050701@redhat.com> <514C64FF.1040504@redhat.com> Message-ID: <514C66DA.9030700@redhat.com> On 03/22/2013 03:04 PM, Petr Viktorin wrote: > On 03/21/2013 03:01 PM, Martin Kosek wrote: >> Recent LDAP refactoring replaced entry_attrs regular dict with >> normalized keys (i.e. lowercase) with LDAPEntry instance which keys >> may not be normalized. This broke CND command output when >> --structured and --all options were used. >> >> Force lowercase normalization of the LDAPEntry keys in DNS plugin >> structured format postprocessing. Also add a missing test for >> DNS record structured output. >> >> https://fedorahosted.org/freeipa/ticket/3526 >> > > ACK, it works well now. > > The test is critical to prevent future regressions. The planned DNSEntry > type-checking will prevent putting dicts in entries; we may need to use plain > dicts for the output. The question will be where to convert them from entries. > Right, this use case adds another level of complexity to this future refactoring. Pushed to master. Thanks, Martin From pviktori at redhat.com Fri Mar 22 15:51:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 16:51:12 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <51408790.8040903@redhat.com> References: <51408790.8040903@redhat.com> Message-ID: <514C7DF0.50201@redhat.com> On 03/13/2013 03:05 PM, Tomas Babej wrote: > Hi, > > The following is mentioned in the server log now: > - existence of host entry (if it already does exist) > - missing krbprincipalname and its new value (if there was no > principal name set) > > https://fedorahosted.org/freeipa/ticket/3481 > > Tomas > Here is what I get first trying to re-enroll a wiped host first using admin username/password, and then using a saved keytab. The first succeeded, the second didn't. [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: admin at IDM.LAB.ENG.BRQ.REDHAT.COM: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False, raw=False, version=u'2.54'): SUCCESS [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: cert_request([...], principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', add=True, version=u'2.51'): SUCCESS I can see what's going on, but I don't think the admin would be much wiser seeing this. Would we want so say something like "Host entry for X already exists; joining may fail on the client side" to explain what's going on? ACK from a technical perspective. -- Petr? From pviktori at redhat.com Fri Mar 22 16:02:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 17:02:38 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <514C7DF0.50201@redhat.com> References: <51408790.8040903@redhat.com> <514C7DF0.50201@redhat.com> Message-ID: <514C809E.4020404@redhat.com> On 03/22/2013 04:51 PM, Petr Viktorin wrote: > On 03/13/2013 03:05 PM, Tomas Babej wrote: >> Hi, >> >> The following is mentioned in the server log now: >> - existence of host entry (if it already does exist) >> - missing krbprincipalname and its new value (if there was no >> principal name set) >> >> https://fedorahosted.org/freeipa/ticket/3481 >> >> Tomas >> > > Here is what I get first trying to re-enroll a wiped host first using > admin username/password, and then using a saved keytab. > The first succeeded, the second didn't. Correction: The first failed, the second succeeded. Sorry for the confusion. > > > [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host > entry for vm-084.idm.lab.eng.brq.redhat.com already exists > [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: > admin at IDM.LAB.ENG.BRQ.REDHAT.COM: > join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', > nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS > [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host > entry for vm-084.idm.lab.eng.brq.redhat.com already exists > [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', > nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS > [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, > ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False, > raw=False, version=u'2.54'): SUCCESS > [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > cert_request([...], > principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', > add=True, version=u'2.51'): SUCCESS > > I can see what's going on, but I don't think the admin would be much > wiser seeing this. > Would we want so say something like "Host entry for X already exists; > joining may fail on the client side" to explain what's going on? > > > ACK from a technical perspective. > -- Petr? From tbabej at redhat.com Fri Mar 22 16:10:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 Mar 2013 17:10:20 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <514C7DF0.50201@redhat.com> References: <51408790.8040903@redhat.com> <514C7DF0.50201@redhat.com> Message-ID: <514C826C.70403@redhat.com> On 03/22/2013 04:51 PM, Petr Viktorin wrote: > On 03/13/2013 03:05 PM, Tomas Babej wrote: >> Hi, >> >> The following is mentioned in the server log now: >> - existence of host entry (if it already does exist) >> - missing krbprincipalname and its new value (if there was no >> principal name set) >> >> https://fedorahosted.org/freeipa/ticket/3481 >> >> Tomas >> > > Here is what I get first trying to re-enroll a wiped host first using > admin username/password, and then using a saved keytab. > The first succeeded, the second didn't. > We discussed this with Petr, this is a typo and actually happend in reversed (and correct) order :) > > [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host > entry for vm-084.idm.lab.eng.brq.redhat.com already exists > [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: > admin at IDM.LAB.ENG.BRQ.REDHAT.COM: > join(u'vm-084.idm.lab.eng.brq.redhat.com', > nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', > version=u'2.51'): SUCCESS > [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host > entry for vm-084.idm.lab.eng.brq.redhat.com already exists > [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > join(u'vm-084.idm.lab.eng.brq.redhat.com', > nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', > version=u'2.51'): SUCCESS > [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, > ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False, > raw=False, version=u'2.54'): SUCCESS > [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: > host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: > cert_request([...], > principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', > add=True, version=u'2.51'): SUCCESS > > I can see what's going on, but I don't think the admin would be much > wiser seeing this. > Would we want so say something like "Host entry for X already exists; > joining may fail on the client side" to explain what's going on? > I agree with the proposal. Sending updated patch, here's the diff: diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py index 86d6674..3b66805 100644 --- a/ipaserver/plugins/join.py +++ b/ipaserver/plugins/join.py @@ -101,7 +101,9 @@ class join(Command): dn = attrs_list['dn'] # No error raised so far means that host entry exists - self.log.info('Host entry for %s already exists', hostname) + self.log.info('Host entry for %s already exists, ' + 'joining may fail on the client side ' + 'if not forced', hostname) # If no principal name is set yet we need to try to add # one. > ACK from a technical perspective. > Attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0041-2-Add-logging-to-join-command.patch Type: text/x-patch Size: 3870 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 22 16:34:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Mar 2013 17:34:43 +0100 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation In-Reply-To: <51471B4D.9090101@redhat.com> References: <51471AB7.90108@redhat.com> <51471B4D.9090101@redhat.com> Message-ID: <514C8823.3040802@redhat.com> On 03/18/2013 02:49 PM, Tomas Babej wrote: > On 03/18/2013 02:46 PM, Tomas Babej wrote: >> Hi, >> >> A new option --force-join has been added to ipa-client-install. >> It forces the host enrollment even if the host entry exists. >> Old certificate is revoked, new certificate and ssh key pair >> generated. See the relevant design for the re-enrollment part: >> http://freeipa.org/page/V3/Client_install_using_keytab --force-join is not mentioned there. Since you're adding a new option, you need to document it. >> https://fedorahosted.org/freeipa/ticket/3482 >> >> Tomas > > A-and the patch itself. The patch itself works fine. -- Petr? From tbabej at redhat.com Fri Mar 22 16:40:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 Mar 2013 17:40:46 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <514C826C.70403@redhat.com> References: <51408790.8040903@redhat.com> <514C7DF0.50201@redhat.com> <514C826C.70403@redhat.com> Message-ID: <514C898E.3000807@redhat.com> On 03/22/2013 05:10 PM, Tomas Babej wrote: > On 03/22/2013 04:51 PM, Petr Viktorin wrote: >> On 03/13/2013 03:05 PM, Tomas Babej wrote: >>> Hi, >>> >>> The following is mentioned in the server log now: >>> - existence of host entry (if it already does exist) >>> - missing krbprincipalname and its new value (if there was no >>> principal name set) >>> >>> https://fedorahosted.org/freeipa/ticket/3481 >>> >>> Tomas >>> >> >> Here is what I get first trying to re-enroll a wiped host first using >> admin username/password, and then using a saved keytab. >> The first succeeded, the second didn't. >> > We discussed this with Petr, this is a typo and actually happend in > reversed (and correct) order :) >> >> [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: >> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >> [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: >> admin at IDM.LAB.ENG.BRQ.REDHAT.COM: >> join(u'vm-084.idm.lab.eng.brq.redhat.com', >> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >> version=u'2.51'): SUCCESS >> [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: >> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >> [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: >> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >> join(u'vm-084.idm.lab.eng.brq.redhat.com', >> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >> version=u'2.51'): SUCCESS >> [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: >> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >> host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, >> ipasshpubkey=([...], [...]), rights=False, updatedns=False, >> all=False, raw=False, version=u'2.54'): SUCCESS >> [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: >> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >> cert_request([...], >> principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', >> add=True, version=u'2.51'): SUCCESS >> >> I can see what's going on, but I don't think the admin would be much >> wiser seeing this. >> Would we want so say something like "Host entry for X already exists; >> joining may fail on the client side" to explain what's going on? >> > I agree with the proposal. Sending updated patch, here's the diff: > > diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py > index 86d6674..3b66805 100644 > --- a/ipaserver/plugins/join.py > +++ b/ipaserver/plugins/join.py > @@ -101,7 +101,9 @@ class join(Command): > dn = attrs_list['dn'] > > # No error raised so far means that host entry exists > - self.log.info('Host entry for %s already exists', hostname) > + self.log.info('Host entry for %s already exists, ' > + 'joining may fail on the client side ' > + 'if not forced', hostname) > > # If no principal name is set yet we need to try to add > # one. > > >> ACK from a technical perspective. >> > > Attached. > > Tomas I sent the wrong patch (the previous one) last time. Sorry for the confusion. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0041-2-Add-logging-to-join-command.patch Type: text/x-patch Size: 3983 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 22 16:54:12 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Mar 2013 12:54:12 -0400 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation In-Reply-To: <514C8823.3040802@redhat.com> References: <51471AB7.90108@redhat.com> <51471B4D.9090101@redhat.com> <514C8823.3040802@redhat.com> Message-ID: <514C8CB4.7080901@redhat.com> Petr Viktorin wrote: > On 03/18/2013 02:49 PM, Tomas Babej wrote: >> On 03/18/2013 02:46 PM, Tomas Babej wrote: >>> Hi, >>> >>> A new option --force-join has been added to ipa-client-install. >>> It forces the host enrollment even if the host entry exists. >>> Old certificate is revoked, new certificate and ssh key pair >>> generated. See the relevant design for the re-enrollment part: >>> http://freeipa.org/page/V3/Client_install_using_keytab > > --force-join is not mentioned there. Since you're adding a new option, > you need to document it. What is the difference between force-join and force? All force does is let the install continue if the join fails, so if we're forcing join to succeed too... > >>> https://fedorahosted.org/freeipa/ticket/3482 >>> >>> Tomas >> >> A-and the patch itself. > > The patch itself works fine. > > > From tbabej at redhat.com Fri Mar 22 17:17:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 Mar 2013 18:17:24 +0100 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation In-Reply-To: <514C8CB4.7080901@redhat.com> References: <51471AB7.90108@redhat.com> <51471B4D.9090101@redhat.com> <514C8823.3040802@redhat.com> <514C8CB4.7080901@redhat.com> Message-ID: <514C9224.5070701@redhat.com> On Fri 22 Mar 2013 05:54:12 PM CET, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/18/2013 02:49 PM, Tomas Babej wrote: >>> On 03/18/2013 02:46 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> A new option --force-join has been added to ipa-client-install. >>>> It forces the host enrollment even if the host entry exists. >>>> Old certificate is revoked, new certificate and ssh key pair >>>> generated. See the relevant design for the re-enrollment part: >>>> http://freeipa.org/page/V3/Client_install_using_keytab >> >> --force-join is not mentioned there. Since you're adding a new option, >> you need to document it. > > What is the difference between force-join and force? All force does is > let the install continue if the join fails, so if we're forcing join > to succeed too... > There's more of different behaviour in ipa-client-install with --force option: - in case of install error, changes are not rolled back - in unattended mode, using --force allows to retrieve the CA cert using HTTP - Kerberos and LDAP settings are forced I'm not against merging the options, It just seemed to me as though they provide support for slightly different use cases. Though, man page for ipa-client-install says about --force option the following: "Force the settings even if errors occur". >> >>>> https://fedorahosted.org/freeipa/ticket/3482 >>>> >>>> Tomas >>> >>> A-and the patch itself. >> >> The patch itself works fine. >> >> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Sat Mar 23 04:06:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 23 Mar 2013 00:06:18 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore Message-ID: <514D2A3A.4010909@redhat.com> TL;DR. Sorry. Here is my current progress on backup and restore. I have not documented any of this in the Implementation section of the wiki yet. I've added two new commands, ipa-backup and ipa-restore. The files go into /var/lib/ipa/backup. When doing a restore you should only reference the directory in backup, not the full path. This needs to change, but it is what it is. There are strict limits on what can be restored where. Only exact matching hostnames and versions are allowed right now. We can probably relax the hostname requirement if we're only restoring data, and the version perhaps for only the the first two values (so you can restore a 3.0.0 backup on 3.0.1 but not on 3.1.0). I've done 99.99% of testing in F-18 with a single instance. I did some initial testing in 6.4 so I think the roots are there, but they are untested currently. I spent a lot of time going in circles when doing a restore and getting replication right. I'm open to discussion on this, but my purpose for restoration was to define a new baseline for the IPA installation. It is basically the catastrophic case, where your data is hosed/untested/whatever and you just want to get back to some sane point. Ok, so given that we need to make sure that any other masters don't send us any updates in their changelog when they come back online. So I use a new feature in 1.3.0 to disable the replication agreements. This works really, really well. The only problem is you have to re-enable the agreement in order to re-initialize a master (https://fedorahosted.org/389/ticket/47304). I have the feeling that this leaves a small window where replication can occur and pollute our restored master. I noticed that we do a force_sync() when doing a full re-init. It may be that if we dropped it that would also mitigate this. I did the majority of my testing using an A <-> B <-> C replication topology. This exposed a lot of issues that A <-> B did not. I don't know if it was the third server or having the extra hop, but I hopefully closed a bunch of the corner cases. So what I would do is either a full or a data restore on A. This would break replication on B and C, as expected. So in this scenario A and B are CAs. Then I'd run this on B: # ipa-replica-manage re-initialize --from=A # ipa-csreplica-manage re-initialize --from=A Once that was done I'd run this on C: # ipa-replica-manage re-initialize --from=B The restoration of the dogtag databases was the last thing I did so it isn't super-well tested. I had to move a fair bit of code around. I think it's the sort of thing that will work when the everything goes well but exceptions may not be well-handled. The man pages are just a shel right now, they need a lot of work. It should also be possible to do a full system restore. I tested with: # ipa-server-install ... # # ipa-backup # add one or more users # ipa-server-install --uninstall -U # ipa-restore ipa-full-... The last batch of users should be gone. I did similar tests with the A/B/C set up. I ran the unit tests against it and all was well. I have done zero testing in a Trust environment, though at least some of the files are backed up in the full case. I did some testing with DNS. I did no testing of a master that was down at the time of restoration and then was brought online later, so it never had its replication agreement disabled. I have the feeling it will hose the data. I have some concern over space requirements. Because I tar things up one basically needs double-the backup space in order to do a restore, and a bit more when encrypted. I'm open to suggestions on how to store the data, but we have many files for the 389-ds bak backup and I didn't want to have to encrypt them all. On that note, that I'm doing a db2bak AND a db2ldif backup and currently using the ldif2db for the restore. My original intention was to use db2bak/bak2db in order to retain the changelog, but retaining the changelog is actually a problem if we're restoring to a known state and forcing a re-init. It wouldn't take much to convince me to drop that, which reduces the # of files we have to deal with. I also snuck in a change to the way that replication is displayed. It has long bothered me that we print out an Updating message during replication because it gives no context. I changed it to be more of a progress indicator, using \r to over-write itself and include the # of seconds elapsed. The log files are still readable but I'd hate to see what this looks like in a typescript :-) Finally, sorry about the huge patch. I looked at the incremental commits I had done and I didn't think they'd tell much of a story. I thought about breaking some of the pieces out, but there is a lot of interdependency, so you'd need everything eventually anyway, so here you go, a 70k patch. A quick roadmap is (and I'll skip the obvious): ipa-csreplica-manage: had to move a bunch of code to replication.py so I could use the CSReplicaManager class in ipa-restore. The rest revolves around handling exceptions raised by get_cs_replication_manager() and enabling replication on both sides to do a re-init. replication.py: the changes mentioned to pretty-print updates, a notable change where a re-init automatically enables replication, the new enable/disable code and all the code from ipa-csreplica-manage. ipa-backup/ipa-restore use the new admintool framework. I generally have a good impression of the new framework, but I found myself having to run in debug mode more than I'd have liked in order to discover some types of errors. ipa-backup does all its binds using ldapi. ipa-restore needs the DM password because we need to contact remote servers to enable/disable replication. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1093-backup.patch Type: text/x-patch Size: 70152 bytes Desc: not available URL: From simo at redhat.com Sat Mar 23 21:30:58 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 23 Mar 2013 17:30:58 -0400 Subject: [Freeipa-devel] patchwork: Automatic marking of pushed commits Message-ID: <1364074258.2660.51.camel@willson.li.ssimo.org> Just a quick note to say I have created[1] a patch to allow automatic marking of patches in patchwork when they are pushed. I have pushed the patch on our patchwork instance. It works by pulling the trees on my patchwork server regularly. Currently this is done by a cronjob that pulls the trees every 10 minutes. I've tested it on a sssd patch and it worked, however it failed for the last 2 freeipa patches. My guess is that they have been slightly changed during the push (whitespaces stripping maybe ?). Hopefully this will reduce the work needed to maintain the patchwork status some. As an aside is anyone interested in me adding support to parse comments in the emails to set patch status ? Patchwork already has some basic support but requires setting mail headers which is not immediate in many MUAs, but I could try to add support for parsing out patchwork commands in the body of the email if it is plain text. HTH, Simo. [1] http://patchwork.ozlabs.org/patch/230341/ -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Mon Mar 25 09:24:04 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Mar 2013 10:24:04 +0100 Subject: [Freeipa-devel] [SSSD] patchwork: Automatic marking of pushed commits In-Reply-To: <1364074258.2660.51.camel@willson.li.ssimo.org> References: <1364074258.2660.51.camel@willson.li.ssimo.org> Message-ID: <20130325092404.GA24382@hendrix.brq.redhat.com> On Sat, Mar 23, 2013 at 05:30:58PM -0400, Simo Sorce wrote: > Just a quick note to say I have created[1] a patch to allow automatic > marking of patches in patchwork when they are pushed. > > I have pushed the patch on our patchwork instance. > It works by pulling the trees on my patchwork server regularly. > Currently this is done by a cronjob that pulls the trees every 10 > minutes. > > I've tested it on a sssd patch and it worked, however it failed for the > last 2 freeipa patches. My guess is that they have been slightly changed > during the push (whitespaces stripping maybe ?). > > Hopefully this will reduce the work needed to maintain the patchwork > status some. > > As an aside is anyone interested in me adding support to parse comments > in the emails to set patch status ? > > Patchwork already has some basic support but requires setting mail > headers which is not immediate in many MUAs, but I could try to add > support for parsing out patchwork commands in the body of the email if > it is plain text. This would be nice even if the detection worked for 80% of the cases. I think a simple regex would cover most of the responses. From pviktori at redhat.com Mon Mar 25 09:30:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Mar 2013 10:30:46 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <514C898E.3000807@redhat.com> References: <51408790.8040903@redhat.com> <514C7DF0.50201@redhat.com> <514C826C.70403@redhat.com> <514C898E.3000807@redhat.com> Message-ID: <51501946.5000405@redhat.com> On 03/22/2013 05:40 PM, Tomas Babej wrote: > On 03/22/2013 05:10 PM, Tomas Babej wrote: >> On 03/22/2013 04:51 PM, Petr Viktorin wrote: >>> On 03/13/2013 03:05 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> The following is mentioned in the server log now: >>>> - existence of host entry (if it already does exist) >>>> - missing krbprincipalname and its new value (if there was no >>>> principal name set) >>>> >>>> https://fedorahosted.org/freeipa/ticket/3481 >>>> >>>> Tomas >>>> >>> >>> Here is what I get first trying to re-enroll a wiped host first using >>> admin username/password, and then using a saved keytab. >>> The first succeeded, the second didn't. >>> >> We discussed this with Petr, this is a typo and actually happend in >> reversed (and correct) order :) >>> >>> [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: >>> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >>> [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: >>> admin at IDM.LAB.ENG.BRQ.REDHAT.COM: >>> join(u'vm-084.idm.lab.eng.brq.redhat.com', >>> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >>> version=u'2.51'): SUCCESS >>> [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: >>> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >>> [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: >>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>> join(u'vm-084.idm.lab.eng.brq.redhat.com', >>> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >>> version=u'2.51'): SUCCESS >>> [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: >>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>> host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, >>> ipasshpubkey=([...], [...]), rights=False, updatedns=False, >>> all=False, raw=False, version=u'2.54'): SUCCESS >>> [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: >>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>> cert_request([...], >>> principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', >>> add=True, version=u'2.51'): SUCCESS >>> >>> I can see what's going on, but I don't think the admin would be much >>> wiser seeing this. >>> Would we want so say something like "Host entry for X already exists; >>> joining may fail on the client side" to explain what's going on? >>> >> I agree with the proposal. Sending updated patch, here's the diff: >> >> diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py >> index 86d6674..3b66805 100644 >> --- a/ipaserver/plugins/join.py >> +++ b/ipaserver/plugins/join.py >> @@ -101,7 +101,9 @@ class join(Command): >> dn = attrs_list['dn'] >> >> # No error raised so far means that host entry exists >> - self.log.info('Host entry for %s already exists', hostname) >> + self.log.info('Host entry for %s already exists, ' >> + 'joining may fail on the client side ' >> + 'if not forced', hostname) >> >> # If no principal name is set yet we need to try to add >> # one. >> >> >>> ACK from a technical perspective. >>> >> >> Attached. >> >> Tomas > > I sent the wrong patch (the previous one) last time. Sorry for the > confusion. > > Tomas ACK -- Petr? From mkosek at redhat.com Mon Mar 25 09:55:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Mar 2013 10:55:01 +0100 Subject: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation In-Reply-To: <514C9224.5070701@redhat.com> References: <51471AB7.90108@redhat.com> <51471B4D.9090101@redhat.com> <514C8823.3040802@redhat.com> <514C8CB4.7080901@redhat.com> <514C9224.5070701@redhat.com> Message-ID: <51501EF5.4020000@redhat.com> On 03/22/2013 06:17 PM, Tomas Babej wrote: > On Fri 22 Mar 2013 05:54:12 PM CET, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/18/2013 02:49 PM, Tomas Babej wrote: >>>> On 03/18/2013 02:46 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> A new option --force-join has been added to ipa-client-install. >>>>> It forces the host enrollment even if the host entry exists. >>>>> Old certificate is revoked, new certificate and ssh key pair >>>>> generated. See the relevant design for the re-enrollment part: >>>>> http://freeipa.org/page/V3/Client_install_using_keytab >>> >>> --force-join is not mentioned there. Since you're adding a new option, >>> you need to document it. >> >> What is the difference between force-join and force? All force does is >> let the install continue if the join fails, so if we're forcing join >> to succeed too... >> > > There's more of different behaviour in ipa-client-install with --force option: > - in case of install error, changes are not rolled back > - in unattended mode, using --force allows to retrieve the CA cert using HTTP > - Kerberos and LDAP settings are forced > > I'm not against merging the options, It just seemed to me as though they provide > support for slightly different use cases. > > Though, man page for ipa-client-install says about --force option the following: > "Force the settings even if errors occur". > That's true, I think that host reenrollment is quite specific action that deserves special force flag. Additionally, people reenrolling a client may not want the changes above. Thus, I am also for special force flag for this operation. Since Petr already checked the patch works, I am giving second ACK. Pushed to master (as agreed with Tomas, I just updated link to wiki page in commit message). Martin From pspacek at redhat.com Mon Mar 25 09:56:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 10:56:05 +0100 Subject: [Freeipa-devel] [PATCH 0129] Harden update-policy processing Message-ID: <51501F35.2010505@redhat.com> Hello, Harden update-policy processing. https://fedorahosted.org/bind-dyndb-ldap/ticket/111 This patch should prevent crashes similar to 'zonesub' problem described in the ticket #111. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0129-Harden-update-policy-processing.patch Type: text/x-patch Size: 2618 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 25 10:01:48 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Mar 2013 11:01:48 +0100 Subject: [Freeipa-devel] [PATCH 0041] Add logging to join command In-Reply-To: <51501946.5000405@redhat.com> References: <51408790.8040903@redhat.com> <514C7DF0.50201@redhat.com> <514C826C.70403@redhat.com> <514C898E.3000807@redhat.com> <51501946.5000405@redhat.com> Message-ID: <5150208C.7030008@redhat.com> On 03/25/2013 10:30 AM, Petr Viktorin wrote: > On 03/22/2013 05:40 PM, Tomas Babej wrote: >> On 03/22/2013 05:10 PM, Tomas Babej wrote: >>> On 03/22/2013 04:51 PM, Petr Viktorin wrote: >>>> On 03/13/2013 03:05 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> The following is mentioned in the server log now: >>>>> - existence of host entry (if it already does exist) >>>>> - missing krbprincipalname and its new value (if there was no >>>>> principal name set) >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3481 >>>>> >>>>> Tomas >>>>> >>>> >>>> Here is what I get first trying to re-enroll a wiped host first using >>>> admin username/password, and then using a saved keytab. >>>> The first succeeded, the second didn't. >>>> >>> We discussed this with Petr, this is a typo and actually happend in >>> reversed (and correct) order :) >>>> >>>> [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: >>>> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >>>> [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: >>>> admin at IDM.LAB.ENG.BRQ.REDHAT.COM: >>>> join(u'vm-084.idm.lab.eng.brq.redhat.com', >>>> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >>>> version=u'2.51'): SUCCESS >>>> [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: >>>> Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists >>>> [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: >>>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>>> join(u'vm-084.idm.lab.eng.brq.redhat.com', >>>> nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', >>>> version=u'2.51'): SUCCESS >>>> [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: >>>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>>> host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, >>>> ipasshpubkey=([...], [...]), rights=False, updatedns=False, >>>> all=False, raw=False, version=u'2.54'): SUCCESS >>>> [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: >>>> host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM: >>>> cert_request([...], >>>> principal=u'host/vm-084.idm.lab.eng.brq.redhat.com at IDM.LAB.ENG.BRQ.REDHAT.COM', >>>> >>>> add=True, version=u'2.51'): SUCCESS >>>> >>>> I can see what's going on, but I don't think the admin would be much >>>> wiser seeing this. >>>> Would we want so say something like "Host entry for X already exists; >>>> joining may fail on the client side" to explain what's going on? >>>> >>> I agree with the proposal. Sending updated patch, here's the diff: >>> >>> diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py >>> index 86d6674..3b66805 100644 >>> --- a/ipaserver/plugins/join.py >>> +++ b/ipaserver/plugins/join.py >>> @@ -101,7 +101,9 @@ class join(Command): >>> dn = attrs_list['dn'] >>> >>> # No error raised so far means that host entry exists >>> - self.log.info('Host entry for %s already exists', hostname) >>> + self.log.info('Host entry for %s already exists, ' >>> + 'joining may fail on the client side ' >>> + 'if not forced', hostname) >>> >>> # If no principal name is set yet we need to try to add >>> # one. >>> >>> >>>> ACK from a technical perspective. >>>> >>> >>> Attached. >>> >>> Tomas >> >> I sent the wrong patch (the previous one) last time. Sorry for the >> confusion. >> >> Tomas > > ACK > Pushed to master, ipa-3-1. Martin From atkac at redhat.com Mon Mar 25 10:17:05 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 11:17:05 +0100 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <51361C3A.6020606@redhat.com> References: <5072E75E.1050305@redhat.com> <20121009112157.GF2593@redhat.com> <50742B7B.2070205@redhat.com> <507BEF22.8070708@redhat.com> <51361C3A.6020606@redhat.com> Message-ID: <20130325101705.GA1897@redhat.com> On Tue, Mar 05, 2013 at 05:24:26PM +0100, Petr Spacek wrote: > On 15.10.2012 13:10, Petr Spacek wrote: > >On 10/09/2012 03:49 PM, Petr Spacek wrote: > >>On 10/09/2012 01:21 PM, Adam Tkac wrote: > >>>On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: > >>>>Hello, > >>>> > >>>> Use automatic connection management in LDAP modification code to > >>>> prevent potential deadlock. > >>>> > >>>> Without this patch the plugin will deadlock when modify_ldap_common() > >>>> is called with PTR synchronization enabled and only single > >>>> connection is available in the connection pool. > >>> > >>>Nack > >>> > >>>If I read the patch correctly, it leaves unused ldap_conn parameters in > >>>ldap_modify_do() and modify_soa_record() functions. > >>> > >>>Those params are always NULL so they can be safely removed. Please also remove > >>>the "autoconn" variable from ldap_modify_do() > >> > >>My intent was to keep the same connection management abilities as are in > >>ldap_query(): You can avoid repetitive ldap_pool_get/putconnection() calls by > >>passing connection via parameter. > >> > >>I can remove it if it isn't worth. (Actually *_modify_*() functions do not use > >>this capability now.) > > > >I forgot to send the patch after our discussion on IRC. Attached patch removes > >unused parameters. > > Patch rebased on top of master branch. No functional changes. Ack. > From 9af7dae883b6f014fdcb5aee8394ad5d8f87aab9 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 5 Mar 2013 17:10:06 +0100 > Subject: [PATCH] Use automatic connection management in LDAP modification > code to prevent potential deadlock. > > Without this patch the plugin could deadlock when modify_ldap_common() > is called with PTR synchronization enabled and only single > connection is available in the connection pool. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 54 +++++++++++++++++++++++------------------------------- > 1 file changed, 23 insertions(+), 31 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index c5c8245ecd664f038781fc98f4b5756ceff87c2e..3ed4a44e043ce98a5503ad351f4e8a91116d5ac3 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -312,8 +312,7 @@ static void ldap_query_free(isc_boolean_t prepare_reuse, ldap_qresult_t **ldap_q > > /* Functions for writing to LDAP. */ > static isc_result_t ldap_modify_do(ldap_instance_t *ldap_inst, > - ldap_connection_t *ldap_conn, const char *dn, LDAPMod **mods, > - isc_boolean_t delete_node); > + const char *dn, LDAPMod **mods, isc_boolean_t delete_node); > static isc_result_t ldap_rdttl_to_ldapmod(isc_mem_t *mctx, > dns_rdatalist_t *rdlist, LDAPMod **changep); > static isc_result_t ldap_rdatalist_to_ldapmod(isc_mem_t *mctx, > @@ -2472,31 +2471,19 @@ reconnect: > } > > static isc_result_t > -ldap_modify_do(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > - const char *dn, LDAPMod **mods, isc_boolean_t delete_node) > +ldap_modify_do(ldap_instance_t *ldap_inst, const char *dn, LDAPMod **mods, > + isc_boolean_t delete_node) > { > int ret; > int err_code; > const char *operation_str; > isc_result_t result; > - isc_boolean_t autoconn = (ldap_conn == NULL); > + ldap_connection_t *ldap_conn = NULL; > > REQUIRE(dn != NULL); > REQUIRE(mods != NULL); > REQUIRE(ldap_inst != NULL); > > - if (autoconn) > - CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - > - if (ldap_conn->handle == NULL) { > - /* > - * handle can be NULL when the first connection to LDAP wasn't > - * successful > - * TODO: handle this case inside ldap_pool_getconnection()? > - */ > - CHECK(ldap_connect(ldap_inst, ldap_conn, ISC_FALSE)); > - } > - > /* Any mod_op can be ORed with LDAP_MOD_BVALUES. */ > if ((mods[0]->mod_op & ~LDAP_MOD_BVALUES) == LDAP_MOD_ADD) > operation_str = "modifying(add)"; > @@ -2507,7 +2494,17 @@ ldap_modify_do(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > else { > operation_str = "modifying(unknown operation)"; > log_bug("%s: 0x%x", operation_str, mods[0]->mod_op); > - CHECK(ISC_R_NOTIMPLEMENTED); > + CLEANUP_WITH(ISC_R_NOTIMPLEMENTED); > + } > + > + CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > + if (ldap_conn->handle == NULL) { > + /* > + * handle can be NULL when the first connection to LDAP wasn't > + * successful > + * TODO: handle this case inside ldap_pool_getconnection()? > + */ > + CHECK(ldap_connect(ldap_inst, ldap_conn, ISC_FALSE)); > } > > if (delete_node) { > @@ -2569,8 +2566,7 @@ ldap_modify_do(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > result = ISC_R_FAILURE; > } > cleanup: > - if (autoconn) > - ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > + ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > > return result; > } > @@ -2738,8 +2734,8 @@ cleanup: > * refresh, retry, expire and minimum attributes for each SOA record. > */ > static isc_result_t > -modify_soa_record(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > - const char *zone_dn, dns_rdata_t *rdata) > +modify_soa_record(ldap_instance_t *ldap_inst, const char *zone_dn, > + dns_rdata_t *rdata) > { > isc_result_t result; > dns_rdata_soa_t soa; > @@ -2772,7 +2768,7 @@ modify_soa_record(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > > dns_rdata_freestruct((void *)&soa); > > - result = ldap_modify_do(ldap_inst, ldap_conn, zone_dn, changep, ISC_FALSE); > + result = ldap_modify_do(ldap_inst, zone_dn, changep, ISC_FALSE); > > cleanup: > return result; > @@ -2787,7 +2783,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > { > isc_result_t result; > isc_mem_t *mctx = ldap_inst->mctx; > - ldap_connection_t *ldap_conn = NULL; > ld_string_t *owner_dn = NULL; > LDAPMod *change[3] = { NULL }; > LDAPMod *change_ptr = NULL; > @@ -2846,10 +2841,8 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > CHECK(zr_get_zone_cache(ldap_inst->zone_register, owner, &cache)); > CHECK(discard_from_cache(cache, owner)); > > - CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - > if (rdlist->type == dns_rdatatype_soa) { > - result = modify_soa_record(ldap_inst, ldap_conn, str_buf(owner_dn), > + result = modify_soa_record(ldap_inst, str_buf(owner_dn), > HEAD(rdlist->rdata)); > goto cleanup; > } > @@ -2860,7 +2853,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > CHECK(ldap_rdttl_to_ldapmod(mctx, rdlist, &change[1])); > } > > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn), change, delete_node)); > + CHECK(ldap_modify_do(ldap_inst, str_buf(owner_dn), change, delete_node)); > > /* Keep the PTR of corresponding A/AAAA record synchronized. */ > if (rdlist->type == dns_rdatatype_a || rdlist->type == dns_rdatatype_aaaa) { > @@ -3018,16 +3011,15 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > change_ptr = NULL; > > /* Modify PTR record. */ > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), > + CHECK(ldap_modify_do(ldap_inst, str_buf(owner_dn_ptr), > change, delete_node)); > cache = NULL; > CHECK(zr_get_zone_cache(ldap_inst->zone_register, > dns_fixedname_name(&ptr_name), &cache)); > CHECK(discard_from_cache(cache, dns_fixedname_name(&ptr_name))); > } > > cleanup: > - ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > str_destroy(&owner_dn_ptr); > str_destroy(&owner_dn); > str_destroy(&str_ptr); > @@ -3303,7 +3295,7 @@ soa_serial_increment(isc_mem_t *mctx, ldap_instance_t *inst, > dns_soa_setserial(new_serial, soa_rdata); > > /* write the new serial back to DB */ > - CHECK(modify_soa_record(inst, NULL, str_buf(zone_dn), soa_rdata)); > + CHECK(modify_soa_record(inst, str_buf(zone_dn), soa_rdata)); > CHECK(zr_get_zone_cache(inst->zone_register, zone_name, &cache)); > CHECK(discard_from_cache(cache, zone_name)); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 10:25:19 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 11:25:19 +0100 Subject: [Freeipa-devel] [PATCH 0121] Fix crash during invalid zone reload process In-Reply-To: <514B08CE.7080708@redhat.com> References: <514B08CE.7080708@redhat.com> Message-ID: <20130325102519.GB1897@redhat.com> On Thu, Mar 21, 2013 at 02:19:10PM +0100, Petr Spacek wrote: > Hello, > > Fix crash during invalid zone reload process. > > This bug was created during settings refactoring and is present only > in master, not in v2 branch. Ack > From 79594a484f30c6677dd901e7f8285719e31bab6b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 21 Mar 2013 14:13:57 +0100 > Subject: [PATCH] Fix crash during invalid zone reload process. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 6f21b8407e8c01a98ae5b6f916c964432c651fd5..7ac5ceda26cd9d734f94d9195388db879be1959e 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3503,7 +3503,7 @@ update_record(isc_task_t *task, isc_event_t *event) > ldapdb_rdatalist_t rdatalist; > > /* Convert domain name from text to struct dns_name_t. */ > - settings_set_t *zone_settings = NULL; > + settings_set_t *zone_settings; > dns_name_t name; > dns_name_t origin; > dns_name_t prevname; > @@ -3569,6 +3569,7 @@ update_restart: > > /* Do not bump serial during initial database dump. */ > if (PSEARCH_ANY(pevent->chgtype)) { > + zone_settings = NULL; > CHECK(zr_get_zone_settings(inst->zone_register, &origin, &zone_settings)); > CHECK(setting_get_bool("serial_autoincrement", zone_settings, > &serial_autoincrement)); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Mon Mar 25 11:13:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 12:13:26 +0100 Subject: [Freeipa-devel] [PATCH 0130] Add support for 'external' match-type in update-policy Message-ID: <51503156.1080203@redhat.com> Hello, Add support for 'external' match-type in update-policy. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0130-Add-support-for-external-match-type-in-update-policy.patch Type: text/x-patch Size: 862 bytes Desc: not available URL: From pvoborni at redhat.com Mon Mar 25 11:46:04 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 25 Mar 2013 12:46:04 +0100 Subject: [Freeipa-devel] [PATCH] 271, 272 Added Web UI support for service PAC type option: NONE In-Reply-To: <5143A503.4020409@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> <5138980F.8070205@redhat.com> <5143A503.4020409@redhat.com> Message-ID: <515038FC.4050307@redhat.com> On 03/15/2013 11:47 PM, Endi Sukma Dewata wrote: > On 3/7/2013 7:37 AM, Petr Vobornik wrote: >>> Ideally it should be generic enough to combine any widgets. This might >>> be a common scenario somewhere else: >>> >>> Something: ( ) Option 1 >>> ( ) Option 2 >>> (o) Other: [something else ] >> >> This design has a flaw: >> https://fedorahosted.org/freeipa/ticket/3404#comment:5 > > I think this one makes the most sense to me: > > PAC Types: ( ) Inherited setting: ... ... > (o) Override inherited setting > [ ] MS-PAC > [ ] PAD > > It looks like the NONE option is identical to not using the inherited > values but also not selecting any new values, so we don't actually need > a separate radio button for NONE because it can be represented by the > above UI without redundancy. We just need better labels to explain the > radio buttons. Maybe someone can come up with better labels than these. > >> I implemented following design: >> https://fedorahosted.org/freeipa/ticket/3404#comment:7 > > It works but I can't imagine how it would look if we have more than two > PAC types. I don't think we want to list every possible combinations. > The above design is more future proof. You are right. > >> Patch attached (255-1). >> >> I have a dilemma. I practically implemented the previous design (and >> then I've found the flaw..). Patches attached as wip-fre... I wonder if >> we can use it somehow or we should ditch it. > Reimplemented ^^ to match your proposal. Attaching as patches with new numbers (271,272) as they don't have much common with the original patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0271-Nestable-checkbox-radio-widget.patch Type: text/x-patch Size: 23769 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0272-Added-Web-UI-support-for-service-PAC-type-option-NON.patch Type: text/x-patch Size: 4509 bytes Desc: not available URL: From pspacek at redhat.com Mon Mar 25 13:40:56 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 14:40:56 +0100 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <20130325101705.GA1897@redhat.com> References: <5072E75E.1050305@redhat.com> <20121009112157.GF2593@redhat.com> <50742B7B.2070205@redhat.com> <507BEF22.8070708@redhat.com> <51361C3A.6020606@redhat.com> <20130325101705.GA1897@redhat.com> Message-ID: <515053E8.1050002@redhat.com> On 25.3.2013 11:17, Adam Tkac wrote: > On Tue, Mar 05, 2013 at 05:24:26PM +0100, Petr Spacek wrote: >> >On 15.10.2012 13:10, Petr Spacek wrote: >>> > >On 10/09/2012 03:49 PM, Petr Spacek wrote: >>>> > >>On 10/09/2012 01:21 PM, Adam Tkac wrote: >>>>> > >>>On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: >>>>>> > >>>>Hello, >>>>>> > >>>> >>>>>> > >>>> Use automatic connection management in LDAP modification code to >>>>>> > >>>> prevent potential deadlock. >>>>>> > >>>> >>>>>> > >>>> Without this patch the plugin will deadlock when modify_ldap_common() >>>>>> > >>>> is called with PTR synchronization enabled and only single >>>>>> > >>>> connection is available in the connection pool. >>>>> > >>> >>>>> > >>>Nack >>>>> > >>> >>>>> > >>>If I read the patch correctly, it leaves unused ldap_conn parameters in >>>>> > >>>ldap_modify_do() and modify_soa_record() functions. >>>>> > >>> >>>>> > >>>Those params are always NULL so they can be safely removed. Please also remove >>>>> > >>>the "autoconn" variable from ldap_modify_do() >>>> > >> >>>> > >>My intent was to keep the same connection management abilities as are in >>>> > >>ldap_query(): You can avoid repetitive ldap_pool_get/putconnection() calls by >>>> > >>passing connection via parameter. >>>> > >> >>>> > >>I can remove it if it isn't worth. (Actually *_modify_*() functions do not use >>>> > >>this capability now.) >>> > > >>> > >I forgot to send the patch after our discussion on IRC. Attached patch removes >>> > >unused parameters. >> > >> >Patch rebased on top of master branch. No functional changes. > Ack. Pushed to master: 7b8ebb8cf459991d20297913b9abb756981201bb This patch fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/113 in master branch, v2 branch needs a bit different approach. -- Petr^2 Spacek From mkosek at redhat.com Mon Mar 25 13:41:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Mar 2013 14:41:46 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <5146FCBB.4000500@redhat.com> References: <5146FCBB.4000500@redhat.com> Message-ID: <5150541A.9030105@redhat.com> On 03/18/2013 12:38 PM, Jan Cholasta wrote: > Hi, > > this patch implements . > > Because the design is not finished yet, this is a minimal implementation - it > uses the krbTicketFlags attribute directly (which means no delegation of rights > to modify specific flags to specific admins) and there is no support for > per-service type default values. > > Honza > > I checked what you have already and this is what I found: 1) Internal error if I try to remove krbticketflags via *attr functions: # ipa service-add foo/`hostname` --setattr=krbticketflags=None ipa: ERROR: an internal error has occurred # ipa service-add foo/`hostname` ------------------------------------------------------------------------ Added service "foo/vm-037.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM" ------------------------------------------------------------------------ # ipa service-mod foo/`hostname` --setattr=krbticketflags=None ipa: ERROR: an internal error has occurred 2) The RFE page needs updating, it does not reflect current reality. AFAIU, the only thing that's left to be decided is the granularity of the ACIs used to control this flag. Otherwise, the patch works fine. Martin From atkac at redhat.com Mon Mar 25 14:49:57 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 15:49:57 +0100 Subject: [Freeipa-devel] [PATCH 0120] Fix automatic reloading of invalid zone after each change in zone data In-Reply-To: <514AFF52.1080305@redhat.com> References: <514AFF52.1080305@redhat.com> Message-ID: <20130325144956.GA12282@redhat.com> On Thu, Mar 21, 2013 at 01:38:42PM +0100, Petr Spacek wrote: > Hello, > > Fix automatic reloading of invalid zone after each change in zone data. > > Reload wasn't done when serial_autoincrement feature was disabled. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > Ack. But before the push, please add explicit comment to ldap_get_zone_serial() call that the only reason of this call is to return ISC_R_SUCCESS in case the zone is loaded or DNS_R_NOTLOADED in case it isn't. I studied the patch for more then 15 minutes before I figured this. Thanks, Adam > From 1700a5d7dbf6c36ce235091a449e13a5e18fbb8b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 21 Mar 2013 13:35:17 +0100 > Subject: [PATCH] Fix automatic reloading of invalid zone after each change in > zone data. > > Reload wasn't done when serial_autoincrement feature was disabled. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index c10a23929c1536961a37d18e68d0669aa26539de..6f21b8407e8c01a98ae5b6f916c964432c651fd5 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3572,8 +3572,15 @@ update_restart: > CHECK(zr_get_zone_settings(inst->zone_register, &origin, &zone_settings)); > CHECK(setting_get_bool("serial_autoincrement", zone_settings, > &serial_autoincrement)); > + > + /* Serial autoincrement does zone state check implicitly. > + * Do explicit state check if serial autoincrement is disabled. */ > if (serial_autoincrement) > CHECK(soa_serial_increment(mctx, inst, &origin)); > + else { > + isc_uint32_t dummy; > + CHECK(ldap_get_zone_serial(inst, &origin, &dummy)); > + } > } > > cleanup: > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 14:56:18 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 15:56:18 +0100 Subject: [Freeipa-devel] [PATCH 0122] Log successful zone reload after record change. In-Reply-To: <514B0EE7.2040109@redhat.com> References: <514B0EE7.2040109@redhat.com> Message-ID: <20130325145618.GB12282@redhat.com> On Thu, Mar 21, 2013 at 02:45:11PM +0100, Petr Spacek wrote: > Hello, > > Log successful zone reload after record change. > > This should be last piece of > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 Ack > From 06c414c2922bb09c18afd9fadc52b2b0f4529f90 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 21 Mar 2013 14:43:56 +0100 > Subject: [PATCH] Log successful zone reload after record change. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 7ac5ceda26cd9d734f94d9195388db879be1959e..72105e6093cea7b0bc9fdfc96229afded7650dce 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3494,6 +3494,7 @@ update_record(isc_task_t *task, isc_event_t *event) > dns_zone_t *zone_ptr = NULL; > isc_boolean_t zone_found = ISC_FALSE; > isc_boolean_t zone_reloaded = ISC_FALSE; > + isc_uint32_t serial; > mctx = pevent->mctx; > > UNUSED(task); > @@ -3579,8 +3580,7 @@ update_restart: > if (serial_autoincrement) > CHECK(soa_serial_increment(mctx, inst, &origin)); > else { > - isc_uint32_t dummy; > - CHECK(ldap_get_zone_serial(inst, &origin, &dummy)); > + CHECK(ldap_get_zone_serial(inst, &origin, &serial)); > } > } > > @@ -3594,16 +3594,23 @@ cleanup: > result = zr_get_zone_ptr(inst->zone_register, &origin, &zone_ptr); > if (result == ISC_R_SUCCESS) > result = dns_zone_load(zone_ptr); > - if (zone_ptr != NULL) > - dns_zone_detach(&zone_ptr); > > if (result == ISC_R_SUCCESS || result == DNS_R_UPTODATE || > result == DNS_R_DYNAMIC || result == DNS_R_CONTINUE) { > /* zone reload succeeded, fire current event again */ > log_debug(1, "restarting update_record after zone reload " > "caused by change in '%s'", pevent->dn); > zone_reloaded = ISC_TRUE; > - goto update_restart; > + result = dns_zone_getserial2(zone_ptr, &serial); > + if (result == ISC_R_SUCCESS) { > + dns_zone_log(zone_ptr, ISC_LOG_INFO, > + "reloaded serial %u", serial); > + goto update_restart; > + } else { > + dns_zone_log(zone_ptr, ISC_LOG_ERROR, > + "could not get serial after " > + "reload"); > + } > } else { > log_error_r("unable to reload invalid zone; " > "reload triggered by change in '%s'", > @@ -3617,6 +3624,8 @@ cleanup: > pevent->dn, pevent->chgtype); > } > > + if (zone_ptr != NULL) > + dns_zone_detach(&zone_ptr); > if (dns_name_dynamic(&name)) > dns_name_free(&name, inst->mctx); > if (dns_name_dynamic(&prevname)) > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 14:56:40 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 15:56:40 +0100 Subject: [Freeipa-devel] [PATCH 0127] Remove orphaned function declaration from ldap_helper.h In-Reply-To: <514C4934.1000105@redhat.com> References: <514C4934.1000105@redhat.com> Message-ID: <20130325145639.GC12282@redhat.com> On Fri, Mar 22, 2013 at 01:06:12PM +0100, Petr Spacek wrote: > Hello, > > Remove orphaned function declaration from ldap_helper.h. > Ack > From 9129f3963c8a7d603c02c5a8ea1ce3f08182541f Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 13:04:29 +0100 > Subject: [PATCH] Remove orphaned function declaration from ldap_helper.h. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/src/ldap_helper.h b/src/ldap_helper.h > index fe54687fa1e8ec16d83105e08e1a17cdec68614e..2eb7c7600f45542d92f01dbc878f4862606ade8a 100644 > --- a/src/ldap_helper.h > +++ b/src/ldap_helper.h > @@ -94,9 +94,6 @@ isc_result_t write_to_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_result_t remove_from_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > dns_rdatalist_t *rdlist, isc_boolean_t delete_node); > > -/* Get cache associated with ldap_inst */ > -ldap_cache_t *ldap_instance_getcache(ldap_instance_t *ldap_inst); > - > settings_set_t * ldap_instance_getsettings_local(ldap_instance_t *ldap_inst); > > #endif /* !_LD_LDAP_HELPER_H_ */ > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 15:08:43 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 16:08:43 +0100 Subject: [Freeipa-devel] [PATCH 0117] Fix crash caused by invalid query/transfer policy In-Reply-To: <5134A01A.7050500@redhat.com> References: <5134A01A.7050500@redhat.com> Message-ID: <20130325150842.GA12895@redhat.com> On Mon, Mar 04, 2013 at 02:22:34PM +0100, Petr Spacek wrote: > Hello, > > Fix crash caused by invalid query/transfer policy. > > Please double-check correctness. The ISC parser is really complex beast! > > Thank you. Ack > From 41061726684211924e453f74d1db3bec6c2e32d6 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 4 Mar 2013 14:20:56 +0100 > Subject: [PATCH] Fix crash caused by invalid query/transfer policy. > > Signed-off-by: Petr Spacek > --- > src/acl.c | 45 +++++++++++++++++++++++++++++++++++---------- > 1 file changed, 35 insertions(+), 10 deletions(-) > > diff --git a/src/acl.c b/src/acl.c > index f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a..076a50375ae1fd132c143aa96379f7c80cc78cb8 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -71,6 +71,19 @@ static cfg_type_t *allow_query; > static cfg_type_t *allow_transfer; > static cfg_type_t *forwarders; > > +/* Following definitions are necessary for context ("map" configuration object) > + * required during ACL parsing. */ > +static cfg_clausedef_t * empty_map_clausesets[] = { > + NULL > +}; > + > +static cfg_type_t cfg_type_empty_map = { > + "empty_map", cfg_parse_map, cfg_print_map, cfg_doc_map, &cfg_rep_map, > + empty_map_clausesets > +}; > + > +static cfg_type_t *empty_map_p = &cfg_type_empty_map; > + > static cfg_type_t * > get_type_from_tuplefield(const cfg_type_t *cfg_type, const char *name) > { > @@ -469,44 +482,56 @@ acl_from_ldap(isc_mem_t *mctx, const char *aclstr, acl_type_t type, > cfg_parser_t *parser = NULL; > cfg_obj_t *aclobj = NULL; > cfg_aclconfctx_t *aclctx = NULL; > + /* ACL parser requires "configuration context". The parser looks for > + * undefined names in this context. We create empty context ("map" type), > + * i.e. only built-in named lists "any", "none" etc. are supported. */ > + cfg_obj_t *cctx = NULL; > + cfg_parser_t *parser_empty = NULL; > > REQUIRE(aclp != NULL && *aclp == NULL); > > CHECK(bracket_str(mctx, aclstr, &new_aclstr)); > > CHECK(cfg_parser_create(mctx, dns_lctx, &parser)); > + CHECK(cfg_parser_create(mctx, dns_lctx, &parser_empty)); > + CHECK(parse(parser_empty, "{}", &empty_map_p, &cctx)); > + > switch (type) { > case acl_type_query: > - result = parse(parser, str_buf(new_aclstr), &allow_query, > - &aclobj); > + CHECK(parse(parser, str_buf(new_aclstr), &allow_query, > + &aclobj)); > break; > case acl_type_transfer: > - result = parse(parser, str_buf(new_aclstr), &allow_transfer, > - &aclobj); > + CHECK(parse(parser, str_buf(new_aclstr), &allow_transfer, > + &aclobj)); > break; > default: > /* This is a bug */ > REQUIRE("Unhandled ACL type in acl_from_ldap" == NULL); > } > > - if (result != ISC_R_SUCCESS) { > - log_error("Failed to parse ACL (%s)", aclstr); > - goto cleanup; > - } > - > CHECK(cfg_aclconfctx_create(mctx, &aclctx)); > - CHECK(cfg_acl_fromconfig(aclobj, NULL, dns_lctx, aclctx, mctx, 0, &acl)); > + CHECK(cfg_acl_fromconfig(aclobj, cctx, dns_lctx, aclctx, mctx, 0, &acl)); > > *aclp = acl; > result = ISC_R_SUCCESS; > > cleanup: > + if (result != ISC_R_SUCCESS) > + log_error_r("%s ACL parsing failed: '%s'", > + type == acl_type_query ? "query" : "transfer", > + aclstr); > + > if (aclctx != NULL) > cfg_aclconfctx_detach(&aclctx); > if (aclobj != NULL) > cfg_obj_destroy(parser, &aclobj); > if (parser != NULL) > cfg_parser_destroy(&parser); > + if (cctx != NULL) > + cfg_obj_destroy(parser_empty, &cctx); > + if (parser_empty != NULL) > + cfg_parser_destroy(&parser_empty); > str_destroy(&new_aclstr); > > return result; > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 15:11:28 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 16:11:28 +0100 Subject: [Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL In-Reply-To: <514C61C7.5010103@redhat.com> References: <514C5C06.9090307@redhat.com> <514C61C7.5010103@redhat.com> Message-ID: <20130325151127.GB12895@redhat.com> On Fri, Mar 22, 2013 at 02:51:03PM +0100, Petr Spacek wrote: > On 22.3.2013 14:26, Petr Spacek wrote: > >Hello, > > > > Fix crash caused by 'zonesub' match-type in update ACL. > > > >Next patchset will improve overall error handling in ACL processing. > > I forgot to check return value from dns_name_copy(). Fixed patch is attached. Ack > From a76a7a2899e1e8b4335c012271f607e438ef0218 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 13:54:39 +0100 > Subject: [PATCH] Fix crash caused by 'zonesub' match-type in update ACL. > > Signed-off-by: Petr Spacek > --- > src/acl.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/src/acl.c b/src/acl.c > index f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a..ed3bdebcc027f3f5b7b2e9e084cf328ed4f6b1dd 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -208,6 +208,7 @@ get_match_type(const cfg_obj_t *obj) > > MATCH("name", DNS_SSUMATCHTYPE_NAME); > MATCH("subdomain", DNS_SSUMATCHTYPE_SUBDOMAIN); > + MATCH("zonesub", DNS_SSUMATCHTYPE_SUBDOMAIN); > MATCH("wildcard", DNS_SSUMATCHTYPE_WILDCARD); > MATCH("self", DNS_SSUMATCHTYPE_SELF); > #if defined(DNS_SSUMATCHTYPE_SELFSUB) && defined(DNS_SSUMATCHTYPE_SELFWILD) > @@ -246,8 +247,16 @@ get_fixed_name(const cfg_obj_t *obj, const char *name, dns_fixedname_t *fname) > > REQUIRE(fname != NULL); > > + if (!cfg_obj_istuple(obj)) { > + log_bug("configuration object is not a tuple"); > + return ISC_R_UNEXPECTED; > + } > obj = cfg_tuple_get(obj, name); > + > + if (!cfg_obj_isstring(obj)) > + return ISC_R_NOTFOUND; > str = cfg_obj_asstring(obj); > + > len = strlen(str); > isc_buffer_init(&buf, str, len); > > @@ -417,7 +426,19 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone) > match_type = get_match_type(stmt); > > CHECK(get_fixed_name(stmt, "identity", &fident)); > - CHECK(get_fixed_name(stmt, "name", &fname)); > + > + /* Use zone name for 'zonesub' match type */ > + result = get_fixed_name(stmt, "name", &fname); > + if (result == ISC_R_NOTFOUND && > + match_type == DNS_SSUMATCHTYPE_SUBDOMAIN) { > + dns_fixedname_init(&fname); > + CHECK(dns_name_copy(dns_zone_getorigin(zone), > + dns_fixedname_name(&fname), > + &fname.buffer)); > + } > + else if (result != ISC_R_SUCCESS) > + goto cleanup; > + > CHECK(get_types(mctx, stmt, &types, &n)); > > if (match_type == DNS_SSUMATCHTYPE_WILDCARD && > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Mon Mar 25 15:13:01 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:13:01 +0100 Subject: [Freeipa-devel] [PATCH 0120] Fix automatic reloading of invalid zone after each change in zone data In-Reply-To: <20130325144956.GA12282@redhat.com> References: <514AFF52.1080305@redhat.com> <20130325144956.GA12282@redhat.com> Message-ID: <5150697D.3040202@redhat.com> On 25.3.2013 15:49, Adam Tkac wrote: > On Thu, Mar 21, 2013 at 01:38:42PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Fix automatic reloading of invalid zone after each change in zone data. >> > >> > Reload wasn't done when serial_autoincrement feature was disabled. >> > >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 >> > > Ack. > > But before the push, please add explicit comment to ldap_get_zone_serial() > call that the only reason of this call is to return ISC_R_SUCCESS in case the > zone is loaded or DNS_R_NOTLOADED in case it isn't. I studied the patch for more > then 15 minutes before I figured this. I clarified the comment and pushed it to git. V2 branch contains rebased version of the patch. master: 9e7780b067b5d6b4ca74a3cdd0e88a97f3bd84c7 v2: 1c6373b2f8952b76cb8b93ed8cba8d444d129049 -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 25 15:14:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:14:40 +0100 Subject: [Freeipa-devel] [PATCH 0121] Fix crash during invalid zone reload process In-Reply-To: <20130325102519.GB1897@redhat.com> References: <514B08CE.7080708@redhat.com> <20130325102519.GB1897@redhat.com> Message-ID: <515069E0.2080500@redhat.com> On 25.3.2013 11:25, Adam Tkac wrote: > On Thu, Mar 21, 2013 at 02:19:10PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Fix crash during invalid zone reload process. >> > >> >This bug was created during settings refactoring and is present only >> >in master, not in v2 branch. > Ack Pushed to master: da4322499fb60549241aa6c529b6ff4f245266a1 V2 branch is unaffected by this bug. -- Petr^2 Spacek From atkac at redhat.com Mon Mar 25 15:15:54 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 16:15:54 +0100 Subject: [Freeipa-devel] [PATCH 0129] Harden update-policy processing In-Reply-To: <51501F35.2010505@redhat.com> References: <51501F35.2010505@redhat.com> Message-ID: <20130325151554.GC12895@redhat.com> On Mon, Mar 25, 2013 at 10:56:05AM +0100, Petr Spacek wrote: > Hello, > > Harden update-policy processing. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/111 > > This patch should prevent crashes similar to 'zonesub' problem > described in the ticket #111. Ack > From 05d73392dc6c0f9f6f7a9e570e4382ccb3c66022 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 25 Mar 2013 10:52:50 +0100 > Subject: [PATCH] Harden update-policy processing. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/111 > > Signed-off-by: Petr Spacek > --- > src/acl.c | 41 ++++++++++++++++++++++++++++------------- > 1 file changed, 28 insertions(+), 13 deletions(-) > > diff --git a/src/acl.c b/src/acl.c > index ed3bdebcc027f3f5b7b2e9e084cf328ed4f6b1dd..3b5de00f8a40cbc1a876ea2b74e9c2093e48774c 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -178,32 +178,48 @@ parse(cfg_parser_t *parser, const char *string, cfg_type_t **type, > #define MATCH(string_rep, return_val) \ > do { \ > if (!strcasecmp(str, string_rep)) { \ > - return return_val; \ > + *value = return_val; \ > + return ISC_R_SUCCESS; \ > } \ > } while (0) > > -static isc_boolean_t > -get_mode(const cfg_obj_t *obj) > +static isc_result_t > +get_mode(const cfg_obj_t *obj, isc_boolean_t *value) > { > const char *str; > > + if (!cfg_obj_istuple(obj)) { > + log_bug("tuple is expected"); > + return ISC_R_UNEXPECTED; > + } > obj = cfg_tuple_get(obj, "mode"); > + if (!cfg_obj_isstring(obj)) { > + log_bug("mode is not defined"); > + return ISC_R_UNEXPECTED; > + } > str = cfg_obj_asstring(obj); > > MATCH("grant", ISC_TRUE); > MATCH("deny", ISC_FALSE); > > - INSIST(0); > - /* Not reached. */ > - return ISC_FALSE; > + log_bug("unsupported ACL mode '%s'", str); > + return ISC_R_NOTIMPLEMENTED; > } > > -static unsigned int > -get_match_type(const cfg_obj_t *obj) > +static isc_result_t > +get_match_type(const cfg_obj_t *obj, unsigned int *value) > { > const char *str; > > + if (!cfg_obj_istuple(obj)) { > + log_bug("tuple is expected"); > + return ISC_R_UNEXPECTED; > + } > obj = cfg_tuple_get(obj, "matchtype"); > + if (!cfg_obj_isstring(obj)) { > + log_bug("matchtype is not defined"); > + return ISC_R_UNEXPECTED; > + } > str = cfg_obj_asstring(obj); > > MATCH("name", DNS_SSUMATCHTYPE_NAME); > @@ -232,9 +248,8 @@ get_match_type(const cfg_obj_t *obj) > MATCH("6to4-self", DNS_SSUMATCHTYPE_6TO4SELF); > #endif > > - INSIST(0); > - /* Not reached. */ > - return DNS_SSUMATCHTYPE_NAME; > + log_bug("unsupported match type '%s'", str); > + return ISC_R_NOTIMPLEMENTED; > } > > static isc_result_t > @@ -422,8 +437,8 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone) > types = NULL; > > stmt = cfg_listelt_value(el); > - grant = get_mode(stmt); > - match_type = get_match_type(stmt); > + CHECK(get_mode(stmt, &grant)); > + CHECK(get_match_type(stmt, &match_type)); > > CHECK(get_fixed_name(stmt, "identity", &fident)); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Mon Mar 25 15:16:28 2013 From: atkac at redhat.com (Adam Tkac) Date: Mon, 25 Mar 2013 16:16:28 +0100 Subject: [Freeipa-devel] [PATCH 0130] Add support for 'external' match-type in update-policy In-Reply-To: <51503156.1080203@redhat.com> References: <51503156.1080203@redhat.com> Message-ID: <20130325151628.GD12895@redhat.com> On Mon, Mar 25, 2013 at 12:13:26PM +0100, Petr Spacek wrote: > Hello, > > Add support for 'external' match-type in update-policy. Ack > From 00ce71c81d2f486ca193acfd3174dc04e612c901 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 25 Mar 2013 12:12:52 +0100 > Subject: [PATCH] Add support for 'external' match-type in update-policy. > > Signed-off-by: Petr Spacek > --- > src/acl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/acl.c b/src/acl.c > index 3b5de00f8a40cbc1a876ea2b74e9c2093e48774c..4614d39a38655377a90a588357e82539ffc00330 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -247,6 +247,9 @@ get_match_type(const cfg_obj_t *obj, unsigned int *value) > MATCH("tcp-self", DNS_SSUMATCHTYPE_TCPSELF); > MATCH("6to4-self", DNS_SSUMATCHTYPE_6TO4SELF); > #endif > +#if defined(DNS_SSUMATCHTYPE_EXTERNAL) > + MATCH("external", DNS_SSUMATCHTYPE_EXTERNAL); > +#endif > > log_bug("unsupported match type '%s'", str); > return ISC_R_NOTIMPLEMENTED; > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Mon Mar 25 15:16:27 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:16:27 +0100 Subject: [Freeipa-devel] [PATCH 0122] Log successful zone reload after record change. In-Reply-To: <20130325145618.GB12282@redhat.com> References: <514B0EE7.2040109@redhat.com> <20130325145618.GB12282@redhat.com> Message-ID: <51506A4B.7070603@redhat.com> On 25.3.2013 15:56, Adam Tkac wrote: > On Thu, Mar 21, 2013 at 02:45:11PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Log successful zone reload after record change. >> > >> >This should be last piece of >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > Ack Pushed to master: 960bcfb93e8e8e5236d8047986dc589e793b3aca v2: 6a69cbc2a4502174c051c82c538eb88b9d9a64e0 -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 25 15:18:56 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:18:56 +0100 Subject: [Freeipa-devel] [PATCH 0117] Fix crash caused by invalid query/transfer policy In-Reply-To: <20130325150842.GA12895@redhat.com> References: <5134A01A.7050500@redhat.com> <20130325150842.GA12895@redhat.com> Message-ID: <51506AE0.4020208@redhat.com> On 25.3.2013 16:08, Adam Tkac wrote: > On Mon, Mar 04, 2013 at 02:22:34PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Fix crash caused by invalid query/transfer policy. >> > >> >Please double-check correctness. The ISC parser is really complex beast! >> > >> >Thank you. > Ack Pushed to master: 8e7ab08b06fe303914b94f42a91467ca5e77f299 v2: 654971e45872471b800fa3f5afd7f7f383d168e9 -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 25 15:20:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:20:12 +0100 Subject: [Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL In-Reply-To: <20130325151127.GB12895@redhat.com> References: <514C5C06.9090307@redhat.com> <514C61C7.5010103@redhat.com> <20130325151127.GB12895@redhat.com> Message-ID: <51506B2C.2060801@redhat.com> On 25.3.2013 16:11, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 02:51:03PM +0100, Petr Spacek wrote: >> >On 22.3.2013 14:26, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > > Fix crash caused by 'zonesub' match-type in update ACL. >>> > > >>> > >Next patchset will improve overall error handling in ACL processing. >> > >> >I forgot to check return value from dns_name_copy(). Fixed patch is attached. > Ack Pushed to master: 7e0976cb448acfbcaa61d36101a01dc48281dab5 v2: 55b623b947b8bef1eb31ad6cd4efe1b846c036c4 -- Petr^2 Spacek From mkosek at redhat.com Mon Mar 25 15:21:26 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Mar 2013 16:21:26 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <5150541A.9030105@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> Message-ID: <51506B76.5070302@redhat.com> On 03/25/2013 02:41 PM, Martin Kosek wrote: > On 03/18/2013 12:38 PM, Jan Cholasta wrote: >> Hi, >> >> this patch implements . >> >> Because the design is not finished yet, this is a minimal implementation - it >> uses the krbTicketFlags attribute directly (which means no delegation of rights >> to modify specific flags to specific admins) and there is no support for >> per-service type default values. >> >> Honza >> >> > > I checked what you have already and this is what I found: > > 1) Internal error if I try to remove krbticketflags via *attr functions: > > # ipa service-add foo/`hostname` --setattr=krbticketflags=None > ipa: ERROR: an internal error has occurred > # ipa service-add foo/`hostname` > ------------------------------------------------------------------------ > Added service "foo/vm-037.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM" > ------------------------------------------------------------------------ > # ipa service-mod foo/`hostname` --setattr=krbticketflags=None > ipa: ERROR: an internal error has occurred > > > 2) The RFE page needs updating, it does not reflect current reality. AFAIU, the > only thing that's left to be decided is the granularity of the ACIs used to > control this flag. I read this part of design proposal discussion wrong, this is already decided - we do not want to have a fine grain granularity, these are too powerful flags to be delegated per-flag to lower admins. So I think that you current approach is sufficient, I do not think we need to add this attribute to some host/service related permission to avoid allowing this sensitive attribute for lower level admins automatically. If someone wants it, he can add and assign an appropriate permission. Martin From pspacek at redhat.com Mon Mar 25 15:21:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:21:57 +0100 Subject: [Freeipa-devel] [PATCH 0129] Harden update-policy processing In-Reply-To: <20130325151554.GC12895@redhat.com> References: <51501F35.2010505@redhat.com> <20130325151554.GC12895@redhat.com> Message-ID: <51506B95.2010401@redhat.com> On 25.3.2013 16:15, Adam Tkac wrote: > On Mon, Mar 25, 2013 at 10:56:05AM +0100, Petr Spacek wrote: >> >Hello, >> > >> >Harden update-policy processing. >> > >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/111 >> > >> >This patch should prevent crashes similar to 'zonesub' problem >> >described in the ticket #111. > Ack Pushed to master: 995c719205265600bfc548c539cfc99dab1bfdc7 v2: 7ba79d000b508a229fd66103b2da74bef9007548 -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 25 15:23:34 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:23:34 +0100 Subject: [Freeipa-devel] [PATCH 0130] Add support for 'external' match-type in update-policy In-Reply-To: <20130325151628.GD12895@redhat.com> References: <51503156.1080203@redhat.com> <20130325151628.GD12895@redhat.com> Message-ID: <51506BF6.9010203@redhat.com> On 25.3.2013 16:16, Adam Tkac wrote: > On Mon, Mar 25, 2013 at 12:13:26PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >Add support for 'external' match-type in update-policy. > Ack Pushed to master: 1fc8af6c0a5408db1766386ca82b5ff5fe01ac10 v2: 6fd6222d53ba32122aa1f5bb36db43fab3653d09 -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 25 15:26:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Mar 2013 16:26:46 +0100 Subject: [Freeipa-devel] [PATCH 0127] Remove orphaned function declaration from ldap_helper.h In-Reply-To: <20130325145639.GC12282@redhat.com> References: <514C4934.1000105@redhat.com> <20130325145639.GC12282@redhat.com> Message-ID: <51506CB6.7000706@redhat.com> On 25.3.2013 15:56, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:06:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Remove orphaned function declaration from ldap_helper.h. >> > > Ack Pushed to master: eb7c5e436b4c7493c47bd9e7e5d394a8042afa5d V2 branch is not affected. -- Petr^2 Spacek From abokovoy at redhat.com Mon Mar 25 18:07:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Mar 2013 20:07:44 +0200 Subject: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam Message-ID: <20130325180744.GH6823@redhat.com> Hi, following patch allows to enumerate UPN suffixes associated with IPA domain and make them available to AD domain we trust. The patch relies on PASSDB API expansion I'm working on and as such requires Samba built with the change. You can find F18 scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=5168969, these patches will be submitted to Samba upstream this week. In the patch I'm filtering out our own DNS domain since its value will be added by Samba by default -- if PASSDB module does not provide the function, its absence will be ignored in the new API. Filtering out is done by freeing the string and moving empty item to last position in the array, reducing the array size but not resizing it -- talloc will hardly win anything from resizing one (char *) pointer and actual lifetime of the array is until the packet is sent so it is acceptable. In order to test the patch, you need updated Samba, then rebuild FreeIPA packages. Once installed and configured, UPN suffixes can be managed via 'ipa realmdomains-mod --{add,dell}-domain' commands. These domains will be exposed to Windows. When you added realm domains, an attempt to establish trust will cause Windows to ask for name suffixes and Samba will serve expanded list of them via netr_GetTrustInformation (opnum 44). In Samba code I've also implemented partially opnum 43 which is giving out the same information via DsRGetTrustInformation but so far Windows AD DC haven't actually tried to use opnum 43. Additionally, you can request Windows to update list of name suffixes via UI. Here is how it looks in Windows 2012 Server: http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png Part of ticket https://fedorahosted.org/freeipa/ticket/2848 -- / Alexander Bokovoy -------------- next part -------------- >From f400d55eaec99b3e5440e90b6a6d055e26529e7e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 22 Mar 2013 17:30:41 +0200 Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the realm domains PASSDB API in Samba adds support for specifying UPN suffixes. The change in ipasam will allow to pass through list of realm domains as UPN suffixes so that Active Directory domain controller will be able to recognize non-primary UPN suffixes as belonging to IPA and properly find our KDC for cross-realm TGT. Since Samba already returns primary DNS domain separately, filter it out from list of UPN suffixes. Also enclose provider of UPN suffixes into #ifdef to support both Samba with and without pdb_enum_upn_suffixes(). Part of https://fedorahosted.org/freeipa/ticket/2848 --- daemons/configure.ac | 10 +++ daemons/ipa-sam/ipa_sam.c | 172 ++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 177 insertions(+), 5 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index d3b6b19..14dc04e 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient], [$SAMBA40EXTRA_LIBPATH]) AC_SUBST(WBCLIENT_LIBS) +AC_CHECK_LIB([pdb], + [make_pdb_method], + [HAVE_LIBPDB=1], + [AC_MSG_ERROR([libpdb does not have make_pdb_method])], + [$SAMBA40EXTRA_LIBPATH]) +AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes], + [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to enumerate UPN suffixes])], + [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no support for realm domains in ipasam])], + [$SAMBA40EXTRA_LIBPATH]) + dnl --------------------------------------------------------------------------- dnl - Check for check unit test framework http://check.sourceforge.net/ dnl --------------------------------------------------------------------------- diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index dd3ad61..1783ca3 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -1,6 +1,7 @@ #define HAVE_IMMEDIATE_STRUCTURES 1 #define LDAP_DEPRECATED 1 +#include "config.h" #include #include #include @@ -167,6 +168,12 @@ struct ipasam_privates { struct sss_idmap_ctx *idmap_ctx; }; + +static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, + TALLOC_CTX *mem_ctx, + char **domain_name); + + static void *idmap_talloc(size_t size, void *pvt) { return talloc_size(pvt, size); @@ -295,6 +302,53 @@ static LDAP *priv2ld(struct ldapsam_privates *priv) return priv->smbldap_state->ldap_struct; } +/* + * get_attribute_values() returns array of all values of the attribute + * allocated over mem_ctx + */ +static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, + LDAPMessage *entry, const char *attribute, int *num_values) +{ + struct berval **values; + int count, i; + char **result = NULL; + size_t conv_size; + + if (attribute == NULL || entry == NULL) { + return NULL; + } + + values = ldap_get_values_len(ldap_struct, entry, attribute); + if (values == NULL) { + DEBUG(10, ("Attribute [%s] not found.\n", attribute)); + return NULL; + } + + /* Note that if we've got any values, count would be > 0 */ + count = ldap_count_values_len(values); + result = talloc_array(mem_ctx, char *, count); + if (result == NULL) { + goto done; + } + + *num_values = count; + for (i = 0; i < count; i++) { + if (!convert_string_talloc(result, CH_UTF8, CH_UNIX, + values[i]->bv_val, values[i]->bv_len, + &result[i], &conv_size)) { + DEBUG(10, ("Failed to convert %dth value of [%s] out of %d.\n", + i, attribute, count)); + talloc_free(result); + result = NULL; + goto done; + } + } + +done: + ldap_value_free_len(values); + return result; +} + static char *get_single_attribute(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, LDAPMessage *entry, const char *attribute) { @@ -3250,9 +3304,8 @@ static struct pdb_domain_info *pdb_ipasam_get_domain_info(struct pdb_methods *pd goto fail; } - /* TODO: read dns_domain, dns_forest and guid from LDAP */ - info->dns_domain = strlower_talloc(info, ldap_state->ipasam_privates->realm); - if (info->dns_domain == NULL) { + status = ipasam_get_domain_name(ldap_state, info, &info->dns_domain); + if (!NT_STATUS_IS_OK(status) || (info->dns_domain == NULL)) { goto fail; } info->dns_forest = talloc_strdup(info, info->dns_domain); @@ -3464,7 +3517,7 @@ static NTSTATUS ipasam_get_base_dn(struct smbldap_state *smbldap_state, static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, TALLOC_CTX *mem_ctx, - const char **domain_name) + char **domain_name) { int ret; LDAPMessage *result; @@ -3572,6 +3625,110 @@ static NTSTATUS ipasam_get_realm(struct ldapsam_privates *ldap_state, return NT_STATUS_OK; } +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES +static NTSTATUS ipasam_enum_upn_suffixes(struct pdb_methods *pdb_methods, + TALLOC_CTX *mem_ctx, + uint32_t *num_suffixes, + char ***suffixes) +{ + int ret; + LDAPMessage *result; + LDAPMessage *entry = NULL; + int count, i; + char *realmdomains_dn = NULL; + char **domains = NULL; + struct ldapsam_privates *ldap_state; + struct smbldap_state *smbldap_state; + const char *attr_list[] = { + "associatedDomain", + NULL + }; + + if ((suffixes == NULL) || (num_suffixes == NULL)) { + return NT_STATUS_UNSUCCESSFUL; + } + + ldap_state = (struct ldapsam_privates *)pdb_methods->private_data; + smbldap_state = ldap_state->smbldap_state; + + realmdomains_dn = talloc_asprintf(mem_ctx, "cn=Realm Domains,cn=ipa,cn=etc,%s", + ldap_state->ipasam_privates->base_dn); + if (realmdomains_dn == NULL) { + return NT_STATUS_NO_MEMORY; + } + + ret = smbldap_search(smbldap_state, + realmdomains_dn, + LDAP_SCOPE_BASE, + "objectclass=domainRelatedObject", attr_list, 0, + &result); + if (ret != LDAP_SUCCESS) { + DEBUG(1, ("Failed to get list of realm domains: %s\n", + ldap_err2string (ret))); + return NT_STATUS_UNSUCCESSFUL; + } + + count = ldap_count_entries(smbldap_state->ldap_struct, result); + if (count != 1) { + DEBUG(1, ("Unexpected number of results [%d] for realm domains " + "search.\n", count)); + ldap_msgfree(result); + return NT_STATUS_OK; + } + + entry = ldap_first_entry(smbldap_state->ldap_struct, result); + if (entry == NULL) { + DEBUG(0, ("Could not get domainRelatedObject entry\n")); + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; + } + + domains = get_attribute_values(mem_ctx, smbldap_state->ldap_struct, entry, + "associatedDomain", &count); + if (domains == NULL) { + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; + } + + /* Since associatedDomain has attributeType MUST, there must be at least one domain */ + for (i = 0; i < count ; i++) { + if (strcmp(ldap_state->domain_name, domains[i]) == 0) { + break; + } + } + + if (i < count) { + /* If we found our primary domain in the list and it is alone, exit with empty list */ + if (count == 1) { + ldap_msgfree(result); + talloc_free(domains); + return NT_STATUS_UNSUCCESSFUL; + } + + talloc_free(domains[i]); + + /* if i is not last element, move everything down */ + if (i != (count - 1)) { + memcpy(domains + i, domains + i + 1, sizeof(char *) * (count - i - 1)); + } + + /* we don't resize whole list, only reduce number of elements in it + * since sizing down a single pointer will not reduce memory usage in talloc + */ + *suffixes = domains; + *num_suffixes = count - 1; + } else { + /* There is no our primary domain in the list */ + *suffixes = domains; + *num_suffixes = count; + } + + ldap_msgfree(result); + return NT_STATUS_OK; +} +#endif /* HAVE_PDB_ENUM_UPN_SUFFIXES */ + + #define SECRETS_DOMAIN_SID "SECRETS/SID" static char *sec_key(TALLOC_CTX *mem_ctx, const char *d) { @@ -4030,7 +4187,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, } status = ipasam_get_domain_name(ldap_state, ldap_state, - &ldap_state->domain_name); + (char**) &ldap_state->domain_name); if (!NT_STATUS_IS_OK(status)) { DEBUG(0, ("Failed to get domain name.\n")); return status; @@ -4150,6 +4307,11 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, (*pdb_method)->set_trusted_domain = ipasam_set_trusted_domain; (*pdb_method)->del_trusted_domain = ipasam_del_trusted_domain; (*pdb_method)->enum_trusted_domains = ipasam_enum_trusted_domains; +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES + (*pdb_method)->enum_upn_suffixes = ipasam_enum_upn_suffixes; + DEBUG(1, ("pdb_init_ipasam: support for pdb_enum_upn_suffixes " + "enabled for domain %s\n", ldap_state->domain_name)); +#endif return NT_STATUS_OK; } -- 1.8.1.4 From pviktori at redhat.com Mon Mar 25 18:08:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Mar 2013 19:08:15 +0100 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <514D2A3A.4010909@redhat.com> References: <514D2A3A.4010909@redhat.com> Message-ID: <5150928F.2010602@redhat.com> On 03/23/2013 05:06 AM, Rob Crittenden wrote: > TL;DR. Sorry. > > Here is my current progress on backup and restore. I have not documented > any of this in the Implementation section of the wiki yet. > > I've added two new commands, ipa-backup and ipa-restore. > > The files go into /var/lib/ipa/backup. When doing a restore you should > only reference the directory in backup, not the full path. This needs to > change, but it is what it is. > > There are strict limits on what can be restored where. Only exact > matching hostnames and versions are allowed right now. We can probably > relax the hostname requirement if we're only restoring data, and the > version perhaps for only the the first two values (so you can restore a > 3.0.0 backup on 3.0.1 but not on 3.1.0). Do we also need to limit the versions of Dogtag, 389, Kerberos...? Or is what they put in /var/lib guaranteed portable across versions? > I've done 99.99% of testing in F-18 with a single instance. I did some > initial testing in 6.4 so I think the roots are there, but they are > untested currently. > > I spent a lot of time going in circles when doing a restore and getting > replication right. I'm open to discussion on this, but my purpose for > restoration was to define a new baseline for the IPA installation. It is > basically the catastrophic case, where your data is > hosed/untested/whatever and you just want to get back to some sane point. > > Ok, so given that we need to make sure that any other masters don't send > us any updates in their changelog when they come back online. So I use a > new feature in 1.3.0 to disable the replication agreements. This works > really, really well. > > The only problem is you have to re-enable the agreement in order to > re-initialize a master (https://fedorahosted.org/389/ticket/47304). I > have the feeling that this leaves a small window where replication can > occur and pollute our restored master. I noticed that we do a > force_sync() when doing a full re-init. It may be that if we dropped it > that would also mitigate this. > > I did the majority of my testing using an A <-> B <-> C replication > topology. This exposed a lot of issues that A <-> B did not. I don't > know if it was the third server or having the extra hop, but I hopefully > closed a bunch of the corner cases. > > So what I would do is either a full or a data restore on A. This would > break replication on B and C, as expected. So in this scenario A and B > are CAs. > > Then I'd run this on B: > > # ipa-replica-manage re-initialize --from=A > # ipa-csreplica-manage re-initialize --from=A > > Once that was done I'd run this on C: > > # ipa-replica-manage re-initialize --from=B > > The restoration of the dogtag databases was the last thing I did so it > isn't super-well tested. I had to move a fair bit of code around. I > think it's the sort of thing that will work when the everything goes > well but exceptions may not be well-handled. > > The man pages are just a shel right now, they need a lot of work. > > It should also be possible to do a full system restore. I tested with: > > # ipa-server-install ... > # > # ipa-backup > # add one or more users > # ipa-server-install --uninstall -U > # ipa-restore ipa-full-... > > The last batch of users should be gone. I did similar tests with the > A/B/C set up. > > I ran the unit tests against it and all was well. > > I have done zero testing in a Trust environment, though at least some of > the files are backed up in the full case. I did some testing with DNS. > > I did no testing of a master that was down at the time of restoration > and then was brought online later, so it never had its replication > agreement disabled. I have the feeling it will hose the data. > > I have some concern over space requirements. Because I tar things up one > basically needs double-the backup space in order to do a restore, and a > bit more when encrypted. I'm open to suggestions on how to store the > data, but we have many files for the 389-ds bak backup and I didn't want > to have to encrypt them all. > > On that note, that I'm doing a db2bak AND a db2ldif backup and currently > using the ldif2db for the restore. My original intention was to use > db2bak/bak2db in order to retain the changelog, but retaining the > changelog is actually a problem if we're restoring to a known state and > forcing a re-init. It wouldn't take much to convince me to drop that, > which reduces the # of files we have to deal with. > > I also snuck in a change to the way that replication is displayed. It > has long bothered me that we print out an Updating message during > replication because it gives no context. I changed it to be more of a > progress indicator, using \r to over-write itself and include the # of > seconds elapsed. The log files are still readable but I'd hate to see > what this looks like in a typescript :-) > > Finally, sorry about the huge patch. I looked at the incremental commits > I had done and I didn't think they'd tell much of a story. I thought > about breaking some of the pieces out, but there is a lot of > interdependency, so you'd need everything eventually anyway, so here you > go, a 70k patch. > > A quick roadmap is (and I'll skip the obvious): > > ipa-csreplica-manage: had to move a bunch of code to replication.py so I > could use the CSReplicaManager class in ipa-restore. The rest revolves > around handling exceptions raised by get_cs_replication_manager() and > enabling replication on both sides to do a re-init. > > replication.py: the changes mentioned to pretty-print updates, a notable > change where a re-init automatically enables replication, the new > enable/disable code and all the code from ipa-csreplica-manage. > > ipa-backup/ipa-restore use the new admintool framework. I generally have > a good impression of the new framework, but I found myself having to run > in debug mode more than I'd have liked in order to discover some types > of errors. That's good to hear! I think while developing, you should run with -v to get all the output. And for production, please have the commands log by default (set log_file_name). > ipa-backup does all its binds using ldapi. ipa-restore needs the DM > password because we need to contact remote servers to enable/disable > replication. The restore assumes that ipa is already installed, right? I can't just run it on a clean machine? Id would be good to check/document this. I looked in the backup tarball and saw dirsrv PID file and lock directories. Are these needed? The tool runners (install/tools/ipa-backup and install/tools/ipa-restore) are missing, so IPA doesn't build. Probably just a forgotten git add. The patch adds an extra backslash in install/tools/man/Makefile.am; consider adding $(NULL) at the end. Backup.dirs, Backup.files, Backup.logs: The code modifies these class-level attributes. This means you can't run the command more than once in one Python session, so it can't be used as a library (e.g. in a hypothetical test suite). Please make the class atrributes immutable (tuples), then in __init__ do `self.dirs = list(self.dirs)` to to get instance-specific lists. Code that creates temporary files/directories or does chdir() should be next to (or in) a try block whose finally: restores things. Instead of star imports (from ipapython.ipa_log_manager import *), please explicitly import whatever you're using from that package. In this case, nothing at all! If there's a get_connection() method, it should return the connection, and it should always be used to get it. Store the connection in self._conn, and rather than: self.get_connection() self.conn.do_work() do: conn = self.get_connection() conn.do_work() This makes forgetting to call get_connection() impossible. If a variable is only used in a single method, like `filename` in Restore.extract_backup, don't store it in the admintool object. In general, try to avoid putting data in self if possible. It's convenient but it allows complex interdependencies. (Yes, I'm guilty of not following this myself.) In several places, the backup tool logs critical errors and then just continues on. Is that by design? I think a nonzero exit code would be appropriate. In the ipa-restore man page, --backend is not documented. In db2ldif, db2bak, etc., a more conscise way to get the time string is `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. When validating --gpg-keyring, it would be good to check both files (.sec and .pub). Here: if (self.backup_type != 'FULL' and not options.data_only and not instances): raise admintool.ScriptError('Cannot restore a data backup into an empty system') did you mean `(self.backup_type != 'FULL' or options.data_only) and not instances`? (I'd introduce a `data_only` flag to prevent confusion.) In the ReplicationManager.check_repl_init reporting: use int(d.total_seconds()) instead of d.seconds, as the latter doesn't include full days. I don't think anyone would wait long enough for the overflow, but better to be correct. -- Petr? From rmeggins at redhat.com Mon Mar 25 23:47:15 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Mar 2013 17:47:15 -0600 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5150928F.2010602@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> Message-ID: <5150E203.10308@redhat.com> On 03/25/2013 12:08 PM, Petr Viktorin wrote: > On 03/23/2013 05:06 AM, Rob Crittenden wrote: >> TL;DR. Sorry. >> >> Here is my current progress on backup and restore. I have not documented >> any of this in the Implementation section of the wiki yet. >> >> I've added two new commands, ipa-backup and ipa-restore. >> >> The files go into /var/lib/ipa/backup. When doing a restore you should >> only reference the directory in backup, not the full path. This needs to >> change, but it is what it is. >> >> There are strict limits on what can be restored where. Only exact >> matching hostnames and versions are allowed right now. We can probably >> relax the hostname requirement if we're only restoring data, and the >> version perhaps for only the the first two values (so you can restore a >> 3.0.0 backup on 3.0.1 but not on 3.1.0). > > Do we also need to limit the versions of Dogtag, 389, Kerberos...? No. > Or is what they put in /var/lib guaranteed portable across versions? Mostly. We always suggest doing ldif dumps (db2ldif) for more long term storage. > >> I've done 99.99% of testing in F-18 with a single instance. I did some >> initial testing in 6.4 so I think the roots are there, but they are >> untested currently. >> >> I spent a lot of time going in circles when doing a restore and getting >> replication right. I'm open to discussion on this, but my purpose for >> restoration was to define a new baseline for the IPA installation. It is >> basically the catastrophic case, where your data is >> hosed/untested/whatever and you just want to get back to some sane >> point. >> >> Ok, so given that we need to make sure that any other masters don't send >> us any updates in their changelog when they come back online. So I use a >> new feature in 1.3.0 to disable the replication agreements. This works >> really, really well. >> >> The only problem is you have to re-enable the agreement in order to >> re-initialize a master (https://fedorahosted.org/389/ticket/47304). I >> have the feeling that this leaves a small window where replication can >> occur and pollute our restored master. I noticed that we do a >> force_sync() when doing a full re-init. It may be that if we dropped it >> that would also mitigate this. >> >> I did the majority of my testing using an A <-> B <-> C replication >> topology. This exposed a lot of issues that A <-> B did not. I don't >> know if it was the third server or having the extra hop, but I hopefully >> closed a bunch of the corner cases. >> >> So what I would do is either a full or a data restore on A. This would >> break replication on B and C, as expected. So in this scenario A and B >> are CAs. >> >> Then I'd run this on B: >> >> # ipa-replica-manage re-initialize --from=A >> # ipa-csreplica-manage re-initialize --from=A >> >> Once that was done I'd run this on C: >> >> # ipa-replica-manage re-initialize --from=B >> >> The restoration of the dogtag databases was the last thing I did so it >> isn't super-well tested. I had to move a fair bit of code around. I >> think it's the sort of thing that will work when the everything goes >> well but exceptions may not be well-handled. >> >> The man pages are just a shel right now, they need a lot of work. >> >> It should also be possible to do a full system restore. I tested with: >> >> # ipa-server-install ... >> # >> # ipa-backup >> # add one or more users >> # ipa-server-install --uninstall -U >> # ipa-restore ipa-full-... >> >> The last batch of users should be gone. I did similar tests with the >> A/B/C set up. >> >> I ran the unit tests against it and all was well. >> >> I have done zero testing in a Trust environment, though at least some of >> the files are backed up in the full case. I did some testing with DNS. >> >> I did no testing of a master that was down at the time of restoration >> and then was brought online later, so it never had its replication >> agreement disabled. I have the feeling it will hose the data. >> >> I have some concern over space requirements. Because I tar things up one >> basically needs double-the backup space in order to do a restore, and a >> bit more when encrypted. I'm open to suggestions on how to store the >> data, but we have many files for the 389-ds bak backup and I didn't want >> to have to encrypt them all. >> >> On that note, that I'm doing a db2bak AND a db2ldif backup and currently >> using the ldif2db for the restore. My original intention was to use >> db2bak/bak2db in order to retain the changelog, but retaining the >> changelog is actually a problem if we're restoring to a known state and >> forcing a re-init. It wouldn't take much to convince me to drop that, >> which reduces the # of files we have to deal with. >> >> I also snuck in a change to the way that replication is displayed. It >> has long bothered me that we print out an Updating message during >> replication because it gives no context. I changed it to be more of a >> progress indicator, using \r to over-write itself and include the # of >> seconds elapsed. The log files are still readable but I'd hate to see >> what this looks like in a typescript :-) >> >> Finally, sorry about the huge patch. I looked at the incremental commits >> I had done and I didn't think they'd tell much of a story. I thought >> about breaking some of the pieces out, but there is a lot of >> interdependency, so you'd need everything eventually anyway, so here you >> go, a 70k patch. >> >> A quick roadmap is (and I'll skip the obvious): >> >> ipa-csreplica-manage: had to move a bunch of code to replication.py so I >> could use the CSReplicaManager class in ipa-restore. The rest revolves >> around handling exceptions raised by get_cs_replication_manager() and >> enabling replication on both sides to do a re-init. >> >> replication.py: the changes mentioned to pretty-print updates, a notable >> change where a re-init automatically enables replication, the new >> enable/disable code and all the code from ipa-csreplica-manage. >> >> ipa-backup/ipa-restore use the new admintool framework. I generally have >> a good impression of the new framework, but I found myself having to run >> in debug mode more than I'd have liked in order to discover some types >> of errors. > > That's good to hear! > > I think while developing, you should run with -v to get all the output. > And for production, please have the commands log by default (set > log_file_name). > >> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >> password because we need to contact remote servers to enable/disable >> replication. > > The restore assumes that ipa is already installed, right? I can't just > run it on a clean machine? Id would be good to check/document this. > > I looked in the backup tarball and saw dirsrv PID file and lock > directories. Are these needed? No. > > > The tool runners (install/tools/ipa-backup and > install/tools/ipa-restore) are missing, so IPA doesn't build. Probably > just a forgotten git add. > > The patch adds an extra backslash in install/tools/man/Makefile.am; > consider adding $(NULL) at the end. > > > Backup.dirs, Backup.files, Backup.logs: > The code modifies these class-level attributes. This means you can't > run the command more than once in one Python session, so it can't be > used as a library (e.g. in a hypothetical test suite). > Please make the class atrributes immutable (tuples), then in __init__ > do `self.dirs = list(self.dirs)` to to get instance-specific lists. > > Code that creates temporary files/directories or does chdir() should > be next to (or in) a try block whose finally: restores things. > > Instead of star imports (from ipapython.ipa_log_manager import *), > please explicitly import whatever you're using from that package. In > this case, nothing at all! > > > If there's a get_connection() method, it should return the connection, > and it should always be used to get it. Store the connection in > self._conn, and rather than: > self.get_connection() > self.conn.do_work() > do: > conn = self.get_connection() > conn.do_work() > This makes forgetting to call get_connection() impossible. > > If a variable is only used in a single method, like `filename` in > Restore.extract_backup, don't store it in the admintool object. > In general, try to avoid putting data in self if possible. It's > convenient but it allows complex interdependencies. > (Yes, I'm guilty of not following this myself.) > > > In several places, the backup tool logs critical errors and then just > continues on. Is that by design? I think a nonzero exit code would be > appropriate. > > > In the ipa-restore man page, --backend is not documented. > > In db2ldif, db2bak, etc., a more conscise way to get the time string > is `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. > > When validating --gpg-keyring, it would be good to check both files > (.sec and .pub). > > Here: > if (self.backup_type != 'FULL' and not options.data_only and > not instances): > raise admintool.ScriptError('Cannot restore a data backup into > an empty system') > did you mean `(self.backup_type != 'FULL' or options.data_only) and > not instances`? (I'd introduce a `data_only` flag to prevent confusion.) > > In the ReplicationManager.check_repl_init reporting: use > int(d.total_seconds()) instead of d.seconds, as the latter doesn't > include full days. I don't think anyone would wait long enough for the > overflow, but better to be correct. > From jcholast at redhat.com Tue Mar 26 14:05:25 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Mar 2013 15:05:25 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51506B76.5070302@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> Message-ID: <5151AB25.1070207@redhat.com> On 25.3.2013 16:21, Martin Kosek wrote: > On 03/25/2013 02:41 PM, Martin Kosek wrote: >> I checked what you have already and this is what I found: >> >> 1) Internal error if I try to remove krbticketflags via *attr functions: >> >> # ipa service-add foo/`hostname` --setattr=krbticketflags=None >> ipa: ERROR: an internal error has occurred >> # ipa service-add foo/`hostname` >> ------------------------------------------------------------------------ >> Added service "foo/vm-037.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM" >> ------------------------------------------------------------------------ >> # ipa service-mod foo/`hostname` --setattr=krbticketflags=None >> ipa: ERROR: an internal error has occurred Fixed. >> >> >> 2) The RFE page needs updating, it does not reflect current reality. AFAIU, the >> only thing that's left to be decided is the granularity of the ACIs used to >> control this flag. RFE page updated. > > I read this part of design proposal discussion wrong, this is already decided - > we do not want to have a fine grain granularity, these are too powerful flags > to be delegated per-flag to lower admins. > > So I think that you current approach is sufficient, I do not think we need to > add this attribute to some host/service related permission to avoid allowing > this sensitive attribute for lower level admins automatically. If someone wants > it, he can add and assign an appropriate permission. Correct, this has been already decided. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-120.1-Add-Kerberos-ticket-flags-management-to-service-and-.patch Type: text/x-patch Size: 22610 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 26 14:08:46 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Mar 2013 09:08:46 -0500 Subject: [Freeipa-devel] [WIP] Web UI Refactoring & plugins effort - current state In-Reply-To: <51362CB7.8000900@redhat.com> References: <51362CB7.8000900@redhat.com> Message-ID: <5151ABEE.4010202@redhat.com> Hi, I have some comments & questions. Navigation: * Dojo/topic is used to handle low-level UI events such as facet-show and facet-change. Is it possible to use dojo/on or direct method calls? I suppose topics would also run slower (although that might not be an issue). Dojo/topic seem to be more appropriate for high-level events such as phase changes (e.g. UI initialized), data changes (e.g. user added), auth changes (e.g. login/logout/expiration), etc. which might affect the UI globally. This way 3rd-party code can subscribe to these topics too. * The navigation uses a 'hash' array that will be joined with a '/'. Should we call this a 'path'? * Is it necessary to have /e and /p prefixes? Is there a possibility where 'entity' and 'page' might conflict? * When is /p used? Any example? * The paths probably can be made more REST-like. Suppose in the future IPA uses REST, they will be easier to translate. Look for REST URL best practices. This is the path style used in Dogtag: /users -> Users search facet /users/admin -> Admin's details (or initial) facet /users/admin/memberof_groups -> Admin's member of groups * When you hover over a link, the hash shown doesn't match the actual hash after clicking the link. * Changing page number doesn't refresh the content. In Permissions search facet if you click Prev or Next or entering the page number nothing is changed, but if you go to another facet then come back it will show the new page. * Existing issue, the navigation profile is hard-coded so it's either admin or self-service, and the identity/user navigation item is defined twice. Is it possible to generalize this so the navigation items are defined only once and each item (or the controller) will determine whether it's supposed to be visible? In the future it might be possible to show more read-only navigation items in self-service mode, so it's not only limited to identity/user. Registers: * The 'register' objects probably should be called 'registry'. Phases: * What's the advantage of using dojo/topic to define phases vs. using inheritance to override phase methods? * Any example where a phase has multiple tasks? * The 'alternation' phase probably should be called 'customization'. Plugins: * Right now the Web UI plugin registration requires running a script to update the index file so the plugin can be loaded. Is it possible to write a server plugin that reads the content of the UI plugins folder on the server, and have the UI call it to get the list of UI plugins and then load it dynamically? * Is there a base class for a plugin? Or is a plugin basically a collection of custom UI components (e.g. entities, facets, widgets)? * Any plugin example? How do you customize the menu (e.g. add a new page)? Other: * The HTML elements in widgets/App.js still contain 'id' attributes which is a global identifier. Not really a problem since it's only used once in UI, but to be really modular it should not contain global identifiers. * This is probably an existing issue, in self-service mode if you select one of the memberof tabs you'll see the Add & Delete appear briefly then disappear immediately. Ideally they should appear only if the user has add/delete rights. * Also in self-service mode, the user can see the action drop down list and action box (of other users) but none of them actually works. -- Endi S. Dewata From mkosek at redhat.com Tue Mar 26 14:32:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Mar 2013 15:32:42 +0100 Subject: [Freeipa-devel] [PATCH] 397 Bump selinux-policy requires In-Reply-To: <514B14FC.9020704@redhat.com> References: <514B14FC.9020704@redhat.com> Message-ID: <5151B18A.1010004@redhat.com> On 03/21/2013 03:11 PM, Martin Kosek wrote: > The higher version is reported to fix a Fedora 17 to 18 upgrade issue. > > https://fedorahosted.org/freeipa/ticket/3399 > ACKed by Alexander on IRC, I was just advised to bump selinux-policy even more to 3.11.1-86 as it is in stable Fedora repo + fixes 916036 - done. Pushed to master, ipa-3-1 (rebased). Martin From pspacek at redhat.com Tue Mar 26 14:45:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 15:45:02 +0100 Subject: [Freeipa-devel] [PATCH 0131] Log plugin version during startup Message-ID: <5151B46E.5040502@redhat.com> Hello, Log plugin version during startup. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0131-Log-plugin-version-during-startup.patch Type: text/x-patch Size: 908 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 26 14:46:52 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 15:46:52 +0100 Subject: [Freeipa-devel] [PATCH 0132] Update NEWS file for upcoming 2.6 release Message-ID: <5151B4DC.2000107@redhat.com> Hello, Update NEWS file for upcoming 2.6 release. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0132-Update-NEWS-file-for-upcoming-2.6-release.patch Type: text/x-patch Size: 1567 bytes Desc: not available URL: From atkac at redhat.com Tue Mar 26 14:47:52 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 26 Mar 2013 15:47:52 +0100 Subject: [Freeipa-devel] [PATCH 0131] Log plugin version during startup In-Reply-To: <5151B46E.5040502@redhat.com> References: <5151B46E.5040502@redhat.com> Message-ID: <20130326144751.GA30207@redhat.com> On Tue, Mar 26, 2013 at 03:45:02PM +0100, Petr Spacek wrote: > Hello, > > Log plugin version during startup. Good idea, ack. > From ab91b26ee8ede6b2909f8dd8b305ed960752c55e Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 26 Mar 2013 15:43:52 +0100 > Subject: [PATCH] Log plugin version during startup. > > Signed-off-by: Petr Spacek > --- > src/zone_manager.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/src/zone_manager.c b/src/zone_manager.c > index c19c3b6c91ff8114fcb15eacba0f74ec46047986..c0006237ffbec8bf08caaa2e729c2808be65cf75 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -32,6 +32,7 @@ > > #include > > +#include "config.h" > #include "ldap_convert.h" > #include "ldap_helper.h" > #include "log.h" > @@ -61,6 +62,9 @@ initialize_manager(void) > { > INIT_LIST(instance_list); > isc_mutex_init(&instance_list_lock); > + log_info("bind-dyndb-ldap version " VERSION > + " compiled at " __TIME__ " " __DATE__ > + ", compiler " __VERSION__); > } > > void > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Mar 26 14:48:41 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 26 Mar 2013 15:48:41 +0100 Subject: [Freeipa-devel] [PATCH 0132] Update NEWS file for upcoming 2.6 release In-Reply-To: <5151B4DC.2000107@redhat.com> References: <5151B4DC.2000107@redhat.com> Message-ID: <20130326144840.GB30207@redhat.com> On Tue, Mar 26, 2013 at 03:46:52PM +0100, Petr Spacek wrote: > Hello, > > Update NEWS file for upcoming 2.6 release. Ack > From cd2a02874950ea9e045763c4a316069a00894d5b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 25 Mar 2013 17:22:36 +0100 > Subject: [PATCH] Update NEWS file for upcoming 2.6 release. > > Signed-off-by: Petr Spacek > --- > NEWS | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/NEWS b/NEWS > index 6dd09c118c86c4f5daf44bfbc5978600092b3d7f..78e16942ed551d0ec1a71f4865d02134c46ada87 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,6 +1,28 @@ > -[1] Automatically reload invalid zone after each change in zone data. > +2.6 > +===== > +[1] Invalid zones are automatically reloaded after each change in zone data. > https://fedorahosted.org/bind-dyndb-ldap/ticket/102 > > +[2] Plugin periodically reconnects when KDC is unavailable. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/100 > + > +[3] Invalid wildcard name in update-policy no longer crashes BIND. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/108 > + > +[4] Crash caused by idnsAllowSyncPTR attribute in global configuration object > + in LDAP was fixed. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/110 > + > +[5] Crash caused by invalid query/transfer policy was fixed. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/109 > + > +[6] Crash caused by 'zonesub' match-type in update ACL was fixed. > + https://fedorahosted.org/bind-dyndb-ldap/ticket/111 > + > +[7] Support for update-policy match type 'external' was added. > + > +[8] Various improvements related to logging. > + > 2.5 > ===== > [1] Fix crash during per-zone cache flush. > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Tue Mar 26 14:57:37 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 15:57:37 +0100 Subject: [Freeipa-devel] [PATCH 0133] Bump NVR to 2.6 Message-ID: <5151B761.4080100@redhat.com> Hello, Bump NVR to 2.6. I will do 2.6 release as soon as this will be pushed :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0133-Bump-NVR-to-2.6.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 26 15:00:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 16:00:44 +0100 Subject: [Freeipa-devel] [PATCH 0131] Log plugin version during startup In-Reply-To: <20130326144751.GA30207@redhat.com> References: <5151B46E.5040502@redhat.com> <20130326144751.GA30207@redhat.com> Message-ID: <5151B81C.4050806@redhat.com> On 26.3.2013 15:47, Adam Tkac wrote: > On Tue, Mar 26, 2013 at 03:45:02PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >Log plugin version during startup. > Good idea, ack. Pushed to master: 5aeaffd2008390e68e9ff8facaba38f54bc1587e v2: dca5eeb785d9cdd529a1bd757133023ea5560ac4 -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 26 15:00:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 16:00:49 +0100 Subject: [Freeipa-devel] [PATCH 0132] Update NEWS file for upcoming 2.6 release In-Reply-To: <20130326144840.GB30207@redhat.com> References: <5151B4DC.2000107@redhat.com> <20130326144840.GB30207@redhat.com> Message-ID: <5151B821.5020604@redhat.com> On 26.3.2013 15:48, Adam Tkac wrote: > On Tue, Mar 26, 2013 at 03:46:52PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >Update NEWS file for upcoming 2.6 release. > Ack Pushed to master: 5aeaffd2008390e68e9ff8facaba38f54bc1587e v2: 6d2812bf65758e370e2c98a4b1b32aab26f71dfd -- Petr^2 Spacek From atkac at redhat.com Tue Mar 26 15:27:58 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 26 Mar 2013 16:27:58 +0100 Subject: [Freeipa-devel] [PATCH 0133] Bump NVR to 2.6 In-Reply-To: <5151B761.4080100@redhat.com> References: <5151B761.4080100@redhat.com> Message-ID: <20130326152757.GA30613@redhat.com> On Tue, Mar 26, 2013 at 03:57:37PM +0100, Petr Spacek wrote: > Hello, > > Bump NVR to 2.6. > > > I will do 2.6 release as soon as this will be pushed :-) Ack > From 6e09c4cfb87fc946c0c199a0fafeb5a7149e5be0 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 26 Mar 2013 15:50:00 +0100 > Subject: [PATCH] Bump NVR to 2.6. > > Signed-off-by: Petr Spacek > --- > configure.ac | 2 +- > contrib/bind-dyndb-ldap.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index a40c49cc44063946522dc8b093660e00a6d2fee4..3b87f4878e45cb0280ee773e74b2cedaca7d4096 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1,5 +1,5 @@ > AC_PREREQ([2.59]) > -AC_INIT([bind-dyndb-ldap], [2.5], [freeipa-devel at redhat.com]) > +AC_INIT([bind-dyndb-ldap], [2.6], [freeipa-devel at redhat.com]) > > AM_INIT_AUTOMAKE([-Wall foreign dist-bzip2]) > > diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec > index d0e49eab8fb26a787385fbbdf5c03cf35026d73f..e145424dff117d46293eeb944e395d42773f9e72 100644 > --- a/contrib/bind-dyndb-ldap.spec > +++ b/contrib/bind-dyndb-ldap.spec > @@ -1,7 +1,7 @@ > %define VERSION %{version} > > Name: bind-dyndb-ldap > -Version: 2.5 > +Version: 2.6 > Release: 0%{?dist} > Summary: LDAP back-end plug-in for BIND > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Tue Mar 26 15:34:29 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Mar 2013 16:34:29 +0100 Subject: [Freeipa-devel] [PATCH 0133] Bump NVR to 2.6 In-Reply-To: <20130326152757.GA30613@redhat.com> References: <5151B761.4080100@redhat.com> <20130326152757.GA30613@redhat.com> Message-ID: <5151C005.3040400@redhat.com> On 26.3.2013 16:27, Adam Tkac wrote: > On Tue, Mar 26, 2013 at 03:57:37PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >Bump NVR to 2.6. >> > >> > >> >I will do 2.6 release as soon as this will be pushed:-) > Ack Pushed to v2: 695e7d352c515c3bd182356594a9f79e270f1172 -- Petr^2 Spacek From pviktori at redhat.com Tue Mar 26 15:48:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 26 Mar 2013 16:48:59 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0205 Installing without a CA, with custom SSL certs In-Reply-To: <514C5B04.4010101@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> Message-ID: <5151C36B.5090009@redhat.com> On 03/22/2013 02:22 PM, Petr Viktorin wrote: [...] > > Design is now at: http://freeipa.org/page/V3/CA-less_install > > Patch 199 deferred to https://fedorahosted.org/freeipa/ticket/3529 > > Updated patches attached. Orion Poplawski found a bug in the patches: the CA cert wasn't loaded into the server NSS databases, making install fail with PKCS#12 files that only contain the server cert. This additional patch fixes that. Note that certs for any *intermediate* CAs must be in the PKCS#12 file; only the root CA may be missing. So this is mainly for cases where the server cert is signed directly by the root CA. Thanks for testing! -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0205-Load-the-CA-cert-into-server-NSS-databases.patch Type: text/x-patch Size: 7524 bytes Desc: not available URL: From tbabej at redhat.com Tue Mar 26 15:59:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 26 Mar 2013 16:59:26 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA Message-ID: <5151C5DE.7090902@redhat.com> Hi, The ipa-replica-install script tries to add replica's A and PTR records to the master DNS, if master does manage DNS. However, master need not to manage replica's zone. Properly handle this use case. https://fedorahosted.org/freeipa/ticket/3496 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0043-Properly-handle-ipa-replica-install-when-its-zone-is.patch Type: text/x-patch Size: 2346 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 26 16:10:01 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 12:10:01 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5150928F.2010602@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> Message-ID: <5151C859.6040208@redhat.com> Petr Viktorin wrote: > On 03/23/2013 05:06 AM, Rob Crittenden wrote: >> There are strict limits on what can be restored where. Only exact >> matching hostnames and versions are allowed right now. We can probably >> relax the hostname requirement if we're only restoring data, and the >> version perhaps for only the the first two values (so you can restore a >> 3.0.0 backup on 3.0.1 but not on 3.1.0). > > Do we also need to limit the versions of Dogtag, 389, Kerberos...? > Or is what they put in /var/lib guaranteed portable across versions? An interesting question. I'd imagine that a major db change would also require a major update to IPA, therefore if we restrict by IPA version we should be ok. I AM doing an untar of files though so yeah, there is a risk here. > > > That's good to hear! > > I think while developing, you should run with -v to get all the output. > And for production, please have the commands log by default (set > log_file_name). Yes, I plan on adding that in the future. > >> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >> password because we need to contact remote servers to enable/disable >> replication. > > The restore assumes that ipa is already installed, right? I can't just > run it on a clean machine? Id would be good to check/document this. It depends. For a full backup you can actually restore to an uninstalled server. In fact, you could restore to a machine w/no IPA bits on it at all in all likelihood (which wouldn't be very nice, but not exactly wrong either IMHO). I tested this with: - ipa-server-install - ipa-backup - ipa-server-install --uninstall -U - ipa-restore - ran the unit tests > I looked in the backup tarball and saw dirsrv PID file and lock > directories. Are these needed? Probably not. I gathered some of the files to backup based on watching what files that changed during an install that are independent of us. I'll take another pass through it, there may be other oddities too. > The tool runners (install/tools/ipa-backup and > install/tools/ipa-restore) are missing, so IPA doesn't build. Probably > just a forgotten git add. Yup. > > The patch adds an extra backslash in install/tools/man/Makefile.am; > consider adding $(NULL) at the end. I'll take a look. > > Backup.dirs, Backup.files, Backup.logs: > The code modifies these class-level attributes. This means you can't run > the command more than once in one Python session, so it can't be used as > a library (e.g. in a hypothetical test suite). > Please make the class atrributes immutable (tuples), then in __init__ do > `self.dirs = list(self.dirs)` to to get instance-specific lists. Ok, fair point. > Code that creates temporary files/directories or does chdir() should be > next to (or in) a try block whose finally: restores things. Yes, I mean to add a big try/finally block around everything in run eventually (or the equivalent anyway). > > Instead of star imports (from ipapython.ipa_log_manager import *), > please explicitly import whatever you're using from that package. In > this case, nothing at all! Yeah, I haven't run this through pylint yet to see all the bad imports I cobbled together. > If there's a get_connection() method, it should return the connection, > and it should always be used to get it. Store the connection in > self._conn, and rather than: > self.get_connection() > self.conn.do_work() > do: > conn = self.get_connection() > conn.do_work() > This makes forgetting to call get_connection() impossible. My purpose was to avoid creating multiple connections. > If a variable is only used in a single method, like `filename` in > Restore.extract_backup, don't store it in the admintool object. > In general, try to avoid putting data in self if possible. It's > convenient but it allows complex interdependencies. > (Yes, I'm guilty of not following this myself.) Yes, there is certainly a bit of cleanup to do. I was in a bit of a rush to get this WIP out. > In several places, the backup tool logs critical errors and then just > continues on. Is that by design? I think a nonzero exit code would be > appropriate. I'll take a look at them, all I can say at this point is maybe. > In the ipa-restore man page, --backend is not documented. > > In db2ldif, db2bak, etc., a more conscise way to get the time string is > `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. > > When validating --gpg-keyring, it would be good to check both files > (.sec and .pub). Ok, I can do those. > > Here: > if (self.backup_type != 'FULL' and not options.data_only and > not instances): > raise admintool.ScriptError('Cannot restore a data backup into > an empty system') > did you mean `(self.backup_type != 'FULL' or options.data_only) and not > instances`? (I'd introduce a `data_only` flag to prevent confusion.) Yeah, looks like that should be an or. > In the ReplicationManager.check_repl_init reporting: use > int(d.total_seconds()) instead of d.seconds, as the latter doesn't > include full days. I don't think anyone would wait long enough for the > overflow, but better to be correct. Sure, I doubt anyone would wait 24 hours either but its a no-brainer to make it safe. rob From mkosek at redhat.com Tue Mar 26 16:19:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Mar 2013 17:19:19 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 3.1.3 Message-ID: <5151CA87.5000601@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.1.3. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/freeipa-3.1.3-1.fc18 This release includes backport of selected (mainly Trust related) features from upcoming FreeIPA 3.2.0 release. The following 3.1.x releases will contain primarily bugfixes only. == Highlights in 3.1.3 == === New features === * New cert-find command. Search certificates in the Dogtag database based on their serial number, validity or revocation details. This feature is available both as a CLI command and Web UI page. * New trustconfig-show and trustconfig-mod command. Show or modify AD Trust settings generated during AD Trust installation (ipa-adtrust-install) * New realmdomains-show and realmdomains-mod command. Manage list of domains managed by FreeIPA server. The list will be used in future releases to inform trusted domain about domains managed by FreeIPA. This feature is available both as a CLI command and Web UI page. * Support trusted domain users in HBAC test command (hbactest command). * Allow filtering incoming trusted domain SIDs per-trust (trust-mod command). * Faster UI loading. FreeIPA Web UI application is now packaged in minimalized format. FreeIPA web server is now also able to transmit data in compressed format. === Bug fixes === * Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and groups from OpenLDAP database instances. * Migration process is now also a lot faster and provides more debug output (to httpd error log). * SUDO rules disabled by sudorule-disable command are now removed from ou=sudoers compat tree without a need to restart 389 Directory Server instance. * Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release * Fixed server installation with external CA (--external-ca) * Consolidate on-line help system, show help without need of valid Kerberos credentials (ipa help) * ... and many others stabilization fixes, see Detailed changelog for full details == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users == Detailed Changelog since 3.1.2 == Alexander Bokovoy (2): * ipasam: use base scope when fetching domain information about own domain * Process exceptions when talking to Dogtag Ana Krivokapic (6): * Take into consideration services when deleting replicas * Add list of domains associated to our realm to cn=etc * Remove check for alphabetic only characters from domain name validation * Fix internal error for ipa show-mappings * Realm Domains page * Use default NETBIOS name in unattended ipa-adtrust-install Jakub Hrozek (1): * Allow ipa-replica-conncheck and ipa-adtrust-install to read krb5 includedir Jan Cholasta (6): * Pylint cleanup. * Raise ValidationError on invalid CSV values. * Run interactive_prompt callbacks after CSV values are split. * Fix remove while iterating in suppress_netgroup_memberof. * Remove disabled entries from sudoers compat tree. * Fix internal error in output_for_cli method of sudorule_{enable,disable}. Martin Kosek (33): * Fix migration for openldap DS * Remove unused krbV imports * Use fully qualified CCACHE names * Fix permission_find test error * Add trusconfig-show and trustconfig-mod commands * ipa-kdb: add sentinel for LDAPDerefSpec allocation * ipa-kdb: avoid ENOMEM when all SIDs are filtered out * ipa-kdb: reinitialize LDAP configuration for known realms * Add SID blacklist attributes * ipa-kdb: read SID blacklist from LDAP * ipa-sam: Fill SID blacklist when trust is added * ipa-adtrust-install should ask for SID generation * Test NetBIOS name clash before creating a trust * Generalize AD GC search * Do not hide SID resolver error in group-add-member * Add support for AD users to hbactest command * Fix hbachelp examples formatting * ipa-kdb: remove memory leaks * ipa-kdb: fix retry logic in ipadb_deref_search * Add autodiscovery section in ipa-client-install man pages * Avoid internal error when user is not Trust admin * Use fixed test domain in realmdomains test * Remove ORDERING for IA5 attributeTypes * Fix includedir directive in krb5.conf template * Preserve order of servers in ipa-client-install * Avoid multiple client discovery with fixed server list * Fix client discovery crash * ipa-client discovery with anonymous access off * Use temporary CCACHE in ipa-client-install * Improve client install LDAP cert retrieval fallback * Configure ipa_dns DS plugin on install and upgrade * Bump selinux-policy requires * Become 3.1.3 Petr Spacek (1): * Add 389 DS plugin for special idnsSOASerial attribute handling Petr Viktorin (23): * Add the CA cert to LDAP after the CA install * Port ipa-replica-prepare to the admintool framework * Don't add another nsDS5ReplicaId on updates if one already exists * Improve `ipa --help` output * Print help to stderr on error * Store the OptionParser in the API, use it to print unified help messages * Simplify `ipa help topics` output * Add command summary to `ipa COMMAND --help` output * Mention `ipa COMMAND --help` as the preferred way to get command help * Parse command arguments before creating a context * Add tests for the help command & --help options * In topic help text, mention how to get help for commands * Check SSH connection in ipa-replica-conncheck * Use ipauniqueid for the RDN of sudo commands * Prevent a sudo command from being deleted if it is a member of a sudo rule * Update sudocmd ACIs to use targetfilter * Add the version option to all Commands * Add ipalib.messages * Add client capabilities, enable messages * Rename the "messages" Output of the i18n_messages command to "texts" * Fix permission validation and normalization in aci.py * cli: Do interactive prompting after a context is created * Fix installing server with external CA Petr Vobornik (36): * Make confirm_dialog a base class of revoke and restore certificate dialogs * Make confirm_dialog a base class for deleter dialog * Make confirm_dialog a base class for message_dialog * Confirm mixin * Confirm adder dialog by enter * Confirm error dialog by enter * Focus last dialog when some is closed * Confirm association dialogs by enter * Standardize login password reset, user reset password and host set OTP dialogs * Focus first input element after 'Add and Add another' * Enable mod_deflate * Use Uglify.js for JS optimization * Dojo Builder * Config files for builder of FreeIPA UI layer * Minimal Dojo layer * Web UI development environment directory structure and configuration * Web UI Sync development utility * Move of Web UI non AMD dep. libs to libs subdirectory * Move of core Web UI files to AMD directory * Update JavaScript Lint configuration file * AMD config file * Change Web UI sources to simple AMD modules * Updated makefiles to build FreeIPA Web UI layer * Change tests to use AMD loader * Fix BuildRequires: rhino replaced with java-1.7.0-openjdk * Develop.js extended * Allow to specify modules for which builder doesn't raise dependency error * Web UI build profile updated * Combobox keyboard support * Fix dirty state update of editable combobox * Fix handling of no_update flag in Web UI * Web UI: configurable SID blacklists * Web UI:Certificate pages * Web UI:Choose different search option for cert-find * Added Web UI support for service PAC type option: NONE * Load extension.js after UI AMD modules. Rob Crittenden (10): * Make certmonger a (pre) requires on server, restart it before upgrading * Use new certmonger locking to prevent NSS database corruption. * Better logging for AdminTool and ipa-ldap-updater * Improve migration performance * Add LDAP server fallback to client installer * Prevent a crash when no entries are successfully migrated. * Implement the cert-find command for the dogtag CA backend. * Add missing v3 schema on upgrades, fix typo in schema. * Don't base64-encode the CA cert when uploading it during an upgrade. * Improve some error handling in ipa-replica-manage Sumit Bose (7): * ipa-kdb: remove unused variable * ipa-kdb: Uninitialized scalar variable in ipadb_reinit_mspac() * ipa-sam: Array compared against 0 in ipasam_set_trusted_domain() * ipa-kdb: Dereference after null check in ipa_kdb_mspac.c * ipa-lockout: Wrong sizeof argument in ipa_lockout.c * ipa-extdom: Double-free in ipa_extdom_common.c * ipa-pwd: Unchecked return value ipapwd_chpwop() Tomas Babej (13): * Fix a typo in ipa-adtrust-install help * Prevent integer overflow when setting krbPasswordExpiration * Add option to specify SID using domain name to idrange-add/mod * Prevent changing protected group's name using --setattr * Use default.conf as flag of IPA client being installed * Make sure appropriate exit status is returned in make-test * Make options checks in idrange-add/mod consistent * Add trusted domain range objectclass when using idrange-mod * Perform secondary rid range overlap check for local ranges only * Make sure uninstall script prompts for reboot as last * Remove implicit Str to DN conversion using *-attr * Enforce exact SID match when adding or modifying a ID range * Add logging to join command sbose (1): * ipa-kdb: Free talloc autofree context when module is closed -- Martin Kosek Senior Software Engineer - Identity Management Team Red Hat Inc. From mkosek at redhat.com Tue Mar 26 16:38:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Mar 2013 17:38:02 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes In-Reply-To: <514AE827.2080909@redhat.com> References: <514AE827.2080909@redhat.com> Message-ID: <5151CEEA.7080302@redhat.com> On 03/21/2013 11:59 AM, Martin Kosek wrote: > This set of patches (details in commit messages) allow build and installation > of FreeIPA in Fedora 19. I tested server and replica install (master on f18, > replica on f19) and both worked fine. > > The patches are compatible with Fedora 18 (I tested). > > If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need to get that > from koji: > > Bug 920713 - named timeouts when started via systemd > > Also, to fix trusts and ipa-adtrust-install, I had to use my custom build of > 389-ds-base as current builds do not accepts Kerberos tickets greater than 2048 > bytes. This is the bug I filed: > > Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC > > Martin > Sending rebased patches (there was a conflic in spec changelog). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-391-2-remove-conflict-with-krb5-1.11.patch Type: text/x-patch Size: 1907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-392-2-remove-build-warnings.patch Type: text/x-patch Size: 13797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-393-2-remove-syslog.target-from-ipa.server.patch Type: text/x-patch Size: 1843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-394-2-put-pid-file-to-named.conf.patch Type: text/x-patch Size: 3802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-395-2-update-mod_wsgi-socket-directory.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From tbabej at redhat.com Tue Mar 26 17:32:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 26 Mar 2013 18:32:52 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes In-Reply-To: <5151CEEA.7080302@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> Message-ID: <5151DBC4.3090901@redhat.com> On 03/26/2013 05:38 PM, Martin Kosek wrote: > On 03/21/2013 11:59 AM, Martin Kosek wrote: >> This set of patches (details in commit messages) allow build and installation >> of FreeIPA in Fedora 19. I tested server and replica install (master on f18, >> replica on f19) and both worked fine. >> >> The patches are compatible with Fedora 18 (I tested). >> >> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need to get that >> from koji: >> >> Bug 920713 - named timeouts when started via systemd >> >> Also, to fix trusts and ipa-adtrust-install, I had to use my custom build of >> 389-ds-base as current builds do not accepts Kerberos tickets greater than 2048 >> bytes. This is the bug I filed: >> >> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >> >> Martin >> > Sending rebased patches (there was a conflic in spec changelog). > > Martin > This still needs the following rebase (changelog is not in chronological order): -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 The build on F19 went OK, however, IPA installation on F19 fails with the following error: [snip] Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance Unexpected error - see /var/log/ipaserver-install.log for details: IOError: [Errno 2] No such file or directory: '/root/.pki/pki-tomcat/ca_admin_cert.p12' Patches work fine on F18. Tomas From mkosek at redhat.com Tue Mar 26 17:49:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Mar 2013 18:49:59 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes In-Reply-To: <5151DBC4.3090901@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> Message-ID: <5151DFC7.5090209@redhat.com> On 03/26/2013 06:32 PM, Tomas Babej wrote: > On 03/26/2013 05:38 PM, Martin Kosek wrote: >> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>> This set of patches (details in commit messages) allow build and installation >>> of FreeIPA in Fedora 19. I tested server and replica install (master on f18, >>> replica on f19) and both worked fine. >>> >>> The patches are compatible with Fedora 18 (I tested). >>> >>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need to get that >>> from koji: >>> >>> Bug 920713 - named timeouts when started via systemd >>> >>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom build of >>> 389-ds-base as current builds do not accepts Kerberos tickets greater than 2048 >>> bytes. This is the bug I filed: >>> >>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>> >>> Martin >>> >> Sending rebased patches (there was a conflic in spec changelog). >> >> Martin >> > This still needs the following rebase (changelog is not in chronological order): > > -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 > +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 Right, I will fix that. > > The build on F19 went OK, however, IPA installation on F19 fails with the > following error: > > [snip] > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/20]: creating certificate server user > [2/20]: configuring certificate server instance > Unexpected error - see /var/log/ipaserver-install.log for details: > IOError: [Errno 2] No such file or directory: > '/root/.pki/pki-tomcat/ca_admin_cert.p12' What pki-ca version do you use? There were some related fixes for bugs I found in pki-ca component (see Bug 919476). I used pki-ca-10.0.1-2.1.fc19.noarch If you have this version or higher, what is the root cause of the failure? Is there any useful info in ipaserver-install.log? Thanks, Martin > > > Patches work fine on F18. > > Tomas From edewata at redhat.com Tue Mar 26 17:55:08 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Mar 2013 12:55:08 -0500 Subject: [Freeipa-devel] [PATCH] 271, 272 Added Web UI support for service PAC type option: NONE In-Reply-To: <515038FC.4050307@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> <5138980F.8070205@redhat.com> <5143A503.4020409@redhat.com> <515038FC.4050307@redhat.com> Message-ID: <5151E0FC.8080909@redhat.com> On 3/25/2013 6:46 AM, Petr Vobornik wrote: > Reimplemented ^^ to match your proposal. Attaching as patches with new > numbers (271,272) as they don't have much common with the original patch. The code looks good. Do you have a static/live demo site? -- Endi S. Dewata From akrivoka at redhat.com Tue Mar 26 18:45:20 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 26 Mar 2013 19:45:20 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install Message-ID: <5151ECC0.60005@redhat.com> Add the option to create home directories for users on their first login to ipa-server-install and ipa-replica-install. https://fedorahosted.org/freeipa/ticket/3515 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0010-Add-mkhomedir-option-to-ipa-server-install-and-ipa-r.patch Type: text/x-patch Size: 4592 bytes Desc: not available URL: From orion at cora.nwra.com Tue Mar 26 18:51:32 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 26 Mar 2013 12:51:32 -0600 Subject: [Freeipa-devel] git versions for rpms in makefile Message-ID: <5151EE34.8060400@cora.nwra.com> This patch uses the Fedora standard for git versioning (version-#.git) when making rpms. I'm afraid I haven't been able to test for the non-git version case. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-Fedora-git-versioning-for-rpms.patch Type: text/x-patch Size: 5765 bytes Desc: not available URL: From xkubat11 at gmail.com Tue Mar 26 19:46:53 2013 From: xkubat11 at gmail.com (=?ISO-8859-1?Q?Petr_Kub=E1t?=) Date: Tue, 26 Mar 2013 20:46:53 +0100 Subject: [Freeipa-devel] Modular PSKC document parser Message-ID: Hello everyone, I am a student at the Brno University of Technology and am working on my bachelor's thesis in cooperation with Red Hat (my supervisor is Jan Zeleny). The project is basically a Portable Symmetric Key Container (PSKC) document parser written in Python with modules to store the parsed information into various storage formats. I will also be designing and implementing a module to store the information into a 389 Directory Server and as such was told by my supervisor to ask you if you would be interested in the project for the FreeIPA solution. Regards, Petr Kubat -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Tue Mar 26 20:43:16 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 26 Mar 2013 14:43:16 -0600 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs Message-ID: <51520864.30004@cora.nwra.com> The current makefile make assumptions about people not redefining _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying all needed directories. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Define-all-needed-rpmbuild-dirs.patch Type: text/x-patch Size: 2035 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 26 23:02:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 19:02:45 -0400 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs In-Reply-To: <51520864.30004@cora.nwra.com> References: <51520864.30004@cora.nwra.com> Message-ID: <51522915.3030002@redhat.com> Orion Poplawski wrote: > The current makefile make assumptions about people not redefining > _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying > all needed directories. Don't we force RPMBUILD to be the local build directory? Why would you want to specify the files to be written elsewhere? rob From orion at cora.nwra.com Tue Mar 26 23:04:13 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 26 Mar 2013 17:04:13 -0600 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs In-Reply-To: <51522915.3030002@redhat.com> References: <51520864.30004@cora.nwra.com> <51522915.3030002@redhat.com> Message-ID: <5152296D.50202@cora.nwra.com> On 03/26/2013 05:02 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> The current makefile make assumptions about people not redefining >> _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying >> all needed directories. > > Don't we force RPMBUILD to be the local build directory? Why would you want to > specify the files to be written elsewhere? > > rob You are assuming that by defining _topdir it is enough. But some people (like myself) redefine _specdir, etc. e.g.: %_rpmtopdir %{_topdir}/%{name}-%{version} %_builddir %{_rpmtopdir} %_rpmdir %{_topdir}/RPMS %_sourcedir %{_rpmtopdir} %_specdir %{_rpmtopdir} %_srcrpmdir %{_rpmtopdir} So the patch makes sure to actually define the macros you need to point to the locations you want. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Tue Mar 26 23:14:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 19:14:11 -0400 Subject: [Freeipa-devel] git versions for rpms in makefile In-Reply-To: <5151EE34.8060400@cora.nwra.com> References: <5151EE34.8060400@cora.nwra.com> Message-ID: <51522BC3.9080108@redhat.com> Orion Poplawski wrote: > This patch uses the Fedora standard for git versioning > (version-#.git) when making rpms. I'm afraid I haven't been able > to test for the non-git version case. What is the purpose of this? We don't do upstream releases from developer build, so having the wrong Source0 doesn't seem like a big deal (though I'll admit no strictly correct). rob From rcritten at redhat.com Tue Mar 26 23:25:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 19:25:45 -0400 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs In-Reply-To: <5152296D.50202@cora.nwra.com> References: <51520864.30004@cora.nwra.com> <51522915.3030002@redhat.com> <5152296D.50202@cora.nwra.com> Message-ID: <51522E79.1010703@redhat.com> Orion Poplawski wrote: > On 03/26/2013 05:02 PM, Rob Crittenden wrote: >> Orion Poplawski wrote: >>> The current makefile make assumptions about people not redefining >>> _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying >>> all needed directories. >> >> Don't we force RPMBUILD to be the local build directory? Why would you >> want to >> specify the files to be written elsewhere? >> >> rob > > You are assuming that by defining _topdir it is enough. But some people > (like myself) redefine _specdir, etc. e.g.: > > %_rpmtopdir %{_topdir}/%{name}-%{version} > %_builddir %{_rpmtopdir} > %_rpmdir %{_topdir}/RPMS > %_sourcedir %{_rpmtopdir} > %_specdir %{_rpmtopdir} > %_srcrpmdir %{_rpmtopdir} > > So the patch makes sure to actually define the macros you need to point > to the locations you want. > But why would you want to? We do this specifically to keep everything within the development tree. rob From simo at redhat.com Wed Mar 27 01:31:48 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 26 Mar 2013 21:31:48 -0400 Subject: [Freeipa-devel] Modular PSKC document parser In-Reply-To: References: Message-ID: <1364347908.2660.148.camel@willson.li.ssimo.org> On Tue, 2013-03-26 at 20:46 +0100, Petr Kub?t wrote: > Hello everyone, > > > I am a student at the Brno University of Technology and am working on > my bachelor's thesis in cooperation with Red Hat (my supervisor is Jan > Zeleny). > The project is basically a Portable Symmetric Key Container (PSKC) > document parser written in Python with modules to store the parsed > information into various storage formats. I will also be designing and > implementing a module to store the information into a 389 Directory > Server and as such was told by my supervisor to ask you if you would > be interested in the project for the FreeIPA solution. It may be interesting, can you give us a bit more background on the project and what kind usage do you see it valuable for? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Mar 27 01:36:25 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 26 Mar 2013 21:36:25 -0400 Subject: [Freeipa-devel] git versions for rpms in makefile In-Reply-To: <51522BC3.9080108@redhat.com> References: <5151EE34.8060400@cora.nwra.com> <51522BC3.9080108@redhat.com> Message-ID: <1364348185.2660.150.camel@willson.li.ssimo.org> On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote: > Orion Poplawski wrote: > > This patch uses the Fedora standard for git versioning > > (version-#.git) when making rpms. I'm afraid I haven't been able > > to test for the non-git version case. > > What is the purpose of this? We don't do upstream releases from > developer build, so having the wrong Source0 doesn't seem like a big > deal (though I'll admit no strictly correct). Sound like a reasonable improvement to me, and makes it sure you do not confuse an upstream build with a developer build, I am not so sure about using __GIT__, it's kinda annoying to type, although shell completion here helps I guess. I lean toward acking this approach, if you do not have objections Rob. Simo. -- Simo Sorce * Red Hat, Inc * New York From orion at cora.nwra.com Wed Mar 27 02:41:47 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 26 Mar 2013 20:41:47 -0600 Subject: [Freeipa-devel] git versions for rpms in makefile In-Reply-To: <1364348185.2660.150.camel@willson.li.ssimo.org> References: <5151EE34.8060400@cora.nwra.com> <51522BC3.9080108@redhat.com> <1364348185.2660.150.camel@willson.li.ssimo.org> Message-ID: <51525C6B.90501@cora.nwra.com> On 03/26/2013 07:36 PM, Simo Sorce wrote: > On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote: >> Orion Poplawski wrote: >>> This patch uses the Fedora standard for git versioning >>> (version-#.git) when making rpms. I'm afraid I haven't been able >>> to test for the non-git version case. >> >> What is the purpose of this? We don't do upstream releases from >> developer build, so having the wrong Source0 doesn't seem like a big >> deal (though I'll admit no strictly correct). > > Sound like a reasonable improvement to me, and makes it sure you do not > confuse an upstream build with a developer build, I am not so sure about > using __GIT__, it's kinda annoying to type, although shell completion > here helps I guess. > > I lean toward acking this approach, if you do not have objections Rob. > > Simo. My motivation for this was from testing the pkcs12 patches. First I did an srpm build and got 3.1.99GITec94138-0.fc18.src.rpm. Then I updated the git repo, did another srpm build and got 3.1.99GIT5acd43d-1.fc18.src.rpm which would have been lower EVR wise. Now I can get: 3.1.99-1.GIT5acd43d.fc18.src.rpm which would have been newer than 3.1.99-0.GITec94138.fc18.src.rpm and allowed me to do yum update. (actually, for pre-releases it should be -0.1.GIT, -0.2.GIT, ...) So it doesn't impact releases, just local developer testing - which I don't know how much is done via rpms. I also wouldn't expect you would ever have to type __GIT__, why do think you would? That is just in the spec.in and gets substituted out for the GIT. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Wed Mar 27 02:50:57 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 26 Mar 2013 20:50:57 -0600 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs In-Reply-To: <51522E79.1010703@redhat.com> References: <51520864.30004@cora.nwra.com> <51522915.3030002@redhat.com> <5152296D.50202@cora.nwra.com> <51522E79.1010703@redhat.com> Message-ID: <51525E91.1010408@cora.nwra.com> On 03/26/2013 05:25 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> On 03/26/2013 05:02 PM, Rob Crittenden wrote: >>> Orion Poplawski wrote: >>>> The current makefile make assumptions about people not redefining >>>> _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying >>>> all needed directories. >>> >>> Don't we force RPMBUILD to be the local build directory? Why would you >>> want to >>> specify the files to be written elsewhere? >>> >>> rob >> >> You are assuming that by defining _topdir it is enough. But some people >> (like myself) redefine _specdir, etc. e.g.: >> >> %_rpmtopdir %{_topdir}/%{name}-%{version} >> %_builddir %{_rpmtopdir} >> %_rpmdir %{_topdir}/RPMS >> %_sourcedir %{_rpmtopdir} >> %_specdir %{_rpmtopdir} >> %_srcrpmdir %{_rpmtopdir} >> >> So the patch makes sure to actually define the macros you need to point >> to the locations you want. >> > > But why would you want to? We do this specifically to keep everything > within the development tree. > > rob Because this is how I like to organize my *personal* rpm development tree (and is what is in my ~/.rpmmacros). But when I did a make srpm in the freeipa directory it looked for the spec in freeipa/rpmbuild/freeipa-3.1.99GIT.../ instead of freeipa/rpmbuild/SPECS, merging my definition of _specdir with freeipa's _topdir. Adding the needed --defines overrides my ~/.rpmmacros. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rcritten at redhat.com Wed Mar 27 03:52:23 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 23:52:23 -0400 Subject: [Freeipa-devel] git versions for rpms in makefile In-Reply-To: <51525C6B.90501@cora.nwra.com> References: <5151EE34.8060400@cora.nwra.com> <51522BC3.9080108@redhat.com> <1364348185.2660.150.camel@willson.li.ssimo.org> <51525C6B.90501@cora.nwra.com> Message-ID: <51526CF7.3040608@redhat.com> Orion Poplawski wrote: > On 03/26/2013 07:36 PM, Simo Sorce wrote: >> On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote: >>> Orion Poplawski wrote: >>>> This patch uses the Fedora standard for git versioning >>>> (version-#.git) when making rpms. I'm afraid I haven't been able >>>> to test for the non-git version case. >>> >>> What is the purpose of this? We don't do upstream releases from >>> developer build, so having the wrong Source0 doesn't seem like a big >>> deal (though I'll admit no strictly correct). >> >> Sound like a reasonable improvement to me, and makes it sure you do not >> confuse an upstream build with a developer build, I am not so sure about >> using __GIT__, it's kinda annoying to type, although shell completion >> here helps I guess. >> >> I lean toward acking this approach, if you do not have objections Rob. >> >> Simo. > > My motivation for this was from testing the pkcs12 patches. First I did > an srpm build and got 3.1.99GITec94138-0.fc18.src.rpm. Then I updated > the git repo, did another srpm build and got > 3.1.99GIT5acd43d-1.fc18.src.rpm which would have been lower EVR wise. > Now I can get: > > 3.1.99-1.GIT5acd43d.fc18.src.rpm > > which would have been newer than > > 3.1.99-0.GITec94138.fc18.src.rpm > > and allowed me to do yum update. > > (actually, for pre-releases it should be -0.1.GIT, -0.2.GIT, ...) > > So it doesn't impact releases, just local developer testing - which I > don't know how much is done via rpms. > > I also wouldn't expect you would ever have to type __GIT__, why do think > you would? That is just in the spec.in and gets substituted out for the > GIT. The root of the problem is the release in n-v-r is always the same value in builds because it makes no difference in a developer build. So either this patch needs to go farther and generate a real value for RELEASE or it just shifts the problem. For pre-releases you build with IPA_VERSION_IS_GIT_SNAPSHOT=no and the values from the file VERSION are used. I generally build and develop on the same machine so a repo never comes into play and use rpm --force -Uvh dist/rpms/* to update. rob From rcritten at redhat.com Wed Mar 27 03:56:09 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Mar 2013 23:56:09 -0400 Subject: [Freeipa-devel] [PATCH] Define all needed rpmbuild dirs In-Reply-To: <51525E91.1010408@cora.nwra.com> References: <51520864.30004@cora.nwra.com> <51522915.3030002@redhat.com> <5152296D.50202@cora.nwra.com> <51522E79.1010703@redhat.com> <51525E91.1010408@cora.nwra.com> Message-ID: <51526DD9.6010702@redhat.com> Orion Poplawski wrote: > On 03/26/2013 05:25 PM, Rob Crittenden wrote: >> Orion Poplawski wrote: >>> On 03/26/2013 05:02 PM, Rob Crittenden wrote: >>>> Orion Poplawski wrote: >>>>> The current makefile make assumptions about people not redefining >>>>> _specdir/_rpmdir/_srpmdir. This patch gets around that by specifying >>>>> all needed directories. >>>> >>>> Don't we force RPMBUILD to be the local build directory? Why would you >>>> want to >>>> specify the files to be written elsewhere? >>>> >>>> rob >>> >>> You are assuming that by defining _topdir it is enough. But some people >>> (like myself) redefine _specdir, etc. e.g.: >>> >>> %_rpmtopdir %{_topdir}/%{name}-%{version} >>> %_builddir %{_rpmtopdir} >>> %_rpmdir %{_topdir}/RPMS >>> %_sourcedir %{_rpmtopdir} >>> %_specdir %{_rpmtopdir} >>> %_srcrpmdir %{_rpmtopdir} >>> >>> So the patch makes sure to actually define the macros you need to point >>> to the locations you want. >>> >> >> But why would you want to? We do this specifically to keep everything >> within the development tree. >> >> rob > > Because this is how I like to organize my *personal* rpm development > tree (and is what is in my ~/.rpmmacros). But when I did a make srpm in > the freeipa directory it looked for the spec in > freeipa/rpmbuild/freeipa-3.1.99GIT.../ instead of > freeipa/rpmbuild/SPECS, merging my definition of _specdir with freeipa's > _topdir. Adding the needed --defines overrides my ~/.rpmmacros. > But why would you do it that way vs make rpms? What is the work flow? As I said, this was an intentional change *because* it was interfering with those that had custom rpm configurations. What is the need to build an srpm and then rpms from that when you are working inside a git tree? There is no need to snapshot the source because git does that for you. That was our reasoning anyway. rob From pspacek at redhat.com Wed Mar 27 09:01:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 Mar 2013 10:01:53 +0100 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 2.6 Message-ID: <5152B581.2040003@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 2.6. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-2.6-1.fc18,bind-9.9.2-9.P1.fc18 This release includes only bug fixes, no new features. == Changes in 2.6 == [1] Invalid zones are automatically reloaded after each change in zone data. https://fedorahosted.org/bind-dyndb-ldap/ticket/102 [2] Plugin periodically reconnects when KDC is unavailable. https://fedorahosted.org/bind-dyndb-ldap/ticket/100 [3] Invalid wildcard name in update-policy no longer crashes BIND. https://fedorahosted.org/bind-dyndb-ldap/ticket/108 [4] Crash caused by idnsAllowSyncPTR attribute in global configuration object in LDAP was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/110 [5] Crash caused by invalid query/transfer policy was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/109 [6] Crash caused by 'zonesub' match-type in update ACL was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/111 [7] Support for update-policy match type 'external' was added. [8] Various improvements related to logging. == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. Downgrading back to any 2.x version is supported. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From tbabej at redhat.com Wed Mar 27 09:42:19 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 27 Mar 2013 10:42:19 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes In-Reply-To: <5151DFC7.5090209@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> <5151DFC7.5090209@redhat.com> Message-ID: <5152BEFB.2040408@redhat.com> On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: > On 03/26/2013 06:32 PM, Tomas Babej wrote: >> On 03/26/2013 05:38 PM, Martin Kosek wrote: >>> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>>> This set of patches (details in commit messages) allow build and >>>> installation >>>> of FreeIPA in Fedora 19. I tested server and replica install >>>> (master on f18, >>>> replica on f19) and both worked fine. >>>> >>>> The patches are compatible with Fedora 18 (I tested). >>>> >>>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need >>>> to get that >>>> from koji: >>>> >>>> Bug 920713 - named timeouts when started via systemd >>>> >>>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom >>>> build of >>>> 389-ds-base as current builds do not accepts Kerberos tickets >>>> greater than 2048 >>>> bytes. This is the bug I filed: >>>> >>>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>>> >>>> Martin >>>> >>> Sending rebased patches (there was a conflic in spec changelog). >>> >>> Martin >>> >> This still needs the following rebase (changelog is not in >> chronological order): >> >> -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 >> +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 > > Right, I will fix that. > >> >> The build on F19 went OK, however, IPA installation on F19 fails with >> the >> following error: >> >> [snip] >> Configuring certificate server (pki-tomcatd): Estimated time 3 >> minutes 30 seconds >> [1/20]: creating certificate server user >> [2/20]: configuring certificate server instance >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IOError: [Errno 2] No such file or directory: >> '/root/.pki/pki-tomcat/ca_admin_cert.p12' > > What pki-ca version do you use? There were some related fixes for bugs > I found in pki-ca component (see Bug 919476). I used > pki-ca-10.0.1-2.1.fc19.noarch > The version is the same. > If you have this version or higher, what is the root cause of the > failure? Is there any useful info in ipaserver-install.log? > I haven't been able to identify the cause. There seems to be an issue with certmonger as well, since consenquent uninstallation fails with: $ sudo ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unexpected error - see /var/log/ipaserver-uninstall.log for details: CalledProcessError: Command '/bin/systemctl start certmonger.service' returned non-zero exit status 1 Looking at systemctl status certmonger.service, it looks like D-Bus connection problem: $ sudo service certmonger status Redirecting to /bin/systemctl status certmonger.service certmonger.service - Certificate monitoring and PKI enrollment Loaded: loaded (/usr/lib/systemd/system/certmonger.service; disabled) Active: failed (Result: exit-code) since Wed 2013-03-27 10:06:08 CET; 2s ago Process: 5870 ExecStart=/usr/sbin/certmonger -S -p /var/run/certmonger.pid -n $OPTS (code=exited, status=1/FAILURE) Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Starting Certificate monitoring and PKI enrollment... Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com certmonger[5870]: 2013-03-27 10:06:08 [5870] Error connecting to system bus. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com certmonger[5870]: Error connecting to D-Bus. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: certmonger.service: main process exited, code=exited, status=1/FAILURE Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Failed to start Certificate monitoring and PKI enrollment. Mar 27 10:06:08 vm-093.idm.lab.eng.brq.redhat.com systemd[1]: Unit certmonger.service entered failed state Relevant part of the log (we already went through it with Martin, but maybe somebody has some additional insight). 2013-03-26T17:03:06Z DEBUG Starting external process 2013-03-26T17:03:06Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp4CgKef 2013-03-26T17:03:19Z DEBUG Process finished, return code=0 2013-03-26T17:03:19Z DEBUG stdout= 2013-03-26T17:03:19Z DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and 'journalctl -xn' for details. *sys-package-mgr*: processing new jar, '/usr/share/java/jython.jar' *sys-package-mgr*: processing new jar, '/usr/share/java/jakarta-oro.jar' [snip] *sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/ext/pulse-java.jar' Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: I/O exception (org.mozilla.jss.ssl.SSLSocketException) caught when connecting to the target host: Unable to connect: (-5961) TCP connection reset by peer. Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect INFO: I/O exception (org.mozilla.jss.ssl.SSLSocketException) caught when connecting to the target host: Unable to connect: (-5961) TCP connection reset by peer. Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: I/O exception (org.mozilla.jss.ssl.SSLSocketException) caught when connecting to the target host: Unable to connect: (-5961) TCP connection reset by peer. Mar 26, 2013 6:03:19 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect Traceback (innermost last): File "/usr/lib/python2.7/site-packages/pki/deployment/configuration.jy", line 110, in ? File "/usr/lib/python2.7/site-packages/pki/deployment/configuration.jy", line 107, in main File "/usr/lib/python2.7/site-packages/pki/deployment/pkijython.py", line 531, in configure_pki_data at org.jboss.resteasy.client.core.ClientInvoker.invoke(ClientInvoker.java:114) at org.jboss.resteasy.client.core.ClientProxy.invoke(ClientProxy.java:88) at sun.proxy.$Proxy20.configure(Unknown Source) at com.netscape.certsrv.system.SystemConfigClient.configure(SystemConfigClient.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) java.lang.RuntimeException: java.lang.RuntimeException: org.mozilla.jss.ssl.SSLSocketException: Unable to connect: (-5961) TCP connection reset by peer. 2013-03-26T17:03:19Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 612, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 999, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 618, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 359, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 747, in __spawn_instance "/root/ca-agent.p12") File "/usr/lib64/python2.7/shutil.py", line 299, in move copy2(src, real_dst) File "/usr/lib64/python2.7/shutil.py", line 128, in copy2 copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: 2013-03-26T17:03:19Z INFO The ipa-server-install command failed, exception: IOError: [Errno 2] No such file or directory: '/root/.pki/pki-tomcat/ca_admin_cert.p12' > Thanks, > Martin > >> >> >> Patches work fine on F18. >> >> Tomas > From sbose at redhat.com Wed Mar 27 09:50:22 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 27 Mar 2013 10:50:22 +0100 Subject: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam In-Reply-To: <20130325180744.GH6823@redhat.com> References: <20130325180744.GH6823@redhat.com> Message-ID: <20130327095021.GE2112@localhost.localdomain> On Mon, Mar 25, 2013 at 08:07:44PM +0200, Alexander Bokovoy wrote: > Hi, > > following patch allows to enumerate UPN suffixes associated with IPA > domain and make them available to AD domain we trust. > > The patch relies on PASSDB API expansion I'm working on and as such > requires Samba built with the change. You can find F18 scratch build at > http://koji.fedoraproject.org/koji/taskinfo?taskID=5168969, these > patches will be submitted to Samba upstream this week. > > In the patch I'm filtering out our own DNS domain since its value will > be added by Samba by default -- if PASSDB module does not provide the > function, its absence will be ignored in the new API. Filtering out is > done by freeing the string and moving empty item to last position in the > array, reducing the array size but not resizing it -- talloc will hardly > win anything from resizing one (char *) pointer and actual lifetime of > the array is until the packet is sent so it is acceptable. > > In order to test the patch, you need updated Samba, then rebuild FreeIPA > packages. Once installed and configured, UPN suffixes can be managed via > 'ipa realmdomains-mod --{add,dell}-domain' commands. These domains will > be exposed to Windows. > > When you added realm domains, an attempt to establish trust will cause > Windows to ask for name suffixes and Samba will serve expanded list of > them via netr_GetTrustInformation (opnum 44). In Samba code I've also > implemented partially opnum 43 which is giving out the same information > via DsRGetTrustInformation but so far Windows AD DC haven't actually > tried to use opnum 43. > > Additionally, you can request Windows to update list of name suffixes > via UI. Here is how it looks in Windows 2012 Server: > http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png > > Part of ticket https://fedorahosted.org/freeipa/ticket/2848 I've tested the attached patch with the samba packages mentioned above and everything works as expect. As can be seen in the figure Alexander linked above the new suffixes are disabled by default on the Windows side. This is expected and exactly the same behaviour can be found in AD-AD trusts. Nevertheless it would be good if you can make sure this behaviour is explicitly mentioned e.g. in the design page or other documents to avoid confusion when this feature is tested by others. Review comments are in-line. bye, Sumit > > > -- > / Alexander Bokovoy > >From f400d55eaec99b3e5440e90b6a6d055e26529e7e Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Fri, 22 Mar 2013 17:30:41 +0200 > Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the > realm domains > > PASSDB API in Samba adds support for specifying UPN suffixes. The change > in ipasam will allow to pass through list of realm domains as UPN suffixes > so that Active Directory domain controller will be able to recognize > non-primary UPN suffixes as belonging to IPA and properly find our KDC > for cross-realm TGT. > > Since Samba already returns primary DNS domain separately, filter it out > from list of UPN suffixes. > > Also enclose provider of UPN suffixes into #ifdef to support both > Samba with and without pdb_enum_upn_suffixes(). > > Part of https://fedorahosted.org/freeipa/ticket/2848 > --- > daemons/configure.ac | 10 +++ > daemons/ipa-sam/ipa_sam.c | 172 ++++++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 177 insertions(+), 5 deletions(-) > > diff --git a/daemons/configure.ac b/daemons/configure.ac > index d3b6b19..14dc04e 100644 > --- a/daemons/configure.ac > +++ b/daemons/configure.ac > @@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient], > [$SAMBA40EXTRA_LIBPATH]) > AC_SUBST(WBCLIENT_LIBS) > > +AC_CHECK_LIB([pdb], > + [make_pdb_method], > + [HAVE_LIBPDB=1], > + [AC_MSG_ERROR([libpdb does not have make_pdb_method])], > + [$SAMBA40EXTRA_LIBPATH]) > +AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes], > + [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to enumerate UPN suffixes])], > + [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no support for realm domains in ipasam])], > + [$SAMBA40EXTRA_LIBPATH]) any reason for the extra space in the indentation? > + > dnl --------------------------------------------------------------------------- > dnl - Check for check unit test framework http://check.sourceforge.net/ > dnl --------------------------------------------------------------------------- ... > +static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, > + LDAPMessage *entry, const char *attribute, int *num_values) > +{ > + struct berval **values; > + int count, i; > + char **result = NULL; > + size_t conv_size; > + > + if (attribute == NULL || entry == NULL) { > + return NULL; > + } > + > + values = ldap_get_values_len(ldap_struct, entry, attribute); > + if (values == NULL) { > + DEBUG(10, ("Attribute [%s] not found.\n", attribute)); > + return NULL; > + } if ldap_get_values_len() returns NULL in the case of an error (according to the man page), if there are no attributes, an empty array is returned. This also means that count can be 0 below. > + > + /* Note that if we've got any values, count would be > 0 */ > + count = ldap_count_values_len(values); > + result = talloc_array(mem_ctx, char *, count); > + if (result == NULL) { > + goto done; > + } > + > + *num_values = count; > + for (i = 0; i < count; i++) { > + if (!convert_string_talloc(result, CH_UTF8, CH_UNIX, > + values[i]->bv_val, values[i]->bv_len, > + &result[i], &conv_size)) { > + DEBUG(10, ("Failed to convert %dth value of [%s] out of %d.\n", > + i, attribute, count)); > + talloc_free(result); > + result = NULL; maybe set *num_values = 0 as a precaution as well? > + goto done; > + } > + } > + > +done: > + ldap_value_free_len(values); > + return result; > +} > + > ... > +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES > +static NTSTATUS ipasam_enum_upn_suffixes(struct pdb_methods *pdb_methods, > + TALLOC_CTX *mem_ctx, > + uint32_t *num_suffixes, > + char ***suffixes) > +{ > + int ret; > + LDAPMessage *result; > + LDAPMessage *entry = NULL; > + int count, i; > + char *realmdomains_dn = NULL; > + char **domains = NULL; > + struct ldapsam_privates *ldap_state; > + struct smbldap_state *smbldap_state; > + const char *attr_list[] = { > + "associatedDomain", would you mind to #define attribute names and directory paths at the beginning of ipa_sam.c? > + NULL > + }; > + > + if ((suffixes == NULL) || (num_suffixes == NULL)) { > + return NT_STATUS_UNSUCCESSFUL; > + } > + > + ldap_state = (struct ldapsam_privates *)pdb_methods->private_data; > + smbldap_state = ldap_state->smbldap_state; > + > + realmdomains_dn = talloc_asprintf(mem_ctx, "cn=Realm Domains,cn=ipa,cn=etc,%s", > + ldap_state->ipasam_privates->base_dn); > + if (realmdomains_dn == NULL) { > + return NT_STATUS_NO_MEMORY; > + } > + > + ret = smbldap_search(smbldap_state, > + realmdomains_dn, > + LDAP_SCOPE_BASE, > + "objectclass=domainRelatedObject", attr_list, 0, > + &result); > + if (ret != LDAP_SUCCESS) { > + DEBUG(1, ("Failed to get list of realm domains: %s\n", > + ldap_err2string (ret))); > + return NT_STATUS_UNSUCCESSFUL; > + } > + > + count = ldap_count_entries(smbldap_state->ldap_struct, result); > + if (count != 1) { > + DEBUG(1, ("Unexpected number of results [%d] for realm domains " > + "search.\n", count)); > + ldap_msgfree(result); > + return NT_STATUS_OK; > + } Is there a reason to return NT_STATUS_OK for this particular error condition? > + > + entry = ldap_first_entry(smbldap_state->ldap_struct, result); > + if (entry == NULL) { > + DEBUG(0, ("Could not get domainRelatedObject entry\n")); > + ldap_msgfree(result); > + return NT_STATUS_UNSUCCESSFUL; > + } > + > + domains = get_attribute_values(mem_ctx, smbldap_state->ldap_struct, entry, > + "associatedDomain", &count); > + if (domains == NULL) { > + ldap_msgfree(result); > + return NT_STATUS_UNSUCCESSFUL; > + } > + > + /* Since associatedDomain has attributeType MUST, there must be at least one domain */ > + for (i = 0; i < count ; i++) { > + if (strcmp(ldap_state->domain_name, domains[i]) == 0) { > + break; > + } > + } Since we area handling DNS domain names here strcasecmp() would be more fault tolerant? OTOH I think mixed cases here can only happen if some modifies IPA LDAP object manually. > + > + if (i < count) { > + /* If we found our primary domain in the list and it is alone, exit with empty list */ > + if (count == 1) { > + ldap_msgfree(result); > + talloc_free(domains); > + return NT_STATUS_UNSUCCESSFUL; > + } > + > + talloc_free(domains[i]); > + > + /* if i is not last element, move everything down */ > + if (i != (count - 1)) { > + memcpy(domains + i, domains + i + 1, sizeof(char *) * (count - i - 1)); > + } I think you meant memmove() according to your comment, because memcpy() should not be used for overlapping areas. Maybe add domains[count - 1] = NULL; as a precaution measure? > + > + /* we don't resize whole list, only reduce number of elements in it > + * since sizing down a single pointer will not reduce memory usage in talloc > + */ > + *suffixes = domains; > + *num_suffixes = count - 1; > + } else { > + /* There is no our primary domain in the list */ > + *suffixes = domains; > + *num_suffixes = count; > + } > + > + ldap_msgfree(result); > + return NT_STATUS_OK; > +} > +#endif /* HAVE_PDB_ENUM_UPN_SUFFIXES */ > + > + > #define SECRETS_DOMAIN_SID "SECRETS/SID" > static char *sec_key(TALLOC_CTX *mem_ctx, const char *d) > { > @@ -4030,7 +4187,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, > } > > status = ipasam_get_domain_name(ldap_state, ldap_state, > - &ldap_state->domain_name); > + (char**) &ldap_state->domain_name); > if (!NT_STATUS_IS_OK(status)) { > DEBUG(0, ("Failed to get domain name.\n")); > return status; > @@ -4150,6 +4307,11 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, > (*pdb_method)->set_trusted_domain = ipasam_set_trusted_domain; > (*pdb_method)->del_trusted_domain = ipasam_del_trusted_domain; > (*pdb_method)->enum_trusted_domains = ipasam_enum_trusted_domains; > +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES > + (*pdb_method)->enum_upn_suffixes = ipasam_enum_upn_suffixes; > + DEBUG(1, ("pdb_init_ipasam: support for pdb_enum_upn_suffixes " > + "enabled for domain %s\n", ldap_state->domain_name)); > +#endif > > return NT_STATUS_OK; > } > -- > 1.8.1.4 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Wed Mar 27 10:53:18 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 Mar 2013 12:53:18 +0200 Subject: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam In-Reply-To: <20130327095021.GE2112@localhost.localdomain> References: <20130325180744.GH6823@redhat.com> <20130327095021.GE2112@localhost.localdomain> Message-ID: <20130327105318.GK6823@redhat.com> Hi, On Wed, 27 Mar 2013, Sumit Bose wrote: >> Additionally, you can request Windows to update list of name suffixes >> via UI. Here is how it looks in Windows 2012 Server: >> http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png >> >> Part of ticket https://fedorahosted.org/freeipa/ticket/2848 > >I've tested the attached patch with the samba packages mentioned above >and everything works as expect. > >As can be seen in the figure Alexander linked above the new suffixes are >disabled by default on the Windows side. This is expected and exactly >the same behaviour can be found in AD-AD trusts. Nevertheless it would >be good if you can make sure this behaviour is explicitly mentioned e.g. >in the design page or other documents to avoid confusion when this >feature is tested by others. I'll add that, thanks for reminding. > >Review comments are in-line. > >bye, >Sumit > >> >> >> -- >> / Alexander Bokovoy > >> >From f400d55eaec99b3e5440e90b6a6d055e26529e7e Mon Sep 17 00:00:00 2001 >> From: Alexander Bokovoy >> Date: Fri, 22 Mar 2013 17:30:41 +0200 >> Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the >> realm domains >> >> PASSDB API in Samba adds support for specifying UPN suffixes. The change >> in ipasam will allow to pass through list of realm domains as UPN suffixes >> so that Active Directory domain controller will be able to recognize >> non-primary UPN suffixes as belonging to IPA and properly find our KDC >> for cross-realm TGT. >> >> Since Samba already returns primary DNS domain separately, filter it out >> from list of UPN suffixes. >> >> Also enclose provider of UPN suffixes into #ifdef to support both >> Samba with and without pdb_enum_upn_suffixes(). >> >> Part of https://fedorahosted.org/freeipa/ticket/2848 >> --- >> daemons/configure.ac | 10 +++ >> daemons/ipa-sam/ipa_sam.c | 172 ++++++++++++++++++++++++++++++++++++++++++++-- >> 2 files changed, 177 insertions(+), 5 deletions(-) >> >> diff --git a/daemons/configure.ac b/daemons/configure.ac >> index d3b6b19..14dc04e 100644 >> --- a/daemons/configure.ac >> +++ b/daemons/configure.ac >> @@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient], >> [$SAMBA40EXTRA_LIBPATH]) >> AC_SUBST(WBCLIENT_LIBS) >> >> +AC_CHECK_LIB([pdb], >> + [make_pdb_method], >> + [HAVE_LIBPDB=1], >> + [AC_MSG_ERROR([libpdb does not have make_pdb_method])], >> + [$SAMBA40EXTRA_LIBPATH]) >> +AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes], >> + [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to enumerate UPN suffixes])], >> + [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no support for realm domains in ipasam])], >> + [$SAMBA40EXTRA_LIBPATH]) > >any reason for the extra space in the indentation? No :) >> + >> dnl --------------------------------------------------------------------------- >> dnl - Check for check unit test framework http://check.sourceforge.net/ >> dnl --------------------------------------------------------------------------- > >... > >> +static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, >> + LDAPMessage *entry, const char *attribute, int *num_values) >> +{ >> + struct berval **values; >> + int count, i; >> + char **result = NULL; >> + size_t conv_size; >> + >> + if (attribute == NULL || entry == NULL) { >> + return NULL; >> + } >> + >> + values = ldap_get_values_len(ldap_struct, entry, attribute); >> + if (values == NULL) { >> + DEBUG(10, ("Attribute [%s] not found.\n", attribute)); >> + return NULL; >> + } > >if ldap_get_values_len() returns NULL in the case of an error (according >to the man page), if there are no attributes, an empty array is >returned. This also means that count can be 0 below. I ended up specifically checking count to zero and returning before allocating values. >> +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES >> +static NTSTATUS ipasam_enum_upn_suffixes(struct pdb_methods *pdb_methods, >> + TALLOC_CTX *mem_ctx, >> + uint32_t *num_suffixes, >> + char ***suffixes) >> +{ >> + int ret; >> + LDAPMessage *result; >> + LDAPMessage *entry = NULL; >> + int count, i; >> + char *realmdomains_dn = NULL; >> + char **domains = NULL; >> + struct ldapsam_privates *ldap_state; >> + struct smbldap_state *smbldap_state; >> + const char *attr_list[] = { >> + "associatedDomain", > >would you mind to #define attribute names and directory paths at the >beginning of ipa_sam.c? Yes, I was wondering about that before. We have another places where we use associatedDomain now. I've moved all of them to defines. >> + NULL >> + }; >> + >> + if ((suffixes == NULL) || (num_suffixes == NULL)) { >> + return NT_STATUS_UNSUCCESSFUL; >> + } >> + >> + ldap_state = (struct ldapsam_privates *)pdb_methods->private_data; >> + smbldap_state = ldap_state->smbldap_state; >> + >> + realmdomains_dn = talloc_asprintf(mem_ctx, "cn=Realm Domains,cn=ipa,cn=etc,%s", >> + ldap_state->ipasam_privates->base_dn); >> + if (realmdomains_dn == NULL) { >> + return NT_STATUS_NO_MEMORY; >> + } >> + >> + ret = smbldap_search(smbldap_state, >> + realmdomains_dn, >> + LDAP_SCOPE_BASE, >> + "objectclass=domainRelatedObject", attr_list, 0, >> + &result); >> + if (ret != LDAP_SUCCESS) { >> + DEBUG(1, ("Failed to get list of realm domains: %s\n", >> + ldap_err2string (ret))); >> + return NT_STATUS_UNSUCCESSFUL; >> + } >> + >> + count = ldap_count_entries(smbldap_state->ldap_struct, result); >> + if (count != 1) { >> + DEBUG(1, ("Unexpected number of results [%d] for realm domains " >> + "search.\n", count)); >> + ldap_msgfree(result); >> + return NT_STATUS_OK; >> + } > >Is there a reason to return NT_STATUS_OK for this particular error >condition? Actually, it should have been NT_STATUS_UNSUCCESSFUL and it is the same error as in ipasam_get_domain_name. I've fixed both now. >> + >> + entry = ldap_first_entry(smbldap_state->ldap_struct, result); >> + if (entry == NULL) { >> + DEBUG(0, ("Could not get domainRelatedObject entry\n")); >> + ldap_msgfree(result); >> + return NT_STATUS_UNSUCCESSFUL; >> + } >> + >> + domains = get_attribute_values(mem_ctx, smbldap_state->ldap_struct, entry, >> + "associatedDomain", &count); >> + if (domains == NULL) { >> + ldap_msgfree(result); >> + return NT_STATUS_UNSUCCESSFUL; >> + } >> + >> + /* Since associatedDomain has attributeType MUST, there must be at least one domain */ >> + for (i = 0; i < count ; i++) { >> + if (strcmp(ldap_state->domain_name, domains[i]) == 0) { >> + break; >> + } >> + } > >Since we area handling DNS domain names here strcasecmp() would be more >fault tolerant? OTOH I think mixed cases here can only happen if some >modifies IPA LDAP object manually. Technically it should be something that does utf-8 caseless lookups. We can go with strcasecmp as it is for time being, I'll add TODO there for future IDN handling. > >> + >> + if (i < count) { >> + /* If we found our primary domain in the list and it is alone, exit with empty list */ >> + if (count == 1) { >> + ldap_msgfree(result); >> + talloc_free(domains); >> + return NT_STATUS_UNSUCCESSFUL; >> + } >> + >> + talloc_free(domains[i]); >> + >> + /* if i is not last element, move everything down */ >> + if (i != (count - 1)) { >> + memcpy(domains + i, domains + i + 1, sizeof(char *) * (count - i - 1)); >> + } > >I think you meant memmove() according to your comment, because memcpy() >should not be used for overlapping areas. Fixed, thanks! >Maybe add domains[count - 1] = NULL; as a precaution measure? Added this as well. New patch attached. Survives Windows 2012 testing. -- / Alexander Bokovoy -------------- next part -------------- >From 48906c4bb1226a174de3acf4a656fd6eb4466218 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 22 Mar 2013 17:30:41 +0200 Subject: [PATCH 2/2] ipasam: add enumeration of UPN suffixes based on the realm domains PASSDB API in Samba adds support for specifying UPN suffixes. The change in ipasam will allow to pass through list of realm domains as UPN suffixes so that Active Directory domain controller will be able to recognize non-primary UPN suffixes as belonging to IPA and properly find our KDC for cross-realm TGT. Since Samba already returns primary DNS domain separately, filter it out from list of UPN suffixes. Also enclose provider of UPN suffixes into #ifdef to support both Samba with and without pdb_enum_upn_suffixes(). Part of https://fedorahosted.org/freeipa/ticket/2848 --- daemons/configure.ac | 10 +++ daemons/ipa-sam/ipa_sam.c | 192 +++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 191 insertions(+), 11 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index d3b6b19..0eb0646 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -252,6 +252,16 @@ AC_CHECK_LIB([wbclient], [$SAMBA40EXTRA_LIBPATH]) AC_SUBST(WBCLIENT_LIBS) +AC_CHECK_LIB([pdb], + [make_pdb_method], + [HAVE_LIBPDB=1], + [AC_MSG_ERROR([libpdb does not have make_pdb_method])], + [$SAMBA40EXTRA_LIBPATH]) +AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes], + [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to enumerate UPN suffixes])], + [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no support for realm domains in ipasam])], + [$SAMBA40EXTRA_LIBPATH]) + dnl --------------------------------------------------------------------------- dnl - Check for check unit test framework http://check.sourceforge.net/ dnl --------------------------------------------------------------------------- diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index dd3ad61..4a2fca5 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -1,6 +1,7 @@ #define HAVE_IMMEDIATE_STRUCTURES 1 #define LDAP_DEPRECATED 1 +#include "config.h" #include #include #include @@ -127,6 +128,7 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_ATTRIBUTE_NTHASH "ipaNTHash" #define LDAP_ATTRIBUTE_UIDNUMBER "uidnumber" #define LDAP_ATTRIBUTE_GIDNUMBER "gidnumber" +#define LDAP_ATTRIBUTE_ASSOCIATED_DOMAIN "associatedDomain" #define LDAP_OBJ_KRB_PRINCIPAL "krbPrincipal" #define LDAP_OBJ_KRB_PRINCIPAL_AUX "krbPrincipalAux" @@ -141,6 +143,9 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_OBJ_NESTEDGROUP "nestedGroup" #define LDAP_OBJ_IPAUSERGROUP "ipaUserGroup" #define LDAP_OBJ_POSIXGROUP "posixGroup" +#define LDAP_OBJ_DOMAINRELATED "domainRelatedObject" + +#define LDAP_CN_REALM_DOMAINS "cn=Realm Domains,cn=ipa,cn=etc" #define HAS_KRB_PRINCIPAL (1<<0) #define HAS_KRB_PRINCIPAL_AUX (1<<1) @@ -167,6 +172,12 @@ struct ipasam_privates { struct sss_idmap_ctx *idmap_ctx; }; + +static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, + TALLOC_CTX *mem_ctx, + char **domain_name); + + static void *idmap_talloc(size_t size, void *pvt) { return talloc_size(pvt, size); @@ -295,6 +306,56 @@ static LDAP *priv2ld(struct ldapsam_privates *priv) return priv->smbldap_state->ldap_struct; } +/* + * get_attribute_values() returns array of all values of the attribute + * allocated over mem_ctx + */ +static char **get_attribute_values(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, + LDAPMessage *entry, const char *attribute, int *num_values) +{ + struct berval **values; + int count, i; + char **result = NULL; + size_t conv_size; + + if (attribute == NULL || entry == NULL) { + return NULL; + } + + values = ldap_get_values_len(ldap_struct, entry, attribute); + if (values == NULL) { + DEBUG(10, ("Attribute [%s] not found.\n", attribute)); + return NULL; + } + + count = ldap_count_values_len(values); + if (count == 0) { + goto done; + } + + result = talloc_array(mem_ctx, char *, count); + if (result == NULL) { + goto done; + } + + *num_values = count; + for (i = 0; i < count; i++) { + if (!convert_string_talloc(result, CH_UTF8, CH_UNIX, + values[i]->bv_val, values[i]->bv_len, + &result[i], &conv_size)) { + DEBUG(10, ("Failed to convert %dth value of [%s] out of %d.\n", + i, attribute, count)); + talloc_free(result); + result = NULL; + goto done; + } + } + +done: + ldap_value_free_len(values); + return result; +} + static char *get_single_attribute(TALLOC_CTX *mem_ctx, LDAP *ldap_struct, LDAPMessage *entry, const char *attribute) { @@ -3250,9 +3311,8 @@ static struct pdb_domain_info *pdb_ipasam_get_domain_info(struct pdb_methods *pd goto fail; } - /* TODO: read dns_domain, dns_forest and guid from LDAP */ - info->dns_domain = strlower_talloc(info, ldap_state->ipasam_privates->realm); - if (info->dns_domain == NULL) { + status = ipasam_get_domain_name(ldap_state, info, &info->dns_domain); + if (!NT_STATUS_IS_OK(status) || (info->dns_domain == NULL)) { goto fail; } info->dns_forest = talloc_strdup(info, info->dns_domain); @@ -3464,7 +3524,7 @@ static NTSTATUS ipasam_get_base_dn(struct smbldap_state *smbldap_state, static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, TALLOC_CTX *mem_ctx, - const char **domain_name) + char **domain_name) { int ret; LDAPMessage *result; @@ -3473,14 +3533,14 @@ static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, char *cn; struct smbldap_state *smbldap_state = ldap_state->smbldap_state; const char *attr_list[] = { - "associatedDomain", + LDAP_ATTRIBUTE_ASSOCIATED_DOMAIN, NULL }; ret = smbldap_search(smbldap_state, ldap_state->ipasam_privates->base_dn, LDAP_SCOPE_BASE, - "objectclass=domainRelatedObject", attr_list, 0, + "objectclass=" LDAP_OBJ_DOMAINRELATED, attr_list, 0, &result); if (ret != LDAP_SUCCESS) { DEBUG(1, ("Failed to get domain name: %s\n", @@ -3494,11 +3554,10 @@ static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, DEBUG(1, ("Unexpected number of results [%d] for domain name " "search.\n", count)); ldap_msgfree(result); - return NT_STATUS_OK; + return NT_STATUS_UNSUCCESSFUL; } - entry = ldap_first_entry(smbldap_state->ldap_struct, - result); + entry = ldap_first_entry(smbldap_state->ldap_struct, result); if (entry == NULL) { DEBUG(0, ("Could not get domainRelatedObject entry\n")); ldap_msgfree(result); @@ -3506,7 +3565,7 @@ static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, } cn = get_single_attribute(mem_ctx, smbldap_state->ldap_struct, entry, - "associatedDomain"); + LDAP_ATTRIBUTE_ASSOCIATED_DOMAIN); if (cn == NULL) { ldap_msgfree(result); return NT_STATUS_UNSUCCESSFUL; @@ -3572,6 +3631,112 @@ static NTSTATUS ipasam_get_realm(struct ldapsam_privates *ldap_state, return NT_STATUS_OK; } +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES +static NTSTATUS ipasam_enum_upn_suffixes(struct pdb_methods *pdb_methods, + TALLOC_CTX *mem_ctx, + uint32_t *num_suffixes, + char ***suffixes) +{ + int ret; + LDAPMessage *result; + LDAPMessage *entry = NULL; + int count, i; + char *realmdomains_dn = NULL; + char **domains = NULL; + struct ldapsam_privates *ldap_state; + struct smbldap_state *smbldap_state; + const char *attr_list[] = { + LDAP_ATTRIBUTE_ASSOCIATED_DOMAIN, + NULL + }; + + if ((suffixes == NULL) || (num_suffixes == NULL)) { + return NT_STATUS_UNSUCCESSFUL; + } + + ldap_state = (struct ldapsam_privates *)pdb_methods->private_data; + smbldap_state = ldap_state->smbldap_state; + + realmdomains_dn = talloc_asprintf(mem_ctx, "%s,%s", LDAP_CN_REALM_DOMAINS, + ldap_state->ipasam_privates->base_dn); + if (realmdomains_dn == NULL) { + return NT_STATUS_NO_MEMORY; + } + + ret = smbldap_search(smbldap_state, + realmdomains_dn, + LDAP_SCOPE_BASE, + "objectclass=" LDAP_OBJ_DOMAINRELATED, attr_list, 0, + &result); + if (ret != LDAP_SUCCESS) { + DEBUG(1, ("Failed to get list of realm domains: %s\n", + ldap_err2string (ret))); + return NT_STATUS_UNSUCCESSFUL; + } + + count = ldap_count_entries(smbldap_state->ldap_struct, result); + if (count != 1) { + DEBUG(1, ("Unexpected number of results [%d] for realm domains " + "search.\n", count)); + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; + } + + entry = ldap_first_entry(smbldap_state->ldap_struct, result); + if (entry == NULL) { + DEBUG(0, ("Could not get domainRelatedObject entry\n")); + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; + } + + domains = get_attribute_values(mem_ctx, smbldap_state->ldap_struct, entry, + LDAP_ATTRIBUTE_ASSOCIATED_DOMAIN, &count); + if (domains == NULL) { + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; + } + + /* Since associatedDomain has attributeType MUST, there must be at least one domain */ + for (i = 0; i < count ; i++) { + /* TODO: use comparison function friendly to IDN */ + if (strcasecmp(ldap_state->domain_name, domains[i]) == 0) { + break; + } + } + + if (i < count) { + /* If we found our primary domain in the list and it is alone, exit with empty list */ + if (count == 1) { + ldap_msgfree(result); + talloc_free(domains); + return NT_STATUS_UNSUCCESSFUL; + } + + talloc_free(domains[i]); + + /* if i is not last element, move everything down */ + if (i != (count - 1)) { + memmove(domains + i, domains + i + 1, sizeof(char *) * (count - i - 1)); + } + + /* we don't resize whole list, only reduce number of elements in it + * since sizing down a single pointer will not reduce memory usage in talloc + */ + domains[count - 1] = NULL; + *suffixes = domains; + *num_suffixes = count - 1; + } else { + /* There is no our primary domain in the list */ + *suffixes = domains; + *num_suffixes = count; + } + + ldap_msgfree(result); + return NT_STATUS_OK; +} +#endif /* HAVE_PDB_ENUM_UPN_SUFFIXES */ + + #define SECRETS_DOMAIN_SID "SECRETS/SID" static char *sec_key(TALLOC_CTX *mem_ctx, const char *d) { @@ -4030,7 +4195,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, } status = ipasam_get_domain_name(ldap_state, ldap_state, - &ldap_state->domain_name); + (char**) &ldap_state->domain_name); if (!NT_STATUS_IS_OK(status)) { DEBUG(0, ("Failed to get domain name.\n")); return status; @@ -4150,6 +4315,11 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, (*pdb_method)->set_trusted_domain = ipasam_set_trusted_domain; (*pdb_method)->del_trusted_domain = ipasam_del_trusted_domain; (*pdb_method)->enum_trusted_domains = ipasam_enum_trusted_domains; +#ifdef HAVE_PDB_ENUM_UPN_SUFFIXES + (*pdb_method)->enum_upn_suffixes = ipasam_enum_upn_suffixes; + DEBUG(1, ("pdb_init_ipasam: support for pdb_enum_upn_suffixes " + "enabled for domain %s\n", ldap_state->domain_name)); +#endif return NT_STATUS_OK; } -- 1.8.1.4 From tbabej at redhat.com Wed Mar 27 11:15:51 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 27 Mar 2013 12:15:51 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install In-Reply-To: <5151ECC0.60005@redhat.com> References: <5151ECC0.60005@redhat.com> Message-ID: <5152D4E7.8060703@redhat.com> On 03/26/2013 07:45 PM, Ana Krivokapic wrote: > Add the option to create home directories for users on their first login > to ipa-server-install and ipa-replica-install. > > https://fedorahosted.org/freeipa/ticket/3515 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK from the functional point of view. Just a nitpick, can you please reformat the patch and fix PEP8 E501 errors? I know there's a lot of PEP8 errors and warnings in the whole project (and we probably need to adress this), however, let us not introduce new ones. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Mar 27 11:46:13 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 27 Mar 2013 12:46:13 +0100 Subject: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam In-Reply-To: <20130327105318.GK6823@redhat.com> References: <20130325180744.GH6823@redhat.com> <20130327095021.GE2112@localhost.localdomain> <20130327105318.GK6823@redhat.com> Message-ID: <20130327114449.GI2112@localhost.localdomain> On Wed, Mar 27, 2013 at 12:53:18PM +0200, Alexander Bokovoy wrote: > Hi, > > On Wed, 27 Mar 2013, Sumit Bose wrote: > >>Additionally, you can request Windows to update list of name suffixes > >>via UI. Here is how it looks in Windows 2012 Server: > >>http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png > >> > >>Part of ticket https://fedorahosted.org/freeipa/ticket/2848 > > > >I've tested the attached patch with the samba packages mentioned above > >and everything works as expect. > > > >As can be seen in the figure Alexander linked above the new suffixes are > >disabled by default on the Windows side. This is expected and exactly > >the same behaviour can be found in AD-AD trusts. Nevertheless it would > >be good if you can make sure this behaviour is explicitly mentioned e.g. > >in the design page or other documents to avoid confusion when this > >feature is tested by others. > I'll add that, thanks for reminding. > > > > >Review comments are in-line. > > > >bye, > >>+ > >>+ /* Since associatedDomain has attributeType MUST, there must be at least one domain */ > >>+ for (i = 0; i < count ; i++) { > >>+ if (strcmp(ldap_state->domain_name, domains[i]) == 0) { > >>+ break; > >>+ } > >>+ } > > > >Since we area handling DNS domain names here strcasecmp() would be more > >fault tolerant? OTOH I think mixed cases here can only happen if some > >modifies IPA LDAP object manually. > Technically it should be something that does utf-8 caseless lookups. We > can go with strcasecmp as it is for time being, I'll add TODO there for > future IDN handling. yes, good idea > > > New patch attached. Survives Windows 2012 testing. Survives my testing with 2008 as well. ACK. bye, Sumit > > > > -- > / Alexander Bokovoy From akrivoka at redhat.com Wed Mar 27 12:54:49 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 27 Mar 2013 13:54:49 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install In-Reply-To: <5152D4E7.8060703@redhat.com> References: <5151ECC0.60005@redhat.com> <5152D4E7.8060703@redhat.com> Message-ID: <5152EC19.8040608@redhat.com> On 03/27/2013 12:15 PM, Tomas Babej wrote: > On 03/26/2013 07:45 PM, Ana Krivokapic wrote: >> Add the option to create home directories for users on their first login >> to ipa-server-install and ipa-replica-install. >> >> https://fedorahosted.org/freeipa/ticket/3515 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK from the functional point of view. > > Just a nitpick, can you please reformat the patch and fix PEP8 E501 > errors? > > I know there's a lot of PEP8 errors and warnings in the whole project > (and we probably need to adress this), however, let us not introduce > new ones. > > Tomas Fixed, thanks. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0010-02-Add-mkhomedir-option-to-ipa-server-install-and-ipa-r.patch Type: text/x-patch Size: 4852 bytes Desc: not available URL: From tbabej at redhat.com Wed Mar 27 13:32:50 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 27 Mar 2013 14:32:50 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install In-Reply-To: <5152EC19.8040608@redhat.com> References: <5151ECC0.60005@redhat.com> <5152D4E7.8060703@redhat.com> <5152EC19.8040608@redhat.com> Message-ID: <5152F502.5060700@redhat.com> On Wed 27 Mar 2013 01:54:49 PM CET, Ana Krivokapic wrote: > On 03/27/2013 12:15 PM, Tomas Babej wrote: >> On 03/26/2013 07:45 PM, Ana Krivokapic wrote: >>> Add the option to create home directories for users on their first login >>> to ipa-server-install and ipa-replica-install. >>> >>> https://fedorahosted.org/freeipa/ticket/3515 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> ACK from the functional point of view. >> >> Just a nitpick, can you please reformat the patch and fix PEP8 E501 >> errors? >> >> I know there's a lot of PEP8 errors and warnings in the whole project >> (and we probably need to adress this), however, let us not introduce >> new ones. >> >> Tomas > > Fixed, thanks. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. Thanks. Updated patch works fine, ACK. Tomas From mkosek at redhat.com Wed Mar 27 13:51:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Mar 2013 14:51:05 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <5151AB25.1070207@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> Message-ID: <5152F949.6050604@redhat.com> On 03/26/2013 03:05 PM, Jan Cholasta wrote: > On 25.3.2013 16:21, Martin Kosek wrote: >> On 03/25/2013 02:41 PM, Martin Kosek wrote: >>> I checked what you have already and this is what I found: >>> >>> 1) Internal error if I try to remove krbticketflags via *attr functions: >>> >>> # ipa service-add foo/`hostname` --setattr=krbticketflags=None >>> ipa: ERROR: an internal error has occurred >>> # ipa service-add foo/`hostname` >>> ------------------------------------------------------------------------ >>> Added service "foo/vm-037.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM" >>> ------------------------------------------------------------------------ >>> # ipa service-mod foo/`hostname` --setattr=krbticketflags=None >>> ipa: ERROR: an internal error has occurred > > Fixed. > >>> >>> >>> 2) The RFE page needs updating, it does not reflect current reality. AFAIU, the >>> only thing that's left to be decided is the granularity of the ACIs used to >>> control this flag. > > RFE page updated. > >> >> I read this part of design proposal discussion wrong, this is already decided - >> we do not want to have a fine grain granularity, these are too powerful flags >> to be delegated per-flag to lower admins. >> >> So I think that you current approach is sufficient, I do not think we need to >> add this attribute to some host/service related permission to avoid allowing >> this sensitive attribute for lower level admins automatically. If someone wants >> it, he can add and assign an appropriate permission. > > Correct, this has been already decided. > > Updated patch attached. > > Honza > This looks OK. Please just also add unit tests exercising this new feature. Thanks, Martin From jcholast at redhat.com Wed Mar 27 14:44:25 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Mar 2013 15:44:25 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4A35.2060200@redhat.com> References: <514C4A35.2060200@redhat.com> Message-ID: <515305C9.4070600@redhat.com> Hi, On 22.3.2013 13:10, Petr Viktorin wrote: > The design page for CA-less installation with user-provided SSL certs is > available at http://freeipa.org/page/V3/CA-less_install. I've also > copied it to this mail. > > Does it answer all your questions? > I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. Also, the RFE page states that the options to specify PKCS#12 files are called --http_pkcs and --dirsrv_pkcs, but they are in fact called --http_pkcs12 and --dirsrv_pkcs12. Honza -- Jan Cholasta From jdennis at redhat.com Wed Mar 27 15:04:35 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Mar 2013 11:04:35 -0400 Subject: [Freeipa-devel] git versions for rpms in makefile In-Reply-To: <51525C6B.90501@cora.nwra.com> References: <5151EE34.8060400@cora.nwra.com> <51522BC3.9080108@redhat.com> <1364348185.2660.150.camel@willson.li.ssimo.org> <51525C6B.90501@cora.nwra.com> Message-ID: <51530A83.9020807@redhat.com> On 03/26/2013 10:41 PM, Orion Poplawski wrote: > On 03/26/2013 07:36 PM, Simo Sorce wrote: >> On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote: >>> Orion Poplawski wrote: >>>> This patch uses the Fedora standard for git versioning >>>> (version-#.git) when making rpms. I'm afraid I haven't been able >>>> to test for the non-git version case. >>> >>> What is the purpose of this? We don't do upstream releases from >>> developer build, so having the wrong Source0 doesn't seem like a big >>> deal (though I'll admit no strictly correct). >> >> Sound like a reasonable improvement to me, and makes it sure you do not >> confuse an upstream build with a developer build, I am not so sure about >> using __GIT__, it's kinda annoying to type, although shell completion >> here helps I guess. >> >> I lean toward acking this approach, if you do not have objections Rob. >> >> Simo. > > My motivation for this was from testing the pkcs12 patches. First I did > an srpm build and got 3.1.99GITec94138-0.fc18.src.rpm. Then I updated > the git repo, did another srpm build and got > 3.1.99GIT5acd43d-1.fc18.src.rpm which would have been lower EVR wise. > Now I can get: > > 3.1.99-1.GIT5acd43d.fc18.src.rpm > > which would have been newer than > > 3.1.99-0.GITec94138.fc18.src.rpm > > and allowed me to do yum update. > > (actually, for pre-releases it should be -0.1.GIT, -0.2.GIT, ...) > > So it doesn't impact releases, just local developer testing - which I > don't know how much is done via rpms. I think you're confusing issues. You cannot use a git hash to properly collate based on build sequence. This is why in our development builds we prefix the git hash with a timestamp. It's the timestamp which affords the proper collation, the git hash is only informative. These issues to not arise in "release builds" because version and or release value is incremented. But the above is independent of whether we should follow the fedora convention for git hash, that's probably a good idea, just realize it won't solve your problem of version collation. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Wed Mar 27 15:23:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 27 Mar 2013 16:23:49 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515305C9.4070600@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> Message-ID: <51530F05.607@redhat.com> On 03/27/2013 03:44 PM, Jan Cholasta wrote: > Hi, > > On 22.3.2013 13:10, Petr Viktorin wrote: >> The design page for CA-less installation with user-provided SSL certs is >> available at http://freeipa.org/page/V3/CA-less_install. I've also >> copied it to this mail. >> >> Does it answer all your questions? >> > > I have gone through the whole discussion, RFE page and your patches, and > I still don't see why --root-ca-file is necessary. Walking the > certificate chain from the server cert up to the root CA is easy, so why > not do that to determine the root CA? If the option is there just to > ensure that the right certificate is used, I think it would be better to > ask the user to confirm that during the installation process, or use > --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a "globally" trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. > We should do some validation of the PKCS#12 files and the certificates > within them, as currently ipa-server-install will happily accept > anything thrown at it. I think the minimum is to validate that the > PKCS#12 file contains the whole certificate chain, the server key and > only that, and that the server certificate has CN= (or > CN=*. if we want to allow wildcard certs) in its subject. If we > don't do that, ipa-server-install might fail when it's too late to fix > things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? > Also, the RFE page states that the options to specify PKCS#12 files are > called --http_pkcs and --dirsrv_pkcs, but they are in fact called > --http_pkcs12 and --dirsrv_pkcs12. Fixed, thanks. -- Petr? From jcholast at redhat.com Wed Mar 27 15:40:23 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Mar 2013 16:40:23 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <51530F05.607@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> Message-ID: <515312E7.20604@redhat.com> On 27.3.2013 16:23, Petr Viktorin wrote: > On 03/27/2013 03:44 PM, Jan Cholasta wrote: >> I have gone through the whole discussion, RFE page and your patches, and >> I still don't see why --root-ca-file is necessary. Walking the >> certificate chain from the server cert up to the root CA is easy, so why >> not do that to determine the root CA? If the option is there just to >> ensure that the right certificate is used, I think it would be better to >> ask the user to confirm that during the installation process, or use >> --root-ca-subject or similar option to specify what certificate to use. > > Well, --root-ca-file specifies the root of trust, not necessarily the > selfsigned/unsigned CA at end of the trust chain. > Suppose you have a company-wide cert signed by a "globally" trusted CA, > but you're paranoid only want to trust the company cert, not a CA that > signs half the world's certificates. In that case walking up the chain > would select the wrong certificate. > Please correct me if my thinking is wrong. Makes sense, thanks. Can you please put this information in the RFE page? > > Yes, a --root-ca-subject would work too. I assumed the PEM file is > readily available. Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... > >> We should do some validation of the PKCS#12 files and the certificates >> within them, as currently ipa-server-install will happily accept >> anything thrown at it. I think the minimum is to validate that the >> PKCS#12 file contains the whole certificate chain, the server key and >> only that, and that the server certificate has CN= (or >> CN=*. if we want to allow wildcard certs) in its subject. If we >> don't do that, ipa-server-install might fail when it's too late to fix >> things. > > I don't want to check the subject because this RFE was prompted by IPA's > normal CA rejecting valid wildcart certs. Is there a reasonable way to > ask NSS if it will trust the cert? If there is I can put it in, but I > don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? > > The code checks for the whole cert chain, and that's there only one > server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. -- Jan Cholasta From jdennis at redhat.com Wed Mar 27 15:40:08 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Mar 2013 11:40:08 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <51530F05.607@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> Message-ID: <515312D8.3000502@redhat.com> On 03/27/2013 11:23 AM, Petr Viktorin wrote: > I don't want to check the subject because this RFE was prompted by IPA's > normal CA rejecting valid wildcart certs. Is there a reasonable way to > ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Finding time to work on python-nss has been a problem. This is further complicated by the fact Mozilla has changed from CVS to Mercurial while I had this code in development and I haven't moved over to the new distributed SCM yet. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From edewata at redhat.com Wed Mar 27 15:42:36 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Mar 2013 10:42:36 -0500 Subject: [Freeipa-devel] [PATCH] 271, 272 Added Web UI support for service PAC type option: NONE In-Reply-To: <5151E0FC.8080909@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> <5138980F.8070205@redhat.com> <5143A503.4020409@redhat.com> <515038FC.4050307@redhat.com> <5151E0FC.8080909@redhat.com> Message-ID: <5153136C.1020805@redhat.com> On 3/26/2013 12:55 PM, Endi Sukma Dewata wrote: > On 3/25/2013 6:46 AM, Petr Vobornik wrote: >> Reimplemented ^^ to match your proposal. Attaching as patches with new >> numbers (271,272) as they don't have much common with the original patch. > > The code looks good. Do you have a static/live demo site? After some testing, ACK. One minor thing (and you already documented this behavior), suppose initially you override the PAC types, then you change to inherit the settings, then you switch back to override, the checkboxes aren't restored. Yes, there's an undo/reset button, but it would be nice if we can preserve the checkboxes (by disabling them but keep the selection) even if the radio button isn't selected. Then if we save the changes, the disabled checkboxes can be completely cleared. -- Endi S. Dewata From rcritten at redhat.com Wed Mar 27 16:09:17 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Mar 2013 12:09:17 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515312E7.20604@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> Message-ID: <515319AD.4060909@redhat.com> Jan Cholasta wrote: > On 27.3.2013 16:23, Petr Viktorin wrote: >> On 03/27/2013 03:44 PM, Jan Cholasta wrote: >>> I have gone through the whole discussion, RFE page and your patches, and >>> I still don't see why --root-ca-file is necessary. Walking the >>> certificate chain from the server cert up to the root CA is easy, so why >>> not do that to determine the root CA? If the option is there just to >>> ensure that the right certificate is used, I think it would be better to >>> ask the user to confirm that during the installation process, or use >>> --root-ca-subject or similar option to specify what certificate to use. >> >> Well, --root-ca-file specifies the root of trust, not necessarily the >> selfsigned/unsigned CA at end of the trust chain. >> Suppose you have a company-wide cert signed by a "globally" trusted CA, >> but you're paranoid only want to trust the company cert, not a CA that >> signs half the world's certificates. In that case walking up the chain >> would select the wrong certificate. >> Please correct me if my thinking is wrong. > > Makes sense, thanks. Can you please put this information in the RFE page? > >> >> Yes, a --root-ca-subject would work too. I assumed the PEM file is >> readily available. > > Well, I don't like how PEM file duplicates an unnecessary amount of > information (the whole certificate). Also, copy-pasting subject might be > faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. > >> >>> We should do some validation of the PKCS#12 files and the certificates >>> within them, as currently ipa-server-install will happily accept >>> anything thrown at it. I think the minimum is to validate that the >>> PKCS#12 file contains the whole certificate chain, the server key and >>> only that, and that the server certificate has CN= (or >>> CN=*. if we want to allow wildcard certs) in its subject. If we >>> don't do that, ipa-server-install might fail when it's too late to fix >>> things. >> >> I don't want to check the subject because this RFE was prompted by IPA's >> normal CA rejecting valid wildcart certs. Is there a reasonable way to >> ask NSS if it will trust the cert? If there is I can put it in, but I >> don't want to re-create the validation. > > I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. >> >> The code checks for the whole cert chain, and that's there only one >> server cert. Does that not work? > > Actually I didn't check this specifically. But, I used a server > certificate with wrong subject and that made ipa-server-install fail. > One of the many cases that we will need to handle. rob From pviktori at redhat.com Wed Mar 27 16:18:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 27 Mar 2013 17:18:51 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515312E7.20604@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> Message-ID: <51531BEB.3080805@redhat.com> On 03/27/2013 04:40 PM, Jan Cholasta wrote: > On 27.3.2013 16:23, Petr Viktorin wrote: >> On 03/27/2013 03:44 PM, Jan Cholasta wrote: >>> I have gone through the whole discussion, RFE page and your patches, and >>> I still don't see why --root-ca-file is necessary. Walking the >>> certificate chain from the server cert up to the root CA is easy, so why >>> not do that to determine the root CA? If the option is there just to >>> ensure that the right certificate is used, I think it would be better to >>> ask the user to confirm that during the installation process, or use >>> --root-ca-subject or similar option to specify what certificate to use. >> >> Well, --root-ca-file specifies the root of trust, not necessarily the >> selfsigned/unsigned CA at end of the trust chain. >> Suppose you have a company-wide cert signed by a "globally" trusted CA, >> but you're paranoid only want to trust the company cert, not a CA that >> signs half the world's certificates. In that case walking up the chain >> would select the wrong certificate. >> Please correct me if my thinking is wrong. > > Makes sense, thanks. Can you please put this information in the RFE page? Added. >> Yes, a --root-ca-subject would work too. I assumed the PEM file is >> readily available. > > Well, I don't like how PEM file duplicates an unnecessary amount of > information (the whole certificate). Also, copy-pasting subject might be > faster than exporting certificate in PEM and uploading it to the server... Well, if the PKCS#12 only has the server cert that's signed directly by the CA, there's no duplication. This is arguably the common case. Honestly, I don't know what would be easier for a typical sysadmin in an organization that needs this functionality. These two approaches seem pretty even to me. >>> We should do some validation of the PKCS#12 files and the certificates >>> within them, as currently ipa-server-install will happily accept >>> anything thrown at it. I think the minimum is to validate that the >>> PKCS#12 file contains the whole certificate chain, the server key and >>> only that, and that the server certificate has CN= (or >>> CN=*. if we want to allow wildcard certs) in its subject. If we >>> don't do that, ipa-server-install might fail when it's too late to fix >>> things. >> >> I don't want to check the subject because this RFE was prompted by IPA's >> normal CA rejecting valid wildcart certs. Is there a reasonable way to >> ask NSS if it will trust the cert? If there is I can put it in, but I >> don't want to re-create the validation. > > I'm not sure TBH. Maybe someone with more NSS experience could answer this? > >> >> The code checks for the whole cert chain, and that's there only one >> server cert. Does that not work? > > Actually I didn't check this specifically. But, I used a server > certificate with wrong subject and that made ipa-server-install fail. I'll see how python-nss can help here. -- Petr? From pviktori at redhat.com Wed Mar 27 16:42:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 27 Mar 2013 17:42:43 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515319AD.4060909@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> <515319AD.4060909@redhat.com> Message-ID: <51532183.9070109@redhat.com> On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] >> Well, I don't like how PEM file duplicates an unnecessary amount of >> information (the whole certificate). Also, copy-pasting subject might be >> faster than exporting certificate in PEM and uploading it to the >> server... > > We're talking a one-time operation. I don't think it's asking too much. > It also gives the user some amount of control rather than assuming that > whatever tool their using to create the PKCS#12 file is also smart > enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) [...] >>> I don't want to check the subject because this RFE was prompted by IPA's >>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>> ask NSS if it will trust the cert? If there is I can put it in, but I >>> don't want to re-create the validation. >> >> I'm not sure TBH. Maybe someone with more NSS experience could answer >> this? > > certutil -V -u V will do it. The usage is already checked -- and with this command, too :) The problem here is hostname validation. > I don't think it would be onerous to assure that either the FQDN is in > the CN or it is a '*'. python-nss has fairly easy ways to grab the > subject out of a cert for this comparison. > >>> >>> The code checks for the whole cert chain, and that's there only one >>> server cert. Does that not work? >> >> Actually I didn't check this specifically. But, I used a server >> certificate with wrong subject and that made ipa-server-install fail. >> > > One of the many cases that we will need to handle. I found that python-nss has a verify_hostname call. I'll add it. -- Petr? From pviktori at redhat.com Wed Mar 27 16:44:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 27 Mar 2013 17:44:54 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515312D8.3000502@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> Message-ID: <51532206.8040405@redhat.com> On 03/27/2013 04:40 PM, John Dennis wrote: > On 03/27/2013 11:23 AM, Petr Viktorin wrote: >> I don't want to check the subject because this RFE was prompted by IPA's >> normal CA rejecting valid wildcart certs. Is there a reasonable way to >> ask NSS if it will trust the cert? > > Yes. NSS provides a variety of tools to test validation. Thanks! I'll take a look at it again. > Going just on memory here, our current version of python-nss has a > simple call to test validation. Sometime in the last year I added a fair > amount of new support for certificate validation including getting back > diagnostic information for validation failures, however if I recall > correctly the extended functionality in python-nss has not been released > yet. I'll add verify_hostname from the validation example; if there's anything else please give me a pointer -- I haven't read all the docs, yet. -- Petr? From jdennis at redhat.com Wed Mar 27 16:58:34 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Mar 2013 12:58:34 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <51532183.9070109@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> <515319AD.4060909@redhat.com> <51532183.9070109@redhat.com> Message-ID: <5153253A.8040102@redhat.com> On 03/27/2013 12:42 PM, Petr Viktorin wrote: > On 03/27/2013 05:09 PM, Rob Crittenden wrote: > [...] >>> Well, I don't like how PEM file duplicates an unnecessary amount of >>> information (the whole certificate). Also, copy-pasting subject might be >>> faster than exporting certificate in PEM and uploading it to the >>> server... >> >> We're talking a one-time operation. I don't think it's asking too much. >> It also gives the user some amount of control rather than assuming that >> whatever tool their using to create the PKCS#12 file is also smart >> enough to include the right CAs. > > Well, to be fair, if there are any intermediate CAs, they need to be in > the PKCS#12. (In the future there may be support for multiple root CAs, > which would all get explicit trust. Those would all go in the PEM, so > intermediate ones must be somewhere else -- in the PKCS#12.) > > Anyway I think it's unlikely that everybody will have the certs in the > right format for IPA by default, whatever that format is. > Honza has a point, but... If one solution is clearly better (in terms of > best/common practices in organizations this feature is for), I'm happy > to change it. Otherwise let's paint the bikeshed with the color I have > ready :) > > [...] >>>> I don't want to check the subject because this RFE was prompted by IPA's >>>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>>> ask NSS if it will trust the cert? If there is I can put it in, but I >>>> don't want to re-create the validation. >>> >>> I'm not sure TBH. Maybe someone with more NSS experience could answer >>> this? >> >> certutil -V -u V will do it. > > The usage is already checked -- and with this command, too :) > The problem here is hostname validation. > >> I don't think it would be onerous to assure that either the FQDN is in >> the CN or it is a '*'. python-nss has fairly easy ways to grab the >> subject out of a cert for this comparison. >> >>>> >>>> The code checks for the whole cert chain, and that's there only one >>>> server cert. Does that not work? >>> >>> Actually I didn't check this specifically. But, I used a server >>> certificate with wrong subject and that made ipa-server-install fail. >>> >> >> One of the many cases that we will need to handle. > > I found that python-nss has a verify_hostname call. I'll add it. It also has Certificate.verify_now(). There are examples of usage in either the doc/examples directory or the test directory. NB, the cert has to be in the database, a possible limitation for the intended usage. The enhanced unreleased code dispenses with that restriction and adds additional functionality. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Mar 27 17:01:58 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Mar 2013 13:01:58 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <51532206.8040405@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <51532206.8040405@redhat.com> Message-ID: <51532606.9090600@redhat.com> On 03/27/2013 12:44 PM, Petr Viktorin wrote: > On 03/27/2013 04:40 PM, John Dennis wrote: >> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>> I don't want to check the subject because this RFE was prompted by IPA's >>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>> ask NSS if it will trust the cert? >> >> Yes. NSS provides a variety of tools to test validation. > > Thanks! I'll take a look at it again. > >> Going just on memory here, our current version of python-nss has a >> simple call to test validation. Sometime in the last year I added a fair >> amount of new support for certificate validation including getting back >> diagnostic information for validation failures, however if I recall >> correctly the extended functionality in python-nss has not been released >> yet. > > I'll add verify_hostname from the validation example; if there's > anything else please give me a pointer -- I haven't read all the docs, yet. > doc/examples/verify_server.py test/test_client_server.py illustrate example usage. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Wed Mar 27 17:09:11 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 27 Mar 2013 18:09:11 +0100 Subject: [Freeipa-devel] [PATCH] 110 Add support for cmocka C-Unit Test framework Message-ID: <20130327170911.GL2112@localhost.localdomain> Hi, this patch does not do anything really useful for now, it just adds configure checks. The related ticket https://fedorahosted.org/freeipa/ticket/3434 is in the current milestone but it can easily deferred to a later milestone if you do not have the time to review it. bye, Sumit -------------- next part -------------- From 8fd76e4b6f911243aa17b73910348c2b4c4bcd7b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 27 Mar 2013 18:00:29 +0100 Subject: [PATCH] Add support for cmocka C-Unit Test framework cmocka is a more advanced unit test framework for C-code than the currently used check framework. This patch adds configure checks and makefile variables so that new unit tests can use cmocka. Fixes https://fedorahosted.org/freeipa/ticket/3434 --- daemons/configure.ac | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/daemons/configure.ac b/daemons/configure.ac index 0eb064665623f0406d88b3d7c019661505650bbe..3e8e81f5e3fa278347c1990ff2d831216e4e5eb3 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -273,6 +273,37 @@ else fi AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) +dnl --------------------------------------------------------------------------- +dnl - Check for cmocka unit test framework http://cmocka.cryptomilk.org/ +dnl This will be simplified when cmocka carries a .pc file. +dnl --------------------------------------------------------------------------- +AC_SUBST(CMOCKA_LIBS) +AC_SUBST(CMOCKA_CFLAGS) + +AC_CHECK_HEADERS( + [setjmp.h cmocka.h],,, + [[ #include + # include + #ifdef HAVE_SETJMP_H + # include + #endif + ]] +) + +if test "x$ac_cv_header_setjmp_h" = "xyes" && test "x$ac_cv_header_cmocka_h" = "xyes" ; then + AC_CHECK_LIB([cmocka], [_will_return], + [ CMOCKA_LIBS="-lcmocka" + AC_MSG_RESULT([libcmocka available, cmocka tests will be build]) + have_cmocka="yes" ], + [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be build]) + have_cmocka="no" ]) +else + AC_MSG_WARN([Required header files for libcmocka are missing, cmocka tests will not be build]) + have_cmocka="no" +fi + +AM_CONDITIONAL([HAVE_CMOCKA], [test x$have_cmocka = xyes]) + dnl -- dirsrv is needed for the extdom unit tests -- PKG_CHECK_MODULES([DIRSRV], [dirsrv >= 1.3.0]) dnl -- sss_idmap is needed by the extdom exop -- -- 1.8.1.4 From orion at cora.nwra.com Thu Mar 28 02:19:50 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 27 Mar 2013 20:19:50 -0600 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <51532183.9070109@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> <515319AD.4060909@redhat.com> <51532183.9070109@redhat.com> Message-ID: <5153A8C6.80603@cora.nwra.com> On 03/27/2013 10:42 AM, Petr Viktorin wrote: > On 03/27/2013 05:09 PM, Rob Crittenden wrote: > [...] >>> Well, I don't like how PEM file duplicates an unnecessary amount of >>> information (the whole certificate). Also, copy-pasting subject might be >>> faster than exporting certificate in PEM and uploading it to the >>> server... >> >> We're talking a one-time operation. I don't think it's asking too much. >> It also gives the user some amount of control rather than assuming that >> whatever tool their using to create the PKCS#12 file is also smart >> enough to include the right CAs. > > Well, to be fair, if there are any intermediate CAs, they need to be in > the PKCS#12. (In the future there may be support for multiple root CAs, > which would all get explicit trust. Those would all go in the PEM, so > intermediate ones must be somewhere else -- in the PKCS#12.) > > Anyway I think it's unlikely that everybody will have the certs in the > right format for IPA by default, whatever that format is. > Honza has a point, but... If one solution is clearly better (in terms of > best/common practices in organizations this feature is for), I'm happy > to change it. Otherwise let's paint the bikeshed with the color I have > ready :) FWIW (about $0.02), it did take me a while to figure out how to create pkcs12 files that included the CA certificate chain out of the PEM files given to me by my CA that ipa needed. Might be nice to have that in docs somewhere. But I can live with this color of bikeshed :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From mkosek at redhat.com Thu Mar 28 07:47:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Mar 2013 08:47:02 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Add mkhomedir option to ipa-server-install and ipa-replica-install In-Reply-To: <5152F502.5060700@redhat.com> References: <5151ECC0.60005@redhat.com> <5152D4E7.8060703@redhat.com> <5152EC19.8040608@redhat.com> <5152F502.5060700@redhat.com> Message-ID: <5153F576.4060507@redhat.com> On 03/27/2013 02:32 PM, Tomas Babej wrote: > On Wed 27 Mar 2013 01:54:49 PM CET, Ana Krivokapic wrote: >> On 03/27/2013 12:15 PM, Tomas Babej wrote: >>> On 03/26/2013 07:45 PM, Ana Krivokapic wrote: >>>> Add the option to create home directories for users on their first login >>>> to ipa-server-install and ipa-replica-install. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3515 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> ACK from the functional point of view. >>> >>> Just a nitpick, can you please reformat the patch and fix PEP8 E501 >>> errors? >>> >>> I know there's a lot of PEP8 errors and warnings in the whole project >>> (and we probably need to adress this), however, let us not introduce >>> new ones. >>> >>> Tomas >> >> Fixed, thanks. >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. > > Thanks. Updated patch works fine, ACK. > > Tomas Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Thu Mar 28 09:20:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Mar 2013 10:20:58 +0100 Subject: [Freeipa-devel] [PATCH] 391-395 Fedora 19 build and install fixes In-Reply-To: <5152BEFB.2040408@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> <5151DFC7.5090209@redhat.com> <5152BEFB.2040408@redhat.com> Message-ID: <51540B7A.9070504@redhat.com> On 03/27/2013 10:42 AM, Tomas Babej wrote: > On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: >> On 03/26/2013 06:32 PM, Tomas Babej wrote: >>> On 03/26/2013 05:38 PM, Martin Kosek wrote: >>>> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>>>> This set of patches (details in commit messages) allow build and >>>>> installation >>>>> of FreeIPA in Fedora 19. I tested server and replica install >>>>> (master on f18, >>>>> replica on f19) and both worked fine. >>>>> >>>>> The patches are compatible with Fedora 18 (I tested). >>>>> >>>>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need >>>>> to get that >>>>> from koji: >>>>> >>>>> Bug 920713 - named timeouts when started via systemd >>>>> >>>>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom >>>>> build of >>>>> 389-ds-base as current builds do not accepts Kerberos tickets >>>>> greater than 2048 >>>>> bytes. This is the bug I filed: >>>>> >>>>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>>>> >>>>> Martin >>>>> >>>> Sending rebased patches (there was a conflic in spec changelog). >>>> >>>> Martin >>>> >>> This still needs the following rebase (changelog is not in >>> chronological order): >>> >>> -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 >>> +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 >> >> Right, I will fix that. >> >>> >>> The build on F19 went OK, however, IPA installation on F19 fails with >>> the >>> following error: >>> >>> [snip] >>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>> minutes 30 seconds >>> [1/20]: creating certificate server user >>> [2/20]: configuring certificate server instance >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> IOError: [Errno 2] No such file or directory: >>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >> >> What pki-ca version do you use? There were some related fixes for bugs >> I found in pki-ca component (see Bug 919476). I used >> pki-ca-10.0.1-2.1.fc19.noarch >> > > The version is the same. > >> If you have this version or higher, what is the root cause of the >> failure? Is there any useful info in ipaserver-install.log? >> > > I haven't been able to identify the cause. There seems to be an issue with > certmonger as well, > since consenquent uninstallation fails with: > > [snip] > 2013-03-26T17:03:19Z INFO The ipa-server-install command failed, exception: > IOError: [Errno 2] No such file or directory: > '/root/.pki/pki-tomcat/ca_admin_cert.p12' > >> Thanks, >> Martin >> >>> >>> >>> Patches work fine on F18. >>> >>> Tomas >> > > Tomas is investigating the Fedora 19 failure, it was most probably caused by improperly upgraded VM. Sending updated and rebased patchset addressing issues found so far. I also reopened BIND bug as BIND does not start after reboot due to wrong tmpfiles.d configuration: https://bugzilla.redhat.com/show_bug.cgi?id=920713 But this should not affect the patches as the fix would need to be done only in bind packages. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-391-3-remove-conflict-with-krb5-1.11.patch Type: text/x-patch Size: 2367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-392-3-remove-build-warnings.patch Type: text/x-patch Size: 14329 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-393-3-remove-syslog.target-from-ipa.server.patch Type: text/x-patch Size: 1876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-394-3-put-pid-file-to-named.conf.patch Type: text/x-patch Size: 3802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-395-3-update-mod_wsgi-socket-directory.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 28 11:20:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 28 Mar 2013 12:20:49 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0205 Installing without a CA, with custom SSL certs In-Reply-To: <5151C36B.5090009@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> Message-ID: <51542791.10809@redhat.com> On 03/26/2013 04:48 PM, Petr Viktorin wrote: > [...] This update adds a check for validity of the server cert's hostname, using python-nss. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0197.3-ipa-server-install-Make-temporary-pin-files-availabl.patch Type: text/x-patch Size: 6412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0198.3-ipa-server-install-Remove-the-selfsign-option.patch Type: text/x-patch Size: 10328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0200.3-Remove-unused-ipapython.certdb.CertDB-class.patch Type: text/x-patch Size: 6266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0201.3-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch Type: text/x-patch Size: 13843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0202.3-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0203.3-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch Type: text/x-patch Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204.3-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 21029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0205.3-Load-the-CA-cert-into-server-NSS-databases.patch Type: text/x-patch Size: 7524 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 28 11:50:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 28 Mar 2013 12:50:29 +0100 Subject: [Freeipa-devel] [WIP] Web UI Refactoring & plugins effort - current state In-Reply-To: <5151ABEE.4010202@redhat.com> References: <51362CB7.8000900@redhat.com> <5151ABEE.4010202@redhat.com> Message-ID: <51542E85.7050507@redhat.com> Thanks for the review, I will incorporate most of the agreed changes ASAP. See comments below. On 03/26/2013 03:08 PM, Endi Sukma Dewata wrote: > Hi, I have some comments & questions. > > Navigation: > > * Dojo/topic is used to handle low-level UI events such as facet-show > and facet-change. Is it possible to use dojo/on or direct method calls? > I suppose topics would also run slower (although that might not be an > issue). The low-level nature might be debatable. I don't have a strong option though so I will change it. Regarding the performance part: Looked at source code and topic is basically a interface for global `Evented` object (and Evented internally uses dojo/on). So the performance is about the same. > Dojo/topic seem to be more appropriate for high-level events such as > phase changes (e.g. UI initialized), data changes (e.g. user added), > auth changes (e.g. login/logout/expiration), etc. which might affect the > UI globally. This way 3rd-party code can subscribe to these topics too. +1 > * The navigation uses a 'hash' array that will be joined with a '/'. > Should we call this a 'path'? Sure. So joining path will produce hash, right? (I consider 'hash' everything in url after the hash sign '#'. > > * Is it necessary to have /e and /p prefixes? Is there a possibility > where 'entity' and 'page' might conflict? > The general idea is to have means to use entity-less facets. It might be an error page, some help, quick actions or whatever (my favorite Web CLI idea :)). The infrastructure is not yet fully implemented/tested. I will uncomment the code and try if its working. Prefixes are there to distinguish following paths: '/e/:entity' '/p/:page' It clearly says what route handler should be used. This pattern also seems more extensible. In theory the prefixes can be removed and routes can be handled by single handler. I'm not sure if it would be a win though. > * When is /p used? Any example? Nowhere yet. First will be the error facet, which reminds me that I should implement proper error reporting for initialization errors (phase errors). > > * The paths probably can be made more REST-like. Suppose in the future > IPA uses REST, they will be easier to translate. Look for REST URL best > practices. This is the path style used in Dogtag: > > /users -> Users search facet > /users/admin -> Admin's details (or initial) facet > /users/admin/memberof_groups -> Admin's member of groups > Nice idea, but not sure if it will add value. More REST-like approach suffers in cases when an entity doesn't have an implicit facet/view. Two search and details facets in automember: /e/automember/searchgroup /e/automember/searchhostgroup If we use the propose form add the facet after / it might be confused with pkey. (Automember plugin is not designed well...) I'm sure we can fine more special cases. In theory we can make custom routes for different entities - make virtual entities. One problem in current router design is that its create_hash method is not exactly extensible in comparison with register_route - plugin/module can register new route handler for some paths but it can't tell the router to make hash in different ways. Now, path structure basically copies UI structure, which is IMO beneficial. > * When you hover over a link, the hash shown doesn't match the actual > hash after clicking the link. Seem like too much work for not much gain. On each update we would have to create hashes for each link, that means to know beforehand what the handler would do with facet state. Some links might not even change the facet state/hash. The only reason why is there something is that 'a' element requires something in 'href' attr. > > * Changing page number doesn't refresh the content. In Permissions > search facet if you click Prev or Next or entering the page number > nothing is changed, but if you go to another facet then come back it > will show the new page. Fixed. There was a typo in Facet_state class. I also noticed related problem. Strict value comparison '===' is used in facet.state_diff method. In general I consider it better than '==' because it helps to avoid surprises. It creates a problem for Numbers stored in a state. For example: that.state.set({page: 1}); Serialization and then deserialization from hash changes 1 to '1'. Which makes state_diff to return true. Question is if it's better to say that all simple values stored in state should be strings or whether it is better to use == for comparison in state_diff. > > * Existing issue, the navigation profile is hard-coded so it's either > admin or self-service, and the identity/user navigation item is defined > twice. Is it possible to generalize this so the navigation items are > defined only once and each item (or the controller) will determine > whether it's supposed to be visible? In the future it might be possible > to show more read-only navigation items in self-service mode, so it's > not only limited to identity/user. I didn't give much thought into profiles yet. I basically transformed existing functionality. I agree that it should/might be improved. Not sure what is the best way. For example I was thinking about, that menu would not be defined centrally like now but each module would add its own menu items in profile phase. It might bring some problems like ordering of items, to many refreshes and so on, but that's manageable. As an example I can mention reversed used case - removal of DNS menu item when dns is not configured. phases.on('profile', function() { if (!IPA.dns_enabled) { menu.remove_item('identity/dns'); } }, 20); > > > Registers: > > * The 'register' objects probably should be called 'registry'. OK. I wasn't sure what's better. > > > Phases: > > * What's the advantage of using dojo/topic to define phases vs. using > inheritance to override phase methods? dojo/topic only notifies about phase changes and it's main purpose is to give some controller information about what is happening. At the moment it's only used for handling 'phase-error' event. I tried to avoid using inheritance/method overriding for the purpose of altering of initialization process. Therefore I created phases as they are. Phase modules are not dependent on any other modules so each module can register it's task independently on other modules. It means they tasks before/after other tasks (each task can have priority set). Probably main benefit is that phases uses Deferreds. So we can synchronize asynchronous tasks - phase is not finished until all tasks are completed. > > * Any example where a phase has multiple tasks? Extensibility. Some module might require to run a command to check if some feature is supported. Something like following: (using dns as if it was an external plugin) var dns_module = { enabled: false, check_support: function() { var deferred = new Deferred(); var command = IPA.command({ entity: 'dns', method: 'is_enabled', on_success: lang.hitch(this, function(data, text_status, xhr) { this.enabled = data.result; deferred.resolve(this.enabled); }), on_error: function(xhr, text_status, error_thrown) { deferred.reject(error_thrown); } } command.execute(); return deferred.promise; } } phases.on('init', function() { return dns_module.check_support(); }); return dns_module; We can see that there is no need to hack IPA.init method. > > * The 'alternation' phase probably should be called 'customization'. Sure When I was writing plugin example I discovered, that it would be useful to be able to add some new phase after/before some existing phase to be able to do some work after all tasks are finished but before we proceed to next phase. Theoretically it can be done in a handler for 'phase-completed' topic but it's limited only to synchronous tasks. > > > Plugins: > > * Right now the Web UI plugin registration requires running a script to > update the index file so the plugin can be loaded. Is it possible to > write a server plugin that reads the content of the UI plugins folder on > the server, and have the UI call it to get the list of UI plugins and > then load it dynamically? We can make a wsgi plugin to run a simple script. I don't like that it would change the nature of static UI + it's necessary to run it every time we load an UI. On the other hand it simplifies installation of FreeIPA and its plugins. I don't have a strong option on either solution. > > * Is there a base class for a plugin? No > Or is a plugin basically a > collection of custom UI components (e.g. entities, facets, widgets)? Yes > > * Any plugin example? How do you customize the menu (e.g. add a new page)? Some examples attached - plain source code and also a patch that can applied and examined in static version. Example shows, that adding new entity is really easy but adding another entity subtree is not really straightforward. > > > Other: > > * The HTML elements in widgets/App.js still contain 'id' attributes > which is a global identifier. Not really a problem since it's only used > once in UI, but to be really modular it should not contain global > identifiers. Yes, we should remove them. > > * This is probably an existing issue, in self-service mode if you select > one of the memberof tabs you'll see the Add & Delete appear briefly then > disappear immediately. Ideally they should appear only if the user has > add/delete rights. Separate issue, will be fixed later. > > * Also in self-service mode, the user can see the action drop down list > and action box (of other users) but none of them actually works. Separate issue, will be fixed later. By testing some stuff for this mail I noticed several errors in DNS and automember plugin, will fix them. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: simpleuser.js Type: application/javascript Size: 6564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0463-Another-user-pages-plugin-example.patch Type: text/x-patch Size: 14694 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 28 14:04:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Mar 2013 15:04:02 +0100 Subject: [Freeipa-devel] [PATCH] 391-395, 398 Fedora 19 build and install fixes In-Reply-To: <51540B7A.9070504@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> <5151DFC7.5090209@redhat.com> <5152BEFB.2040408@redhat.com> <51540B7A.9070504@redhat.com> Message-ID: <51544DD2.1090403@redhat.com> On 03/28/2013 10:20 AM, Martin Kosek wrote: > On 03/27/2013 10:42 AM, Tomas Babej wrote: >> On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: >>> On 03/26/2013 06:32 PM, Tomas Babej wrote: >>>> On 03/26/2013 05:38 PM, Martin Kosek wrote: >>>>> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>>>>> This set of patches (details in commit messages) allow build and >>>>>> installation >>>>>> of FreeIPA in Fedora 19. I tested server and replica install >>>>>> (master on f18, >>>>>> replica on f19) and both worked fine. >>>>>> >>>>>> The patches are compatible with Fedora 18 (I tested). >>>>>> >>>>>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need >>>>>> to get that >>>>>> from koji: >>>>>> >>>>>> Bug 920713 - named timeouts when started via systemd >>>>>> >>>>>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom >>>>>> build of >>>>>> 389-ds-base as current builds do not accepts Kerberos tickets >>>>>> greater than 2048 >>>>>> bytes. This is the bug I filed: >>>>>> >>>>>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>>>>> >>>>>> Martin >>>>>> >>>>> Sending rebased patches (there was a conflic in spec changelog). >>>>> >>>>> Martin >>>>> >>>> This still needs the following rebase (changelog is not in >>>> chronological order): >>>> >>>> -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 >>>> +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 >>> >>> Right, I will fix that. >>> >>>> >>>> The build on F19 went OK, however, IPA installation on F19 fails with >>>> the >>>> following error: >>>> >>>> [snip] >>>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>>> minutes 30 seconds >>>> [1/20]: creating certificate server user >>>> [2/20]: configuring certificate server instance >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> IOError: [Errno 2] No such file or directory: >>>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >>> >>> What pki-ca version do you use? There were some related fixes for bugs >>> I found in pki-ca component (see Bug 919476). I used >>> pki-ca-10.0.1-2.1.fc19.noarch >>> >> >> The version is the same. >> >>> If you have this version or higher, what is the root cause of the >>> failure? Is there any useful info in ipaserver-install.log? >>> >> >> I haven't been able to identify the cause. There seems to be an issue with >> certmonger as well, >> since consenquent uninstallation fails with: >> >> > [snip] >> 2013-03-26T17:03:19Z INFO The ipa-server-install command failed, exception: >> IOError: [Errno 2] No such file or directory: >> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >> >>> Thanks, >>> Martin >>> >>>> >>>> >>>> Patches work fine on F18. >>>> >>>> Tomas >>> >> >> > > Tomas is investigating the Fedora 19 failure, it was most probably caused by > improperly upgraded VM. Sending updated and rebased patchset addressing issues > found so far. > > I also reopened BIND bug as BIND does not start after reboot due to wrong > tmpfiles.d configuration: > https://bugzilla.redhat.com/show_bug.cgi?id=920713 > But this should not affect the patches as the fix would need to be done only in > bind packages. > > Martin > Attaching one more fix for PKI CA installation, installer in F19 seems more sensitive to the certificate downloaded via sslget from pki-ca. It may contain DOS line endings which breaks certutil cert import and crashes the install. Patch 398 fixes it - tested both on F18 and F19. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-391-4-clean-spec-file-for-Fedora-19.patch Type: text/x-patch Size: 2909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-392-4-remove-build-warnings.patch Type: text/x-patch Size: 14329 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-393-4-remove-syslog.target-from-ipa.server.patch Type: text/x-patch Size: 1887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-394-4-put-pid-file-to-named.conf.patch Type: text/x-patch Size: 3802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-395-4-update-mod_wsgi-socket-directory.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-398-4-normalize-ra-agent-certificate.patch Type: text/x-patch Size: 1351 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 28 15:12:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Mar 2013 16:12:03 +0100 Subject: [Freeipa-devel] [PATCH] 110 Add support for cmocka C-Unit Test framework In-Reply-To: <20130327170911.GL2112@localhost.localdomain> References: <20130327170911.GL2112@localhost.localdomain> Message-ID: <51545DC3.5080000@redhat.com> On 03/27/2013 06:09 PM, Sumit Bose wrote: > Hi, > > this patch does not do anything really useful for now, it just adds > configure checks. The related ticket > https://fedorahosted.org/freeipa/ticket/3434 is in the current milestone > but it can easily deferred to a later milestone if you do not have the > time to review it. > > bye, > Sumit > Works fine, tested with and without libcmocka-devel. ACK. Pushed to master. Martin From jcholast at redhat.com Thu Mar 28 15:56:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Mar 2013 16:56:54 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <5152F949.6050604@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> Message-ID: <51546846.9040109@redhat.com> On 27.3.2013 14:51, Martin Kosek wrote: > This looks OK. Please just also add unit tests exercising this new feature. > > Thanks, > Martin > Tests added. I have also made some additional changes: * renamed the virtual attribute from ipakrbflagokasdelegate to ipakrbokasdelegate * fixed internal error when krbticketflags has more than one value * fixed updates overwriting krbticketflags instead of updating it * allow krbticketflags to be overwritten when it has non-integer value * do not hide krbticketflags in command output Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-120.2-Add-Kerberos-ticket-flags-management-to-service-and-.patch Type: text/x-patch Size: 27259 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 28 17:16:30 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Mar 2013 18:16:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0205 Installing without a CA, with custom SSL certs In-Reply-To: <51542791.10809@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> Message-ID: <51547AEE.5000604@redhat.com> On 28.3.2013 12:20, Petr Viktorin wrote: > On 03/26/2013 04:48 PM, Petr Viktorin wrote: >> [...] > > This update adds a check for validity of the server cert's hostname, > using python-nss. > This is what I have found just by looking at the patches: Patch 197: "We names of files with pkcs12 pins to installers ..." This sentence does not seem right to me. Patch 198: + if setup_ca: + print "Be sure to back up the CA certificate stored in /etc/httpd/alias/cacert.p12" + print "The password for this file is in /etc/httpd/alias/pwdfile.txt" This is not the right message. This is the message for --selfsign. Patch 204: + http_cert_name =check_pkcs12(http_pkcs12_info, ca_file, host_name) Missing space after equal sign. More to come tomorrow, when I'm finished with testing. Honza -- Jan Cholasta From pviktori at redhat.com Thu Mar 28 17:14:39 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 28 Mar 2013 18:14:39 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0206 Installing without a CA, with custom SSL certs In-Reply-To: <51542791.10809@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> Message-ID: <51547A7F.8050907@redhat.com> On 03/28/2013 12:20 PM, Petr Viktorin wrote: > On 03/26/2013 04:48 PM, Petr Viktorin wrote: >> [...] > > This update adds a check for validity of the server cert's hostname, > using python-nss. > And another update. Patch 204: Fix default ID range in ipa-server-install New patch 206: The host plugin assumed cert-* commands are always available, and failed when removing/upddating a host because it could not revoke the certificate. This leaves out the revocation if there's no CA. The tests should pass now. The Web UI currently assumes cert-* commands are always available. I'm testing a patch from Petr? that will fix this. Also, clients currently call cert-request via certmonger. This fails. A patch to not request the host certificate in ipa-client-install is coming up. As far as I know, the failing request doesn't hurt anything; old clients should work fine, certmonger will just spam the syslog. I'll add steps to remove the request on old clients to the design doc. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204.4-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 21104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0206-Do-not-call-cert-commands-in-host-plugin-if-a-RA-is-.patch Type: text/x-patch Size: 4859 bytes Desc: not available URL: From tbabej at redhat.com Fri Mar 29 07:13:15 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 29 Mar 2013 08:13:15 +0100 Subject: [Freeipa-devel] [PATCH] 391-395, 398 Fedora 19 build and install fixes In-Reply-To: <51544DD2.1090403@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> <5151DFC7.5090209@redhat.com> <5152BEFB.2040408@redhat.com> <51540B7A.9070504@redhat.com> <51544DD2.1090403@redhat.com> Message-ID: <51553F0B.8090008@redhat.com> On 03/28/2013 03:04 PM, Martin Kosek wrote: > On 03/28/2013 10:20 AM, Martin Kosek wrote: >> On 03/27/2013 10:42 AM, Tomas Babej wrote: >>> On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: >>>> On 03/26/2013 06:32 PM, Tomas Babej wrote: >>>>> On 03/26/2013 05:38 PM, Martin Kosek wrote: >>>>>> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>>>>>> This set of patches (details in commit messages) allow build and >>>>>>> installation >>>>>>> of FreeIPA in Fedora 19. I tested server and replica install >>>>>>> (master on f18, >>>>>>> replica on f19) and both worked fine. >>>>>>> >>>>>>> The patches are compatible with Fedora 18 (I tested). >>>>>>> >>>>>>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need >>>>>>> to get that >>>>>>> from koji: >>>>>>> >>>>>>> Bug 920713 - named timeouts when started via systemd >>>>>>> >>>>>>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom >>>>>>> build of >>>>>>> 389-ds-base as current builds do not accepts Kerberos tickets >>>>>>> greater than 2048 >>>>>>> bytes. This is the bug I filed: >>>>>>> >>>>>>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> Sending rebased patches (there was a conflic in spec changelog). >>>>>> >>>>>> Martin >>>>>> >>>>> This still needs the following rebase (changelog is not in >>>>> chronological order): >>>>> >>>>> -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 >>>>> +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 >>>> Right, I will fix that. >>>> >>>>> The build on F19 went OK, however, IPA installation on F19 fails with >>>>> the >>>>> following error: >>>>> >>>>> [snip] >>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>>>> minutes 30 seconds >>>>> [1/20]: creating certificate server user >>>>> [2/20]: configuring certificate server instance >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> IOError: [Errno 2] No such file or directory: >>>>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >>>> What pki-ca version do you use? There were some related fixes for bugs >>>> I found in pki-ca component (see Bug 919476). I used >>>> pki-ca-10.0.1-2.1.fc19.noarch >>>> >>> The version is the same. >>> >>>> If you have this version or higher, what is the root cause of the >>>> failure? Is there any useful info in ipaserver-install.log? >>>> >>> I haven't been able to identify the cause. There seems to be an issue with >>> certmonger as well, >>> since consenquent uninstallation fails with: >>> >>> >> [snip] >>> 2013-03-26T17:03:19Z INFO The ipa-server-install command failed, exception: >>> IOError: [Errno 2] No such file or directory: >>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >>> >>>> Thanks, >>>> Martin >>>> >>>>> >>>>> Patches work fine on F18. >>>>> >>>>> Tomas >>> >> Tomas is investigating the Fedora 19 failure, it was most probably caused by >> improperly upgraded VM. Sending updated and rebased patchset addressing issues >> found so far. >> >> I also reopened BIND bug as BIND does not start after reboot due to wrong >> tmpfiles.d configuration: >> https://bugzilla.redhat.com/show_bug.cgi?id=920713 >> But this should not affect the patches as the fix would need to be done only in >> bind packages. >> >> Martin >> > Attaching one more fix for PKI CA installation, installer in F19 seems more > sensitive to the certificate downloaded via sslget from pki-ca. It may contain > DOS line endings which breaks certutil cert import and crashes the install. > Patch 398 fixes it - tested both on F18 and F19. > > Martin Patches work fine both on F18 and F19 and indeed fix the discovered issues. There's still the following problem that *can* occur(not 100% reproducible) when installing rpms: [snip] Installing : freeipa-server-3.1.99GITa9b9b77-0.fc19.x86_64 4/7 Installing : freeipa-server-selinux-3.1.99GITa9b9b77-0.fc19.x86_64 5/7 libsemanage.semanage_exec_prog: Child process /sbin/load_policy did not exit cleanly. libsemanage.semanage_reload_policy: load_policy returned error code -1. libsemanage.semanage_exec_prog: Child process /sbin/load_policy did not exit cleanly. libsemanage.semanage_reload_policy: load_policy returned error code -1. semodule: Failed! Installing : freeipa-server-trust-ad-3.1.99GITa9b9b77-0.fc19.x86_64 6/7 Consenquently, it causes the following failure during ipa-server-install: [12/14]: configuring SELinux for httpd WARNING: could not set the following SELinux boolean(s): httpd_can_network_connect -> on httpd_manage_ipa -> on The web interface may not function correctly until the booleans are successfully changed with the command: /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on Try updating the policycoreutils and selinux-policy packages. [13/14]: restarting httpd ... However, this looks like a bug in SELinux policy, probably. The workaround (manual setting of SELinux booleans) is printed out by ipa-server-install script, so I would not consider it as a blocker for this patchset. ACK. Tomas From mkosek at redhat.com Fri Mar 29 08:04:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Mar 2013 09:04:13 +0100 Subject: [Freeipa-devel] [PATCH] 391-395, 398 Fedora 19 build and install fixes In-Reply-To: <51553F0B.8090008@redhat.com> References: <514AE827.2080909@redhat.com> <5151CEEA.7080302@redhat.com> <5151DBC4.3090901@redhat.com> <5151DFC7.5090209@redhat.com> <5152BEFB.2040408@redhat.com> <51540B7A.9070504@redhat.com> <51544DD2.1090403@redhat.com> <51553F0B.8090008@redhat.com> Message-ID: <51554AFD.1010701@redhat.com> On 03/29/2013 08:13 AM, Tomas Babej wrote: > On 03/28/2013 03:04 PM, Martin Kosek wrote: >> On 03/28/2013 10:20 AM, Martin Kosek wrote: >>> On 03/27/2013 10:42 AM, Tomas Babej wrote: >>>> On Tue 26 Mar 2013 06:49:59 PM CET, Martin Kosek wrote: >>>>> On 03/26/2013 06:32 PM, Tomas Babej wrote: >>>>>> On 03/26/2013 05:38 PM, Martin Kosek wrote: >>>>>>> On 03/21/2013 11:59 AM, Martin Kosek wrote: >>>>>>>> This set of patches (details in commit messages) allow build and >>>>>>>> installation >>>>>>>> of FreeIPA in Fedora 19. I tested server and replica install >>>>>>>> (master on f18, >>>>>>>> replica on f19) and both worked fine. >>>>>>>> >>>>>>>> The patches are compatible with Fedora 18 (I tested). >>>>>>>> >>>>>>>> If your Fedora 19 does not have bind-9.9.2-11.P1.fc19, you may need >>>>>>>> to get that >>>>>>>> from koji: >>>>>>>> >>>>>>>> Bug 920713 - named timeouts when started via systemd >>>>>>>> >>>>>>>> Also, to fix trusts and ipa-adtrust-install, I had to use my custom >>>>>>>> build of >>>>>>>> 389-ds-base as current builds do not accepts Kerberos tickets >>>>>>>> greater than 2048 >>>>>>>> bytes. This is the bug I filed: >>>>>>>> >>>>>>>> Bug 923879 - 389-ds-base cannot handle Kerberos tickets with PAC >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> Sending rebased patches (there was a conflic in spec changelog). >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> This still needs the following rebase (changelog is not in >>>>>> chronological order): >>>>>> >>>>>> -* Wed Mar 13 2013 Martin Kosek - 3.1.99-2 >>>>>> +* Tue Mar 26 2013 Martin Kosek - 3.1.99-2 >>>>> Right, I will fix that. >>>>> >>>>>> The build on F19 went OK, however, IPA installation on F19 fails with >>>>>> the >>>>>> following error: >>>>>> >>>>>> [snip] >>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>>>>> minutes 30 seconds >>>>>> [1/20]: creating certificate server user >>>>>> [2/20]: configuring certificate server instance >>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>> IOError: [Errno 2] No such file or directory: >>>>>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >>>>> What pki-ca version do you use? There were some related fixes for bugs >>>>> I found in pki-ca component (see Bug 919476). I used >>>>> pki-ca-10.0.1-2.1.fc19.noarch >>>>> >>>> The version is the same. >>>> >>>>> If you have this version or higher, what is the root cause of the >>>>> failure? Is there any useful info in ipaserver-install.log? >>>>> >>>> I haven't been able to identify the cause. There seems to be an issue with >>>> certmonger as well, >>>> since consenquent uninstallation fails with: >>>> >>>> >>> [snip] >>>> 2013-03-26T17:03:19Z INFO The ipa-server-install command failed, exception: >>>> IOError: [Errno 2] No such file or directory: >>>> '/root/.pki/pki-tomcat/ca_admin_cert.p12' >>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>>> >>>>>> Patches work fine on F18. >>>>>> >>>>>> Tomas >>>> >>> Tomas is investigating the Fedora 19 failure, it was most probably caused by >>> improperly upgraded VM. Sending updated and rebased patchset addressing issues >>> found so far. >>> >>> I also reopened BIND bug as BIND does not start after reboot due to wrong >>> tmpfiles.d configuration: >>> https://bugzilla.redhat.com/show_bug.cgi?id=920713 >>> But this should not affect the patches as the fix would need to be done only in >>> bind packages. >>> >>> Martin >>> >> Attaching one more fix for PKI CA installation, installer in F19 seems more >> sensitive to the certificate downloaded via sslget from pki-ca. It may contain >> DOS line endings which breaks certutil cert import and crashes the install. >> Patch 398 fixes it - tested both on F18 and F19. >> >> Martin > Patches work fine both on F18 and F19 and indeed fix the discovered issues. > > There's still the following problem that *can* occur(not 100% reproducible) > when installing rpms: > > [snip] > Installing : freeipa-server-3.1.99GITa9b9b77-0.fc19.x86_64 4/7 > Installing : freeipa-server-selinux-3.1.99GITa9b9b77-0.fc19.x86_64 5/7 > libsemanage.semanage_exec_prog: Child process /sbin/load_policy did not exit > cleanly. > libsemanage.semanage_reload_policy: load_policy returned error code -1. > libsemanage.semanage_exec_prog: Child process /sbin/load_policy did not exit > cleanly. > libsemanage.semanage_reload_policy: load_policy returned error code -1. > semodule: Failed! > Installing : freeipa-server-trust-ad-3.1.99GITa9b9b77-0.fc19.x86_64 6/7 > > Consenquently, it causes the following failure during ipa-server-install: > > [12/14]: configuring SELinux for httpd > WARNING: could not set the following SELinux boolean(s): > httpd_can_network_connect -> on > httpd_manage_ipa -> on > The web interface may not function correctly until the booleans > are successfully changed with the command: > /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_manage_ipa=on > Try updating the policycoreutils and selinux-policy packages. > [13/14]: restarting httpd > ... > > However, this looks like a bug in SELinux policy, probably. The workaround > (manual setting of SELinux booleans) is printed out by ipa-server-install script, > so I would not consider it as a blocker for this patchset. I filed a Bugzilla for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=929062 We will see what's the real root cause of it. > > ACK. > > Tomas Pushed to master. Martin From mkosek at redhat.com Fri Mar 29 09:55:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Mar 2013 10:55:28 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51546846.9040109@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> <51546846.9040109@redhat.com> Message-ID: <51556510.1050304@redhat.com> On 03/28/2013 04:56 PM, Jan Cholasta wrote: > On 27.3.2013 14:51, Martin Kosek wrote: >> This looks OK. Please just also add unit tests exercising this new feature. >> >> Thanks, >> Martin >> > > Tests added. > > I have also made some additional changes: > > * renamed the virtual attribute from ipakrbflagokasdelegate to > ipakrbokasdelegate > * fixed internal error when krbticketflags has more than one value > * fixed updates overwriting krbticketflags instead of updating it > * allow krbticketflags to be overwritten when it has non-integer value > * do not hide krbticketflags in command output > > Honza > This looks much better, thanks for catching more errors and the unit test. I have few more: 1) API minor number in VERSION file needs a bump 2) I did some functional testing and found strange behavior with services. Adding our custom krbticketflags disables some flags ipa-kdb adds by default, like REQUIRES_PRE_AUTH. Example: # ipa host-add foo.example.com --force ---------------------------- Added host "foo.example.com" ---------------------------- Host name: foo.example.com Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM Password: False Keytab: False Managed by: foo.example.com # ipa-getkeytab -s `hostname` -p host/foo.example.com -k foo.keytab Keytab successfully retrieved and stored in: foo.keytab # kinit -kt foo.keytab host/foo.example.com # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" ... Attributes: REQUIRES_PRE_AUTH Policy: [none] krb5kdc.log correctly shows that preauth is needed: Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.37: NEEDED_PREAUTH: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Additional pre-authentication required Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.37: ISSUE: authtime 1364548860, etypes {rep=18 tkt=18 ses=18}, host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM However, when I add OK_AS_DELEGATE, REQUIRES_PRE_AUTH vanishes: # ipa host-mod foo.example.com --ok-as-delegate=1 ------------------------------- Modified host "foo.example.com" ------------------------------- Host name: foo.example.com Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM Trusted for delegation: True Password: False Keytab: True Managed by: foo.example.com # ipa service-mod HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM --ok-as-delegate=1 -------------------------------------------------------------- Modified service "HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM" -------------------------------------------------------------- Principal: HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM Trusted for delegation: True Managed by: foo.example.com # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" ... Attributes: OK_AS_DELEGATE Policy: [none] Is this intentional? Shouldn't "ipa host-add $HOST" or "ipa service-add $SERVICE" always set "krbticketflags" with this flag (0x00000080) on instead of adding it silently in ipa-kdb? (adding Simo to CC to help us with that). If no, shouldn't we at least add means to set this flag in host-mod or service-mod so that admins can set it? I.e. option like --requires-pre-auth=1 Martin From jcholast at redhat.com Fri Mar 29 10:14:06 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Mar 2013 11:14:06 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0206 Installing without a CA, with custom SSL certs In-Reply-To: <51547A7F.8050907@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> Message-ID: <5155696E.9030209@redhat.com> On 28.3.2013 18:14, Petr Viktorin wrote: > And another update. > > Patch 204: Fix default ID range in ipa-server-install > New patch 206: The host plugin assumed cert-* commands are always > available, and failed when removing/upddating a host because it could > not revoke the certificate. This leaves out the revocation if there's no > CA. > > The tests should pass now. > > > The Web UI currently assumes cert-* commands are always available. I'm > testing a patch from Petr? that will fix this. > > Also, clients currently call cert-request via certmonger. This fails. A > patch to not request the host certificate in ipa-client-install is > coming up. > As far as I know, the failing request doesn't hurt anything; old clients > should work fine, certmonger will just spam the syslog. > I'll add steps to remove the request on old clients to the design doc. > Patch 204: All the validation check in ipa-server-install should also be done in ipa-replica-prepare. It is possible to prepare a replica with invalid certificates, which makes ipa-replica-install fail in the middle of the install process. Also I was able to install IPA with revoked certificates, but it doesn't seem to break anything - the CRL specified in the certificates' CRL distribution point is not automatically imported into any of the NSS databases and when it is imported manually, everything still seems to work fine. I haven't checked OCSP. Can and/or do we want to do something about this? Patch 205: Can we instead require the PKCS#12 files to always contain the whole certificate chain? IMO that way it would be more obvious what should actually be in the files and it would make things easier should there ever be need for --root-ca-subject. Patch 206: In host_del and host_disable, this doesn't have to be done when enable_ra is False: try: (dn, entry_attrs) = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) In host_disable, I think this should be done even when enable_ra is False: # Remove the usercertificate altogether ldap.update_entry(dn, {'usercertificate': None}) Honza -- Jan Cholasta From jcholast at redhat.com Fri Mar 29 10:20:17 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Mar 2013 11:20:17 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0206 Installing without a CA, with custom SSL certs In-Reply-To: <5155696E.9030209@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> Message-ID: <51556AE1.7000104@redhat.com> On 29.3.2013 11:14, Jan Cholasta wrote: > On 28.3.2013 18:14, Petr Viktorin wrote: >> And another update. >> >> Patch 204: Fix default ID range in ipa-server-install >> New patch 206: The host plugin assumed cert-* commands are always >> available, and failed when removing/upddating a host because it could >> not revoke the certificate. This leaves out the revocation if there's no >> CA. >> >> The tests should pass now. >> >> >> The Web UI currently assumes cert-* commands are always available. I'm >> testing a patch from Petr? that will fix this. >> >> Also, clients currently call cert-request via certmonger. This fails. A >> patch to not request the host certificate in ipa-client-install is >> coming up. >> As far as I know, the failing request doesn't hurt anything; old clients >> should work fine, certmonger will just spam the syslog. >> I'll add steps to remove the request on old clients to the design doc. >> > > > Patch 204: > > All the validation check in ipa-server-install should also be done in > ipa-replica-prepare. It is possible to prepare a replica with invalid > certificates, which makes ipa-replica-install fail in the middle of the > install process. > > Also I was able to install IPA with revoked certificates, but it doesn't > seem to break anything - the CRL specified in the certificates' CRL > distribution point is not automatically imported into any of the NSS > databases and when it is imported manually, everything still seems to > work fine. I haven't checked OCSP. Can and/or do we want to do something > about this? Update: the ipa command does not work: $ ipa host-show $HOSTNAME --all --raw ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked. > > > Patch 205: > > Can we instead require the PKCS#12 files to always contain the whole > certificate chain? IMO that way it would be more obvious what should > actually be in the files and it would make things easier should there > ever be need for --root-ca-subject. > > > Patch 206: > > In host_del and host_disable, this doesn't have to be done when > enable_ra is False: > > try: > (dn, entry_attrs) = ldap.get_entry(dn, ['usercertificate']) > except errors.NotFound: > self.obj.handle_not_found(*keys) > > In host_disable, I think this should be done even when enable_ra is False: > > # Remove the usercertificate altogether > ldap.update_entry(dn, {'usercertificate': None}) > > > Honza > -- Jan Cholasta From jcholast at redhat.com Fri Mar 29 10:28:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Mar 2013 11:28:12 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51556510.1050304@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> <51546846.9040109@redhat.com> <51556510.1050304@redhat.com> Message-ID: <51556CBC.8010908@redhat.com> On 29.3.2013 10:55, Martin Kosek wrote: > This looks much better, thanks for catching more errors and the unit test. I > have few more: > > 1) API minor number in VERSION file needs a bump Whoops, fixed. > > 2) I did some functional testing and found strange behavior with services. > Adding our custom krbticketflags disables some flags ipa-kdb adds by default, > like REQUIRES_PRE_AUTH. > > Example: > > # ipa host-add foo.example.com --force > ---------------------------- > Added host "foo.example.com" > ---------------------------- > Host name: foo.example.com > Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM > Password: False > Keytab: False > Managed by: foo.example.com > > # ipa-getkeytab -s `hostname` -p host/foo.example.com -k foo.keytab > Keytab successfully retrieved and stored in: foo.keytab > > # kinit -kt foo.keytab host/foo.example.com > > # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" > ... > Attributes: REQUIRES_PRE_AUTH > Policy: [none] > > > krb5kdc.log correctly shows that preauth is needed: > > Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 > etypes {18 17 16 23}) 10.16.78.37: NEEDED_PREAUTH: > host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for > krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Additional > pre-authentication required > Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 > etypes {18 17 16 23}) 10.16.78.37: ISSUE: authtime 1364548860, etypes {rep=18 > tkt=18 ses=18}, host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for > krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM > > > However, when I add OK_AS_DELEGATE, REQUIRES_PRE_AUTH vanishes: > # ipa host-mod foo.example.com --ok-as-delegate=1 > ------------------------------- > Modified host "foo.example.com" > ------------------------------- > Host name: foo.example.com > Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM > Trusted for delegation: True > Password: False > Keytab: True > Managed by: foo.example.com > > # ipa service-mod HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM --ok-as-delegate=1 > -------------------------------------------------------------- > Modified service "HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM" > -------------------------------------------------------------- > Principal: HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM > Trusted for delegation: True > Managed by: foo.example.com > > # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" > ... > Attributes: OK_AS_DELEGATE > Policy: [none] > > > Is this intentional? > > Shouldn't "ipa host-add $HOST" or "ipa service-add $SERVICE" always set > "krbticketflags" with this flag (0x00000080) on instead of adding it silently > in ipa-kdb? (adding Simo to CC to help us with that). > > If no, shouldn't we at least add means to set this flag in host-mod or > service-mod so that admins can set it? I.e. option like --requires-pre-auth=1 I assumed the default value is 0. I changed it to 0x00000080. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-120.3-Add-Kerberos-ticket-flags-management-to-service-and-.patch Type: text/x-patch Size: 27708 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 29 11:46:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Mar 2013 12:46:14 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51556CBC.8010908@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> <51546846.9040109@redhat.com> <51556510.1050304@redhat.com> <51556CBC.8010908@redhat.com> Message-ID: <51557F06.2060503@redhat.com> On 03/29/2013 11:28 AM, Jan Cholasta wrote: > On 29.3.2013 10:55, Martin Kosek wrote: >> This looks much better, thanks for catching more errors and the unit test. I >> have few more: >> >> 1) API minor number in VERSION file needs a bump > > Whoops, fixed. > >> >> 2) I did some functional testing and found strange behavior with services. >> Adding our custom krbticketflags disables some flags ipa-kdb adds by default, >> like REQUIRES_PRE_AUTH. >> >> Example: >> >> # ipa host-add foo.example.com --force >> ---------------------------- >> Added host "foo.example.com" >> ---------------------------- >> Host name: foo.example.com >> Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM >> Password: False >> Keytab: False >> Managed by: foo.example.com >> >> # ipa-getkeytab -s `hostname` -p host/foo.example.com -k foo.keytab >> Keytab successfully retrieved and stored in: foo.keytab >> >> # kinit -kt foo.keytab host/foo.example.com >> >> # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" >> ... >> Attributes: REQUIRES_PRE_AUTH >> Policy: [none] >> >> >> krb5kdc.log correctly shows that preauth is needed: >> >> Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 >> etypes {18 17 16 23}) 10.16.78.37: NEEDED_PREAUTH: >> host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for >> krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Additional >> pre-authentication required >> Mar 29 05:21:00 vm-037.idm.lab.bos.redhat.com krb5kdc[3977](info): AS_REQ (4 >> etypes {18 17 16 23}) 10.16.78.37: ISSUE: authtime 1364548860, etypes {rep=18 >> tkt=18 ses=18}, host/foo.example.com at IDM.LAB.BOS.REDHAT.COM for >> krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM >> >> >> However, when I add OK_AS_DELEGATE, REQUIRES_PRE_AUTH vanishes: >> # ipa host-mod foo.example.com --ok-as-delegate=1 >> ------------------------------- >> Modified host "foo.example.com" >> ------------------------------- >> Host name: foo.example.com >> Principal name: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM >> Trusted for delegation: True >> Password: False >> Keytab: True >> Managed by: foo.example.com >> >> # ipa service-mod HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM --ok-as-delegate=1 >> -------------------------------------------------------------- >> Modified service "HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM" >> -------------------------------------------------------------- >> Principal: HTTP/foo.example.com at IDM.LAB.BOS.REDHAT.COM >> Trusted for delegation: True >> Managed by: foo.example.com >> >> # kadmin.local -q "getprinc host/foo.example.com at IDM.LAB.BOS.REDHAT.COM" >> ... >> Attributes: OK_AS_DELEGATE >> Policy: [none] >> >> >> Is this intentional? >> >> Shouldn't "ipa host-add $HOST" or "ipa service-add $SERVICE" always set >> "krbticketflags" with this flag (0x00000080) on instead of adding it silently >> in ipa-kdb? (adding Simo to CC to help us with that). >> >> If no, shouldn't we at least add means to set this flag in host-mod or >> service-mod so that admins can set it? I.e. option like --requires-pre-auth=1 > > I assumed the default value is 0. I changed it to 0x00000080. > > Updated patch attached. > > Honza > 1) This causes an error in the test suite: ====================================================================== FAIL: test_service[23]: service_mod: Enable u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE Kerberos ticket flag ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 267, in func = lambda: self.check(nice, **test) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 323, in check_output assert_deepequal(expected, got, nice) File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/tests/util.py", line 323, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (i,)) File "/root/freeipa-master/tests/util.py", line 343, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. test_service[23]: service_mod: Enable u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE Kerberos ticket flag expected = u'1048576' got = u'1048704' path = ('result', 'krbticketflags', 0) ---------------------------------------------------------------------- 2) Since we add REQUIRES_PRE_AUTH flag by default, shouldn't we then also add --requires-pre-auth flag as I wrote above so that admin can get rid of this flag if he chooses to? Martin From pviktori at redhat.com Fri Mar 29 11:57:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Mar 2013 12:57:28 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515312D8.3000502@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> Message-ID: <515581A8.7040902@redhat.com> On 03/27/2013 04:40 PM, John Dennis wrote: > On 03/27/2013 11:23 AM, Petr Viktorin wrote: >> I don't want to check the subject because this RFE was prompted by IPA's >> normal CA rejecting valid wildcart certs. Is there a reasonable way to >> ask NSS if it will trust the cert? > > Yes. NSS provides a variety of tools to test validation. > > Going just on memory here, our current version of python-nss has a > simple call to test validation. Sometime in the last year I added a fair > amount of new support for certificate validation including getting back > diagnostic information for validation failures, however if I recall > correctly the extended functionality in python-nss has not been released > yet. Does the new code include downloading and importing CRLs? > Finding time to work on python-nss has been a problem. This is further > complicated by the fact Mozilla has changed from CVS to Mercurial while > I had this code in development and I haven't moved over to the new > distributed SCM yet. -- Petr? From akrivoka at redhat.com Fri Mar 29 13:15:09 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 29 Mar 2013 14:15:09 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <5151C5DE.7090902@redhat.com> References: <5151C5DE.7090902@redhat.com> Message-ID: <515593DD.3090405@redhat.com> On 03/26/2013 04:59 PM, Tomas Babej wrote: > Hi, > > The ipa-replica-install script tries to add replica's A and PTR > records to the master DNS, if master does manage DNS. However, > master need not to manage replica's zone. Properly handle this use > case. > > https://fedorahosted.org/freeipa/ticket/3496 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The patch works well and fixes the issue. Just a couple of nitpicks: 1) "However, master need not to manage replica's zone." -- This sentence sounds a little strange to me, but I am not a native speaker so I may be wrong about that. 2) There are three PEP8 501 errors introduced by the patch, but given the recent discussion on this subject, I think it is really up to you if you want to take the time to fix these. ACK from the functional perspective. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 29 12:48:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Mar 2013 13:48:35 +0100 Subject: [Freeipa-devel] [PATCH] 0100 Enumerate UPN suffixes in ipasam In-Reply-To: <20130327114449.GI2112@localhost.localdomain> References: <20130325180744.GH6823@redhat.com> <20130327095021.GE2112@localhost.localdomain> <20130327105318.GK6823@redhat.com> <20130327114449.GI2112@localhost.localdomain> Message-ID: <51558DA3.40102@redhat.com> On 03/27/2013 12:46 PM, Sumit Bose wrote: > On Wed, Mar 27, 2013 at 12:53:18PM +0200, Alexander Bokovoy wrote: >> Hi, >> >> On Wed, 27 Mar 2013, Sumit Bose wrote: >>>> Additionally, you can request Windows to update list of name suffixes >>>> via UI. Here is how it looks in Windows 2012 Server: >>>> http://abbra.fedorapeople.org/.paste/win2012-multiple-suffixes.png >>>> >>>> Part of ticket https://fedorahosted.org/freeipa/ticket/2848 >>> >>> I've tested the attached patch with the samba packages mentioned above >>> and everything works as expect. >>> >>> As can be seen in the figure Alexander linked above the new suffixes are >>> disabled by default on the Windows side. This is expected and exactly >>> the same behaviour can be found in AD-AD trusts. Nevertheless it would >>> be good if you can make sure this behaviour is explicitly mentioned e.g. >>> in the design page or other documents to avoid confusion when this >>> feature is tested by others. >> I'll add that, thanks for reminding. >> >>> >>> Review comments are in-line. >>> >>> bye, >>>> + >>>> + /* Since associatedDomain has attributeType MUST, there must be at least one domain */ >>>> + for (i = 0; i < count ; i++) { >>>> + if (strcmp(ldap_state->domain_name, domains[i]) == 0) { >>>> + break; >>>> + } >>>> + } >>> >>> Since we area handling DNS domain names here strcasecmp() would be more >>> fault tolerant? OTOH I think mixed cases here can only happen if some >>> modifies IPA LDAP object manually. >> Technically it should be something that does utf-8 caseless lookups. We >> can go with strcasecmp as it is for time being, I'll add TODO there for >> future IDN handling. > > yes, good idea > >> >> >> New patch attached. Survives Windows 2012 testing. > > Survives my testing with 2008 as well. ACK. > > bye, > Sumit Also survived my testing without support of PASSDB API in samba (i.e. did not crash or disable existing functionality). Pushed to master. Martin From jcholast at redhat.com Fri Mar 29 12:48:47 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Mar 2013 13:48:47 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51557F06.2060503@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> <51546846.9040109@redhat.com> <51556510.1050304@redhat.com> <51556CBC.8010908@redhat.com> <51557F06.2060503@redhat.com> Message-ID: <51558DAF.3020102@redhat.com> On 29.3.2013 12:46, Martin Kosek wrote: > 1) This causes an error in the test suite: > > ====================================================================== > FAIL: test_service[23]: service_mod: Enable > u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE > Kerberos ticket flag > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 267, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 323, in > check_output > assert_deepequal(expected, got, nice) > File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > File "/root/freeipa-master/tests/util.py", line 323, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (i,)) > File "/root/freeipa-master/tests/util.py", line 343, in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > test_service[23]: service_mod: Enable > u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE > Kerberos ticket flag > expected = u'1048576' > got = u'1048704' > path = ('result', 'krbticketflags', 0) > Fixed. > ---------------------------------------------------------------------- > > 2) Since we add REQUIRES_PRE_AUTH flag by default, shouldn't we then also add > --requires-pre-auth flag as I wrote above so that admin can get rid of this > flag if he chooses to? Added. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-120.4-Add-Kerberos-ticket-flags-management-to-service-and-.patch Type: text/x-patch Size: 28715 bytes Desc: not available URL: From tbabej at redhat.com Fri Mar 29 14:11:48 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 29 Mar 2013 15:11:48 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <515593DD.3090405@redhat.com> References: <5151C5DE.7090902@redhat.com> <515593DD.3090405@redhat.com> Message-ID: <5155A124.1090601@redhat.com> On 03/29/2013 02:15 PM, Ana Krivokapic wrote: > On 03/26/2013 04:59 PM, Tomas Babej wrote: >> Hi, >> >> The ipa-replica-install script tries to add replica's A and PTR >> records to the master DNS, if master does manage DNS. However, >> master need not to manage replica's zone. Properly handle this use >> case. >> >> https://fedorahosted.org/freeipa/ticket/3496 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The patch works well and fixes the issue. > > Just a couple of nitpicks: > > 1) "However, master need not to manage replica's zone." -- This > sentence sounds a little strange to me, but I am not a native speaker > so I may be wrong about that. The phrase should be ok. I assume you're worried about "need not" construct, which may sound a bit unusal as opposed to, for example, "does not need to". One could argue that it sounds archaic. However, consider the following chart, which clearly proves the opposite: http://books.google.com/ngrams/chart?content=need%20not%2Cneeds%20not%2Cdoes%20not%20need%20to%2Cdoesn%20'%20t%20need%20to&corpus=0&smoothing=3&year_start=1800&year_end=2000 For more detailed explanation, see: http://english.stackexchange.com/questions/29409/why-use-need-not-instead-of-do-not-need-to > > 2) There are three PEP8 501 errors introduced by the patch, but given > the recent discussion on this subject, I think it is really up to you > if you want to take the time to fix these. Sure I do. Thanks for the catch. Updated patch attached. > > ACK from the functional perspective. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0043-2-Properly-handle-ipa-replica-install-when-its-zone-is.patch Type: text/x-patch Size: 2415 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 29 14:31:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Mar 2013 15:31:22 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0207 Installing without a CA, with custom SSL certs In-Reply-To: <51556AE1.7000104@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> <51556AE1.7000104@redhat.com> Message-ID: <5155A5BA.9060505@redhat.com> Replying to other mail: > Patch 197: > > "We names of files with pkcs12 pins to installers ..." > > This sentence does not seem right to me. Fixed > Patch 198: > > + if setup_ca: > + print "Be sure to back up the CA certificate stored in > /etc/httpd/alias/cacert.p12" > + print "The password for this file is in > /etc/httpd/alias/pwdfile.txt" > > This is not the right message. This is the message for --selfsign. Whoops, fixed > Patch 204: > + http_cert_name =check_pkcs12(http_pkcs12_info, > ca_file, host_name) > > Missing space after equal sign. Fixed On 03/29/2013 11:20 AM, Jan Cholasta wrote: > On 29.3.2013 11:14, Jan Cholasta wrote: >> On 28.3.2013 18:14, Petr Viktorin wrote: >>> And another update. >>> >>> Patch 204: Fix default ID range in ipa-server-install >>> New patch 206: The host plugin assumed cert-* commands are always >>> available, and failed when removing/upddating a host because it could >>> not revoke the certificate. This leaves out the revocation if there's no >>> CA. >>> >>> The tests should pass now. >>> >>> >>> The Web UI currently assumes cert-* commands are always available. I'm >>> testing a patch from Petr? that will fix this. >>> >>> Also, clients currently call cert-request via certmonger. This fails. A >>> patch to not request the host certificate in ipa-client-install is >>> coming up. >>> As far as I know, the failing request doesn't hurt anything; old clients >>> should work fine, certmonger will just spam the syslog. >>> I'll add steps to remove the request on old clients to the design doc. >>> >> >> >> Patch 204: >> >> All the validation check in ipa-server-install should also be done in >> ipa-replica-prepare. It is possible to prepare a replica with invalid >> certificates, which makes ipa-replica-install fail in the middle of the >> install process. Moved check_pkcs12 to installutils, calling it from both. Thanks for the catch! >> Also I was able to install IPA with revoked certificates, but it doesn't >> seem to break anything - the CRL specified in the certificates' CRL >> distribution point is not automatically imported into any of the NSS >> databases and when it is imported manually, everything still seems to >> work fine. I haven't checked OCSP. Can and/or do we want to do something >> about this? > > Update: the ipa command does not work: > > $ ipa host-show $HOSTNAME --all --raw > ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" > ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) > ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno > -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked. I think we can live with not checking CRLs now. I haven't found a way to download CRLs with certutil or python-nss (short of explicitly examining the certs, downloading the CRL and importing it, but I don't think IPA is the place for that). I've asked John. >> Patch 205: >> >> Can we instead require the PKCS#12 files to always contain the whole >> certificate chain? IMO that way it would be more obvious what should >> actually be in the files and it would make things easier should there >> ever be need for --root-ca-subject. Not requiring the root CA is a convenient shortcut. It's common to have certs signed directly by the CA, and in this case you can use either a single-cert PKCS#12 or one with the full chain. Actually, originally the full chain was required, and a user already complained :) If we add a new option, we can specify its requirements on the other options. >> Patch 206: >> >> In host_del and host_disable, this doesn't have to be done when >> enable_ra is False: >> >> try: >> (dn, entry_attrs) = ldap.get_entry(dn, ['usercertificate']) >> except errors.NotFound: >> self.obj.handle_not_found(*keys) In does host_disable, for done_work. Removed in host_del. >> In host_disable, I think this should be done even when enable_ra is >> False: >> >> # Remove the usercertificate altogether >> ldap.update_entry(dn, {'usercertificate': None}) Changed. Adding a new patch for client installation. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0197.5-ipa-server-install-Make-temporary-pin-files-availabl.patch Type: text/x-patch Size: 6417 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0198.5-ipa-server-install-Remove-the-selfsign-option.patch Type: text/x-patch Size: 10375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0200.5-Remove-unused-ipapython.certdb.CertDB-class.patch Type: text/x-patch Size: 6266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0201.5-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch Type: text/x-patch Size: 13843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0202.5-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0203.5-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch Type: text/x-patch Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204.5-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 22742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0205.5-Load-the-CA-cert-into-server-NSS-databases.patch Type: text/x-patch Size: 11090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0206.5-Do-not-call-cert-commands-in-host-plugin-if-a-RA-is-.patch Type: text/x-patch Size: 10403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0207.5-ipa-client-install-Do-not-request-host-certificate-i.patch Type: text/x-patch Size: 3996 bytes Desc: not available URL: From jdennis at redhat.com Fri Mar 29 14:40:47 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 29 Mar 2013 10:40:47 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515581A8.7040902@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <515581A8.7040902@redhat.com> Message-ID: <5155A7EF.50304@redhat.com> On 03/29/2013 07:57 AM, Petr Viktorin wrote: > On 03/27/2013 04:40 PM, John Dennis wrote: >> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>> I don't want to check the subject because this RFE was prompted by IPA's >>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>> ask NSS if it will trust the cert? >> >> Yes. NSS provides a variety of tools to test validation. >> >> Going just on memory here, our current version of python-nss has a >> simple call to test validation. Sometime in the last year I added a fair >> amount of new support for certificate validation including getting back >> diagnostic information for validation failures, however if I recall >> correctly the extended functionality in python-nss has not been released >> yet. > > Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From akrivoka at redhat.com Fri Mar 29 14:48:43 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 29 Mar 2013 15:48:43 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <5155A124.1090601@redhat.com> References: <5151C5DE.7090902@redhat.com> <515593DD.3090405@redhat.com> <5155A124.1090601@redhat.com> Message-ID: <5155A9CB.5010605@redhat.com> On 03/29/2013 03:11 PM, Tomas Babej wrote: > On 03/29/2013 02:15 PM, Ana Krivokapic wrote: >> On 03/26/2013 04:59 PM, Tomas Babej wrote: >>> Hi, >>> >>> The ipa-replica-install script tries to add replica's A and PTR >>> records to the master DNS, if master does manage DNS. However, >>> master need not to manage replica's zone. Properly handle this use >>> case. >>> >>> https://fedorahosted.org/freeipa/ticket/3496 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> The patch works well and fixes the issue. >> >> Just a couple of nitpicks: >> >> 1) "However, master need not to manage replica's zone." -- This >> sentence sounds a little strange to me, but I am not a native speaker >> so I may be wrong about that. > > The phrase should be ok. I assume you're worried about "need not" > construct, which may sound a bit unusal as opposed to, for example, > "does not need to". > > One could argue that it sounds archaic. However, consider the > following chart, which clearly proves the opposite: > > http://books.google.com/ngrams/chart?content=need%20not%2Cneeds%20not%2Cdoes%20not%20need%20to%2Cdoesn%20'%20t%20need%20to&corpus=0&smoothing=3&year_start=1800&year_end=2000 > > > For more detailed explanation, see: > > http://english.stackexchange.com/questions/29409/why-use-need-not-instead-of-do-not-need-to > Actually, the part that sounded weird to me is the "to" that comes after "need not" in your commit message. Also, the stackexchange link you provided states: "This /need/ is a *modal verb*: it always requires an infinitive without /to/;". Sorry that I wasn't clear about this in my first email. >> >> 2) There are three PEP8 501 errors introduced by the patch, but given >> the recent discussion on this subject, I think it is really up to you >> if you want to take the time to fix these. > > Sure I do. Thanks for the catch. Updated patch attached. There is still one line with E501: install/tools/ipa-replica-install:303:80: E501 line too long (80 > 79 characters) > >> >> ACK from the functional perspective. >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. > -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Mar 29 15:00:56 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 29 Mar 2013 16:00:56 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <5155A9CB.5010605@redhat.com> References: <5151C5DE.7090902@redhat.com> <515593DD.3090405@redhat.com> <5155A124.1090601@redhat.com> <5155A9CB.5010605@redhat.com> Message-ID: <5155ACA8.2090408@redhat.com> On 03/29/2013 03:48 PM, Ana Krivokapic wrote: > On 03/29/2013 03:11 PM, Tomas Babej wrote: >> On 03/29/2013 02:15 PM, Ana Krivokapic wrote: >>> On 03/26/2013 04:59 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> The ipa-replica-install script tries to add replica's A and PTR >>>> records to the master DNS, if master does manage DNS. However, >>>> master need not to manage replica's zone. Properly handle this use >>>> case. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3496 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> The patch works well and fixes the issue. >>> >>> Just a couple of nitpicks: >>> >>> 1) "However, master need not to manage replica's zone." -- This >>> sentence sounds a little strange to me, but I am not a native >>> speaker so I may be wrong about that. >> >> The phrase should be ok. I assume you're worried about "need not" >> construct, which may sound a bit unusal as opposed to, for example, >> "does not need to". >> >> One could argue that it sounds archaic. However, consider the >> following chart, which clearly proves the opposite: >> >> http://books.google.com/ngrams/chart?content=need%20not%2Cneeds%20not%2Cdoes%20not%20need%20to%2Cdoesn%20'%20t%20need%20to&corpus=0&smoothing=3&year_start=1800&year_end=2000 >> >> >> For more detailed explanation, see: >> >> http://english.stackexchange.com/questions/29409/why-use-need-not-instead-of-do-not-need-to >> > Actually, the part that sounded weird to me is the "to" that comes > after "need not" in your commit message. Also, the stackexchange link > you provided states: "This /need/ is a *modal verb*: it always > requires an infinitive without /to/;". > > Sorry that I wasn't clear about this in my first email. Yes, that's a mistake on my part, thanks fot catching that. Fixed the commit message. > >>> >>> 2) There are three PEP8 501 errors introduced by the patch, but >>> given the recent discussion on this subject, I think it is really up >>> to you if you want to take the time to fix these. >> >> Sure I do. Thanks for the catch. Updated patch attached. > There is still one line with E501: > > install/tools/ipa-replica-install:303:80: E501 line too long (80 > 79 > characters) I left that one so intentionally. Imho, it would only mangle the line unnecessarily, the line is exactly 80 characters long with no nice point where to break it. > >> >>> >>> ACK from the functional perspective. >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >> > > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0043-3-Properly-handle-ipa-replica-install-when-its-zone-is.patch Type: text/x-patch Size: 2412 bytes Desc: not available URL: From akrivoka at redhat.com Fri Mar 29 15:17:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 29 Mar 2013 16:17:27 +0100 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <5155ACA8.2090408@redhat.com> References: <5151C5DE.7090902@redhat.com> <515593DD.3090405@redhat.com> <5155A124.1090601@redhat.com> <5155A9CB.5010605@redhat.com> <5155ACA8.2090408@redhat.com> Message-ID: <5155B087.5030309@redhat.com> On 03/29/2013 04:00 PM, Tomas Babej wrote: > On 03/29/2013 03:48 PM, Ana Krivokapic wrote: >> On 03/29/2013 03:11 PM, Tomas Babej wrote: >>> On 03/29/2013 02:15 PM, Ana Krivokapic wrote: >>>> On 03/26/2013 04:59 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> The ipa-replica-install script tries to add replica's A and PTR >>>>> records to the master DNS, if master does manage DNS. However, >>>>> master need not to manage replica's zone. Properly handle this use >>>>> case. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3496 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> The patch works well and fixes the issue. >>>> >>>> Just a couple of nitpicks: >>>> >>>> 1) "However, master need not to manage replica's zone." -- This >>>> sentence sounds a little strange to me, but I am not a native >>>> speaker so I may be wrong about that. >>> >>> The phrase should be ok. I assume you're worried about "need not" >>> construct, which may sound a bit unusal as opposed to, for example, >>> "does not need to". >>> >>> One could argue that it sounds archaic. However, consider the >>> following chart, which clearly proves the opposite: >>> >>> http://books.google.com/ngrams/chart?content=need%20not%2Cneeds%20not%2Cdoes%20not%20need%20to%2Cdoesn%20'%20t%20need%20to&corpus=0&smoothing=3&year_start=1800&year_end=2000 >>> >>> >>> For more detailed explanation, see: >>> >>> http://english.stackexchange.com/questions/29409/why-use-need-not-instead-of-do-not-need-to >>> >> Actually, the part that sounded weird to me is the "to" that comes >> after "need not" in your commit message. Also, the stackexchange link >> you provided states: "This /need/ is a *modal verb*: it always >> requires an infinitive without /to/;". >> >> Sorry that I wasn't clear about this in my first email. > Yes, that's a mistake on my part, thanks fot catching that. Fixed the > commit message. >> >>>> >>>> 2) There are three PEP8 501 errors introduced by the patch, but >>>> given the recent discussion on this subject, I think it is really >>>> up to you if you want to take the time to fix these. >>> >>> Sure I do. Thanks for the catch. Updated patch attached. >> There is still one line with E501: >> >> install/tools/ipa-replica-install:303:80: E501 line too long (80 > 79 >> characters) > I left that one so intentionally. Imho, it would only mangle the line > unnecessarily, the line is exactly 80 characters long with no nice > point where to break it. OK, makes sense. >> >>> >>>> >>>> ACK from the functional perspective. >>>> >>>> -- >>>> Regards, >>>> >>>> Ana Krivokapic >>>> Associate Software Engineer >>>> FreeIPA team >>>> Red Hat Inc. >>> >> >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. > ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Mar 29 15:41:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Mar 2013 16:41:32 +0100 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4A35.2060200@redhat.com> References: <514C4A35.2060200@redhat.com> Message-ID: <5155B62C.4060807@redhat.com> On 03/22/2013 01:10 PM, Petr Viktorin wrote: > The design page for CA-less installation with user-provided SSL certs is > available at http://freeipa.org/page/V3/CA-less_install. I've also > copied it to this mail. > > Does it answer all your questions? > I have added "Affected commands" and "Clients" sections to the RFE. Since I mentioned host-mod which takes certs in yet another format, I've added a "Base64-encoded DER certificates" section as well. == Affected commands == IPA's cert plugin and cert-* commands will not be available at all. Calling them will result in CommandError (code 905) No online help will be available on them, or on the "cert" topic. Certificates removed from LDAP will not be automatically revoked. This affects the following commands: * host-del * host-mod * host-disable * service-del * service-mod * service-disable == Clients == Clients in a CA-less IPA installation will work normally, except host certificates will not be assigned automatically. Older clients configure certmonger to obtain the host certificate, which will fail, with the folloging line apparing periodically in the system log: Server failed request, will retry: 905 (RPC failed at server. unknown command 'cert_request'). The errors can be stopped by issuing: # getcert list # to find out the certmonger request ID # getcert stop-tracking If needed, machine certificates may be obtained from the external CA and added to the server with: ipa host-mod --certificate --- === Base64-encoded DER certificates === The letters and symbols between a PEM file's BEGIN CERTIFICATE and END CERTIFICATE markers are a base64-encoded DER-encoded X.509 certificate. To convert between PEM and base64-encoded DER, just add or remove the markers in a text editor. -- Petr? From mkosek at redhat.com Fri Mar 29 15:42:11 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Mar 2013 16:42:11 +0100 Subject: [Freeipa-devel] [WIP][PATCH] 120 Add Kerberos ticket flags management to service and host plugins In-Reply-To: <51558DAF.3020102@redhat.com> References: <5146FCBB.4000500@redhat.com> <5150541A.9030105@redhat.com> <51506B76.5070302@redhat.com> <5151AB25.1070207@redhat.com> <5152F949.6050604@redhat.com> <51546846.9040109@redhat.com> <51556510.1050304@redhat.com> <51556CBC.8010908@redhat.com> <51557F06.2060503@redhat.com> <51558DAF.3020102@redhat.com> Message-ID: <5155B653.2050503@redhat.com> On 03/29/2013 01:48 PM, Jan Cholasta wrote: > On 29.3.2013 12:46, Martin Kosek wrote: >> 1) This causes an error in the test suite: >> >> ====================================================================== >> FAIL: test_service[23]: service_mod: Enable >> u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE >> Kerberos ticket flag >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >> self.test(*self.arg) >> File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 267, in >> >> func = lambda: self.check(nice, **test) >> File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 285, in >> check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 323, in >> check_output >> assert_deepequal(expected, got, nice) >> File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> File "/root/freeipa-master/tests/util.py", line 323, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (i,)) >> File "/root/freeipa-master/tests/util.py", line 343, in assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> test_service[23]: service_mod: Enable >> u'HTTP/testhost1.idm.lab.bos.redhat.com at IDM.LAB.BOS.REDHAT.COM' OK_AS_DELEGATE >> Kerberos ticket flag >> expected = u'1048576' >> got = u'1048704' >> path = ('result', 'krbticketflags', 0) >> > > Fixed. > >> ---------------------------------------------------------------------- >> >> 2) Since we add REQUIRES_PRE_AUTH flag by default, shouldn't we then also add >> --requires-pre-auth flag as I wrote above so that admin can get rid of this >> flag if he chooses to? > > Added. > > Updated patch attached. > > Honza > I discussed this approach also with Simo and current state should be OK since we manipulate krbticketflags only for hosts and services. When we add these options also for users, we need to add big fat warning that pre_auth flag is required for users in order work correctly. ACK. Pushed to master. Martin From pvoborni at redhat.com Fri Mar 29 16:10:12 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Mar 2013 17:10:12 +0100 Subject: [Freeipa-devel] [PATCH] 273 Add ipakrbokasdelegate option to service and host Web UI pages Message-ID: <5155BCE4.2050100@redhat.com> https://fedorahosted.org/freeipa/ticket/3329 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0273-Add-ipakrbokasdelegate-option-to-service-and-host-We.patch Type: text/x-patch Size: 7988 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 29 16:25:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Mar 2013 17:25:29 +0100 Subject: [Freeipa-devel] [PATCH] 271, 272 Added Web UI support for service PAC type option: NONE In-Reply-To: <5153136C.1020805@redhat.com> References: <5114FD48.3070104@redhat.com> <511A6A54.1040307@redhat.com> <511A7437.8000207@redhat.com> <511ABF1F.70106@redhat.com> <511CD8F6.9040509@redhat.com> <511D093C.5090602@redhat.com> <5138980F.8070205@redhat.com> <5143A503.4020409@redhat.com> <515038FC.4050307@redhat.com> <5151E0FC.8080909@redhat.com> <5153136C.1020805@redhat.com> Message-ID: <5155C079.6000001@redhat.com> On 03/27/2013 04:42 PM, Endi Sukma Dewata wrote: > On 3/26/2013 12:55 PM, Endi Sukma Dewata wrote: >> On 3/25/2013 6:46 AM, Petr Vobornik wrote: >>> Reimplemented ^^ to match your proposal. Attaching as patches with new >>> numbers (271,272) as they don't have much common with the original >>> patch. >> >> The code looks good. Do you have a static/live demo site? > > After some testing, ACK. Pushed to master. > > One minor thing (and you already documented this behavior), suppose > initially you override the PAC types, then you change to inherit the > settings, then you switch back to override, the checkboxes aren't restored. > > Yes, there's an undo/reset button, but it would be nice if we can > preserve the checkboxes (by disabling them but keep the selection) even > if the radio button isn't selected. Then if we save the changes, the > disabled checkboxes can be completely cleared. > I agree, just not sure when to improve it. -- Petr Vobornik From pvoborni at redhat.com Fri Mar 29 17:17:08 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Mar 2013 18:17:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <51470169.1090308@redhat.com> References: <51470169.1090308@redhat.com> Message-ID: <5155CC94.3060208@redhat.com> Hello, attaching Web UI part. Petr On 03/18/2013 12:58 PM, Petr Viktorin wrote: > Hello, > While the work is not complete, these patches allowed me to install an > IPA server without a CA, using PKCS#12 files for the server certs. > > The patches don't break normal installation. > The --selfsign option (but not yet the code behind it) is removed. > > The absence of a CA is indicated by `enable_ra=False` in the IPA config. > > ipa-replica-install will still refuse to run; I'll look into that next. > > I removed some unused code that got in my way: Dogtag 9 installation (we > can run a Dogtag 9-style CA, but we never *install* it), and > ipapython.certdb.CertDB (unused, not to be confused with ipaserver's > CertDB). > > I tried using python-nss, but unfortunately found that it's not yet > usable here. John filed > https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our > conversation. Parsing certutil output, while dirty, is more reliable in > my limited experience. > I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper > around certdb operations. We have a CertDB class for it but that one is > too tied to the current code paths: when I used it I found myself > re-implementing a lot of methods to get rid of some assumption or other. > The new NSSDatabase is not tied to IPA configuration. > > > From what I've learned, PKCS#12 files are just a bag of certificates; > there are basically no restrictions on their contents. But we assume > there's only one cert inside that has a private key, and use that for > the server cert. We also pretty much assume that there's one CA cert: if > not we pick the first one and trust it as root CA. > In short, I think --http_pkcs & friends are too vague for PKCS#12s we > don't control; we should have the user name the certs more explicitly. > Am I wrong here? Is this the usual way to import server certs? > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0274-Web-UI-Disable-cert-functionality-if-a-CA-is-not-ava.patch Type: text/x-patch Size: 4597 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 29 16:23:28 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Mar 2013 17:23:28 +0100 Subject: [Freeipa-devel] [PATCH] 273 Add ipakrbokasdelegate option to service and host Web UI pages In-Reply-To: <5155BCE4.2050100@redhat.com> References: <5155BCE4.2050100@redhat.com> Message-ID: <5155C000.2070002@redhat.com> On 03/29/2013 05:10 PM, Petr Vobornik wrote: > > https://fedorahosted.org/freeipa/ticket/3329 > Attaching new rebased version. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0273-1-Add-ipakrbokasdelegate-option-to-service-and-host-We.patch Type: text/x-patch Size: 7914 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 29 17:33:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Mar 2013 18:33:22 +0100 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <5155CC94.3060208@redhat.com> References: <51470169.1090308@redhat.com> <5155CC94.3060208@redhat.com> Message-ID: <5155D062.2030000@redhat.com> On 03/29/2013 06:17 PM, Petr Vobornik wrote: > Hello, > > attaching Web UI part. > > Petr > Works well for me, if someone can check if the Javascript looks fine then ACK. -- Petr? From dpal at redhat.com Fri Mar 29 20:50:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 29 Mar 2013 16:50:44 -0400 Subject: [Freeipa-devel] Modular PSKC document parser In-Reply-To: <1364347908.2660.148.camel@willson.li.ssimo.org> References: <1364347908.2660.148.camel@willson.li.ssimo.org> Message-ID: <5155FEA4.1000306@redhat.com> On 03/26/2013 09:31 PM, Simo Sorce wrote: > On Tue, 2013-03-26 at 20:46 +0100, Petr Kub?t wrote: >> Hello everyone, >> >> >> I am a student at the Brno University of Technology and am working on >> my bachelor's thesis in cooperation with Red Hat (my supervisor is Jan >> Zeleny). >> The project is basically a Portable Symmetric Key Container (PSKC) >> document parser written in Python with modules to store the parsed >> information into various storage formats. I will also be designing and >> implementing a module to store the information into a 389 Directory >> Server and as such was told by my supervisor to ask you if you would >> be interested in the project for the FreeIPA solution. > It may be interesting, can you give us a bit more background on the > project and what kind usage do you see it valuable for? > > Simo. > Simo, This is rfc6030 http://tools.ietf.org/html/rfc6030 The main point of the project is to allow loading token data that comes in a from of XML file in the different destinations. For IPA the value would be the ability to support 3rd party hardware OTP tokens The work would be to create a library that would allow processing an XML file and storing data in a provided back end. One back end we care about - LDAP, but in future other people should be able to add other back ends if they need to. Petr Welcome! Our OTP schema is defined here: http://www.freeipa.org/page/V3/OTP I think this is a good start. Let us know if you have any other questions. Nathaniel, I might make sense for you and Petr to work more closely in this area. Nathan, You might want to keep an eye too. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Mar 29 20:58:20 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 29 Mar 2013 16:58:20 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <5153A8C6.80603@cora.nwra.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312E7.20604@redhat.com> <515319AD.4060909@redhat.com> <51532183.9070109@redhat.com> <5153A8C6.80603@cora.nwra.com> Message-ID: <5156006C.2040306@redhat.com> On 03/27/2013 10:19 PM, Orion Poplawski wrote: > On 03/27/2013 10:42 AM, Petr Viktorin wrote: >> On 03/27/2013 05:09 PM, Rob Crittenden wrote: >> [...] >>>> Well, I don't like how PEM file duplicates an unnecessary amount of >>>> information (the whole certificate). Also, copy-pasting subject >>>> might be >>>> faster than exporting certificate in PEM and uploading it to the >>>> server... >>> >>> We're talking a one-time operation. I don't think it's asking too much. >>> It also gives the user some amount of control rather than assuming that >>> whatever tool their using to create the PKCS#12 file is also smart >>> enough to include the right CAs. >> >> Well, to be fair, if there are any intermediate CAs, they need to be in >> the PKCS#12. (In the future there may be support for multiple root CAs, >> which would all get explicit trust. Those would all go in the PEM, so >> intermediate ones must be somewhere else -- in the PKCS#12.) >> >> Anyway I think it's unlikely that everybody will have the certs in the >> right format for IPA by default, whatever that format is. >> Honza has a point, but... If one solution is clearly better (in terms of >> best/common practices in organizations this feature is for), I'm happy >> to change it. Otherwise let's paint the bikeshed with the color I have >> ready :) > > FWIW (about $0.02), it did take me a while to figure out how to create > pkcs12 files that included the CA certificate chain out of the PEM > files given to me by my CA that ipa needed. Might be nice to have > that in docs somewhere. But I can live with this color of bikeshed :) > > > Would you mind writing a page or a blog about it? That would be really appreciated. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/