From tbabej at redhat.com Fri Aug 1 10:30:06 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 01 Aug 2014 12:30:06 +0200 Subject: [Freeipa-devel] [PATCHES 247-259] ID views - management part Message-ID: <53DB6C2E.1050501@redhat.com> Hi, the following set of patches implements the ID view creation and management of views and ID overrides in IPA. Pending questions: 1.) The patch 253 implements basic managed permissions for ID views and ID overrides. Do we want to have a separate permission for assigning ID views? 2.) Performance: idview-apply command takes ~100 seconds for hostgroups with 1000 member hosts. I am able to lower that by 20-30% using raw ldap calls, is bypassing the framework worth the performance gain? We'll lose the possiblity to hook on exception callbacks. The commands also need more helpful documentation, I am working on that. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0247-idviews-Add-necessary-schema-for-the-ID-views.patch Type: text/x-patch Size: 5041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0248-idviews-Create-container-for-ID-views-under-cn-accou.patch Type: text/x-patch Size: 1875 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0249-idviews-Add-ipaAssignedIDVIew-reference-to-the-host-.patch Type: text/x-patch Size: 9356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0250-ipalib-Remove-redundant-and-star-imports-from-host-p.patch Type: text/x-patch Size: 2623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0251-ipalib-PEP8-fixes-for-host-plugin.patch Type: text/x-patch Size: 6857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0252-idviews-Create-basic-idview-plugin-structure.patch Type: text/x-patch Size: 17264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0253-idvies-Add-managed-permissions-for-idview-and-idover.patch Type: text/x-patch Size: 3844 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0254-idviews-Set-proper-objectclass-for-the-ID-override-o.patch Type: text/x-patch Size: 4302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0255-hostgroup-Add-helper-that-returns-all-members-of-a-h.patch Type: text/x-patch Size: 978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0256-hostgroup-Remove-redundant-and-star-imports.patch Type: text/x-patch Size: 1279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0257-hostgroup-Selected-PEP8-fixes-for-the-hostgroup-plug.patch Type: text/x-patch Size: 2851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0258-idviews-Add-ipa-idview-apply-and-idview-unapply-comm.patch Type: text/x-patch Size: 9710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0259-idviews-Extend-idview-show-command-to-display-assign.patch Type: text/x-patch Size: 5038 bytes Desc: not available URL: From simo at redhat.com Fri Aug 1 11:54:55 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Aug 2014 07:54:55 -0400 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53D76E12.9090002@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> <53D76E12.9090002@redhat.com> Message-ID: <1406894095.19681.8.camel@willson.usersys.redhat.com> On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going > to comment the steps from the link above here: I think anyone with a fedora login can change it, but thanks anyway, you clarified quite some things. I have a questions about algorithms agility though, are we tied to use AES128 and RSA2048 ? Or do we have the means to specify and use alternative algorithms should it be necessary ? (Like EC instead of RSA ?) Also would you know where I can find details on how CKM_AES_KEY_WRAP[_PAD] is actually implemented ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Aug 1 12:00:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Aug 2014 14:00:18 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1406894095.19681.8.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> <53D76E12.9090002@redhat.com> <1406894095.19681.8.camel@willson.usersys.redhat.com> Message-ID: <53DB8152.4080303@redhat.com> On 08/01/2014 01:54 PM, Simo Sorce wrote: > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going >> to comment the steps from the link above here: > > I think anyone with a fedora login can change it, but thanks anyway, you > clarified quite some things. Yup. Wiki edits are allowed for all authenticated users, check "Edit this page" button at the bottom of the page. Honza, please add your clarification to the page, as we can see - it clarifies a lot. Thanks, Martin From jcholast at redhat.com Fri Aug 1 12:31:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 01 Aug 2014 14:31:04 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1406894095.19681.8.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> <53D76E12.9090002@redhat.com> <1406894095.19681.8.camel@willson.usersys.redhat.com> Message-ID: <53DB8888.80902@redhat.com> Dne 1.8.2014 v 13:54 Simo Sorce napsal(a): > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going >> to comment the steps from the link above here: > > I think anyone with a fedora login can change it, but thanks anyway, you > clarified quite some things. > > I have a questions about algorithms agility though, are we tied to use > AES128 and RSA2048 ? Or do we have the means to specify and use > alternative algorithms should it be necessary ? > (Like EC instead of RSA ?) The schema allows different key types and wrapping algorithms to be used in the future. > > Also would you know where I can find details on how > CKM_AES_KEY_WRAP[_PAD] is actually implemented ? CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394, CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649. We don't use CKM_AES_KEY_WRAP ATM. > > Simo. > -- Jan Cholasta From simo at redhat.com Fri Aug 1 13:34:31 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Aug 2014 09:34:31 -0400 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53DB8888.80902@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> <53D76E12.9090002@redhat.com> <1406894095.19681.8.camel@willson.usersys.redhat.com> <53DB8888.80902@redhat.com> Message-ID: <1406900071.19681.9.camel@willson.usersys.redhat.com> On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote: > Dne 1.8.2014 v 13:54 Simo Sorce napsal(a): > > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote: > > > >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going > >> to comment the steps from the link above here: > > > > I think anyone with a fedora login can change it, but thanks anyway, you > > clarified quite some things. > > > > I have a questions about algorithms agility though, are we tied to use > > AES128 and RSA2048 ? Or do we have the means to specify and use > > alternative algorithms should it be necessary ? > > (Like EC instead of RSA ?) > > The schema allows different key types and wrapping algorithms to be used > in the future. Excellent > > > > Also would you know where I can find details on how > > CKM_AES_KEY_WRAP[_PAD] is actually implemented ? > > CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394, > CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649. We don't > use CKM_AES_KEY_WRAP ATM. Thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Aug 1 14:45:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Aug 2014 16:45:10 +0200 Subject: [Freeipa-devel] [PATCH] 481 ipa-adtrust-install does not re-add member in adtrust agents Message-ID: <53DBA7F6.3020203@redhat.com> When a CIFS service exists and adtrust agents group does not have it as a member attribute (for whatever reason), re-running ipa-adtrust-install does not fix the inconsistency. Make the installer more robust by being able to fix the inconsistency. https://fedorahosted.org/freeipa/ticket/4464 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-481-ipa-adtrust-install-does-not-re-add-member-in-adtrus.patch Type: text/x-patch Size: 3177 bytes Desc: not available URL: From abokovoy at redhat.com Fri Aug 1 14:53:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 1 Aug 2014 17:53:58 +0300 Subject: [Freeipa-devel] [PATCH] 481 ipa-adtrust-install does not re-add member in adtrust agents In-Reply-To: <53DBA7F6.3020203@redhat.com> References: <53DBA7F6.3020203@redhat.com> Message-ID: <20140801145358.GI3492@redhat.com> On Fri, 01 Aug 2014, Martin Kosek wrote: >When a CIFS service exists and adtrust agents group does not >have it as a member attribute (for whatever reason), re-running >ipa-adtrust-install does not fix the inconsistency. > >Make the installer more robust by being able to fix the inconsistency. > >https://fedorahosted.org/freeipa/ticket/4464 > ACK. -- / Alexander Bokovoy From edewata at redhat.com Fri Aug 1 15:28:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 01 Aug 2014 10:28:28 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <1406846048.19681.6.camel@willson.usersys.redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> Message-ID: <53DBB21C.40408@redhat.com> On 7/31/2014 5:34 PM, Simo Sorce wrote: > I think you misunderstood what I was proposing. > I was proposing the vault is the unit of encryption, as a single blob of > data. But the vault would still contain multiple secrets, simply > formatted into a json object. > > Something like: > > plaintext: > { > { id: "email", > data: "Passw0rd", > description: "my email password" > }, > { id: "redhat.com", > data: "Secret5", > description: "redhat.com website password" > }, > ... > } OK, understood. This means in the service use case the service vault password will have to be provisioned to service instances using separate vaults that use asymmetric encryption key. This type of vaults will become a "drop box" and will not support escrow. >> Any concern about the crypto operations being computationally expensive, >> or retrieving the whole blob just to see the metadata would waste bandwidth? > > How big do you think the vault would be ? > It is not meant to contain anything more than a bunch of passwords, do > we really have a problem if the blob is a few tens of kilobytes ? I can't say how people will use it, but regardless, we can configure the size limit on the server. > Given service passwords is an actual use case I think /services should > be a top level namespace available by default. OK. Any preference how the service vaults should be structured? * /services/@ -> repetitive server name? * /services// -> more organized Is this going to be the service drop box (to provision the service vault password) or the service vault (that the instance is going to access using the service vault password)? Or will the instances access a shared service vault? -- Endi S. Dewata From simo at redhat.com Fri Aug 1 17:21:24 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Aug 2014 13:21:24 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53DBB21C.40408@redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> <53DBB21C.40408@redhat.com> Message-ID: <1406913684.19681.13.camel@willson.usersys.redhat.com> On Fri, 2014-08-01 at 10:28 -0500, Endi Sukma Dewata wrote: > On 7/31/2014 5:34 PM, Simo Sorce wrote: > > I think you misunderstood what I was proposing. > > I was proposing the vault is the unit of encryption, as a single blob of > > data. But the vault would still contain multiple secrets, simply > > formatted into a json object. > > > > Something like: > > > > plaintext: > > { > > { id: "email", > > data: "Passw0rd", > > description: "my email password" > > }, > > { id: "redhat.com", > > data: "Secret5", > > description: "redhat.com website password" > > }, > > ... > > } > > OK, understood. This means in the service use case the service vault > password will have to be provisioned to service instances using separate > vaults that use asymmetric encryption key. This type of vaults will > become a "drop box" and will not support escrow. I do not understand why escrow would not be supported, can you elaborate ? > >> Any concern about the crypto operations being computationally expensive, > >> or retrieving the whole blob just to see the metadata would waste bandwidth? > > > > How big do you think the vault would be ? > > It is not meant to contain anything more than a bunch of passwords, do > > we really have a problem if the blob is a few tens of kilobytes ? > > I can't say how people will use it, but regardless, we can configure the > size limit on the server. Right > > Given service passwords is an actual use case I think /services should > > be a top level namespace available by default. > > OK. Any preference how the service vaults should be structured? > * /services/@ -> repetitive server name? > * /services// -> more organized The latter seem to make more sense to me. > Is this going to be the service drop box (to provision the service vault > password) or the service vault (that the instance is going to access > using the service vault password)? Or will the instances access a shared > service vault? Good questions, I am not sure. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Fri Aug 1 19:42:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 01 Aug 2014 14:42:27 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <1406913684.19681.13.camel@willson.usersys.redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> <53DBB21C.40408@redhat.com> <1406913684.19681.13.camel@willson.usersys.redhat.com> Message-ID: <53DBEDA3.5080101@redhat.com> On 8/1/2014 12:21 PM, Simo Sorce wrote: >> OK, understood. This means in the service use case the service vault >> password will have to be provisioned to service instances using separate >> vaults that use asymmetric encryption key. This type of vaults will >> become a "drop box" and will not support escrow. > > I do not understand why escrow would not be supported, can you > elaborate ? See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. With a normal vault (symmetric key) the secrets will be encrypted with a symmetric secret key, then the secret key itself will be encrypted with the escrow officer's public key and stored on the server. On recovery the escrow officer will decrypt the encrypted secret key with the private key, and use it to decrypt the secrets. I suppose with a drop box (asymmetric key) the secrets themselves will be encrypted with the public key of the owner (i.e. the service instance), not the escrow officer. The secrets can only be retrieved/recovered using the owner's private key. There's no secret key to escrow, unless we want to escrow the owner's private key? >> OK. Any preference how the service vaults should be structured? >> * /services/@ -> repetitive server name? >> * /services// -> more organized > > The latter seem to make more sense to me. > >> Is this going to be the service drop box (to provision the service vault >> password) or the service vault (that the instance is going to access >> using the service vault password)? Or will the instances access a shared >> service vault? > > Good questions, I am not sure. Unless there's an objection I'll use it as a drop box. I think each service instance should have a mechanism to configure the vaults it's going to use anyway, so we don't have to decide this now. -- Endi S. Dewata From simo at redhat.com Fri Aug 1 19:45:42 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 01 Aug 2014 15:45:42 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53DBEDA3.5080101@redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> <53DBB21C.40408@redhat.com> <1406913684.19681.13.camel@willson.usersys.redhat.com> <53DBEDA3.5080101@redhat.com> Message-ID: <1406922342.19681.20.camel@willson.usersys.redhat.com> On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote: > On 8/1/2014 12:21 PM, Simo Sorce wrote: > >> OK, understood. This means in the service use case the service vault > >> password will have to be provisioned to service instances using separate > >> vaults that use asymmetric encryption key. This type of vaults will > >> become a "drop box" and will not support escrow. > > > > I do not understand why escrow would not be supported, can you > > elaborate ? > > See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. > > With a normal vault (symmetric key) the secrets will be encrypted with a > symmetric secret key, then the secret key itself will be encrypted with > the escrow officer's public key and stored on the server. On recovery > the escrow officer will decrypt the encrypted secret key with the > private key, and use it to decrypt the secrets. > > I suppose with a drop box (asymmetric key) the secrets themselves will > be encrypted with the public key of the owner (i.e. the service > instance), not the escrow officer. The secrets can only be > retrieved/recovered using the owner's private key. There's no secret key > to escrow, unless we want to escrow the owner's private key? The service can create a symmetric key and encrypt it with its public key and the escrow public key. > >> OK. Any preference how the service vaults should be structured? > >> * /services/@ -> repetitive server name? > >> * /services// -> more organized > > > > The latter seem to make more sense to me. > > > >> Is this going to be the service drop box (to provision the service vault > >> password) or the service vault (that the instance is going to access > >> using the service vault password)? Or will the instances access a shared > >> service vault? > > > > Good questions, I am not sure. > > Unless there's an objection I'll use it as a drop box. I think each > service instance should have a mechanism to configure the vaults it's > going to use anyway, so we don't have to decide this now. I am not sure having no escrow is good, often services are given secrets need to connect to third parties so escrow may be important in case the service private key is lost accidentally. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Fri Aug 1 20:04:45 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 01 Aug 2014 15:04:45 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <1406922342.19681.20.camel@willson.usersys.redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> <53DBB21C.40408@redhat.com> <1406913684.19681.13.camel@willson.usersys.redhat.com> <53DBEDA3.5080101@redhat.com> <1406922342.19681.20.camel@willson.usersys.redhat.com> Message-ID: <53DBF2DD.4060900@redhat.com> On 8/1/2014 2:45 PM, Simo Sorce wrote: > On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote: >> On 8/1/2014 12:21 PM, Simo Sorce wrote: >>>> OK, understood. This means in the service use case the service vault >>>> password will have to be provisioned to service instances using separate >>>> vaults that use asymmetric encryption key. This type of vaults will >>>> become a "drop box" and will not support escrow. >>> >>> I do not understand why escrow would not be supported, can you >>> elaborate ? >> >> See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. >> >> With a normal vault (symmetric key) the secrets will be encrypted with a >> symmetric secret key, then the secret key itself will be encrypted with >> the escrow officer's public key and stored on the server. On recovery >> the escrow officer will decrypt the encrypted secret key with the >> private key, and use it to decrypt the secrets. >> >> I suppose with a drop box (asymmetric key) the secrets themselves will >> be encrypted with the public key of the owner (i.e. the service >> instance), not the escrow officer. The secrets can only be >> retrieved/recovered using the owner's private key. There's no secret key >> to escrow, unless we want to escrow the owner's private key? > > The service can create a symmetric key and encrypt it with its public > key and the escrow public key. Not sure I understand. How does the admin provision the service vault password to the instance? How does the instance retrieve the service vault password? How does the escrow officer recover the service vault password? >>>> OK. Any preference how the service vaults should be structured? >>>> * /services/@ -> repetitive server name? >>>> * /services// -> more organized >>> >>> The latter seem to make more sense to me. >>> >>>> Is this going to be the service drop box (to provision the service vault >>>> password) or the service vault (that the instance is going to access >>>> using the service vault password)? Or will the instances access a shared >>>> service vault? >>> >>> Good questions, I am not sure. >> >> Unless there's an objection I'll use it as a drop box. I think each >> service instance should have a mechanism to configure the vaults it's >> going to use anyway, so we don't have to decide this now. > > I am not sure having no escrow is good, often services are given secrets > need to connect to third parties so escrow may be important in case the > service private key is lost accidentally. Those secrets probably should be stored in the service vault (which will be accessed using the service vault password) instead of in the drop box. That service vault will support normal escrow since it's using symmetric key. -- Endi S. Dewata From jcholast at redhat.com Mon Aug 4 08:39:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 04 Aug 2014 10:39:12 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage In-Reply-To: <53D113D8.9050507@redhat.com> References: <53D113D8.9050507@redhat.com> Message-ID: <53DF46B0.3070301@redhat.com> Dne 24.7.2014 v 16:10 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes . > > Requires my patches 246 and 262 (current versions attached). > > Honza Forgot to update the man page. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.8-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.7-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-308.1-Allow-changing-CA-renewal-master-in-ipa-csreplica-ma.patch Type: text/x-patch Size: 3742 bytes Desc: not available URL: From pviktori at redhat.com Mon Aug 4 09:22:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 04 Aug 2014 11:22:17 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap In-Reply-To: <53D9FD4B.5050608@redhat.com> References: <53D12736.9000409@redhat.com> <53D68F7C.5040006@redhat.com> <53D73EEC.6090607@redhat.com> <53D770D3.5020007@redhat.com> <53D9FD4B.5050608@redhat.com> Message-ID: <53DF50C9.7060601@redhat.com> On 07/31/2014 10:24 AM, Jan Cholasta wrote: > Dne 29.7.2014 v 12:00 Petr Viktorin napsal(a): >> On 07/29/2014 08:27 AM, Jan Cholasta wrote: >>> Dne 28.7.2014 v 19:59 Petr Viktorin napsal(a): >>>> On 07/24/2014 05:33 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>>> >>>> >>>> NACK >>>> If the value *is* a str, with this patch it ends up undefined. >>>> >>> >>> Right, fixed. >>> >> >> ACK, pushed to: >> master: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b >> ipa-4-1: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b >> ipa-4-0: 2eee6060f3237cc4cf23f4044e67e95d7fad195d >> >> Could you also write a test for this, though? > > Sure. > Thanks! ACK, pushed to: master: 34de95545d0a09de2f1acc6987edc27feb762c1b ipa-4-0: c93fe68e398a32b1ed0a139613da452e151e7156 ipa-4-1: 34de95545d0a09de2f1acc6987edc27feb762c1b -- Petr? From jcholast at redhat.com Mon Aug 4 09:30:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 04 Aug 2014 11:30:49 +0200 Subject: [Freeipa-devel] [PATCH] 312 Fix parsing of long nicknames in certutil -L output Message-ID: <53DF52C9.2030707@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-312-Fix-parsing-of-long-nicknames-in-certutil-L-output.patch Type: text/x-patch Size: 1072 bytes Desc: not available URL: From pviktori at redhat.com Mon Aug 4 10:21:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 04 Aug 2014 12:21:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0629-0630 test_integration.task: Add DNS A records when installing a master Message-ID: <53DF5EB9.90600@redhat.com> Hello, Here are some fixes to our integration tests. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0629-test_integration.tasks-Wait-for-DNS-after-adding-A-r.patch Type: text/x-patch Size: 1260 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0630-test_integration.task-Add-DNS-A-records-when-install.patch Type: text/x-patch Size: 2995 bytes Desc: not available URL: From tbabej at redhat.com Mon Aug 4 10:35:16 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 04 Aug 2014 12:35:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0629-0630 test_integration.task: Add DNS A records when installing a master In-Reply-To: <53DF5EB9.90600@redhat.com> References: <53DF5EB9.90600@redhat.com> Message-ID: <53DF61E4.9050609@redhat.com> Functionally the patches look OK, tests are passing as well. 629: ACK 630: The only thing missing is the documentation of the new suboption in the ipa-test-task manpage. When you add that, it's an ACK for both patches. On 08/04/2014 12:21 PM, Petr Viktorin wrote: > Hello, > Here are some fixes to our integration tests. > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mkosek at redhat.com Mon Aug 4 10:46:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Aug 2014 12:46:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0629-0630 test_integration.task: Add DNS A records when installing a master In-Reply-To: <53DF61E4.9050609@redhat.com> References: <53DF5EB9.90600@redhat.com> <53DF61E4.9050609@redhat.com> Message-ID: <53DF648C.1090203@redhat.com> On 08/04/2014 12:35 PM, Tomas Babej wrote: > Functionally the patches look OK, tests are passing as well. > > 629: ACK Hmm. Does this line: + '-e', 'wait_for_dns=30', really do anything given the environmental variable is evaluated on the server in the post callback? Wouldn't we rather need to update our installer to add this to /etc/ipa/default.conf? > 630: The only thing missing is the documentation of the new suboption in > the ipa-test-task manpage. > > When you add that, it's an ACK for both patches. > > On 08/04/2014 12:21 PM, Petr Viktorin wrote: >> Hello, >> Here are some fixes to our integration tests. Maybe I miss something, but it seems to me that option name + subparser.add_argument('--no-a-records', action='store_false', and arg name + tasks.install_master(master, add_a_records=args.add_a_records) do not match. Martin From pviktori at redhat.com Mon Aug 4 12:27:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 04 Aug 2014 14:27:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0629-0630 test_integration.task: Add DNS A records when installing a master In-Reply-To: <53DF648C.1090203@redhat.com> References: <53DF5EB9.90600@redhat.com> <53DF61E4.9050609@redhat.com> <53DF648C.1090203@redhat.com> Message-ID: <53DF7C4E.80703@redhat.com> On 08/04/2014 12:46 PM, Martin Kosek wrote: > On 08/04/2014 12:35 PM, Tomas Babej wrote: >> Functionally the patches look OK, tests are passing as well. >> >> 629: ACK > > Hmm. Does this line: > > + '-e', 'wait_for_dns=30', > > really do anything given the environmental variable is evaluated on the server > in the post callback? Wouldn't we rather need to update our installer to add > this to /etc/ipa/default.conf? Hm. Correct. I'm retiring the patch for now, and I'll talk to Petr ?pa?ek to see if we can make wait_for_dns a default, since after all any automated deployment could run into this. >> 630: The only thing missing is the documentation of the new suboption in >> the ipa-test-task manpage. >> >> When you add that, it's an ACK for both patches. Added, thanks for the catch. >> On 08/04/2014 12:21 PM, Petr Viktorin wrote: >>> Hello, >>> Here are some fixes to our integration tests. > > Maybe I miss something, but it seems to me that option name > + subparser.add_argument('--no-a-records', action='store_false', > and arg name > + tasks.install_master(master, add_a_records=args.add_a_records) > do not match. You're right, I forgot the `dest`. I've tested more throroughly now. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0630.2-test_integration.task-Add-DNS-A-records-when-install.patch Type: text/x-patch Size: 3871 bytes Desc: not available URL: From jcholast at redhat.com Tue Aug 5 08:30:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 Aug 2014 10:30:09 +0200 Subject: [Freeipa-devel] [PATCH] Make CA-less ipa-server-install option --root-ca-file optional Message-ID: <53E09611.3030903@redhat.com> Hi, the attached patch fixes the code part of . The next step is to review and update CA-less articles in our wiki. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-313-Make-CA-less-ipa-server-install-option-root-ca-file-.patch Type: text/x-patch Size: 14973 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:19:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:19:55 +0200 Subject: [Freeipa-devel] [PATCH] 718 webui: better error reporting Message-ID: <53E0BDDB.3060501@redhat.com> On page: - styled to use proper line breaks - "centered" by .container class and not by huge padding Console: - proper line breaks - links in stack trace are clickable(Chrome) -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0718-webui-better-error-reporting.patch Type: text/x-patch Size: 3130 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:20:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:20:40 +0200 Subject: [Freeipa-devel] [PATCH] 719 webui-ci: fix table widget add Message-ID: <53E0BE08.7010406@redhat.com> add_table_record call used old selector for add button which caused 3 fails in CI: - ERROR: Test automember rebuild membership feature for hosts - ERROR: Test automember rebuild membership feature for users - ERROR: Basic CRUD: dns related to: https://fedorahosted.org/freeipa/ticket/4258 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0719-webui-ci-fix-table-widget-add.patch Type: text/x-patch Size: 1229 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:31:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:31:22 +0200 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements Message-ID: <53E0C08A.9000406@redhat.com> patches 725-728 are preparation for 729 but they can also affect the rest of UI (intentional). 728 is useful for non-admins. We might want to discuss enabling of `hide_empty_widgets` flag in patch 727. ticket: https://fedorahosted.org/freeipa/ticket/4402 [PATCH] 720 webui: add measurement unit to token time step field [PATCH] 721 webui: better otp token type label [PATCH] 722 webui: add token from user page Add 'Add OTP Token' action to user action menu. This option is disabled in self-service when viewing other users. [PATCH] 723 webui: add i18n for the rest of QR code strings [PATCH] 724 webui: display fields based on otp token type - in adder dialog [PATCH] 725 webui: better value-change reporting - widget save() save method should try to always return value even if read only - report value-change event with actual value to allow processing of the value [PATCH] 726 webui: widget initialization - used `ctor_init` instead of `init` to avoid name collision with existing logic - `ctor_init` is called right after widget instantiation. Basically support better inheritance for the old class system which doesn't have proper contructors [PATCH] 727 webui: hide empty fields and sections Hide widgets without a value. Must be explicitly turned on. In widget by `hidden_if_empty` flag. Or globally by `hide_empty_widgets` flag. Global hiding can be individually turned off by `ignore_empty_hiding` flag. [PATCH] 728 webui: hide non-readable fields hide widgets if associated field had received attribute level rights without 'r' right. Explicit rights are required to avoid hiding of special widgets which are not associated with any LDAP attribute. [PATCH] 729 webui: hide otp fields based on token type - uses hide empty feature -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0729-webui-hide-otp-fields-based-on-token-type.patch Type: text/x-patch Size: 1604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0728-webui-hide-non-readable-fields.patch Type: text/x-patch Size: 5654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0727-webui-hide-empty-fields-and-sections.patch Type: text/x-patch Size: 7491 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0726-webui-widget-initialization.patch Type: text/x-patch Size: 1404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0725-webui-better-value-change-reporting.patch Type: text/x-patch Size: 8313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0724-webui-display-fields-based-on-otp-token-type.patch Type: text/x-patch Size: 2027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0723-webui-add-i18n-for-the-rest-of-QR-code-strings.patch Type: text/x-patch Size: 5040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0722-webui-add-token-from-user-page.patch Type: text/x-patch Size: 5194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0721-webui-better-otp-token-type-label.patch Type: text/x-patch Size: 2856 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0720-webui-add-measurement-unit-to-token-time-step-field.patch Type: text/x-patch Size: 1470 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:36:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:36:28 +0200 Subject: [Freeipa-devel] [PATCH] 730-732 webui: Login pages usability improvements Message-ID: <53E0C1BC.7070404@redhat.com> [PATCH] 730 webui: display expired session notification in a more visible area The notification is a primary information of the page. It should be more highlighted. https://fedorahosted.org/freeipa/ticket/4470 [PATCH] 731 webui: improved info msgs on login/token sync/reset pwd pages - add info icons to distinguish and classify the messages. - add info text for OTP fields - fix login instruction inaccuracy related to position of login button https://fedorahosted.org/freeipa/ticket/4470 [PATCH] 732 webui: login screen - improved button switching - added cancel button to reset password view of login screen - re-implemented buttons hiding mechanism - switching between 'Reset Password' and 'Reset Password and Login' according to presence of value in OTP field https://fedorahosted.org/freeipa/ticket/4470 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0732-webui-login-screen-improved-button-switching.patch Type: text/x-patch Size: 7214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0731-webui-improved-info-msgs-on-login-token-sync-reset-p.patch Type: text/x-patch Size: 7745 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0730-webui-display-expired-session-notification-in-a-more.patch Type: text/x-patch Size: 1667 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:38:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:38:37 +0200 Subject: [Freeipa-devel] [PATCH] 733-735 webui: Better description for User authentication types Message-ID: <53E0C23D.2000109@redhat.com> [PATCH] 733 webui: rename tooltip to title - use title for input's elements 'title' attribute - tooltip for Bootstrap's tooltip component https://fedorahosted.org/freeipa/ticket/4471 [PATCH] 734 webui: tooltip support Allow to set 'tooltip' attribute in spec. It displays info icon with Bootstrap's tooltip near field's label. https://fedorahosted.org/freeipa/ticket/4471 [PATCH] 735 webui: better authentication types description Tooltips were added to "User authentication types" and "Default user objectclasses" to describe their relationship and a meaning of not-setting a value. https://fedorahosted.org/freeipa/ticket/4471 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0735-webui-better-authentication-types-description.patch Type: text/x-patch Size: 4622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0734-webui-tooltip-support.patch Type: text/x-patch Size: 2723 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0733-webui-rename-tooltip-to-title.patch Type: text/x-patch Size: 13837 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 11:43:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 13:43:02 +0200 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes Message-ID: <53E0C346.1050700@redhat.com> [PATCH] 736 webui: convert widget.less indentation to spaces [PATCH] 737 webui: improve rule table css - category radio line has line-height large enough to contain undo button -> content doesn't move several pixels on change - remove vertical padding from btns in table headers to maintain about the same height - remove invisible border from link buttons to have the same height for disabled and enabled button [PATCH] 738 webui: sshkey widget - usability fixes - save one click by opening edit dialog right after adding new row - add margin between fingerprint and "show/edit" button - fix honoring of writable/read-only flags upon row creation [PATCH] 739 webui: disable batch action buttons by default action buttons associated with batch actions were enabled by default, but they were disabled right after facet creation and a load of data. It caused a visual flicker. UX is enhanced by making them disabled by default. [PATCH] 740 webui: fix group type padding -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0740-webui-fix-group-type-padding.patch Type: text/x-patch Size: 987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0739-webui-disable-batch-action-buttons-by-default.patch Type: text/x-patch Size: 3841 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0738-webui-sshkey-widget-usability-fixes.patch Type: text/x-patch Size: 2494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0737-webui-improve-rule-table-css.patch Type: text/x-patch Size: 2277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0736-webui-convert-widget.less-indentation-to-spaces.patch Type: text/x-patch Size: 2959 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 5 15:11:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Aug 2014 17:11:19 +0200 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app Message-ID: <53E0F417.8050204@redhat.com> - display info message which points user to FreeOTP project page - the link or the text can be easily changed by a plugin if needed https://fedorahosted.org/freeipa/ticket/4469 Notes: - the design can be a subject of discussion. - the FreeOTP project page [1] is not very end-user friendly but serves the purpose - it's not fully configurable, as decided at today's meeting, but a very simple plugin can hide or modify the message [1] https://fedorahosted.org/freeotp/ -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0741-webui-add-link-to-OTP-token-app.patch Type: text/x-patch Size: 3244 bytes Desc: not available URL: From npmccallum at redhat.com Tue Aug 5 20:22:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 5 Aug 2014 16:22:23 -0400 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app In-Reply-To: <53E0F417.8050204@redhat.com> References: <53E0F417.8050204@redhat.com> Message-ID: <27C058BB-954B-41B2-978F-7ECCBBE346A1@redhat.com> On Aug 5, 2014, at 11:11 AM, Petr Vobornik wrote: > - display info message which points user to FreeOTP project page > - the link or the text can be easily changed by a plugin if needed > > https://fedorahosted.org/freeipa/ticket/4469 > > Notes: > - the design can be a subject of discussion. > - the FreeOTP project page [1] is not very end-user friendly but serves the purpose > - it's not fully configurable, as decided at today's meeting, but a very simple plugin can hide or modify the message > > [1] https://fedorahosted.org/freeotp/ > -- > Petr Vobornik > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Can we wait a few days on this patch? I?m working on a domain name for FreeOTP. Nathaniel From invite at feedspotmailer.com Tue Aug 5 23:08:47 2014 From: invite at feedspotmailer.com (farzad niazmand via Feedspot) Date: Tue, 5 Aug 2014 23:08:47 +0000 Subject: [Freeipa-devel] farzad niazmand is still waiting for you to join Feedspot... Message-ID: <00000147a86e9d3f-49001801-7e39-418f-a109-78a889daff3c-000000@email.amazonses.com>
farzad niazmand is still waiting for you to join Feedspot - A place to organize and read all the sites you visit in one place. Feedspot makes checking your favorite sites as easy as checking your email.
www.feedspot.com



- The Feedspot Team


This email was sent to freeipa-devel at redhat.com. You are receiving pending invitation emails.
You received this email because your friend farzad niazmand (farzad.niazmand at gmail.com) invited you to join Feedspot.
Click here to Unsubscribe if you wish not to receive pending invitation from farzad niazmand via Feedspot.
Feedspot.com, 303 Cape Court, Mill Valley, CA 94941
-------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Aug 6 07:42:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 Aug 2014 09:42:35 +0200 Subject: [Freeipa-devel] [PATCH] Make CA-less ipa-server-install option --root-ca-file optional In-Reply-To: <53E09611.3030903@redhat.com> References: <53E09611.3030903@redhat.com> Message-ID: <53E1DC6B.5030003@redhat.com> Dne 5.8.2014 v 10:30 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes the code part of > . Also the patch depends on my patch 295, which is already available in ipa-4-1 and master. Attaching the current version of the patch. > > The next step is to review and update CA-less articles in our wiki. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.5-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-313-Make-CA-less-ipa-server-install-option-root-ca-file-.patch Type: text/x-patch Size: 14973 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 6 07:57:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 Aug 2014 09:57:06 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install Message-ID: <53E1DFD2.60307@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-314-Allow-specifying-key-algorithm-of-the-IPA-CA-cert-in.patch Type: text/x-patch Size: 6721 bytes Desc: not available URL: From rcritten at redhat.com Wed Aug 6 12:43:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2014 08:43:57 -0400 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <53E1DFD2.60307@redhat.com> References: <53E1DFD2.60307@redhat.com> Message-ID: <53E2230D.6090908@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patch fixes . > + cert_group.add_option("--ca-key-algorithm", dest="ca_key_algorithm", + help="Key algorithm of the IPA CA certificate (default SHA256withRSA)") Why not set the default here rather than later? Should the list of options be added to the man page as well? Do we want to support the MD*-based signing algorithms? I'd think not. Seeing the context makes me wonder if we should eventually add options for CA key size and signing alg as well. rob From mkosek at redhat.com Wed Aug 6 14:26:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Aug 2014 16:26:22 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <53E2230D.6090908@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> Message-ID: <53E23B0E.8080802@redhat.com> On 08/06/2014 02:43 PM, Rob Crittenden wrote: ... > Seeing the context makes me wonder if we should eventually add options > for CA key size and signing alg as well. > > rob Good idea if it would be just a simple change. In a long run, PKI team plans to implement something better to craft the CSR, check Christina Fu's response in https://bugzilla.redhat.com/show_bug.cgi?id=790924#c12 Martin From pviktori at redhat.com Wed Aug 6 14:36:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Aug 2014 16:36:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0631-0632 Integration tests for backup & restore Message-ID: <53E23D75.2040005@redhat.com> Hello, These patches add integration tests for backup & restore. I'm also attaching a patch for the job definitions at https://github.com/encukou/freeipa-ci -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ci--Add-job-for-the-backup-restore-integration-test.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0631-Add-basic-test-for-backup-restore.patch Type: text/x-patch Size: 4528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0632-Add-test-for-backup-delete-system-users-restore.patch Type: text/x-patch Size: 4415 bytes Desc: not available URL: From pviktori at redhat.com Wed Aug 6 14:52:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 06 Aug 2014 16:52:11 +0200 Subject: [Freeipa-devel] [PATCHES] 0631-0632 Integration tests for backup & restore In-Reply-To: <53E23D75.2040005@redhat.com> References: <53E23D75.2040005@redhat.com> Message-ID: <53E2411B.2010301@redhat.com> On 08/06/2014 04:36 PM, Petr Viktorin wrote: > Hello, > These patches add integration tests for backup & restore. They depend on my earlier backup/restore patches, 0624-0627. > I'm also attaching a patch for the job definitions at > https://github.com/encukou/freeipa-ci I hit Send too soon, sorry for that -- Petr? From jcholast at redhat.com Wed Aug 6 16:17:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 Aug 2014 18:17:42 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <53E2230D.6090908@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> Message-ID: <53E25526.4080109@redhat.com> Dne 6.8.2014 v 14:43 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> > > > + cert_group.add_option("--ca-key-algorithm", dest="ca_key_algorithm", > + help="Key algorithm of the IPA CA certificate > (default SHA256withRSA)") > > Why not set the default here rather than later? CA-related defaults should be internalized in CA-related code IMHO. > > Should the list of options be added to the man page as well? Sure, why not. > > Do we want to support the MD*-based signing algorithms? I'd think not. Since the reason this patch exists is to support old and/or broken external CAs, I would think yes, but I don't have a strong opinion on this. > > Seeing the context makes me wonder if we should eventually add options > for CA key size and signing alg as well. > > rob > -- Jan Cholasta From pspacek at redhat.com Wed Aug 6 16:54:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 Aug 2014 18:54:19 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1406900071.19681.9.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> <53D76E12.9090002@redhat.com> <1406894095.19681.8.camel@willson.usersys.redhat.com> <53DB8888.80902@redhat.com> <1406900071.19681.9.camel@willson.usersys.redhat.com> Message-ID: <53E25DBB.6070501@redhat.com> On 1.8.2014 15:34, Simo Sorce wrote: > On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote: >> >Dne 1.8.2014 v 13:54 Simo Sorce napsal(a): >>> > >I have a questions about algorithms agility though, are we tied to use >>> > >AES128 and RSA2048 ? Or do we have the means to specify and use >>> > >alternative algorithms should it be necessary ? >>> > >(Like EC instead of RSA ?) >> > >> >The schema allows different key types and wrapping algorithms to be used >> >in the future. To be more specific: Keys are stored in LDAP in formats described on: http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data I.e. algorithm OID, (optional) algorithm parameters and key data are stored as DER-encoded SubjectPublicKeyInfo / DER-encoded EncryptedPrivateKeyInfo / DER-encoded IPAEncryptedSecretKeyInfo blobs. Our proprietary "IPAEncryptedSecretKeyInfo" structure is going to be the same thing as EncryptedPrivateKeyInfo, just the algorithm OID will specify some symmetric algorithm. At the moment, there is no configuration in LDAP which says which algorithm and parameters to use for wrapping/creating blobs. We are going to hard code this for now into IPA daemons/tools. The implicit assumption here is that later versions of IPA will add configuration attributes as necessary. The point is that decryption should 'just work' because all the metadata are in LDAP so even old replicas will know which algorithms and parameters to use for key unwrapping. (This assumes that new algorithms are supported by libraries etc.) > Excellent > >>> > > >>> > >Also would you know where I can find details on how >>> > >CKM_AES_KEY_WRAP[_PAD] is actually implemented ? >> > >> >CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394, >> >CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649. I have written RFC 5649 implementation for OpenSSL. You can see the code on https://github.com/openssl/openssl/commit/d31fed73e25391cd71a0de488d88724db78f6f8a More eyes on this code are more than welcome! :-) >> >We don't >> >use CKM_AES_KEY_WRAP ATM. I have to say that pure RFC 3394 is unusable for us. It works only on inputs with (length % 8) == 0. -- Petr^2 Spacek From alee at redhat.com Wed Aug 6 20:32:05 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 06 Aug 2014 16:32:05 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53C81F12.4020902@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> Message-ID: <1407357125.14215.7.camel@aleeredhat.laptop> Attached is a new patch. I believe I have addressed all the issues raided by pviktori, edewata and rcrit. Please let me know if I missed something! Incidentally, to get all this to work, you should use the latest Dogtag 10.2 build, which also contains a fix for pkidestroy that is not yet merged in. A COPR build is currently underway at: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/ Thanks, Ade On Thu, 2014-07-17 at 21:08 +0200, Petr Viktorin wrote: > On 07/16/2014 02:55 PM, Petr Viktorin wrote: > > On 07/14/2014 11:45 AM, Ade Lee wrote: > >> Hi all, > >> > >> I have rebased all the previous patches against master, and have > >> squashed them all into a single patch. > >> Its a large patch, but as many folks have already reviewed the > >> constituent precursor patches, most if it > >> should be familiar and easier to review. > > > > I think it would be nice to have the fixes that aren't related to DRM > > (e.g. style issues) separate, so the patch can be reverted easily. But, > > what's done is done. Thanks for the cleanup! > > > >> The main difference with what was specified before is that the DRM > >> database is installed as a subtree > >> to o=ipaca. This means that no new replication agreements will be > >> needed to replicate DRM data. > >> Replication agreements set up for the Dogtag CA will automatically > >> replicate DRM data. > >> > >> In order for this patch to work, a new 10.2 build of Dogtag 10.2 is > >> needed - with specific changes to > >> allow the ability to install a database as a subtree of an existing > >> tree. At this time, these > >> changes have not yet been checked into the dogtag source. You can > >> obtain such a build from: > >> > >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ > >> > >> Please review, > > > > > > I've started reading the code; here are my thoughts on the first part: > > > > In ipa-ca-install and ipa-replica-install, you only ever set > > "REPLICA_INFO_TOP_DIR" to None. In Python, "global" has module scope, > > it's not for the entire process. (And it's bad practice anyway.) > > You'll need to pass it around explicitly, perhaps store it in > > ReplicaConfig. > > > > It would be nice to use the admintool framework for the new script, > > instead of copying the old boilerplate code again. See e.g. > > ipa-server-certinstall for an example. > > > > Logging functions interpolate their arguments, so you should use e.g. > > root_logger.critical("failed to configure %s instance %s", > > subsystem, e) > > instead of using the % operator. > > Also, in e.g. > root_logger.debug( > 'Unable to determine PIN for the Dogtag instance: %s' % str(e)) > the "s" in "%s" means "convert to string", so explicit str() isn't > necessary. > > > installutils.create_replica_config: Any time you call sys.exit(), please > > log a message so we know why the log file ends. > > > > In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The > > information is available in api.env once api is finalized. > > > > In ipa-server-install, do we want to display the message about backing > > up /root/drmcert.p12 even if DRM is not installed? > > > > Please use path constants from ipaplatform.base.paths, or add new ones > > if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}. > > In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change > > that back to paths.NAMED_KEYTAB. > > Same in CAInstance.uninstall with "/usr/bin/pkiremove". > > > > In ipa-upgradeconfig.find_subject_base, the docstring should mention to > > DsInstance.find_subject_base's docstring rather than being a copy; we > > dont' want them getting out of sync. > > > > In DsInstance.find_subject_base, don't use a bare `except:`, at least do > > `except Exception:`, so you don't e.g. disable Ctrl+C. > > > > In CADSInstance.uninstall, you don't need the _running and _user_exists > > variables at all, just call the functions. > > Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode. > > Same in CAInstance.uninstall for _user_exists. > > > > In DogtagInstance, stop_tracking_certificates was moved here from > > cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR. > > Is that intended? > > > > In CAInstance.__init__, when calling DogtagInstance.__init__, consider > > using super, and naming the arguments for clarity: > > super(CAInstance, self).__init__( > > realm=realm, > > subsystem="CA", > > service_desc="certificate server", > > dogtag_constants=dogtag_constants, > > ) > Same in DogtagInstance, DRMInstance. > > > Since CAInstance inherits from DogtagInstance, the `enable`, > > `start_instance`, `stop_instance`, `http_proxy` methods that just call > > the superclass are unnecessary. > > IMO the comment from CAInstance.__enable was important, it should be in > > DogtagInstance.enable. > > > > In DogtagInstance.spawn_instance, it's not nice to modify lists the > > caller pased in. Take a copy of the nolog first. Ideally combine that > > with the conversion to tuple, and allow any sequence to be passed in: > > nolog_list = tuple(nolog_list) + (self.admin_password, > > self.dm_password) > > > > In CAInstance.__create_ca_user, it's better to use functions instead of > > staticmethods, unless you'll want to override them in subclasses (which > > you're explicitly discouraging here, by using the double underscore). > > Anyway I don't get why you want these to be staticmethods. > > > > dogtaginstance.py, drminstance.py: Avoid star imports, especially in new > code. AFAICS you're only using root_logger from ipapython.ipa_log_manager. > Also consider using an class-specific logger: > class DogtagInstance(...): > def __init__(...): > ... > self.log = ipa_log_manager.log_mgr.get_logger(self) > > later: > self.log.error("Unable to determine PIN for the Dogtag > instance:", e) > > About the "# noinspection PyBroadException" comments -- we already use > pylint, I don't think we want instructions for other linters in the code. > > In DogtagInstance.get_admin_cert: > admin_cert = entry_attrs.get('usercertificate')[0] > This relies on the order of values returned by LDAP. If the choice of > certificate doesn't matter here, leave a comment. > > drminstance.py: Please remove the `if __name__ == '__main__':` section > at the end. If this needs to be tested, provide a real test; if it's > example usage put it in the docs/docstring; if it's a personal tool just > keep it to yourself. > > In DRMInstance.__init__, the docstring is wrong; __init__ doesn't return > anything. > > In dogtag.py, this change breaks the formatting: > > - |staus |string |cert_request_status|unicode [1]_ | > > + |status |string |cert_request_status|unicode [1]_ | > > In drm.__init__, use `os.path.join(api.env.dot_ipa, 'alias')` instead of > joining manually. There are also hardcoded paths, put them in the > platform paths module. > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-1-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 155623 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 7 09:13:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Aug 2014 11:13:44 +0200 Subject: [Freeipa-devel] [PATCH] 481 ipa-adtrust-install does not re-add member in adtrust agents In-Reply-To: <20140801145358.GI3492@redhat.com> References: <53DBA7F6.3020203@redhat.com> <20140801145358.GI3492@redhat.com> Message-ID: <53E34348.4070200@redhat.com> On 08/01/2014 04:53 PM, Alexander Bokovoy wrote: > On Fri, 01 Aug 2014, Martin Kosek wrote: >> When a CIFS service exists and adtrust agents group does not >> have it as a member attribute (for whatever reason), re-running >> ipa-adtrust-install does not fix the inconsistency. >> >> Make the installer more robust by being able to fix the inconsistency. >> >> https://fedorahosted.org/freeipa/ticket/4464 >> > ACK. > Pushed to: master: 7caed6ecfb17050796c11fa9718aa8fb1464655d ipa-4-1: 7caed6ecfb17050796c11fa9718aa8fb1464655d ipa-4-0: 24f71476422503467bf09cdd1277ae0c0ea0adb4 -- Petr? From pviktori at redhat.com Thu Aug 7 10:54:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Aug 2014 12:54:31 +0200 Subject: [Freeipa-devel] [PATCH 0244] ipatests: test_trust: Add test to cover lookup of trusdomains In-Reply-To: <53C7B225.1020204@redhat.com> References: <53C7B181.7080801@redhat.com> <53C7B225.1020204@redhat.com> Message-ID: <53E35AE7.9020000@redhat.com> On 07/17/2014 01:23 PM, Tomas Babej wrote: > On 07/17/2014 01:20 PM, Tomas Babej wrote: >> Hi, >> >> Adds an integration tests that checks that all trustdomains are >> able to be found by trustdomain-find command right after the >> trust has been established. >> >> Also moves some code to allow easier adding common test cases for >> both POSIX and non-POSIX test classes. >> >> https://fedorahosted.org/freeipa/ticket/4208 Works here. ACK, pushed to: master: 6bb4eea348f9c90351987e20a49bbaca265291f4 ipa-4-1: 6bb4eea348f9c90351987e20a49bbaca265291f4 ipa-4-0: c9d4974267c6df6e16723686248db988d77abb8b > Also, attached is a required patch for freeipa-ci. > Pushed to https://github.com/encukou/freeipa-ci as b8c7db10a9396acacb75e1ab9e6a180f788ea2aa -- Petr? From mbasti at redhat.com Thu Aug 7 12:33:33 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 Aug 2014 14:33:33 +0200 Subject: [Freeipa-devel] [PATCH 0101, 106] Tests: host plugin (Allow to add host if AAAA record exists) In-Reply-To: <53D63E07.4060400@redhat.com> References: <53BD6DD4.8060903@redhat.com> <53D63E07.4060400@redhat.com> Message-ID: <53E3721D.6050005@redhat.com> On 28/07/14 14:11, Petr Viktorin wrote: > On 07/09/2014 06:29 PM, Martin Basti wrote: >> Patch attached. >> Ticket: https://fedorahosted.org/freeipa/ticket/4164 >> > > Looks & works fine for me. > Can you also add a test for this? > > Tests attached. I also added tests with --ip-address parameter. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0106-Tests-host-tests-with-dns.patch Type: text/x-patch Size: 17744 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 7 13:10:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Aug 2014 15:10:18 +0200 Subject: [Freeipa-devel] [PATCH] 312 Fix parsing of long nicknames in certutil -L output In-Reply-To: <53DF52C9.2030707@redhat.com> References: <53DF52C9.2030707@redhat.com> Message-ID: <53E37ABA.7000006@redhat.com> On 08/04/2014 11:30 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza This fixes the issue for me, ACK, pushed to: master: 6bb240fa2cf6ce257376241d0a779ca5cc96078e ipa-4-1: 6bb240fa2cf6ce257376241d0a779ca5cc96078e It would be nice if you could also add a test. -- Petr? From pviktori at redhat.com Thu Aug 7 14:27:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Aug 2014 16:27:02 +0200 Subject: [Freeipa-devel] [PATCH 0101, 106] Tests: host plugin (Allow to add host if AAAA record exists) In-Reply-To: <53E3721D.6050005@redhat.com> References: <53BD6DD4.8060903@redhat.com> <53D63E07.4060400@redhat.com> <53E3721D.6050005@redhat.com> Message-ID: <53E38CB6.9020403@redhat.com> On 08/07/2014 02:33 PM, Martin Basti wrote: > On 28/07/14 14:11, Petr Viktorin wrote: >> On 07/09/2014 06:29 PM, Martin Basti wrote: >>> Patch attached. >>> Ticket: https://fedorahosted.org/freeipa/ticket/4164 >>> >> >> Looks & works fine for me. >> Can you also add a test for this? >> >> > Tests attached. > I also added tests with --ip-address parameter. > This works, thanks! I have some comments however: Variables like `name5` can have more descriptive names, so that you can look at the test definition and actually know what's being tested. Some of the tests are independent (both in the sense that they don't need the other tests to be run, and that they test a different thing than the others); those can be in separate classes. There are better things to do in IPA than making the tests perfect, so ACK if you want to push this as is. -- Petr? From mbasti at redhat.com Thu Aug 7 15:05:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 Aug 2014 17:05:03 +0200 Subject: [Freeipa-devel] [PATCH 0101, 106] Tests: host plugin (Allow to add host if AAAA record exists) In-Reply-To: <53E38CB6.9020403@redhat.com> References: <53BD6DD4.8060903@redhat.com> <53D63E07.4060400@redhat.com> <53E3721D.6050005@redhat.com> <53E38CB6.9020403@redhat.com> Message-ID: <53E3959F.4080209@redhat.com> On 07/08/14 16:27, Petr Viktorin wrote: > On 08/07/2014 02:33 PM, Martin Basti wrote: >> On 28/07/14 14:11, Petr Viktorin wrote: >>> On 07/09/2014 06:29 PM, Martin Basti wrote: >>>> Patch attached. >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4164 >>>> >>> >>> Looks & works fine for me. >>> Can you also add a test for this? >>> >>> >> Tests attached. >> I also added tests with --ip-address parameter. >> > > This works, thanks! > I have some comments however: > > Variables like `name5` can have more descriptive names, so that you > can look at the test definition and actually know what's being tested. > > Some of the tests are independent (both in the sense that they don't > need the other tests to be run, and that they test a different thing > than the others); those can be in separate classes. > > > There are better things to do in IPA than making the tests perfect, so > ACK if you want to push this as is. > Please wait, I will fix the names then, it'll be fast. -- Martin Basti From mbasti at redhat.com Thu Aug 7 15:40:37 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 Aug 2014 17:40:37 +0200 Subject: [Freeipa-devel] [PATCH 0101, 106] Tests: host plugin (Allow to add host if AAAA record exists) In-Reply-To: <53E3959F.4080209@redhat.com> References: <53BD6DD4.8060903@redhat.com> <53D63E07.4060400@redhat.com> <53E3721D.6050005@redhat.com> <53E38CB6.9020403@redhat.com> <53E3959F.4080209@redhat.com> Message-ID: <53E39DF5.2070002@redhat.com> On 07/08/14 17:05, Martin Basti wrote: > On 07/08/14 16:27, Petr Viktorin wrote: >> On 08/07/2014 02:33 PM, Martin Basti wrote: >>> On 28/07/14 14:11, Petr Viktorin wrote: >>>> On 07/09/2014 06:29 PM, Martin Basti wrote: >>>>> Patch attached. >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4164 >>>>> >>>> >>>> Looks & works fine for me. >>>> Can you also add a test for this? >>>> >>>> >>> Tests attached. >>> I also added tests with --ip-address parameter. >>> >> >> This works, thanks! >> I have some comments however: >> >> Variables like `name5` can have more descriptive names, so that you >> can look at the test definition and actually know what's being tested. >> >> Some of the tests are independent (both in the sense that they don't >> need the other tests to be run, and that they test a different thing >> than the others); those can be in separate classes. >> >> >> There are better things to do in IPA than making the tests perfect, >> so ACK if you want to push this as is. >> > Please wait, I will fix the names then, it'll be fast. > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0106.2-Tests-host-tests-with-dns.patch Type: text/x-patch Size: 19243 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 7 15:46:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 07 Aug 2014 17:46:06 +0200 Subject: [Freeipa-devel] [PATCH] Make CA-less ipa-server-install option --root-ca-file optional In-Reply-To: <53E1DC6B.5030003@redhat.com> References: <53E09611.3030903@redhat.com> <53E1DC6B.5030003@redhat.com> Message-ID: <53E39F3E.3000007@redhat.com> On 08/06/2014 09:42 AM, Jan Cholasta wrote: > Dne 5.8.2014 v 10:30 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch fixes the code part of >> . Works for me, thanks! > Also the patch depends on my patch 295, which is already available in > ipa-4-1 and master. Attaching the current version of the patch. >> The next step is to review and update CA-less articles in our wiki. The next step should be adding integration tests for this, otherwise it will break in a few months. -- Petr? From pspacek at redhat.com Thu Aug 7 16:21:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 07 Aug 2014 18:21:40 +0200 Subject: [Freeipa-devel] Ipsilon vs. FedOAuth In-Reply-To: <53CF7CDE.5070509@redhat.com> References: <53CF7CDE.5070509@redhat.com> Message-ID: <53E3A794.7050800@redhat.com> On 23.7.2014 11:14, Petr Spacek wrote: > Hello list, > > I have noticed that Fedora is heavily using project FedOAuth: > > Federated Open Authentication > "FedOAuth is a provider for federated authentication mechanisms with a modular > authentication backend." > > It sounds somewhat similar to our Ipsilon project and it is also written in > Python. > > Maybe it would be beneficial to somehow cooperate ... There is silence like in a grave so I have tried to contact FedOAuth people in https://github.com/FedOAuth/FedOAuth/issues/61 And I have got a reply! " > It seems that FedOAuth and Ipsilon projects are somehow similar. Maybe it would be beneficial to cooperate and possibly share some code. [...] Hi, this would certainly be interesting. I've got SAML, OpenID, OpenID Connect and Persona providers currently, and for backends I currently have the Fedora Account System, a preconfigured user, LDAP, kerberos and a database-backed module. What was your exact idea for collaboration? " https://github.com/FedOAuth/FedOAuth/issues/61#issuecomment-50056634 From this text, it seems that FedOAuth is light years away (more mature) than Ipsilon - and FedOAuth is actually used in production now (by Fedora infrastructure). So the inevitable questions are: - What can Ipsilon do and what can't be done with FedOAuth? - Can we simply add missing features to FedOAuth? I.e. - Is it worth to spend more time on Ipsilon? Sorry Simo, this is not a meant as personal attack! :-) -- Petr^2 Spacek From simo at redhat.com Thu Aug 7 16:47:43 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2014 12:47:43 -0400 Subject: [Freeipa-devel] Ipsilon vs. FedOAuth In-Reply-To: <53E3A794.7050800@redhat.com> References: <53CF7CDE.5070509@redhat.com> <53E3A794.7050800@redhat.com> Message-ID: <1407430063.28399.7.camel@willson.usersys.redhat.com> On Thu, 2014-08-07 at 18:21 +0200, Petr Spacek wrote: > On 23.7.2014 11:14, Petr Spacek wrote: > > Hello list, > > > > I have noticed that Fedora is heavily using project FedOAuth: > > > > Federated Open Authentication > > "FedOAuth is a provider for federated authentication mechanisms with a modular > > authentication backend." > > > > It sounds somewhat similar to our Ipsilon project and it is also written in > > Python. > > > > Maybe it would be beneficial to somehow cooperate ... > > There is silence like in a grave so I have tried to contact FedOAuth people in > https://github.com/FedOAuth/FedOAuth/issues/61 > > And I have got a reply! > > " > > It seems that FedOAuth and Ipsilon projects are somehow similar. Maybe it > would be beneficial to cooperate and possibly share some code. > [...] > > Hi, this would certainly be interesting. > I've got SAML, OpenID, OpenID Connect and Persona providers currently, and for > backends I currently have the Fedora Account System, a preconfigured user, > LDAP, kerberos and a database-backed module. > What was your exact idea for collaboration? > " > https://github.com/FedOAuth/FedOAuth/issues/61#issuecomment-50056634 > > From this text, it seems that FedOAuth is light years away (more mature) than > Ipsilon - and FedOAuth is actually used in production now (by Fedora > infrastructure). > > > So the inevitable questions are: > - What can Ipsilon do and what can't be done with FedOAuth? > - Can we simply add missing features to FedOAuth? > I.e. > - Is it worth to spend more time on Ipsilon? > > Sorry Simo, this is not a meant as personal attack! :-) Oh I do not take it personally at all, I will take a look and see how much overlap there is. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Fri Aug 8 07:24:41 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 08 Aug 2014 09:24:41 +0200 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins Message-ID: <53E47B39.8020302@redhat.com> Hi, The attached patch is a first patch related to 'User Life Cycle' (https://fedorahosted.org/freeipa/ticket/3813) It creates 'Stage' and 'Delete' containers and configure DS plugin to scope only 'Active' container or exclude 'Stage'/'Delete' Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0001-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch Type: text/x-patch Size: 6416 bytes Desc: not available URL: From jcholast at redhat.com Fri Aug 8 08:55:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 08 Aug 2014 10:55:18 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn Message-ID: <53E49076.9010100@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-315-Convert-external-CA-chain-to-PKCS-7-before-passing-i.patch Type: text/x-patch Size: 1693 bytes Desc: not available URL: From mkosek at redhat.com Fri Aug 8 09:20:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Aug 2014 11:20:17 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn In-Reply-To: <53E49076.9010100@redhat.com> References: <53E49076.9010100@redhat.com> Message-ID: <53E49651.1000206@redhat.com> On 08/08/2014 10:55 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Thanks! I did not test, just have couple questions/suggestions: 1) Are we testing that the certificate is in proper format, e.g. is not PKCS7 already? We need to error out properly then 2) Are ipa-server-install --help options as informative as possible? --external-ca installation is tricky, we need to make sure that is no doubt about what the input is. 3) We may want to add instructions how to convert PKCS#7 -> PEM to "man ipa-server-install" too. Martin From jcholast at redhat.com Fri Aug 8 09:50:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 08 Aug 2014 11:50:51 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn In-Reply-To: <53E49651.1000206@redhat.com> References: <53E49076.9010100@redhat.com> <53E49651.1000206@redhat.com> Message-ID: <53E49D7B.7060207@redhat.com> Dne 8.8.2014 v 11:20 Martin Kosek napsal(a): > On 08/08/2014 10:55 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Thanks! I did not test, just have couple questions/suggestions: > > 1) Are we testing that the certificate is in proper format, e.g. is not PKCS7 > already? We need to error out properly then Yes, in ipa-server-install. > > 2) Are ipa-server-install --help options as informative as possible? > --external-ca installation is tricky, we need to make sure that is no doubt > about what the input is. I amended them a little bit. > > 3) We may want to add instructions how to convert PKCS#7 -> PEM to "man > ipa-server-install" too. Added. > > Martin > Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-315.1-Convert-external-CA-chain-to-PKCS-7-before-passing-i.patch Type: text/x-patch Size: 4320 bytes Desc: not available URL: From tbordaz at redhat.com Fri Aug 8 10:15:55 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 08 Aug 2014 12:15:55 +0200 Subject: [Freeipa-devel] [PATCH] 0002 User Life Cycle: Exclude subtree for ipaUniqueID generation Message-ID: <53E4A35B.5010405@redhat.com> Hi, The attached patch is the second patch related to 'User Life Cycle' (https://fedorahosted.org/freeipa/ticket/3813) It allows to prevent IPA UUID DS plugin to generate ipaUniqueID for 'Stage' users (http://www.freeipa.org/page/V4/User_Life-Cycle_Management#IPA_UUID_plugin) Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0002-User-Life-Cycle-Exclude-tree-ipaUniqueID-generation.patch Type: text/x-patch Size: 2660 bytes Desc: not available URL: From tbordaz at redhat.com Fri Aug 8 13:54:54 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 08 Aug 2014 15:54:54 +0200 Subject: [Freeipa-devel] [PATCH] 0003 User life cycle: new stageuser plugin with add verb Message-ID: <53E4D6AE.6050505@redhat.com> Hi, The attached patch is related to 'User Life Cycle' (https://fedorahosted.org/freeipa/ticket/3813) It creates a stageuser plugin with a first function stageuser-add. Stage user entries are provisioned under 'cn=staged users,cn=accounts,cn=provisioning,SUFFIX'. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0003-User-life-cycle-new-stageuser-plugin.patch Type: text/x-patch Size: 42540 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 8 23:36:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Aug 2014 19:36:24 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1407357125.14215.7.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> Message-ID: <53E55EF8.5060902@redhat.com> Ade Lee wrote: > Attached is a new patch. I believe I have addressed all the issues > raided by pviktori, edewata and rcrit. > > Please let me know if I missed something! > > Incidentally, to get all this to work, you should use the latest Dogtag > 10.2 build, which also contains a fix for pkidestroy that is not yet > merged in. A COPR build is currently underway at: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/ Some whitespace issues: Applying: Add a DRM to IPA /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing whitespace. This relies on the DRM client to generate a wrapping key /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line at EOF. + warning: 2 lines add whitespace errors. lying: Add a DRM to IPA /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing whitespace. This relies on the DRM client to generate a wrapping key /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line at EOF. + warning: 2 lines add whitespace errors. I do hope you're planning on adding a minimum build dep at some point? Still seeing AVCs during install: ---- time->Fri Aug 8 19:13:35 2014 type=SYSCALL msg=audit(1407539615.743:1503): arch=c000003e syscall=1 success=no exit=-13 a0=3 a1=210cb30 a2=2d a3=7fff1caa83f0 items=0 ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 key=(null) type=AVC msg=audit(1407539615.743:1503): avc: denied { setfscreate } for pid=12307 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process ---- time->Fri Aug 8 19:13:35 2014 type=SYSCALL msg=audit(1407539615.743:1504): arch=c000003e syscall=190 success=no exit=-13 a0=4 a1=7fff1caa8590 a2=210c8f0 a3=2d items=0 ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 key=(null) type=AVC msg=audit(1407539615.743:1504): avc: denied { relabelfrom } for pid=12307 comm="cp" name="CS.cfg.bak.20140808191335" dev="dm-0" ino=430828 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file ---- time->Fri Aug 8 19:13:35 2014 type=SYSCALL msg=audit(1407539615.744:1505): arch=c000003e syscall=88 success=no exit=-13 a0=7fffd3c0daa7 a1=7fffd3c0daea a2=0 a3=7fffd3c0b9b0 items=0 ppid=12121 pid=12308 auid=4294967295 uid=994 gid=993 euid=994 suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="ln" exe="/usr/bin/ln" subj=system_u:system_r:pki_tomcat_t:s0 key=(null) type=AVC msg=audit(1407539615.744:1505): avc: denied { create } for pid=12308 comm="ln" name="CS.cfg.bak" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file The new estimated time was dead on :-) There was a fairly long wait after "Done configuring DRM server (pki-tomcatd)." and the install was done. I thought we always displayed text when restarting (e.g. handled by the service wrapper) but I guess not. It would be nice to know what is going on. Re-running ipa-drm-install results in a scary error: ]# ipa-drm-install Usage: ipa-drm-install [options] [replica_file] ipa-drm-install: error: DRM is already installed. Your system may be partly configured. Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. And now onto the code... class drm _create_pem_file isnt' exactly descriptive and there is no method documentation. _setup. Just a nit: do you want to hardcode the port? I think I'd prefer it come via the constructor and default to 443. It may be worth beefing up the return value docs ala what John did in the dogtag section. I notice, for example, you always return a tuple and one value as None in store_secret. I assume there is a reason for that but it isn't obvious. This happens elsewhere too. Should the copyright dates on existing files be changed? I don't think they should be, but I'm hardly an expert. I just did a cursory look-see in the code and things generally looked ok. I'm hoping Petr^3 will take a closer look. rob From redhatrises at gmail.com Sat Aug 9 02:44:40 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 8 Aug 2014 20:44:40 -0600 Subject: [Freeipa-devel] [PATCH 0027-0031][DOC] Chapter 1 and 2 updates to documentation Message-ID: Hello, I have a few updates to Chapters 1 and 2 for the documentation. I also have a patch to add CA-less install example. Chapter 1 updates: - Patch 0027 removes leading and trailing whitespace and fixes tab indentation. - Patch 0028 adds SSSD section and updates NTP, DNS, and replica sections Chapter 2 updates: - Patch 0029 removes leading and trailing whitespace and fixes tab indentation. - Patch 0030 update DNS instructions, installation options/examples, prerequisites, replica information, etc. - Patch 0031 updates the CA section and adds CA-less install example. All patches would be need to be applied in order listed. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0027-Fix-Chapter-1-formatting.patch Type: text/x-patch Size: 30511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0028-DOC-Various-Chapter-1-updates.patch Type: text/x-patch Size: 9663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0029-DOC-Fix-Chapter-2-formatting.patch Type: text/x-patch Size: 79847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0030-DOC-Various-Chapter-2-updates.patch Type: text/x-patch Size: 85478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0031-DOC-Update-Chapter-2-CA-section.patch Type: text/x-patch Size: 16920 bytes Desc: not available URL: From pspacek at redhat.com Mon Aug 11 07:44:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 Aug 2014 09:44:14 +0200 Subject: [Freeipa-devel] [PATCH 0030][DOC] Chapter 1 and 2 updates to documentation In-Reply-To: References: Message-ID: <53E8744E.5080501@redhat.com> Hello, I did proof-reading of patch 0030. It seems that you have canibalized RHEL docs which is a bit unfortunate, they are not entirely correct. RHEL docs are being review and fixed right now so it would be better to wait until RHEL guide is fixed. On 9.8.2014 04:44, Gabe Alford wrote: > - Patch 0030 update DNS instructions, installation options/examples, > prerequisites, replica information, etc. I started to read the patch and found following: > + NOTE > > - It is recommended that a separate DNS domain be allocated for the &IPA; server. While not required (clients from other domains can still be enrolled in the &IPA; domain), this is a convenience for overall DNS management. > - > - > - > - TIP > + If the &IPA; server is configured to host its own DNS server, the &IPA; DNS service processes all DNS queries. The &IPA; DNS records take precedence, and any previous existing DNS configuration is ignored. > + > + > + All systems within the domain must be configured to use the &IPA;-managed DNS server. > + > + > + This is incorrect (and really important). This text should say that if IdM is a DNS server then there has to be correct delegation from parent domain to IdM servers. I.e. if IdM domain is ipa.example.com. is has to be delegated properly from example.com. domain. This follows normal rules for DNS, nothing special. > + IMPORTANT > + > + This must be a valid DNS name, which means only numbers, alphabetic characters, underscores(_), and hyphens (-) are allowed. Other characters in the hostname will cause DNS failures. > + > + Underscore is not allowed. (Even if it is technically possible docs shouldn't encourage people to do that.) > + > + > + The A and PTR records do not need to match the &IPA; server. > + > + The A and PTR records do not need to match for the server. Forward DNS record (A, AAAA) need to match. > -[root at server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPT > +[root at server ~]# firewalld -A INPUT -p tcp --dport 389 -j ACCEPT This is wrong. One cannot just replace "iptables" command with "firewalld" and hope it works. I would rather skip this command at all and just point to firewalld man page. And so on and so on. At this point I have realized that the same mistakes are in RHEL docs so it would be better to drop the patch and wait until RHEL docs are fixed. In future, please use IP address ranges reserved for documentation: IPv6: http://tools.ietf.org/html/rfc3849 IPv4: http://tools.ietf.org/html/rfc5737 It prevents people from screwing real networks when doing copy&paste. (This concern is well based. Copy&paste mistakes in the past caused huge routing problems on public Internet.) Thank you for understanding - and have a nice day! -- Petr^2 Spacek From redhatrises at gmail.com Mon Aug 11 13:28:26 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 11 Aug 2014 07:28:26 -0600 Subject: [Freeipa-devel] [PATCH 0030][DOC] Chapter 1 and 2 updates to documentation In-Reply-To: <53E8744E.5080501@redhat.com> References: <53E8744E.5080501@redhat.com> Message-ID: Thanks, Petr. What is the project's preference here as far as (if they were correct) having documentation flow from RHEL to the Fedora docs? It seems to me that really the upstream should be Freeipa Docs that flows into RHEL docs (with mods for RH needs)? On Mon, Aug 11, 2014 at 1:44 AM, Petr Spacek wrote: > Hello, > > I did proof-reading of patch 0030. It seems that you have canibalized RHEL > docs which is a bit unfortunate, they are not entirely correct. > > RHEL docs are being review and fixed right now so it would be better to > wait until RHEL guide is fixed. > > > On 9.8.2014 04:44, Gabe Alford wrote: > >> - Patch 0030 update DNS instructions, installation options/examples, >> prerequisites, replica information, etc. >> > > I started to read the patch and found following: > > + NOTE >> >> - It is recommended >> that a separate DNS domain be allocated for the &IPA; server. While not >> required (clients from other domains can still be enrolled in the &IPA; >> domain), this is a convenience for overall DNS management. >> - >> - >> - >> - TIP >> + If the &IPA; server is >> configured to host its own DNS server, the &IPA; DNS service processes all >> DNS queries. The &IPA; DNS records take precedence, and any previous >> existing DNS configuration is ignored. >> + >> + >> + All systems within the >> domain must be configured to use the &IPA;-managed DNS server. >> + >> + >> + >> > > This is incorrect (and really important). This text should say that if IdM > is a DNS server then there has to be correct delegation from parent domain > to IdM servers. > > I.e. if IdM domain is ipa.example.com. is has to be delegated properly > from example.com. domain. This follows normal rules for DNS, nothing > special. > > > + >> IMPORTANT >> + >> + >> This must be a valid DNS name, which means only numbers, alphabetic >> characters, underscores(_), and hyphens (-) are allowed. Other characters >> in the hostname will cause DNS failures. >> + >> + >> > Underscore is not allowed. (Even if it is technically possible docs > shouldn't encourage people to do that.) > > > + >> + >> + The A and >> PTR records do not need to match the &IPA; server. >> + >> + >> > The A and PTR records do not need to match for the server. Forward DNS > record (A, AAAA) need to match. > > -[root at server ~]# iptables -A INPUT -p tcp --dport 389 -j >> ACCEPT >> +[root at server ~]# firewalld -A INPUT -p tcp --dport 389 -j >> ACCEPT >> > > This is wrong. One cannot just replace "iptables" command with "firewalld" > and hope it works. I would rather skip this command at all and just point > to firewalld man page. > > And so on and so on. > > At this point I have realized that the same mistakes are in RHEL docs so > it would be better to drop the patch and wait until RHEL docs are fixed. > > In future, please use IP address ranges reserved for documentation: > IPv6: http://tools.ietf.org/html/rfc3849 > IPv4: http://tools.ietf.org/html/rfc5737 > > It prevents people from screwing real networks when doing copy&paste. > (This concern is well based. Copy&paste mistakes in the past caused huge > routing problems on public Internet.) > > Thank you for understanding - and have a nice day! > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Aug 11 14:03:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 11 Aug 2014 16:03:18 +0200 Subject: [Freeipa-devel] [PATCH 0101, 106] Tests: host plugin (Allow to add host if AAAA record exists) In-Reply-To: <53E39DF5.2070002@redhat.com> References: <53BD6DD4.8060903@redhat.com> <53D63E07.4060400@redhat.com> <53E3721D.6050005@redhat.com> <53E38CB6.9020403@redhat.com> <53E3959F.4080209@redhat.com> <53E39DF5.2070002@redhat.com> Message-ID: <53E8CD26.1050909@redhat.com> On 08/07/2014 05:40 PM, Martin Basti wrote: > On 07/08/14 17:05, Martin Basti wrote: >> On 07/08/14 16:27, Petr Viktorin wrote: >>> On 08/07/2014 02:33 PM, Martin Basti wrote: >>>> On 28/07/14 14:11, Petr Viktorin wrote: >>>>> On 07/09/2014 06:29 PM, Martin Basti wrote: >>>>>> Patch attached. >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4164 >>>>>> >>>>> >>>>> Looks & works fine for me. >>>>> Can you also add a test for this? >>>>> >>>>> >>>> Tests attached. >>>> I also added tests with --ip-address parameter. >>>> >>> >>> This works, thanks! >>> I have some comments however: >>> >>> Variables like `name5` can have more descriptive names, so that you >>> can look at the test definition and actually know what's being tested. >>> >>> Some of the tests are independent (both in the sense that they don't >>> need the other tests to be run, and that they test a different thing >>> than the others); those can be in separate classes. >>> >>> >>> There are better things to do in IPA than making the tests perfect, >>> so ACK if you want to push this as is. >>> >> Please wait, I will fix the names then, it'll be fast. >> > Updated patch attached. > ACK, pushed to: master: 4b5a4882497ce7c3ecdf8f898fc695b2309df1b5 ipa-4-1: 4b5a4882497ce7c3ecdf8f898fc695b2309df1b5 ipa-4-0: 2fa1555722ed875a32d3480ea08c5ad420a015a6 -- Petr? From pviktori at redhat.com Mon Aug 11 14:54:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 11 Aug 2014 16:54:36 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53E55EF8.5060902@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> Message-ID: <53E8D92C.1080803@redhat.com> On 08/09/2014 01:36 AM, Rob Crittenden wrote: > Ade Lee wrote: >> Attached is a new patch. I believe I have addressed all the issues >> raided by pviktori, edewata and rcrit. Arrrrr! >> Please let me know if I missed something! >> >> Incidentally, to get all this to work, you should use the latest Dogtag >> 10.2 build, which also contains a fix for pkidestroy that is not yet >> merged in. A COPR build is currently underway at: >> >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/ > > Some whitespace issues: > > Applying: Add a DRM to IPA > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > whitespace. > This relies on the DRM client to generate a wrapping key > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > at EOF. > + > warning: 2 lines add whitespace errors. > lying: Add a DRM to IPA > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > whitespace. > This relies on the DRM client to generate a wrapping key > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > at EOF. > + > warning: 2 lines add whitespace errors. > > I do hope you're planning on adding a minimum build dep at some point? > > Still seeing AVCs during install: > > ---- > time->Fri Aug 8 19:13:35 2014 > type=SYSCALL msg=audit(1407539615.743:1503): arch=c000003e syscall=1 > success=no exit=-13 a0=3 a1=210cb30 a2=2d a3=7fff1caa83f0 items=0 > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > key=(null) > type=AVC msg=audit(1407539615.743:1503): avc: denied { setfscreate } > for pid=12307 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 > tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process > ---- > time->Fri Aug 8 19:13:35 2014 > type=SYSCALL msg=audit(1407539615.743:1504): arch=c000003e syscall=190 > success=no exit=-13 a0=4 a1=7fff1caa8590 a2=210c8f0 a3=2d items=0 > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > key=(null) > type=AVC msg=audit(1407539615.743:1504): avc: denied { relabelfrom } > for pid=12307 comm="cp" name="CS.cfg.bak.20140808191335" dev="dm-0" > ino=430828 scontext=system_u:system_r:pki_tomcat_t:s0 > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file > ---- > time->Fri Aug 8 19:13:35 2014 > type=SYSCALL msg=audit(1407539615.744:1505): arch=c000003e syscall=88 > success=no exit=-13 a0=7fffd3c0daa7 a1=7fffd3c0daea a2=0 a3=7fffd3c0b9b0 > items=0 ppid=12121 pid=12308 auid=4294967295 uid=994 gid=993 euid=994 > suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > comm="ln" exe="/usr/bin/ln" subj=system_u:system_r:pki_tomcat_t:s0 > key=(null) > type=AVC msg=audit(1407539615.744:1505): avc: denied { create } for > pid=12308 comm="ln" name="CS.cfg.bak" > scontext=system_u:system_r:pki_tomcat_t:s0 > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file > > The new estimated time was dead on :-) > > There was a fairly long wait after "Done configuring DRM server > (pki-tomcatd)." and the install was done. I thought we always displayed > text when restarting (e.g. handled by the service wrapper) but I guess > not. It would be nice to know what is going on. > > Re-running ipa-drm-install results in a scary error: > > ]# ipa-drm-install > Usage: ipa-drm-install [options] [replica_file] > > ipa-drm-install: error: DRM is already installed. > > Your system may be partly configured. > Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. Right, you don't want to override handle_error here. Instead, wrap the body of run() in try: .... except: self.log.error(self.FAIL_MESSAGE) raise (Yes, bare `except` and bare `raise`) I used self.log.error() instead of print, because I think at least the "Your system may be partly configured." part of the FAIL_MESSAGE should end up in the log, not just on screen. > And now onto the code... > > class drm > > _create_pem_file isnt' exactly descriptive and there is no method > documentation. > > _setup. Just a nit: do you want to hardcode the port? I think I'd prefer > it come via the constructor and default to 443. > > It may be worth beefing up the return value docs ala what John did in > the dogtag section. I notice, for example, you always return a tuple and > one value as None in store_secret. I assume there is a reason for that > but it isn't obvious. This happens elsewhere too. > > Should the copyright dates on existing files be changed? I don't think > they should be, but I'm hardly an expert. > > I just did a cursory look-see in the code and things generally looked > ok. I'm hoping Petr^3 will take a closer look. > > rob > I also see a scary error I can't make heads or tails of when trying to install DRM on a replica: $ sudo ipa-drm-install Your system may be partly configured. Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /ca/rest/securityDomain/domainInfo (Caused by : [Errno 111] Connection refused) pviktori at vm-234:~/freeipa{master}e819ca8?$ The traceback is: ipa.ipaserver.install.ipa_drm_install.DRMInstaller: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_drm_install.py", line 180, in validate_options self.installing_replica = dogtaginstance.is_installing_replica("KRA") File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 82, in is_installing_replica info = get_security_domain() File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 71, in get_security_domain info = domain_client.get_security_domain_info() File "/usr/lib/python2.7/site-packages/pki/system.py", line 95, in get_security_domain_info response = self.connection.get('/rest/securityDomain/domainInfo') File "/usr/lib/python2.7/site-packages/pki/client.py", line 60, in get data=payload) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 347, in get return self.request('GET', url, **kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 335, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 438, in send r = adapter.send(request, **kwargs) File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 327, in send raise ConnectionError(e) Perhaps I'm doing something wrong here? Regarding the code I just have a bunch of nitpicks: There are some more logger calls that use `%` for interpolation: - ipa-ca-install.install_replica - ipaserver.install.installutils.check_entropy There are some more hardcoded paths. We've just moved these to the platform module recently, and the move wasn't totally thorough, so these are not entirely your fault. Still, they should be fixed: ipaserver.install.cainstance.CAInstance.stop_tracking_agent_certificate (/etc/httpd/alias) ipaserver.install.dogtaginstance.HTTPD_CONFD (later when you use it, use os.path.join() instead of adding strings) ipaserver.install.ipa_replica_prepare.ReplicaPrepare.copy_misc_files (/etc/ipa/default.conf) ipaserver.install.cainstance.CAInstance.uninstall: "-pki_instance_root=/var/lib" (not touched directly by your change but it would be nice to fix) ipaserver.install.drminstance.DRMInstance.__spawn_instance: "/var/lib/pki/pki-tomcat/alias/kra_backup_keys.p12", "/root/kracert.p12", "/tmp" ipa-server-install, summary message: "/root/cacert.p12", "/root/drmcert.p12" ipaserver.install.dogtaginstance.DogtagInstance.ADMIN_CERT_PATH ipaserver.install.dogtaginstance.check_inst: '/usr/share/pki/%s/conf/server.xml' (note, constants for template paths have a _TEMPLATE suffix by convention) ipaserver.install.dogtaginstance.DogtagInstance.spawn_instance: "/usr/sbin/pkispawn" ipaserver.install.dogtaginstance.DogtagInstance.uninstall: "/usr/sbin/pkidestroy" ipa_drm_install.DRMInstaller.FAIL_MESSAGE: Just use `ipa-drm-install` as the command; the Python module you mention is not executable. ipaserver.install.installutils.check_entropy: "/proc/sys/kernel/random/entropy_avail" CAInstance.__init__, DRMInstance.__init__: These docstrings are unnecessary. ipa_drm_install.DRMInstall.__init__ just calls the superclass, so it's not necessary to override it. In ipa_drm_install.DRMInstall.add_options, when adding --uninstall, don't give the empty string (see --no-host-dns). For ipa_drm_install.DRMInstaller's INSTALLER_START_MESSAGE and FAIL_MESSAGE, you can use textwrap.dedent() for nicer indentation: https://docs.python.org/2/library/textwrap.html#textwrap.dedent In ipa_drm_install.DRMInstaller.__init__, AFAICS setting "installing_replica" and "replica_file" is not needed, and the values are misleading until validate_options sets the the correct values. In ipa_drm_install.DRMInstaller.validate_options: Instead of `ra_plugin is not None and ra_plugin == "dogtag"` you can use just `ra_plugin == "dogtag"`. Same with `if dogtag_version is not None and dogtag_version >= 10:` (you explicitly convert the value to int earlier, so it can't be None here). Instead of `if len(self.args) < 1:` just use `if not self.args:`. The tool should also error out if more than one replica file is given, or if file(s) are given for non-replica master or for uninstalling. The commit message is slightly wrong; ipa-drm-install does not ask for a replica file when it's needed and not given. And, please link to the ticket and design page in the commit message. -- Petr? From edewata at redhat.com Tue Aug 12 15:57:40 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Aug 2014 10:57:40 -0500 Subject: [Freeipa-devel] [PATCH] 718 webui: better error reporting In-Reply-To: <53E0BDDB.3060501@redhat.com> References: <53E0BDDB.3060501@redhat.com> Message-ID: <53EA3974.9030502@redhat.com> On 8/5/2014 6:19 AM, Petr Vobornik wrote: > On page: > - styled to use proper line breaks > - "centered" by .container class and not by huge padding > > Console: > - proper line breaks > - links in stack trace are clickable(Chrome) ACK. -- Endi S. Dewata From edewata at redhat.com Tue Aug 12 15:58:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Aug 2014 10:58:21 -0500 Subject: [Freeipa-devel] [PATCH] 719 webui-ci: fix table widget add In-Reply-To: <53E0BE08.7010406@redhat.com> References: <53E0BE08.7010406@redhat.com> Message-ID: <53EA399D.9080106@redhat.com> On 8/5/2014 6:20 AM, Petr Vobornik wrote: > add_table_record call used old selector for add button which > caused 3 fails in CI: > - ERROR: Test automember rebuild membership feature for hosts > - ERROR: Test automember rebuild membership feature for users > - ERROR: Basic CRUD: dns > > related to: > https://fedorahosted.org/freeipa/ticket/4258 ACK. -- Endi S. Dewata From edewata at redhat.com Tue Aug 12 15:59:04 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Aug 2014 10:59:04 -0500 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <53E0C08A.9000406@redhat.com> References: <53E0C08A.9000406@redhat.com> Message-ID: <53EA39C8.5020304@redhat.com> On 8/5/2014 6:31 AM, Petr Vobornik wrote: > patches 725-728 are preparation for 729 but they can also affect the > rest of UI (intentional). 728 is useful for non-admins. We might want > to discuss enabling of `hide_empty_widgets` flag in patch 727. > > ticket: https://fedorahosted.org/freeipa/ticket/4402 > > [PATCH] 720 webui: add measurement unit to token time step field ACK. > [PATCH] 721 webui: better otp token type label ACK. > [PATCH] 722 webui: add token from user page > > Add 'Add OTP Token' action to user action menu. > > This option is disabled in self-service when viewing other users. ACK, but I'm just wondering if it would be more intuitive to define an enabled condition (you're an admin or editing your own user) rather than a disabled condition (you're in self-service mode but editing other user). > [PATCH] 723 webui: add i18n for the rest of QR code strings ACK. > [PATCH] 724 webui: display fields based on otp token type > > - in adder dialog > > > [PATCH] 725 webui: better value-change reporting > > - widget save() save method should try to always return value even if > read only > - report value-change event with actual value to allow processing of > the value ACK. > [PATCH] 726 webui: widget initialization > > - used `ctor_init` instead of `init` to avoid name collision with > existing logic > - `ctor_init` is called right after widget instantiation. Basically > support > better inheritance for the old class system which doesn't have proper > contructors ACK. > [PATCH] 727 webui: hide empty fields and sections > > Hide widgets without a value. Must be explicitly turned on. In widget by > `hidden_if_empty` flag. Or globally by `hide_empty_widgets` flag. Global > hiding can be individually turned off by `ignore_empty_hiding` flag. In item #2 of ticket #4402 I was originally thinking the widget visibility would be determined by the token type. Any plan to add the token type field in the future? Will the "counter" field strictly have a value with HOTP only and "clock offset & interval" fields strictly have value with TOTP only? Do these fields contain the configured values or the effective values? I was just thinking maybe in the future some of these fields might be configured empty and they will use the default values instead. If that's not a problem then ACK. > [PATCH] 728 webui: hide non-readable fields > > hide widgets if associated field had received attribute level rights > without 'r' right. > > Explicit rights are required to avoid hiding of special widgets which > are not associated with any LDAP attribute. ACK. > [PATCH] 729 webui: hide otp fields based on token type > > - uses hide empty feature Assuming patch #727 is fine then it's ACKed too. Some other comments/questions: 1. The "Validity start/end" fields don't show the date/time format. When you type the first letter then it will show the validation message with the format. It's not a big deal, but it's not very intuitive because people might not know what letter to type in the first place. Usually the field label should indicate the format/unit and the validation message will only appear if the value entered doesn't match the format/unit. 2. The "Digits" field by itself sounds a bit weird. How about "Number of digits", or "OTP length" and add the unit in the value (e.g. 6 digits)? 3. The "Clock offset" field doesn't have a unit. 4. If no "Owner" is specified when adding a token, it will default to admin. Is this the intended behavior? -- Endi S. Dewata From edewata at redhat.com Tue Aug 12 20:58:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Aug 2014 15:58:02 -0500 Subject: [Freeipa-devel] [PATCH] 730-732 webui: Login pages usability improvements In-Reply-To: <53E0C1BC.7070404@redhat.com> References: <53E0C1BC.7070404@redhat.com> Message-ID: <53EA7FDA.5020906@redhat.com> On 8/5/2014 6:36 AM, Petr Vobornik wrote: > [PATCH] 730 webui: display expired session notification in a more visible > area > > The notification is a primary information of the page. It should be > more highlighted. > > https://fedorahosted.org/freeipa/ticket/4470 ACK. > [PATCH] 731 webui: improved info msgs on login/token sync/reset pwd > pages > > - add info icons to distinguish and classify the messages. > - add info text for OTP fields > - fix login instruction inaccuracy related to position of login button > > https://fedorahosted.org/freeipa/ticket/4470 Just one thing, instead of "enter them in the fields nearby" how about "enter them in the corresponding fields"? Otherwise it's ACKed. > [PATCH] 732 webui: login screen - improved button switching > > - added cancel button to reset password view of login screen > - re-implemented buttons hiding mechanism > - switching between 'Reset Password' and 'Reset Password and Login' > according to presence of value in OTP field > > https://fedorahosted.org/freeipa/ticket/4470 The code seems to be fine so it's ACKed, but see comments below: 1. It looks like the OTP token needs to be synchronized before it can be used for the first time. Is that true for all types of tokens (hardware/software, TOTP/HOTP)? If possible the synchronization should be part of the token creation process, so the admin can provide a token that can be used right away, so we may need an interface in the UI to sync the tokens. If the sync can only be done by users themselves, there should be a message on the login screen for first time OTP users to synchronize the token first. 2. Try logging in with an incorrect password/OTP. After you get a login error click Sync OTP Token. Once the sync is completed it will go back to the login page with a "Token was synchronized" message that disappears in a few seconds, but the old login error still appears which is confusing. Error messages in the UI should only reflect the last executed operation. -- Endi S. Dewata From pviktori at redhat.com Wed Aug 13 13:12:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 13 Aug 2014 15:12:17 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn In-Reply-To: <53E49D7B.7060207@redhat.com> References: <53E49076.9010100@redhat.com> <53E49651.1000206@redhat.com> <53E49D7B.7060207@redhat.com> Message-ID: <53EB6431.7050004@redhat.com> On 08/08/2014 11:50 AM, Jan Cholasta wrote: > Dne 8.8.2014 v 11:20 Martin Kosek napsal(a): >> On 08/08/2014 10:55 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Thanks! I did not test, just have couple questions/suggestions: >> >> 1) Are we testing that the certificate is in proper format, e.g. is >> not PKCS7 >> already? We need to error out properly then > > Yes, in ipa-server-install. > >> >> 2) Are ipa-server-install --help options as informative as possible? >> --external-ca installation is tricky, we need to make sure that is no >> doubt >> about what the input is. > > I amended them a little bit. > >> >> 3) We may want to add instructions how to convert PKCS#7 -> PEM to "man >> ipa-server-install" too. > > Added. > >> >> Martin >> > > Updated patch attached. > Hello, This works for me, but I'm not sure if I'm correctly reproducing the specific scenario this patch fixes. So as always, can you please add tests for code you write? As far as other scenarios, it seems to me that when I do something wrong I get a very unhelpful error message late in the installation. I tried signing the request using xca but pkispawn choked on the result; I'll try to write a reproducer script using command-line tools. Attached is a script (based on the external ca integration test) that reproduces the same IndexError as mentioned in the ticket. (If necessary, adjust the IP addresses, hostnames, etc. to fit your environment.) The difference from a working script is that extensions aren't added to the IPA cert when it's signed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: index-error-reproducer.sh Type: application/x-shellscript Size: 2844 bytes Desc: not available URL: From mkosek at redhat.com Wed Aug 13 13:57:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Aug 2014 15:57:01 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn In-Reply-To: <53EB6431.7050004@redhat.com> References: <53E49076.9010100@redhat.com> <53E49651.1000206@redhat.com> <53E49D7B.7060207@redhat.com> <53EB6431.7050004@redhat.com> Message-ID: <53EB6EAD.8070307@redhat.com> On 08/13/2014 03:12 PM, Petr Viktorin wrote: > On 08/08/2014 11:50 AM, Jan Cholasta wrote: >> Dne 8.8.2014 v 11:20 Martin Kosek napsal(a): >>> On 08/08/2014 10:55 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes . >>>> >>>> Honza >>> >>> Thanks! I did not test, just have couple questions/suggestions: >>> >>> 1) Are we testing that the certificate is in proper format, e.g. is >>> not PKCS7 >>> already? We need to error out properly then >> >> Yes, in ipa-server-install. >> >>> >>> 2) Are ipa-server-install --help options as informative as possible? >>> --external-ca installation is tricky, we need to make sure that is no >>> doubt >>> about what the input is. >> >> I amended them a little bit. >> >>> >>> 3) We may want to add instructions how to convert PKCS#7 -> PEM to "man >>> ipa-server-install" too. >> >> Added. >> >>> >>> Martin >>> >> >> Updated patch attached. >> > > Hello, > This works for me, but I'm not sure if I'm correctly reproducing the specific > scenario this patch fixes. So as always, can you please add tests for code you > write? +1! > As far as other scenarios, it seems to me that when I do something wrong I get > a very unhelpful error message late in the installation. > > I tried signing the request using xca but pkispawn choked on the result; I'll > try to write a reproducer script using command-line tools. > > Attached is a script (based on the external ca integration test) that > reproduces the same IndexError as mentioned in the ticket. (If necessary, > adjust the IP addresses, hostnames, etc. to fit your environment.) > The difference from a working script is that extensions aren't added to the IPA > cert when it's signed. This is a very good finding. If Jan's patch fixes the reported problem, let us push it. But the missing validation should be fixed too. Can you please extend https://fedorahosted.org/freeipa/ticket/4480 that is (will be) planned for 4.1 and attach your script as well so that we can improve the usability by both accepting more certificate types and validation? Martin From edewata at redhat.com Wed Aug 13 14:17:41 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Aug 2014 09:17:41 -0500 Subject: [Freeipa-devel] [PATCH] 733-735 webui: Better description for User authentication types In-Reply-To: <53E0C23D.2000109@redhat.com> References: <53E0C23D.2000109@redhat.com> Message-ID: <53EB7385.8030108@redhat.com> On 8/5/2014 6:38 AM, Petr Vobornik wrote: > [PATCH] 733 webui: rename tooltip to title > > - use title for input's elements 'title' attribute > - tooltip for Bootstrap's tooltip component > > https://fedorahosted.org/freeipa/ticket/4471 ACK. > [PATCH] 734 webui: tooltip support > > Allow to set 'tooltip' attribute in spec. It displays info icon > with Bootstrap's tooltip near field's label. > > https://fedorahosted.org/freeipa/ticket/4471 ACK. > [PATCH] 735 webui: better authentication types description > > Tooltips were added to "User authentication types" and "Default user > objectclasses" to describe their relationship and a meaning of > not-setting a value. > > https://fedorahosted.org/freeipa/ticket/4471 Just one thing, in the patch comment you probably meant "Default user authentication types". ACK. -- Endi S. Dewata From pviktori at redhat.com Wed Aug 13 14:48:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 13 Aug 2014 16:48:10 +0200 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53E47B39.8020302@redhat.com> References: <53E47B39.8020302@redhat.com> Message-ID: <53EB7AAA.2070802@redhat.com> On 08/08/2014 09:24 AM, thierry bordaz wrote: > Hi, > > The attached patch is a first patch related to 'User Life Cycle' > (https://fedorahosted.org/freeipa/ticket/3813) > > It creates 'Stage' and 'Delete' containers and configure DS plugin to > scope only 'Active' container or exclude 'Stage'/'Delete' Hello, The .ldif files are copied only during initial installation. When upgrading to a version with this patch, changes in .ldif files are not applied. So all updates need to be in .update files. For example, for DNA plugin configuration you would need something like this in an .update file: dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config remove:dnaScope: "$SUFFIX" add:dnaScope: "cn=accounts,$SUFFIX" .update files, on the other hand, are applied both on installation and on upgrade. To avoid duplication you can put whole entries in .update and delete them from the .ldif, provided the entries always end up being created in a correct order. Patch submission technicalities: Please don't add the "Reviewed by" tag to the commit message, it's added when pushing. The other tags are not used FreeIPA. (What's a "Flag Day"?) When you send more patches that depend on each other, either attach them all to one e-mail, or explicitly say what each patch depends on. -- Petr? From rmeggins at redhat.com Wed Aug 13 15:11:43 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 13 Aug 2014 09:11:43 -0600 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53EB7AAA.2070802@redhat.com> References: <53E47B39.8020302@redhat.com> <53EB7AAA.2070802@redhat.com> Message-ID: <53EB802F.1090407@redhat.com> On 08/13/2014 08:48 AM, Petr Viktorin wrote: > On 08/08/2014 09:24 AM, thierry bordaz wrote: >> Hi, >> >> The attached patch is a first patch related to 'User Life Cycle' >> (https://fedorahosted.org/freeipa/ticket/3813) >> >> It creates 'Stage' and 'Delete' containers and configure DS plugin to >> scope only 'Active' container or exclude 'Stage'/'Delete' > > Hello, > > The .ldif files are copied only during initial installation. When > upgrading to a version with this patch, changes in .ldif files are not > applied. > > So all updates need to be in .update files. For example, for DNA > plugin configuration you would need something like this in an .update > file: > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > remove:dnaScope: "$SUFFIX" > add:dnaScope: "cn=accounts,$SUFFIX" > > > .update files, on the other hand, are applied both on installation and > on upgrade. To avoid duplication you can put whole entries in .update > and delete them from the .ldif, provided the entries always end up > being created in a correct order. > > > Patch submission technicalities: > Please don't add the "Reviewed by" tag to the commit message, it's > added when pushing. The other tags are not used FreeIPA. (What's a > "Flag Day"?) Flag Day is a warning to other developers - "Hey, this change will break something in your usual workflow, plan accordingly" > When you send more patches that depend on each other, either attach > them all to one e-mail, or explicitly say what each patch depends on. > From tbordaz at redhat.com Wed Aug 13 15:17:14 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 13 Aug 2014 17:17:14 +0200 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53EB7AAA.2070802@redhat.com> References: <53E47B39.8020302@redhat.com> <53EB7AAA.2070802@redhat.com> Message-ID: <53EB817A.3070805@redhat.com> On 08/13/2014 04:48 PM, Petr Viktorin wrote: > On 08/08/2014 09:24 AM, thierry bordaz wrote: >> Hi, >> >> The attached patch is a first patch related to 'User Life Cycle' >> (https://fedorahosted.org/freeipa/ticket/3813) >> >> It creates 'Stage' and 'Delete' containers and configure DS plugin to >> scope only 'Active' container or exclude 'Stage'/'Delete' > > Hello, > > The .ldif files are copied only during initial installation. When > upgrading to a version with this patch, changes in .ldif files are not > applied. > > So all updates need to be in .update files. For example, for DNA > plugin configuration you would need something like this in an .update > file: > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > remove:dnaScope: "$SUFFIX" > add:dnaScope: "cn=accounts,$SUFFIX" > > > .update files, on the other hand, are applied both on installation and > on upgrade. To avoid duplication you can put whole entries in .update > and delete them from the .ldif, provided the entries always end up > being created in a correct order. Hello Petr, Thanks you very much for your review. I understand that the fix does not work in upgrade and I will change it following your recommendation. I think that adding entries with the .update syntax should be similar to what is in 55-pbacmemberof.update for example. > > > Patch submission technicalities: > Please don't add the "Reviewed by" tag to the commit message, it's > added when pushing. The other tags are not used FreeIPA. (What's a > "Flag Day"?) > When you send more patches that depend on each other, either attach > them all to one e-mail, or explicitly say what each patch depends on. > That is correct I used a review template that was for 389-ds and I will change it. 'Flag Day' was part of 389-DS template, it was a flag to inform if the fix had a wide impact (things needing to be ported/recompile). I split ULC fix into several logical sub fixes and you are right they are all related even if for example 0002 does not depend on 0001. Do you want I resend patch 0003 with the statement it relies on 0001 (and with the correct commit message ?). thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Aug 13 15:20:46 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Aug 2014 10:20:46 -0500 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53E0C346.1050700@redhat.com> References: <53E0C346.1050700@redhat.com> Message-ID: <53EB824E.6030001@redhat.com> On 8/5/2014 6:43 AM, Petr Vobornik wrote: > [PATCH] 736 webui: convert widget.less indentation to spaces ACK. > [PATCH] 737 webui: improve rule table css > > - category radio line has line-height large enough to contain > undo button -> content doesn't move several pixels on change > - remove vertical padding from btns in table headers to maintain > about the same height > - remove invisible border from link buttons to have the same height > for disabled and enabled button ACK. > [PATCH] 738 webui: sshkey widget - usability fixes > > - save one click by opening edit dialog right after adding new row > - add margin between fingerprint and "show/edit" button > - fix honoring of writable/read-only flags upon row creation ACK. Possible improvements: 1. How about removing the row if the user cancels the addition or enters blank value? That way the rows will always have values, so we don't need the "New: key set/not set" labels anymore. 2. Can the UI parse the new key and display it the same way as other keys that are already saved? That will make it more seamless. 3. If we do #2, the "Show/Set key" button probably can be changed to Edit or Modify. > [PATCH] 739 webui: disable batch action buttons by default > > action buttons associated with batch actions were enabled by default, > but they were disabled right after facet creation and a load of data. > It caused a visual flicker. > > UX is enhanced by making them disabled by default. ACK. > [PATCH] 740 webui: fix group type padding ACK. -- Endi S. Dewata From edewata at redhat.com Wed Aug 13 15:26:43 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Aug 2014 10:26:43 -0500 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app In-Reply-To: <53E0F417.8050204@redhat.com> References: <53E0F417.8050204@redhat.com> Message-ID: <53EB83B3.704@redhat.com> On 8/5/2014 10:11 AM, Petr Vobornik wrote: > - display info message which points user to FreeOTP project page > - the link or the text can be easily changed by a plugin if needed > > https://fedorahosted.org/freeipa/ticket/4469 > > Notes: > - the design can be a subject of discussion. > - the FreeOTP project page [1] is not very end-user friendly but > serves the purpose > - it's not fully configurable, as decided at today's meeting, but a > very simple plugin can hide or modify the message > > [1] https://fedorahosted.org/freeotp/ ACK. -- Endi S. Dewata From pviktori at redhat.com Wed Aug 13 15:34:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 13 Aug 2014 17:34:00 +0200 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53EB817A.3070805@redhat.com> References: <53E47B39.8020302@redhat.com> <53EB7AAA.2070802@redhat.com> <53EB817A.3070805@redhat.com> Message-ID: <53EB8568.5080305@redhat.com> On 08/13/2014 05:17 PM, thierry bordaz wrote: > On 08/13/2014 04:48 PM, Petr Viktorin wrote: >> On 08/08/2014 09:24 AM, thierry bordaz wrote: >>> Hi, >>> >>> The attached patch is a first patch related to 'User Life Cycle' >>> (https://fedorahosted.org/freeipa/ticket/3813) >>> >>> It creates 'Stage' and 'Delete' containers and configure DS plugin to >>> scope only 'Active' container or exclude 'Stage'/'Delete' >> >> Hello, >> >> The .ldif files are copied only during initial installation. When >> upgrading to a version with this patch, changes in .ldif files are not >> applied. >> >> So all updates need to be in .update files. For example, for DNA >> plugin configuration you would need something like this in an .update >> file: >> >> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >> Plugin,cn=plugins,cn=config >> remove:dnaScope: "$SUFFIX" >> add:dnaScope: "cn=accounts,$SUFFIX" >> >> >> .update files, on the other hand, are applied both on installation and >> on upgrade. To avoid duplication you can put whole entries in .update >> and delete them from the .ldif, provided the entries always end up >> being created in a correct order. > > Hello Petr, > > Thanks you very much for your review. I understand that the fix does > not work in upgrade and I will change it following your recommendation. > I think that adding entries with the .update syntax should be > similar to what is in 55-pbacmemberof.update for example. Yes. >> Patch submission technicalities: >> Please don't add the "Reviewed by" tag to the commit message, it's >> added when pushing. The other tags are not used FreeIPA. (What's a >> "Flag Day"?) >> When you send more patches that depend on each other, either attach >> them all to one e-mail, or explicitly say what each patch depends on. >> > That is correct I used a review template that was for 389-ds and I > will change it. 'Flag Day' was part of 389-DS template, it was a > flag to inform if the fix had a wide impact (things needing to be > ported/recompile). > I split ULC fix into several logical sub fixes and you are right > they are all related even if for example 0002 does not depend on 0001. > Do you want I resend patch 0003 with the statement it relies on 0001 > (and with the correct commit message ?). These guidelines just make it easier for us to handle the large numbers of patches that land on the list. Try to follow them next time you send a patch (or revision), but there's no need to resubmit things just to comply. We can change the message when pushing if the patch contents are acked. Thanks for the dependency information. -- Petr? From edewata at redhat.com Wed Aug 13 15:46:05 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Aug 2014 10:46:05 -0500 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html In-Reply-To: <53D77D41.2050400@redhat.com> References: <53CFCDD2.3000606@redhat.com> <53D2BDB5.5080109@redhat.com> <53D610AC.6020505@redhat.com> <53D683A5.7080606@redhat.com> <53D77D41.2050400@redhat.com> Message-ID: <53EB883D.4080704@redhat.com> On 7/29/2014 5:53 AM, Petr Vobornik wrote: > Just one thing, there is no pause between clicking the Reset button >>>> and the redirection, so the "Password reset was successful." >>>> confirmation message might only appear very briefly. A possible >>>> alternative is to show a confirmation page/message, but the user will >>>> have to click to continue to the next page. >>> >>> I don't believe there is a universal solution. I would say that it >>> depends on personal preferences and a use case. I.e., if it's part >>> of a >>> login procedure I would prefer immediate redirection back to login >>> page. >>> If it's invoked from a user action - just to change the password, some >>> delay might be good. >>> >>> We might add a URL param(s) to configure the delay/link. >> >> How about 2 URL params? >> 1. the link to the next page >> 2. an option whether to >> a) redirect to the link immediately >> b) show a confirmation page with the link >> >> Just my preference, but I don't really like a 'delay' on a web page. >> It's either too short or too long, and we can't put important info >> during the delay because there's no guarantee people will see it. >> > > Yes, how about this: > > 1. redirection=url_to_the_page > 2. in=x, where x is number of seconds or a string > > - redirect immediately if only `redirection` is supplied or `in=0` > - show "Continue to next page" link if `in` is present > - show count-down timer if `in` is > 1 with "You will be redirected in > `x`s" text. > - don't redirect if `in` is negative or NaN (your scenario), e.g.: > `in=no` up to user > - ignore `in` if `redirection` is not present > > Then we will support all described scenarios and the decision will be > on web-site admin. Feel free to propose better name for `in`. How about 'url/link' or 'next_url' for the first parameter and 'delay' for the second one? I think in this case 'delay' would describe its function better than 'in'. If delay=0 that means we're redirecting immediately. If delay parameter is not specified that means we're waiting for the user to click the link. -- Endi S. Dewata From alee at redhat.com Wed Aug 13 18:05:51 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 13 Aug 2014 14:05:51 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53E8D92C.1080803@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> Message-ID: <1407953151.6981.43.camel@aleeredhat.laptop> New patch attached which all the issues noted below. Rebased to master. Please review, Thanks, Ade On Mon, 2014-08-11 at 16:54 +0200, Petr Viktorin wrote: > On 08/09/2014 01:36 AM, Rob Crittenden wrote: > > Ade Lee wrote: > >> Attached is a new patch. I believe I have addressed all the issues > >> raided by pviktori, edewata and rcrit. > Arrrrr! > >> Please let me know if I missed something! > >> > >> Incidentally, to get all this to work, you should use the latest Dogtag > >> 10.2 build, which also contains a fix for pkidestroy that is not yet > >> merged in. A COPR build is currently underway at: > >> > >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/ > > > > Some whitespace issues: > > > > Applying: Add a DRM to IPA > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > > whitespace. > > This relies on the DRM client to generate a wrapping key > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > > at EOF. > > + > > warning: 2 lines add whitespace errors. > > lying: Add a DRM to IPA > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > > whitespace. > > This relies on the DRM client to generate a wrapping key > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > > at EOF. > > + > > warning: 2 lines add whitespace errors. > > fixed > > I do hope you're planning on adding a minimum build dep at some point? > > yes - as soon as we have an official-ish dogtag build. > > Still seeing AVCs during install: > > > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.743:1503): arch=c000003e syscall=1 > > success=no exit=-13 a0=3 a1=210cb30 a2=2d a3=7fff1caa83f0 items=0 > > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.743:1503): avc: denied { setfscreate } > > for pid=12307 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.743:1504): arch=c000003e syscall=190 > > success=no exit=-13 a0=4 a1=7fff1caa8590 a2=210c8f0 a3=2d items=0 > > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.743:1504): avc: denied { relabelfrom } > > for pid=12307 comm="cp" name="CS.cfg.bak.20140808191335" dev="dm-0" > > ino=430828 scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.744:1505): arch=c000003e syscall=88 > > success=no exit=-13 a0=7fffd3c0daa7 a1=7fffd3c0daea a2=0 a3=7fffd3c0b9b0 > > items=0 ppid=12121 pid=12308 auid=4294967295 uid=994 gid=993 euid=994 > > suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="ln" exe="/usr/bin/ln" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.744:1505): avc: denied { create } for > > pid=12308 comm="ln" name="CS.cfg.bak" > > scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file > > Rob, please open BZ against selinux-policy for these. Interestingly, audit2allow doesn't provide me with any output for these AVC's. > > The new estimated time was dead on :-) > > > > There was a fairly long wait after "Done configuring DRM server > > (pki-tomcatd)." and the install was done. I thought we always displayed > > text when restarting (e.g. handled by the service wrapper) but I guess > > not. It would be nice to know what is going on. > > done > > Re-running ipa-drm-install results in a scary error: > > > > ]# ipa-drm-install > > Usage: ipa-drm-install [options] [replica_file] > > > > ipa-drm-install: error: DRM is already installed. > > > > Your system may be partly configured. > > Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. > > Right, you don't want to override handle_error here. Instead, wrap the > body of run() in > > try: > .... > except: > self.log.error(self.FAIL_MESSAGE) > raise > > (Yes, bare `except` and bare `raise`) > > I used self.log.error() instead of print, because I think at least the > "Your system may be partly configured." part of the FAIL_MESSAGE should > end up in the log, not just on screen. > done > > And now onto the code... > > > > class drm > > > > _create_pem_file isnt' exactly descriptive and there is no method > > documentation. > > done > > _setup. Just a nit: do you want to hardcode the port? I think I'd prefer > > it come via the constructor and default to 443. > > done > > It may be worth beefing up the return value docs ala what John did in > > the dogtag section. I notice, for example, you always return a tuple and > > one value as None in store_secret. I assume there is a reason for that > > but it isn't obvious. This happens elsewhere too. > > done > > Should the copyright dates on existing files be changed? I don't think > > they should be, but I'm hardly an expert. > > > > I just did a cursory look-see in the code and things generally looked > > ok. I'm hoping Petr^3 will take a closer look. > > > > rob > > > > I also see a scary error I can't make heads or tails of when trying to > install DRM on a replica: > > $ sudo ipa-drm-install > > Your system may be partly configured. > Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. > > HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded > with url: /ca/rest/securityDomain/domainInfo (Caused by 'socket.error'>: [Errno 111] Connection refused) Do you have a replica CA installed? The replica is trying to reach the local replica CA install on localhost/ port 8080. Is port 8080 somehow blocked in your local machine? Can you get to http://localhost:8080/ca/rest/securityDomain/domainInfo ? > pviktori at vm-234:~/freeipa{master}e819ca8?$ > > The traceback is: > > ipa.ipaserver.install.ipa_drm_install.DRMInstaller: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in > execute > self.validate_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_drm_install.py", > line 180, in validate_options > self.installing_replica = dogtaginstance.is_installing_replica("KRA") > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 82, in is_installing_replica > info = get_security_domain() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 71, in get_security_domain > info = domain_client.get_security_domain_info() > File "/usr/lib/python2.7/site-packages/pki/system.py", line 95, in > get_security_domain_info > response = self.connection.get('/rest/securityDomain/domainInfo') > File "/usr/lib/python2.7/site-packages/pki/client.py", line 60, in get > data=payload) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 347, in get > return self.request('GET', url, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 335, in request > resp = self.send(prep, **send_kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 438, in send > r = adapter.send(request, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/adapters.py", line > 327, in send > raise ConnectionError(e) > > Perhaps I'm doing something wrong here? > > > Regarding the code I just have a bunch of nitpicks: > > There are some more logger calls that use `%` for interpolation: > - ipa-ca-install.install_replica done > - ipaserver.install.installutils.check_entropy > done > There are some more hardcoded paths. We've just moved these to the > platform module recently, and the move wasn't totally thorough, so these > are not entirely your fault. Still, they should be fixed: > ipaserver.install.cainstance.CAInstance.stop_tracking_agent_certificate > (/etc/httpd/alias) done > ipaserver.install.dogtaginstance.HTTPD_CONFD (later when you use it, use > os.path.join() instead of adding strings) done > ipaserver.install.ipa_replica_prepare.ReplicaPrepare.copy_misc_files > (/etc/ipa/default.conf) done > ipaserver.install.cainstance.CAInstance.uninstall: > "-pki_instance_root=/var/lib" (not touched directly by your change but > it would be nice to fix) done > ipaserver.install.drminstance.DRMInstance.__spawn_instance: > "/var/lib/pki/pki-tomcat/alias/kra_backup_keys.p12", > "/root/kracert.p12", "/tmp" done > ipa-server-install, summary message: "/root/cacert.p12", "/root/drmcert.p12" done > ipaserver.install.dogtaginstance.DogtagInstance.ADMIN_CERT_PATH done > ipaserver.install.dogtaginstance.check_inst: > '/usr/share/pki/%s/conf/server.xml' (note, constants for template paths > have a _TEMPLATE suffix by convention) done > ipaserver.install.dogtaginstance.DogtagInstance.spawn_instance: > "/usr/sbin/pkispawn" done > ipaserver.install.dogtaginstance.DogtagInstance.uninstall: > "/usr/sbin/pkidestroy" done > ipa_drm_install.DRMInstaller.FAIL_MESSAGE: Just use `ipa-drm-install` as > the command; the Python module you mention is not executable. done > ipaserver.install.installutils.check_entropy: > "/proc/sys/kernel/random/entropy_avail" > done > CAInstance.__init__, DRMInstance.__init__: These docstrings are unnecessary. done > ipa_drm_install.DRMInstall.__init__ just calls the superclass, so it's > not necessary to override it. done > In ipa_drm_install.DRMInstall.add_options, when adding --uninstall, > don't give the empty string (see --no-host-dns). > done > For ipa_drm_install.DRMInstaller's INSTALLER_START_MESSAGE and > FAIL_MESSAGE, you can use textwrap.dedent() for nicer indentation: > https://docs.python.org/2/library/textwrap.html#textwrap.dedent > done > In ipa_drm_install.DRMInstaller.__init__, AFAICS setting > "installing_replica" and "replica_file" is not needed, and the values > are misleading until validate_options sets the the correct values. > done > In ipa_drm_install.DRMInstaller.validate_options: > Instead of `ra_plugin is not None and ra_plugin == "dogtag"` you can use > just `ra_plugin == "dogtag"`. > Same with `if dogtag_version is not None and dogtag_version >= 10:` (you > explicitly convert the value to int earlier, so it can't be None here). > Instead of `if len(self.args) < 1:` just use `if not self.args:`. All done > The tool should also error out if more than one replica file is given, > or if file(s) are given for non-replica master or for uninstalling. > done. > The commit message is slightly wrong; ipa-drm-install does not ask for a > replica file when it's needed and not given. > And, please link to the ticket and design page in the commit message. > done -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-2-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 159241 bytes Desc: not available URL: From alee at redhat.com Wed Aug 13 19:54:21 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 13 Aug 2014 15:54:21 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1407953151.6981.43.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> Message-ID: <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. DRM was really only used in docs/marketing, whereas KRA is all over the code. Soon, the code and the marketing/docs will match. The following patch changes all references to the DRM to KRA. so for example, you need to run ipa-kra-install etc. Please apply this on top of the previous patch. I'll go ahead and squash them before commit. Thanks, Ade ----- Original Message ----- From: "Ade Lee" To: "Petr Viktorin" Cc: freeipa-devel at redhat.com Sent: Wednesday, August 13, 2014 2:05:51 PM Subject: Re: [Freeipa-devel] [PATCH] - Add DRM to IPA New patch attached which all the issues noted below. Rebased to master. Please review, Thanks, Ade On Mon, 2014-08-11 at 16:54 +0200, Petr Viktorin wrote: > On 08/09/2014 01:36 AM, Rob Crittenden wrote: > > Ade Lee wrote: > >> Attached is a new patch. I believe I have addressed all the issues > >> raided by pviktori, edewata and rcrit. > Arrrrr! > >> Please let me know if I missed something! > >> > >> Incidentally, to get all this to work, you should use the latest Dogtag > >> 10.2 build, which also contains a fix for pkidestroy that is not yet > >> merged in. A COPR build is currently underway at: > >> > >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/ > > > > Some whitespace issues: > > > > Applying: Add a DRM to IPA > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > > whitespace. > > This relies on the DRM client to generate a wrapping key > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > > at EOF. > > + > > warning: 2 lines add whitespace errors. > > lying: Add a DRM to IPA > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing > > whitespace. > > This relies on the DRM client to generate a wrapping key > > /home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line > > at EOF. > > + > > warning: 2 lines add whitespace errors. > > fixed > > I do hope you're planning on adding a minimum build dep at some point? > > yes - as soon as we have an official-ish dogtag build. > > Still seeing AVCs during install: > > > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.743:1503): arch=c000003e syscall=1 > > success=no exit=-13 a0=3 a1=210cb30 a2=2d a3=7fff1caa83f0 items=0 > > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.743:1503): avc: denied { setfscreate } > > for pid=12307 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.743:1504): arch=c000003e syscall=190 > > success=no exit=-13 a0=4 a1=7fff1caa8590 a2=210c8f0 a3=2d items=0 > > ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994 > > fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.743:1504): avc: denied { relabelfrom } > > for pid=12307 comm="cp" name="CS.cfg.bak.20140808191335" dev="dm-0" > > ino=430828 scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file > > ---- > > time->Fri Aug 8 19:13:35 2014 > > type=SYSCALL msg=audit(1407539615.744:1505): arch=c000003e syscall=88 > > success=no exit=-13 a0=7fffd3c0daa7 a1=7fffd3c0daea a2=0 a3=7fffd3c0b9b0 > > items=0 ppid=12121 pid=12308 auid=4294967295 uid=994 gid=993 euid=994 > > suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 > > comm="ln" exe="/usr/bin/ln" subj=system_u:system_r:pki_tomcat_t:s0 > > key=(null) > > type=AVC msg=audit(1407539615.744:1505): avc: denied { create } for > > pid=12308 comm="ln" name="CS.cfg.bak" > > scontext=system_u:system_r:pki_tomcat_t:s0 > > tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file > > Rob, please open BZ against selinux-policy for these. Interestingly, audit2allow doesn't provide me with any output for these AVC's. > > The new estimated time was dead on :-) > > > > There was a fairly long wait after "Done configuring DRM server > > (pki-tomcatd)." and the install was done. I thought we always displayed > > text when restarting (e.g. handled by the service wrapper) but I guess > > not. It would be nice to know what is going on. > > done > > Re-running ipa-drm-install results in a scary error: > > > > ]# ipa-drm-install > > Usage: ipa-drm-install [options] [replica_file] > > > > ipa-drm-install: error: DRM is already installed. > > > > Your system may be partly configured. > > Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. > > Right, you don't want to override handle_error here. Instead, wrap the > body of run() in > > try: > .... > except: > self.log.error(self.FAIL_MESSAGE) > raise > > (Yes, bare `except` and bare `raise`) > > I used self.log.error() instead of print, because I think at least the > "Your system may be partly configured." part of the FAIL_MESSAGE should > end up in the log, not just on screen. > done > > And now onto the code... > > > > class drm > > > > _create_pem_file isnt' exactly descriptive and there is no method > > documentation. > > done > > _setup. Just a nit: do you want to hardcode the port? I think I'd prefer > > it come via the constructor and default to 443. > > done > > It may be worth beefing up the return value docs ala what John did in > > the dogtag section. I notice, for example, you always return a tuple and > > one value as None in store_secret. I assume there is a reason for that > > but it isn't obvious. This happens elsewhere too. > > done > > Should the copyright dates on existing files be changed? I don't think > > they should be, but I'm hardly an expert. > > > > I just did a cursory look-see in the code and things generally looked > > ok. I'm hoping Petr^3 will take a closer look. > > > > rob > > > > I also see a scary error I can't make heads or tails of when trying to > install DRM on a replica: > > $ sudo ipa-drm-install > > Your system may be partly configured. > Run /usr/sbin/ipa_drm_install.py --uninstall to clean up. > > HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded > with url: /ca/rest/securityDomain/domainInfo (Caused by 'socket.error'>: [Errno 111] Connection refused) Do you have a replica CA installed? The replica is trying to reach the local replica CA install on localhost/ port 8080. Is port 8080 somehow blocked in your local machine? Can you get to http://localhost:8080/ca/rest/securityDomain/domainInfo ? > pviktori at vm-234:~/freeipa{master}e819ca8?$ > > The traceback is: > > ipa.ipaserver.install.ipa_drm_install.DRMInstaller: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in > execute > self.validate_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_drm_install.py", > line 180, in validate_options > self.installing_replica = dogtaginstance.is_installing_replica("KRA") > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 82, in is_installing_replica > info = get_security_domain() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 71, in get_security_domain > info = domain_client.get_security_domain_info() > File "/usr/lib/python2.7/site-packages/pki/system.py", line 95, in > get_security_domain_info > response = self.connection.get('/rest/securityDomain/domainInfo') > File "/usr/lib/python2.7/site-packages/pki/client.py", line 60, in get > data=payload) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 347, in get > return self.request('GET', url, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 335, in request > resp = self.send(prep, **send_kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line > 438, in send > r = adapter.send(request, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/adapters.py", line > 327, in send > raise ConnectionError(e) > > Perhaps I'm doing something wrong here? > > > Regarding the code I just have a bunch of nitpicks: > > There are some more logger calls that use `%` for interpolation: > - ipa-ca-install.install_replica done > - ipaserver.install.installutils.check_entropy > done > There are some more hardcoded paths. We've just moved these to the > platform module recently, and the move wasn't totally thorough, so these > are not entirely your fault. Still, they should be fixed: > ipaserver.install.cainstance.CAInstance.stop_tracking_agent_certificate > (/etc/httpd/alias) done > ipaserver.install.dogtaginstance.HTTPD_CONFD (later when you use it, use > os.path.join() instead of adding strings) done > ipaserver.install.ipa_replica_prepare.ReplicaPrepare.copy_misc_files > (/etc/ipa/default.conf) done > ipaserver.install.cainstance.CAInstance.uninstall: > "-pki_instance_root=/var/lib" (not touched directly by your change but > it would be nice to fix) done > ipaserver.install.drminstance.DRMInstance.__spawn_instance: > "/var/lib/pki/pki-tomcat/alias/kra_backup_keys.p12", > "/root/kracert.p12", "/tmp" done > ipa-server-install, summary message: "/root/cacert.p12", "/root/drmcert.p12" done > ipaserver.install.dogtaginstance.DogtagInstance.ADMIN_CERT_PATH done > ipaserver.install.dogtaginstance.check_inst: > '/usr/share/pki/%s/conf/server.xml' (note, constants for template paths > have a _TEMPLATE suffix by convention) done > ipaserver.install.dogtaginstance.DogtagInstance.spawn_instance: > "/usr/sbin/pkispawn" done > ipaserver.install.dogtaginstance.DogtagInstance.uninstall: > "/usr/sbin/pkidestroy" done > ipa_drm_install.DRMInstaller.FAIL_MESSAGE: Just use `ipa-drm-install` as > the command; the Python module you mention is not executable. done > ipaserver.install.installutils.check_entropy: > "/proc/sys/kernel/random/entropy_avail" > done > CAInstance.__init__, DRMInstance.__init__: These docstrings are unnecessary. done > ipa_drm_install.DRMInstall.__init__ just calls the superclass, so it's > not necessary to override it. done > In ipa_drm_install.DRMInstall.add_options, when adding --uninstall, > don't give the empty string (see --no-host-dns). > done > For ipa_drm_install.DRMInstaller's INSTALLER_START_MESSAGE and > FAIL_MESSAGE, you can use textwrap.dedent() for nicer indentation: > https://docs.python.org/2/library/textwrap.html#textwrap.dedent > done > In ipa_drm_install.DRMInstaller.__init__, AFAICS setting > "installing_replica" and "replica_file" is not needed, and the values > are misleading until validate_options sets the the correct values. > done > In ipa_drm_install.DRMInstaller.validate_options: > Instead of `ra_plugin is not None and ra_plugin == "dogtag"` you can use > just `ra_plugin == "dogtag"`. > Same with `if dogtag_version is not None and dogtag_version >= 10:` (you > explicitly convert the value to int earlier, so it can't be None here). > Instead of `if len(self.args) < 1:` just use `if not self.args:`. All done > The tool should also error out if more than one replica file is given, > or if file(s) are given for non-replica master or for uninstalling. > done. > The commit message is slightly wrong; ipa-drm-install does not ask for a > replica file when it's needed and not given. > And, please link to the ticket and design page in the commit message. > done _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Replace-DRM-with-KRA.patch Type: text/x-patch Size: 41293 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 14 08:09:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 14 Aug 2014 10:09:42 +0200 Subject: [Freeipa-devel] [PATCH] 315 Convert external CA chain to PKCS#7 before passing it to pkispawn In-Reply-To: <53EB6EAD.8070307@redhat.com> References: <53E49076.9010100@redhat.com> <53E49651.1000206@redhat.com> <53E49D7B.7060207@redhat.com> <53EB6431.7050004@redhat.com> <53EB6EAD.8070307@redhat.com> Message-ID: <53EC6EC6.8040900@redhat.com> On 08/13/2014 03:57 PM, Martin Kosek wrote: > On 08/13/2014 03:12 PM, Petr Viktorin wrote: [...] >> This works for me, but I'm not sure if I'm correctly reproducing the specific >> scenario this patch fixes. So as always, can you please add tests for code you >> write? > > +1! > >> As far as other scenarios, it seems to me that when I do something wrong I get >> a very unhelpful error message late in the installation. >> >> I tried signing the request using xca but pkispawn choked on the result; I'll >> try to write a reproducer script using command-line tools. >> >> Attached is a script (based on the external ca integration test) that >> reproduces the same IndexError as mentioned in the ticket. (If necessary, >> adjust the IP addresses, hostnames, etc. to fit your environment.) >> The difference from a working script is that extensions aren't added to the IPA >> cert when it's signed. > > This is a very good finding. If Jan's patch fixes the reported problem, let us > push it. Pushed to: master: 359dfe58b94079e1e16f4fb8960eb29b251f2cbc ipa-4-1: 359dfe58b94079e1e16f4fb8960eb29b251f2cbc ipa-4-0: 7c03ef0e727ca44ce1228e9896079a1d02227e14 > But the missing validation should be fixed too. Can you please extend > https://fedorahosted.org/freeipa/ticket/4480 > that is (will be) planned for 4.1 and attach your script as well so that we can > improve the usability by both accepting more certificate types and validation? Comment added. -- Petr? From mkosek at redhat.com Thu Aug 14 08:24:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Aug 2014 10:24:48 +0200 Subject: [Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53EB8568.5080305@redhat.com> References: <53E47B39.8020302@redhat.com> <53EB7AAA.2070802@redhat.com> <53EB817A.3070805@redhat.com> <53EB8568.5080305@redhat.com> Message-ID: <53EC7250.7040703@redhat.com> On 08/13/2014 05:34 PM, Petr Viktorin wrote: > On 08/13/2014 05:17 PM, thierry bordaz wrote: ... >>> Patch submission technicalities: >>> Please don't add the "Reviewed by" tag to the commit message, it's >>> added when pushing. The other tags are not used FreeIPA. (What's a >>> "Flag Day"?) >>> When you send more patches that depend on each other, either attach >>> them all to one e-mail, or explicitly say what each patch depends on. >>> >> That is correct I used a review template that was for 389-ds and I >> will change it. 'Flag Day' was part of 389-DS template, it was a >> flag to inform if the fix had a wide impact (things needing to be >> ported/recompile). >> I split ULC fix into several logical sub fixes and you are right >> they are all related even if for example 0002 does not depend on 0001. >> Do you want I resend patch 0003 with the statement it relies on 0001 >> (and with the correct commit message ?). > > These guidelines just make it easier for us to handle the large numbers of > patches that land on the list. Try to follow them next time you send a patch > (or revision), but there's no need to resubmit things just to comply. > We can change the message when pushing if the patch contents are acked. +1. The page describing our submission rules are described on this page: http://www.freeipa.org/page/Contribute/Code and this sub-page: http://www.freeipa.org/page/Contribute/Patch_Format including a patch description example. HTH, Martin From mkosek at redhat.com Thu Aug 14 08:53:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Aug 2014 10:53:26 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> Message-ID: <53EC7906.5060200@redhat.com> On 08/13/2014 09:54 PM, Ade Lee wrote: > In Dogtag, we have decided to revert the name of the DRM to the old name KRA. > DRM was really only used in docs/marketing, whereas KRA is all over the code. > Soon, the code and the marketing/docs will match. > > The following patch changes all references to the DRM to KRA. > so for example, you need to run ipa-kra-install etc. > > Please apply this on top of the previous patch. I'll go ahead and squash them > before commit. > > Thanks, > Ade Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to KRA and assigned respective tickets to that. Let us use the KRA term for the Vault then. Martin From pviktori at redhat.com Thu Aug 14 12:29:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 14 Aug 2014 14:29:00 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53EC7906.5060200@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> Message-ID: <53ECAB8C.6060701@redhat.com> On 08/14/2014 10:53 AM, Martin Kosek wrote: > On 08/13/2014 09:54 PM, Ade Lee wrote: >> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. >> DRM was really only used in docs/marketing, whereas KRA is all over the code. >> Soon, the code and the marketing/docs will match. >> >> The following patch changes all references to the DRM to KRA. >> so for example, you need to run ipa-kra-install etc. >> >> Please apply this on top of the previous patch. I'll go ahead and squash them >> before commit. >> >> Thanks, >> Ade > > Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to > KRA and assigned respective tickets to that. Let us use the KRA term for the > Vault then. > > Martin > ipa_drm_install.py: No newline at end of file ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is ipa-drm-install (with hyphens) The error I got previously was when running ipa-kra-install on a replica that didn't have CA yet. It would be nice to provide a better message for this case. On a replica with KRA, I get: $ sudo ipa-kra-install --uninstall Usage: ipa-kra-install [options] [replica_file] ipa-kra-install: error: Cannot uninstall. There is no KRA installed on this system. I tested the kra plugin with this Python script: from ipalib import api api.bootstrap(context='server', kra_host='localhost') api.finalize() api.Backend.kra.store_secret('test', 'tkey') which gives me: Traceback (most recent call last): File "", line 1, in File "ipaserver/plugins/dogtag.py", line 2012, in store_secret self._setup() File "ipaserver/plugins/dogtag.py", line 1965, in _setup connection = PKIConnection('https', self.kra_host, self.kra_port, 'kra') File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, in __init__ self.hostname + ':' + self.port + '/' + \ TypeError: coercing to Unicode: need string or buffer, int found Apparently, PKIConnection requires the port to be a string, but we pass an int. I'd consider this an issue in pki. The kra_host='localhost' option to api.bootstrap is necessary because kra_host is not added to default.conf on install. How is this planned to work when the plugin is done? -- Petr? From tbordaz at redhat.com Thu Aug 14 17:18:40 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 14 Aug 2014 19:18:40 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins Message-ID: <53ECEF70.40301@redhat.com> Hello, Following Petr remarks from the previous review, I modified the original fix to move it only in '.update' files. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0001-2-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch Type: text/x-patch Size: 6050 bytes Desc: not available URL: From edewata at redhat.com Fri Aug 15 15:59:46 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Aug 2014 10:59:46 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53DBF2DD.4060900@redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> <1406846048.19681.6.camel@willson.usersys.redhat.com> <53DBB21C.40408@redhat.com> <1406913684.19681.13.camel@willson.usersys.redhat.com> <53DBEDA3.5080101@redhat.com> <1406922342.19681.20.camel@willson.usersys.redhat.com> <53DBF2DD.4060900@redhat.com> Message-ID: <53EE2E72.2050806@redhat.com> On 8/1/2014 3:04 PM, Endi Sukma Dewata wrote: > On 8/1/2014 2:45 PM, Simo Sorce wrote: >> On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote: >>> On 8/1/2014 12:21 PM, Simo Sorce wrote: >>>>> OK, understood. This means in the service use case the service vault >>>>> password will have to be provisioned to service instances using >>>>> separate >>>>> vaults that use asymmetric encryption key. This type of vaults will >>>>> become a "drop box" and will not support escrow. >>>> >>>> I do not understand why escrow would not be supported, can you >>>> elaborate ? >>> >>> See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows. >>> >>> With a normal vault (symmetric key) the secrets will be encrypted >>> with a >>> symmetric secret key, then the secret key itself will be encrypted with >>> the escrow officer's public key and stored on the server. On recovery >>> the escrow officer will decrypt the encrypted secret key with the >>> private key, and use it to decrypt the secrets. >>> >>> I suppose with a drop box (asymmetric key) the secrets themselves will >>> be encrypted with the public key of the owner (i.e. the service >>> instance), not the escrow officer. The secrets can only be >>> retrieved/recovered using the owner's private key. There's no secret >>> key >>> to escrow, unless we want to escrow the owner's private key? >> >> The service can create a symmetric key and encrypt it with its public >> key and the escrow public key. > > Not sure I understand. How does the admin provision the service vault > password to the instance? How does the instance retrieve the service > vault password? How does the escrow officer recover the service vault > password? Hi, Please take a look at the revised design: http://www.freeipa.org/page/V4/Password_Vault_Implementation The design now supports two types for vaults: - regular vault with symmetric key derived from vault password, - and drop box with asymmetric keys which may be new keys generated for vault, not necessarily the owner's personal keys. Both types will support escrow now. On regular vault we escrow the vault encryption/secret key. On drop box we escrow the vault private key. It will also support multiple escrow officers. The escrow officers need to share the escrow private key (not the escrow officer's personal keys). I removed the password hash used previously to verify the password. Assuming that retrieving secrets with a wrong password/key will not produce a usable result (invalid JSON structure), it's no longer necessary to verify password. The Client API has been simplified as well by handling the secrets as a single collection. The CLI will still provide the interface to manage the secrets individually. There's no service-specific API, it will be handled by the CLI. Please let me know if you have any comments/questions. See also the FAQ and To Do list at the bottom of the page. I'll be out of the office until Thursday, but I'll be back on Friday 22nd. Thanks! -- Endi S. Dewata From pviktori at redhat.com Fri Aug 15 20:40:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 15 Aug 2014 22:40:41 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring Message-ID: <53EE7049.3050605@redhat.com> A fix for https://fedorahosted.org/freeipa/ticket/4157 This depends on my patches 0631-0632 (for backup/restore integration tests). Our setsebool code was repeated a few times. Instead of adding another copy, I refactored what we have into a platform task. I fixed two old setsebool tickets while I was at it: https://fedorahosted.org/freeipa/ticket/2519 https://fedorahosted.org/freeipa/ticket/2934 Since ipaplatform should not depend on ipalib, and I needed a new exception type, I added a new module, ipapython.errors. This might not be the best name, since it could be confused with ipalib.errors. Opinions welcome. As for the second patch: ideally, rather than what I do with `if 'ADTRUST' in self.backup_services`, we'd get the list of booleans directly from the *instance modules, or even tell the individual services to restore themselves. But, that refactoring looks like too much to do now. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0411-Move-setting-SELinux-booleans-to-platform-code.patch Type: text/x-patch Size: 16594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0412-ipa-restore-Set-SELinux-booleans-when-restoring.patch Type: text/x-patch Size: 3899 bytes Desc: not available URL: From redhatrises at gmail.com Mon Aug 18 02:23:32 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sun, 17 Aug 2014 20:23:32 -0600 Subject: [Freeipa-devel] [DOC] Update firewall sections from iptables to firewalld Message-ID: Hello, This patch updates the iptables references to firewalld and links to the firewalld in the security guides for configuring ports. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0032-DOC-Update-iptables-sections-to-firewalld.patch Type: text/x-patch Size: 12735 bytes Desc: not available URL: From purpleidea at gmail.com Mon Aug 18 04:05:47 2014 From: purpleidea at gmail.com (James) Date: Mon, 18 Aug 2014 00:05:47 -0400 Subject: [Freeipa-devel] Multi-OS FreeIPA in puppet-ipa Message-ID: <1408334747.10563.6.camel@freed> I've just pushed out a WIP feature branch for multi-os puppet-ipa. This is an elegant way to create a multi-os compatible puppet module. It can be useful for managing differences between RHEL and Debian, but also between CentOS and RHEL, and even RHEL 6.x and RHEL 7, etc... Some background on the technique when I did this for puppet-gluster: https://ttboj.wordpress.com/2014/06/04/hiera-data-in-modules-and-os-independent-puppet/ Since I'm only currently testing CentOS/RHEL 6.x, please report any issues with other versions or OS's, and I'll patch them ASAP. WIP branch: https://github.com/purpleidea/puppet-ipa/tree/feat/yamldata I'll rebase this branch as new patches are added, and I'll usually keep it current against git master. Once someone ACK's that it is working against another OS or version, then I'll maintain it in git master. Thank you, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From pviktori at redhat.com Mon Aug 18 14:06:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 18 Aug 2014 16:06:04 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53ECEF70.40301@redhat.com> References: <53ECEF70.40301@redhat.com> Message-ID: <53F2084C.8070307@redhat.com> On 08/14/2014 07:18 PM, thierry bordaz wrote: > Hello, > > Following Petr remarks from the previous review, I modified the > original fix to move it only in '.update' files. > > Thanks > thierry > Looks better, thanks! I've tested install and upgrades, everything works as expected. Some whitespace issues: Applying: User Life Cycle: create containers and scoping DS plugins .git/rebase-apply/patch:44: new blank line at EOF. + .git/rebase-apply/patch:111: new blank line at EOF. + warning: 2 lines add whitespace errors. A tiny nitpick: +dn: cn=Deleted users,cn=accounts,cn=provisioning,$SUFFIX CN is case-insensitive, but the capital D does stand out. Otherwise ACK. We want to push this together with your patch 0002, right? -- Petr? From tbordaz at redhat.com Mon Aug 18 15:03:34 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 18 Aug 2014 17:03:34 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F2084C.8070307@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> Message-ID: <53F215C6.4060200@redhat.com> On 08/18/2014 04:06 PM, Petr Viktorin wrote: > On 08/14/2014 07:18 PM, thierry bordaz wrote: >> Hello, >> >> Following Petr remarks from the previous review, I modified the >> original fix to move it only in '.update' files. >> >> Thanks >> thierry >> > > Looks better, thanks! > I've tested install and upgrades, everything works as expected. :-) . Thanks for your tests. > > > Some whitespace issues: > > Applying: User Life Cycle: create containers and scoping DS plugins > .git/rebase-apply/patch:44: new blank line at EOF. > + > .git/rebase-apply/patch:111: new blank line at EOF. > + > warning: 2 lines add whitespace errors. > > > A tiny nitpick: > +dn: cn=Deleted users,cn=accounts,cn=provisioning,$SUFFIX > > CN is case-insensitive, but the capital D does stand out. Good ! This extra lines sounds a familiar issue to me ;). I fixed this and I removed the extra lines and lowercase. Basically it creates a new patch freeipa-tbordaz-0001-3-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch. How should I proceed here, send a new review on freeipa-devel and/or attache this patch (1.3) to the bug ? > > > > Otherwise ACK. We want to push this together with your patch 0002, right? Well, patch 0002 does not require 0001 (and the opposite as well). Although they are both related to ULC, I separated them to make reviews and dev simpler. So if you are ok, I can push 0001 without the immediate need to push 0002. thanks again thierry > > From pviktori at redhat.com Mon Aug 18 15:10:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 18 Aug 2014 17:10:31 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F215C6.4060200@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> <53F215C6.4060200@redhat.com> Message-ID: <53F21767.9050804@redhat.com> On 08/18/2014 05:03 PM, thierry bordaz wrote: > On 08/18/2014 04:06 PM, Petr Viktorin wrote: >> On 08/14/2014 07:18 PM, thierry bordaz wrote: >>> Hello, >>> >>> Following Petr remarks from the previous review, I modified the >>> original fix to move it only in '.update' files. >>> >>> Thanks >>> thierry >>> >> >> Looks better, thanks! >> I've tested install and upgrades, everything works as expected. > :-) . Thanks for your tests. >> >> >> Some whitespace issues: >> >> Applying: User Life Cycle: create containers and scoping DS plugins >> .git/rebase-apply/patch:44: new blank line at EOF. >> + >> .git/rebase-apply/patch:111: new blank line at EOF. >> + >> warning: 2 lines add whitespace errors. >> >> >> A tiny nitpick: >> +dn: cn=Deleted users,cn=accounts,cn=provisioning,$SUFFIX >> >> CN is case-insensitive, but the capital D does stand out. > > Good ! This extra lines sounds a familiar issue to me ;). I fixed this > and I removed the extra lines and lowercase. > Basically it creates a new patch > freeipa-tbordaz-0001-3-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch. > > How should I proceed here, send a new review on freeipa-devel and/or > attache this patch (1.3) to the bug ? Simply reply to this mail with the revised patch attached. As for attaching patches to the tickets, I've never done it and no one ever complained, so it's not necessary. But attach it if you like :) >> Otherwise ACK. We want to push this together with your patch 0002, right? > Well, patch 0002 does not require 0001 (and the opposite as well). > Although they are both related to ULC, I separated them to make reviews > and dev simpler. > So if you are ok, I can push 0001 without the immediate need to push 0002. OK -- Petr? From tbordaz at redhat.com Mon Aug 18 15:17:37 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 18 Aug 2014 17:17:37 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F21767.9050804@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> <53F215C6.4060200@redhat.com> <53F21767.9050804@redhat.com> Message-ID: <53F21911.4090102@redhat.com> On 08/18/2014 05:10 PM, Petr Viktorin wrote: > On 08/18/2014 05:03 PM, thierry bordaz wrote: >> On 08/18/2014 04:06 PM, Petr Viktorin wrote: >>> On 08/14/2014 07:18 PM, thierry bordaz wrote: >>>> Hello, >>>> >>>> Following Petr remarks from the previous review, I modified the >>>> original fix to move it only in '.update' files. >>>> >>>> Thanks >>>> thierry >>>> >>> >>> Looks better, thanks! >>> I've tested install and upgrades, everything works as expected. >> :-) . Thanks for your tests. >>> >>> >>> Some whitespace issues: >>> >>> Applying: User Life Cycle: create containers and scoping DS plugins >>> .git/rebase-apply/patch:44: new blank line at EOF. >>> + >>> .git/rebase-apply/patch:111: new blank line at EOF. >>> + >>> warning: 2 lines add whitespace errors. >>> >>> >>> A tiny nitpick: >>> +dn: cn=Deleted users,cn=accounts,cn=provisioning,$SUFFIX >>> >>> CN is case-insensitive, but the capital D does stand out. >> >> Good ! This extra lines sounds a familiar issue to me ;). I fixed this >> and I removed the extra lines and lowercase. >> Basically it creates a new patch >> freeipa-tbordaz-0001-3-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch. >> >> >> How should I proceed here, send a new review on freeipa-devel and/or >> attache this patch (1.3) to the bug ? > > Simply reply to this mail with the revised patch attached. > > As for attaching patches to the tickets, I've never done it and no one > ever complained, so it's not necessary. But attach it if you like :) Good to know :). Thanks > >>> Otherwise ACK. We want to push this together with your patch 0002, >>> right? >> Well, patch 0002 does not require 0001 (and the opposite as well). >> Although they are both related to ULC, I separated them to make reviews >> and dev simpler. >> So if you are ok, I can push 0001 without the immediate need to push >> 0002. > > OK > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0001-3-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch Type: text/x-patch Size: 6044 bytes Desc: not available URL: From alee at redhat.com Mon Aug 18 17:36:44 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 18 Aug 2014 13:36:44 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53ECAB8C.6060701@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> Message-ID: <1408383404.22256.15.camel@aleeredhat.laptop> On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote: > On 08/14/2014 10:53 AM, Martin Kosek wrote: > > On 08/13/2014 09:54 PM, Ade Lee wrote: > >> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. > >> DRM was really only used in docs/marketing, whereas KRA is all over the code. > >> Soon, the code and the marketing/docs will match. > >> > >> The following patch changes all references to the DRM to KRA. > >> so for example, you need to run ipa-kra-install etc. > >> > >> Please apply this on top of the previous patch. I'll go ahead and squash them > >> before commit. > >> > >> Thanks, > >> Ade > > > > Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to > > KRA and assigned respective tickets to that. Let us use the KRA term for the > > Vault then. > > > > Martin > > > > ipa_drm_install.py: No newline at end of file > ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is > ipa-drm-install (with hyphens) > fixed > > The error I got previously was when running ipa-kra-install on a replica > that didn't have CA yet. It would be nice to provide a better message > for this case. > agreed. the problem here was that the check to see whether a ca was already installed locally was not working as expected. I have since added a new check - which should fail if a CA is not installed locally. > > On a replica with KRA, I get: > $ sudo ipa-kra-install --uninstall > Usage: ipa-kra-install [options] [replica_file] > > ipa-kra-install: error: Cannot uninstall. There is no KRA > installed on this system. > Not sure what happened there. With the latest code, that does not appear to happen for me. Let me know if it recurs. > I tested the kra plugin with this Python script: > > from ipalib import api > api.bootstrap(context='server', kra_host='localhost') > api.finalize() > api.Backend.kra.store_secret('test', 'tkey') > > which gives me: > > Traceback (most recent call last): > File "", line 1, in > File "ipaserver/plugins/dogtag.py", line 2012, in store_secret > self._setup() > File "ipaserver/plugins/dogtag.py", line 1965, in _setup > connection = PKIConnection('https', self.kra_host, > self.kra_port, 'kra') > File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, > in __init__ > self.hostname + ':' + self.port + '/' + \ > TypeError: coercing to Unicode: need string or buffer, int found > > > Apparently, PKIConnection requires the port to be a string, but we pass > an int. I'd consider this an issue in pki. > Agreed. I will open a ticket to fix it in pki. For now though, I have cast to str(). > > The kra_host='localhost' option to api.bootstrap is necessary because > kra_host is not added to default.conf on install. How is this planned to > work when the plugin is done? > I followed what was done for ca_host, but did not set the required default in constants.py. Thats fixed, so this should work now. After discussion with Endi, I also removed some functions in dogtag.py (the plugin) which basically just wrapped calls to the keyclient. There is no need to do this wrapping and it is much more flexible for IPA code to call the keyclient directly. Accordingly, I have added a method to get the keyclient. Your test code would look like this now: from ipalib import api from pki.key import KeyClient api.bootstrap(context='server') api.finalize() keyclient = api.Backend.kra.get_keyclient() keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') I added a couple of directives in the proxy file to allow it to progress further and it now fails in trying to do the archive_key due to authentication issues. It was never the intention of this patch to get the plugin completely working though. That was the goal of a follow on patch being written by Endi. This patch is already pretty long and touches a lot of code. I propose we let Endi fix the above issue. I have squashed the drm-> kra changes and created just a single patch, which is attached. This is the only patch needed. I'm also starting a new COPR build, just to be sure we all have the most up-to-date dogtag build. Ade > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-3-Add-a-KRA-to-IPA.patch Type: text/x-patch Size: 157798 bytes Desc: not available URL: From dkupka at redhat.com Tue Aug 19 07:05:02 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 19 Aug 2014 09:05:02 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. Message-ID: <53F2F71E.8050802@redhat.com> FreeIPA will use certmonger D-Bus API as discussed in this thread https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html This change should prevent hard-to-reproduce bugs like https://fedorahosted.org/freeipa/ticket/4280 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 34342 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 19 07:38:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Aug 2014 09:38:49 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F21911.4090102@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> <53F215C6.4060200@redhat.com> <53F21767.9050804@redhat.com> <53F21911.4090102@redhat.com> Message-ID: <53F2FF09.4060602@redhat.com> On 08/18/2014 05:17 PM, thierry bordaz wrote: > On 08/18/2014 05:10 PM, Petr Viktorin wrote: >> On 08/18/2014 05:03 PM, thierry bordaz wrote: ... >> >> Simply reply to this mail with the revised patch attached. >> >> As for attaching patches to the tickets, I've never done it and no one ever >> complained, so it's not necessary. But attach it if you like :) > > Good to know :). Thanks It is not required. It is only stated as "optional" step in http://www.freeipa.org/page/Contribute/Code#Submit_a_patch I personally attach at least the first version to help pairing the ticket with the patch number and better searching in the list. The job is done by my patch submission script, so it is no additional work for me anyway :-) Martin From tbordaz at redhat.com Tue Aug 19 07:45:35 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 Aug 2014 09:45:35 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F2FF09.4060602@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> <53F215C6.4060200@redhat.com> <53F21767.9050804@redhat.com> <53F21911.4090102@redhat.com> <53F2FF09.4060602@redhat.com> Message-ID: <53F3009F.60903@redhat.com> On 08/19/2014 09:38 AM, Martin Kosek wrote: > On 08/18/2014 05:17 PM, thierry bordaz wrote: >> On 08/18/2014 05:10 PM, Petr Viktorin wrote: >>> On 08/18/2014 05:03 PM, thierry bordaz wrote: > ... >>> Simply reply to this mail with the revised patch attached. >>> >>> As for attaching patches to the tickets, I've never done it and no one ever >>> complained, so it's not necessary. But attach it if you like :) >> Good to know :). Thanks > It is not required. It is only stated as "optional" step in > http://www.freeipa.org/page/Contribute/Code#Submit_a_patch > > I personally attach at least the first version to help pairing the ticket with > the patch number and better searching in the list. The job is done by my patch > submission script, so it is no additional work for me anyway :-) Ok. Thanks for the explanation. In fact with multi patch ticket, adding all patches (original+reviewed) seems too noisy. I will keep the process to add in the ticket the first version of each patch. thanks thierry > > Martin From pviktori at redhat.com Tue Aug 19 07:51:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Aug 2014 09:51:09 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53F21911.4090102@redhat.com> References: <53ECEF70.40301@redhat.com> <53F2084C.8070307@redhat.com> <53F215C6.4060200@redhat.com> <53F21767.9050804@redhat.com> <53F21911.4090102@redhat.com> Message-ID: <53F301ED.5010309@redhat.com> On 08/18/2014 05:17 PM, thierry bordaz wrote: > On 08/18/2014 05:10 PM, Petr Viktorin wrote: >> On 08/18/2014 05:03 PM, thierry bordaz wrote: >>> On 08/18/2014 04:06 PM, Petr Viktorin wrote: >>>> On 08/14/2014 07:18 PM, thierry bordaz wrote: >>>>> Hello, [...] >>>> Otherwise ACK. We want to push this together with your patch 0002, >>>> right? >>> Well, patch 0002 does not require 0001 (and the opposite as well). >>> Although they are both related to ULC, I separated them to make reviews >>> and dev simpler. >>> So if you are ok, I can push 0001 without the immediate need to push >>> 0002. >> >> OK Pushed to master: 04ea75a7a5109907ede2a0216bd39fac46a992c0 -- Petr? From mkosek at redhat.com Tue Aug 19 07:58:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Aug 2014 09:58:16 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53F2F71E.8050802@redhat.com> References: <53F2F71E.8050802@redhat.com> Message-ID: <53F30398.1030905@redhat.com> On 08/19/2014 09:05 AM, David Kupka wrote: > FreeIPA will use certmonger D-Bus API as discussed in this thread > https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html > > This change should prevent hard-to-reproduce bugs like > https://fedorahosted.org/freeipa/ticket/4280 Thanks for this effort, the updated certmonger module looks much better! This will help us get rid of the non-standard communication with certmonger. Just couple initial comments from me by reading the code: 1) Testing needs fixed version of certmonger, right? This needs to be spelled out right with the patch. 2) Description text in patches is cheap, do not be afraid to use it and describe what you did and why. Link to the ticket is missing in the description as well: > Subject: [PATCH] Use certmonger D-Bus API instead of messing with its files. > > --- 3) get_request_id API: > criteria = ( > - ('cert_storage_location', dogtag_constants.ALIAS_DIR, > - certmonger.NPATH), > - ('cert_nickname', nickname, None), > + ('cert_storage_location', dogtag_constants.ALIAS_DIR), > + ('cert_nickname', nickname), > ) > request_id = certmonger.get_request_id(criteria) Do we want to continue using the "criteria" object or should we rather switch to normal function options? I.e. rather using request_id = certmonger.get_request_id(cert_nickname=nickname, cert_storage_location=dogtag_constants.ALIAS_DIR) ? It would look more consistent with other calls. I am just asking, not insisting. 3) Starting function: > + try: > + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], skip_output=True) > + except Exception, e: > + root_logger.error('Failed to start certmonger: %s' % e) > + raise e I see 2 issues related to this code: a) Do not call SYSTEMCTL directly. To be platform independent, rather use services.knownservices.messagebus.start() that is overridable by someone else porting to non-systemd platforms. b) In this case, do not use "raise e", but just "raise" to keep the exception stack trace intact for better debugging. Both a) and b) should be fixed in other occasions and places. 4) Feel free to add yourself to Authors section of this module. You refactored it greatly to earn it :-) Martin From pviktori at redhat.com Tue Aug 19 11:28:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Aug 2014 13:28:44 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals Message-ID: <53F334EC.2030009@redhat.com> Services can now be added to roles. https://fedorahosted.org/freeipa/ticket/3164 I added a new integration test for checking that a service can actually use the right granted by a role. I don't think there's a good way to do this kind of thing in our Declarative test suite. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0635-Support-delegating-RBAC-roles-to-service-principals.patch Type: text/x-patch Size: 6747 bytes Desc: not available URL: From pspacek at redhat.com Tue Aug 19 11:40:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 Aug 2014 13:40:52 +0200 Subject: [Freeipa-devel] [PATCH 0278] Fix ticket expiration check Message-ID: <53F337C4.3040806@redhat.com> Hello, Fix ticket expiration check. https://fedorahosted.org/bind-dyndb-ldap/ticket/131 This is one of obvious bugs when you finally see it :-) The original code died miserably when named reload happened 0-300 seconds after ticket expiration. Symptoms (debug level 6): > registering dynamic ldap driver for ipa. > trying to establish LDAP connection to ldapi://%2fvar%2frun%2fslapd-IPA-EXAMPLE.socket > Using default keytab file name: FILE:/etc/named.keytab > Found valid Kerberos credentials in cache > trying interactive bind using GSSAPI mechanism > doing interactive bind > got request for SASL_CB_USER > bind to LDAP server failed: Local error > couldn't establish connection in LDAP connection pool: failure > LDAP instance 'ipa' destroyed > load_configuration: failure > reloading configuration failed: failure There is at least one other problem which causes deadlock on shutdown from time to time, I will look into it separately. Both problems are hard to reproduce. It seems that the best chance is to change logrotate period (/etc/logrotate.d/named) or Kerberos ticket policy (ipa krbtpolicy-mod) to the same values, keep fingers crossed and hope. On my VM it manifests after several iterations. This patch should go to all maintained branches (v2, v3, v4, master). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0278-Fix-ticket-expiration-check.patch Type: text/x-patch Size: 1034 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 19 11:41:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Aug 2014 13:41:22 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F334EC.2030009@redhat.com> References: <53F334EC.2030009@redhat.com> Message-ID: <53F337E2.7010702@redhat.com> On 08/19/2014 01:28 PM, Petr Viktorin wrote: > Services can now be added to roles. > > https://fedorahosted.org/freeipa/ticket/3164 > > > I added a new integration test for checking that a service can actually use the > right granted by a role. I don't think there's a good way to do this kind of > thing in our Declarative test suite. 1) I think you also need to update service object's attribute_members so that it can properly show role membership. 2) Why did you skip updating VERSION file? 3) We will also need patch for Web UI (will require fix for 1. IMO). CCing Petr Vobornik to help with 3). Martin From dkupka at redhat.com Tue Aug 19 15:05:08 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 19 Aug 2014 17:05:08 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53F30398.1030905@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> Message-ID: <53F367A4.9000802@redhat.com> On 08/19/2014 09:58 AM, Martin Kosek wrote: > On 08/19/2014 09:05 AM, David Kupka wrote: >> FreeIPA will use certmonger D-Bus API as discussed in this thread >> https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html >> >> This change should prevent hard-to-reproduce bugs like >> https://fedorahosted.org/freeipa/ticket/4280 > > Thanks for this effort, the updated certmonger module looks much better! This > will help us get rid of the non-standard communication with certmonger. > > Just couple initial comments from me by reading the code: > > 1) Testing needs fixed version of certmonger, right? This needs to be spelled > out right with the patch. Yes, certmonger 0.75.13 and above should be fine according ticket https://fedorahosted.org/certmonger/ticket/36. Added to patch description. > > 2) Description text in patches is cheap, do not be afraid to use it and > describe what you did and why. Link to the ticket is missing in the description > as well: Ok, increased verbosity a bit :-) > >> Subject: [PATCH] Use certmonger D-Bus API instead of messing with its files. >> >> --- > > 3) get_request_id API: > >> criteria = ( >> - ('cert_storage_location', dogtag_constants.ALIAS_DIR, >> - certmonger.NPATH), >> - ('cert_nickname', nickname, None), >> + ('cert_storage_location', dogtag_constants.ALIAS_DIR), >> + ('cert_nickname', nickname), >> ) >> request_id = certmonger.get_request_id(criteria) > > Do we want to continue using the "criteria" object or should we rather switch > to normal function options? I.e. rather using > > request_id = certmonger.get_request_id(cert_nickname=nickname, > cert_storage_location=dogtag_constants.ALIAS_DIR) > > ? It would look more consistent with other calls. I am just asking, not insisting. I've no preference here. It seems to be a very small change. Has anyone a reason to do it one way and not the other? > > 3) Starting function: > >> + try: >> + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], skip_output=True) >> + except Exception, e: >> + root_logger.error('Failed to start certmonger: %s' % e) >> + raise e > > I see 2 issues related to this code: > a) Do not call SYSTEMCTL directly. To be platform independent, rather use > services.knownservices.messagebus.start() that is overridable by someone else > porting to non-systemd platforms. Is there anything that can't be done using ipalib/ipapython/ipaplatform? > b) In this case, do not use "raise e", but just "raise" to keep the exception > stack trace intact for better debugging. Every day there's something new to learn about python or FreeIPA. > > Both a) and b) should be fixed in other occasions and places. I found only one occurence of a) issue. Is there some hidden or are you talking about the whole FreeIPA project? > > 4) Feel free to add yourself to Authors section of this module. You refactored > it greatly to earn it :-) Done. > > Martin > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-2-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 34905 bytes Desc: not available URL: From dpal at redhat.com Tue Aug 19 15:11:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 Aug 2014 17:11:21 +0200 Subject: [Freeipa-devel] OpenLMI integration Message-ID: <53F36919.6020306@redhat.com> Hello, As some might have heard there are plans to refactor our approach to how IPA server instances are installed and managed. Right now the procedures for server installation imply administrator presence and interaction. In the automated environments that does not work quite well. So we did some evaluation and decided that it would make sense to make IPA be capable of managing its on cluster as well as to be able to deploy IPA from an external system using tools of your preference without imposing too much knowledge of IPA internals on these tools. OpenLMI approach seems like the best available so we reached out to OpenLMI project to get some guidance. The following page is the summary of the architecture we managed to work out with OpenLMI guys. This is a high level architecture. The goal of the page is to define the parts of the solution and summarize the scope of effort. The plan is to handle it in FreeIPA 4.2 so whoever is going to be in charge of the implementation of different componants would probably create specific pages or sections for those components and fill the rest of the template per component. Comments and suggestions welcome but I would suggest we refrain from diving into design and implementation until somone actually picks up this feature in several months. Right now let us focus on making sure that: a) Approach makes sense b) Architecture is sound c) Components and interfaces are not missing d) All core elements of the feature outlined Link - http://www.freeipa.org/page/V4/IPA_Server_Management_via_OpenLMI -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jdennis at redhat.com Tue Aug 19 15:31:53 2014 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Aug 2014 11:31:53 -0400 Subject: [Freeipa-devel] OpenLMI integration In-Reply-To: <53F36919.6020306@redhat.com> References: <53F36919.6020306@redhat.com> Message-ID: <53F36DE9.7060709@redhat.com> Seeing all the blue lines of CIM <--> DBus I thought I would remind folks that the realmd cim provider has a nice DBus module that sits between the extremely low level DBus API and the very high level DBus GObject/GType API. In other words it lets you do things in C code which uses gVariants, etc. *without* having pull in the entire GObject/GType complexity. I always thought this should be a separate library so others who have to code DBus in C could use it. [1] As Goldilocks said "It's not too small, it's not too big, it's just right" :-) [1] Writing DBus in C can be tedious and frustrating because you're forced to use either something really primitive or something extraordinarily complicated (unless you happen to be a Gnome guru and totally grok the entire GObject/GType pseudo objected-orientated class framework that you have to code to). If the DBus interface you're coding to includes things like variants I think you'll appreciate the middle approach. -- John From rcritten at redhat.com Tue Aug 19 15:44:54 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Aug 2014 11:44:54 -0400 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53F367A4.9000802@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> <53F367A4.9000802@redhat.com> Message-ID: <53F370F6.9030700@redhat.com> David Kupka wrote: > On 08/19/2014 09:58 AM, Martin Kosek wrote: >> On 08/19/2014 09:05 AM, David Kupka wrote: >>> FreeIPA will use certmonger D-Bus API as discussed in this thread >>> https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html >>> >>> This change should prevent hard-to-reproduce bugs like >>> https://fedorahosted.org/freeipa/ticket/4280 >> >> Thanks for this effort, the updated certmonger module looks much >> better! This >> will help us get rid of the non-standard communication with certmonger. >> >> Just couple initial comments from me by reading the code: >> >> 1) Testing needs fixed version of certmonger, right? This needs to be >> spelled >> out right with the patch. > Yes, certmonger 0.75.13 and above should be fine according ticket > https://fedorahosted.org/certmonger/ticket/36. Added to patch description. You should update the spec to set the minimum version as well. >> >> 2) Description text in patches is cheap, do not be afraid to use it and >> describe what you did and why. Link to the ticket is missing in the >> description >> as well: > Ok, increased verbosity a bit :-) >> >>> Subject: [PATCH] Use certmonger D-Bus API instead of messing with its >>> files. >>> >>> --- >> >> 3) get_request_id API: >> >>> criteria = ( >>> - ('cert_storage_location', dogtag_constants.ALIAS_DIR, >>> - certmonger.NPATH), >>> - ('cert_nickname', nickname, None), >>> + ('cert_storage_location', dogtag_constants.ALIAS_DIR), >>> + ('cert_nickname', nickname), >>> ) >>> request_id = certmonger.get_request_id(criteria) >> >> Do we want to continue using the "criteria" object or should we rather >> switch >> to normal function options? I.e. rather using >> >> request_id = certmonger.get_request_id(cert_nickname=nickname, >> cert_storage_location=dogtag_constants.ALIAS_DIR) >> >> ? It would look more consistent with other calls. I am just asking, >> not insisting. > I've no preference here. It seems to be a very small change. Has anyone > a reason to do it one way and not the other? I think I used this criteria thing to avoid having a bazillion optional parameters and for future-proofing. I think at this point the list is probably pretty stable, so I'd base it on whether you care about having a whole ton of optional parameters or not (it has the advantage of self-documenting itself). >> >> 3) Starting function: >> >>> + try: >>> + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], >>> skip_output=True) >>> + except Exception, e: >>> + root_logger.error('Failed to start certmonger: %s' % e) >>> + raise e >> >> I see 2 issues related to this code: >> a) Do not call SYSTEMCTL directly. To be platform independent, rather use >> services.knownservices.messagebus.start() that is overridable by >> someone else >> porting to non-systemd platforms. > Is there anything that can't be done using ipalib/ipapython/ipaplatform? It can't make coffee (yet). >> b) In this case, do not use "raise e", but just "raise" to keep the >> exception >> stack trace intact for better debugging. > Every day there's something new to learn about python or FreeIPA. >> >> Both a) and b) should be fixed in other occasions and places. > I found only one occurence of a) issue. Is there some hidden or are you > talking about the whole FreeIPA project? >> >> 4) Feel free to add yourself to Authors section of this module. You >> refactored >> it greatly to earn it :-) > Done. You already import dbus, why also separately import DBusException? rob From mkosek at redhat.com Tue Aug 19 16:35:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Aug 2014 18:35:55 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53F370F6.9030700@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> <53F367A4.9000802@redhat.com> <53F370F6.9030700@redhat.com> Message-ID: <53F37CEB.5040101@redhat.com> On 08/19/2014 05:44 PM, Rob Crittenden wrote: > David Kupka wrote: ... >>> b) In this case, do not use "raise e", but just "raise" to keep the >>> exception >>> stack trace intact for better debugging. >> Every day there's something new to learn about python or FreeIPA. >>> >>> Both a) and b) should be fixed in other occasions and places. >> I found only one occurence of a) issue. Is there some hidden or are you >> talking about the whole FreeIPA project? Ah, I see - there really is just one a). You can just fix the refactored plugin, let us not save the whole world/freeipa yet. Martin From pviktori at redhat.com Tue Aug 19 17:49:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Aug 2014 19:49:00 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F337E2.7010702@redhat.com> References: <53F334EC.2030009@redhat.com> <53F337E2.7010702@redhat.com> Message-ID: <53F38E0C.3060703@redhat.com> On 08/19/2014 01:41 PM, Martin Kosek wrote: > On 08/19/2014 01:28 PM, Petr Viktorin wrote: >> Services can now be added to roles. >> >> https://fedorahosted.org/freeipa/ticket/3164 >> >> >> I added a new integration test for checking that a service can actually use the >> right granted by a role. I don't think there's a good way to do this kind of >> thing in our Declarative test suite. > > 1) I think you also need to update service object's attribute_members so that > it can properly show role membership. Right, added (with tests). > 2) Why did you skip updating VERSION file? A rookie mistake. (Forgot to save the file) > 3) We will also need patch for Web UI (will require fix for 1. IMO). CCing Petr > Vobornik to help with 3). Updated patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0635.2-Support-delegating-RBAC-roles-to-service-principals.patch Type: text/x-patch Size: 14534 bytes Desc: not available URL: From npmccallum at redhat.com Tue Aug 19 20:46:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 19 Aug 2014 16:46:19 -0400 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation Message-ID: <1408481179.3505.6.camel@redhat.com> Also, remove the attempt to load the objectClasses when absent. This never makes sense during an add operation. https://fedorahosted.org/freeipa/ticket/4455 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0061-Ensure-ipaUserAuthTypeClass-when-needed-on-user-crea.patch Type: text/x-patch Size: 2578 bytes Desc: not available URL: From npmccallum at redhat.com Tue Aug 19 21:10:48 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 19 Aug 2014 17:10:48 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name Message-ID: <1408482648.3505.8.camel@redhat.com> Admins need the ability to specify the token ID in the case of imports. However, generally, this ability is not needed. Is it possible to offload the ID generation to the ipa-uuid plugin? I'm not quite sure how to enable this (I think it involves passing a magic value?). But I'm not quite sure how this fits in with the IPA framework as the generated value is the DN. However, assuming this can be used, I propose the following. The token ID is removed from the UI for regular users (but retained for admins). We change the ACIs for token addition/modification to prevent regular users from specifying the ID in an add or mod operation. The CLI would retain the option to set it, but this option would only be usable by admins. Make sense? From pvoborni at redhat.com Wed Aug 20 08:46:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 Aug 2014 10:46:17 +0200 Subject: [Freeipa-devel] [PATCH] 718 webui: better error reporting In-Reply-To: <53EA3974.9030502@redhat.com> References: <53E0BDDB.3060501@redhat.com> <53EA3974.9030502@redhat.com> Message-ID: <53F46059.7000600@redhat.com> On 12.8.2014 17:57, Endi Sukma Dewata wrote: > On 8/5/2014 6:19 AM, Petr Vobornik wrote: >> On page: >> - styled to use proper line breaks >> - "centered" by .container class and not by huge padding >> >> Console: >> - proper line breaks >> - links in stack trace are clickable(Chrome) > > ACK. Pushed to ipa-4-0: * d3a7fecdaf7e8a8bd35713ff53cccca6e0dcbc9e webui: better error reporting ipa-4-1: * 23413e9daad540d3f23aedf124fba64a9b5a1904 webui: better error reporting master: * e995d2b827cae875245a479ee0a090c546f2858e webui: better error reporting > > -- > Endi S. Dewata -- Petr Vobornik From pvoborni at redhat.com Wed Aug 20 08:46:23 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 Aug 2014 10:46:23 +0200 Subject: [Freeipa-devel] [PATCH] 719 webui-ci: fix table widget add In-Reply-To: <53EA399D.9080106@redhat.com> References: <53E0BE08.7010406@redhat.com> <53EA399D.9080106@redhat.com> Message-ID: <53F4605F.8080606@redhat.com> On 12.8.2014 17:58, Endi Sukma Dewata wrote: > On 8/5/2014 6:20 AM, Petr Vobornik wrote: >> add_table_record call used old selector for add button which >> caused 3 fails in CI: >> - ERROR: Test automember rebuild membership feature for hosts >> - ERROR: Test automember rebuild membership feature for users >> - ERROR: Basic CRUD: dns >> >> related to: >> https://fedorahosted.org/freeipa/ticket/4258 > > ACK. > > -- > Endi S. Dewata Pushed to: ipa-4-0: 4582f48806644a7088eb1cda9beff189c5aa2c68 ipa-4-1: 4fde71672eb22390480d40fb0ed3c27df040a1b3 master: a3c51e2383a0abc6ab09537734187f67356fea0b -- Petr Vobornik From mkosek at redhat.com Wed Aug 20 08:59:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Aug 2014 10:59:23 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F38E0C.3060703@redhat.com> References: <53F334EC.2030009@redhat.com> <53F337E2.7010702@redhat.com> <53F38E0C.3060703@redhat.com> Message-ID: <53F4636B.4000409@redhat.com> On 08/19/2014 07:49 PM, Petr Viktorin wrote: > On 08/19/2014 01:41 PM, Martin Kosek wrote: >> On 08/19/2014 01:28 PM, Petr Viktorin wrote: >>> Services can now be added to roles. >>> >>> https://fedorahosted.org/freeipa/ticket/3164 >>> >>> >>> I added a new integration test for checking that a service can actually use the >>> right granted by a role. I don't think there's a good way to do this kind of >>> thing in our Declarative test suite. >> >> 1) I think you also need to update service object's attribute_members so that >> it can properly show role membership. > > Right, added (with tests). Thanks! (especially for the tests) I am thinking about one usability improvement. All over the code, we allow to specify services without the REALM as the realm is pretty clear and we do not need it from the user: # ipa service-add test/`hostname` ------------------------------------------------------------------ Added service "test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST" ------------------------------------------------------------------ Principal: test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST Managed by: ipa.mkosek-fedora20.test However, the new --services option does not allow that: ]# ipa role-add-member foo --services test/`hostname` Role name: foo Description: foo Failed members: member user: member group: member host: member host group: member service: test/ipa.mkosek-fedora20.test: no such entry ------------------------- Number of members added 0 ------------------------- Could we just add the realm if it does not exists in the service-add-member precallback? Martin From mkosek at redhat.com Wed Aug 20 09:00:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Aug 2014 11:00:44 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F4636B.4000409@redhat.com> References: <53F334EC.2030009@redhat.com> <53F337E2.7010702@redhat.com> <53F38E0C.3060703@redhat.com> <53F4636B.4000409@redhat.com> Message-ID: <53F463BC.6090405@redhat.com> On 08/20/2014 10:59 AM, Martin Kosek wrote: > On 08/19/2014 07:49 PM, Petr Viktorin wrote: ... > Could we just add the realm if it does not exists in the service-add-member > precallback? s/service-add-member/role-add-member/ Martin From sgallagh at redhat.com Wed Aug 20 11:59:22 2014 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 20 Aug 2014 07:59:22 -0400 Subject: [Freeipa-devel] [PATCH] Change BuildRequires for Java Message-ID: <53F48D9A.9040803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. This is breaking my nightly static analysis scans on Rawhide. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP0jZoACgkQeiVVYja6o6OyNgCeL/x+CKnGMhuw8tGM/X3xi5Po L+8AoKI14SRizGxPmBpjhuZkxk8uZlLU =l8zE -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-BuildRequires-for-Java.patch Type: text/x-patch Size: 967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-BuildRequires-for-Java.patch.sig Type: application/pgp-signature Size: 72 bytes Desc: not available URL: From sgallagh at redhat.com Wed Aug 20 12:17:01 2014 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 20 Aug 2014 08:17:01 -0400 Subject: [Freeipa-devel] [PATCH] Change BuildRequires for Java In-Reply-To: <53F48D9A.9040803@redhat.com> References: <53F48D9A.9040803@redhat.com> Message-ID: <53F491BD.9030807@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2014 07:59 AM, Stephen Gallagher wrote: > Requiring a specific version of Java leads to breakages, like the > one happening on nightly builds in Fedora Rawhide right now. We > should use the more generic 'java' BuildRequires instead of the > versioned one. > > > This is breaking my nightly static analysis scans on Rawhide. > > It was pointed out on IRC that we should be using java-headless as well. Updated patch attached. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP0kb0ACgkQeiVVYja6o6PpRQCeMwFoK+Pm1YILMhGqW6gxPF8B f54AmgPufg9fMKo2/l4h3yh5/13S6SHW =lFv4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-BuildRequires-for-Java.patch Type: text/x-patch Size: 976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-BuildRequires-for-Java.patch.sig Type: application/pgp-signature Size: 72 bytes Desc: not available URL: From tbordaz at redhat.com Wed Aug 20 12:35:12 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 20 Aug 2014 14:35:12 +0200 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <1408481179.3505.6.camel@redhat.com> References: <1408481179.3505.6.camel@redhat.com> Message-ID: <53F49600.7070504@redhat.com> On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: > Also, remove the attempt to load the objectClasses when absent. This > never makes sense during an add operation. > > https://fedorahosted.org/freeipa/ticket/4455 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Reading the patch I have one novice remark. In the previous code, 'objectclass' was added to 'entry_attr' in the case it was missing in 'entry_attr' (at the condition 'ipatokenradiusconfiglink' was defined). In the new code, if 'objectclass' is missing it is not added. Is it ok ? Also, regarding the 'user life cycle'. Staging users are candidate to become Active users. I wonder if Staging users should also contain your fix that add the ipaUserAuthTypeClass. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Aug 20 13:02:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Aug 2014 15:02:06 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1408383404.22256.15.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> Message-ID: <53F49C4E.9050705@redhat.com> On 08/18/2014 07:36 PM, Ade Lee wrote: [...] > > After discussion with Endi, I also removed some functions in dogtag.py > (the plugin) which basically just wrapped calls to the keyclient. There > is no need to do this wrapping and it is much more flexible for IPA code > to call the keyclient directly. Accordingly, I have added a method to > get the keyclient. Your test code would look like this now: > > from ipalib import api > from pki.key import KeyClient > api.bootstrap(context='server') > api.finalize() > keyclient = api.Backend.kra.get_keyclient() > keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') > > I added a couple of directives in the proxy file to allow it to progress > further and it now fails in trying to do the archive_key due to > authentication issues. > > It was never the intention of this patch to get the plugin completely > working though. That was the goal of a follow on patch being written by > Endi. This patch is already pretty long and touches a lot of code. I > propose we let Endi fix the above issue. I understand. However, I don't know another way to do a functional test. Without the plugin the best I can do is look if there are some extra entries in DS, and since I don't know KRA internals I can't check if they're correct. With the above script, I get: >>> from ipalib import api >>> from pki.key import KeyClient >>> api.bootstrap(context='server') >>> api.finalize() >>> keyclient = api.Backend.kra.get_keyclient() >>> >>> keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/pki/__init__.py", line 253, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python2.7/site-packages/pki/key.py", line 616, in archive_key key_size=key_size) File "/usr/lib/python2.7/site-packages/pki/__init__.py", line 253, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python2.7/site-packages/pki/key.py", line 669, in archive_encrypted_data return self.create_request(request) File "/usr/lib/python2.7/site-packages/pki/__init__.py", line 253, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python2.7/site-packages/pki/key.py", line 527, in create_request response = self.connection.post(url, key_request, self.headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line 70, in post params=params) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 377, in post return self.request('POST', url, data=data, **kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 335, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 438, in send r = adapter.send(request, **kwargs) File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 331, in send raise SSLError(e) requests.exceptions.SSLError: [Errno 1] _ssl.c:1419: error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message > I have squashed the drm-> kra changes and created just a single patch, > which is attached. This is the only patch needed. I didn't find any issues except the error above. > I'm also starting a new COPR build, just to be sure we all have the most > up-to-date dogtag build. Things are working nicely for the most part. However I still did manage to break my installation: - Install master and replica, both with CA and KRA - Remove KRA on both hosts At this point, trying to instal KRA on the replica fails: $ sudo ipa-kra-install replica-info-file.gpg Usage: ipa-kra-install [options] [replica_file] ipa-kra-install: error: Too many parameters provided. No replica file is required. $ sudo ipa-kra-install Directory Manager password: =================================================================== This program will setup Dogtag KRA for the FreeIPA Server. Configuring KRA server (pki-tomcatd): Estimated time 2 minutes 6 seconds [1/5]: configuring KRA instance failed to configure KRA instance Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmp_FKfkR'' returned non-zero exit status 1 Your system may be partly configured. Run ipa-kra-install --uninstall to clean up. Configuration of KRA failed This seems to cripple the installation: ipa-kra-install --uninstall will complain that KRA is not installed. Also, ipa-kra-install on the master will complain that it wasn't given a replica file. I understand this is an edge case, but we should handle it if we support uninstallation. I'd be okay with disabling --uninstall for now and filing a ticket for later. (After all, ipa-ca-install doesn't have --uninstall at all.) -- Petr? From npmccallum at redhat.com Wed Aug 20 13:48:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 20 Aug 2014 09:48:21 -0400 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <53F49600.7070504@redhat.com> References: <1408481179.3505.6.camel@redhat.com> <53F49600.7070504@redhat.com> Message-ID: <1408542501.3505.10.camel@redhat.com> On Wed, 2014-08-20 at 14:35 +0200, thierry bordaz wrote: > On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: > > > Also, remove the attempt to load the objectClasses when absent. This > > never makes sense during an add operation. > > > > https://fedorahosted.org/freeipa/ticket/4455 > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello Nathaniel, > > Reading the patch I have one novice remark. In the previous > code, 'objectclass' was added to 'entry_attr' in the case it > was missing in 'entry_attr' (at the condition > 'ipatokenradiusconfiglink' was defined). In the new code, if > 'objectclass' is missing it is not added. Is it ok ? I don't think objectClass is ever missing. It must be specified in an add operation. Attempting to load the attribute doesn't make sense when you are adding the object. > Also, regarding the 'user life cycle'. Staging users are > candidate to become Active users. I wonder if Staging users > should also contain your fix that add the > ipaUserAuthTypeClass. What code is this in? Nathaniel From tbordaz at redhat.com Wed Aug 20 14:03:28 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 20 Aug 2014 16:03:28 +0200 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <1408542501.3505.10.camel@redhat.com> References: <1408481179.3505.6.camel@redhat.com> <53F49600.7070504@redhat.com> <1408542501.3505.10.camel@redhat.com> Message-ID: <53F4AAB0.7090803@redhat.com> On 08/20/2014 03:48 PM, Nathaniel McCallum wrote: > On Wed, 2014-08-20 at 14:35 +0200, thierry bordaz wrote: >> On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: >> >>> Also, remove the attempt to load the objectClasses when absent. This >>> never makes sense during an add operation. >>> >>> https://fedorahosted.org/freeipa/ticket/4455 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello Nathaniel, >> >> Reading the patch I have one novice remark. In the previous >> code, 'objectclass' was added to 'entry_attr' in the case it >> was missing in 'entry_attr' (at the condition >> 'ipatokenradiusconfiglink' was defined). In the new code, if >> 'objectclass' is missing it is not added. Is it ok ? > I don't think objectClass is ever missing. It must be specified in an > add operation. Attempting to load the attribute doesn't make sense when > you are adding the object. Yes I agree. > >> Also, regarding the 'user life cycle'. Staging users are >> candidate to become Active users. I wonder if Staging users >> should also contain your fix that add the >> ipaUserAuthTypeClass. > What code is this in? Well it is not yet into master. stageuser plugin is still under review (design is http://www.freeipa.org/page/V3/User_Life-Cycle_Management) Now parts of stageuser_add code are close to user_add. When a stage user is activated (stage user entry is move to Active container), it becomes a full IPA user. This is why if a IPA user needs to be 'ipauserauthtypeclass' it impacts stage user. Either stageuser_add does the same as user_add or stageuser_activate checks the need of 'ipauserauthtypeclass. thanks thierry > > Nathaniel > From pvoborni at redhat.com Wed Aug 20 14:32:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 Aug 2014 16:32:50 +0200 Subject: [Freeipa-devel] [PATCH] Change BuildRequires for Java In-Reply-To: <53F491BD.9030807@redhat.com> References: <53F48D9A.9040803@redhat.com> <53F491BD.9030807@redhat.com> Message-ID: <53F4B192.9020503@redhat.com> On 20.8.2014 14:17, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/20/2014 07:59 AM, Stephen Gallagher wrote: >> Requiring a specific version of Java leads to breakages, like the >> one happening on nightly builds in Fedora Rawhide right now. We >> should use the more generic 'java' BuildRequires instead of the >> versioned one. >> >> >> This is breaking my nightly static analysis scans on Rawhide. >> >> > > It was pointed out on IRC that we should be using java-headless as > well. Updated patch attached. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlP0kb0ACgkQeiVVYja6o6PpRQCeMwFoK+Pm1YILMhGqW6gxPF8B > f54AmgPufg9fMKo2/l4h3yh5/13S6SHW > =lFv4 > -----END PGP SIGNATURE----- > > ACK Pushed to: ipa-4-0: 52f7bb4de98b4c43828668222b14d8f490d61bb7 ipa-4-1: a6927994a0fd17f0fa7446f037d9840f21bcb445 master: fa8f180ff5d68d0f492af258785a06e4c8079e1b Tested on f20 and rawhide. -- Petr Vobornik From mbasti at redhat.com Wed Aug 20 15:37:09 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Aug 2014 17:37:09 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation Message-ID: <53F4C0A5.6030408@redhat.com> Patches attached. Ticket: https://fedorahosted.org/freeipa/ticket/4488 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0107-FIX-DNS-wildcard-records-RFC4592.patch Type: text/x-patch Size: 2389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0108-Tests-DNS-wildcard-records.patch Type: text/x-patch Size: 4370 bytes Desc: not available URL: From pviktori at redhat.com Wed Aug 20 16:09:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Aug 2014 18:09:05 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F4636B.4000409@redhat.com> References: <53F334EC.2030009@redhat.com> <53F337E2.7010702@redhat.com> <53F38E0C.3060703@redhat.com> <53F4636B.4000409@redhat.com> Message-ID: <53F4C821.9060509@redhat.com> On 08/20/2014 10:59 AM, Martin Kosek wrote: > On 08/19/2014 07:49 PM, Petr Viktorin wrote: >> On 08/19/2014 01:41 PM, Martin Kosek wrote: >>> On 08/19/2014 01:28 PM, Petr Viktorin wrote: >>>> Services can now be added to roles. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3164 >>>> >>>> >>>> I added a new integration test for checking that a service can actually use the >>>> right granted by a role. I don't think there's a good way to do this kind of >>>> thing in our Declarative test suite. >>> >>> 1) I think you also need to update service object's attribute_members so that >>> it can properly show role membership. >> >> Right, added (with tests). > > Thanks! (especially for the tests) > > I am thinking about one usability improvement. All over the code, we allow to > specify services without the REALM as the realm is pretty clear and we do not > need it from the user: > > # ipa service-add test/`hostname` > ------------------------------------------------------------------ > Added service "test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST" > ------------------------------------------------------------------ > Principal: test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > Managed by: ipa.mkosek-fedora20.test > > However, the new --services option does not allow that: > > ]# ipa role-add-member foo --services test/`hostname` > Role name: foo > Description: foo > Failed members: > member user: > member group: > member host: > member host group: > member service: test/ipa.mkosek-fedora20.test: no such entry > ------------------------- > Number of members added 0 > ------------------------- > > Could we just add the realm if it does not exists in the service-add-member > precallback? Looks like we want to add it any time we look up a service, right? This additional patch should do that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0636.2-service-Normalize-service-principal-in-get_dn.patch Type: text/x-patch Size: 3041 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 20 17:26:24 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Aug 2014 19:26:24 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation Message-ID: <53F4DA40.7060507@redhat.com> Part of DNSSEC Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0109-DNSSEC-fix-DS-record-validation.patch Type: text/x-patch Size: 2107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0110-Tests-DNS-dsrecord-validation.patch Type: text/x-patch Size: 3146 bytes Desc: not available URL: From pvoborni at redhat.com Wed Aug 20 17:30:32 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 Aug 2014 19:30:32 +0200 Subject: [Freeipa-devel] [PATCH] 730-732 webui: Login pages usability improvements In-Reply-To: <53EA7FDA.5020906@redhat.com> References: <53E0C1BC.7070404@redhat.com> <53EA7FDA.5020906@redhat.com> Message-ID: <53F4DB38.4090808@redhat.com> On 12.8.2014 22:58, Endi Sukma Dewata wrote: > On 8/5/2014 6:36 AM, Petr Vobornik wrote: >> [PATCH] 730 webui: display expired session notification in a more visible >> area >> >> The notification is a primary information of the page. It should be >> more highlighted. >> >> https://fedorahosted.org/freeipa/ticket/4470 > > ACK. > >> [PATCH] 731 webui: improved info msgs on login/token sync/reset pwd >> pages >> >> - add info icons to distinguish and classify the messages. >> - add info text for OTP fields >> - fix login instruction inaccuracy related to position of login button >> >> https://fedorahosted.org/freeipa/ticket/4470 > > Just one thing, instead of "enter them in the fields nearby" how about > "enter them in the corresponding fields"? Otherwise it's ACKed. Changed, pushed using trivial/one-liner rule > >> [PATCH] 732 webui: login screen - improved button switching >> >> - added cancel button to reset password view of login screen >> - re-implemented buttons hiding mechanism >> - switching between 'Reset Password' and 'Reset Password and Login' >> according to presence of value in OTP field >> >> https://fedorahosted.org/freeipa/ticket/4470 > > The code seems to be fine so it's ACKed, but see comments below: > > 1. It looks like the OTP token needs to be synchronized before it can be > used for the first time. Is that true for all types of tokens > (hardware/software, TOTP/HOTP)? If possible the synchronization should > be part of the token creation process, so the admin can provide a token > that can be used right away, so we may need an interface in the UI to > sync the tokens. If the sync can only be done by users themselves, there > should be a message on the login screen for first time OTP users to > synchronize the token first. Synchronization right away won't hurt but it's not always required. TOTP works for me if the device has properly synchronized time. I haven't noticed any sync issue with HOTP. Synchronization right from the UI is covered by: https://fedorahosted.org/freeipa/ticket/4365 https://fedorahosted.org/freeipa/ticket/4366 > > 2. Try logging in with an incorrect password/OTP. After you get a login > error click Sync OTP Token. Once the sync is completed it will go back > to the login page with a "Token was synchronized" message that > disappears in a few seconds, but the old login error still appears which > is confusing. Error messages in the UI should only reflect the last > executed operation. I'll fix it in separate patch. > > -- > Endi S. Dewata Pushed to: master: * a94fc09b5747ff5ffc632d95b330470ed78ee0f5 webui: display expired session notification in a more visible area * cba5247f99bca6eb8ed73b73f20cb9e9b3a45e91 webui: improved info msgs on login/token sync/reset pwd pages * 4832f2986d1a457acf3ff000433aa0732364c19c webui: login screen - improved button switching ipa-4-1: * 6f8dc9dba488caba7be2afc17b9e2b5191ffa585 webui: display expired session notification in a more visible area * 68647276ed58cb46c64884c2944cbd90979faf79 webui: improved info msgs on login/token sync/reset pwd pages * b37854051d6afd3f57ce28d059105797d13f0c22 webui: login screen - improved button switching -- Petr Vobornik From rcritten at redhat.com Wed Aug 20 19:35:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 15:35:33 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1408383404.22256.15.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> Message-ID: <53F4F885.4020308@redhat.com> Ade Lee wrote: > On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote: >> On 08/14/2014 10:53 AM, Martin Kosek wrote: >>> On 08/13/2014 09:54 PM, Ade Lee wrote: >>>> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. >>>> DRM was really only used in docs/marketing, whereas KRA is all over the code. >>>> Soon, the code and the marketing/docs will match. >>>> >>>> The following patch changes all references to the DRM to KRA. >>>> so for example, you need to run ipa-kra-install etc. >>>> >>>> Please apply this on top of the previous patch. I'll go ahead and squash them >>>> before commit. >>>> >>>> Thanks, >>>> Ade >>> >>> Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to >>> KRA and assigned respective tickets to that. Let us use the KRA term for the >>> Vault then. >>> >>> Martin >>> >> >> ipa_drm_install.py: No newline at end of file >> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is >> ipa-drm-install (with hyphens) >> > fixed >> >> The error I got previously was when running ipa-kra-install on a replica >> that didn't have CA yet. It would be nice to provide a better message >> for this case. >> > agreed. the problem here was that the check to see whether a ca was > already installed locally was not working as expected. > > I have since added a new check - which should fail if a CA is not > installed locally. > >> >> On a replica with KRA, I get: >> $ sudo ipa-kra-install --uninstall >> Usage: ipa-kra-install [options] [replica_file] >> >> ipa-kra-install: error: Cannot uninstall. There is no KRA >> installed on this system. >> > > Not sure what happened there. With the latest code, that does not > appear to happen for me. Let me know if it recurs. > >> I tested the kra plugin with this Python script: >> >> from ipalib import api >> api.bootstrap(context='server', kra_host='localhost') >> api.finalize() >> api.Backend.kra.store_secret('test', 'tkey') >> >> which gives me: >> >> Traceback (most recent call last): >> File "", line 1, in >> File "ipaserver/plugins/dogtag.py", line 2012, in store_secret >> self._setup() >> File "ipaserver/plugins/dogtag.py", line 1965, in _setup >> connection = PKIConnection('https', self.kra_host, >> self.kra_port, 'kra') >> File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, >> in __init__ >> self.hostname + ':' + self.port + '/' + \ >> TypeError: coercing to Unicode: need string or buffer, int found >> >> >> Apparently, PKIConnection requires the port to be a string, but we pass >> an int. I'd consider this an issue in pki. >> > Agreed. I will open a ticket to fix it in pki. For now though, I have > cast to str(). > >> >> The kra_host='localhost' option to api.bootstrap is necessary because >> kra_host is not added to default.conf on install. How is this planned to >> work when the plugin is done? >> > I followed what was done for ca_host, but did not set the required > default in constants.py. Thats fixed, so this should work now. > > After discussion with Endi, I also removed some functions in dogtag.py > (the plugin) which basically just wrapped calls to the keyclient. There > is no need to do this wrapping and it is much more flexible for IPA code > to call the keyclient directly. Accordingly, I have added a method to > get the keyclient. Your test code would look like this now: > > from ipalib import api > from pki.key import KeyClient > api.bootstrap(context='server') > api.finalize() > keyclient = api.Backend.kra.get_keyclient() > keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') > > I added a couple of directives in the proxy file to allow it to progress > further and it now fails in trying to do the archive_key due to > authentication issues. > > It was never the intention of this patch to get the plugin completely > working though. That was the goal of a follow on patch being written by > Endi. This patch is already pretty long and touches a lot of code. I > propose we let Endi fix the above issue. > > I have squashed the drm-> kra changes and created just a single patch, > which is attached. This is the only patch needed. > > I'm also starting a new COPR build, just to be sure we all have the most > up-to-date dogtag build. It doesn't look like the --no-host-dns option is used anywhere. I'm kinda with Petr, I don't know that an uninstall option is needed. On a single master install I successfully did a kra install, uninstall, re-install, so maybe the issue that Petr saw was related to cloning. There is no man page for ipa-kra-install Functionally the KRA itself seems to be working ok. rob From alee at redhat.com Thu Aug 21 05:15:29 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 21 Aug 2014 01:15:29 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F4F885.4020308@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> Message-ID: <1408598129.20372.28.camel@aleeredhat.laptop> On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote: > Ade Lee wrote: > > On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote: > >> On 08/14/2014 10:53 AM, Martin Kosek wrote: > >>> On 08/13/2014 09:54 PM, Ade Lee wrote: > >>>> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. > >>>> DRM was really only used in docs/marketing, whereas KRA is all over the code. > >>>> Soon, the code and the marketing/docs will match. > >>>> > >>>> The following patch changes all references to the DRM to KRA. > >>>> so for example, you need to run ipa-kra-install etc. > >>>> > >>>> Please apply this on top of the previous patch. I'll go ahead and squash them > >>>> before commit. > >>>> > >>>> Thanks, > >>>> Ade > >>> > >>> Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to > >>> KRA and assigned respective tickets to that. Let us use the KRA term for the > >>> Vault then. > >>> > >>> Martin > >>> > >> > >> ipa_drm_install.py: No newline at end of file > >> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is > >> ipa-drm-install (with hyphens) > >> > > fixed > >> > >> The error I got previously was when running ipa-kra-install on a replica > >> that didn't have CA yet. It would be nice to provide a better message > >> for this case. > >> > > agreed. the problem here was that the check to see whether a ca was > > already installed locally was not working as expected. > > > > I have since added a new check - which should fail if a CA is not > > installed locally. > > > >> > >> On a replica with KRA, I get: > >> $ sudo ipa-kra-install --uninstall > >> Usage: ipa-kra-install [options] [replica_file] > >> > >> ipa-kra-install: error: Cannot uninstall. There is no KRA > >> installed on this system. > >> > > > > Not sure what happened there. With the latest code, that does not > > appear to happen for me. Let me know if it recurs. > > > >> I tested the kra plugin with this Python script: > >> > >> from ipalib import api > >> api.bootstrap(context='server', kra_host='localhost') > >> api.finalize() > >> api.Backend.kra.store_secret('test', 'tkey') > >> > >> which gives me: > >> > >> Traceback (most recent call last): > >> File "", line 1, in > >> File "ipaserver/plugins/dogtag.py", line 2012, in store_secret > >> self._setup() > >> File "ipaserver/plugins/dogtag.py", line 1965, in _setup > >> connection = PKIConnection('https', self.kra_host, > >> self.kra_port, 'kra') > >> File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, > >> in __init__ > >> self.hostname + ':' + self.port + '/' + \ > >> TypeError: coercing to Unicode: need string or buffer, int found > >> > >> > >> Apparently, PKIConnection requires the port to be a string, but we pass > >> an int. I'd consider this an issue in pki. > >> > > Agreed. I will open a ticket to fix it in pki. For now though, I have > > cast to str(). > > > >> > >> The kra_host='localhost' option to api.bootstrap is necessary because > >> kra_host is not added to default.conf on install. How is this planned to > >> work when the plugin is done? > >> > > I followed what was done for ca_host, but did not set the required > > default in constants.py. Thats fixed, so this should work now. > > > > After discussion with Endi, I also removed some functions in dogtag.py > > (the plugin) which basically just wrapped calls to the keyclient. There > > is no need to do this wrapping and it is much more flexible for IPA code > > to call the keyclient directly. Accordingly, I have added a method to > > get the keyclient. Your test code would look like this now: > > > > from ipalib import api > > from pki.key import KeyClient > > api.bootstrap(context='server') > > api.finalize() > > keyclient = api.Backend.kra.get_keyclient() > > keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') > > > > I added a couple of directives in the proxy file to allow it to progress > > further and it now fails in trying to do the archive_key due to > > authentication issues. > > Did some more investigation on this. It turns out that the problem is in the PEM file that is generated (/etc/httpd/aliad/agent.pem) There are in fact two problems. One is that the agent.pem that is available there is for the IPA RA agent, who is not an agent on the KRA. Also, it appears that the PEM file itself may have some weirdness in its format. The PEM file is generated by the code _generate_pem_file() in dogtag.py. That code will need to be re-examined and fixed. I would like to leave that task to Endi - as he needs to decide how/which agent will be used to communicate with the KRA. If you use a valid agent PEM, then the above test code works. Here is what I did: $ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes And then I ran the following without issues: from ipalib import api from pki.key import KeyClient api.bootstrap(context='server') api.finalize() keyclient = api.Backend.kra.get_keyclient() infos = keyclient.list_keys() for info in infos.key_infos: print "{0} {1}".format(info.client_key_id, info.key_url) keyclient.archive_key('test3', KeyClient.PASS_PHRASE_TYPE,'tkey') print keyclient.retrieve_key(1).data You can also use the pki cli utility (pki key ...) to confirm that the KRA is in fact operational. > > It was never the intention of this patch to get the plugin completely > > working though. That was the goal of a follow on patch being written by > > Endi. This patch is already pretty long and touches a lot of code. I > > propose we let Endi fix the above issue. > > > > I have squashed the drm-> kra changes and created just a single patch, > > which is attached. This is the only patch needed. > > > > I'm also starting a new COPR build, just to be sure we all have the most > > up-to-date dogtag build. > > It doesn't look like the --no-host-dns option is used anywhere. > removed in attached patch. > I'm kinda with Petr, I don't know that an uninstall option is needed. > On a single master install I successfully did a kra install, uninstall, > re-install, so maybe the issue that Petr saw was related to cloning. I investigated this error. The failure to reinstall on the clone is due to a bug in the way pkidestroy handles the kra connector configuration that is created on the CA. I have opened up a ticket to address this, and will try to fix this issue within the next week or two. Once this is fixed, installing/uninstalling on either a master or clone should work without issues. As a workaround till then, after uninstalling the master and clone KRAs, check the CS.cfg of the master/clone CA and remove any entries that start with ca.connector.KRA.* And of course, restart the CA. I propose leaving this in -- it basically works right now - except for the issue above. > > There is no man page for ipa-kra-install > Can I add this in a separate patch? > Functionally the KRA itself seems to be working ok. Attached is a patch with a few basic changes - mostly additional URLs needed to make sure the script above runs. Please apply on top of the big one previously attached. I'll squash before commit. > rob > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Some-additional-minor-changes.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 21 06:43:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Aug 2014 08:43:48 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <53F4C0A5.6030408@redhat.com> References: <53F4C0A5.6030408@redhat.com> Message-ID: <53F59524.3040506@redhat.com> On 20.8.2014 17:37, Martin Basti wrote: > + # dissallowed wildcard (RFC 4592) > + no_wildcard_rtypes = ['CNAME', 'DNAME', 'DS', 'NS'] NACK http://tools.ietf.org/html/rfc4592#section-4.3 doesn't forbid CNAME with wildcard owner name. This subsection is is just a "note" for implementers about proper wildcard handling. Sorry :-) -- Petr^2 Spacek From pviktori at redhat.com Thu Aug 21 07:52:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Aug 2014 09:52:24 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F4F885.4020308@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> Message-ID: <53F5A538.80404@redhat.com> On 08/20/2014 09:35 PM, Rob Crittenden wrote: [...] > I'm kinda with Petr, I don't know that an uninstall option is needed. > > On a single master install I successfully did a kra install, uninstall, > re-install, so maybe the issue that Petr saw was related to cloning. Yes, on a single master it works great. -- Petr? From pvoborni at redhat.com Thu Aug 21 08:49:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Aug 2014 10:49:03 +0200 Subject: [Freeipa-devel] [PATCH] 733-735 webui: Better description for User authentication types In-Reply-To: <53EB7385.8030108@redhat.com> References: <53E0C23D.2000109@redhat.com> <53EB7385.8030108@redhat.com> Message-ID: <53F5B27F.3080804@redhat.com> On 13.8.2014 16:17, Endi Sukma Dewata wrote: > On 8/5/2014 6:38 AM, Petr Vobornik wrote: >> [PATCH] 733 webui: rename tooltip to title >> >> - use title for input's elements 'title' attribute >> - tooltip for Bootstrap's tooltip component >> >> https://fedorahosted.org/freeipa/ticket/4471 > > ACK. > >> [PATCH] 734 webui: tooltip support >> >> Allow to set 'tooltip' attribute in spec. It displays info icon >> with Bootstrap's tooltip near field's label. >> >> https://fedorahosted.org/freeipa/ticket/4471 > > ACK. > >> [PATCH] 735 webui: better authentication types description >> >> Tooltips were added to "User authentication types" and "Default user >> objectclasses" to describe their relationship and a meaning of >> not-setting a value. >> >> https://fedorahosted.org/freeipa/ticket/4471 > > Just one thing, in the patch comment you probably meant "Default user > authentication types". ACK. > Yes, comment amended. Pushed to: master: * def8696819e923bc7126af54bcd9f1452de30dcd webui: rename tooltip to title * 19bef5bd01b2490e11ffaead12066c2ad0e0e885 webui: tooltip support * 27128bd8f50cebb8fc3b8a86b642ca0e272d2024 webui: better authentication types description ipa-4-1: * 9554b5109c191df23872d4ca7f2fa29787df70f4 webui: rename tooltip to title * c1290a768c6105045e7acae2cd13a9228a7d5f41 webui: tooltip support * af83c37ef1311dca744f3775c5301d09e2ce61c6 webui: better authentication types description -- Petr Vobornik From mbasti at redhat.com Thu Aug 21 08:58:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Aug 2014 10:58:49 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <53F59524.3040506@redhat.com> References: <53F4C0A5.6030408@redhat.com> <53F59524.3040506@redhat.com> Message-ID: <53F5B4C9.3060708@redhat.com> On 21/08/14 08:43, Petr Spacek wrote: > On 20.8.2014 17:37, Martin Basti wrote: >> + # dissallowed wildcard (RFC 4592) >> + no_wildcard_rtypes = ['CNAME', 'DNAME', 'DS', 'NS'] > NACK > > http://tools.ietf.org/html/rfc4592#section-4.3 doesn't forbid CNAME > with wildcard owner name. This subsection is is just a "note" for > implementers about proper wildcard handling. > > Sorry :-) > Thank you! Updated patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0107.2-FIX-DNS-wildcard-records-RFC4592.patch Type: text/x-patch Size: 2390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0108.2-Tests-DNS-wildcard-records.patch Type: text/x-patch Size: 3886 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 21 09:10:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Aug 2014 11:10:21 +0200 Subject: [Freeipa-devel] [PATCH 0030][DOC] Chapter 1 and 2 updates to documentation In-Reply-To: References: <53E8744E.5080501@redhat.com> Message-ID: <53F5B77D.8050900@redhat.com> On 08/11/2014 03:28 PM, Gabe Alford wrote: > Thanks, Petr. > > What is the project's preference here as far as (if they were correct) > having documentation flow from RHEL to the Fedora docs? It seems to me > that really the upstream should be Freeipa Docs that flows into RHEL > docs (with mods for RH needs)? Hello, The preference is that the upstream FreeIPA docs flow into RHEL, yes. -- Petr? From abokovoy at redhat.com Thu Aug 21 10:43:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 Aug 2014 13:43:35 +0300 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations Message-ID: <20140821104335.GX4748@redhat.com> Hi! Attached patchset improves trust operations: 1. Ensures we only allow establishing trust to forest root domain 2. Ensures that we select primary domain controllers 3. Ensures first create trust and later set it to transitive state and update forest topology 4. Relaxes filtering of domains obtained from AD side to allow some of possible topology combinations which were not accounted for previously 5. Reverts to any PDC rather than a closest one if closest one is not available due to site mismanagement. Affected tickets: https://fedorahosted.org/freeipa/ticket/4463 https://fedorahosted.org/freeipa/ticket/4479 https://fedorahosted.org/freeipa/ticket/4458 The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 branches). They were tested with Windows Server 2008R2 and Windows Server 2012 environments. -- / Alexander Bokovoy -------------- next part -------------- From 18b27e8363799070cce57ab393787c99fa7ebc77 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 19 Aug 2014 16:19:45 +0300 Subject: [PATCH 1/5] ipaserver/dcerpc.py: if search of a closest GC failed, try to find any GC https://fedorahosted.org/freeipa/ticket/4458 --- ipaserver/dcerpc.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index f1c7508..b11476a 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -588,7 +588,11 @@ class DomainValidator(object): try: result = netrc.finddc(domain=domain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_GC | nbt.NBT_SERVER_CLOSEST) except RuntimeError, e: - finddc_error = e + try: + # If search of closest GC failed, attempt to find any one + result = netrc.finddc(domain=domain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_GC) + except RuntimeError, e: + finddc_error = e if not self._domains: self._domains = self.get_trusted_domains() -- 1.9.3 -------------- next part -------------- From 96e5022a65798f4f4961ea904ce639ffe4477dc1 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 19 Aug 2014 16:21:21 +0300 Subject: [PATCH 2/5] ipaserver/dcerpc.py: make PDC discovery more robust Certain operations against AD domain controller can only be done if its FSMO role is primary domain controller. We need to use writable DC and PDC when creating trust and updating name suffix routing information. https://fedorahosted.org/freeipa/ticket/4479 --- ipaserver/dcerpc.py | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index b11476a..78bfc5d 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -706,16 +706,19 @@ class TrustDomainInstance(object): binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] - def retrieve_anonymously(self, remote_host, discover_srv=False): + def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): """ When retrieving DC information anonymously, we can't get SID of the domain """ netrc = net.Net(creds=self.creds, lp=self.parm) + flags = nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS | nbt.NBT_SERVER_WRITABLE + if search_pdc: + flags = flags | nbt.NBT_SERVER_PDC try: if discover_srv: - result = netrc.finddc(domain=remote_host, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + result = netrc.finddc(domain=remote_host, flags=flags) else: - result = netrc.finddc(address=remote_host, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + result = netrc.finddc(address=remote_host, flags=flags) except RuntimeError, e: raise assess_dcerpc_exception(message=str(e)) @@ -726,6 +729,7 @@ class TrustDomainInstance(object): self.info['dns_forest'] = unicode(result.forest) self.info['guid'] = unicode(result.domain_uuid) self.info['dc'] = unicode(result.pdc_dns_name) + self.info['is_pdc'] = (result.server_type & nbt.NBT_SERVER_PDC) != 0 # Netlogon response doesn't contain SID of the domain. # We need to do rootDSE search with LDAP_SERVER_EXTENDED_DN_OID control to reveal the SID @@ -774,6 +778,13 @@ class TrustDomainInstance(object): self.info['sid'] = unicode(result.sid) self.info['dc'] = remote_host + try: + result = self._pipe.QueryInfoPolicy2(self._policy_handle, lsa.LSA_POLICY_INFO_ROLE) + except RuntimeError, (num, message): + raise assess_dcerpc_exception(num=num, message=message) + + self.info['is_pdc'] = (result.role == lsa.LSA_ROLE_PRIMARY) + def generate_auth(self, trustdom_secret): def arcfour_encrypt(key, data): c = RC4.RC4(key) @@ -1069,9 +1080,9 @@ class TrustDomainJoins(object): rd.creds.set_anonymous() rd.creds.set_workstation(self.local_domain.hostname) if realm_server is None: - rd.retrieve_anonymously(realm, discover_srv=True) + rd.retrieve_anonymously(realm, discover_srv=True, search_pdc=True) else: - rd.retrieve_anonymously(realm_server, discover_srv=False) + rd.retrieve_anonymously(realm_server, discover_srv=False, search_pdc=True) rd.read_only = True if realm_admin and realm_passwd: if 'name' in rd.info: -- 1.9.3 -------------- next part -------------- From 29248c0cfcf7885f66b0d001bcbe693b3eb285f0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 19 Aug 2014 16:22:54 +0300 Subject: [PATCH 3/5] ipaserver/dcerpc.py: Avoid hitting issue with transitive trusts on Windows Server prior to 2012 http://msdn.microsoft.com/en-us/library/2a769a08-e023-459f-aebe-4fb3f595c0b7#id83 --- ipaserver/dcerpc.py | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 78bfc5d..3adac8b 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -900,7 +900,7 @@ class TrustDomainInstance(object): info.sid = security.dom_sid(another_domain.info['sid']) info.trust_direction = lsa.LSA_TRUST_DIRECTION_INBOUND | lsa.LSA_TRUST_DIRECTION_OUTBOUND info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL - info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE + info.trust_attributes = 0 try: dname = lsa.String() @@ -917,8 +917,6 @@ class TrustDomainInstance(object): except RuntimeError, (num, message): raise assess_dcerpc_exception(num=num, message=message) - self.update_ftinfo(another_domain) - # We should use proper trustdom handle in order to modify the # trust settings. Samba insists this has to be done with LSA # OpenTrustedDomain* calls, it is not enough to have a handle @@ -937,6 +935,15 @@ class TrustDomainInstance(object): # server as that one doesn't support AES encryption types pass + try: + info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE + self._pipe.SetInformationTrustedDomain(trustdom_handle, lsa.LSA_TRUSTED_DOMAIN_INFO_INFO_EX, info) + except RuntimeError, e: + root_logger.error('unable to set trust to transitive: %s' % (str(e))) + pass + if self.info['is_pdc']: + self.update_ftinfo(another_domain) + def verify_trust(self, another_domain): def retrieve_netlogon_info_2(domain, function_code, data): try: -- 1.9.3 -------------- next part -------------- From 33521446e4344d5f7c80d70ed5907f75fcce2b65 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 19 Aug 2014 16:23:58 +0300 Subject: [PATCH 4/5] ipaserver/dcerpc.py: be more open to what domains can be seen through the forest trust https://fedorahosted.org/freeipa/ticket/4463 --- ipaserver/dcerpc.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 3adac8b..118b657 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1038,7 +1038,7 @@ def fetch_domains(api, mydomain, trustdomain, creds=None): result = [] for t in domains.array: - if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + if (not (t.trust_flags & trust_flags['NETR_TRUST_FLAG_PRIMARY']) and (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): res = dict() res['cn'] = unicode(t.dns_name) -- 1.9.3 -------------- next part -------------- From 64b6d18522bb3b9c4bb61075d36362ba7b6e24ca Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 19 Aug 2014 16:24:27 +0300 Subject: [PATCH 5/5] ipaserver/dcerpc.py: Make sure trust is established only to forest root domain Part of https://fedorahosted.org/freeipa/ticket/4463 --- ipalib/errors.py | 16 ++++++++++++++++ ipaserver/dcerpc.py | 6 ++++++ 2 files changed, 22 insertions(+) diff --git a/ipalib/errors.py b/ipalib/errors.py index 716decb..405c5c3 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -810,6 +810,22 @@ class DeprecationError(InvocationError): errno = 3015 format = _("Command '%(name)s' has been deprecated") +class NotAForestRootError(InvocationError): + """ + **3016** Raised when an attempt to establish trust is done against non-root domain + Forest root domain has the same name as the forest itself + + For example: + + >>> raise NotAForestRootError(forest='example.test', domain='jointops.test') + Traceback (most recent call last): + ... + NotAForestRootError: Domain 'jointops.test' is not a root domain for forest 'example.test' + """ + + errno = 3016 + format = _("Domain '%(domain)s' is not a root domain for forest '%(forest)s'") + ############################################################################## # 4000 - 4999: Execution errors diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 118b657..e779a12 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1150,6 +1150,9 @@ class TrustDomainJoins(object): realm_passwd ) + if self.remote_domain.info['dns_domain'] != self.remote_domain.info['dns_forest']: + raise errors.NotAForestRootError(forest=self.remote_domain.info['dns_forest'], domain=self.remote_domain.info['dns_domain']) + if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) self.get_realmdomains() @@ -1166,5 +1169,8 @@ class TrustDomainJoins(object): if not(isinstance(self.remote_domain, TrustDomainInstance)): self.populate_remote_domain(realm, realm_server, realm_passwd=None) + if self.remote_domain.info['dns_domain'] != self.remote_domain.info['dns_forest']: + raise errors.NotAForestRootError(forest=self.remote_domain.info['dns_forest'], domain=self.remote_domain.info['dns_domain']) + self.local_domain.establish_trust(self.remote_domain, trustdom_passwd) return dict(local=self.local_domain, remote=self.remote_domain, verified=False) -- 1.9.3 From pvoborni at redhat.com Thu Aug 21 12:11:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Aug 2014 14:11:14 +0200 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53EB824E.6030001@redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> Message-ID: <53F5E1E2.7080800@redhat.com> On 13.8.2014 17:20, Endi Sukma Dewata wrote: > On 8/5/2014 6:43 AM, Petr Vobornik wrote: >> [PATCH] 736 webui: convert widget.less indentation to spaces > > ACK. > >> [PATCH] 737 webui: improve rule table css >> >> - category radio line has line-height large enough to contain >> undo button -> content doesn't move several pixels on change >> - remove vertical padding from btns in table headers to maintain >> about the same height >> - remove invisible border from link buttons to have the same height >> for disabled and enabled button > > ACK. > >> [PATCH] 738 webui: sshkey widget - usability fixes >> >> - save one click by opening edit dialog right after adding new row >> - add margin between fingerprint and "show/edit" button >> - fix honoring of writable/read-only flags upon row creation > > ACK. Possible improvements: > > 1. How about removing the row if the user cancels the addition or enters > blank value? That way the rows will always have values, so we don't need > the "New: key set/not set" labels anymore. Good idea. > > 2. Can the UI parse the new key and display it the same way as other > keys that are already saved? That will make it more seamless. Would be nice, but is it worth the effort? We would have to reimplement ipapython.ssh into JavaScript + pull in crypto.js or other lib for sha1 and sha256 functions since Web Cryptography API is still only a draft [1]. [1] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > > 3. If we do #2, the "Show/Set key" button probably can be changed to > Edit or Modify. > >> [PATCH] 739 webui: disable batch action buttons by default >> >> action buttons associated with batch actions were enabled by default, >> but they were disabled right after facet creation and a load of data. >> It caused a visual flicker. >> >> UX is enhanced by making them disabled by default. > > ACK. > >> [PATCH] 740 webui: fix group type padding > > ACK. > Pushed to: ipa-4-1: * 500db900e578bc87bb95fef53ac8abff9ca47e4b webui: convert widget.less indentation to spaces * 189f6fdfd539486cf49e114cf5d0ebf9fb6bee6e webui: improve rule table css * a8a799822c4f1f3b17ac2b86ef8cf84a4a781d9e webui: sshkey widget - usability fixes * dd45278e5aeb4fbb4b7f567ee6e6dda079afb728 webui: disable batch action buttons by default * 2752f8e286074c210d3229ae94871afbfdc99f7f webui: fix group type padding master: * 8f73bf3713da42bfe6503ef2afbe4a6de3bf44d0 webui: convert widget.less indentation to spaces * 356059e07ddb492aa9d6b63ee806ae804afbec40 webui: improve rule table css * d138b44480dfef3220e0a39bef9c064a314ee6bf webui: sshkey widget - usability fixes * 9446c4c8b4bc397c6c2d1d94725f7aae4b123b5f webui: disable batch action buttons by default * 981b399c4e6938b4ab096dee9411cb025e221703 webui: fix group type padding -- Petr Vobornik From simo at redhat.com Thu Aug 21 12:18:54 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 21 Aug 2014 08:18:54 -0400 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53F5E1E2.7080800@redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> Message-ID: <1408623534.7908.23.camel@willson.usersys.redhat.com> On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: > > Would be nice, but is it worth the effort? We would have to > reimplement ipapython.ssh into JavaScript + pull in crypto.js or other > lib for sha1and sha256 functions since Web Cryptography API is still > only a draft [1]. I do not do this lightly, but you have my veto to do any crypto in javascript unless you convince me first it make sense. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Aug 21 12:33:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Aug 2014 14:33:05 +0200 Subject: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals In-Reply-To: <53F4C821.9060509@redhat.com> References: <53F334EC.2030009@redhat.com> <53F337E2.7010702@redhat.com> <53F38E0C.3060703@redhat.com> <53F4636B.4000409@redhat.com> <53F4C821.9060509@redhat.com> Message-ID: <53F5E701.1010709@redhat.com> On 08/20/2014 06:09 PM, Petr Viktorin wrote: > On 08/20/2014 10:59 AM, Martin Kosek wrote: >> On 08/19/2014 07:49 PM, Petr Viktorin wrote: >>> On 08/19/2014 01:41 PM, Martin Kosek wrote: >>>> On 08/19/2014 01:28 PM, Petr Viktorin wrote: >>>>> Services can now be added to roles. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3164 >>>>> >>>>> >>>>> I added a new integration test for checking that a service can actually >>>>> use the >>>>> right granted by a role. I don't think there's a good way to do this kind of >>>>> thing in our Declarative test suite. >>>> >>>> 1) I think you also need to update service object's attribute_members so that >>>> it can properly show role membership. >>> >>> Right, added (with tests). >> >> Thanks! (especially for the tests) >> >> I am thinking about one usability improvement. All over the code, we allow to >> specify services without the REALM as the realm is pretty clear and we do not >> need it from the user: >> >> # ipa service-add test/`hostname` >> ------------------------------------------------------------------ >> Added service "test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST" >> ------------------------------------------------------------------ >> Principal: test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >> Managed by: ipa.mkosek-fedora20.test >> >> However, the new --services option does not allow that: >> >> ]# ipa role-add-member foo --services test/`hostname` >> Role name: foo >> Description: foo >> Failed members: >> member user: >> member group: >> member host: >> member host group: >> member service: test/ipa.mkosek-fedora20.test: no such entry >> ------------------------- >> Number of members added 0 >> ------------------------- >> >> Could we just add the realm if it does not exists in the service-add-member >> precallback? > > Looks like we want to add it any time we look up a service, right? > This additional patch should do that. Right. This approach works for me, ACK on both. Pushed to: master: a8ba6b3b8cdaf39152bce394ad419d28037f687e ipa-4-1: e49768864f5fd735f9f30241b22c595908b762af Martin From redhatrises at gmail.com Thu Aug 21 12:50:34 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 21 Aug 2014 06:50:34 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> <53DA423B.2050607@redhat.com> Message-ID: Hello, Just wondering if this needs to be re-ack'd. Thanks, Gabe On Thu, Jul 31, 2014 at 7:57 AM, Gabe Alford wrote: > Okay. Sounds good. Update patch attached. > > > On Thu, Jul 31, 2014 at 7:18 AM, Martin Kosek wrote: > >> Ah, right. But I still think that's a too-early optimization. We can add >> this >> callback when this necessity arises. Until then, I would rather prefer to >> keep >> the code clean. >> >> Martin >> >> On 07/31/2014 03:17 PM, Gabe Alford wrote: >> > Right. The reason I added it in there is that I could see that in the >> > future trust_type could be more than just 'ad' (maybe 'ipa', 'krb', >> etc?) >> > which at that point I'm not sure a default makes sense. So, I thought >> to go >> > ahead and add the check for future use cases so that it doesn't have to >> be >> > remembered later. However, maybe that was just a bad idea as right now >> it >> > is a pointless check? >> > >> > Gabe >> > >> > >> > On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy > > >> > wrote: >> > >> >> On Thu, 31 Jul 2014, Martin Kosek wrote: >> >> >> >>> Sorry for going late in the game, just a quick question - why do we >> want >> >>> to add >> >>> this part: >> >>> >> >>> + if trust_type is None: >> >>> + kw['trust_type'] = self.prompt_param(self.params[ >> >>> 'trust_type']) >> >>> >> >>> ? I do not see a reason for adding a special interactive prompt >> callback >> >>> for >> >>> that - trust_type has a default value "ad". CCing Alexander to double >> >>> check. >> >>> >> >> I also don't understand why you need to ask interactively for the >> >> trust_type as it defaults to non-empty value and this value is the only >> >> one we currently support. >> >> >> >> >> >> -- >> >> / Alexander Bokovoy >> >> >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- From 3fc52b8fec42a294f0e95f0bd8bcc2f1e0958ed3 Mon Sep 17 00:00:00 2001 From: Gabe Date: Thu, 31 Jul 2014 07:26:00 -0600 Subject: [PATCH] ipa trust-add command should be interactive - Make ipa trust-add command interactive for realm_admin and realm_passwd - Fix 'Active directory' typo to 'Active Directory' https://fedorahosted.org/freeipa/ticket/3034 --- ipalib/plugins/trust.py | 26 +++++++++++++++++++++++++- 1 files changed, 25 insertions(+), 1 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index fe1a76719b0e35136fb46d917bd998cdfd631695..736cb6f573f9a18eca882db136133205c583b67d 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -435,7 +435,7 @@ sides. ), Password('realm_passwd?', cli_name='password', - label=_("Active directory domain administrator's password"), + label=_("Active Directory domain administrator's password"), confirm=False, ), Str('realm_server?', @@ -511,6 +511,30 @@ sides. return result + def interactive_prompt_callback(self, kw): + """ + Also ensure that realm_admin is prompted for if --admin or + --trust-secret is not specified when 'ipa trust-add' is run on the + system. + + Also ensure that realm_passwd is prompted for if --password or + --trust-secret is not specified when 'ipa trust-add' is run on the + system. + """ + + trust_secret = kw.get('trust_secret') + realm_admin = kw.get('realm_admin') + realm_passwd = kw.get('realm_passwd') + + if trust_secret is None: + if realm_admin is None: + kw['realm_admin'] = self.prompt_param( + self.params['realm_admin']) + + if realm_passwd is None: + kw['realm_passwd'] = self.Backend.textui.prompt_password( + self.params['realm_passwd'].label, confirm=False) + def validate_options(self, *keys, **options): if not _bindings_installed: raise errors.NotFound( -- 1.7.1 From alee at redhat.com Thu Aug 21 13:48:07 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 21 Aug 2014 09:48:07 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1408598129.20372.28.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> Message-ID: <1408628887.30166.1.camel@aleeredhat.laptop> As agreed on #irc, disabling uninstallation for now. Please apply this new patch on top of the big one. Ade On Thu, 2014-08-21 at 01:15 -0400, Ade Lee wrote: > On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote: > > Ade Lee wrote: > > > On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote: > > >> On 08/14/2014 10:53 AM, Martin Kosek wrote: > > >>> On 08/13/2014 09:54 PM, Ade Lee wrote: > > >>>> In Dogtag, we have decided to revert the name of the DRM to the old name KRA. > > >>>> DRM was really only used in docs/marketing, whereas KRA is all over the code. > > >>>> Soon, the code and the marketing/docs will match. > > >>>> > > >>>> The following patch changes all references to the DRM to KRA. > > >>>> so for example, you need to run ipa-kra-install etc. > > >>>> > > >>>> Please apply this on top of the previous patch. I'll go ahead and squash them > > >>>> before commit. > > >>>> > > >>>> Thanks, > > >>>> Ade > > >>> > > >>> Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to > > >>> KRA and assigned respective tickets to that. Let us use the KRA term for the > > >>> Vault then. > > >>> > > >>> Martin > > >>> > > >> > > >> ipa_drm_install.py: No newline at end of file > > >> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is > > >> ipa-drm-install (with hyphens) > > >> > > > fixed > > >> > > >> The error I got previously was when running ipa-kra-install on a replica > > >> that didn't have CA yet. It would be nice to provide a better message > > >> for this case. > > >> > > > agreed. the problem here was that the check to see whether a ca was > > > already installed locally was not working as expected. > > > > > > I have since added a new check - which should fail if a CA is not > > > installed locally. > > > > > >> > > >> On a replica with KRA, I get: > > >> $ sudo ipa-kra-install --uninstall > > >> Usage: ipa-kra-install [options] [replica_file] > > >> > > >> ipa-kra-install: error: Cannot uninstall. There is no KRA > > >> installed on this system. > > >> > > > > > > Not sure what happened there. With the latest code, that does not > > > appear to happen for me. Let me know if it recurs. > > > > > >> I tested the kra plugin with this Python script: > > >> > > >> from ipalib import api > > >> api.bootstrap(context='server', kra_host='localhost') > > >> api.finalize() > > >> api.Backend.kra.store_secret('test', 'tkey') > > >> > > >> which gives me: > > >> > > >> Traceback (most recent call last): > > >> File "", line 1, in > > >> File "ipaserver/plugins/dogtag.py", line 2012, in store_secret > > >> self._setup() > > >> File "ipaserver/plugins/dogtag.py", line 1965, in _setup > > >> connection = PKIConnection('https', self.kra_host, > > >> self.kra_port, 'kra') > > >> File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, > > >> in __init__ > > >> self.hostname + ':' + self.port + '/' + \ > > >> TypeError: coercing to Unicode: need string or buffer, int found > > >> > > >> > > >> Apparently, PKIConnection requires the port to be a string, but we pass > > >> an int. I'd consider this an issue in pki. > > >> > > > Agreed. I will open a ticket to fix it in pki. For now though, I have > > > cast to str(). > > > > > >> > > >> The kra_host='localhost' option to api.bootstrap is necessary because > > >> kra_host is not added to default.conf on install. How is this planned to > > >> work when the plugin is done? > > >> > > > I followed what was done for ca_host, but did not set the required > > > default in constants.py. Thats fixed, so this should work now. > > > > > > After discussion with Endi, I also removed some functions in dogtag.py > > > (the plugin) which basically just wrapped calls to the keyclient. There > > > is no need to do this wrapping and it is much more flexible for IPA code > > > to call the keyclient directly. Accordingly, I have added a method to > > > get the keyclient. Your test code would look like this now: > > > > > > from ipalib import api > > > from pki.key import KeyClient > > > api.bootstrap(context='server') > > > api.finalize() > > > keyclient = api.Backend.kra.get_keyclient() > > > keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey') > > > > > > I added a couple of directives in the proxy file to allow it to progress > > > further and it now fails in trying to do the archive_key due to > > > authentication issues. > > > > Did some more investigation on this. It turns out that the problem is > in the PEM file that is generated (/etc/httpd/aliad/agent.pem) > > There are in fact two problems. One is that the agent.pem that is > available there is for the IPA RA agent, who is not an agent on the KRA. > Also, it appears that the PEM file itself may have some weirdness in its > format. > > The PEM file is generated by the code _generate_pem_file() in dogtag.py. > That code will need to be re-examined and fixed. I would like to leave > that task to Endi - as he needs to decide how/which agent will be used > to communicate with the KRA. > > If you use a valid agent PEM, then the above test code works. > > Here is what I did: > $ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes > > And then I ran the following without issues: > > from ipalib import api > from pki.key import KeyClient > api.bootstrap(context='server') > api.finalize() > keyclient = api.Backend.kra.get_keyclient() > > infos = keyclient.list_keys() > for info in infos.key_infos: > print "{0} {1}".format(info.client_key_id, info.key_url) > > keyclient.archive_key('test3', KeyClient.PASS_PHRASE_TYPE,'tkey') > print keyclient.retrieve_key(1).data > > You can also use the pki cli utility (pki key ...) to confirm that the > KRA is in fact operational. > > > > It was never the intention of this patch to get the plugin completely > > > working though. That was the goal of a follow on patch being written by > > > Endi. This patch is already pretty long and touches a lot of code. I > > > propose we let Endi fix the above issue. > > > > > > I have squashed the drm-> kra changes and created just a single patch, > > > which is attached. This is the only patch needed. > > > > > > I'm also starting a new COPR build, just to be sure we all have the most > > > up-to-date dogtag build. > > > > It doesn't look like the --no-host-dns option is used anywhere. > > > > removed in attached patch. > > > I'm kinda with Petr, I don't know that an uninstall option is needed. > > > On a single master install I successfully did a kra install, uninstall, > > re-install, so maybe the issue that Petr saw was related to cloning. > > I investigated this error. The failure to reinstall on the clone is due > to a bug in the way pkidestroy handles the kra connector configuration > that is created on the CA. I have opened up a ticket to address this, > and will try to fix this issue within the next week or two. > > Once this is fixed, installing/uninstalling on either a master or clone > should work without issues. > > As a workaround till then, after uninstalling the master and clone KRAs, > check the CS.cfg of the master/clone CA and remove any entries that > start with ca.connector.KRA.* And of course, restart the CA. > > I propose leaving this in -- it basically works right now - except for > the issue above. > > > > There is no man page for ipa-kra-install > > > Can I add this in a separate patch? > > > Functionally the KRA itself seems to be working ok. > > Attached is a patch with a few basic changes - mostly additional URLs > needed to make sure the script above runs. Please apply on top of the > big one previously attached. I'll squash before commit. > > > rob > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-1-Some-additional-minor-changes.patch Type: text/x-patch Size: 3785 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 21 15:27:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Aug 2014 17:27:50 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1408628887.30166.1.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> Message-ID: <53F60FF6.3060203@redhat.com> On 08/21/2014 03:48 PM, Ade Lee wrote: > As agreed on #irc, disabling uninstallation for now. > Please apply this new patch on top of the big one. I'm fine with pushing a patch with incomplete functionality, after all I did this all the time with permissions. The incomplete parts (apart from the plugin which is entirely out of scope) are: - The agent PEM issue (will be sorted out as the plugin is implemented) - Missing man page (will be written before the plugin is implemented) - Uninstall (will be fixed on Dogtag side, re-tested and enabled) I'll open tickets for these before pushing. ACK from me if Rob agrees. On IRC, Rob said he'd rather delay pushing until the man page is written, but delegated the decision to Martin. So, Martin, can we push now and trust Ade's promise that he'll write the docs? -- Petr? From pvoborni at redhat.com Thu Aug 21 16:06:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Aug 2014 18:06:33 +0200 Subject: [Freeipa-devel] [PATCH] 742 webui: adjust behavior of bounce url Message-ID: <53F61909.4070402@redhat.com> based on: http://www.redhat.com/archives/freeipa-devel/2014-August/msg00073.html - bounce url param was renamed from 'redirect' to 'url' - support for 'delay' param added Behavior: - "Continue to next page" link is shown if 'url' is present - page is no longer automatically redirected if 'url' is present - automatic redirect is controlled by 'delay' param - it specifies number of seconds until redirection - info message 'You will be redirected in Xs' is show to notify the user that something will happen. It's useful even if delay is 0 or negative because redirection might be slow. - counter is decremented every second - delay is ignored if parsed as NaN https://fedorahosted.org/freeipa/ticket/4440 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0742-webui-adjust-behavior-of-bounce-url.patch Type: text/x-patch Size: 3543 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 21 17:21:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Aug 2014 19:21:17 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation Message-ID: <53F62A8D.30303@redhat.com> During work on DNSSEC we found a wrong validation of NS records Patch 0113 fixes an error in tests caused by bind-dyndb-ldap bug https://fedorahosted.org/bind-dyndb-ldap/ticket/123 Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0111-DNS-fix-NS-record-coexistence-validator.patch Type: text/x-patch Size: 2484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0112-Test-DNS-NS-validation.patch Type: text/x-patch Size: 4260 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0113-Fix-DNS-record-rename-test.patch Type: text/x-patch Size: 3661 bytes Desc: not available URL: From mkosek at redhat.com Thu Aug 21 19:52:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Aug 2014 21:52:54 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F60FF6.3060203@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> Message-ID: <53F64E16.3040308@redhat.com> On 08/21/2014 05:27 PM, Petr Viktorin wrote: > On 08/21/2014 03:48 PM, Ade Lee wrote: >> As agreed on #irc, disabling uninstallation for now. >> Please apply this new patch on top of the big one. > > > I'm fine with pushing a patch with incomplete functionality, after all I did > this all the time with permissions. > > The incomplete parts (apart from the plugin which is entirely out of scope) are: > - The agent PEM issue (will be sorted out as the plugin is implemented) > - Missing man page (will be written before the plugin is implemented) > - Uninstall (will be fixed on Dogtag side, re-tested and enabled) > > I'll open tickets for these before pushing. > > ACK from me if Rob agrees. On IRC, Rob said he'd rather delay pushing until the > man page is written, but delegated the decision to Martin. > So, Martin, can we push now and trust Ade's promise that he'll write the docs? Yes, if you open ticket(s) for all missing parts and put them in the same milestone. I would rather have the patches in than waiting for man page and then have a conflict and postpone the patch set. I trust Ade to provide the man page later, I am sure he does not want to meet with my whip otherwise :-) Martin From alee at redhat.com Thu Aug 21 20:53:06 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 21 Aug 2014 16:53:06 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F64E16.3040308@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> <53F64E16.3040308@redhat.com> Message-ID: <1408654386.2886.3.camel@aleeredhat.laptop> On Thu, 2014-08-21 at 21:52 +0200, Martin Kosek wrote: > On 08/21/2014 05:27 PM, Petr Viktorin wrote: > > On 08/21/2014 03:48 PM, Ade Lee wrote: > >> As agreed on #irc, disabling uninstallation for now. > >> Please apply this new patch on top of the big one. > > > > > > I'm fine with pushing a patch with incomplete functionality, after all I did > > this all the time with permissions. > > > > The incomplete parts (apart from the plugin which is entirely out of scope) are: > > - The agent PEM issue (will be sorted out as the plugin is implemented) > > - Missing man page (will be written before the plugin is implemented) > > - Uninstall (will be fixed on Dogtag side, re-tested and enabled) > > > > I'll open tickets for these before pushing. > > > > ACK from me if Rob agrees. On IRC, Rob said he'd rather delay pushing until the > > man page is written, but delegated the decision to Martin. > > So, Martin, can we push now and trust Ade's promise that he'll write the docs? > > Yes, if you open ticket(s) for all missing parts and put them in the same > milestone. I would rather have the patches in than waiting for man page and > then have a conflict and postpone the patch set. > > I trust Ade to provide the man page later, I am sure he does not want to meet > with my whip otherwise :-) > Perfect, thanks! I don't have commit rights, so please commit the patches for me. Ade > Martin From pviktori at redhat.com Fri Aug 22 08:03:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Aug 2014 10:03:30 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1408654386.2886.3.camel@aleeredhat.laptop> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> <53F64E16.3040308@redhat.com> <1408654386.2886.3.camel@aleeredhat.laptop> Message-ID: <53F6F952.8020307@redhat.com> On 08/21/2014 10:53 PM, Ade Lee wrote: > On Thu, 2014-08-21 at 21:52 +0200, Martin Kosek wrote: >> On 08/21/2014 05:27 PM, Petr Viktorin wrote: >>> On 08/21/2014 03:48 PM, Ade Lee wrote: >>>> As agreed on #irc, disabling uninstallation for now. >>>> Please apply this new patch on top of the big one. >>> >>> >>> I'm fine with pushing a patch with incomplete functionality, after all I did >>> this all the time with permissions. >>> >>> The incomplete parts (apart from the plugin which is entirely out of scope) are: >>> - The agent PEM issue (will be sorted out as the plugin is implemented) https://fedorahosted.org/freeipa/ticket/4503 >>> - Missing man page (will be written before the plugin is implemented) https://fedorahosted.org/freeipa/ticket/4504 >>> - Uninstall (will be fixed on Dogtag side, re-tested and enabled) https://fedorahosted.org/freeipa/ticket/4505 >>> >>> I'll open tickets for these before pushing. >>> >>> ACK from me if Rob agrees. On IRC, Rob said he'd rather delay pushing until the >>> man page is written, but delegated the decision to Martin. >>> So, Martin, can we push now and trust Ade's promise that he'll write the docs? >> >> Yes, if you open ticket(s) for all missing parts and put them in the same >> milestone. I would rather have the patches in than waiting for man page and >> then have a conflict and postpone the patch set. >> >> I trust Ade to provide the man page later, I am sure he does not want to meet >> with my whip otherwise :-) >> > > Perfect, thanks! I don't have commit rights, so please commit the > patches for me. > Pushed to master: a25fe00c62117cb11a1e75fbcc4960a0cfa72aab -- Petr? From pvoborni at redhat.com Fri Aug 22 08:31:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 10:31:31 +0200 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <53EA39C8.5020304@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> Message-ID: <53F6FFE3.3070302@redhat.com> On 12.8.2014 17:59, Endi Sukma Dewata wrote: > On 8/5/2014 6:31 AM, Petr Vobornik wrote:>> >> ticket: https://fedorahosted.org/freeipa/ticket/4402 snip (ACK of 720, 721) but patch 720 was replaced by a new version > >> [PATCH] 722 webui: add token from user page >> >> Add 'Add OTP Token' action to user action menu. >> >> This option is disabled in self-service when viewing other users. > > ACK, but I'm just wondering if it would be more intuitive to define an > enabled condition (you're an admin or editing your own user) rather than > a disabled condition (you're in self-service mode but editing other user). probably snip (ACK of 723) >> [PATCH] 724 webui: display fields based on otp token type >> >> - in adder dialog is it an ACK? >> snip (ACK of 725, 726) > >> [PATCH] 727 webui: hide empty fields and sections >> >> Hide widgets without a value. Must be explicitly turned on. In widget by >> `hidden_if_empty` flag. Or globally by `hide_empty_widgets` flag. Global >> hiding can be individually turned off by `ignore_empty_hiding` flag. > > In item #2 of ticket #4402 I was originally thinking the widget > visibility would be determined by the token type. Originally I wrote it that way but with this patch it became redundant. > Any plan to add the > token type field in the future? maybe, I don't have any strong feelings about it. Will users benefit from adding it? If yes, it should be also added to CLI. Atm. token type is derived from object classes. It exists only in add operation as a virtual attribute. We can check a presence of ipatokenhotp or ipatokentotp object classes to simulate the field. > Will the "counter" field strictly have a > value with HOTP only and "clock offset & interval" fields strictly have > value with TOTP only? Do these fields contain the configured values or > the effective values? I was just thinking maybe in the future some of > these fields might be configured empty and they will use the default > values instead. If that's not a problem then ACK. Respective fields are present only in corresponding object classes -> there won't be an HTOP token with 'clock offset'. If they are present, they have a default value. -> No false hiding -> Shouldn't be a problem. Btw: Other of my other original intents was to hide it based on ACI rights. The issues is that the rights are not present without corresponding OC. Hiding in such case is dangerous - explicitly disabled in patch 728. What do you think about setting `hide_empty_widgets` global setting to True? > >> [PATCH] 728 webui: hide non-readable fields >> >> hide widgets if associated field had received attribute level rights >> without 'r' right. >> >> Explicit rights are required to avoid hiding of special widgets which >> are not associated with any LDAP attribute. > > ACK. > >> [PATCH] 729 webui: hide otp fields based on token type >> >> - uses hide empty feature > > Assuming patch #727 is fine then it's ACKed too. > > Some other comments/questions: > > 1. The "Validity start/end" fields don't show the date/time format. When > you type the first letter then it will show the validation message with > the format. It's not a big deal, but it's not very intuitive because > people might not know what letter to type in the first place. Usually > the field label should indicate the format/unit and the validation > message will only appear if the value entered doesn't match the > format/unit. +1 We could set one of supported format as a placeholder + later is should be transformed into proper datetime select. Also some of our validators could benefit from more intelligent logic, e.g. don't show error while typing if the entered value is a beginning of a correct form > > 2. The "Digits" field by itself sounds a bit weird. How about "Number of > digits", or "OTP length" and add the unit in the value (e.g. 6 digits)? Both UIs should use the same terminology if possible. I like the "OTP length" example but it doesn't work for CLI much. "Number of digits" sounds reasonable. Should be changed in ipalib.otptoken though. > > 3. The "Clock offset" field doesn't have a unit. Fixed in patch 720-1, patch 729 was rebased > > 4. If no "Owner" is specified when adding a token, it will default to > admin. Is this the intended behavior? > Sadly yes. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0720-1-webui-add-measurement-unit-to-otp-token-time-fields.patch Type: text/x-patch Size: 1693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0729-1-webui-hide-otp-fields-based-on-token-type.patch Type: text/x-patch Size: 1572 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 22 11:51:58 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 13:51:58 +0200 Subject: [Freeipa-devel] [PATCH] 743 webui: do not show login error when switching back from otp sync screen Message-ID: <53F72EDE.3070307@redhat.com> Errors should reflect only a result of last operation. https://fedorahosted.org/freeipa/ticket/4470 Fixes issue found by Endi: > Try logging in with an incorrect password/OTP. After you get a login > error click Sync OTP Token. Once the sync is completed it will go > back to the login page with a "Token was synchronized" message that > disappears in a few seconds, but the old login error still appears > which is confusing. Error messages in the UI should only reflect the > last executed operation. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0743-webui-do-not-show-login-error-when-switching-back-fr.patch Type: text/x-patch Size: 3091 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 22 13:27:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 15:27:26 +0200 Subject: [Freeipa-devel] Notice: vakwetu/dogtag COPR repo required in order to run master on F20 Message-ID: <53F7453E.1000407@redhat.com> For those of you who haven't read the "Add DRM to IPA" thread: you have to use Dogtag 10.2 which is only available in COPR repo. Otherwise httpd won't start because of missing pki.crypto. Could be done simply by: # dnf copr enable vakwetu/dogtag Might save you some time... -- Petr Vobornik From pvoborni at redhat.com Fri Aug 22 13:28:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 15:28:53 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F6F952.8020307@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> <53F64E16.3040308@redhat.com> <1408654386.2886.3.camel@aleeredhat.laptop> <53F6F952.8020307@redhat.com> Message-ID: <53F74595.6040602@redhat.com> On 22.8.2014 10:03, Petr Viktorin wrote: > On 08/21/2014 10:53 PM, Ade Lee wrote: >> On Thu, 2014-08-21 at 21:52 +0200, Martin Kosek wrote: >>> On 08/21/2014 05:27 PM, Petr Viktorin wrote: >>>> On 08/21/2014 03:48 PM, Ade Lee wrote: >>>>> As agreed on #irc, disabling uninstallation for now. >>>>> Please apply this new patch on top of the big one. >>>> >>>> >>>> I'm fine with pushing a patch with incomplete functionality, after >>>> all I did >>>> this all the time with permissions. >>>> >>>> The incomplete parts (apart from the plugin which is entirely out of >>>> scope) are: >>>> - The agent PEM issue (will be sorted out as the plugin is implemented) > > https://fedorahosted.org/freeipa/ticket/4503 > >>>> - Missing man page (will be written before the plugin is implemented) > > https://fedorahosted.org/freeipa/ticket/4504 > >>>> - Uninstall (will be fixed on Dogtag side, re-tested and enabled) > > https://fedorahosted.org/freeipa/ticket/4505 > >>>> >>>> I'll open tickets for these before pushing. >>>> >>>> ACK from me if Rob agrees. On IRC, Rob said he'd rather delay >>>> pushing until the >>>> man page is written, but delegated the decision to Martin. >>>> So, Martin, can we push now and trust Ade's promise that he'll write >>>> the docs? >>> >>> Yes, if you open ticket(s) for all missing parts and put them in the >>> same >>> milestone. I would rather have the patches in than waiting for man >>> page and >>> then have a conflict and postpone the patch set. >>> >>> I trust Ade to provide the man page later, I am sure he does not want >>> to meet >>> with my whip otherwise :-) >>> >> >> Perfect, thanks! I don't have commit rights, so please commit the >> patches for me. >> > > Pushed to master: a25fe00c62117cb11a1e75fbcc4960a0cfa72aab > Should the requirement of Dogtag 10.2 be reflected in a spec file? -- Petr Vobornik From edewata at redhat.com Fri Aug 22 14:52:41 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 22 Aug 2014 09:52:41 -0500 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <1408623534.7908.23.camel@willson.usersys.redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> <1408623534.7908.23.camel@willson.usersys.redhat.com> Message-ID: <53F75939.2090100@redhat.com> On 8/21/2014 7:18 AM, Simo Sorce wrote: > On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: >> On 13.8.2014 17:20, Endi Sukma Dewata wrote: >>> 2. Can the UI parse the new key and display it the same way as other >>> keys that are already saved? That will make it more seamless. >> Would be nice, but is it worth the effort? We would have to >> reimplement ipapython.ssh into JavaScript + pull in crypto.js or other >> lib for sha1and sha256 functions since Web Cryptography API is still >> only a draft [1]. > I do not do this lightly, but you have my veto to do any crypto in > javascript unless you convince me first it make sense. > > Simo. Just to clarify, the point is to display some kind of information about the public keys the user just entered in the UI (that have not been saved) so that: a) If user enters multiple keys at once, the user can distinguish which keys have been added rather than displaying a generic "New: key set" for all new keys. b) The UI can detect if the key already exists on the server. If this can be done without any cryptographic operations that would be great, but I'm not sure about the details. For (a) I was wondering if the UI can decode the base-64 encoded public key entered by the user and display some user-friendly information about the key itself, maybe just the hexdump of the first few bytes of the key, or maybe the key type too if possible, or at least just the first few chars of the undecoded key. For (b) the UI would have to use some crypto functions to generate the key fingerprints as generated by the server. But even if we do that, we are not doing any data encryption or dealing with secret information. Alternatively, instead of displaying the fingerprints of the saved keys, the UI can display the first few bytes/chars of hexdump/encoded key to match (a) such that they can be compared without cryptography. BTW, WebCrypto implementation has been making its way into Firefox: https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing -- Endi S. Dewata From simo at redhat.com Fri Aug 22 15:51:35 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 22 Aug 2014 11:51:35 -0400 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53F75939.2090100@redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> <1408623534.7908.23.camel@willson.usersys.redhat.com> <53F75939.2090100@redhat.com> Message-ID: <1408722695.26587.20.camel@willson.usersys.redhat.com> On Fri, 2014-08-22 at 09:52 -0500, Endi Sukma Dewata wrote: > On 8/21/2014 7:18 AM, Simo Sorce wrote: > > On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: > >> On 13.8.2014 17:20, Endi Sukma Dewata wrote: > >>> 2. Can the UI parse the new key and display it the same way as other > >>> keys that are already saved? That will make it more seamless. > >> Would be nice, but is it worth the effort? We would have to > >> reimplement ipapython.ssh into JavaScript + pull in crypto.js or other > >> lib for sha1and sha256 functions since Web Cryptography API is still > >> only a draft [1]. > > I do not do this lightly, but you have my veto to do any crypto in > > javascript unless you convince me first it make sense. > > > > Simo. > > Just to clarify, the point is to display some kind of information about > the public keys the user just entered in the UI (that have not been > saved) so that: > a) If user enters multiple keys at once, the user can distinguish which > keys have been added rather than displaying a generic "New: key set" for > all new keys. > b) The UI can detect if the key already exists on the server. > If this can be done without any cryptographic operations that would be > great, but I'm not sure about the details. > > For (a) I was wondering if the UI can decode the base-64 encoded public > key entered by the user and display some user-friendly information about > the key itself, maybe just the hexdump of the first few bytes of the > key, or maybe the key type too if possible, or at least just the first > few chars of the undecoded key. > > For (b) the UI would have to use some crypto functions to generate the > key fingerprints as generated by the server. But even if we do that, we > are not doing any data encryption or dealing with secret information. I do not think you need crypto functions for (a) and it is unclear to me what (b) is, if the key already exist on the IPA server you can find it out with a simple memcmp, why should you need a fingeprint ? > Alternatively, instead of displaying the fingerprints of the saved keys, > the UI can display the first few bytes/chars of hexdump/encoded key to > match (a) such that they can be compared without cryptography. > > BTW, WebCrypto implementation has been making its way into Firefox: > https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing Yes and I find it a particularly bad/dangerous thing, I tend to agree with this: http://tonyarcieri.com/whats-wrong-with-webcrypto see also the links it points to which explains why crypto in javascript (ie in the "user-hostile" sandbox running in the browser) is mostly a bad idea, and can give a false sense of security and a slippery slope in actually unprotecting data. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Aug 22 16:07:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Aug 2014 18:07:16 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure Message-ID: <53F76AB4.5000708@redhat.com> https://fedorahosted.org/freeipa/ticket/4499 Actually I wonder why we use backup_state/restore_state for these settings. Rob, was there a reason for not just always setting nsslapd-port: 389 and nsslapd-security: on? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0637-upgradeinstance-Restore-listeners-on-failure.patch Type: text/x-patch Size: 4679 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 22 16:29:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 18:29:30 +0200 Subject: [Freeipa-devel] [PATCH] 744 webui: switch associators if default doesn't work Message-ID: <53F76FEA.9090806@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4507 Support for delegating RBAC roles to service principals added new attribute members. [1][2] Most of Web UI was automatically extended but the defaults chose wrong associator for service's memberof_role facet traditionally it would be solved by { $type: 'association', name: 'memberof_role', associator: IPA.serial_associator } This patch tries to make the auto-magic functionality little bit less stupid to eliminate a need for ^^ patches. It's far from perfect - doesn't support things like: { $type: 'association', name: 'memberof_sudorule', associator: IPA.serial_associator, add_method: 'add_user', remove_method: 'remove_user' } [1] https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8fabd6dde152fc394bd4f093d93c8a46e5b2851b [2] https://fedorahosted.org/freeipa/ticket/3164 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0744-webui-switch-associators-if-default-doesn-t-work.patch Type: text/x-patch Size: 1592 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 22 17:18:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 Aug 2014 19:18:55 +0200 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <1408722695.26587.20.camel@willson.usersys.redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> <1408623534.7908.23.camel@willson.usersys.redhat.com> <53F75939.2090100@redhat.com> <1408722695.26587.20.camel@willson.usersys.redhat.com> Message-ID: <53F77B7F.40501@redhat.com> On 22.8.2014 17:51, Simo Sorce wrote: > On Fri, 2014-08-22 at 09:52 -0500, Endi Sukma Dewata wrote: >> On 8/21/2014 7:18 AM, Simo Sorce wrote: >>> On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: >>>> On 13.8.2014 17:20, Endi Sukma Dewata wrote: >>>>> 2. Can the UI parse the new key and display it the same way as other >>>>> keys that are already saved? That will make it more seamless. >>>> Would be nice, but is it worth the effort? We would have to >>>> reimplement ipapython.ssh into JavaScript + pull in crypto.js or other >>>> lib for sha1and sha256 functions since Web Cryptography API is still >>>> only a draft [1]. >>> I do not do this lightly, but you have my veto to do any crypto in >>> javascript unless you convince me first it make sense. >>> >>> Simo. >> >> Just to clarify, the point is to display some kind of information about >> the public keys the user just entered in the UI (that have not been >> saved) so that: >> a) If user enters multiple keys at once, the user can distinguish which >> keys have been added rather than displaying a generic "New: key set" for >> all new keys. >> b) The UI can detect if the key already exists on the server. >> If this can be done without any cryptographic operations that would be >> great, but I'm not sure about the details. >> >> For (a) I was wondering if the UI can decode the base-64 encoded public >> key entered by the user and display some user-friendly information about >> the key itself, maybe just the hexdump of the first few bytes of the >> key, or maybe the key type too if possible, or at least just the first >> few chars of the undecoded key. >> >> For (b) the UI would have to use some crypto functions to generate the >> key fingerprints as generated by the server. But even if we do that, we >> are not doing any data encryption or dealing with secret information. > > I do not think you need crypto functions for (a) and it is unclear to me > what (b) is, if the key already exist on the IPA server you can find it > out with a simple memcmp, why should you need a fingeprint ? in both (a) and (b) the key does not exist on the server - user just added the key(s) but he had not yet clicked on 'update' button to upload them. Will displaying of the fingerprints prior saving help(improve UX) the user? The issue is that user can't distinguish multiple added keys. The "first few chars of the undecoded key" variant of (a) will solve the issue in the most efficient way - user will see what he just added. No crypto needed. > >> Alternatively, instead of displaying the fingerprints of the saved keys, >> the UI can display the first few bytes/chars of hexdump/encoded key to >> match (a) such that they can be compared without cryptography. >> >> BTW, WebCrypto implementation has been making its way into Firefox: >> https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing > > Yes and I find it a particularly bad/dangerous thing, I tend to agree > with this: http://tonyarcieri.com/whats-wrong-with-webcrypto see also > the links it points to which explains why crypto in javascript (ie in > the "user-hostile" sandbox running in the browser) is mostly a bad idea, > and can give a false sense of security and a slippery slope in actually > unprotecting data. > > Simo. > -- Petr Vobornik From edewata at redhat.com Fri Aug 22 19:32:47 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 22 Aug 2014 14:32:47 -0500 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53F77B7F.40501@redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> <1408623534.7908.23.camel@willson.usersys.redhat.com> <53F75939.2090100@redhat.com> <1408722695.26587.20.camel@willson.usersys.redhat.com> <53F77B7F.40501@redhat.com> Message-ID: <53F79ADF.1060701@redhat.com> On 8/22/2014 12:18 PM, Petr Vobornik wrote: > On 22.8.2014 17:51, Simo Sorce wrote: >> On Fri, 2014-08-22 at 09:52 -0500, Endi Sukma Dewata wrote: >>> On 8/21/2014 7:18 AM, Simo Sorce wrote: >>>> On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: >>>>> On 13.8.2014 17:20, Endi Sukma Dewata wrote: >>>>>> 2. Can the UI parse the new key and display it the same way as other >>>>>> keys that are already saved? That will make it more seamless. >>>>> Would be nice, but is it worth the effort? We would have to >>>>> reimplement ipapython.ssh into JavaScript + pull in crypto.js or >>>>> other >>>>> lib for sha1and sha256 functions since Web Cryptography API is still >>>>> only a draft [1]. >>>> I do not do this lightly, but you have my veto to do any crypto in >>>> javascript unless you convince me first it make sense. >>>> >>>> Simo. >>> >>> Just to clarify, the point is to display some kind of information about >>> the public keys the user just entered in the UI (that have not been >>> saved) so that: >>> a) If user enters multiple keys at once, the user can distinguish which >>> keys have been added rather than displaying a generic "New: key set" >>> for >>> all new keys. >>> b) The UI can detect if the key already exists on the server. >>> If this can be done without any cryptographic operations that would be >>> great, but I'm not sure about the details. >>> >>> For (a) I was wondering if the UI can decode the base-64 encoded public >>> key entered by the user and display some user-friendly information >>> about >>> the key itself, maybe just the hexdump of the first few bytes of the >>> key, or maybe the key type too if possible, or at least just the first >>> few chars of the undecoded key. >>> >>> For (b) the UI would have to use some crypto functions to generate the >>> key fingerprints as generated by the server. But even if we do that, we >>> are not doing any data encryption or dealing with secret information. >> >> I do not think you need crypto functions for (a) and it is unclear to me >> what (b) is, if the key already exist on the IPA server you can find it >> out with a simple memcmp, why should you need a fingeprint ? > > in both (a) and (b) the key does not exist on the server - user just > added the key(s) but he had not yet clicked on 'update' button to > upload them. > Right, all the UI has is the base-64 encoded key entered by the user. So without crypto, all the UI can do is probably decoding the key and, if possible, parsing the key structure to obtain some useful information. Can we obtain the key type this way, or does it require crypto? The existing keys on the other hand are displayed in the UI with their fingerprints and key type, for example: A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa) The UI does not show the base-64 encoded key unless the user clicks the "Show/Set key" button. To check if a new key already exists on the server, the UI can compare either the base-64 encoded keys or the fingerprints (if available). > Will displaying of the fingerprints prior saving help(improve UX) the > user? The issue is that user can't distinguish multiple added keys. > The "first few chars of the undecoded key" variant of (a) will solve > the issue in the most efficient way - user will see what he just > added. No crypto needed. Displaying the fingerprints of the new keys is not necessary to solve (a), but the display will not be seamless without it. For example, it could become like this: A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa) AAAAB3NzaC1yc2EAAAABIwAAAQEAueevoxw+... (new key) On the other hand, since existing keys are displayed with their fingerprints, it's not possible to open a public key file and compare it to the list before adding it to the UI. Are the fingerprints actually only used internally by the server? Do the users have any use of the fingerprints? If the fingerprints are internal only, the UI shouldn't need to display it. I'd say the UI should just display the key itself, not the whole key but just long enough to be distinguishable, either as a hexdump or base-64 encoded. >> >>> BTW, WebCrypto implementation has been making its way into Firefox: >>> https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing >>> >> >> Yes and I find it a particularly bad/dangerous thing, I tend to agree >> with this: http://tonyarcieri.com/whats-wrong-with-webcrypto see also >> the links it points to which explains why crypto in javascript (ie in >> the "user-hostile" sandbox running in the browser) is mostly a bad idea, >> and can give a false sense of security and a slippery slope in actually >> unprotecting data. >> >> Simo. >> If for some reason we decided to generate fingerprints in the UI, in my opinion using WebCrypto will not pose any security problem or mislead users into a false sense of security because the operation is purely informational, it does not do any encryption/decryption/validation. Any fingerprint generated on the UI side will be discarded anyway, the server will still generate its own fingerprints. This belongs to a separate discussion, but the article was concerned about possible inconsistencies across browser implementations and the reliance on the server to deliver the application that uses WebCrypto. I think there are limited/specific scenarios where WebCrypto could be used in IPA (like above) as long as the implications are well understood. In the future we might be able to deliver the whole UI as a signed browser extension that uses WebCrypto which would address those concerns. -- Endi S. Dewata From alee at redhat.com Sun Aug 24 16:28:13 2014 From: alee at redhat.com (Ade Lee) Date: Sun, 24 Aug 2014 12:28:13 -0400 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install Message-ID: <1408897693.23316.2.camel@aleeredhat.laptop> Added man pages for ipa-kra-install. And its not even Tuesday yet :) Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Added-man-page-for-ipa-kra-install.patch Type: text/x-patch Size: 4068 bytes Desc: not available URL: From simo at redhat.com Mon Aug 25 00:32:13 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 24 Aug 2014 20:32:13 -0400 Subject: [Freeipa-devel] [PATCH] 736-740 webui: various minor fixes In-Reply-To: <53F79ADF.1060701@redhat.com> References: <53E0C346.1050700@redhat.com> <53EB824E.6030001@redhat.com> <53F5E1E2.7080800@redhat.com> <1408623534.7908.23.camel@willson.usersys.redhat.com> <53F75939.2090100@redhat.com> <1408722695.26587.20.camel@willson.usersys.redhat.com> <53F77B7F.40501@redhat.com> <53F79ADF.1060701@redhat.com> Message-ID: <1408926733.26587.37.camel@willson.usersys.redhat.com> On Fri, 2014-08-22 at 14:32 -0500, Endi Sukma Dewata wrote: > > If for some reason we decided to generate fingerprints in the UI, in > my opinion using WebCrypto will not pose any security problem or > mislead users into a false sense of security because the operation is > purely informational, it does not do any > encryption/decryption/validation. Any fingerprint generated on the UI > side will be discarded anyway, the server will still generate its own > fingerprints. It's not (only) the users I am concerned about, mostly the developers. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Aug 25 08:28:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Aug 2014 10:28:01 +0200 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <1408897693.23316.2.camel@aleeredhat.laptop> References: <1408897693.23316.2.camel@aleeredhat.laptop> Message-ID: <53FAF391.7060104@redhat.com> On 08/24/2014 06:28 PM, Ade Lee wrote: > Added man pages for ipa-kra-install. And its not even Tuesday yet :) > > Please review, > Ade > If I was new to this, I think I'd be quite lost. I think the man page should briefly explain what KRA is -- just a sentence would be fine. At the very least expand the acronym. -- Petr? From jcholast at redhat.com Mon Aug 25 10:00:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Aug 2014 12:00:35 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> <53DA423B.2050607@redhat.com> Message-ID: <53FB0943.4090609@redhat.com> The docstring of interactive_prompt_callback could use some tweaking, but besides that re-ACK. Dne 21.8.2014 v 14:50 Gabe Alford napsal(a): > Hello, > > Just wondering if this needs to be re-ack'd. > > Thanks, > > Gabe > > > On Thu, Jul 31, 2014 at 7:57 AM, Gabe Alford > wrote: > > Okay. Sounds good. Update patch attached. > > > On Thu, Jul 31, 2014 at 7:18 AM, Martin Kosek > wrote: > > Ah, right. But I still think that's a too-early optimization. We > can add this > callback when this necessity arises. Until then, I would rather > prefer to keep > the code clean. > > Martin > > On 07/31/2014 03:17 PM, Gabe Alford wrote: > > Right. The reason I added it in there is that I could see > that in the > > future trust_type could be more than just 'ad' (maybe 'ipa', > 'krb', etc?) > > which at that point I'm not sure a default makes sense. So, I > thought to go > > ahead and add the check for future use cases so that it > doesn't have to be > > remembered later. However, maybe that was just a bad idea as > right now it > > is a pointless check? > > > > Gabe > > > > > > On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy > > > > wrote: > > > >> On Thu, 31 Jul 2014, Martin Kosek wrote: > >> > >>> Sorry for going late in the game, just a quick question - > why do we want > >>> to add > >>> this part: > >>> > >>> + if trust_type is None: > >>> + kw['trust_type'] = self.prompt_param(self.params[ > >>> 'trust_type']) > >>> > >>> ? I do not see a reason for adding a special interactive > prompt callback > >>> for > >>> that - trust_type has a default value "ad". CCing Alexander > to double > >>> check. > >>> > >> I also don't understand why you need to ask interactively > for the > >> trust_type as it defaults to non-empty value and this value > is the only > >> one we currently support. > >> > >> > >> -- > >> / Alexander Bokovoy > >> > > > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Jan Cholasta From mkosek at redhat.com Mon Aug 25 10:35:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Aug 2014 12:35:05 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53FB0943.4090609@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> <53DA423B.2050607@redhat.com> <53FB0943.4090609@redhat.com> Message-ID: <53FB1159.9080603@redhat.com> Thanks. Pushed to: master: 9415aba87789512e34cb4ed62534cde7822ff70b ipa-4-1: 8bb2af0e0ca375e10a406883ada5769963813763 ipa-4-0: b708001074e1fc1e412bc18b1e5e0b408151847b Martin On 08/25/2014 12:00 PM, Jan Cholasta wrote: > The docstring of interactive_prompt_callback could use some tweaking, but > besides that re-ACK. > > Dne 21.8.2014 v 14:50 Gabe Alford napsal(a): >> Hello, >> >> Just wondering if this needs to be re-ack'd. >> >> Thanks, >> >> Gabe >> >> >> On Thu, Jul 31, 2014 at 7:57 AM, Gabe Alford > > wrote: >> >> Okay. Sounds good. Update patch attached. >> >> >> On Thu, Jul 31, 2014 at 7:18 AM, Martin Kosek > > wrote: >> >> Ah, right. But I still think that's a too-early optimization. We >> can add this >> callback when this necessity arises. Until then, I would rather >> prefer to keep >> the code clean. >> >> Martin >> >> On 07/31/2014 03:17 PM, Gabe Alford wrote: >> > Right. The reason I added it in there is that I could see >> that in the >> > future trust_type could be more than just 'ad' (maybe 'ipa', >> 'krb', etc?) >> > which at that point I'm not sure a default makes sense. So, I >> thought to go >> > ahead and add the check for future use cases so that it >> doesn't have to be >> > remembered later. However, maybe that was just a bad idea as >> right now it >> > is a pointless check? >> > >> > Gabe >> > >> > >> > On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy >> > >> > wrote: >> > >> >> On Thu, 31 Jul 2014, Martin Kosek wrote: >> >> >> >>> Sorry for going late in the game, just a quick question - >> why do we want >> >>> to add >> >>> this part: >> >>> >> >>> + if trust_type is None: >> >>> + kw['trust_type'] = self.prompt_param(self.params[ >> >>> 'trust_type']) >> >>> >> >>> ? I do not see a reason for adding a special interactive >> prompt callback >> >>> for >> >>> that - trust_type has a default value "ad". CCing Alexander >> to double >> >>> check. >> >>> >> >> I also don't understand why you need to ask interactively >> for the >> >> trust_type as it defaults to non-empty value and this value >> is the only >> >> one we currently support. >> >> >> >> >> >> -- >> >> / Alexander Bokovoy >> >> >> > >> >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > From pviktori at redhat.com Mon Aug 25 11:14:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Aug 2014 13:14:59 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53F74595.6040602@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> <53F64E16.3040308@redhat.com> <1408654386.2886.3.camel@aleeredhat.laptop> <53F6F952.8020307@redhat.com> <53F74595.6040602@redhat.com> Message-ID: <53FB1AB3.4010001@redhat.com> On 08/22/2014 03:28 PM, Petr Vobornik wrote: [...] > Should the requirement of Dogtag 10.2 be reflected in a spec file? Yes. Sorry for forgetting that point in he review. We can do two things here: 1) Require Dogtag 10.2 (and ask developers to add the vakwetu-dogtag repo for ipa master) or 2) Disable ipa-kra-install and the kra plugin if pki.crypto is not importable How soon will 10.2 be available? If it will take a while I'd rather do 2) but it does mean more churn in the repo. Thoughts? -- Petr? From mbasti at redhat.com Mon Aug 25 12:52:33 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 Aug 2014 14:52:33 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' Message-ID: <53FB3191.7090102@redhat.com> Patches attached. Ticket: https://fedorahosted.org/freeipa/ticket/4149 There is a bug in bind-dyndb-ldap (or worse in dirsrv), which cause the named service is stopped after deleting zone. Bug ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/138 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114-Fix-DNS-plugin-to-allow-to-add-root-zone.patch Type: text/x-patch Size: 4904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0115-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4529 bytes Desc: not available URL: From alee at redhat.com Mon Aug 25 13:02:59 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 25 Aug 2014 09:02:59 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53FB1AB3.4010001@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> <53C81F12.4020902@redhat.com> <1407357125.14215.7.camel@aleeredhat.laptop> <53E55EF8.5060902@redhat.com> <53E8D92C.1080803@redhat.com> <1407953151.6981.43.camel@aleeredhat.laptop> <662317244.6201992.1407959661287.JavaMail.zimbra@redhat.com> <53EC7906.5060200@redhat.com> <53ECAB8C.6060701@redhat.com> <1408383404.22256.15.camel@aleeredhat.laptop> <53F4F885.4020308@redhat.com> <1408598129.20372.28.camel@aleeredhat.laptop> <1408628887.30166.1.camel@aleeredhat.laptop> <53F60FF6.3060203@redhat.com> <53F64E16.3040308@redhat.com> <1408654386.2886.3.camel@aleeredhat.laptop> <53F6F952.8020307@redhat.com> <53F74595.6040602@redhat.com> <53FB1AB3.4010001@redhat.com> Message-ID: <1408971779.16812.3.camel@aleeredhat.laptop> We plan to do an alpha build of Dogtag 10.2 on Fedora 21 at the end of this week. Ade On Mon, 2014-08-25 at 13:14 +0200, Petr Viktorin wrote: > On 08/22/2014 03:28 PM, Petr Vobornik wrote: > [...] > > Should the requirement of Dogtag 10.2 be reflected in a spec file? > > > Yes. Sorry for forgetting that point in he review. > > We can do two things here: > 1) Require Dogtag 10.2 (and ask developers to add the vakwetu-dogtag > repo for ipa master) > or > 2) Disable ipa-kra-install and the kra plugin if pki.crypto is not > importable > > How soon will 10.2 be available? If it will take a while I'd rather do > 2) but it does mean more churn in the repo. Thoughts? > From dkupka at redhat.com Mon Aug 25 13:39:29 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 25 Aug 2014 15:39:29 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53F370F6.9030700@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> <53F367A4.9000802@redhat.com> <53F370F6.9030700@redhat.com> Message-ID: <53FB3C91.7010508@redhat.com> On 08/19/2014 05:44 PM, Rob Crittenden wrote: > David Kupka wrote: >> On 08/19/2014 09:58 AM, Martin Kosek wrote: >>> On 08/19/2014 09:05 AM, David Kupka wrote: >>>> FreeIPA will use certmonger D-Bus API as discussed in this thread >>>> https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html >>>> >>>> This change should prevent hard-to-reproduce bugs like >>>> https://fedorahosted.org/freeipa/ticket/4280 >>> >>> Thanks for this effort, the updated certmonger module looks much >>> better! This >>> will help us get rid of the non-standard communication with certmonger. >>> >>> Just couple initial comments from me by reading the code: >>> >>> 1) Testing needs fixed version of certmonger, right? This needs to be >>> spelled >>> out right with the patch. >> Yes, certmonger 0.75.13 and above should be fine according ticket >> https://fedorahosted.org/certmonger/ticket/36. Added to patch description. > > You should update the spec to set the minimum version as well. Sure, thanks. > >>> >>> 2) Description text in patches is cheap, do not be afraid to use it and >>> describe what you did and why. Link to the ticket is missing in the >>> description >>> as well: >> Ok, increased verbosity a bit :-) >>> >>>> Subject: [PATCH] Use certmonger D-Bus API instead of messing with its >>>> files. >>>> >>>> --- >>> >>> 3) get_request_id API: >>> >>>> criteria = ( >>>> - ('cert_storage_location', dogtag_constants.ALIAS_DIR, >>>> - certmonger.NPATH), >>>> - ('cert_nickname', nickname, None), >>>> + ('cert_storage_location', dogtag_constants.ALIAS_DIR), >>>> + ('cert_nickname', nickname), >>>> ) >>>> request_id = certmonger.get_request_id(criteria) >>> >>> Do we want to continue using the "criteria" object or should we rather >>> switch >>> to normal function options? I.e. rather using >>> >>> request_id = certmonger.get_request_id(cert_nickname=nickname, >>> cert_storage_location=dogtag_constants.ALIAS_DIR) >>> >>> ? It would look more consistent with other calls. I am just asking, >>> not insisting. >> I've no preference here. It seems to be a very small change. Has anyone >> a reason to do it one way and not the other? > > I think I used this criteria thing to avoid having a bazillion optional > parameters and for future-proofing. I think at this point the list is > probably pretty stable, so I'd base it on whether you care about having > a whole ton of optional parameters or not (it has the advantage of > self-documenting itself). > The list is probably stable but also really excessive. I don't think it would help to have more than dozen optional parameters. So I prefer to leave as-is and change it in future if it is wanted. >>> >>> 3) Starting function: >>> >>>> + try: >>>> + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], >>>> skip_output=True) >>>> + except Exception, e: >>>> + root_logger.error('Failed to start certmonger: %s' % e) >>>> + raise e >>> >>> I see 2 issues related to this code: >>> a) Do not call SYSTEMCTL directly. To be platform independent, rather use >>> services.knownservices.messagebus.start() that is overridable by >>> someone else >>> porting to non-systemd platforms. >> Is there anything that can't be done using ipalib/ipapython/ipaplatform? > > It can't make coffee (yet). > >>> b) In this case, do not use "raise e", but just "raise" to keep the >>> exception >>> stack trace intact for better debugging. >> Every day there's something new to learn about python or FreeIPA. >>> >>> Both a) and b) should be fixed in other occasions and places. >> I found only one occurence of a) issue. Is there some hidden or are you >> talking about the whole FreeIPA project? >>> >>> 4) Feel free to add yourself to Authors section of this module. You >>> refactored >>> it greatly to earn it :-) >> Done. > > You already import dbus, why also separately import DBusException? > Removed, thanks for noticing. > rob > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-3-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 35352 bytes Desc: not available URL: From dkupka at redhat.com Mon Aug 25 15:04:34 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 25 Aug 2014 17:04:34 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. Message-ID: <53FB5082.9020703@redhat.com> https://fedorahosted.org/freeipa/ticket/3575 Also should fix https://bugzilla.redhat.com/show_bug.cgi?id=1128380 as installation is no longer interrupted when multiple IPs are resolved. But it does not add the option to change the IP address during second run. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 16789 bytes Desc: not available URL: From alee at redhat.com Mon Aug 25 16:17:41 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 25 Aug 2014 12:17:41 -0400 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <53FAF391.7060104@redhat.com> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> Message-ID: <1408983461.16812.26.camel@aleeredhat.laptop> What if I add the following first paragraph? The KRA (Key Recovery Authority) is a component used to securely store secrets such as passwords, symmetric keys and private asymmetric keys. It is used as the back-end repository for the IPA Password Vault. Ade On Mon, 2014-08-25 at 10:28 +0200, Petr Viktorin wrote: > On 08/24/2014 06:28 PM, Ade Lee wrote: > > Added man pages for ipa-kra-install. And its not even Tuesday yet :) > > > > Please review, > > Ade > > > > If I was new to this, I think I'd be quite lost. > > I think the man page should briefly explain what KRA is -- just a > sentence would be fine. At the very least expand the acronym. > From pviktori at redhat.com Mon Aug 25 16:25:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Aug 2014 18:25:51 +0200 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <1408983461.16812.26.camel@aleeredhat.laptop> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> <1408983461.16812.26.camel@aleeredhat.laptop> Message-ID: <53FB638F.9030107@redhat.com> On 08/25/2014 06:17 PM, Ade Lee wrote: > What if I add the following first paragraph? > > The KRA (Key Recovery Authority) is a component used to securely store > secrets such as passwords, symmetric keys and private asymmetric keys. > It is used as the back-end repository for the IPA Password Vault. > > Ade Perfect. > > On Mon, 2014-08-25 at 10:28 +0200, Petr Viktorin wrote: >> On 08/24/2014 06:28 PM, Ade Lee wrote: >>> Added man pages for ipa-kra-install. And its not even Tuesday yet :) >>> >>> Please review, >>> Ade >>> >> >> If I was new to this, I think I'd be quite lost. >> >> I think the man page should briefly explain what KRA is -- just a >> sentence would be fine. At the very least expand the acronym. >> > > -- Petr? From pviktori at redhat.com Mon Aug 25 16:34:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Aug 2014 18:34:21 +0200 Subject: [Freeipa-devel] [RFE] Backporting capabilities Message-ID: <53FB658D.3060901@redhat.com> https://fedorahosted.org/freeipa/ticket/4427 Here is a design that enables backporting capabilities (i.e. backwards-incompatible API changes) to maintenance branches of FreeIPA. The premise is that no branched development occurs on the maintenance branch, only single targeted changes are brought back. I believe it solves the problem rather nicely, and the implementation would be pretty straightforward. The downside is that uses weird API versions like '2.347+backported_capability' (which are currently valid API versions, though). http://www.freeipa.org/page/V4/Backporting_Capabilities -- Petr? From alee at redhat.com Mon Aug 25 16:37:37 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 25 Aug 2014 12:37:37 -0400 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <53FB638F.9030107@redhat.com> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> <1408983461.16812.26.camel@aleeredhat.laptop> <53FB638F.9030107@redhat.com> Message-ID: <1408984657.16812.28.camel@aleeredhat.laptop> New patch attached. If OK, please commit for me. Thanks, Ade On Mon, 2014-08-25 at 18:25 +0200, Petr Viktorin wrote: > On 08/25/2014 06:17 PM, Ade Lee wrote: > > What if I add the following first paragraph? > > > > The KRA (Key Recovery Authority) is a component used to securely store > > secrets such as passwords, symmetric keys and private asymmetric keys. > > It is used as the back-end repository for the IPA Password Vault. > > > > Ade > > Perfect. > > > > > On Mon, 2014-08-25 at 10:28 +0200, Petr Viktorin wrote: > >> On 08/24/2014 06:28 PM, Ade Lee wrote: > >>> Added man pages for ipa-kra-install. And its not even Tuesday yet :) > >>> > >>> Please review, > >>> Ade > >>> > >> > >> If I was new to this, I think I'd be quite lost. > >> > >> I think the man page should briefly explain what KRA is -- just a > >> sentence would be fine. At the very least expand the acronym. > >> > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-1-Added-man-page-for-ipa-kra-install.patch Type: text/x-patch Size: 4280 bytes Desc: not available URL: From jhrozek at redhat.com Mon Aug 25 17:36:29 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 19:36:29 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname Message-ID: <20140825173629.GO10132@hendrix.redhat.com> Hi, ipa-client-install was failing for me on a fresh F-21 machine until I manually dragged in python-backports-ssl_match_hostname -------------- next part -------------- >From d5ff5ec7cb2ee0b3f116b4e9a25d2907bb8140d9 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Mon, 25 Aug 2014 19:33:30 +0200 Subject: [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname Without python-backports-ssl_match_hostname installed, an ipa-client installation could have failed with: from backports.ssl_match_hostname import match_hostname ImportError: No module named ssl_match_hostname This patch adds an explicit dependency to python-backports-ssl_match_hostname. --- ipa-client/ipa-client.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipa-client/ipa-client.spec.in b/ipa-client/ipa-client.spec.in index 686259ad24b241c232dce83b695a05f6fd6c3849..36701afc50f12b27556a70ed41defc77d4bec93a 100644 --- a/ipa-client/ipa-client.spec.in +++ b/ipa-client/ipa-client.spec.in @@ -9,7 +9,7 @@ URL: http://www.freeipa.org Source0: %{name}-%{version}.tgz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) -Requires: python python-ldap python-krbV ipa-python cyrus-sasl-gssapi +Requires: python python-ldap python-krbV ipa-python cyrus-sasl-gssapi python-backports-ssl_match_hostname %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} -- 1.9.3 From dkupka at redhat.com Tue Aug 26 11:01:06 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 26 Aug 2014 13:01:06 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file Message-ID: <53FC68F2.4040104@redhat.com> https://fedorahosted.org/freeipa/ticket/4481 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0010-Add-host-setting-into-default.conf-configuration-fil.patch Type: text/x-patch Size: 1426 bytes Desc: not available URL: From pviktori at redhat.com Tue Aug 26 11:16:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 26 Aug 2014 13:16:04 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} In-Reply-To: <53D9008E.7060404@redhat.com> References: <53D7B77A.5010802@redhat.com> <53D7C5DE.6000004@redhat.com> <53D9008E.7060404@redhat.com> Message-ID: <53FC6C74.1060907@redhat.com> On 07/30/2014 04:26 PM, Petr Viktorin wrote: > On 07/29/2014 06:03 PM, Petr Viktorin wrote: >> On 07/29/2014 05:02 PM, Petr Viktorin wrote: >>> Hello, >>> >>> The first patch here consolidates our system user creation code a bit. >>> >>> The second patch fixes an oversight in the restore script. >>> >>> The third changes the backup script to not include /etc/{passwd,group}, >>> and the restore script to create the PKI user if a CA is being restored. >>> Note that the DS user is already created early in the restore process. >>> (In the future we may want a nice generic framework for restoring users, >>> but I'd like to extrapolate from more than one data point when designing >>> it.) >> >> Another note: tar uses owner user/group names by default, so no >> additional chowning is required even if the IDs change between backup & >> restore. >> >>> >>> The fourth patch adds a log entry I find very useful in testing >>> backup/restore. > > > Rebased onto current master. Rebased again. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0624.3-ipaserver.install-Consolidate-system-user-creation.patch Type: text/x-patch Size: 10310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0625.3-ipa_restore-Split-the-services-list.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0626.3-backup-restore-Don-t-overwrite-etc-passwd-group.patch Type: text/x-patch Size: 2275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0627.3-ipa_backup-Log-where-the-backup-is-be-stored.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From pviktori at redhat.com Tue Aug 26 12:13:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 26 Aug 2014 14:13:12 +0200 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <1408984657.16812.28.camel@aleeredhat.laptop> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> <1408983461.16812.26.camel@aleeredhat.laptop> <53FB638F.9030107@redhat.com> <1408984657.16812.28.camel@aleeredhat.laptop> Message-ID: <53FC79D8.4000008@redhat.com> On 08/25/2014 06:37 PM, Ade Lee wrote: > New patch attached. > If OK, please commit for me. > > Thanks, > Ade I missed the argument list, where you have a deprecated option, and you list -U for both --unattended and --uninstall. Here's an updated patch, I can push if it looks OK to you. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0010-2-Add-man-page-for-ipa-kra-install.patch Type: text/x-patch Size: 4434 bytes Desc: not available URL: From alee at redhat.com Tue Aug 26 12:47:48 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 26 Aug 2014 08:47:48 -0400 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <53FC79D8.4000008@redhat.com> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> <1408983461.16812.26.camel@aleeredhat.laptop> <53FB638F.9030107@redhat.com> <1408984657.16812.28.camel@aleeredhat.laptop> <53FC79D8.4000008@redhat.com> Message-ID: <1409057268.9229.0.camel@aleeredhat.laptop> Looks good to me. Thanks. Ade On Tue, 2014-08-26 at 14:13 +0200, Petr Viktorin wrote: > On 08/25/2014 06:37 PM, Ade Lee wrote: > > New patch attached. > > If OK, please commit for me. > > > > Thanks, > > Ade > > > I missed the argument list, where you have a deprecated option, and you > list -U for both --unattended and --uninstall. > > Here's an updated patch, I can push if it looks OK to you. > From jcholast at redhat.com Tue Aug 26 13:08:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Aug 2014 15:08:42 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FC68F2.4040104@redhat.com> References: <53FC68F2.4040104@redhat.com> Message-ID: <53FC86DA.6010408@redhat.com> Hi, Dne 26.8.2014 v 13:01 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4481 Doing this will break ipa-client-automount and ipa-certupdate, because they assume that api.env.host contains the hostname of the local system (which is the default value). There is obviously some confusion about what the option should represent (documentation says server hostname, code does client hostname), IMO we should resolve that first. Honza -- Jan Cholasta From pviktori at redhat.com Tue Aug 26 13:22:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 26 Aug 2014 15:22:48 +0200 Subject: [Freeipa-devel] [PATCH] add man page for ipa-kra-install In-Reply-To: <1409057268.9229.0.camel@aleeredhat.laptop> References: <1408897693.23316.2.camel@aleeredhat.laptop> <53FAF391.7060104@redhat.com> <1408983461.16812.26.camel@aleeredhat.laptop> <53FB638F.9030107@redhat.com> <1408984657.16812.28.camel@aleeredhat.laptop> <53FC79D8.4000008@redhat.com> <1409057268.9229.0.camel@aleeredhat.laptop> Message-ID: <53FC8A28.9010907@redhat.com> On 08/26/2014 02:47 PM, Ade Lee wrote: > Looks good to me. Thanks. > > Ade > On Tue, 2014-08-26 at 14:13 +0200, Petr Viktorin wrote: >> On 08/25/2014 06:37 PM, Ade Lee wrote: >>> New patch attached. >>> If OK, please commit for me. >>> >>> Thanks, >>> Ade >> >> >> I missed the argument list, where you have a deprecated option, and you >> list -U for both --unattended and --uninstall. >> >> Here's an updated patch, I can push if it looks OK to you. Pushed to master: e732458a8e1af6432a739adf7a80a13fabcd59cc -- Petr? From dkupka at redhat.com Tue Aug 26 13:30:22 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 26 Aug 2014 15:30:22 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FC86DA.6010408@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> Message-ID: <53FC8BEE.5070206@redhat.com> On 08/26/2014 03:08 PM, Jan Cholasta wrote: > Hi, > > Dne 26.8.2014 v 13:01 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4481 > > Doing this will break ipa-client-automount and ipa-certupdate, because > they assume that api.env.host contains the hostname of the local system > (which is the default value). It looked suspiciously simple so I could expect that there is some catch. > > There is obviously some confusion about what the option should represent > (documentation says server hostname, code does client hostname), IMO we > should resolve that first. Ok, are there any suggestions? What is the desired state? > > Honza > -- David Kupka From rcritten at redhat.com Tue Aug 26 13:55:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Aug 2014 09:55:55 -0400 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FC8BEE.5070206@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> Message-ID: <53FC91EB.5020603@redhat.com> David Kupka wrote: > On 08/26/2014 03:08 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 26.8.2014 v 13:01 David Kupka napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4481 >> >> Doing this will break ipa-client-automount and ipa-certupdate, because >> they assume that api.env.host contains the hostname of the local system >> (which is the default value). > > It looked suspiciously simple so I could expect that there is some catch. >> >> There is obviously some confusion about what the option should represent >> (documentation says server hostname, code does client hostname), IMO we >> should resolve that first. > > Ok, are there any suggestions? What is the desired state? AIUI the server option is deprecated because it wasn't being used, not that it needed to be replaced. I believe that in most cases the server name is pulled from the xmlrpc_uri. host has always meant the local host name. I think the man page is wrong. rob From tscherf at redhat.com Tue Aug 26 15:53:09 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 26 Aug 2014 17:53:09 +0200 Subject: [Freeipa-devel] [PATCH] 0001 pwpolicy-add: Added better error handling Message-ID: <20140826155309.GI3890@tscherf.redhat.com> pwpolicy-add: Added better error handling Make error message more meaningful when a password policy is added for a non existing group. https://fedorahosted.org/freeipa/ticket/4334 -------------- next part -------------- >From b0b2ab6d785bb8d655d3e8d84b0b2946085fbc23 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 26 Aug 2014 17:46:36 +0200 Subject: [PATCH] pwpolicy-add: Added better error handling Make error message more meaningful when a password policy is added for a non existing group. https://fedorahosted.org/freeipa/ticket/4334 --- ipalib/plugins/pwpolicy.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/pwpolicy.py b/ipalib/plugins/pwpolicy.py index 1976675c56000cff14b211e115fda28105107c15..a6e4fa47cd60342a779ce9a880fabc5ba7a88b39 100644 --- a/ipalib/plugins/pwpolicy.py +++ b/ipalib/plugins/pwpolicy.py @@ -159,9 +159,14 @@ class cosentry_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + # check for existence of the group group_dn = self.api.Object.group.get_dn(keys[-1]) - result = ldap.get_entry(group_dn, ['objectclass']) + try: + result = ldap.get_entry(group_dn, ['objectclass']) + except errors.NotFound: + raise errors.NotFound(reason=_(u'%s: Group not found') % keys ) + oc = map(lambda x:x.lower(),result['objectclass']) if 'mepmanagedentry' in oc: raise errors.ManagedPolicyError() -- 1.9.3 From jcholast at redhat.com Tue Aug 26 16:19:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Aug 2014 18:19:50 +0200 Subject: [Freeipa-devel] [PATCH] 0001 pwpolicy-add: Added better error handling In-Reply-To: <20140826155309.GI3890@tscherf.redhat.com> References: <20140826155309.GI3890@tscherf.redhat.com> Message-ID: <53FCB3A6.1050808@redhat.com> Hi, Dne 26.8.2014 v 17:53 Thorsten Scherf napsal(a): > pwpolicy-add: Added better error handling > Make error message more meaningful when a password policy is added > for a non > existing group. > https://fedorahosted.org/freeipa/ticket/4334 thanks for the patch. Instead of raising NotFound manually, please use: self.api.Object.group.handle_not_found(keys[-1]) It raises NotFound as well, but automatically creates the error message. Honza -- Jan Cholasta From tscherf at redhat.com Tue Aug 26 17:26:13 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 26 Aug 2014 19:26:13 +0200 Subject: [Freeipa-devel] [PATCH] 0001 pwpolicy-add: Added better error handling In-Reply-To: <53FCB3A6.1050808@redhat.com> References: <20140826155309.GI3890@tscherf.redhat.com> <53FCB3A6.1050808@redhat.com> Message-ID: <20140826172613.GK3890@tscherf.redhat.com> Thanks Jan. Find the new patch attached. Cheers, Thorsten On [Tue, 26.08.2014 18:19], Jan Cholasta wrote: >Hi, > >Dne 26.8.2014 v 17:53 Thorsten Scherf napsal(a): >>pwpolicy-add: Added better error handling >> Make error message more meaningful when a password policy is added >>for a non >> existing group. >> https://fedorahosted.org/freeipa/ticket/4334 > >thanks for the patch. > >Instead of raising NotFound manually, please use: > > self.api.Object.group.handle_not_found(keys[-1]) > >It raises NotFound as well, but automatically creates the error message. > >Honza > >-- >Jan Cholasta -------------- next part -------------- >From 57840cb4195f4f23134f5b7c899a4790d814d659 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 26 Aug 2014 19:21:29 +0200 Subject: [PATCH] pwpolicy-add: Added better error handling Make error message more meaningful when a password policy is added for a non existing group. https://fedorahosted.org/freeipa/ticket/4334 --- ipalib/plugins/pwpolicy.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/pwpolicy.py b/ipalib/plugins/pwpolicy.py index 1976675c56000cff14b211e115fda28105107c15..165d54889b016e95b3a4e805f79fc49a8b135228 100644 --- a/ipalib/plugins/pwpolicy.py +++ b/ipalib/plugins/pwpolicy.py @@ -159,9 +159,14 @@ class cosentry_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + # check for existence of the group group_dn = self.api.Object.group.get_dn(keys[-1]) - result = ldap.get_entry(group_dn, ['objectclass']) + try: + result = ldap.get_entry(group_dn, ['objectclass']) + except errors.NotFound: + self.api.Object.group.handle_not_found(keys[-1]) + oc = map(lambda x:x.lower(),result['objectclass']) if 'mepmanagedentry' in oc: raise errors.ManagedPolicyError() -- 1.9.3 From jcholast at redhat.com Wed Aug 27 09:05:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Aug 2014 11:05:45 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53FB3C91.7010508@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> <53F367A4.9000802@redhat.com> <53F370F6.9030700@redhat.com> <53FB3C91.7010508@redhat.com> Message-ID: <53FD9F69.4010700@redhat.com> Hi, Dne 25.8.2014 v 15:39 David Kupka napsal(a): > On 08/19/2014 05:44 PM, Rob Crittenden wrote: >> David Kupka wrote: >>> On 08/19/2014 09:58 AM, Martin Kosek wrote: >>>> On 08/19/2014 09:05 AM, David Kupka wrote: >>>>> FreeIPA will use certmonger D-Bus API as discussed in this thread >>>>> https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html >>>>> >>>>> This change should prevent hard-to-reproduce bugs like >>>>> https://fedorahosted.org/freeipa/ticket/4280 >>>> >>>> Thanks for this effort, the updated certmonger module looks much >>>> better! This >>>> will help us get rid of the non-standard communication with certmonger. >>>> >>>> Just couple initial comments from me by reading the code: >>>> >>>> 1) Testing needs fixed version of certmonger, right? This needs to be >>>> spelled >>>> out right with the patch. >>> Yes, certmonger 0.75.13 and above should be fine according ticket >>> https://fedorahosted.org/certmonger/ticket/36. Added to patch >>> description. >> >> You should update the spec to set the minimum version as well. > Sure, thanks. >> >>>> >>>> 2) Description text in patches is cheap, do not be afraid to use it and >>>> describe what you did and why. Link to the ticket is missing in the >>>> description >>>> as well: >>> Ok, increased verbosity a bit :-) >>>> >>>>> Subject: [PATCH] Use certmonger D-Bus API instead of messing with its >>>>> files. >>>>> >>>>> --- >>>> >>>> 3) get_request_id API: >>>> >>>>> criteria = ( >>>>> - ('cert_storage_location', dogtag_constants.ALIAS_DIR, >>>>> - certmonger.NPATH), >>>>> - ('cert_nickname', nickname, None), >>>>> + ('cert_storage_location', dogtag_constants.ALIAS_DIR), >>>>> + ('cert_nickname', nickname), >>>>> ) >>>>> request_id = certmonger.get_request_id(criteria) >>>> >>>> Do we want to continue using the "criteria" object or should we rather >>>> switch >>>> to normal function options? I.e. rather using >>>> >>>> request_id = certmonger.get_request_id(cert_nickname=nickname, >>>> cert_storage_location=dogtag_constants.ALIAS_DIR) >>>> >>>> ? It would look more consistent with other calls. I am just asking, >>>> not insisting. >>> I've no preference here. It seems to be a very small change. Has anyone >>> a reason to do it one way and not the other? >> >> I think I used this criteria thing to avoid having a bazillion optional >> parameters and for future-proofing. I think at this point the list is >> probably pretty stable, so I'd base it on whether you care about having >> a whole ton of optional parameters or not (it has the advantage of >> self-documenting itself). >> > The list is probably stable but also really excessive. I don't think it > would help to have more than dozen optional parameters. So I prefer to > leave as-is and change it in future if it is wanted. >>>> >>>> 3) Starting function: >>>> >>>>> + try: >>>>> + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], >>>>> skip_output=True) >>>>> + except Exception, e: >>>>> + root_logger.error('Failed to start certmonger: %s' % e) >>>>> + raise e >>>> >>>> I see 2 issues related to this code: >>>> a) Do not call SYSTEMCTL directly. To be platform independent, >>>> rather use >>>> services.knownservices.messagebus.start() that is overridable by >>>> someone else >>>> porting to non-systemd platforms. >>> Is there anything that can't be done using ipalib/ipapython/ipaplatform? >> >> It can't make coffee (yet). >> >>>> b) In this case, do not use "raise e", but just "raise" to keep the >>>> exception >>>> stack trace intact for better debugging. >>> Every day there's something new to learn about python or FreeIPA. >>>> >>>> Both a) and b) should be fixed in other occasions and places. >>> I found only one occurence of a) issue. Is there some hidden or are you >>> talking about the whole FreeIPA project? >>>> >>>> 4) Feel free to add yourself to Authors section of this module. You >>>> refactored >>>> it greatly to earn it :-) >>> Done. >> >> You already import dbus, why also separately import DBusException? >> > Removed, thanks for noticing. >> rob >> 1) The patch needs to be rebased. 2) Please try to follow PEP8, at least in certmonger.py. 3) In certificate_renewal_update() in ipa-upgradeconfig you removed ca_name from criteria. 4) IMO renaming nickname to cert_nickname in dogtag_start_tracking() and stop_tracking() is unnecessary. We can keep calling request nicknames "request_id" and certificate nicknames "nickname" in our APIs. 5) I think it would be better to add a docstring to _cm_dbus_object.__init__() instead of doing this: # object is accesible over this DBus bus instance bus = None # DBus object path path = None # the actual DBus object obj = None # object interface name obj_dbus_if = None # object parent interface name parent_dbus_if = None # object inteface obj_if = None # property interface prop_if = None 6) In _start_certmonger(), please check if certmonger is already running before starting it, what applies to systemd might not apply to other init systems. 7) Do we ever need to connect to certmonger on the session bus? If not, there is no need to support it in _connect_to_certmonger(). 8) You should not ignore other criteria when 'nickname' is specified in _get_requests(). Use find_request_by_nickname only if 'nickname' is the only criterion, otherwise filter the result of get_requests, including 'nickname'. 9) IMO you can indeed remove request_cert(). 10) You forgot to port modify() and resubmit(). 11) As for get_pin(), it should be moved to ipapython.dogtag, because it is Dogtag related (you don't need to do it in this patch). I haven't done functional testing yet, expect more comments later. Honza -- Jan Cholasta From jcholast at redhat.com Wed Aug 27 09:22:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Aug 2014 11:22:37 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FC91EB.5020603@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> Message-ID: <53FDA35D.8040407@redhat.com> Dne 26.8.2014 v 15:55 Rob Crittenden napsal(a): > David Kupka wrote: >> On 08/26/2014 03:08 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 26.8.2014 v 13:01 David Kupka napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4481 >>> >>> Doing this will break ipa-client-automount and ipa-certupdate, because >>> they assume that api.env.host contains the hostname of the local system >>> (which is the default value). >> >> It looked suspiciously simple so I could expect that there is some catch. >>> >>> There is obviously some confusion about what the option should represent >>> (documentation says server hostname, code does client hostname), IMO we >>> should resolve that first. >> >> Ok, are there any suggestions? What is the desired state? > > AIUI the server option is deprecated because it wasn't being used, not > that it needed to be replaced. I believe that in most cases the server > name is pulled from the xmlrpc_uri. Yes, that's what the ticket says: . > > host has always meant the local host name. > > I think the man page is wrong. +1 > > rob > -- Jan Cholasta From dkupka at redhat.com Wed Aug 27 11:56:56 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 27 Aug 2014 13:56:56 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation Message-ID: <53FDC788.2060603@redhat.com> Usually it isn't wise to allow something like this. But in environment with broken DNS (described in ticket) there is probably not many alternatives. https://fedorahosted.org/freeipa/ticket/4444 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0011-Allow-user-to-force-Kerberos-realm-during-installati.patch Type: text/x-patch Size: 4895 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 27 12:24:43 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 27 Aug 2014 14:24:43 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <53FB5082.9020703@redhat.com> References: <53FB5082.9020703@redhat.com> Message-ID: <53FDCE0B.4070105@redhat.com> Patch modified according to jcholast's personally-delivered feedback: > 1) use action='append' instead of that ugly parsing > 2) do not use map(), FreeIPA doesn't like it On 08/25/2014 05:04 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/3575 > > Also should fix https://bugzilla.redhat.com/show_bug.cgi?id=1128380 as > installation is no longer interrupted when multiple IPs are resolved. > But it does not add the option to change the IP address during second run. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-2-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 16317 bytes Desc: not available URL: From mkosek at redhat.com Wed Aug 27 13:17:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Aug 2014 15:17:37 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <53FDCE0B.4070105@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> Message-ID: <53FDDA71.4010602@redhat.com> On 08/27/2014 02:24 PM, David Kupka wrote: ... > > 2) do not use map(), FreeIPA doesn't like it Well, it is not that FreeIPA does not like it, it is just more Pythonic to use list comprehension and not functional languages remnants in Python :-) From mbasti at redhat.com Wed Aug 27 13:22:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 Aug 2014 15:22:35 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind Message-ID: <53FDDB9B.2070401@redhat.com> Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0116-Refactoring-of-autobind-object_exists.patch Type: text/x-patch Size: 9888 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 27 14:49:44 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 27 Aug 2014 16:49:44 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FDA35D.8040407@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> Message-ID: <53FDF008.9040306@redhat.com> On 08/27/2014 11:22 AM, Jan Cholasta wrote: > Dne 26.8.2014 v 15:55 Rob Crittenden napsal(a): >> David Kupka wrote: >>> On 08/26/2014 03:08 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 26.8.2014 v 13:01 David Kupka napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4481 >>>> >>>> Doing this will break ipa-client-automount and ipa-certupdate, because >>>> they assume that api.env.host contains the hostname of the local system >>>> (which is the default value). >>> >>> It looked suspiciously simple so I could expect that there is some >>> catch. >>>> >>>> There is obviously some confusion about what the option should >>>> represent >>>> (documentation says server hostname, code does client hostname), IMO we >>>> should resolve that first. >>> >>> Ok, are there any suggestions? What is the desired state? >> >> AIUI the server option is deprecated because it wasn't being used, not >> that it needed to be replaced. I believe that in most cases the server >> name is pulled from the xmlrpc_uri. > > Yes, that's what the ticket says: > . > Ok, adding 'host' entry with local host name. >> >> host has always meant the local host name. >> >> I think the man page is wrong. > > +1 > Fixing the line in man page. >> >> rob >> > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0010-2-Add-host-setting-into-default.conf-configuration-fil.patch Type: text/x-patch Size: 3269 bytes Desc: not available URL: From ftweedal at redhat.com Thu Aug 28 00:36:41 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 Aug 2014 10:36:41 +1000 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <53FDDA71.4010602@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <53FDDA71.4010602@redhat.com> Message-ID: <20140828003641.GN10036@dhcp-40-8.bne.redhat.com> On Wed, Aug 27, 2014 at 03:17:37PM +0200, Martin Kosek wrote: > On 08/27/2014 02:24 PM, David Kupka wrote: > ... > > > 2) do not use map(), FreeIPA doesn't like it > > Well, it is not that FreeIPA does not like it, it is just more Pythonic to > use list comprehension and not functional languages remnants in Python :-) > Furthermore, if you go the comprehension route, a generator comprehension would be cheaper than a list comprehension. IMBO, this is the main reason to use a [generator] comprehension over ``map`` - in Python 2 at least. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From sbose at redhat.com Thu Aug 28 07:32:23 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 28 Aug 2014 09:32:23 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v4 Message-ID: <20140828073222.GB16631@localhost.localdomain> Hi, there is another update for the user views design http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust (diff can be found at http://www.freeipa.org/index.php?title=V4%2FMigrating_existing_environments_to_Trust&diff=9641&oldid=8696 ) The main change is that the view is not applied as early as possible on the IPA server, but as late as possible by view aware SSSD clients. There is no change for legacy systems, they still have to use the compat tree. There are a couple of reasons for this change: - it reduces to load on the server - clients will know the original data (default view) and so it will be easier for them to apply policies like e.g. sudo or HBAC rules which are assigned to the original object - although we concentrate on AD users in this first step which the new scheme adding support for IPA users will be much easier. As usual comments and suggestions are welcome. bye, Sumit From jcholast at redhat.com Thu Aug 28 12:01:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Aug 2014 14:01:36 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <53FDDB9B.2070401@redhat.com> References: <53FDDB9B.2070401@redhat.com> Message-ID: <53FF1A20.7010809@redhat.com> Hi, Dne 27.8.2014 v 15:22 Martin Basti napsal(a): > Patch attached. > 1) Please rename object_exists to entry_exists. 2) Use empty attribute list in get_entry() in object_exists/entry_exists. 3) Please update LDAPObject.get_dn_if_exists() to use object_exists/entry_exists. 4) I'm not a fan of how do_bind() is laid out, IMHO something like this would be better (untested): + def do_bind(self, dm_password=None, autobind=AUTOBIND_AUTO, timeout=DEFAULT_TIMEOUT): + if dm_password: + self.do_simple_bind(bindpw=dm_password, timeout=timeout) + return + + if autobind != AUTOBIND_DISABLED and os.getegid() == 0 and self.ldapi: + try: + # autobind + pw_name = pwd.getpwuid(os.geteuid()).pw_name + self.do_external_bind(pw_name, timeout=timeout) + return + except errors.NotFound: + if autobind == AUTOBIND_ENABLED: + # autobind was required and failed, raise + # exception that it failed + raise + + # Fall back + self.do_sasl_gssapi_bind(timeout=timeout) Honza -- Jan Cholasta From sbose at redhat.com Thu Aug 28 16:51:21 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 28 Aug 2014 18:51:21 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53ECEF70.40301@redhat.com> References: <53ECEF70.40301@redhat.com> Message-ID: <20140828165120.GF16631@localhost.localdomain> On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: > Hello, > > Following Petr remarks from the previous review, I modified the > original fix to move it only in '.update' files. > > Thanks > thierry > > From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 > From: "Thierry bordaz (tbordaz)" > Date: Thu, 7 Aug 2014 16:29:02 +0200 > Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins > > User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management > It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging > containers needs to be created. > Active: cn=users,cn=accounts,$SUFFIX > Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX > > Plugins scopes: > krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: > cn=accounts,SUFFIX > cn=deleted users,cn=accounts,cn=provisioning,SUFFIX > DNA: > cn=accounts,SUFFIX Hi Thierry, sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA plugin. We need to generate a UID for the trusted domain objects as well which are stored in cn=trusts,SUFFIX. The reason is that AD expects to be able to connect with a special trusted domain account. We generate this account on the fly based on the data in the trusted domain object hence we need a UID here. Since it looks like dnaScope is a SINGLE-VALUE attribute I think dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a different solution? bye, Sumit > > Plugins exclude subtree: > IPA UUID, Referential Integrity, memberOf: > cn=provisioning,SUFFIX > > Reviewed-By: Petr Viktorin > > https://fedorahosted.org/freeipa/ticket/3813 > --- From tbordaz at redhat.com Thu Aug 28 17:26:51 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 28 Aug 2014 19:26:51 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <20140828165120.GF16631@localhost.localdomain> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> Message-ID: <53FF665B.9050604@redhat.com> On 08/28/2014 06:51 PM, Sumit Bose wrote: > On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: >> Hello, >> >> Following Petr remarks from the previous review, I modified the >> original fix to move it only in '.update' files. >> >> Thanks >> thierry >> >> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 >> From: "Thierry bordaz (tbordaz)" >> Date: Thu, 7 Aug 2014 16:29:02 +0200 >> Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins >> >> User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management >> It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging >> containers needs to be created. >> Active: cn=users,cn=accounts,$SUFFIX >> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX >> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX >> >> Plugins scopes: >> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: >> cn=accounts,SUFFIX >> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX >> DNA: >> cn=accounts,SUFFIX > Hi Thierry, > > sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA > plugin. We need to generate a UID for the trusted domain objects as > well which are stored in cn=trusts,SUFFIX. The reason is that AD > expects to be able to connect with a special trusted domain account. We > generate this account on the fly based on the data in the trusted domain > object hence we need a UID here. > > Since it looks like dnaScope is a SINGLE-VALUE attribute I think > dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a > different solution? > > bye, > Sumit Hello Sumit, Thank you so much for having reviewed this fix and your important feedback ! Yes I had the same fear to restrict DNA to 'accounts'. I opened https://fedorahosted.org/389/ticket/47828 to allow to exclude a part of the DIT (here 'cn=provisioning,SUFFIX') from the scope of DNA plugin. Do you think it can address this concern ? thanks thierry > >> Plugins exclude subtree: >> IPA UUID, Referential Integrity, memberOf: >> cn=provisioning,SUFFIX >> >> Reviewed-By: Petr Viktorin >> >> https://fedorahosted.org/freeipa/ticket/3813 >> --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Aug 28 18:14:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 28 Aug 2014 14:14:26 -0400 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <1408481179.3505.6.camel@redhat.com> References: <1408481179.3505.6.camel@redhat.com> Message-ID: <1409249666.9966.4.camel@redhat.com> On Tue, 2014-08-19 at 16:46 -0400, Nathaniel McCallum wrote: > Also, remove the attempt to load the objectClasses when absent. This > never makes sense during an add operation. > > https://fedorahosted.org/freeipa/ticket/4455 I still need a review for this. We are trying to get this in 4.0.2. Nathaniel From sbose at redhat.com Thu Aug 28 18:30:16 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 28 Aug 2014 20:30:16 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53FF665B.9050604@redhat.com> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> <53FF665B.9050604@redhat.com> Message-ID: <20140828183015.GG16631@localhost.localdomain> On Thu, Aug 28, 2014 at 07:26:51PM +0200, thierry bordaz wrote: > On 08/28/2014 06:51 PM, Sumit Bose wrote: > >On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: > >>Hello, > >> > >> Following Petr remarks from the previous review, I modified the > >> original fix to move it only in '.update' files. > >> > >> Thanks > >> thierry > >> > >> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 > >>From: "Thierry bordaz (tbordaz)" > >>Date: Thu, 7 Aug 2014 16:29:02 +0200 > >>Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins > >> > >>User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >>It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging > >>containers needs to be created. > >> Active: cn=users,cn=accounts,$SUFFIX > >> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > >> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX > >> > >>Plugins scopes: > >> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: > >> cn=accounts,SUFFIX > >> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX > >> DNA: > >> cn=accounts,SUFFIX > >Hi Thierry, > > > >sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA > >plugin. We need to generate a UID for the trusted domain objects as > >well which are stored in cn=trusts,SUFFIX. The reason is that AD > >expects to be able to connect with a special trusted domain account. We > >generate this account on the fly based on the data in the trusted domain > >object hence we need a UID here. > > > >Since it looks like dnaScope is a SINGLE-VALUE attribute I think > >dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a > >different solution? > > > >bye, > >Sumit > > Hello Sumit, > > Thank you so much for having reviewed this fix and your important > feedback ! > > Yes I had the same fear to restrict DNA to 'accounts'. I opened > https://fedorahosted.org/389/ticket/47828 > to allow to exclude a part of the DIT (here > 'cn=provisioning,SUFFIX') from the scope of DNA plugin. > Do you think it can address this concern ? Yes, in general this would fix the issue. I'm just wondering if it wouldn't be easier with respect to coding and management to make dnaScope a multi-value attribute? Additionally a fix for IPA master is needed to make trusts work again. Would it be possible to tweak the filter to skip objects in cn=provisioning? E.g. do those objects have the ipaObject objectclass? bye, Sumit > > thanks > thierry > > > > >> Plugins exclude subtree: > >> IPA UUID, Referential Integrity, memberOf: > >> cn=provisioning,SUFFIX > >> > >>Reviewed-By: Petr Viktorin > >> > >>https://fedorahosted.org/freeipa/ticket/3813 > >>--- > From tbordaz at redhat.com Thu Aug 28 18:41:57 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 28 Aug 2014 20:41:57 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <20140828183015.GG16631@localhost.localdomain> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> <53FF665B.9050604@redhat.com> <20140828183015.GG16631@localhost.localdomain> Message-ID: <53FF77F5.2010706@redhat.com> On 08/28/2014 08:30 PM, Sumit Bose wrote: > On Thu, Aug 28, 2014 at 07:26:51PM +0200, thierry bordaz wrote: >> On 08/28/2014 06:51 PM, Sumit Bose wrote: >>> On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: >>>> Hello, >>>> >>>> Following Petr remarks from the previous review, I modified the >>>> original fix to move it only in '.update' files. >>>> >>>> Thanks >>>> thierry >>>> >>>> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 >>>> From: "Thierry bordaz (tbordaz)" >>>> Date: Thu, 7 Aug 2014 16:29:02 +0200 >>>> Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins >>>> >>>> User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management >>>> It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging >>>> containers needs to be created. >>>> Active: cn=users,cn=accounts,$SUFFIX >>>> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX >>>> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX >>>> >>>> Plugins scopes: >>>> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: >>>> cn=accounts,SUFFIX >>>> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX >>>> DNA: >>>> cn=accounts,SUFFIX >>> Hi Thierry, >>> >>> sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA >>> plugin. We need to generate a UID for the trusted domain objects as >>> well which are stored in cn=trusts,SUFFIX. The reason is that AD >>> expects to be able to connect with a special trusted domain account. We >>> generate this account on the fly based on the data in the trusted domain >>> object hence we need a UID here. >>> >>> Since it looks like dnaScope is a SINGLE-VALUE attribute I think >>> dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a >>> different solution? >>> >>> bye, >>> Sumit >> Hello Sumit, >> >> Thank you so much for having reviewed this fix and your important >> feedback ! >> >> Yes I had the same fear to restrict DNA to 'accounts'. I opened >> https://fedorahosted.org/389/ticket/47828 >> to allow to exclude a part of the DIT (here >> 'cn=provisioning,SUFFIX') from the scope of DNA plugin. >> Do you think it can address this concern ? > Yes, in general this would fix the issue. I'm just wondering if it > wouldn't be easier with respect to coding and management to make > dnaScope a multi-value attribute? > > Additionally a fix for IPA master is needed to make trusts work again. > Would it be possible to tweak the filter to skip objects in > cn=provisioning? E.g. do those objects have the ipaObject objectclass? Yes, stage entries have 'objectclass=ipaObject'. Do you suggest to remove this oc from staged entries, so that the filter will not match it ?. I have to check the impact of stage user not being ipaObject. thanks thierry > > bye, > Sumit > >> thanks >> thierry >> >>>> Plugins exclude subtree: >>>> IPA UUID, Referential Integrity, memberOf: >>>> cn=provisioning,SUFFIX >>>> >>>> Reviewed-By: Petr Viktorin >>>> >>>> https://fedorahosted.org/freeipa/ticket/3813 >>>> --- From sbose at redhat.com Thu Aug 28 18:58:00 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 28 Aug 2014 20:58:00 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <53FF77F5.2010706@redhat.com> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> <53FF665B.9050604@redhat.com> <20140828183015.GG16631@localhost.localdomain> <53FF77F5.2010706@redhat.com> Message-ID: <20140828185800.GI16631@localhost.localdomain> On Thu, Aug 28, 2014 at 08:41:57PM +0200, thierry bordaz wrote: > On 08/28/2014 08:30 PM, Sumit Bose wrote: > >On Thu, Aug 28, 2014 at 07:26:51PM +0200, thierry bordaz wrote: > >>On 08/28/2014 06:51 PM, Sumit Bose wrote: > >>>On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: > >>>>Hello, > >>>> > >>>> Following Petr remarks from the previous review, I modified the > >>>> original fix to move it only in '.update' files. > >>>> > >>>> Thanks > >>>> thierry > >>>> > >>>> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 > >>>>From: "Thierry bordaz (tbordaz)" > >>>>Date: Thu, 7 Aug 2014 16:29:02 +0200 > >>>>Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins > >>>> > >>>>User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >>>>It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging > >>>>containers needs to be created. > >>>> Active: cn=users,cn=accounts,$SUFFIX > >>>> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > >>>> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX > >>>> > >>>>Plugins scopes: > >>>> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: > >>>> cn=accounts,SUFFIX > >>>> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX > >>>> DNA: > >>>> cn=accounts,SUFFIX > >>>Hi Thierry, > >>> > >>>sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA > >>>plugin. We need to generate a UID for the trusted domain objects as > >>>well which are stored in cn=trusts,SUFFIX. The reason is that AD > >>>expects to be able to connect with a special trusted domain account. We > >>>generate this account on the fly based on the data in the trusted domain > >>>object hence we need a UID here. > >>> > >>>Since it looks like dnaScope is a SINGLE-VALUE attribute I think > >>>dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a > >>>different solution? > >>> > >>>bye, > >>>Sumit > >>Hello Sumit, > >> > >> Thank you so much for having reviewed this fix and your important > >> feedback ! > >> > >> Yes I had the same fear to restrict DNA to 'accounts'. I opened > >> https://fedorahosted.org/389/ticket/47828 > >> to allow to exclude a part of the DIT (here > >> 'cn=provisioning,SUFFIX') from the scope of DNA plugin. > >> Do you think it can address this concern ? > >Yes, in general this would fix the issue. I'm just wondering if it > >wouldn't be easier with respect to coding and management to make > >dnaScope a multi-value attribute? > > > >Additionally a fix for IPA master is needed to make trusts work again. > >Would it be possible to tweak the filter to skip objects in > >cn=provisioning? E.g. do those objects have the ipaObject objectclass? > Yes, stage entries have 'objectclass=ipaObject'. > Do you suggest to remove this oc from staged entries, so that the filter > will not match it ?. I have to check the impact of stage user not being > ipaObject. no, it was just a suggestion. Maybe we can use entryDN like: (&(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject))(!(entrydn=*cn=provisioning*))) bye, Sumit > > thanks > thierry > > > >bye, > >Sumit > > > >> thanks > >> thierry > >> > >>>> Plugins exclude subtree: > >>>> IPA UUID, Referential Integrity, memberOf: > >>>> cn=provisioning,SUFFIX > >>>> > >>>>Reviewed-By: Petr Viktorin > >>>> > >>>>https://fedorahosted.org/freeipa/ticket/3813 > >>>>--- > From npmccallum at redhat.com Fri Aug 29 02:54:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 28 Aug 2014 22:54:51 -0400 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates Message-ID: <1409280891.9966.11.camel@redhat.com> This prevents any local attempt at rapid token code replay. If two token codes hit the system at roughly the same moment, only the first write will succeed. All subsequent authentications will fail. This obviates the need for an OTP authentication lock. https://fedorahosted.org/freeipa/ticket/4493 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0062-Use-delete-add-for-OTP-counter-watermark-updates.patch Type: text/x-patch Size: 5063 bytes Desc: not available URL: From pvoborni at redhat.com Fri Aug 29 08:40:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Aug 2014 10:40:43 +0200 Subject: [Freeipa-devel] [PATCH] 745 webui: notify psw change success only once Message-ID: <54003C8B.6050109@redhat.com> Password change initiated from header menu notified success twice. First one in `dialogs.password.dialog` and second one in a success callback. The second notification was removed. Caused by: https://fedorahosted.org/freeipa/changeset/870db2f677dff01750aeec104c90fce3ca0e54be/ -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0745-webui-notify-psw-change-success-only-once.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: From sbose at redhat.com Fri Aug 29 09:26:15 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 Aug 2014 11:26:15 +0200 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations In-Reply-To: <20140821104335.GX4748@redhat.com> References: <20140821104335.GX4748@redhat.com> Message-ID: <20140829092615.GL16631@localhost.localdomain> On Thu, Aug 21, 2014 at 01:43:35PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached patchset improves trust operations: > > 1. Ensures we only allow establishing trust to forest root domain > 2. Ensures that we select primary domain controllers > 3. Ensures first create trust and later set it to transitive state and > update forest topology > 4. Relaxes filtering of domains obtained from AD side to allow some of > possible topology combinations which were not accounted for > previously > 5. Reverts to any PDC rather than a closest one if closest one is not > available due to site mismanagement. > > Affected tickets: > https://fedorahosted.org/freeipa/ticket/4463 > https://fedorahosted.org/freeipa/ticket/4479 > https://fedorahosted.org/freeipa/ticket/4458 > > The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 > branches). > > They were tested with Windows Server 2008R2 and Windows Server 2012 > environments. Patches are looking good and I didn't found any issue in my tests, ACK. I only have a question about 158. I wonder if the admin calling ipa trust-add would be interested to see that setting the transitive attribute failed? Currently it is buried in the logs so chances are the nobody will recognise it. bye, Sumit > > -- > / Alexander Bokovoy From abokovoy at redhat.com Fri Aug 29 09:35:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Aug 2014 12:35:05 +0300 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations In-Reply-To: <20140829092615.GL16631@localhost.localdomain> References: <20140821104335.GX4748@redhat.com> <20140829092615.GL16631@localhost.localdomain> Message-ID: <20140829093505.GE29954@redhat.com> On Fri, 29 Aug 2014, Sumit Bose wrote: >On Thu, Aug 21, 2014 at 01:43:35PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> Attached patchset improves trust operations: >> >> 1. Ensures we only allow establishing trust to forest root domain >> 2. Ensures that we select primary domain controllers >> 3. Ensures first create trust and later set it to transitive state and >> update forest topology >> 4. Relaxes filtering of domains obtained from AD side to allow some of >> possible topology combinations which were not accounted for >> previously >> 5. Reverts to any PDC rather than a closest one if closest one is not >> available due to site mismanagement. >> >> Affected tickets: >> https://fedorahosted.org/freeipa/ticket/4463 >> https://fedorahosted.org/freeipa/ticket/4479 >> https://fedorahosted.org/freeipa/ticket/4458 >> >> The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 >> branches). >> >> They were tested with Windows Server 2008R2 and Windows Server 2012 >> environments. > >Patches are looking good and I didn't found any issue in my tests, ACK. > >I only have a question about 158. I wonder if the admin calling ipa >trust-add would be interested to see that setting the transitive >attribute failed? Currently it is buried in the logs so chances are the >nobody will recognise it. Unfortunately, we don't have means in the framework to return warnings nicely formatted and separated from the original output. Thus, I decided to leave it as it is, without additional Python exception raising because one can easily see the error message when enabling debug output, even without restarting Apache. -- / Alexander Bokovoy From sbose at redhat.com Fri Aug 29 09:56:13 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 Aug 2014 11:56:13 +0200 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations In-Reply-To: <20140829093505.GE29954@redhat.com> References: <20140821104335.GX4748@redhat.com> <20140829092615.GL16631@localhost.localdomain> <20140829093505.GE29954@redhat.com> Message-ID: <20140829095613.GM16631@localhost.localdomain> On Fri, Aug 29, 2014 at 12:35:05PM +0300, Alexander Bokovoy wrote: > On Fri, 29 Aug 2014, Sumit Bose wrote: > >On Thu, Aug 21, 2014 at 01:43:35PM +0300, Alexander Bokovoy wrote: > >>Hi! > >> > >>Attached patchset improves trust operations: > >> > >>1. Ensures we only allow establishing trust to forest root domain > >>2. Ensures that we select primary domain controllers > >>3. Ensures first create trust and later set it to transitive state and > >> update forest topology > >>4. Relaxes filtering of domains obtained from AD side to allow some of > >> possible topology combinations which were not accounted for > >> previously > >>5. Reverts to any PDC rather than a closest one if closest one is not > >> available due to site mismanagement. > >> > >>Affected tickets: > >> https://fedorahosted.org/freeipa/ticket/4463 > >> https://fedorahosted.org/freeipa/ticket/4479 > >> https://fedorahosted.org/freeipa/ticket/4458 > >> > >>The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 > >>branches). > >> > >>They were tested with Windows Server 2008R2 and Windows Server 2012 > >>environments. > > > >Patches are looking good and I didn't found any issue in my tests, ACK. > > > >I only have a question about 158. I wonder if the admin calling ipa > >trust-add would be interested to see that setting the transitive > >attribute failed? Currently it is buried in the logs so chances are the > >nobody will recognise it. > Unfortunately, we don't have means in the framework to return warnings > nicely formatted and separated from the original output. Thus, I decided > to leave it as it is, without additional Python exception raising > because one can easily see the error message when enabling debug output, > even without restarting Apache. ok, I see. bye, Sumit > -- > / Alexander Bokovoy From dkupka at redhat.com Fri Aug 29 12:34:33 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 29 Aug 2014 14:34:33 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <53FD9F69.4010700@redhat.com> References: <53F2F71E.8050802@redhat.com> <53F30398.1030905@redhat.com> <53F367A4.9000802@redhat.com> <53F370F6.9030700@redhat.com> <53FB3C91.7010508@redhat.com> <53FD9F69.4010700@redhat.com> Message-ID: <54007359.1000102@redhat.com> Hope, I've addressed all the issues (except 9 and 11, inline). Let's go for another round :-) On 08/27/2014 11:05 AM, Jan Cholasta wrote: > Hi, > > Dne 25.8.2014 v 15:39 David Kupka napsal(a): >> On 08/19/2014 05:44 PM, Rob Crittenden wrote: >>> David Kupka wrote: >>>> On 08/19/2014 09:58 AM, Martin Kosek wrote: >>>>> On 08/19/2014 09:05 AM, David Kupka wrote: >>>>>> FreeIPA will use certmonger D-Bus API as discussed in this thread >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-July/msg00304.html >>>>>> >>>>>> This change should prevent hard-to-reproduce bugs like >>>>>> https://fedorahosted.org/freeipa/ticket/4280 >>>>> >>>>> Thanks for this effort, the updated certmonger module looks much >>>>> better! This >>>>> will help us get rid of the non-standard communication with >>>>> certmonger. >>>>> >>>>> Just couple initial comments from me by reading the code: >>>>> >>>>> 1) Testing needs fixed version of certmonger, right? This needs to be >>>>> spelled >>>>> out right with the patch. >>>> Yes, certmonger 0.75.13 and above should be fine according ticket >>>> https://fedorahosted.org/certmonger/ticket/36. Added to patch >>>> description. >>> >>> You should update the spec to set the minimum version as well. >> Sure, thanks. >>> >>>>> >>>>> 2) Description text in patches is cheap, do not be afraid to use it >>>>> and >>>>> describe what you did and why. Link to the ticket is missing in the >>>>> description >>>>> as well: >>>> Ok, increased verbosity a bit :-) >>>>> >>>>>> Subject: [PATCH] Use certmonger D-Bus API instead of messing with its >>>>>> files. >>>>>> >>>>>> --- >>>>> >>>>> 3) get_request_id API: >>>>> >>>>>> criteria = ( >>>>>> - ('cert_storage_location', dogtag_constants.ALIAS_DIR, >>>>>> - certmonger.NPATH), >>>>>> - ('cert_nickname', nickname, None), >>>>>> + ('cert_storage_location', dogtag_constants.ALIAS_DIR), >>>>>> + ('cert_nickname', nickname), >>>>>> ) >>>>>> request_id = certmonger.get_request_id(criteria) >>>>> >>>>> Do we want to continue using the "criteria" object or should we rather >>>>> switch >>>>> to normal function options? I.e. rather using >>>>> >>>>> request_id = certmonger.get_request_id(cert_nickname=nickname, >>>>> cert_storage_location=dogtag_constants.ALIAS_DIR) >>>>> >>>>> ? It would look more consistent with other calls. I am just asking, >>>>> not insisting. >>>> I've no preference here. It seems to be a very small change. Has anyone >>>> a reason to do it one way and not the other? >>> >>> I think I used this criteria thing to avoid having a bazillion optional >>> parameters and for future-proofing. I think at this point the list is >>> probably pretty stable, so I'd base it on whether you care about having >>> a whole ton of optional parameters or not (it has the advantage of >>> self-documenting itself). >>> >> The list is probably stable but also really excessive. I don't think it >> would help to have more than dozen optional parameters. So I prefer to >> leave as-is and change it in future if it is wanted. >>>>> >>>>> 3) Starting function: >>>>> >>>>>> + try: >>>>>> + ipautil.run([paths.SYSTEMCTL, 'start', 'certmonger'], >>>>>> skip_output=True) >>>>>> + except Exception, e: >>>>>> + root_logger.error('Failed to start certmonger: %s' % e) >>>>>> + raise e >>>>> >>>>> I see 2 issues related to this code: >>>>> a) Do not call SYSTEMCTL directly. To be platform independent, >>>>> rather use >>>>> services.knownservices.messagebus.start() that is overridable by >>>>> someone else >>>>> porting to non-systemd platforms. >>>> Is there anything that can't be done using >>>> ipalib/ipapython/ipaplatform? >>> >>> It can't make coffee (yet). >>> >>>>> b) In this case, do not use "raise e", but just "raise" to keep the >>>>> exception >>>>> stack trace intact for better debugging. >>>> Every day there's something new to learn about python or FreeIPA. >>>>> >>>>> Both a) and b) should be fixed in other occasions and places. >>>> I found only one occurence of a) issue. Is there some hidden or are you >>>> talking about the whole FreeIPA project? >>>>> >>>>> 4) Feel free to add yourself to Authors section of this module. You >>>>> refactored >>>>> it greatly to earn it :-) >>>> Done. >>> >>> You already import dbus, why also separately import DBusException? >>> >> Removed, thanks for noticing. >>> rob >>> > > 1) The patch needs to be rebased. > > > 2) Please try to follow PEP8, at least in certmonger.py. > > > 3) In certificate_renewal_update() in ipa-upgradeconfig you removed > ca_name from criteria. > > > 4) IMO renaming nickname to cert_nickname in dogtag_start_tracking() and > stop_tracking() is unnecessary. We can keep calling request nicknames > "request_id" and certificate nicknames "nickname" in our APIs. > > > 5) I think it would be better to add a docstring to > _cm_dbus_object.__init__() instead of doing this: > > # object is accesible over this DBus bus instance > bus = None > # DBus object path > path = None > # the actual DBus object > obj = None > # object interface name > obj_dbus_if = None > # object parent interface name > parent_dbus_if = None > # object inteface > obj_if = None > # property interface > prop_if = None > > > 6) In _start_certmonger(), please check if certmonger is already running > before starting it, what applies to systemd might not apply to other > init systems. > > > 7) Do we ever need to connect to certmonger on the session bus? If not, > there is no need to support it in _connect_to_certmonger(). > > > 8) You should not ignore other criteria when 'nickname' is specified in > _get_requests(). Use find_request_by_nickname only if 'nickname' is the > only criterion, otherwise filter the result of get_requests, including > 'nickname'. > > > 9) IMO you can indeed remove request_cert(). Not sure, it is used in self-test although I doubt anyone ever ran it. > > > 10) You forgot to port modify() and resubmit(). > > > 11) As for get_pin(), it should be moved to ipapython.dogtag, because it > is Dogtag related (you don't need to do it in this patch). > This patch is ugly enough. I will create a separate one for this. > > I haven't done functional testing yet, expect more comments later. > > Honza > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-4-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 32144 bytes Desc: not available URL: From tbordaz at redhat.com Fri Aug 29 12:52:16 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 29 Aug 2014 14:52:16 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <20140828185800.GI16631@localhost.localdomain> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> <53FF665B.9050604@redhat.com> <20140828183015.GG16631@localhost.localdomain> <53FF77F5.2010706@redhat.com> <20140828185800.GI16631@localhost.localdomain> Message-ID: <54007780.4040005@redhat.com> On 08/28/2014 08:58 PM, Sumit Bose wrote: > On Thu, Aug 28, 2014 at 08:41:57PM +0200, thierry bordaz wrote: >> On 08/28/2014 08:30 PM, Sumit Bose wrote: >>> On Thu, Aug 28, 2014 at 07:26:51PM +0200, thierry bordaz wrote: >>>> On 08/28/2014 06:51 PM, Sumit Bose wrote: >>>>> On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> Following Petr remarks from the previous review, I modified the >>>>>> original fix to move it only in '.update' files. >>>>>> >>>>>> Thanks >>>>>> thierry >>>>>> >>>>>> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 >>>>>> From: "Thierry bordaz (tbordaz)" >>>>>> Date: Thu, 7 Aug 2014 16:29:02 +0200 >>>>>> Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins >>>>>> >>>>>> User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management >>>>>> It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging >>>>>> containers needs to be created. >>>>>> Active: cn=users,cn=accounts,$SUFFIX >>>>>> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX >>>>>> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX >>>>>> >>>>>> Plugins scopes: >>>>>> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: >>>>>> cn=accounts,SUFFIX >>>>>> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX >>>>>> DNA: >>>>>> cn=accounts,SUFFIX >>>>> Hi Thierry, >>>>> >>>>> sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA >>>>> plugin. We need to generate a UID for the trusted domain objects as >>>>> well which are stored in cn=trusts,SUFFIX. The reason is that AD >>>>> expects to be able to connect with a special trusted domain account. We >>>>> generate this account on the fly based on the data in the trusted domain >>>>> object hence we need a UID here. >>>>> >>>>> Since it looks like dnaScope is a SINGLE-VALUE attribute I think >>>>> dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a >>>>> different solution? >>>>> >>>>> bye, >>>>> Sumit >>>> Hello Sumit, >>>> >>>> Thank you so much for having reviewed this fix and your important >>>> feedback ! >>>> >>>> Yes I had the same fear to restrict DNA to 'accounts'. I opened >>>> https://fedorahosted.org/389/ticket/47828 >>>> to allow to exclude a part of the DIT (here >>>> 'cn=provisioning,SUFFIX') from the scope of DNA plugin. >>>> Do you think it can address this concern ? >>> Yes, in general this would fix the issue. I'm just wondering if it >>> wouldn't be easier with respect to coding and management to make >>> dnaScope a multi-value attribute? >>> >>> Additionally a fix for IPA master is needed to make trusts work again. >>> Would it be possible to tweak the filter to skip objects in >>> cn=provisioning? E.g. do those objects have the ipaObject objectclass? >> Yes, stage entries have 'objectclass=ipaObject'. >> Do you suggest to remove this oc from staged entries, so that the filter >> will not match it ?. I have to check the impact of stage user not being >> ipaObject. > no, it was just a suggestion. Maybe we can use entryDN like: > > (&(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject))(!(entrydn=*cn=provisioning*))) Hi Sumit, Ho great I like this idea ! Unfortunately it does not work as expected. In fact 'entrydn' is not present in the added entry when the DNA preop-plugin is called (it is added later). As stage entries may get added with an external provisioning system, I can not rely on any fixed attribute value to skip them from DNA. Also setting this filter and adding a stage user had a curious impact as it sets uidNumber/gidNumber to -2. I believe this is because the filter is true in the preadd (entrydn does not exist) so dna preop set the uid/gidNumber to -2 and when the bepreop is called (entrydn has been added) filter is false and the transient value -2 is not set to -1 :-) So I rely on checking the entry DN vs the scope to prevent DNA to allocated number and I will work on ticket 47828. thanks thierry > > bye, > Sumit > >> thanks >> thierry >>> bye, >>> Sumit >>> >>>> thanks >>>> thierry >>>> >>>>>> Plugins exclude subtree: >>>>>> IPA UUID, Referential Integrity, memberOf: >>>>>> cn=provisioning,SUFFIX >>>>>> >>>>>> Reviewed-By: Petr Viktorin >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3813 >>>>>> --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Aug 29 12:59:31 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 Aug 2014 08:59:31 -0400 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates In-Reply-To: <1409280891.9966.11.camel@redhat.com> References: <1409280891.9966.11.camel@redhat.com> Message-ID: <1409317171.6483.54.camel@willson.usersys.redhat.com> On Thu, 2014-08-28 at 22:54 -0400, Nathaniel McCallum wrote: > This prevents any local attempt at rapid token code replay. If two > token codes hit the system at roughly the same moment, only the > first write will succeed. All subsequent authentications will fail. > > This obviates the need for an OTP authentication lock. > > https://fedorahosted.org/freeipa/ticket/4493 LGTM. Simo. From mkosek at redhat.com Fri Aug 29 14:24:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Aug 2014 16:24:34 +0200 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations In-Reply-To: <20140829093505.GE29954@redhat.com> References: <20140821104335.GX4748@redhat.com> <20140829092615.GL16631@localhost.localdomain> <20140829093505.GE29954@redhat.com> Message-ID: <54008D22.1020607@redhat.com> On 08/29/2014 11:35 AM, Alexander Bokovoy wrote: > On Fri, 29 Aug 2014, Sumit Bose wrote: >> On Thu, Aug 21, 2014 at 01:43:35PM +0300, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached patchset improves trust operations: >>> >>> 1. Ensures we only allow establishing trust to forest root domain >>> 2. Ensures that we select primary domain controllers >>> 3. Ensures first create trust and later set it to transitive state and >>> update forest topology >>> 4. Relaxes filtering of domains obtained from AD side to allow some of >>> possible topology combinations which were not accounted for >>> previously >>> 5. Reverts to any PDC rather than a closest one if closest one is not >>> available due to site mismanagement. >>> >>> Affected tickets: >>> https://fedorahosted.org/freeipa/ticket/4463 >>> https://fedorahosted.org/freeipa/ticket/4479 >>> https://fedorahosted.org/freeipa/ticket/4458 >>> >>> The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 >>> branches). >>> >>> They were tested with Windows Server 2008R2 and Windows Server 2012 >>> environments. >> >> Patches are looking good and I didn't found any issue in my tests, ACK. >> >> I only have a question about 158. I wonder if the admin calling ipa >> trust-add would be interested to see that setting the transitive >> attribute failed? Currently it is buried in the logs so chances are the >> nobody will recognise it. > Unfortunately, we don't have means in the framework to return warnings > nicely formatted and separated from the original output. What about http://www.freeipa.org/page/V3/Messages? We can do warnings already: # ipa dnszone-add example.test --forwarder 10.0.0.1 --name-server=`hostname`. Administrator e-mail address [hostmaster.example.test.]: ipa: WARNING: DNS forwarder semantics changed since IPA 4.0. You may want to use forward zones (dnsforwardzone-*) instead. For more details read the docs. Zone name: example.test. Active zone: TRUE Zone forwarders: 10.0.0.1 Authoritative nameserver: ipa.mkosek-fedora20.test. Administrator e-mail address: hostmaster.example.test. SOA serial: 1409322255 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant MKOSEK-FEDORA20.TEST krb5-self * A; grant MKOSEK-FEDORA20.TEST krb5-self * AAAA; grant MKOSEK-FEDORA20.TEST krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; > Thus, I decided > to leave it as it is, without additional Python exception raising > because one can easily see the error message when enabling debug output, > even without restarting Apache. From tbordaz at redhat.com Fri Aug 29 14:36:24 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 29 Aug 2014 16:36:24 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <20140828185800.GI16631@localhost.localdomain> References: <53ECEF70.40301@redhat.com> <20140828165120.GF16631@localhost.localdomain> <53FF665B.9050604@redhat.com> <20140828183015.GG16631@localhost.localdomain> <53FF77F5.2010706@redhat.com> <20140828185800.GI16631@localhost.localdomain> Message-ID: <54008FE8.2050302@redhat.com> Hello, Partially reverts commit of 04ea75a7a5109907ede2a0216bd39fac46a992c0 The fix 04ea75a7a5109907ede2a0216bd39fac46a992c0 restricted the DNA scope to 'cn=accounts,SUFFIX' . This was invalid. If you run recent master instance (with that scoping) you may need to reinstall IPA or do the following: ldapmodify -h .. -p 389 -D "cn=directory manager" -w xxx cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: dnaScope dnaScope: $SUFFIX ipactl restart Thanks Sumit for this catch. The new patch revert the change in dna update. thierry On 08/28/2014 08:58 PM, Sumit Bose wrote: > On Thu, Aug 28, 2014 at 08:41:57PM +0200, thierry bordaz wrote: >> On 08/28/2014 08:30 PM, Sumit Bose wrote: >>> On Thu, Aug 28, 2014 at 07:26:51PM +0200, thierry bordaz wrote: >>>> On 08/28/2014 06:51 PM, Sumit Bose wrote: >>>>> On Thu, Aug 14, 2014 at 07:18:40PM +0200, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> Following Petr remarks from the previous review, I modified the >>>>>> original fix to move it only in '.update' files. >>>>>> >>>>>> Thanks >>>>>> thierry >>>>>> >>>>>> From d45e78dfeb7761348c464b3bb3956656bb115ce0 Mon Sep 17 00:00:00 2001 >>>>>> From: "Thierry bordaz (tbordaz)" >>>>>> Date: Thu, 7 Aug 2014 16:29:02 +0200 >>>>>> Subject: [PATCH] User Life Cycle: create containers and scoping DS plugins >>>>>> >>>>>> User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management >>>>>> It manages 3 containers (Staging, Active, Delete). At install/upgrade Delete and Staging >>>>>> containers needs to be created. >>>>>> Active: cn=users,cn=accounts,$SUFFIX >>>>>> Delete: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX >>>>>> Stage: cn=staged users ,cn=accounts,cn=provisioning,$SUFFIX >>>>>> >>>>>> Plugins scopes: >>>>>> krbPrincipalName, krbCanonicalName, ipaUniqueID, uid: >>>>>> cn=accounts,SUFFIX >>>>>> cn=deleted users,cn=accounts,cn=provisioning,SUFFIX >>>>>> DNA: >>>>>> cn=accounts,SUFFIX >>>>> Hi Thierry, >>>>> >>>>> sorry for being late, but cn=accounts,SUFFIX is too strict for the DNA >>>>> plugin. We need to generate a UID for the trusted domain objects as >>>>> well which are stored in cn=trusts,SUFFIX. The reason is that AD >>>>> expects to be able to connect with a special trusted domain account. We >>>>> generate this account on the fly based on the data in the trusted domain >>>>> object hence we need a UID here. >>>>> >>>>> Since it looks like dnaScope is a SINGLE-VALUE attribute I think >>>>> dnaScope has to be reverted to SUFFIX. Do you see any drawbacks or a >>>>> different solution? >>>>> >>>>> bye, >>>>> Sumit >>>> Hello Sumit, >>>> >>>> Thank you so much for having reviewed this fix and your important >>>> feedback ! >>>> >>>> Yes I had the same fear to restrict DNA to 'accounts'. I opened >>>> https://fedorahosted.org/389/ticket/47828 >>>> to allow to exclude a part of the DIT (here >>>> 'cn=provisioning,SUFFIX') from the scope of DNA plugin. >>>> Do you think it can address this concern ? >>> Yes, in general this would fix the issue. I'm just wondering if it >>> wouldn't be easier with respect to coding and management to make >>> dnaScope a multi-value attribute? >>> >>> Additionally a fix for IPA master is needed to make trusts work again. >>> Would it be possible to tweak the filter to skip objects in >>> cn=provisioning? E.g. do those objects have the ipaObject objectclass? >> Yes, stage entries have 'objectclass=ipaObject'. >> Do you suggest to remove this oc from staged entries, so that the filter >> will not match it ?. I have to check the impact of stage user not being >> ipaObject. > no, it was just a suggestion. Maybe we can use entryDN like: > > (&(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject))(!(entrydn=*cn=provisioning*))) > > bye, > Sumit > >> thanks >> thierry >>> bye, >>> Sumit >>> >>>> thanks >>>> thierry >>>> >>>>>> Plugins exclude subtree: >>>>>> IPA UUID, Referential Integrity, memberOf: >>>>>> cn=provisioning,SUFFIX >>>>>> >>>>>> Reviewed-By: Petr Viktorin >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3813 >>>>>> --- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0001-4-User-Life-Cycle-new-containers-and-DS-plugin-scope.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: From abokovoy at redhat.com Fri Aug 29 14:39:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Aug 2014 17:39:29 +0300 Subject: [Freeipa-devel] [PATCH] 0154-0158 improve trust operations In-Reply-To: <54008D22.1020607@redhat.com> References: <20140821104335.GX4748@redhat.com> <20140829092615.GL16631@localhost.localdomain> <20140829093505.GE29954@redhat.com> <54008D22.1020607@redhat.com> Message-ID: <20140829143929.GL29954@redhat.com> On Fri, 29 Aug 2014, Martin Kosek wrote: >On 08/29/2014 11:35 AM, Alexander Bokovoy wrote: >> On Fri, 29 Aug 2014, Sumit Bose wrote: >>> On Thu, Aug 21, 2014 at 01:43:35PM +0300, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached patchset improves trust operations: >>>> >>>> 1. Ensures we only allow establishing trust to forest root domain >>>> 2. Ensures that we select primary domain controllers >>>> 3. Ensures first create trust and later set it to transitive state and >>>> update forest topology >>>> 4. Relaxes filtering of domains obtained from AD side to allow some of >>>> possible topology combinations which were not accounted for >>>> previously >>>> 5. Reverts to any PDC rather than a closest one if closest one is not >>>> available due to site mismanagement. >>>> >>>> Affected tickets: >>>> https://fedorahosted.org/freeipa/ticket/4463 >>>> https://fedorahosted.org/freeipa/ticket/4479 >>>> https://fedorahosted.org/freeipa/ticket/4458 >>>> >>>> The patches should apply cleanly to master and ipa-3-3 (and 4-0/4-1 >>>> branches). >>>> >>>> They were tested with Windows Server 2008R2 and Windows Server 2012 >>>> environments. >>> >>> Patches are looking good and I didn't found any issue in my tests, ACK. >>> >>> I only have a question about 158. I wonder if the admin calling ipa >>> trust-add would be interested to see that setting the transitive >>> attribute failed? Currently it is buried in the logs so chances are the >>> nobody will recognise it. >> Unfortunately, we don't have means in the framework to return warnings >> nicely formatted and separated from the original output. > >What about http://www.freeipa.org/page/V3/Messages? We can do warnings already: > ># ipa dnszone-add example.test --forwarder 10.0.0.1 --name-server=`hostname`. >Administrator e-mail address [hostmaster.example.test.]: >ipa: WARNING: DNS forwarder semantics changed since IPA 4.0. >You may want to use forward zones (dnsforwardzone-*) instead. >For more details read the docs. We need to understand consequences. If setting transitive flag on the trust will fail, what does it mean for the trust's use? And what does it mean in the context of one-way trust work? Adding to that, there is another consideration: which leg of the trust failed? With two-way trust we have four of them, with one-way there will be two legs. Since code is structured in a such way that all of these calls are symmetrical, we'll need to pass up the warning to some higher caller and there decide what has happened. The task quickly goes beyond a simple use of messages. I don't have myself all answers yet. :) -- / Alexander Bokovoy From pvoborni at redhat.com Fri Aug 29 16:00:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 29 Aug 2014 18:00:31 +0200 Subject: [Freeipa-devel] [PATCH] 746-747 append domain into network.negotiate-auth.trusted-uris Message-ID: <5400A39F.7000905@redhat.com> [PATCH] 746 webui: append network.negotiate-auth.trusted-uris https://fedorahosted.org/freeipa/ticket/4478 [PATCH] 747 install: create ff krb extension on every install, replica install and upgrade We don't want to copy the extension from master to replica because the replica may use newer version of FreeIPA and therefore the extension code might be obsolete. Same reason for upgrades. https://fedorahosted.org/freeipa/ticket/4478 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0747-install-create-ff-krb-extension-on-every-install-rep.patch Type: text/x-patch Size: 3683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0746-webui-append-network.negotiate-auth.trusted-uris.patch Type: text/x-patch Size: 1987 bytes Desc: not available URL: