From mkosek at redhat.com Mon Sep 1 06:31:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Sep 2014 08:31:10 +0200 Subject: [Freeipa-devel] [Patch] 0001-2 User Life Cycle: create containers and scoping DS plugins In-Reply-To: <54008FE8.2050302@redhat.com> 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> <54008FE8.2050302@redhat.com> Message-ID: <540412AE.2080900@redhat.com> Thanks. ACK, pushed to master. Martin On 08/29/2014 04:36 PM, thierry bordaz wrote: > 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 >>>>>>> --- > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From mkosek at redhat.com Mon Sep 1 08:24:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Sep 2014 10:24:14 +0200 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: <54042D2E.1020203@redhat.com> On 08/29/2014 11:26 AM, 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. > > bye, > Sumit Pushed all patches to master, ipa-4-1, ipa-4-0 and ipa-3-3. Martin From mkosek at redhat.com Mon Sep 1 09:01:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Sep 2014 11:01:23 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <20140825173629.GO10132@hendrix.redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> Message-ID: <540435E3.3000207@redhat.com> On 08/25/2014 07:36 PM, Jakub Hrozek wrote: > Hi, > > ipa-client-install was failing for me on a fresh F-21 machine until I > manually dragged in python-backports-ssl_match_hostname Umh, thanks for the fix, but I do not think this spec is actually used in our build process. The last update was done in 2008 :-) We only use the global freeipa.spec.in and build client from that. I think we should just delete the old one. Martin From lkrispen at redhat.com Mon Sep 1 11:07:43 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 01 Sep 2014 13:07:43 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] ticket #4302 Move replication topology to the shared tree Message-ID: <5404537F.706@redhat.com> Hello, attached is a patch for the plugin part for this enhancement: https://fedorahosted.org/freeipa/ticket/4302 I will now implement the management commands and continue testing in a real setup, so there will probably changes when problems are detected or clarifications added. But I would be interested to get feedback on the approach in the current state. Thanks, Ludwig -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ticket-4302-first-version.patch Type: text/x-patch Size: 63595 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 1 11:08:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 01 Sep 2014 13:08:09 +0200 Subject: [Freeipa-devel] [PATCH] 0003 User life cycle: new stageuser plugin with add verb In-Reply-To: <53E4D6AE.6050505@redhat.com> References: <53E4D6AE.6050505@redhat.com> Message-ID: <54045399.3030404@redhat.com> On 08/08/2014 03:54 PM, thierry bordaz wrote: > 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 Avoid `from ipalib.plugins.baseldap import *` in new code; instead import the module itself and use e.g. `baseldap.LDAPObject`. The stageuser help (docstring) is copied from the user plugin, and discusses things like account lockout and disabling users. It should rather explain what stageuser itself does. (And I don't very much like the Note about the interface being badly designed...) Also decide if the docs should call it "staged user" or "stage user" or "stageuser". A lot of the code is copied and pasted over from the users plugin. Don't do that. Either import things (e.g. validate_nsaccountlock) from the users plugin, or move the reused code into a shared module. For the `user` object, since so much is the same, it might be best to create a common base class for user and stageuser; and similarly for the Command plugins. The default permissions need different names, and you don't need another copy of the 'non_object' ones. Also, run the makeaci script. -- Petr? From jhrozek at redhat.com Mon Sep 1 11:15:02 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 1 Sep 2014 13:15:02 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <540435E3.3000207@redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> <540435E3.3000207@redhat.com> Message-ID: <20140901111502.GH3139@hendrix.brq.redhat.com> On Mon, Sep 01, 2014 at 11:01:23AM +0200, Martin Kosek wrote: > On 08/25/2014 07:36 PM, Jakub Hrozek wrote: > > Hi, > > > > ipa-client-install was failing for me on a fresh F-21 machine until I > > manually dragged in python-backports-ssl_match_hostname > > Umh, thanks for the fix, but I do not think this spec is actually used in our > build process. The last update was done in 2008 :-) > > We only use the global freeipa.spec.in and build client from that. I think we > should just delete the old one. > > Martin OK, I promise to test my patches next time :-) rpm -q --requires shows the python-backports-ssl_match_hostname dependency now. What about the one in attachment? If it doesn't work for you, feel free to just take over the patch.. -------------- next part -------------- >From 99b10a6b0bc342cea7a5764c331951f95daf8b89 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Mon, 1 Sep 2014 13:01:41 +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. --- freeipa.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6df4f06f2925700a35a4fc608c379ac400caa888..07824fed6cc22645f933681d821b79531c880bb8 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -203,6 +203,7 @@ Requires: libsss_autofs Requires: autofs Requires: libnfsidmap Requires: nfs-utils +Requires: python-backports-ssl_match_hostname Requires(post): policycoreutils Obsoletes: ipa-client >= 1.0 -- 1.9.3 From pviktori at redhat.com Mon Sep 1 12:50:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 01 Sep 2014 14:50:08 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <20140901111502.GH3139@hendrix.brq.redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> <540435E3.3000207@redhat.com> <20140901111502.GH3139@hendrix.brq.redhat.com> Message-ID: <54046B80.3010202@redhat.com> On 09/01/2014 01:15 PM, Jakub Hrozek wrote: > On Mon, Sep 01, 2014 at 11:01:23AM +0200, Martin Kosek wrote: >> On 08/25/2014 07:36 PM, Jakub Hrozek wrote: >>> Hi, >>> >>> ipa-client-install was failing for me on a fresh F-21 machine until I >>> manually dragged in python-backports-ssl_match_hostname >> >> Umh, thanks for the fix, but I do not think this spec is actually used in our >> build process. The last update was done in 2008 :-) >> >> We only use the global freeipa.spec.in and build client from that. I think we >> should just delete the old one. >> >> Martin > > OK, I promise to test my patches next time :-) > > rpm -q --requires shows the python-backports-ssl_match_hostname > dependency now. > > What about the one in attachment? If it doesn't work for you, feel free > to just take over the patch.. This also needs to be in BuildRequires to pass pylint. Patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jhrozek-0001-3-freeipa.spec.in-Explicitly-require-python-backports-.patch Type: text/x-patch Size: 1342 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 1 13:56:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Sep 2014 15:56:45 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage In-Reply-To: <53DF46B0.3070301@redhat.com> References: <53D113D8.9050507@redhat.com> <53DF46B0.3070301@redhat.com> Message-ID: <54047B1D.7070102@redhat.com> Dne 4.8.2014 v 10:39 Jan Cholasta napsal(a): > 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. Could someone please review this? -- Jan Cholasta From jcholast at redhat.com Mon Sep 1 14:17:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Sep 2014 16:17:11 +0200 Subject: [Freeipa-devel] [PATCH] 316 Normalize external CA cert before passing it to pkispawn Message-ID: <54047FE7.6030004@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-316-Normalize-external-CA-cert-before-passing-it-to-pkis.patch Type: text/x-patch Size: 2358 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 1 14:26:11 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Sep 2014 16:26:11 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <53FF1A20.7010809@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> Message-ID: <54048203.4060708@redhat.com> On 28/08/14 14:01, Jan Cholasta wrote: > 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 > 3) skipped as we discuss on IRC Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0116.2-Refactoring-of-autobind-object_exists.patch Type: text/x-patch Size: 9673 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 1 14:31:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Sep 2014 16:31:52 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <53D0B05C.3060405@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> Message-ID: <54048358.9000604@redhat.com> On 24/07/14 09:06, Martin Basti wrote: > On 23/07/14 15:17, Martin Basti wrote: >> This patch fixes ordering problem of schema updates >> >> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >> (will be in Fedora 21) >> >> Patch attached >> >> > I found a bug there, but before I send updated version, I need to > decide how print modlist: > > 1. Print modlist before each LDAP update (if changes exist), show > modlist per incremental update > > 2. Print modlist only at once with all updates > > 3. Use [1] for live_run, [2] for test > Print modlis before each LDAP update Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0105.3-FIX-ldap-schmema-updater-needs-correct-ordering-of-t.patch Type: text/x-patch Size: 8246 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 1 14:54:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Sep 2014 16:54:01 +0200 Subject: [Freeipa-devel] [PATCH 0117] Allow to mask and unmask services Message-ID: <54048889.3050105@redhat.com> This is required by DNSSEC installer Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 2671 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 1 14:57:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Sep 2014 16:57:48 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) Message-ID: <5404896C.4030907@redhat.com> This patch allows to disable service in LDAP to prevents service to be started by "ipactl restart" Required by DNSSEC Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0118-LDAP-disable-service.patch Type: text/x-patch Size: 3701 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 1 16:19:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 01 Sep 2014 18:19:34 +0200 Subject: [Freeipa-devel] [PATCH] 0083 Remove internaldb pasword from password.conf In-Reply-To: <527A38EC.4090603@redhat.com> References: <527A376C.40006@redhat.com> <527A38EC.4090603@redhat.com> Message-ID: <54049C96.1050000@redhat.com> On 11/06/2013 01:41 PM, Ana Krivokapic wrote: > On 11/06/2013 01:34 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/4005. I tried installing a replica with this patch applied to the 4.1 branch, but ipa-ca-install fails with: 2014-09-01T16:12:58Z DEBUG stderr=pkispawn : ERROR ....... Exception from Java Configuration Servlet: Failed to obtain configuration entries from the master for cloning org.xml.sax.SAXParseException; Premature end of file. The pkispawn log ends with: 2014-09-01 18:12:35 pkispawn : INFO ... configuring 'pki.server.deployment.scriptlets.configuration' 2014-09-01 18:12:35 pkispawn : INFO ....... mkdir -p /root/.dogtag/pki-tomcat/ca 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 755 /root/.dogtag/pki-tomcat/ca 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 /root/.dogtag/pki-tomcat/ca 2014-09-01 18:12:35 pkispawn : INFO ....... generating '/root/.dogtag/pki-tomcat/ca/password.conf' 2014-09-01 18:12:35 pkispawn : INFO ....... modifying '/root/.dogtag/pki-tomcat/ca/password.conf' 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 /root/.dogtag/pki-tomcat/ca/password.conf 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 /root/.dogtag/pki-tomcat/ca/password.conf 2014-09-01 18:12:35 pkispawn : INFO ....... generating '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' 2014-09-01 18:12:35 pkispawn : INFO ....... modifying '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 498:498 /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'certutil -N -d /tmp/tmp-yRUhk2 -f /root/.dogtag/pki-tomcat/ca/password.conf' 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl daemon-reload' 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl start pki-tomcatd at pki-tomcat.service' 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - server may still be down 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - exception thrown: HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by : [Errno 111] Connection refused) 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - server may still be down 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - exception thrown: HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by : [Errno 111] Connection refused) 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - server may still be down 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - exception thrown: HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by : [Errno 111] Connection refused) 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - server may still be down 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - exception thrown: HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by : [Errno 111] Connection refused) 2014-09-01 18:12:51 pkispawn : DEBUG ........... 0CArunning10.1.1-1.fc20 2014-09-01 18:12:52 pkispawn : INFO ....... constructing PKI configuration data. 2014-09-01 18:12:52 pkispawn : INFO ....... configuring PKI configuration data. 2014-09-01 18:12:58 pkispawn : ERROR ....... Exception from Java Configuration Servlet: Failed to obtain configuration entries from the master for cloning org.xml.sax.SAXParseException; Premature end of file. 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Type: HTTPError 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Message: 500 Server Error: Internal Server Error 2014-09-01 18:12:58 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 463, in main rv = instance.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 126, in spawn json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 3194, in configure_pki_data response = client.configure(data) File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in configure r = self.connection.post('/rest/installer/configure', data, headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post r.raise_for_status() File "/usr/lib/python2.7/site-packages/requests/models.py", line 683, in raise_for_status raise HTTPError(http_error_msg, response=self) Ade, do you have any idea what might be going wrong? -- Petr? From alee at redhat.com Tue Sep 2 03:05:09 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Sep 2014 23:05:09 -0400 Subject: [Freeipa-devel] [PATCH] 11 - re-enable uninstall option in ipa-kra-install Message-ID: <1409627109.4471.8.camel@aleeredhat.laptop> Re-enable uninstall feature for ipa-kra-install The underlying Dogtag issue (Dogtag ticket 1113) has been fixed. We can therefore re-enable the uninstall option for ipa-kra-install. Also, fixes an incorrect path in the ipa-pki-proxy.conf, and adds a debug statement to provide status to the user when an uninstall is done. Also, re-added the no_host_dns option which is used when unpacking a replica file. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 Please review. A new COPR Dogtag build with the relevant fix for ticket 1113 has been built. (pki-core-10.2.0-0.8.fc20) Please update your Dogtag build to this version. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Re-enable-uninstall-feature-for-ipa-kra-install.patch Type: text/x-patch Size: 4133 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 2 07:03:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 09:03:06 +0200 Subject: [Freeipa-devel] [PATCH] 0083 Remove internaldb pasword from password.conf In-Reply-To: <54049C96.1050000@redhat.com> References: <527A376C.40006@redhat.com> <527A38EC.4090603@redhat.com> <54049C96.1050000@redhat.com> Message-ID: <54056BAA.40606@redhat.com> Also, Dogtag certificate renewal does not work with internaldb removed, I'm working on a patch to fix that. Dne 1.9.2014 v 18:19 Petr Viktorin napsal(a): > On 11/06/2013 01:41 PM, Ana Krivokapic wrote: >> On 11/06/2013 01:34 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/4005. > > I tried installing a replica with this patch applied to the 4.1 branch, > but ipa-ca-install fails with: > > 2014-09-01T16:12:58Z DEBUG stderr=pkispawn : ERROR ....... > Exception from Java Configuration Servlet: Failed to obtain > configuration entries from the master for cloning > org.xml.sax.SAXParseException; Premature end of file. > > The pkispawn log ends with: > > 2014-09-01 18:12:35 pkispawn : INFO ... configuring > 'pki.server.deployment.scriptlets.configuration' > 2014-09-01 18:12:35 pkispawn : INFO ....... mkdir -p > /root/.dogtag/pki-tomcat/ca > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 755 > /root/.dogtag/pki-tomcat/ca > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 > /root/.dogtag/pki-tomcat/ca > 2014-09-01 18:12:35 pkispawn : INFO ....... generating > '/root/.dogtag/pki-tomcat/ca/password.conf' > 2014-09-01 18:12:35 pkispawn : INFO ....... modifying > '/root/.dogtag/pki-tomcat/ca/password.conf' > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 > /root/.dogtag/pki-tomcat/ca/password.conf > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 > /root/.dogtag/pki-tomcat/ca/password.conf > 2014-09-01 18:12:35 pkispawn : INFO ....... generating > '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' > 2014-09-01 18:12:35 pkispawn : INFO ....... modifying > '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 > /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf > 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 498:498 > /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf > 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'certutil > -N -d /tmp/tmp-yRUhk2 -f /root/.dogtag/pki-tomcat/ca/password.conf' > 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl > daemon-reload' > 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl > start pki-tomcatd at pki-tomcat.service' > 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - > server may still be down > 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - > exception thrown: > HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', > port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus > (Caused by : [Errno 111] Connection refused) > 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - > server may still be down > 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - > exception thrown: > HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', > port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus > (Caused by : [Errno 111] Connection refused) > 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - > server may still be down > 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - > exception thrown: > HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', > port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus > (Caused by : [Errno 111] Connection refused) > 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - > server may still be down > 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - > exception thrown: > HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', > port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus > (Caused by : [Errno 111] Connection refused) > 2014-09-01 18:12:51 pkispawn : DEBUG ........... version="1.0" encoding="UTF-8" > standalone="no"?>0CArunning10.1.1-1.fc20 > > 2014-09-01 18:12:52 pkispawn : INFO ....... constructing PKI > configuration data. > 2014-09-01 18:12:52 pkispawn : INFO ....... configuring PKI > configuration data. > 2014-09-01 18:12:58 pkispawn : ERROR ....... Exception from Java > Configuration Servlet: Failed to obtain configuration entries from the > master for cloning org.xml.sax.SAXParseException; Premature end of file. > 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Type: HTTPError > 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Message: 500 > Server Error: Internal Server Error > 2014-09-01 18:12:58 pkispawn : DEBUG ....... File > "/usr/sbin/pkispawn", line 463, in main > rv = instance.spawn(deployer) > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", > line 126, in spawn > json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", > line 3194, in configure_pki_data > response = client.configure(data) > File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in > configure > r = self.connection.post('/rest/installer/configure', data, headers) > File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post > r.raise_for_status() > File "/usr/lib/python2.7/site-packages/requests/models.py", line 683, > in raise_for_status > raise HTTPError(http_error_msg, response=self) > > > Ade, do you have any idea what might be going wrong? > > -- Jan Cholasta From jcholast at redhat.com Tue Sep 2 07:10:13 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 09:10:13 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <5404896C.4030907@redhat.com> References: <5404896C.4030907@redhat.com> Message-ID: <54056D55.7030102@redhat.com> Hi, Dne 1.9.2014 v 16:57 Martin Basti napsal(a): > This patch allows to disable service in LDAP to prevents service to be > started by "ipactl restart" > > Required by DNSSEC > > Patch attached I don't think the extra argument in ldap_enable is necessary. It should enable the service no matter if the entry existed before or not. Similarly, in ldap_disable you should not raise an error when the entry is not found, because that already makes the service disabled. Honza -- Jan Cholasta From jcholast at redhat.com Tue Sep 2 07:11:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 09:11:30 +0200 Subject: [Freeipa-devel] [PATCH 0117] Allow to mask and unmask services In-Reply-To: <54048889.3050105@redhat.com> References: <54048889.3050105@redhat.com> Message-ID: <54056DA2.5000801@redhat.com> Hi, Dne 1.9.2014 v 16:54 Martin Basti napsal(a): > This is required by DNSSEC installer > > Patch attached IMO masking/unmasking should be part of disabling/enabling a service in systemd. AFAIK in most other init systems when you disable a service, it has the same effect as masking the service in systemd - it will never be started until it is enabled/unmasked again. Honza -- Jan Cholasta From jcholast at redhat.com Tue Sep 2 07:19:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 09:19:41 +0200 Subject: [Freeipa-devel] [PATCH] 0001 pwpolicy-add: Added better error handling In-Reply-To: <20140826172613.GK3890@tscherf.redhat.com> References: <20140826155309.GI3890@tscherf.redhat.com> <53FCB3A6.1050808@redhat.com> <20140826172613.GK3890@tscherf.redhat.com> Message-ID: <54056F8D.3090606@redhat.com> There's some trailing whitespace on lines 22 and 29 of the patch, but besides that ACK. Dne 26.8.2014 v 19:26 Thorsten Scherf napsal(a): > 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 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Jan Cholasta From jcholast at redhat.com Tue Sep 2 08:18:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 10:18:12 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <53FDF008.9040306@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> Message-ID: <54057D44.9040107@redhat.com> Dne 27.8.2014 v 16:49 David Kupka napsal(a): > 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 >>> >> > ACK as long as this works for Nalin. -- Jan Cholasta From dkupka at redhat.com Tue Sep 2 08:29:06 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 02 Sep 2014 10:29:06 +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: <54057FD2.1010001@redhat.com> Forget to add str() conversion to some places when removing map(). Now it should be working again. On 08/27/2014 02:24 PM, David Kupka wrote: > 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 >> > > > > _______________________________________________ > 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-3-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 16327 bytes Desc: not available URL: From mkosek at redhat.com Tue Sep 2 08:42:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Sep 2014 10:42:34 +0200 Subject: [Freeipa-devel] [PATCH] 0001 pwpolicy-add: Added better error handling In-Reply-To: <54056F8D.3090606@redhat.com> References: <20140826155309.GI3890@tscherf.redhat.com> <53FCB3A6.1050808@redhat.com> <20140826172613.GK3890@tscherf.redhat.com> <54056F8D.3090606@redhat.com> Message-ID: <540582FA.8090706@redhat.com> Thanks to both! Pushed to master: a2eab057d4adfaa8da7fee07410e1a33efb7f95d Martin On 09/02/2014 09:19 AM, Jan Cholasta wrote: > There's some trailing whitespace on lines 22 and 29 of the patch, but besides > that ACK. > > Dne 26.8.2014 v 19:26 Thorsten Scherf napsal(a): >> 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 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > From jcholast at redhat.com Tue Sep 2 09:37:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 11:37:46 +0200 Subject: [Freeipa-devel] [PATCH] 0083 Remove internaldb pasword from password.conf In-Reply-To: <54056BAA.40606@redhat.com> References: <527A376C.40006@redhat.com> <527A38EC.4090603@redhat.com> <54049C96.1050000@redhat.com> <54056BAA.40606@redhat.com> Message-ID: <54058FEA.9070301@redhat.com> Patch attached. Dne 2.9.2014 v 09:03 Jan Cholasta napsal(a): > Also, Dogtag certificate renewal does not work with internaldb removed, > I'm working on a patch to fix that. > > Dne 1.9.2014 v 18:19 Petr Viktorin napsal(a): >> On 11/06/2013 01:41 PM, Ana Krivokapic wrote: >>> On 11/06/2013 01:34 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses >>>> tickethttps://fedorahosted.org/freeipa/ticket/4005. >> >> I tried installing a replica with this patch applied to the 4.1 branch, >> but ipa-ca-install fails with: >> >> 2014-09-01T16:12:58Z DEBUG stderr=pkispawn : ERROR ....... >> Exception from Java Configuration Servlet: Failed to obtain >> configuration entries from the master for cloning >> org.xml.sax.SAXParseException; Premature end of file. >> >> The pkispawn log ends with: >> >> 2014-09-01 18:12:35 pkispawn : INFO ... configuring >> 'pki.server.deployment.scriptlets.configuration' >> 2014-09-01 18:12:35 pkispawn : INFO ....... mkdir -p >> /root/.dogtag/pki-tomcat/ca >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 755 >> /root/.dogtag/pki-tomcat/ca >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 >> /root/.dogtag/pki-tomcat/ca >> 2014-09-01 18:12:35 pkispawn : INFO ....... generating >> '/root/.dogtag/pki-tomcat/ca/password.conf' >> 2014-09-01 18:12:35 pkispawn : INFO ....... modifying >> '/root/.dogtag/pki-tomcat/ca/password.conf' >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 >> /root/.dogtag/pki-tomcat/ca/password.conf >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 0:0 >> /root/.dogtag/pki-tomcat/ca/password.conf >> 2014-09-01 18:12:35 pkispawn : INFO ....... generating >> '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' >> 2014-09-01 18:12:35 pkispawn : INFO ....... modifying >> '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf' >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chmod 660 >> /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... chown 498:498 >> /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf >> 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'certutil >> -N -d /tmp/tmp-yRUhk2 -f /root/.dogtag/pki-tomcat/ca/password.conf' >> 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl >> daemon-reload' >> 2014-09-01 18:12:35 pkispawn : INFO ....... executing 'systemctl >> start pki-tomcatd at pki-tomcat.service' >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - >> server may still be down >> 2014-09-01 18:12:35 pkispawn : DEBUG ........... No connection - >> exception thrown: >> HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', >> port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus >> (Caused by : [Errno 111] Connection refused) >> 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - >> server may still be down >> 2014-09-01 18:12:36 pkispawn : DEBUG ........... No connection - >> exception thrown: >> HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', >> port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus >> (Caused by : [Errno 111] Connection refused) >> 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - >> server may still be down >> 2014-09-01 18:12:37 pkispawn : DEBUG ........... No connection - >> exception thrown: >> HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', >> port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus >> (Caused by : [Errno 111] Connection refused) >> 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - >> server may still be down >> 2014-09-01 18:12:38 pkispawn : DEBUG ........... No connection - >> exception thrown: >> HTTPSConnectionPool(host='vm-234.idm.lab.eng.brq.redhat.com', >> port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus >> (Caused by : [Errno 111] Connection refused) >> 2014-09-01 18:12:51 pkispawn : DEBUG ........... > version="1.0" encoding="UTF-8" >> standalone="no"?>0CArunning10.1.1-1.fc20 >> >> >> 2014-09-01 18:12:52 pkispawn : INFO ....... constructing PKI >> configuration data. >> 2014-09-01 18:12:52 pkispawn : INFO ....... configuring PKI >> configuration data. >> 2014-09-01 18:12:58 pkispawn : ERROR ....... Exception from Java >> Configuration Servlet: Failed to obtain configuration entries from the >> master for cloning org.xml.sax.SAXParseException; Premature end of file. >> 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Type: HTTPError >> 2014-09-01 18:12:58 pkispawn : DEBUG ....... Error Message: 500 >> Server Error: Internal Server Error >> 2014-09-01 18:12:58 pkispawn : DEBUG ....... File >> "/usr/sbin/pkispawn", line 463, in main >> rv = instance.spawn(deployer) >> File >> "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", >> >> line 126, in spawn >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) >> File >> "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", >> line 3194, in configure_pki_data >> response = client.configure(data) >> File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in >> configure >> r = self.connection.post('/rest/installer/configure', data, headers) >> File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in >> post >> r.raise_for_status() >> File "/usr/lib/python2.7/site-packages/requests/models.py", line 683, >> in raise_for_status >> raise HTTPError(http_error_msg, response=self) >> >> >> Ade, do you have any idea what might be going wrong? >> >> > > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-317-Use-autobind-when-updating-CA-people-entries-during-.patch Type: text/x-patch Size: 2208 bytes Desc: not available URL: From tbordaz at redhat.com Tue Sep 2 09:40:04 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 02 Sep 2014 11:40:04 +0200 Subject: [Freeipa-devel] [PATCH] 0003 User life cycle: new stageuser plugin with add verb In-Reply-To: <54045399.3030404@redhat.com> References: <53E4D6AE.6050505@redhat.com> <54045399.3030404@redhat.com> Message-ID: <54059074.5060502@redhat.com> On 09/01/2014 01:08 PM, Petr Viktorin wrote: > On 08/08/2014 03:54 PM, thierry bordaz wrote: >> 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 > > Avoid `from ipalib.plugins.baseldap import *` in new code; instead > import the module itself and use e.g. `baseldap.LDAPObject`. > > The stageuser help (docstring) is copied from the user plugin, and > discusses things like account lockout and disabling users. It should > rather explain what stageuser itself does. (And I don't very much like > the Note about the interface being badly designed...) > Also decide if the docs should call it "staged user" or "stage user" > or "stageuser". Hello Petr, Thanks for your review. I will rewrite the docstring to be only staged user related and I will adopt 'stage user' and 'stageuser'. About the interface, that is correct that I was not able to find a good solution. I need to add a 'stageuser' I use 'stageuser-add' and '--first' and '--last' are required. Now when a user got deleted ('user-del') and is later move to 'stage user' it also use the command line 'stageuser-add'. At this time the delete user is know/found by it 'user login'/uid. So '--first' and '--last' are not required to find it (can be used to check givenname/sn). Now I do not expect that 'stageuser-add' will be frequently used to move a Delete user to Stage user, so it is not a so painful constraint. > > A lot of the code is copied and pasted over from the users plugin. > Don't do that. Either import things (e.g. validate_nsaccountlock) from > the users plugin, or move the reused code into a shared module. > > For the `user` object, since so much is the same, it might be best to > create a common base class for user and stageuser; and similarly for > the Command plugins. I agree that user and stageuser have a lot of code in common. So it would be beneficial to have a common base class. Is it ok to put this in a file under freeipa/ipalib ? About the name of this class, what about 'accounts' or 'user_accounts' ? What do you mean by 'similarly for Command plugins' ?. If I create, for example, a freeipa/ipalib/accounts.py containing all the common code for 'user' and 'stageuser'. Then import it into freeipa/ipalib/plugins/user and freeipa/ipalib/plugins/stageuser I believe it will refactore the 'Command plugins'. > > The default permissions need different names, and you don't need > another copy of the 'non_object' ones. Also, run the makeaci script. Ok. I will update the names. 'non_object' is not clear to me, what does this exactly mean when a managed_permission has 'non_object' True. In update_managed_permissions.py it is said that if True, it target a defaults value. But on the other side, the managed permissions also define 'ipapermtarget' (like ipauser or UPG) many thanks Petr thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Sep 2 09:57:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Sep 2014 11:57:08 +0200 Subject: [Freeipa-devel] [PATCH] 0003 User life cycle: new stageuser plugin with add verb In-Reply-To: <54059074.5060502@redhat.com> References: <53E4D6AE.6050505@redhat.com> <54045399.3030404@redhat.com> <54059074.5060502@redhat.com> Message-ID: <54059474.1060606@redhat.com> On 09/02/2014 11:40 AM, thierry bordaz wrote: > On 09/01/2014 01:08 PM, Petr Viktorin wrote: >> On 08/08/2014 03:54 PM, thierry bordaz wrote: >>> 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 >> >> Avoid `from ipalib.plugins.baseldap import *` in new code; instead >> import the module itself and use e.g. `baseldap.LDAPObject`. >> >> The stageuser help (docstring) is copied from the user plugin, and >> discusses things like account lockout and disabling users. It should >> rather explain what stageuser itself does. (And I don't very much like >> the Note about the interface being badly designed...) >> Also decide if the docs should call it "staged user" or "stage user" >> or "stageuser". > Hello Petr, > > Thanks for your review. > > I will rewrite the docstring to be only staged user related and I > will adopt 'stage user' and 'stageuser'. > About the interface, that is correct that I was not able to find a > good solution. > I need to add a 'stageuser' I use 'stageuser-add' and '--first' and > '--last' are required. > Now when a user got deleted ('user-del') and is later move to 'stage > user' it also use the command line 'stageuser-add'. > At this time the delete user is know/found by it 'user login'/uid. > So '--first' and '--last' are not required to find it (can be used > to check givenname/sn). > Now I do not expect that 'stageuser-add' will be frequently used to > move a Delete user to Stage user, so it is not a so painful constraint. Right, it's probably not worth worrying about. But you could make them optional formally, and validate them in the pre_callback. >> A lot of the code is copied and pasted over from the users plugin. >> Don't do that. Either import things (e.g. validate_nsaccountlock) from >> the users plugin, or move the reused code into a shared module. >> >> For the `user` object, since so much is the same, it might be best to >> create a common base class for user and stageuser; and similarly for >> the Command plugins. > > I agree that user and stageuser have a lot of code in common. So it > would be beneficial to have a common base class. Is it ok to put > this in a file under freeipa/ipalib ? About the name of this class, > what about 'accounts' or 'user_accounts' ? Either ipalib/accounts.py or ipalib/plugins/accounts.py is fine. It would inherit from code in baseldap, which is in plugins, so putting it in plugins would be somewhat more consistent. > What do you mean by 'similarly for Command plugins' ?. If I create, 'user' and 'stageuser' are Object plugins, 'user_add' and 'stageuser_add' are Command plugins. > for example, a freeipa/ipalib/accounts.py containing all the common > code for 'user' and 'stageuser'. Then import it into > freeipa/ipalib/plugins/user and freeipa/ipalib/plugins/stageuser I > believe it will refactore the 'Command plugins'. Yes, that's the idea. >> The default permissions need different names, and you don't need >> another copy of the 'non_object' ones. Also, run the makeaci script. > > Ok. I will update the names. 'non_object' is not clear to me, what does > this exactly mean when a managed_permission has 'non_object' True. > In update_managed_permissions.py it is said that if True, it target a > defaults value. But on the other side, the managed permissions also > define 'ipapermtarget' (like ipauser or UPG) 'non_object' means that it doesn't take attributes, such as ipapermlocation, from the Object it's defined in. If 'non_object' is false (or missing), the defaults are taken from the object but can be overridden. -- Petr? From mbasti at redhat.com Tue Sep 2 09:59:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 02 Sep 2014 11:59:15 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <54056D55.7030102@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> Message-ID: <540594F3.2030001@redhat.com> On 02/09/14 09:10, Jan Cholasta wrote: > Hi, > > Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >> This patch allows to disable service in LDAP to prevents service to be >> started by "ipactl restart" >> >> Required by DNSSEC >> >> Patch attached > > I don't think the extra argument in ldap_enable is necessary. It > should enable the service no matter if the entry existed before or not. > > Similarly, in ldap_disable you should not raise an error when the > entry is not found, because that already makes the service disabled. > > Honza > Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0118.2-LDAP-disable-service.patch Type: text/x-patch Size: 3219 bytes Desc: not available URL: From dkupka at redhat.com Tue Sep 2 10:13:03 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 02 Sep 2014 12:13:03 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Add record(s) to /etc/host when IPA is configured as DNS server. Message-ID: <5405982F.3000709@redhat.com> This patch depends on freeipa-dkupka-0009 as it modifies the same part of code. https://fedorahosted.org/freeipa/ticket/4220 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0012-Add-record-s-to-etc-host-when-IPA-is-configured-as-D.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: From pvoborni at redhat.com Tue Sep 2 11:49:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 02 Sep 2014 13:49:08 +0200 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <1409249666.9966.4.camel@redhat.com> References: <1408481179.3505.6.camel@redhat.com> <1409249666.9966.4.camel@redhat.com> Message-ID: <5405AEB4.4080809@redhat.com> On 28.8.2014 20:14, Nathaniel McCallum wrote: > 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 > ACK if comment below doesn't need any change: Maybe I'm missing something, but why do we do following check: `if 'objectclass' in entry_attrs:`? Shouldn't it be always True? Since the objectclass is set in LDAPCreate.execute. A pre-callback in an third party plugin can remove it, but I don't think we should care. -- Petr Vobornik From jcholast at redhat.com Tue Sep 2 11:56:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 13:56:48 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54007359.1000102@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> <54007359.1000102@redhat.com> Message-ID: <5405B080.4010509@redhat.com> Dne 29.8.2014 v 14:34 David Kupka napsal(a): > 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. I didn't notice the patch is targeted for 4.0. Can you please provide patches for both ipa-4-0 and ipa-4-1/master? >> >> >> 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 You removed the comments, but left the attributes there. You should remove them as well, they are not necessary, as you set them all in __init__(). >> >> >> 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. OK, no need to include the TODO comment though. > >> >> I haven't done functional testing yet, expect more comments later. >> >> Honza >> > 12) ipa-client-install still uses ipa-getcert instead of certmonger API to request the host certificate, but since we plan on stopping doing that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't have to do anything about it. 13) You require dict for criteria in get_request_id, but you pass tuples to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which makes them fail. -- Jan Cholasta From pviktori at redhat.com Tue Sep 2 13:31:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Sep 2014 15:31:48 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage In-Reply-To: <54047B1D.7070102@redhat.com> References: <53D113D8.9050507@redhat.com> <53DF46B0.3070301@redhat.com> <54047B1D.7070102@redhat.com> Message-ID: <5405C6C4.9080708@redhat.com> On 09/01/2014 03:56 PM, Jan Cholasta wrote: > Dne 4.8.2014 v 10:39 Jan Cholasta napsal(a): >> 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. > > Could someone please review this? I ran into some trouble installing Dogtag, but it wasn't caused by this patch. ACK, pushed to: master: 774140196360c727f11c75622ace488d591ddfba ipa-4-1: aae78480220203b1c64c8b3c6b8297868c849110 ipa-4-0: 8999300894326d104ddf22a97d74d78fdab0984c -- Petr? From jcholast at redhat.com Tue Sep 2 14:07:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Sep 2014 16:07:01 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage In-Reply-To: <5405C6C4.9080708@redhat.com> References: <53D113D8.9050507@redhat.com> <53DF46B0.3070301@redhat.com> <54047B1D.7070102@redhat.com> <5405C6C4.9080708@redhat.com> Message-ID: <5405CF05.8070408@redhat.com> Dne 2.9.2014 v 15:31 Petr Viktorin napsal(a): > On 09/01/2014 03:56 PM, Jan Cholasta wrote: >> Dne 4.8.2014 v 10:39 Jan Cholasta napsal(a): >>> 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. >> >> Could someone please review this? > > I ran into some trouble installing Dogtag, but it wasn't caused by this > patch. > > ACK, pushed to: > master: 774140196360c727f11c75622ace488d591ddfba > ipa-4-1: aae78480220203b1c64c8b3c6b8297868c849110 > ipa-4-0: 8999300894326d104ddf22a97d74d78fdab0984c Thanks. Please also push the required patches (246 and 262) to ipa-4-0 (they already are in ipa-4-1 and master). -- Jan Cholasta From pviktori at redhat.com Tue Sep 2 14:26:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Sep 2014 16:26:10 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage In-Reply-To: <5405CF05.8070408@redhat.com> References: <53D113D8.9050507@redhat.com> <53DF46B0.3070301@redhat.com> <54047B1D.7070102@redhat.com> <5405C6C4.9080708@redhat.com> <5405CF05.8070408@redhat.com> Message-ID: <5405D382.2050000@redhat.com> On 09/02/2014 04:07 PM, Jan Cholasta wrote: > Dne 2.9.2014 v 15:31 Petr Viktorin napsal(a): >> On 09/01/2014 03:56 PM, Jan Cholasta wrote: >>> Dne 4.8.2014 v 10:39 Jan Cholasta napsal(a): >>>> 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. >>> >>> Could someone please review this? >> >> I ran into some trouble installing Dogtag, but it wasn't caused by this >> patch. >> >> ACK, pushed to: >> master: 774140196360c727f11c75622ace488d591ddfba >> ipa-4-1: aae78480220203b1c64c8b3c6b8297868c849110 >> ipa-4-0: 8999300894326d104ddf22a97d74d78fdab0984c > > Thanks. Please also push the required patches (246 and 262) to ipa-4-0 > (they already are in ipa-4-1 and master). > I knew I forgot something. Pushed to ipa-4-0: 113b033ae5290425aa41c07835b4f24068514473 -- Petr? From mbasti at redhat.com Tue Sep 2 14:30:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 02 Sep 2014 16:30:58 +0200 Subject: [Freeipa-devel] [PATCH 0278] Fix ticket expiration check In-Reply-To: <53F337C4.3040806@redhat.com> References: <53F337C4.3040806@redhat.com> Message-ID: <5405D4A2.6020808@redhat.com> On 19/08/14 13:40, Petr Spacek wrote: > 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). > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Patch works for me. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Sep 2 14:31:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Sep 2014 16:31:05 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <20140901111502.GH3139@hendrix.brq.redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> <540435E3.3000207@redhat.com> <20140901111502.GH3139@hendrix.brq.redhat.com> Message-ID: <5405D4A9.4080302@redhat.com> On 09/01/2014 01:15 PM, Jakub Hrozek wrote: > On Mon, Sep 01, 2014 at 11:01:23AM +0200, Martin Kosek wrote: >> On 08/25/2014 07:36 PM, Jakub Hrozek wrote: >>> Hi, >>> >>> ipa-client-install was failing for me on a fresh F-21 machine until I >>> manually dragged in python-backports-ssl_match_hostname >> >> Umh, thanks for the fix, but I do not think this spec is actually used in our >> build process. The last update was done in 2008 :-) >> >> We only use the global freeipa.spec.in and build client from that. I think we >> should just delete the old one. >> >> Martin > > OK, I promise to test my patches next time :-) > > rpm -q --requires shows the python-backports-ssl_match_hostname > dependency now. > > What about the one in attachment? If it doesn't work for you, feel free > to just take over the patch.. No, it is fine. I just added a link to the ticket. Pushed to: master: 42bf7abb5f81f0b8f98370f7330ab5c5dc2a2fb4 ipa-4-1: c03404423d30781ab18815472782f465915fec7f ipa-4-0: aa5d86cf84afe766a7493a184a6a55442298ea98 Martin From pviktori at redhat.com Tue Sep 2 14:48:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Sep 2014 16:48:20 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <54046B80.3010202@redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> <540435E3.3000207@redhat.com> <20140901111502.GH3139@hendrix.brq.redhat.com> <54046B80.3010202@redhat.com> Message-ID: <5405D8B4.6010904@redhat.com> On 09/01/2014 02:50 PM, Petr Viktorin wrote: > On 09/01/2014 01:15 PM, Jakub Hrozek wrote: >> On Mon, Sep 01, 2014 at 11:01:23AM +0200, Martin Kosek wrote: >>> On 08/25/2014 07:36 PM, Jakub Hrozek wrote: >>>> Hi, >>>> >>>> ipa-client-install was failing for me on a fresh F-21 machine until I >>>> manually dragged in python-backports-ssl_match_hostname >>> >>> Umh, thanks for the fix, but I do not think this spec is actually >>> used in our >>> build process. The last update was done in 2008 :-) >>> >>> We only use the global freeipa.spec.in and build client from that. I >>> think we >>> should just delete the old one. >>> >>> Martin >> >> OK, I promise to test my patches next time :-) >> >> rpm -q --requires shows the python-backports-ssl_match_hostname >> dependency now. >> >> What about the one in attachment? If it doesn't work for you, feel free >> to just take over the patch.. > > This also needs to be in BuildRequires to pass pylint. Patch attached. > Rebased. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0638-freeipa.spec.in-Add-python-backports-ssl_match_hostn.patch Type: text/x-patch Size: 965 bytes Desc: not available URL: From dkupka at redhat.com Tue Sep 2 14:51:49 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 02 Sep 2014 16:51:49 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Add record(s) to /etc/host when IPA is configured as DNS server. In-Reply-To: <5405982F.3000709@redhat.com> References: <5405982F.3000709@redhat.com> Message-ID: <5405D985.8080800@redhat.com> Ok, the patch no longer depends on 0009. The reason is that 0012 is going to ipa-4.0 and 0009 to ipa-4.1. On 09/02/2014 12:13 PM, David Kupka wrote: > This patch depends on freeipa-dkupka-0009 as it modifies the same part > of code. > > https://fedorahosted.org/freeipa/ticket/4220 > > > _______________________________________________ > 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-0012-2-Add-record-s-to-etc-host-when-IPA-is-configured-as-D.patch Type: text/x-patch Size: 1234 bytes Desc: not available URL: From dkupka at redhat.com Tue Sep 2 14:55:50 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 02 Sep 2014 16:55:50 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54057FD2.1010001@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> Message-ID: <5405DA76.1020502@redhat.com> The patch now depends on freeipa-dkupka-0012 as both modifies the same part of code. On 09/02/2014 10:29 AM, David Kupka wrote: > Forget to add str() conversion to some places when removing map(). Now > it should be working again. > > On 08/27/2014 02:24 PM, David Kupka wrote: >> 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 >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-4-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 16348 bytes Desc: not available URL: From mkosek at redhat.com Tue Sep 2 15:00:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Sep 2014 17:00:06 +0200 Subject: [Freeipa-devel] [PATCH] CLIENT: Explicitly require python-backports-ssl_match_hostname In-Reply-To: <5405D8B4.6010904@redhat.com> References: <20140825173629.GO10132@hendrix.redhat.com> <540435E3.3000207@redhat.com> <20140901111502.GH3139@hendrix.brq.redhat.com> <54046B80.3010202@redhat.com> <5405D8B4.6010904@redhat.com> Message-ID: <5405DB76.4020103@redhat.com> On 09/02/2014 04:48 PM, Petr Viktorin wrote: > On 09/01/2014 02:50 PM, Petr Viktorin wrote: >> On 09/01/2014 01:15 PM, Jakub Hrozek wrote: >>> On Mon, Sep 01, 2014 at 11:01:23AM +0200, Martin Kosek wrote: >>>> On 08/25/2014 07:36 PM, Jakub Hrozek wrote: >>>>> Hi, >>>>> >>>>> ipa-client-install was failing for me on a fresh F-21 machine until I >>>>> manually dragged in python-backports-ssl_match_hostname >>>> >>>> Umh, thanks for the fix, but I do not think this spec is actually >>>> used in our >>>> build process. The last update was done in 2008 :-) >>>> >>>> We only use the global freeipa.spec.in and build client from that. I >>>> think we >>>> should just delete the old one. >>>> >>>> Martin >>> >>> OK, I promise to test my patches next time :-) >>> >>> rpm -q --requires shows the python-backports-ssl_match_hostname >>> dependency now. >>> >>> What about the one in attachment? If it doesn't work for you, feel free >>> to just take over the patch.. >> >> This also needs to be in BuildRequires to pass pylint. Patch attached. >> > > Rebased. Thanks for the catch, sorry for missing the updated patch earlier. ACK, pushed to: master: 68b7312639260926e3d4a07ab002f54ce238c72e ipa-4-1: cac070b121b0a676c1367602852b8fafe62a3330 ipa-4-0: 4adefc3f5d177337a7e1acfc2a07e67853e716c7 Martin From pvoborni at redhat.com Tue Sep 2 15:15:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 02 Sep 2014 17:15:14 +0200 Subject: [Freeipa-devel] [PATCH] 748 webui: extract complex pkey on Add and Edit Message-ID: <5405DF02.7000209@redhat.com> DNS zone 'Add and Edit' failed because of new DNS name encoding. This patch makes sure that keys are extracted properly. https://fedorahosted.org/freeipa/ticket/4520 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0748-webui-extract-complex-pkey-on-Add-and-Edit.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 2 15:16:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 17:16:03 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <53F4DA40.7060507@redhat.com> References: <53F4DA40.7060507@redhat.com> Message-ID: <5405DF33.9050108@redhat.com> On 20.8.2014 19:26, Martin Basti wrote: > Part of DNSSEC > Patches attached. NACK # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS record (RFC 4529, section 4.6) RFC number is incorrect. IMHO it should also reference 'RFC 4035 section 2.4'. Also, there is one hole: Current code allows you to add DS RR to existing NS and then to remove NS. Let me know if adding a check to -del is too hard, maybe we can live without it... -- Petr^2 Spacek From npmccallum at redhat.com Tue Sep 2 15:22:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Sep 2014 11:22:10 -0400 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <5405AEB4.4080809@redhat.com> References: <1408481179.3505.6.camel@redhat.com> <1409249666.9966.4.camel@redhat.com> <5405AEB4.4080809@redhat.com> Message-ID: <1409671330.4163.0.camel@redhat.com> On Tue, 2014-09-02 at 13:49 +0200, Petr Vobornik wrote: > On 28.8.2014 20:14, Nathaniel McCallum wrote: > > 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 > > > > ACK if comment below doesn't need any change: > > Maybe I'm missing something, but why do we do following check: `if > 'objectclass' in entry_attrs:`? Shouldn't it be always True? Since > the objectclass is set in LDAPCreate.execute. A pre-callback in an third > party plugin can remove it, but I don't think we should care. I also thought that was odd, but I cargo-culted it to retain backwards compatibility. Attached is a version of the patch which doesn't retain this. I don't care which gets merged. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0061.1-Ensure-ipaUserAuthTypeClass-when-needed-on-user-crea.patch Type: text/x-patch Size: 2443 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 2 15:33:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 17:33:46 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <53F5B4C9.3060708@redhat.com> References: <53F4C0A5.6030408@redhat.com> <53F59524.3040506@redhat.com> <53F5B4C9.3060708@redhat.com> Message-ID: <5405E35A.2030801@redhat.com> On 21.8.2014 10:58, Martin Basti wrote: > 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. > # ipa dnsrecord-add ipa.example. '*' --ns-rec='ns' ipa: ERROR: invalid 'idnsname': owner of DNAME, DS, NS records should not be a wildcard domain name (RFC 4592) It would be nice to have more specific reference to RFC: 'RFC 4592 section 4'. CondACK: It can be pushed if you amend the error message. -- Petr^2 Spacek From pspacek at redhat.com Tue Sep 2 15:38:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 17:38:23 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation In-Reply-To: <53F62A8D.30303@redhat.com> References: <53F62A8D.30303@redhat.com> Message-ID: <5405E46F.6040703@redhat.com> On 21.8.2014 19:21, Martin Basti wrote: > 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. Functional ACK. It can be pushed if Python gurus don't see any problem. -- Petr^2 Spacek From pspacek at redhat.com Tue Sep 2 15:46:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 17:46:27 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <53FB3191.7090102@redhat.com> References: <53FB3191.7090102@redhat.com> Message-ID: <5405E653.2050604@redhat.com> On 25.8.2014 14:52, Martin Basti wrote: > 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 Functional ACK, it works for me. It can be pushed if Python gurus are okay with the code. # ipa dnszone-add . Authoritative nameserver: @ Administrator e-mail address [hostmaster.]: >>> Administrator e-mail address: missing address domain Administrator e-mail address [hostmaster.]: hostmaster. >>> Administrator e-mail address: missing address domain Administrator e-mail address [hostmaster.]: hostmaster.test. Nameserver IP address: 127.0.0.1 Zone name: . Active zone: TRUE Authoritative nameserver: @ Administrator e-mail address: hostmaster.test. SOA serial: 1409672572 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; # ipa dnszone-mod . --expire=555 Zone name: . Active zone: TRUE Authoritative nameserver: @ Administrator e-mail address: hostmaster.test. SOA serial: 1409672710 SOA refresh: 3600 SOA retry: 900 SOA expire: 555 SOA minimum: 3600 Allow query: any; Allow transfer: none; # ipa dnszone-del . -------------------- Deleted DNS zone "." -------------------- "Administrator e-mail address: missing address domain" failure is IMHO acceptable in this case. It seems unlikely that root domain will have MX records :-) -- Petr^2 Spacek From pspacek at redhat.com Tue Sep 2 15:49:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 17:49:57 +0200 Subject: [Freeipa-devel] [PATCH 0278] Fix ticket expiration check In-Reply-To: <5405D4A2.6020808@redhat.com> References: <53F337C4.3040806@redhat.com> <5405D4A2.6020808@redhat.com> Message-ID: <5405E725.5000805@redhat.com> On 2.9.2014 16:30, Martin Basti wrote: > On 19/08/14 13:40, Petr Spacek wrote: >> 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). >> > ACK > Patch works for me. Thank you! Pushed to Git: master: 24f05cf9b9b6bd9c57d09dbd018da179eb8dc8bb v4: bc5f3139b7ce55e5a116331eeec3b154a4204daa v3: 55c91481ec3bdc6d3bca4d3bce58c5ba39b636db v2: 80f7663f309c0d0b9cb89ed8f8b38301b207360d -- Petr^2 Spacek From pspacek at redhat.com Tue Sep 2 16:54:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Sep 2014 18:54:17 +0200 Subject: [Freeipa-devel] [PATCH 0279] Always use task associated ISC event instead of global inst->task Message-ID: <5405F639.9090406@redhat.com> Hello, Always use task associated with ISC event instead of global inst->task. This is necessary to prevent random crashes like: REQUIRE(task->state == task_state_running) failed https://fedorahosted.org/bind-dyndb-ldap/ticket/138 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0279-Always-use-task-associated-ISC-event-instead-of-glob.patch Type: text/x-patch Size: 6433 bytes Desc: not available URL: From abokovoy at redhat.com Wed Sep 3 05:55:15 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 08:55:15 +0300 Subject: [Freeipa-devel] Search Base issues In-Reply-To: <540631F0.1020805@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> Message-ID: <20140903055515.GH3593@redhat.com> Switching to freeipa-devel@ since it is an important issue. On Tue, 02 Sep 2014, Rob Crittenden wrote: >Chris Whittle wrote: >> If I do this >> >> ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D >> "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' >> -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" >> >> It works fine > >AFAICT there currently isn't a permission for the compat tree. The admin >user can do it via 'Admin can manage any entry" and of course DM can do >it because it can do anything. > >A temporary workaround would be to add an aci manually: > >dn: dc=example,dc=com >changetype: modify >add: aci >aci: (targetattr = "*")(target = >"ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl >"Read canlogin compat tree";allow (compare,read,search) userdn = >"ldap:///all";) > >This won't show up as a permission and will grant all authenticated >users read access to the canlogin compat tree. I'm assuming here this >contains entries keyed on uid. We have several use-cases for compat tree and I wonder what to do with completely unauthenticated case? Do we still want to support that? Exposing the same data anonymously over compat tree when it is available only for authenticated users over primary tree isn't secure. -- / Alexander Bokovoy From mkosek at redhat.com Wed Sep 3 08:17:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 10:17:08 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <20140903055515.GH3593@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> Message-ID: <5406CE84.1030600@redhat.com> On 09/03/2014 07:55 AM, Alexander Bokovoy wrote: > Switching to freeipa-devel@ since it is an important issue. > > On Tue, 02 Sep 2014, Rob Crittenden wrote: >> Chris Whittle wrote: >>> If I do this >>> >>> ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D >>> "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' >>> -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" >>> >>> It works fine >> >> AFAICT there currently isn't a permission for the compat tree. The admin >> user can do it via 'Admin can manage any entry" and of course DM can do >> it because it can do anything. >> >> A temporary workaround would be to add an aci manually: >> >> dn: dc=example,dc=com >> changetype: modify >> add: aci >> aci: (targetattr = "*")(target = >> "ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl >> "Read canlogin compat tree";allow (compare,read,search) userdn = >> "ldap:///all";) >> >> This won't show up as a permission and will grant all authenticated >> users read access to the canlogin compat tree. I'm assuming here this >> contains entries keyed on uid. > We have several use-cases for compat tree and I wonder what to do with > completely unauthenticated case? Do we still want to support that? Wouldn't hiding the compat tree only to authenticated users limit our Legacy Client feature? See "ipa-advise config-redhat-nss-ldap", this advise would stop working after this change, right? We already show selected subset of attributes to anonymous, I think we should continue with that: # ipa permission-show "System: Read User Standard Attributes" Permission name: System: Read User Standard Attributes Granted rights: read, compare, search Effective attributes: cn, description, displayname, gecos, gidnumber, givenname, homedirectory, initials, ipantsecurityidentifier, loginshell, manager, objectclass, sn, title, uid, uidnumber Default attributes: displayname, description, title, objectclass, loginshell, ipantsecurityidentifier, uidnumber, gidnumber, initials, manager, gecos, sn, homedirectory, givenname, cn, uid Bind rule type: anonymous Subtree: cn=users,cn=accounts,dc=mkosek-fedora20,dc=test Type: user > Exposing the same data anonymously over compat tree when it is available > only for authenticated users over primary tree isn't secure. If you check cn=users,cn=Schema Compatibility,cn=plugins,cn=config you would see that we only allow attributes we already expose to anonymous as in the basic permission. So it is not that bad. But maybe we should add a new internal "link" between standard and compat tree permissions and issue a warning when visibility of one is changed... Regarding missing compat permissions, I would personally add these: System: Read User Compat Tree System: Read Group Compat Tree System: Read Host Compat Tree System: Read Netgroup Compat Tree so that they are close to their standard tree alternatives. Martin From pviktori at redhat.com Wed Sep 3 08:45:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 10:45:14 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406CE84.1030600@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> Message-ID: <5406D51A.8010500@redhat.com> On 09/03/2014 10:17 AM, Martin Kosek wrote: [...] >> Exposing the same data anonymously over compat tree when it is available >> only for authenticated users over primary tree isn't secure. > > If you check > cn=users,cn=Schema Compatibility,cn=plugins,cn=config > you would see that we only allow attributes we already expose to anonymous as > in the basic permission. So it is not that bad. For users, yes. I assume we want the others to be authenticated only? > But maybe we should add a new internal "link" between standard and compat tree > permissions and issue a warning when visibility of one is changed... > > Regarding missing compat permissions, I would personally add these: > > System: Read User Compat Tree > System: Read Group Compat Tree > System: Read Host Compat Tree > System: Read Netgroup Compat Tree > > so that they are close to their standard tree alternatives. -- Petr? From mbasti at redhat.com Wed Sep 3 09:54:38 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 11:54:38 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5405E653.2050604@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> Message-ID: <5406E55E.3030006@redhat.com> On 02/09/14 17:46, Petr Spacek wrote: > On 25.8.2014 14:52, Martin Basti wrote: >> 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 > > Functional ACK, it works for me. It can be pushed if Python gurus are > okay with the code. > > # ipa dnszone-add . > Authoritative nameserver: @ > Administrator e-mail address [hostmaster.]: > >>> Administrator e-mail address: missing address domain > Administrator e-mail address [hostmaster.]: hostmaster. > >>> Administrator e-mail address: missing address domain > Administrator e-mail address [hostmaster.]: hostmaster.test. > Nameserver IP address: 127.0.0.1 > Zone name: . > Active zone: TRUE > Authoritative nameserver: @ > Administrator e-mail address: hostmaster.test. > SOA serial: 1409672572 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant > IPA.EXAMPLE krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; > Dynamic update: FALSE > Allow query: any; > Allow transfer: none; > > # ipa dnszone-mod . --expire=555 > Zone name: . > Active zone: TRUE > Authoritative nameserver: @ > Administrator e-mail address: hostmaster.test. > SOA serial: 1409672710 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 555 > SOA minimum: 3600 > Allow query: any; > Allow transfer: none; > > # ipa dnszone-del . > -------------------- > Deleted DNS zone "." > -------------------- > > "Administrator e-mail address: missing address domain" failure is IMHO > acceptable in this case. It seems unlikely that root domain will have > MX records :-) > I noticed that during patch creation, the behavior seems good to me. -- Martin Basti From pviktori at redhat.com Wed Sep 3 10:17:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 12:17:27 +0200 Subject: [Freeipa-devel] [PATCH[ 0639 permission plugin: Make --target available in the CLI Message-ID: <5406EAB7.1080209@redhat.com> This fixes https://fedorahosted.org/freeipa/ticket/4522. The API is already tested and the attribute is available in the UI. Pushed as one-liner to: ipa-4-0: 1044d09333114058bf38df501acc12708329af73 ipa-4-1: c01c61618d5e768fde0376b2f46b4887308f7a86 master: 4fbba3f7b86e4e7c8890911da650a3b55cc9a046 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0639-permission-plugin-Make-target-available-in-the-CLI.patch Type: text/x-patch Size: 914 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 3 10:26:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:26:31 +0200 Subject: [Freeipa-devel] [PATCH[ 0639 permission plugin: Make --target available in the CLI In-Reply-To: <5406EAB7.1080209@redhat.com> References: <5406EAB7.1080209@redhat.com> Message-ID: <5406ECD7.90009@redhat.com> On 09/03/2014 12:17 PM, Petr Viktorin wrote: > This fixes https://fedorahosted.org/freeipa/ticket/4522. The API is already > tested and the attribute is available in the UI. > > Pushed as one-liner to: > ipa-4-0: 1044d09333114058bf38df501acc12708329af73 > ipa-4-1: c01c61618d5e768fde0376b2f46b4887308f7a86 > master: 4fbba3f7b86e4e7c8890911da650a3b55cc9a046 Given that we now publish this attribute in CLI, shouldn't we improve it's label and docs? I am not sure if just plain "ACI target DN" is useful for anyone not very familiar with ACI structure. Maybe we should label it as just "Target DN" with docs something like "Optional DN to apply permissions to (can be used on top of Subtree)" Martin From mkosek at redhat.com Wed Sep 3 10:27:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:27:44 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5405E653.2050604@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> Message-ID: <5406ED20.7040703@redhat.com> On 09/02/2014 05:46 PM, Petr Spacek wrote: > On 25.8.2014 14:52, Martin Basti wrote: >> 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 > > Functional ACK, it works for me. It can be pushed if Python gurus are okay with > the code. Is it safe to commit the change given that bind-dyndb-ldap still crash when "." is removed? Wouldn't it break our CI tests? Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it would be soon. Martin From mkosek at redhat.com Wed Sep 3 10:30:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:30:56 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation In-Reply-To: <5405E46F.6040703@redhat.com> References: <53F62A8D.30303@redhat.com> <5405E46F.6040703@redhat.com> Message-ID: <5406EDE0.3000806@redhat.com> On 09/02/2014 05:38 PM, Petr Spacek wrote: > On 21.8.2014 19:21, Martin Basti wrote: >> 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. > > Functional ACK. It can be pushed if Python gurus don't see any problem. > I think the patches will need a rebase before push, I cannot apply them to my tree. The Python part itself looked good to me. Martin From pviktori at redhat.com Wed Sep 3 10:32:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 12:32:22 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406D51A.8010500@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> Message-ID: <5406EE36.6020009@redhat.com> On 09/03/2014 10:45 AM, Petr Viktorin wrote: > On 09/03/2014 10:17 AM, Martin Kosek wrote: > [...] >>> Exposing the same data anonymously over compat tree when it is available >>> only for authenticated users over primary tree isn't secure. >> >> If you check >> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >> you would see that we only allow attributes we already expose to >> anonymous as >> in the basic permission. So it is not that bad. > > For users, yes. I assume we want the others to be authenticated only? > >> But maybe we should add a new internal "link" between standard and >> compat tree >> permissions and issue a warning when visibility of one is changed... >> >> Regarding missing compat permissions, I would personally add these: >> >> System: Read User Compat Tree >> System: Read Group Compat Tree >> System: Read Host Compat Tree >> System: Read Netgroup Compat Tree Also, what about sudoers? -- Petr? From mkosek at redhat.com Wed Sep 3 10:34:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:34:28 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406EE36.6020009@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <5406EE36.6020009@redhat.com> Message-ID: <5406EEB4.5020306@redhat.com> On 09/03/2014 12:32 PM, Petr Viktorin wrote: > On 09/03/2014 10:45 AM, Petr Viktorin wrote: >> On 09/03/2014 10:17 AM, Martin Kosek wrote: >> [...] >>>> Exposing the same data anonymously over compat tree when it is available >>>> only for authenticated users over primary tree isn't secure. >>> >>> If you check >>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>> you would see that we only allow attributes we already expose to >>> anonymous as >>> in the basic permission. So it is not that bad. >> >> For users, yes. I assume we want the others to be authenticated only? >> >>> But maybe we should add a new internal "link" between standard and >>> compat tree >>> permissions and issue a warning when visibility of one is changed... >>> >>> Regarding missing compat permissions, I would personally add these: >>> >>> System: Read User Compat Tree >>> System: Read Group Compat Tree >>> System: Read Host Compat Tree >>> System: Read Netgroup Compat Tree > > Also, what about sudoers? What about them? I thought we have that part resolved already: # ipa permission-find sudoers -------------------- 1 permission matched -------------------- Permission name: System: Read Sudoers compat tree Granted rights: read, compare, search Effective attributes: cn, description, objectclass, ou, sudocommand, sudohost, sudonotafter, sudonotbefore, sudooption, sudoorder, sudorunas, sudorunasgroup, sudorunasuser, sudouser Default attributes: sudonotafter, description, sudouser, cn, objectclass, sudooption, sudocommand, sudonotbefore, sudorunas, sudorunasuser, sudohost, ou, sudoorder, sudorunasgroup Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: ou=sudoers,dc=mkosek-fedora20,dc=test ---------------------------- Number of entries returned 1 ---------------------------- Martin From dkupka at redhat.com Wed Sep 3 10:37:06 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 03 Sep 2014 12:37:06 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5405B080.4010509@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> Message-ID: <5406EF52.1000403@redhat.com> On 09/02/2014 01:56 PM, Jan Cholasta wrote: > Dne 29.8.2014 v 14:34 David Kupka napsal(a): >> 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. > > I didn't notice the patch is targeted for 4.0. Can you please provide > patches for both ipa-4-0 and ipa-4-1/master? > Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on ipa-4-0. >>> >>> >>> 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 > > You removed the comments, but left the attributes there. You should > remove them as well, they are not necessary, as you set them all in > __init__(). > Removed. >>> >>> >>> 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. > > OK, no need to include the TODO comment though. > >> >>> >>> I haven't done functional testing yet, expect more comments later. >>> >>> Honza >>> >> > > 12) ipa-client-install still uses ipa-getcert instead of certmonger API > to request the host certificate, but since we plan on stopping doing > that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't > have to do anything about it. Ok. I will leave it on you since you are owner of this ticket. > > > 13) You require dict for criteria in get_request_id, but you pass tuples > to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which > makes them fail. Good point, fixed. > > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-5-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 32035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-5-ipa40-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 29313 bytes Desc: not available URL: From abokovoy at redhat.com Wed Sep 3 10:39:04 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 13:39:04 +0300 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406D51A.8010500@redhat.com> References: <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> Message-ID: <20140903103904.GI3593@redhat.com> On Wed, 03 Sep 2014, Petr Viktorin wrote: >On 09/03/2014 10:17 AM, Martin Kosek wrote: >[...] >>>Exposing the same data anonymously over compat tree when it is available >>>only for authenticated users over primary tree isn't secure. >> >>If you check >>cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>you would see that we only allow attributes we already expose to anonymous as >>in the basic permission. So it is not that bad. > >For users, yes. I assume we want the others to be authenticated only? My point was that if we are hiding from anonymous access even the fact that certain user or group exists, compat tree is the one where we were leaking this information. Do we want to continue giving it out for unauthenticated? It is not about specific attributes but rather just the fact that certain user or group exists. Finally, sudo compat tree shouldn't be an issue as SSSD does use authenticated access and native sudo.ldap plugin supports using bind DN. The only issue is switching from unauthenticated 3.3 to authenticated 4.0.x where your existing clients using non-bound version will stop authorizing sudo commands. And this issue is huge. -- / Alexander Bokovoy From pviktori at redhat.com Wed Sep 3 10:43:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 12:43:14 +0200 Subject: [Freeipa-devel] [PATCH[ 0639 permission plugin: Make --target available in the CLI In-Reply-To: <5406ECD7.90009@redhat.com> References: <5406EAB7.1080209@redhat.com> <5406ECD7.90009@redhat.com> Message-ID: <5406F0C2.5050208@redhat.com> On 09/03/2014 12:26 PM, Martin Kosek wrote: > On 09/03/2014 12:17 PM, Petr Viktorin wrote: >> This fixes https://fedorahosted.org/freeipa/ticket/4522. The API is already >> tested and the attribute is available in the UI. >> >> Pushed as one-liner to: >> ipa-4-0: 1044d09333114058bf38df501acc12708329af73 >> ipa-4-1: c01c61618d5e768fde0376b2f46b4887308f7a86 >> master: 4fbba3f7b86e4e7c8890911da650a3b55cc9a046 > > Given that we now publish this attribute in CLI, shouldn't we improve it's > label and docs? I am not sure if just plain "ACI target DN" is useful for > anyone not very familiar with ACI structure. You're right, as always > Maybe we should label it as just "Target DN" with docs something like "Optional > DN to apply permissions to (can be used on top of Subtree)" Instead I parenthesized the major limitation (specifying a target outside of subtree will give an ACI error) and the usual use case. Does this look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0641-permission-plugin-Improve-description-of-the-target-.patch Type: text/x-patch Size: 1001 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 3 10:45:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:45:03 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5406EF52.1000403@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> Message-ID: <5406F12F.9030707@redhat.com> On 09/03/2014 12:37 PM, David Kupka wrote: > On 09/02/2014 01:56 PM, Jan Cholasta wrote: >> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>> 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. >> >> I didn't notice the patch is targeted for 4.0. Can you please provide >> patches for both ipa-4-0 and ipa-4-1/master? >> > > Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on ipa-4-0. > >>>> >>>> >>>> 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 >> >> You removed the comments, but left the attributes there. You should >> remove them as well, they are not necessary, as you set them all in >> __init__(). >> > > Removed. > >>>> >>>> >>>> 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. >> >> OK, no need to include the TODO comment though. >> >>> >>>> >>>> I haven't done functional testing yet, expect more comments later. >>>> >>>> Honza >>>> >>> >> >> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >> to request the host certificate, but since we plan on stopping doing >> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >> have to do anything about it. > > Ok. I will leave it on you since you are owner of this ticket. > >> >> >> 13) You require dict for criteria in get_request_id, but you pass tuples >> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >> makes them fail. > > Good point, fixed. It seems we are getting close to resolving this ticket, so I am just checking - are we OK with the new certmonger 0.75.13, given that it is not in Fedora 20? I assume yes as it is in F21 and we will put it to our F20 Copr repo anyway. Martin From mbasti at redhat.com Wed Sep 3 10:45:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 12:45:54 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5406ED20.7040703@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> Message-ID: <5406F162.4060409@redhat.com> On 03/09/14 12:27, Martin Kosek wrote: > On 09/02/2014 05:46 PM, Petr Spacek wrote: >> On 25.8.2014 14:52, Martin Basti wrote: >>> 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 >> Functional ACK, it works for me. It can be pushed if Python gurus are okay with >> the code. > Is it safe to commit the change given that bind-dyndb-ldap still crash when "." > is removed? Wouldn't it break our CI tests? > > Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it > would be soon. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel It will broke tests, don't push it until bind-dyndb-ldap is fixed. Currently I'm testing bind-dyndb-ldap related patch. -- Martin Basti From mkosek at redhat.com Wed Sep 3 10:49:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:49:01 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <20140903103904.GI3593@redhat.com> References: <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> Message-ID: <5406F21D.6040802@redhat.com> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: > On Wed, 03 Sep 2014, Petr Viktorin wrote: >> On 09/03/2014 10:17 AM, Martin Kosek wrote: >> [...] >>>> Exposing the same data anonymously over compat tree when it is available >>>> only for authenticated users over primary tree isn't secure. >>> >>> If you check >>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>> you would see that we only allow attributes we already expose to anonymous as >>> in the basic permission. So it is not that bad. >> >> For users, yes. I assume we want the others to be authenticated only? > My point was that if we are hiding from anonymous access even the fact > that certain user or group exists Are we? # ipa permission-find standard -------------------- 1 permission matched -------------------- Permission name: System: Read User Standard Attributes Granted rights: read, compare, search Effective attributes: cn, description, displayname, gecos, gidnumber, givenname, homedirectory, initials, ipantsecurityidentifier, loginshell, manager, objectclass, sn, title, uid, uidnumber Default attributes: displayname, description, title, objectclass, loginshell, ipantsecurityidentifier, uidnumber, gidnumber, initials, manager, gecos, sn, homedirectory, givenname, cn, uid Bind rule type: *anonymous* Subtree: cn=users,cn=accounts,dc=mkosek-fedora20,dc=test Type: user ---------------------------- Number of entries returned 1 ---------------------------- # ipa permission-show "System: Read Groups" Permission name: System: Read Groups Granted rights: read, compare, search Effective attributes: businesscategory, cn, description, gidnumber, ipaexternalmember, ipantsecurityidentifier, ipauniqueid, mepmanagedby, o, objectclass, ou, owner, seealso Default attributes: businesscategory, cn, ipaexternalmember, objectclass, ipantsecurityidentifier, description, gidnumber, o, mepmanagedby, ipauniqueid, owner, ou, seealso Bind rule type: *anonymous* Subtree: cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test Type: group > compat tree is the one where we were > leaking this information. Do we want to continue giving it out for > unauthenticated? > > It is not about specific attributes but rather just the fact that > certain user or group exists. > > Finally, sudo compat tree shouldn't be an issue as SSSD does use > authenticated access and native sudo.ldap plugin supports using bind DN. > > The only issue is switching from unauthenticated 3.3 to authenticated > 4.0.x where your existing clients using non-bound version will stop > authorizing sudo commands. And this issue is huge. Right, this affects Legacy clients feature, makes our ipa-advise insufficient. Martin From mkosek at redhat.com Wed Sep 3 10:50:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 12:50:00 +0200 Subject: [Freeipa-devel] [PATCH[ 0639 permission plugin: Make --target available in the CLI In-Reply-To: <5406F0C2.5050208@redhat.com> References: <5406EAB7.1080209@redhat.com> <5406ECD7.90009@redhat.com> <5406F0C2.5050208@redhat.com> Message-ID: <5406F258.1060402@redhat.com> On 09/03/2014 12:43 PM, Petr Viktorin wrote: > On 09/03/2014 12:26 PM, Martin Kosek wrote: >> On 09/03/2014 12:17 PM, Petr Viktorin wrote: >>> This fixes https://fedorahosted.org/freeipa/ticket/4522. The API is already >>> tested and the attribute is available in the UI. >>> >>> Pushed as one-liner to: >>> ipa-4-0: 1044d09333114058bf38df501acc12708329af73 >>> ipa-4-1: c01c61618d5e768fde0376b2f46b4887308f7a86 >>> master: 4fbba3f7b86e4e7c8890911da650a3b55cc9a046 >> >> Given that we now publish this attribute in CLI, shouldn't we improve it's >> label and docs? I am not sure if just plain "ACI target DN" is useful for >> anyone not very familiar with ACI structure. > > You're right, as always Heh, I have my moments :) >> Maybe we should label it as just "Target DN" with docs something like "Optional >> DN to apply permissions to (can be used on top of Subtree)" > > Instead I parenthesized the major limitation (specifying a target outside of > subtree will give an ACI error) and the usual use case. > Does this look OK? It does - ACK. Thanks, Martin From abokovoy at redhat.com Wed Sep 3 11:02:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 14:02:53 +0300 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406F21D.6040802@redhat.com> References: <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> Message-ID: <20140903110253.GJ3593@redhat.com> On Wed, 03 Sep 2014, Martin Kosek wrote: >On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>> [...] >>>>> Exposing the same data anonymously over compat tree when it is available >>>>> only for authenticated users over primary tree isn't secure. >>>> >>>> If you check >>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>> you would see that we only allow attributes we already expose to anonymous as >>>> in the basic permission. So it is not that bad. >>> >>> For users, yes. I assume we want the others to be authenticated only? >> My point was that if we are hiding from anonymous access even the fact >> that certain user or group exists > >Are we? I was under impression we've followed the change requested by some our users to knock down anonymous access completely but I still see # FIXME: We need to allow truly anonymous access only to NIS data for # older clients. We need to allow broad access to most attributes only # to authenticated users in install/share/default-aci.ldif Maybe it is time to do so? >> 4.0.x where your existing clients using non-bound version will stop >> authorizing sudo commands. And this issue is huge. > >Right, this affects Legacy clients feature, makes our ipa-advise insufficient. Means we should improve the advices. -- / Alexander Bokovoy From pvoborni at redhat.com Wed Sep 3 11:14:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 03 Sep 2014 13:14:55 +0200 Subject: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation In-Reply-To: <1409671330.4163.0.camel@redhat.com> References: <1408481179.3505.6.camel@redhat.com> <1409249666.9966.4.camel@redhat.com> <5405AEB4.4080809@redhat.com> <1409671330.4163.0.camel@redhat.com> Message-ID: <5406F82F.2080707@redhat.com> On 2.9.2014 17:22, Nathaniel McCallum wrote: > On Tue, 2014-09-02 at 13:49 +0200, Petr Vobornik wrote: >> On 28.8.2014 20:14, Nathaniel McCallum wrote: >>> 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 >>> >> >> ACK if comment below doesn't need any change: >> >> Maybe I'm missing something, but why do we do following check: `if >> 'objectclass' in entry_attrs:`? Shouldn't it be always True? Since >> the objectclass is set in LDAPCreate.execute. A pre-callback in an third >> party plugin can remove it, but I don't think we should care. > > I also thought that was odd, but I cargo-culted it to retain backwards > compatibility. Attached is a version of the patch which doesn't retain > this. I don't care which gets merged. > > Nathaniel > ACK Pushed to: master: e26b3e14eb07baa4868109307d9d064bab4c5e0b ipa-4-1: 480512f6db4d4b487e3376e7bca1b658d76c6f86 ipa-4-0: 4200af9b7a8c254b02034b067b29a3e66532daa2 -- Petr Vobornik From pviktori at redhat.com Wed Sep 3 11:27:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 13:27:30 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree Message-ID: <5406FB22.5090004@redhat.com> Hello, This adds managed read permissions to the compat tree. For users it grants anonymous access; authenticated users can read groups, hosts and netgroups. I'm unsure if this is what we want to do for groups, but "Read Group Membership" is only granted to authenticated users by default, and the compat tree exposes memberuid. https://fedorahosted.org/freeipa/ticket/4521 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0640-Add-managed-read-permissions-for-compat-tree.patch Type: text/x-patch Size: 9783 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 3 11:28:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 13:28:26 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <20140903110253.GJ3593@redhat.com> References: <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> Message-ID: <5406FB5A.9090004@redhat.com> On 09/03/2014 01:02 PM, Alexander Bokovoy wrote: > On Wed, 03 Sep 2014, Martin Kosek wrote: >> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >>> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>>> [...] >>>>>> Exposing the same data anonymously over compat tree when it is available >>>>>> only for authenticated users over primary tree isn't secure. >>>>> >>>>> If you check >>>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>>> you would see that we only allow attributes we already expose to anonymous as >>>>> in the basic permission. So it is not that bad. >>>> >>>> For users, yes. I assume we want the others to be authenticated only? >>> My point was that if we are hiding from anonymous access even the fact >>> that certain user or group exists >> >> Are we? > I was under impression we've followed the change requested by some our > users to knock down anonymous access completely but I still see > > # FIXME: We need to allow truly anonymous access only to NIS data for > # older clients. We need to allow broad access to most attributes only > # to authenticated users > > in install/share/default-aci.ldif > > Maybe it is time to do so? Not sure about this FIXME comment, we already show most attributes to authenticated users only, we only show the very basic POSIX attributes. You can check yourself with # ipa permission-find "Read User" >>> 4.0.x where your existing clients using non-bound version will stop >>> authorizing sudo commands. And this issue is huge. >> >> Right, this affects Legacy clients feature, makes our ipa-advise insufficient. > Means we should improve the advices. ipa-advise would then need to refer to some common system account + it's password it would bind with. Should we file RFE? Is this a right move? Martin From abokovoy at redhat.com Wed Sep 3 12:04:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 15:04:32 +0300 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <5406FB5A.9090004@redhat.com> References: <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> <5406FB5A.9090004@redhat.com> Message-ID: <20140903120432.GK3593@redhat.com> On Wed, 03 Sep 2014, Martin Kosek wrote: >On 09/03/2014 01:02 PM, Alexander Bokovoy wrote: >> On Wed, 03 Sep 2014, Martin Kosek wrote: >>> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >>>> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>>>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>>>> [...] >>>>>>> Exposing the same data anonymously over compat tree when it is available >>>>>>> only for authenticated users over primary tree isn't secure. >>>>>> >>>>>> If you check >>>>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>>>> you would see that we only allow attributes we already expose to anonymous as >>>>>> in the basic permission. So it is not that bad. >>>>> >>>>> For users, yes. I assume we want the others to be authenticated only? >>>> My point was that if we are hiding from anonymous access even the fact >>>> that certain user or group exists >>> >>> Are we? >> I was under impression we've followed the change requested by some our >> users to knock down anonymous access completely but I still see >> >> # FIXME: We need to allow truly anonymous access only to NIS data for >> # older clients. We need to allow broad access to most attributes only >> # to authenticated users >> >> in install/share/default-aci.ldif >> >> Maybe it is time to do so? > >Not sure about this FIXME comment, we already show most attributes to >authenticated users only, we only show the very basic POSIX attributes. You can >check yourself with > ># ipa permission-find "Read User" No, my question is not about that. We had this discussion in January where people were asking about shutting anonymous binds to non-rootDSE. Do we want to follow that now that we have easy way to manage permissions and remove anonymous binds by default? And another request was repeated to me lately at a local security meetup by one of heavy IPA users: can we make an option to prevent authenticated users from seeing details of other users? This is a lock down most welcomed by governmental contractors, I've heard. With our existing permission scheme we seem to be able to implement that, isn't it? >>>> 4.0.x where your existing clients using non-bound version will stop >>>> authorizing sudo commands. And this issue is huge. >>> >>> Right, this affects Legacy clients feature, makes our ipa-advise insufficient. >> Means we should improve the advices. > >ipa-advise would then need to refer to some common system account + it's >password it would bind with. Should we file RFE? Is this a right move? Yes, we need to file RFE and make recommendations to always have BINDDN/BINDPW or GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL (see sudoers.ldap and ldap.conf manpages). -- / Alexander Bokovoy From jcholast at redhat.com Wed Sep 3 12:07:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 14:07:33 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5406F12F.9030707@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5406F12F.9030707@redhat.com> Message-ID: <54070485.1040109@redhat.com> Dne 3.9.2014 v 12:45 Martin Kosek napsal(a): > On 09/03/2014 12:37 PM, David Kupka wrote: >> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>> 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. >>> >>> I didn't notice the patch is targeted for 4.0. Can you please provide >>> patches for both ipa-4-0 and ipa-4-1/master? >>> >> >> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on ipa-4-0. >> >>>>> >>>>> >>>>> 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 >>> >>> You removed the comments, but left the attributes there. You should >>> remove them as well, they are not necessary, as you set them all in >>> __init__(). >>> >> >> Removed. >> >>>>> >>>>> >>>>> 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. >>> >>> OK, no need to include the TODO comment though. >>> >>>> >>>>> >>>>> I haven't done functional testing yet, expect more comments later. >>>>> >>>>> Honza >>>>> >>>> >>> >>> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >>> to request the host certificate, but since we plan on stopping doing >>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >>> have to do anything about it. >> >> Ok. I will leave it on you since you are owner of this ticket. >> >>> >>> >>> 13) You require dict for criteria in get_request_id, but you pass tuples >>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >>> makes them fail. >> >> Good point, fixed. > > It seems we are getting close to resolving this ticket, so I am just checking - > are we OK with the new certmonger 0.75.13, given that it is not in Fedora 20? > > I assume yes as it is in F21 and we will put it to our F20 Copr repo anyway. > > Martin > I was about to ask the same. Another option is to ask Nalin to update certmonger in F20. -- Jan Cholasta From mbasti at redhat.com Wed Sep 3 12:25:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 14:25:30 +0200 Subject: [Freeipa-devel] [PATCH 0279] Always use task associated ISC event instead of global inst->task In-Reply-To: <5405F639.9090406@redhat.com> References: <5405F639.9090406@redhat.com> Message-ID: <540708BA.7020503@redhat.com> On 02/09/14 18:54, Petr Spacek wrote: > Hello, > > Always use task associated with ISC event instead of global inst->task. > > This is necessary to prevent random crashes like: > REQUIRE(task->state == task_state_running) failed > > https://fedorahosted.org/bind-dyndb-ldap/ticket/138 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Functional ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Sep 3 12:27:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 14:27:34 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <5406FB22.5090004@redhat.com> References: <5406FB22.5090004@redhat.com> Message-ID: <54070936.3070003@redhat.com> On 09/03/2014 01:27 PM, Petr Viktorin wrote: > Hello, > This adds managed read permissions to the compat tree. > > For users it grants anonymous access; authenticated users can read > groups, hosts and netgroups. > > I'm unsure if this is what we want to do for groups, but "Read Group > Membership" is only granted to authenticated users by default, and the > compat tree exposes memberuid. > > https://fedorahosted.org/freeipa/ticket/4521 Self-NACK, there's a typo (though I could swear I tested this :/) -- Petr? From mkosek at redhat.com Wed Sep 3 12:32:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 14:32:44 +0200 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <20140903120432.GK3593@redhat.com> References: <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> <5406FB5A.9090004@redhat.com> <20140903120432.GK3593@redhat.com> Message-ID: <54070A6C.4010400@redhat.com> On 09/03/2014 02:04 PM, Alexander Bokovoy wrote: > On Wed, 03 Sep 2014, Martin Kosek wrote: >> On 09/03/2014 01:02 PM, Alexander Bokovoy wrote: >>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >>>>> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>>>>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>>>>> [...] >>>>>>>> Exposing the same data anonymously over compat tree when it is available >>>>>>>> only for authenticated users over primary tree isn't secure. >>>>>>> >>>>>>> If you check >>>>>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>>>>> you would see that we only allow attributes we already expose to >>>>>>> anonymous as >>>>>>> in the basic permission. So it is not that bad. >>>>>> >>>>>> For users, yes. I assume we want the others to be authenticated only? >>>>> My point was that if we are hiding from anonymous access even the fact >>>>> that certain user or group exists >>>> >>>> Are we? >>> I was under impression we've followed the change requested by some our >>> users to knock down anonymous access completely but I still see >>> >>> # FIXME: We need to allow truly anonymous access only to NIS data for >>> # older clients. We need to allow broad access to most attributes only >>> # to authenticated users >>> >>> in install/share/default-aci.ldif >>> >>> Maybe it is time to do so? >> >> Not sure about this FIXME comment, we already show most attributes to >> authenticated users only, we only show the very basic POSIX attributes. You can >> check yourself with >> >> # ipa permission-find "Read User" > No, my question is not about that. We had this discussion in January > where people were asking about shutting anonymous binds to non-rootDSE. > Do we want to follow that now that we have easy way to manage > permissions and remove anonymous binds by default? Now it is easy to change different parts of your DIT to different view levels. You can easily turn off anonymous access to users without having to disable anonymous access on DS cn=config level. > And another request was repeated to me lately at a local security meetup > by one of heavy IPA users: can we make an option to prevent > authenticated users from seeing details of other users? This is a > lock down most welcomed by governmental contractors, I've heard. > With our existing permission scheme we seem to be able to implement > that, isn't it? Hm, it would be difficult. SSSD still needs to be able to read all that, so all host/FQDN principals need to access that. So you would first need to have a hostgroup with all hosts to be able to point permissions at them. >>>>> 4.0.x where your existing clients using non-bound version will stop >>>>> authorizing sudo commands. And this issue is huge. >>>> >>>> Right, this affects Legacy clients feature, makes our ipa-advise insufficient. >>> Means we should improve the advices. >> >> ipa-advise would then need to refer to some common system account + it's >> password it would bind with. Should we file RFE? Is this a right move? > Yes, we need to file RFE and make recommendations to always have > BINDDN/BINDPW or GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL > (see sudoers.ldap and ldap.conf manpages). Ok, please file the ticket then. Martin From mkosek at redhat.com Wed Sep 3 12:34:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 14:34:44 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54070485.1040109@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5406F12F.9030707@redhat.com> <54070485.1040109@redhat.com> Message-ID: <54070AE4.8070301@redhat.com> On 09/03/2014 02:07 PM, Jan Cholasta wrote: > Dne 3.9.2014 v 12:45 Martin Kosek napsal(a): >> On 09/03/2014 12:37 PM, David Kupka wrote: >>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>> 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. >>>> >>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>> patches for both ipa-4-0 and ipa-4-1/master? >>>> >>> >>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on ipa-4-0. >>> >>>>>> >>>>>> >>>>>> 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 >>>> >>>> You removed the comments, but left the attributes there. You should >>>> remove them as well, they are not necessary, as you set them all in >>>> __init__(). >>>> >>> >>> Removed. >>> >>>>>> >>>>>> >>>>>> 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. >>>> >>>> OK, no need to include the TODO comment though. >>>> >>>>> >>>>>> >>>>>> I haven't done functional testing yet, expect more comments later. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> >>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >>>> to request the host certificate, but since we plan on stopping doing >>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >>>> have to do anything about it. >>> >>> Ok. I will leave it on you since you are owner of this ticket. >>> >>>> >>>> >>>> 13) You require dict for criteria in get_request_id, but you pass tuples >>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >>>> makes them fail. >>> >>> Good point, fixed. >> >> It seems we are getting close to resolving this ticket, so I am just checking - >> are we OK with the new certmonger 0.75.13, given that it is not in Fedora 20? >> >> I assume yes as it is in F21 and we will put it to our F20 Copr repo anyway. >> >> Martin >> > > I was about to ask the same. Another option is to ask Nalin to update > certmonger in F20. > CCing Nalin. What is your take on this, do you plan to release it to F20. AFAIK, it is just stabilization/bugfixing release so it should fit there nicely. Martin From mbasti at redhat.com Wed Sep 3 12:40:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 14:40:22 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <5405E35A.2030801@redhat.com> References: <53F4C0A5.6030408@redhat.com> <53F59524.3040506@redhat.com> <53F5B4C9.3060708@redhat.com> <5405E35A.2030801@redhat.com> Message-ID: <54070C36.80304@redhat.com> On 02/09/14 17:33, Petr Spacek wrote: > On 21.8.2014 10:58, Martin Basti wrote: >> 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. >> > > # ipa dnsrecord-add ipa.example. '*' --ns-rec='ns' > ipa: ERROR: invalid 'idnsname': owner of DNAME, DS, NS records should > not be a wildcard domain name (RFC 4592) > > It would be nice to have more specific reference to RFC: 'RFC 4592 > section 4'. > > CondACK: It can be pushed if you amend the error message. > Updated patch attached. Please push to branches: ipa 4.0.x, 4.1, master -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0107.3-FIX-DNS-wildcard-records-RFC4592.patch Type: text/x-patch Size: 2413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0108.3-Tests-DNS-wildcard-records.patch Type: text/x-patch Size: 3926 bytes Desc: not available URL: From abokovoy at redhat.com Wed Sep 3 13:08:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 16:08:50 +0300 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <54070A6C.4010400@redhat.com> References: <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> <5406FB5A.9090004@redhat.com> <20140903120432.GK3593@redhat.com> <54070A6C.4010400@redhat.com> Message-ID: <20140903130850.GL3593@redhat.com> On Wed, 03 Sep 2014, Martin Kosek wrote: >On 09/03/2014 02:04 PM, Alexander Bokovoy wrote: >> On Wed, 03 Sep 2014, Martin Kosek wrote: >>> On 09/03/2014 01:02 PM, Alexander Bokovoy wrote: >>>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>>> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >>>>>> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>>>>>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>>>>>> [...] >>>>>>>>> Exposing the same data anonymously over compat tree when it is available >>>>>>>>> only for authenticated users over primary tree isn't secure. >>>>>>>> >>>>>>>> If you check >>>>>>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>>>>>> you would see that we only allow attributes we already expose to >>>>>>>> anonymous as >>>>>>>> in the basic permission. So it is not that bad. >>>>>>> >>>>>>> For users, yes. I assume we want the others to be authenticated only? >>>>>> My point was that if we are hiding from anonymous access even the fact >>>>>> that certain user or group exists >>>>> >>>>> Are we? >>>> I was under impression we've followed the change requested by some our >>>> users to knock down anonymous access completely but I still see >>>> >>>> # FIXME: We need to allow truly anonymous access only to NIS data for >>>> # older clients. We need to allow broad access to most attributes only >>>> # to authenticated users >>>> >>>> in install/share/default-aci.ldif >>>> >>>> Maybe it is time to do so? >>> >>> Not sure about this FIXME comment, we already show most attributes to >>> authenticated users only, we only show the very basic POSIX attributes. You can >>> check yourself with >>> >>> # ipa permission-find "Read User" >> No, my question is not about that. We had this discussion in January >> where people were asking about shutting anonymous binds to non-rootDSE. >> Do we want to follow that now that we have easy way to manage >> permissions and remove anonymous binds by default? > >Now it is easy to change different parts of your DIT to different view levels. >You can easily turn off anonymous access to users without having to disable >anonymous access on DS cn=config level. Yep, that's good and need to be documented, we don't have to push people to cn=config changes like documentation says now. > >> And another request was repeated to me lately at a local security meetup >> by one of heavy IPA users: can we make an option to prevent >> authenticated users from seeing details of other users? This is a >> lock down most welcomed by governmental contractors, I've heard. >> With our existing permission scheme we seem to be able to implement >> that, isn't it? > >Hm, it would be difficult. SSSD still needs to be able to read all that, so all >host/FQDN principals need to access that. So you would first need to have a >hostgroup with all hosts to be able to point permissions at them. Can we find a better solution here? I.e. make a filter that considers selfdn and denies access to other user and group accounts unless selfdn is memberof those groups? If current ACI syntax doesn't allow this, what can we do to extend the syntax? I see value in such changes as they will allow also to proceed to proper containerized setups (multiple trees in the same directory, invisible to each other). >>>>>> 4.0.x where your existing clients using non-bound version will stop >>>>>> authorizing sudo commands. And this issue is huge. >>>>> >>>>> Right, this affects Legacy clients feature, makes our ipa-advise insufficient. >>>> Means we should improve the advices. >>> >>> ipa-advise would then need to refer to some common system account + it's >>> password it would bind with. Should we file RFE? Is this a right move? >> Yes, we need to file RFE and make recommendations to always have >> BINDDN/BINDPW or GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL >> (see sudoers.ldap and ldap.conf manpages). > >Ok, please file the ticket then. Will do. -- / Alexander Bokovoy From pviktori at redhat.com Wed Sep 3 13:15:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 15:15:35 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54070936.3070003@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> Message-ID: <54071477.1020303@redhat.com> On 09/03/2014 02:27 PM, Petr Viktorin wrote: > On 09/03/2014 01:27 PM, Petr Viktorin wrote: >> Hello, >> This adds managed read permissions to the compat tree. >> >> For users it grants anonymous access; authenticated users can read >> groups, hosts and netgroups. >> >> I'm unsure if this is what we want to do for groups, but "Read Group >> Membership" is only granted to authenticated users by default, and the >> compat tree exposes memberuid. >> >> https://fedorahosted.org/freeipa/ticket/4521 > > Self-NACK, there's a typo (though I could swear I tested this :/) > > Fixed patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0640.2-Add-managed-read-permissions-for-compat-tree.patch Type: text/x-patch Size: 9783 bytes Desc: not available URL: From rcritten at redhat.com Wed Sep 3 13:18:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 09:18:14 -0400 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <20140903130850.GL3593@redhat.com> References: <540631F0.1020805@redhat.com> <20140903055515.GH3593@redhat.com> <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> <5406FB5A.9090004@redhat.com> <20140903120432.GK3593@redhat.com> <54070A6C.4010400@redhat.com> <20140903130850.GL3593@redhat.com> Message-ID: <54071516.3020208@redhat.com> Alexander Bokovoy wrote: > On Wed, 03 Sep 2014, Martin Kosek wrote: >> On 09/03/2014 02:04 PM, Alexander Bokovoy wrote: >>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>> On 09/03/2014 01:02 PM, Alexander Bokovoy wrote: >>>>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>>>> On 09/03/2014 12:39 PM, Alexander Bokovoy wrote: >>>>>>> On Wed, 03 Sep 2014, Petr Viktorin wrote: >>>>>>>> On 09/03/2014 10:17 AM, Martin Kosek wrote: >>>>>>>> [...] >>>>>>>>>> Exposing the same data anonymously over compat tree when it is >>>>>>>>>> available >>>>>>>>>> only for authenticated users over primary tree isn't secure. >>>>>>>>> >>>>>>>>> If you check >>>>>>>>> cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>>>>>>> you would see that we only allow attributes we already expose to >>>>>>>>> anonymous as >>>>>>>>> in the basic permission. So it is not that bad. >>>>>>>> >>>>>>>> For users, yes. I assume we want the others to be authenticated >>>>>>>> only? >>>>>>> My point was that if we are hiding from anonymous access even the >>>>>>> fact >>>>>>> that certain user or group exists >>>>>> >>>>>> Are we? >>>>> I was under impression we've followed the change requested by some our >>>>> users to knock down anonymous access completely but I still see >>>>> >>>>> # FIXME: We need to allow truly anonymous access only to NIS data for >>>>> # older clients. We need to allow broad access to most attributes only >>>>> # to authenticated users >>>>> >>>>> in install/share/default-aci.ldif >>>>> >>>>> Maybe it is time to do so? >>>> >>>> Not sure about this FIXME comment, we already show most attributes to >>>> authenticated users only, we only show the very basic POSIX >>>> attributes. You can >>>> check yourself with >>>> >>>> # ipa permission-find "Read User" >>> No, my question is not about that. We had this discussion in January >>> where people were asking about shutting anonymous binds to non-rootDSE. >>> Do we want to follow that now that we have easy way to manage >>> permissions and remove anonymous binds by default? >> >> Now it is easy to change different parts of your DIT to different view >> levels. >> You can easily turn off anonymous access to users without having to >> disable >> anonymous access on DS cn=config level. > Yep, that's good and need to be documented, we don't have to push people > to cn=config changes like documentation says now. > >> >>> And another request was repeated to me lately at a local security meetup >>> by one of heavy IPA users: can we make an option to prevent >>> authenticated users from seeing details of other users? This is a >>> lock down most welcomed by governmental contractors, I've heard. >>> With our existing permission scheme we seem to be able to implement >>> that, isn't it? >> >> Hm, it would be difficult. SSSD still needs to be able to read all >> that, so all >> host/FQDN principals need to access that. So you would first need to >> have a >> hostgroup with all hosts to be able to point permissions at them. > Can we find a better solution here? I.e. make a filter that considers > selfdn and denies access to other user and group accounts unless selfdn > is memberof those groups? > > If current ACI syntax doesn't allow this, what can we do to extend the > syntax? I see value in such changes as they will allow also to proceed > to proper containerized setups (multiple trees in the same directory, > invisible to each other). > > >>>>>>> 4.0.x where your existing clients using non-bound version will stop >>>>>>> authorizing sudo commands. And this issue is huge. >>>>>> >>>>>> Right, this affects Legacy clients feature, makes our ipa-advise >>>>>> insufficient. >>>>> Means we should improve the advices. >>>> >>>> ipa-advise would then need to refer to some common system account + >>>> it's >>>> password it would bind with. Should we file RFE? Is this a right move? >>> Yes, we need to file RFE and make recommendations to always have >>> BINDDN/BINDPW or >>> GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL >>> (see sudoers.ldap and ldap.conf manpages). >> >> Ok, please file the ticket then. > Will do. > Remember that most of the NIS/legacy systems that would actually use this are non-Linux so keep that in mind as you tighten things up. ipa-advise doesn't cover the cases of AIX, Solaris and HP/ux. rob From nalin at redhat.com Wed Sep 3 13:29:15 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 3 Sep 2014 09:29:15 -0400 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <54057D44.9040107@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> Message-ID: <20140903132915.GA21660@redhat.com> On Tue, Sep 02, 2014 at 10:18:12AM +0200, Jan Cholasta wrote: > Dne 27.8.2014 v 16:49 David Kupka napsal(a): > >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 > > ACK as long as this works for Nalin. The other half of this was cases where there's no ldap_uri set. Just so there's no confusion, if ldap_uri and/or server_uri are not set, what are the recommended fallback settings that should be used for constructing them? I suspect it's "server", then "host", which is the reverse of the order that they're currently being consulted, but I figured I'd ask while we're all here. Thanks, Nalin From abokovoy at redhat.com Wed Sep 3 13:33:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Sep 2014 16:33:25 +0300 Subject: [Freeipa-devel] Compat tree permissions In-Reply-To: <54071516.3020208@redhat.com> References: <5406CE84.1030600@redhat.com> <5406D51A.8010500@redhat.com> <20140903103904.GI3593@redhat.com> <5406F21D.6040802@redhat.com> <20140903110253.GJ3593@redhat.com> <5406FB5A.9090004@redhat.com> <20140903120432.GK3593@redhat.com> <54070A6C.4010400@redhat.com> <20140903130850.GL3593@redhat.com> <54071516.3020208@redhat.com> Message-ID: <20140903133325.GM3593@redhat.com> On Wed, 03 Sep 2014, Rob Crittenden wrote: >>>>> ipa-advise would then need to refer to some common system account + >>>>> it's >>>>> password it would bind with. Should we file RFE? Is this a right move? >>>> Yes, we need to file RFE and make recommendations to always have >>>> BINDDN/BINDPW or >>>> GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL >>>> (see sudoers.ldap and ldap.conf manpages). >>> >>> Ok, please file the ticket then. >> Will do. >> > >Remember that most of the NIS/legacy systems that would actually use >this are non-Linux so keep that in mind as you tighten things up. >ipa-advise doesn't cover the cases of AIX, Solaris and HP/ux. Yep. However: - NIS doesn't require LDAP access from client side and nis plugin will work fine as it uses slapi_*_internal_*() calls which are not subject to ACI evaluation. - LDAP with any non-anonymous bind will work, including simple bind over SSL. I've fixed recently cyrus-sasl bug with GSSAPI mech that was preventing GSSAPI authentication from AIX. Unfortunately, cyrus-sasl developers are not responsive, no answers from upstream for a month. Fedora/RHEL packages are not yet updated but I'm going to do that soon. This affects only server-side, so by fixing it we'll get GSSAPI working for old LDAP clients that support it. -- / Alexander Bokovoy From nalin at redhat.com Wed Sep 3 13:34:24 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 3 Sep 2014 09:34:24 -0400 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54070AE4.8070301@redhat.com> References: <53F367A4.9000802@redhat.com> <53F370F6.9030700@redhat.com> <53FB3C91.7010508@redhat.com> <53FD9F69.4010700@redhat.com> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5406F12F.9030707@redhat.com> <54070485.1040109@redhat.com> <54070AE4.8070301@redhat.com> Message-ID: <20140903133424.GC21660@redhat.com> On Wed, Sep 03, 2014 at 02:34:44PM +0200, Martin Kosek wrote: > On 09/03/2014 02:07 PM, Jan Cholasta wrote: > > I was about to ask the same. Another option is to ask Nalin to update > > certmonger in F20. > > CCing Nalin. What is your take on this, do you plan to release it to F20. > AFAIK, it is just stabilization/bugfixing release so it should fit there nicely. Assuming you don't hit any new bugs, yeah, that makes sense to me, too. The current F21 candidate build (not in bodhi yet... I should get to that) is probably what you'll see pop up for F20 as well. HTH, Nalin From jcholast at redhat.com Wed Sep 3 13:41:58 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 15:41:58 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <20140903132915.GA21660@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <20140903132915.GA21660@redhat.com> Message-ID: <54071AA6.5080507@redhat.com> Dne 3.9.2014 v 15:29 Nalin Dahyabhai napsal(a): > On Tue, Sep 02, 2014 at 10:18:12AM +0200, Jan Cholasta wrote: >> Dne 27.8.2014 v 16:49 David Kupka napsal(a): >>> 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 >> >> ACK as long as this works for Nalin. > > The other half of this was cases where there's no ldap_uri set. Just so > there's no confusion, if ldap_uri and/or server_uri are not set, what > are the recommended fallback settings that should be used for > constructing them? I suspect it's "server", then "host", which is the > reverse of the order that they're currently being consulted, but I > figured I'd ask while we're all here. "ldap_uri" is set only on servers, on clients you should use "server" (we should probably un-deprecate it). You could use "host" as a fallback, but it will only work on servers, as it points to the local host. IMO the right order is "server", then "ldap_uri", then maybe "host". > > Thanks, > > Nalin > -- Jan Cholasta From jcholast at redhat.com Wed Sep 3 13:43:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 15:43:24 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Add record(s) to /etc/host when IPA is configured as DNS server. In-Reply-To: <5405D985.8080800@redhat.com> References: <5405982F.3000709@redhat.com> <5405D985.8080800@redhat.com> Message-ID: <54071AFC.5010005@redhat.com> Hi, Dne 2.9.2014 v 16:51 David Kupka napsal(a): > Ok, the patch no longer depends on 0009. The reason is that 0012 is > going to ipa-4.0 and 0009 to ipa-4.1. > > On 09/02/2014 12:13 PM, David Kupka wrote: >> This patch depends on freeipa-dkupka-0009 as it modifies the same part >> of code. >> >> https://fedorahosted.org/freeipa/ticket/4220 Works for me, ACK. Honza -- Jan Cholasta From tbabej at redhat.com Wed Sep 3 13:53:14 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Sep 2014 15:53:14 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to Message-ID: <54071D4A.9040509@redhat.com> Hi, Makes sure that any new sources added are not already present in the entry. https://fedorahosted.org/freeipa/ticket/4508 -- 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-0260-ipa-client-install-Do-not-add-already-configured-sou.patch Type: text/x-patch Size: 2521 bytes Desc: not available URL: From jcholast at redhat.com Wed Sep 3 14:05:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 16:05:47 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5406EF52.1000403@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> Message-ID: <5407203B.3030709@redhat.com> Dne 3.9.2014 v 12:37 David Kupka napsal(a): > On 09/02/2014 01:56 PM, Jan Cholasta wrote: >> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>> 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. >> >> I didn't notice the patch is targeted for 4.0. Can you please provide >> patches for both ipa-4-0 and ipa-4-1/master? >> > > Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on ipa-4-0. There is a little bug in ipa-upgradeconfig in the 4.0 version of the patch. This is wrong: for request in requests: nss_dir, nickname, ca_name, pre_command, post_command, profile = request criteria = { 'cert-database': nss_dir, 'cert-nickname': nickname, 'ca-name': ca_name, 'template-profile': profile, } It should be: for nss_dir, nickname, ca_name, pre_command, post_command in requests: criteria = { 'cert-database': nss_dir, 'cert-nickname': nickname, 'ca-name': ca_name, } > >>>> >>>> >>>> 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 >> >> You removed the comments, but left the attributes there. You should >> remove them as well, they are not necessary, as you set them all in >> __init__(). >> > > Removed. > >>>> >>>> >>>> 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(). You no longer check if the profile argument is set in modify() - either re-introduce the check, or remove the default value of the argument to make it mandatory. >>>> >>>> >>>> 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. >> >> OK, no need to include the TODO comment though. >> >>> >>>> >>>> I haven't done functional testing yet, expect more comments later. >>>> >>>> Honza >>>> >>> >> >> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >> to request the host certificate, but since we plan on stopping doing >> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >> have to do anything about it. > > Ok. I will leave it on you since you are owner of this ticket. > >> >> >> 13) You require dict for criteria in get_request_id, but you pass tuples >> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >> makes them fail. > > Good point, fixed. I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it should be fixed as well. -- Jan Cholasta From pviktori at redhat.com Wed Sep 3 14:04:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 16:04:14 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Add record(s) to /etc/host when IPA is configured as DNS server. In-Reply-To: <54071AFC.5010005@redhat.com> References: <5405982F.3000709@redhat.com> <5405D985.8080800@redhat.com> <54071AFC.5010005@redhat.com> Message-ID: <54071FDE.6080701@redhat.com> On 09/03/2014 03:43 PM, Jan Cholasta wrote: > Hi, > > Dne 2.9.2014 v 16:51 David Kupka napsal(a): >> Ok, the patch no longer depends on 0009. The reason is that 0012 is >> going to ipa-4.0 and 0009 to ipa-4.1. >> >> On 09/02/2014 12:13 PM, David Kupka wrote: >>> This patch depends on freeipa-dkupka-0009 as it modifies the same part >>> of code. >>> >>> https://fedorahosted.org/freeipa/ticket/4220 > > Works for me, ACK. Pushed to: master: 8aa01e24a1664f5f523732f79ae8d842fb4417a8 ipa-4-1: 7baf8fecd410e5a8b64767d27a6a2848c4a00803 ipa-4-0: c1b680c54ec2bc0846c4e8a0f5d3260864d645b9 -- Petr? From mkosek at redhat.com Wed Sep 3 14:25:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 16:25:00 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <54071AA6.5080507@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <20140903132915.GA21660@redhat.com> <54071AA6.5080507@redhat.com> Message-ID: <540724BC.3000003@redhat.com> On 09/03/2014 03:41 PM, Jan Cholasta wrote: > Dne 3.9.2014 v 15:29 Nalin Dahyabhai napsal(a): >> On Tue, Sep 02, 2014 at 10:18:12AM +0200, Jan Cholasta wrote: >>> Dne 27.8.2014 v 16:49 David Kupka napsal(a): >>>> 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 >>> >>> ACK as long as this works for Nalin. >> >> The other half of this was cases where there's no ldap_uri set. Just so >> there's no confusion, if ldap_uri and/or server_uri are not set, what >> are the recommended fallback settings that should be used for >> constructing them? I suspect it's "server", then "host", which is the >> reverse of the order that they're currently being consulted, but I >> figured I'd ask while we're all here. > > "ldap_uri" is set only on servers, on clients you should use "server" (we > should probably un-deprecate it). You could use "host" as a fallback, but it > will only work on servers, as it points to the local host. IMO the right order > is "server", then "ldap_uri", then maybe "host". BTW what happens when original server that the client enrolled with no longer exist and was replaced by some other server with other FQDN. Will certmonger fail in this case or will it fall back and do DNS SRV record to find alternative server like "ipa" command does? Martin From dkupka at redhat.com Wed Sep 3 14:25:21 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 03 Sep 2014 16:25:21 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5407203B.3030709@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> Message-ID: <540724D1.6020506@redhat.com> On 09/03/2014 04:05 PM, Jan Cholasta wrote: > Dne 3.9.2014 v 12:37 David Kupka napsal(a): >> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>> 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. >>> >>> I didn't notice the patch is targeted for 4.0. Can you please provide >>> patches for both ipa-4-0 and ipa-4-1/master? >>> >> >> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >> ipa-4-0. > > There is a little bug in ipa-upgradeconfig in the 4.0 version of the > patch. This is wrong: > > for request in requests: > nss_dir, nickname, ca_name, pre_command, post_command, profile > = request > criteria = { > 'cert-database': nss_dir, > 'cert-nickname': nickname, > 'ca-name': ca_name, > 'template-profile': profile, > } > > It should be: > > for nss_dir, nickname, ca_name, pre_command, post_command in > requests: > criteria = { > 'cert-database': nss_dir, > 'cert-nickname': nickname, > 'ca-name': ca_name, > } > >> >>>>> >>>>> >>>>> 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 >>> >>> You removed the comments, but left the attributes there. You should >>> remove them as well, they are not necessary, as you set them all in >>> __init__(). >>> >> >> Removed. >> >>>>> >>>>> >>>>> 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(). > > You no longer check if the profile argument is set in modify() - either > re-introduce the check, or remove the default value of the argument to > make it mandatory. > >>>>> >>>>> >>>>> 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. >>> >>> OK, no need to include the TODO comment though. >>> >>>> >>>>> >>>>> I haven't done functional testing yet, expect more comments later. >>>>> >>>>> Honza >>>>> >>>> >>> >>> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >>> to request the host certificate, but since we plan on stopping doing >>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >>> have to do anything about it. >> >> Ok. I will leave it on you since you are owner of this ticket. >> >>> >>> >>> 13) You require dict for criteria in get_request_id, but you pass tuples >>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >>> makes them fail. >> >> Good point, fixed. > > I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it > should be fixed as well. > I need to check my patches more carefully, thank for the patience. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-6-ipa40-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 29435 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-6-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 32216 bytes Desc: not available URL: From nalin at redhat.com Wed Sep 3 14:33:11 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 3 Sep 2014 10:33:11 -0400 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <540724BC.3000003@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <20140903132915.GA21660@redhat.com> <54071AA6.5080507@redhat.com> <540724BC.3000003@redhat.com> Message-ID: <20140903143311.GB17260@redhat.com> On Wed, Sep 03, 2014 at 04:25:00PM +0200, Martin Kosek wrote: > On 09/03/2014 03:41 PM, Jan Cholasta wrote: > > "ldap_uri" is set only on servers, on clients you should use "server" (we > > should probably un-deprecate it). You could use "host" as a fallback, but it > > will only work on servers, as it points to the local host. IMO the right order > > is "server", then "ldap_uri", then maybe "host". > > BTW what happens when original server that the client enrolled with no longer > exist and was replaced by some other server with other FQDN. Will certmonger > fail in this case or will it fall back and do DNS SRV record to find > alternative server like "ipa" command does? It doesn't currently, but that certainly sounds like a reasonable thing to ask for in a trac ticket or bugzilla. Cheers, Nalin From mbasti at redhat.com Wed Sep 3 14:42:06 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 16:42:06 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <5405DF33.9050108@redhat.com> References: <53F4DA40.7060507@redhat.com> <5405DF33.9050108@redhat.com> Message-ID: <540728BE.6050707@redhat.com> On 02/09/14 17:16, Petr Spacek wrote: > On 20.8.2014 19:26, Martin Basti wrote: >> Part of DNSSEC >> Patches attached. > > NACK > > # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' > ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an > NS record (RFC 4529, section 4.6) > > RFC number is incorrect. IMHO it should also reference 'RFC 4035 > section 2.4'. > > Also, there is one hole: > Current code allows you to add DS RR to existing NS and then to remove > NS. > > Let me know if adding a check to -del is too hard, maybe we can live > without it... > dnsrecord-del validation added Updated patch attached Required in ipa 4.1 but this could be pushed to 4.0.x too -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0109.2-DNSSEC-fix-DS-record-validation.patch Type: text/x-patch Size: 7967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0110.2-Tests-DNS-dsrecord-validation.patch Type: text/x-patch Size: 3981 bytes Desc: not available URL: From jcholast at redhat.com Wed Sep 3 14:45:59 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 16:45:59 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <540724D1.6020506@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> Message-ID: <540729A7.3020203@redhat.com> Dne 3.9.2014 v 16:25 David Kupka napsal(a): > On 09/03/2014 04:05 PM, Jan Cholasta wrote: >> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>> 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. >>>> >>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>> patches for both ipa-4-0 and ipa-4-1/master? >>>> >>> >>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>> ipa-4-0. >> >> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >> patch. This is wrong: >> >> for request in requests: >> nss_dir, nickname, ca_name, pre_command, post_command, profile >> = request >> criteria = { >> 'cert-database': nss_dir, >> 'cert-nickname': nickname, >> 'ca-name': ca_name, >> 'template-profile': profile, >> } >> >> It should be: >> >> for nss_dir, nickname, ca_name, pre_command, post_command in >> requests: >> criteria = { >> 'cert-database': nss_dir, >> 'cert-nickname': nickname, >> 'ca-name': ca_name, >> } >> >>> >>>>>> >>>>>> >>>>>> 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 >>>> >>>> You removed the comments, but left the attributes there. You should >>>> remove them as well, they are not necessary, as you set them all in >>>> __init__(). >>>> >>> >>> Removed. >>> >>>>>> >>>>>> >>>>>> 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(). >> >> You no longer check if the profile argument is set in modify() - either >> re-introduce the check, or remove the default value of the argument to >> make it mandatory. >> >>>>>> >>>>>> >>>>>> 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. >>>> >>>> OK, no need to include the TODO comment though. >>>> >>>>> >>>>>> >>>>>> I haven't done functional testing yet, expect more comments later. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> >>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger API >>>> to request the host certificate, but since we plan on stopping doing >>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >>>> have to do anything about it. >>> >>> Ok. I will leave it on you since you are owner of this ticket. >>> >>>> >>>> >>>> 13) You require dict for criteria in get_request_id, but you pass >>>> tuples >>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, which >>>> makes them fail. >>> >>> Good point, fixed. >> >> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >> should be fixed as well. >> > I need to check my patches more carefully, thank for the patience. > And I need to do my reviews more carefully: in ca_renewal_master, the "cert-storage" criterium should in fact be "cert-database". ACK after you fix the above. -- Jan Cholasta From mkosek at redhat.com Wed Sep 3 14:46:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 16:46:13 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <20140903143311.GB17260@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <20140903132915.GA21660@redhat.com> <54071AA6.5080507@redhat.com> <540724BC.3000003@redhat.com> <20140903143311.GB17260@redhat.com> Message-ID: <540729B5.2070208@redhat.com> On 09/03/2014 04:33 PM, Nalin Dahyabhai wrote: > On Wed, Sep 03, 2014 at 04:25:00PM +0200, Martin Kosek wrote: >> On 09/03/2014 03:41 PM, Jan Cholasta wrote: >>> "ldap_uri" is set only on servers, on clients you should use "server" (we >>> should probably un-deprecate it). You could use "host" as a fallback, but it >>> will only work on servers, as it points to the local host. IMO the right order >>> is "server", then "ldap_uri", then maybe "host". >> >> BTW what happens when original server that the client enrolled with no longer >> exist and was replaced by some other server with other FQDN. Will certmonger >> fail in this case or will it fall back and do DNS SRV record to find >> alternative server like "ipa" command does? > > It doesn't currently, but that certainly sounds like a reasonable thing > to ask for in a trac ticket or bugzilla. > > Cheers, > > Nalin > Ok, bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1136900 Martin From simo at redhat.com Wed Sep 3 14:51:35 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Sep 2014 10:51:35 -0400 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <5406FB22.5090004@redhat.com> References: <5406FB22.5090004@redhat.com> Message-ID: <1409755895.8703.5.camel@willson.usersys.redhat.com> On Wed, 2014-09-03 at 13:27 +0200, Petr Viktorin wrote: > Hello, > This adds managed read permissions to the compat tree. > > For users it grants anonymous access; authenticated users can read > groups, hosts and netgroups. > > I'm unsure if this is what we want to do for groups, but "Read Group > Membership" is only granted to authenticated users by default, and the > compat tree exposes memberuid. The reason we restrict member is because it exposes also hbac, sudo and other sensible groupings. memberuid does not have those groups in, so I think it is safe (and necessary for legacy clients) to allow anonymous to read it, just like for users. Simo. > https://fedorahosted.org/freeipa/ticket/4521 > -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed Sep 3 14:51:39 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Sep 2014 16:51:39 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation In-Reply-To: <5406EDE0.3000806@redhat.com> References: <53F62A8D.30303@redhat.com> <5405E46F.6040703@redhat.com> <5406EDE0.3000806@redhat.com> Message-ID: <54072AFB.6060500@redhat.com> On 03/09/14 12:30, Martin Kosek wrote: > On 09/02/2014 05:38 PM, Petr Spacek wrote: >> On 21.8.2014 19:21, Martin Basti wrote: >>> 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. >> Functional ACK. It can be pushed if Python gurus don't see any problem. >> > I think the patches will need a rebase before push, I cannot apply them to my > tree. The Python part itself looked good to me. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased patch attached, due changes in freeipa-mbasti-0109, patches mbasti-0109.2, mbasti-0110.2 are required. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0111.2-DNS-fix-NS-record-coexistence-validator.patch Type: text/x-patch Size: 2571 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0112.2-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.2-Fix-DNS-record-rename-test.patch Type: text/x-patch Size: 3661 bytes Desc: not available URL: From tbabej at redhat.com Wed Sep 3 14:53:34 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Sep 2014 16:53:34 +0200 Subject: [Freeipa-devel] [PATCH 0242] Set the default attributes for RootDSE In-Reply-To: <53D64A26.70106@redhat.com> References: <53C4D49F.5010908@redhat.com> <53D64A26.70106@redhat.com> Message-ID: <54072B6E.3010107@redhat.com> On 07/28/2014 03:03 PM, Petr Viktorin wrote: > On 07/15/2014 09:13 AM, Tomas Babej wrote: >> Hi, >> >> With 389 DS 1.3.3 upwards we can leverage the >> nsslapd-return-default-opattr >> attribute to enumerate the list of attributes that should be returned >> even if not specified explicitly. Use the behaviour to get the same >> attributes >> returned from searches on rootDSE as in 1.3.1. >> >> https://fedorahosted.org/freeipa/ticket/4288 > > This fails with an older DS version. > > Running transaction (shutdown inhibited) > Updating : freeipa-python-4.0.0GITa2b91d7-0.fc20.x86_64 > 1/14 > Updating : freeipa-client-4.0.0GITa2b91d7-0.fc20.x86_64 > 2/14 > Could not load host key: /etc/ssh/ssh_host_dsa_key > Updating : freeipa-admintools-4.0.0GITa2b91d7-0.fc20.x86_64 > 3/14 > Updating : freeipa-server-4.0.0GITa2b91d7-0.fc20.x86_64 > 4/14 > Updating : freeipa-server-trust-ad-4.0.0GITa2b91d7-0.fc20.x86_64 > 5/14 > Updating : freeipa-tests-4.0.0GITa2b91d7-0.fc20.x86_64 > 6/14 > Updating : freeipa-debuginfo-4.0.0GITa2b91d7-0.fc20.x86_64 > 7/14 > Cleanup : freeipa-tests-4.0.0GIT06aa522-0.fc20.x86_64 > 8/14 > Cleanup : freeipa-debuginfo-4.0.0GIT06aa522-0.fc20.x86_64 > 9/14 > Cleanup : freeipa-server-trust-ad-4.0.0GIT06aa522-0.fc20.x86_64 > 10/14 > Cleanup : freeipa-server-4.0.0GIT06aa522-0.fc20.x86_64 > 11/14 > Cleanup : freeipa-admintools-4.0.0GIT06aa522-0.fc20.x86_64 > 12/14 > Cleanup : freeipa-client-4.0.0GIT06aa522-0.fc20.x86_64 > 13/14 > Cleanup : freeipa-python-4.0.0GIT06aa522-0.fc20.x86_64 > 14/14 > Upgrade failed with attribute "nsslapd-return-default-opattr" not allowed > IPA upgrade failed. > > You'll need to update the spec file too, at least. > Sure, spec file updated. We might want to wait with pushing this, since 1.3.3 is not available yet. -- 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-0242-2-Set-the-default-attributes-for-RootDSE.patch Type: text/x-patch Size: 2480 bytes Desc: not available URL: From pviktori at redhat.com Wed Sep 3 14:53:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 16:53:46 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to In-Reply-To: <54071D4A.9040509@redhat.com> References: <54071D4A.9040509@redhat.com> Message-ID: <54072B7A.5090304@redhat.com> On 09/03/2014 03:53 PM, Tomas Babej wrote: > Hi, > > Makes sure that any new sources added are not already present > in the entry. > > https://fedorahosted.org/freeipa/ticket/4508 It works fine, ACK. I do have some comments, but 4.0.x is a stabilization release, so they'd probably be better in a 4.1 patch: The way you first join default_value to make configured_services, and then repeatedly split it, looks quite wasteful. Wouldn't configured_services be better as a list? Also I wonder if configure_nsswitch_database needs those unused preserve/append options. Should I push now? -- Petr? From pviktori at redhat.com Wed Sep 3 14:55:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Sep 2014 16:55:48 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <1409755895.8703.5.camel@willson.usersys.redhat.com> References: <5406FB22.5090004@redhat.com> <1409755895.8703.5.camel@willson.usersys.redhat.com> Message-ID: <54072BF4.5060002@redhat.com> On 09/03/2014 04:51 PM, Simo Sorce wrote: > On Wed, 2014-09-03 at 13:27 +0200, Petr Viktorin wrote: >> Hello, >> This adds managed read permissions to the compat tree. >> >> For users it grants anonymous access; authenticated users can read >> groups, hosts and netgroups. >> >> I'm unsure if this is what we want to do for groups, but "Read Group >> Membership" is only granted to authenticated users by default, and the >> compat tree exposes memberuid. > > The reason we restrict member is because it exposes also hbac, sudo and > other sensible groupings. memberuid does not have those groups in, so I > think it is safe (and necessary for legacy clients) to allow anonymous > to read it, just like for users. > > Simo. In that case, I'd also add memberuid to 'Read Groups', to make it clear what our default policy is. -- Petr? From jcholast at redhat.com Wed Sep 3 15:09:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 17:09:33 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <53FDC788.2060603@redhat.com> References: <53FDC788.2060603@redhat.com> Message-ID: <54072F2D.4020502@redhat.com> Hi, Dne 27.8.2014 v 13:56 David Kupka napsal(a): > 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 1) I think you can log realm in search() as part of the "Starting IPA discovery ..." message instead of a separate message. 2) Also, no need to log the realm twice in search(). 3) It looks like you forgot to un-indent some code in ipadnssearchkrbkdc(). Honza -- Jan Cholasta From mkosek at redhat.com Wed Sep 3 15:25:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 17:25:22 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54071477.1020303@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> Message-ID: <540732E2.2030207@redhat.com> On 09/03/2014 03:15 PM, Petr Viktorin wrote: > On 09/03/2014 02:27 PM, Petr Viktorin wrote: >> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>> Hello, >>> This adds managed read permissions to the compat tree. >>> >>> For users it grants anonymous access; authenticated users can read >>> groups, hosts and netgroups. >>> >>> I'm unsure if this is what we want to do for groups, but "Read Group >>> Membership" is only granted to authenticated users by default, and the >>> compat tree exposes memberuid. >>> >>> https://fedorahosted.org/freeipa/ticket/4521 >> >> Self-NACK, there's a typo (though I could swear I tested this :/) >> >> > > Fixed patch attached. > I tested and it looks and works OK, ACK from me. We can wait till tomorrow to see if there are no reservations from Alexander or Rob. Martin From jcholast at redhat.com Wed Sep 3 16:35:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Sep 2014 18:35:23 +0200 Subject: [Freeipa-devel] [PATCH] 318 Backup CS.cfg before modifying it Message-ID: <5407434B.5030104@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-318-Backup-CS.cfg-before-modifying-it.patch Type: text/x-patch Size: 3036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-318-Backup-CS.cfg-before-modifying-it-ipa-4-0.patch Type: text/x-patch Size: 3236 bytes Desc: not available URL: From rcritten at redhat.com Wed Sep 3 19:23:47 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 15:23:47 -0400 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert Message-ID: <54076AC3.5040503@redhat.com> No longer request and install a cert for the IPA client machine. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1109-client-cert.patch Type: text/x-patch Size: 4204 bytes Desc: not available URL: From edewata at redhat.com Wed Sep 3 19:44:20 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 03 Sep 2014 14:44:20 -0500 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <53F6FFE3.3070302@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> <53F6FFE3.3070302@redhat.com> Message-ID: <54076F94.4030100@redhat.com> On 8/22/2014 3:31 AM, Petr Vobornik wrote: > 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 ACK. >>> [PATCH] 724 webui: display fields based on otp token type >>> >>> - in adder dialog > > is it an ACK? Sorry, missed this one. 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. > > 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. Can the users tell which type of token they have based on the existing fields? There is a model field which is populated with the type (e.g. totp or hotp). But since the value can be changed to anything it's not a reliable way to determine the type. I don't think it's very user-friendly to ask the user to see whether the type-specific fields are shown in order to determine the type. I can't say there's a big benefit by adding the field, but maybe some admins might find it useful, and it can be used to sort/filter out search results. > 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. Yes, if people can add an attribute usually they will expect to be able to see what they added. >> 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? On a read-only page I think it's OK to hide empty fields. But on edit page I don't think we should do that by default. Does "empty" mean "unset", or "blank" like empty string/array? Does "unset" always mean "non-editable and invisible" and "blank" always mean "editable and visible but it's just empty"? If this definition isn't strictly followed there could be an editable field that accidentally gets hidden because it's empty. Generally if a field is supposed to be hidden in an edit page because of other condition (e.g. token type), not because of the value, the code should also use that condition instead of relying on the value being unset. In this particular case, instead of: if (field !== undefined) { // display field } we probably should do: var type = ... if (type == 'hotp') { // display hotp fields } else { // totp // display totp fields } For now the type can be determined by the availability of certain type-specific fields, but in the future we may add the type itself. >> 3. The "Clock offset" field doesn't have a unit. > > Fixed in patch 720-1, patch 729 was rebased ACK. >> 4. If no "Owner" is specified when adding a token, it will default to >> admin. Is this the intended behavior? > > Sadly yes. Maybe the adder dialog should show admin (or the current user?) as the default owner instead of empty? -- Endi S. Dewata From edewata at redhat.com Wed Sep 3 22:53:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 03 Sep 2014 17:53:19 -0500 Subject: [Freeipa-devel] [PATCH] 748 webui: extract complex pkey on Add and Edit In-Reply-To: <5405DF02.7000209@redhat.com> References: <5405DF02.7000209@redhat.com> Message-ID: <54079BDF.5090605@redhat.com> On 9/2/2014 10:15 AM, Petr Vobornik wrote: > DNS zone 'Add and Edit' failed because of new DNS name encoding. > > This patch makes sure that keys are extracted properly. > > https://fedorahosted.org/freeipa/ticket/4520 ACK. -- Endi S. Dewata From edewata at redhat.com Wed Sep 3 23:25:59 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 03 Sep 2014 18:25:59 -0500 Subject: [Freeipa-devel] [PATCH] 742 webui: adjust behavior of bounce url In-Reply-To: <53F61909.4070402@redhat.com> References: <53F61909.4070402@redhat.com> Message-ID: <5407A387.9070104@redhat.com> On 8/21/2014 11:06 AM, Petr Vobornik wrote: > 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 ACK. Just one thing, when the delay=0 and the direction happens quickly, the users might see the confirmation and the redirection messages displayed briefly on the screen but they cannot read it because it's too quick, which might leave them wondering what it was. I think delay=0 is a special case where we want a seamless integration with 3rd party application. If the password reset is completed successfully, it should just display the next page in the 3rd party application. Users shouldn't see a 'redirection' message. To them it's all one application. -- Endi S. Dewata From edewata at redhat.com Thu Sep 4 02:09:07 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 03 Sep 2014 21:09:07 -0500 Subject: [Freeipa-devel] [PATCH] 743 webui: do not show login error when switching back from otp sync screen In-Reply-To: <53F72EDE.3070307@redhat.com> References: <53F72EDE.3070307@redhat.com> Message-ID: <5407C9C3.9000409@redhat.com> On 8/22/2014 6:51 AM, Petr Vobornik wrote: > 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. ACK. -- Endi S. Dewata From pspacek at redhat.com Thu Sep 4 09:46:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 11:46:47 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <540728BE.6050707@redhat.com> References: <53F4DA40.7060507@redhat.com> <5405DF33.9050108@redhat.com> <540728BE.6050707@redhat.com> Message-ID: <54083507.7040505@redhat.com> On 3.9.2014 16:42, Martin Basti wrote: > On 02/09/14 17:16, Petr Spacek wrote: >> On 20.8.2014 19:26, Martin Basti wrote: >>> Part of DNSSEC >>> Patches attached. >> >> NACK >> >> # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' >> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS >> record (RFC 4529, section 4.6) >> >> RFC number is incorrect. IMHO it should also reference 'RFC 4035 section 2.4'. >> >> Also, there is one hole: >> Current code allows you to add DS RR to existing NS and then to remove NS. >> >> Let me know if adding a check to -del is too hard, maybe we can live without >> it... >> > dnsrecord-del validation added > > Updated patch attached > > Required in ipa 4.1 but this could be pushed to 4.0.x too It almost works ... almost. I'm not sure if the problem is in your patch or in existing code: [root at vm-035 git]# ipa dnsrecord-add ipa.example ds --ds-rec='1 2 3 4' Record name: ds DS record: 1 2 3 4 NS record: vm-035.idm.lab.eng.brq.redhat.com. [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS record (RFC 4592 section 4.6, RFC 4035 section 2.4) [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ds-rec= Record name: ds NS record: vm-035.idm.lab.eng.brq.redhat.com. [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= ipa: ERROR: an internal error has occurred # tail /var/log/httpd/error_log ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): output['value']: need ; got : [] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 348, in wsgi_execute result = self.Command[name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, in __call__ self.validate_output(ret, options['version']) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, in validate_output o.validate(self, value, version) File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, in validate types[0], type(value), value)) TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): output['value']: need ; got : [] ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(, , nsrecord=None, rights=False, structured=False, all=False, raw=False, version=u'2.102'): TypeError -- Petr^2 Spacek From pviktori at redhat.com Thu Sep 4 10:15:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 04 Sep 2014 12:15:18 +0200 Subject: [Freeipa-devel] [PATCH] 316 Normalize external CA cert before passing it to pkispawn In-Reply-To: <54047FE7.6030004@redhat.com> References: <54047FE7.6030004@redhat.com> Message-ID: <54083BB6.9070005@redhat.com> On 09/01/2014 04:17 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza ACK, pushed to: master: 93346b1cf9ffae5afdd9bb71684f22922dbc8ea4 ipa-4-1: 451c2e2bc4da52900dbf6cd67ea62ccd70e8e421 ipa-4-0: b50528a7d92d811cfcc00bf0ecdecbab13fec5b1 -- Petr? From dkupka at redhat.com Thu Sep 4 10:31:50 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 04 Sep 2014 12:31:50 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <540729A7.3020203@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> Message-ID: <54083F96.50509@redhat.com> On 09/03/2014 04:45 PM, Jan Cholasta wrote: > Dne 3.9.2014 v 16:25 David Kupka napsal(a): >> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>> 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. >>>>> >>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>> >>>> >>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>> ipa-4-0. >>> >>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>> patch. This is wrong: >>> >>> for request in requests: >>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>> = request >>> criteria = { >>> 'cert-database': nss_dir, >>> 'cert-nickname': nickname, >>> 'ca-name': ca_name, >>> 'template-profile': profile, >>> } >>> >>> It should be: >>> >>> for nss_dir, nickname, ca_name, pre_command, post_command in >>> requests: >>> criteria = { >>> 'cert-database': nss_dir, >>> 'cert-nickname': nickname, >>> 'ca-name': ca_name, >>> } >>> >>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>> >>>>> You removed the comments, but left the attributes there. You should >>>>> remove them as well, they are not necessary, as you set them all in >>>>> __init__(). >>>>> >>>> >>>> Removed. >>>> >>>>>>> >>>>>>> >>>>>>> 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(). >>> >>> You no longer check if the profile argument is set in modify() - either >>> re-introduce the check, or remove the default value of the argument to >>> make it mandatory. >>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>> >>>>> OK, no need to include the TODO comment though. >>>>> >>>>>> >>>>>>> >>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>> >>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>> API >>>>> to request the host certificate, but since we plan on stopping doing >>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you don't >>>>> have to do anything about it. >>>> >>>> Ok. I will leave it on you since you are owner of this ticket. >>>> >>>>> >>>>> >>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>> tuples >>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>> which >>>>> makes them fail. >>>> >>>> Good point, fixed. >>> >>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>> should be fixed as well. >>> >> I need to check my patches more carefully, thank for the patience. >> > > And I need to do my reviews more carefully: in ca_renewal_master, the > "cert-storage" criterium should in fact be "cert-database". > > ACK after you fix the above. > Fixed together with other issues discussed on IRC. Please review it one more time. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-8-ipa40-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 32526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-8-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 35087 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 4 10:32:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Sep 2014 12:32:38 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to In-Reply-To: <54072B7A.5090304@redhat.com> References: <54071D4A.9040509@redhat.com> <54072B7A.5090304@redhat.com> Message-ID: <54083FC6.5050001@redhat.com> On 09/03/2014 04:53 PM, Petr Viktorin wrote: > On 09/03/2014 03:53 PM, Tomas Babej wrote: >> Hi, >> >> Makes sure that any new sources added are not already present >> in the entry. >> >> https://fedorahosted.org/freeipa/ticket/4508 > > It works fine, ACK. > > I do have some comments, but 4.0.x is a stabilization release, so > they'd probably be better in a 4.1 patch: > > The way you first join default_value to make configured_services, and > then repeatedly split it, looks quite wasteful. Wouldn't > configured_services be better as a list? Yes, the string handling was kind of unfortunate. I fixed it in this iteration of the patch. > Also I wonder if configure_nsswitch_database needs those unused > preserve/append options. Although not used yet, I think it's handy to have them there, they do not complicate the code much. > > Should I push now? > -- 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-0260-2-ipa-client-install-Do-not-add-already-configured-sou.patch Type: text/x-patch Size: 2886 bytes Desc: not available URL: From dkupka at redhat.com Thu Sep 4 10:42:03 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 04 Sep 2014 12:42:03 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <54072F2D.4020502@redhat.com> References: <53FDC788.2060603@redhat.com> <54072F2D.4020502@redhat.com> Message-ID: <540841FB.5090301@redhat.com> On 09/03/2014 05:09 PM, Jan Cholasta wrote: > Hi, > > Dne 27.8.2014 v 13:56 David Kupka napsal(a): >> 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 > > 1) I think you can log realm in search() as part of the "Starting IPA > discovery ..." message instead of a separate message. > > > 2) Also, no need to log the realm twice in search(). I forget to remove some redundant debug prints. > > > 3) It looks like you forgot to un-indent some code in ipadnssearchkrbkdc(). > Fixed, thanks. > > Honza > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0011-2-Allow-user-to-force-Kerberos-realm-during-installati.patch Type: text/x-patch Size: 4511 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 4 10:45:34 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Sep 2014 12:45:34 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to In-Reply-To: <54083FC6.5050001@redhat.com> References: <54071D4A.9040509@redhat.com> <54072B7A.5090304@redhat.com> <54083FC6.5050001@redhat.com> Message-ID: <540842CE.6050809@redhat.com> Also I made explicit conversion to list for default values upon Petr's request. On 09/04/2014 12:32 PM, Tomas Babej wrote: > On 09/03/2014 04:53 PM, Petr Viktorin wrote: >> On 09/03/2014 03:53 PM, Tomas Babej wrote: >>> Hi, >>> >>> Makes sure that any new sources added are not already present >>> in the entry. >>> >>> https://fedorahosted.org/freeipa/ticket/4508 >> It works fine, ACK. >> >> I do have some comments, but 4.0.x is a stabilization release, so >> they'd probably be better in a 4.1 patch: >> >> The way you first join default_value to make configured_services, and >> then repeatedly split it, looks quite wasteful. Wouldn't >> configured_services be better as a list? > Yes, the string handling was kind of unfortunate. I fixed it in this > iteration of the patch. > >> Also I wonder if configure_nsswitch_database needs those unused >> preserve/append options. > Although not used yet, I think it's handy to have them there, they do > not complicate the code much. > >> Should I push now? >> > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0260-3-ipa-client-install-Do-not-add-already-configured-sou.patch Type: text/x-patch Size: 2892 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 4 11:00:54 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Sep 2014 13:00:54 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to In-Reply-To: <540842CE.6050809@redhat.com> References: <54071D4A.9040509@redhat.com> <54072B7A.5090304@redhat.com> <54083FC6.5050001@redhat.com> <540842CE.6050809@redhat.com> Message-ID: <54084666.6050203@redhat.com> Minor fix regarding default_value being None converted to list. On 09/04/2014 12:45 PM, Tomas Babej wrote: > Also I made explicit conversion to list for default values upon Petr's > request. > > On 09/04/2014 12:32 PM, Tomas Babej wrote: >> On 09/03/2014 04:53 PM, Petr Viktorin wrote: >>> On 09/03/2014 03:53 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Makes sure that any new sources added are not already present >>>> in the entry. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4508 >>> It works fine, ACK. >>> >>> I do have some comments, but 4.0.x is a stabilization release, so >>> they'd probably be better in a 4.1 patch: >>> >>> The way you first join default_value to make configured_services, and >>> then repeatedly split it, looks quite wasteful. Wouldn't >>> configured_services be better as a list? >> Yes, the string handling was kind of unfortunate. I fixed it in this >> iteration of the patch. >> >>> Also I wonder if configure_nsswitch_database needs those unused >>> preserve/append options. >> Although not used yet, I think it's handy to have them there, they do >> not complicate the code much. >> >>> Should I push now? >>> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0260-4-ipa-client-install-Do-not-add-already-configured-sou.patch Type: text/x-patch Size: 3311 bytes Desc: not available URL: From mbasti at redhat.com Thu Sep 4 11:02:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 13:02:48 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <54083507.7040505@redhat.com> References: <53F4DA40.7060507@redhat.com> <5405DF33.9050108@redhat.com> <540728BE.6050707@redhat.com> <54083507.7040505@redhat.com> Message-ID: <540846D8.5030805@redhat.com> On 04/09/14 11:46, Petr Spacek wrote: > On 3.9.2014 16:42, Martin Basti wrote: >> On 02/09/14 17:16, Petr Spacek wrote: >>> On 20.8.2014 19:26, Martin Basti wrote: >>>> Part of DNSSEC >>>> Patches attached. >>> >>> NACK >>> >>> # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' >>> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with >>> an NS >>> record (RFC 4529, section 4.6) >>> >>> RFC number is incorrect. IMHO it should also reference 'RFC 4035 >>> section 2.4'. >>> >>> Also, there is one hole: >>> Current code allows you to add DS RR to existing NS and then to >>> remove NS. >>> >>> Let me know if adding a check to -del is too hard, maybe we can live >>> without >>> it... >>> >> dnsrecord-del validation added >> >> Updated patch attached >> >> Required in ipa 4.1 but this could be pushed to 4.0.x too > > It almost works ... almost. I'm not sure if the problem is in your > patch or in existing code: > > [root at vm-035 git]# ipa dnsrecord-add ipa.example ds --ds-rec='1 2 3 4' > Record name: ds > DS record: 1 2 3 4 > NS record: vm-035.idm.lab.eng.brq.redhat.com. > > [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= > ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an > NS record (RFC 4592 section 4.6, RFC 4035 section 2.4) > > [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ds-rec= > Record name: ds > NS record: vm-035.idm.lab.eng.brq.redhat.com. > > [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= > ipa: ERROR: an internal error has occurred > > # tail /var/log/httpd/error_log > > ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => > PrimaryKey.validate(): > output['value']: need ; got 'list'>: [] > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 348, in wsgi_execute > result = self.Command[name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 451, in __call__ > self.validate_output(ret, options['version']) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 944, in validate_output > o.validate(self, value, version) > File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, > in validate > types[0], type(value), value)) > TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): > output['value']: need ; got 'list'>: [] > ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod( name ipa.example.>, , nsrecord=None, rights=False, > structured=False, all=False, raw=False, version=u'2.102'): TypeError > This bug is not related with the patches. Error is raised when you try to delete the last record in RRset using dnsrecord-mod --any-rec="" -- Martin Basti From pspacek at redhat.com Thu Sep 4 11:11:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 13:11:13 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <540846D8.5030805@redhat.com> References: <53F4DA40.7060507@redhat.com> <5405DF33.9050108@redhat.com> <540728BE.6050707@redhat.com> <54083507.7040505@redhat.com> <540846D8.5030805@redhat.com> Message-ID: <540848D1.6090601@redhat.com> On 4.9.2014 13:02, Martin Basti wrote: > On 04/09/14 11:46, Petr Spacek wrote: >> On 3.9.2014 16:42, Martin Basti wrote: >>> On 02/09/14 17:16, Petr Spacek wrote: >>>> On 20.8.2014 19:26, Martin Basti wrote: >>>>> Part of DNSSEC >>>>> Patches attached. >>>> >>>> NACK >>>> >>>> # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' >>>> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS >>>> record (RFC 4529, section 4.6) >>>> >>>> RFC number is incorrect. IMHO it should also reference 'RFC 4035 section >>>> 2.4'. >>>> >>>> Also, there is one hole: >>>> Current code allows you to add DS RR to existing NS and then to remove NS. >>>> >>>> Let me know if adding a check to -del is too hard, maybe we can live without >>>> it... >>>> >>> dnsrecord-del validation added >>> >>> Updated patch attached >>> >>> Required in ipa 4.1 but this could be pushed to 4.0.x too >> >> It almost works ... almost. I'm not sure if the problem is in your patch or >> in existing code: >> >> [root at vm-035 git]# ipa dnsrecord-add ipa.example ds --ds-rec='1 2 3 4' >> Record name: ds >> DS record: 1 2 3 4 >> NS record: vm-035.idm.lab.eng.brq.redhat.com. >> >> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS >> record (RFC 4592 section 4.6, RFC 4035 section 2.4) >> >> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ds-rec= >> Record name: ds >> NS record: vm-035.idm.lab.eng.brq.redhat.com. >> >> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >> ipa: ERROR: an internal error has occurred >> >> # tail /var/log/httpd/error_log >> >> ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => >> PrimaryKey.validate(): >> output['value']: need ; got > 'list'>: [] >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 348, >> in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, in >> __call__ >> self.validate_output(ret, options['version']) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, in >> validate_output >> o.validate(self, value, version) >> File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, in >> validate >> types[0], type(value), value)) >> TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): >> output['value']: need ; got > 'list'>: [] >> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(> ipa.example.>, , nsrecord=None, rights=False, structured=False, >> all=False, raw=False, version=u'2.102'): TypeError >> > This bug is not related with the patches. > Error is raised when you try to delete the last record in RRset using > dnsrecord-mod --any-rec="" Okay, functional ACK. Please send a separate patch for this problem or at least open a ticket and describe what is wrong with it. It can be pushed if Python gurus are okay with the code. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Thu Sep 4 11:12:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 13:12:21 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation In-Reply-To: <54072AFB.6060500@redhat.com> References: <53F62A8D.30303@redhat.com> <5405E46F.6040703@redhat.com> <5406EDE0.3000806@redhat.com> <54072AFB.6060500@redhat.com> Message-ID: <54084915.9090103@redhat.com> On 3.9.2014 16:51, Martin Basti wrote: > On 03/09/14 12:30, Martin Kosek wrote: >> On 09/02/2014 05:38 PM, Petr Spacek wrote: >>> On 21.8.2014 19:21, Martin Basti wrote: >>>> 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. >>> Functional ACK. It can be pushed if Python gurus don't see any problem. >>> >> I think the patches will need a rebase before push, I cannot apply them to my >> tree. The Python part itself looked good to me. >> >> Martin >> > Rebased patch attached, due changes in freeipa-mbasti-0109, > patches mbasti-0109.2, mbasti-0110.2 are required. Rebased versions work for me. Functional ACK. -- Petr^2 Spacek From jcholast at redhat.com Thu Sep 4 11:19:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 13:19:04 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54083F96.50509@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> <54083F96.50509@redhat.com> Message-ID: <54084AA8.3020103@redhat.com> Dne 4.9.2014 v 12:31 David Kupka napsal(a): > On 09/03/2014 04:45 PM, Jan Cholasta wrote: >> Dne 3.9.2014 v 16:25 David Kupka napsal(a): >>> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>>> 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. >>>>>> >>>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>>> >>>>> >>>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>>> ipa-4-0. >>>> >>>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>>> patch. This is wrong: >>>> >>>> for request in requests: >>>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>>> = request >>>> criteria = { >>>> 'cert-database': nss_dir, >>>> 'cert-nickname': nickname, >>>> 'ca-name': ca_name, >>>> 'template-profile': profile, >>>> } >>>> >>>> It should be: >>>> >>>> for nss_dir, nickname, ca_name, pre_command, post_command in >>>> requests: >>>> criteria = { >>>> 'cert-database': nss_dir, >>>> 'cert-nickname': nickname, >>>> 'ca-name': ca_name, >>>> } >>>> >>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> You removed the comments, but left the attributes there. You should >>>>>> remove them as well, they are not necessary, as you set them all in >>>>>> __init__(). >>>>>> >>>>> >>>>> Removed. >>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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(). >>>> >>>> You no longer check if the profile argument is set in modify() - either >>>> re-introduce the check, or remove the default value of the argument to >>>> make it mandatory. >>>> >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>> >>>>>> OK, no need to include the TODO comment though. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>> >>>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>>> API >>>>>> to request the host certificate, but since we plan on stopping doing >>>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you >>>>>> don't >>>>>> have to do anything about it. >>>>> >>>>> Ok. I will leave it on you since you are owner of this ticket. >>>>> >>>>>> >>>>>> >>>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>>> tuples >>>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>>> which >>>>>> makes them fail. >>>>> >>>>> Good point, fixed. >>>> >>>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>>> should be fixed as well. >>>> >>> I need to check my patches more carefully, thank for the patience. >>> >> >> And I need to do my reviews more carefully: in ca_renewal_master, the >> "cert-storage" criterium should in fact be "cert-database". >> >> ACK after you fix the above. >> > Fixed together with other issues discussed on IRC. Please review it one > more time. Thanks, ACK. -- Jan Cholasta From jcholast at redhat.com Thu Sep 4 11:22:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 13:22:12 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <540841FB.5090301@redhat.com> References: <53FDC788.2060603@redhat.com> <54072F2D.4020502@redhat.com> <540841FB.5090301@redhat.com> Message-ID: <54084B64.4090007@redhat.com> Dne 4.9.2014 v 12:42 David Kupka napsal(a): > On 09/03/2014 05:09 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 27.8.2014 v 13:56 David Kupka napsal(a): >>> 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 >> >> 1) I think you can log realm in search() as part of the "Starting IPA >> discovery ..." message instead of a separate message. >> >> >> 2) Also, no need to log the realm twice in search(). > I forget to remove some redundant debug prints. >> >> >> 3) It looks like you forgot to un-indent some code in >> ipadnssearchkrbkdc(). >> > Fixed, thanks. What I meant is that this: def ipadnssearchkrbkdc(self, domain=None): kdc = None if not domain: domain = self.domain kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, break_on_first=False) if kdc: kdc = ','.join(kdc) else: root_logger.debug("SRV record for KDC not found! Domain: %s" % domain) kdc = None return kdc should be this: def ipadnssearchkrbkdc(self, domain=None): if not domain: domain = self.domain kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, break_on_first=False) if kdc: kdc = ','.join(kdc) else: root_logger.debug("SRV record for KDC not found! Domain: %s" % domain) kdc = None return kdc Isn't that right? >> >> Honza >> > -- Jan Cholasta From pviktori at redhat.com Thu Sep 4 11:40:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 04 Sep 2014 13:40:05 +0200 Subject: [Freeipa-devel] [PATCH 0260] ipa-client-install: Do not add already configured sources to In-Reply-To: <54084666.6050203@redhat.com> References: <54071D4A.9040509@redhat.com> <54072B7A.5090304@redhat.com> <54083FC6.5050001@redhat.com> <540842CE.6050809@redhat.com> <54084666.6050203@redhat.com> Message-ID: <54084F95.5090500@redhat.com> On 09/04/2014 01:00 PM, Tomas Babej wrote: > Minor fix regarding default_value being None converted to list. > > On 09/04/2014 12:45 PM, Tomas Babej wrote: >> Also I made explicit conversion to list for default values upon Petr's >> request. >> ACK, pushed to: master: fd26560a164e757970584009d54f81c678a7056c ipa-4-1: 5aead1ff6fd6709a267fc91cb2e437d504ad2bac ipa-4-0: 6bb6671cb5ea4c71581675330b398ab64c9dffd3 -- Petr? From mkosek at redhat.com Thu Sep 4 11:40:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 13:40:09 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54084AA8.3020103@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> <54083F96.50509@redhat.com> <54084AA8.3020103@redhat.com> Message-ID: <54084F99.3060409@redhat.com> On 09/04/2014 01:19 PM, Jan Cholasta wrote: > Dne 4.9.2014 v 12:31 David Kupka napsal(a): >> On 09/03/2014 04:45 PM, Jan Cholasta wrote: >>> Dne 3.9.2014 v 16:25 David Kupka napsal(a): >>>> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>>>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>>>> 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. >>>>>>> >>>>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>>>> >>>>>> >>>>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>>>> ipa-4-0. >>>>> >>>>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>>>> patch. This is wrong: >>>>> >>>>> for request in requests: >>>>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>>>> = request >>>>> criteria = { >>>>> 'cert-database': nss_dir, >>>>> 'cert-nickname': nickname, >>>>> 'ca-name': ca_name, >>>>> 'template-profile': profile, >>>>> } >>>>> >>>>> It should be: >>>>> >>>>> for nss_dir, nickname, ca_name, pre_command, post_command in >>>>> requests: >>>>> criteria = { >>>>> 'cert-database': nss_dir, >>>>> 'cert-nickname': nickname, >>>>> 'ca-name': ca_name, >>>>> } >>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>> >>>>>>> You removed the comments, but left the attributes there. You should >>>>>>> remove them as well, they are not necessary, as you set them all in >>>>>>> __init__(). >>>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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(). >>>>> >>>>> You no longer check if the profile argument is set in modify() - either >>>>> re-introduce the check, or remove the default value of the argument to >>>>> make it mandatory. >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>> >>>>>>> OK, no need to include the TODO comment though. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>>>> API >>>>>>> to request the host certificate, but since we plan on stopping doing >>>>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you >>>>>>> don't >>>>>>> have to do anything about it. >>>>>> >>>>>> Ok. I will leave it on you since you are owner of this ticket. >>>>>> >>>>>>> >>>>>>> >>>>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>>>> tuples >>>>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>>>> which >>>>>>> makes them fail. >>>>>> >>>>>> Good point, fixed. >>>>> >>>>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>>>> should be fixed as well. >>>>> >>>> I need to check my patches more carefully, thank for the patience. >>>> >>> >>> And I need to do my reviews more carefully: in ca_renewal_master, the >>> "cert-storage" criterium should in fact be "cert-database". >>> >>> ACK after you fix the above. >>> >> Fixed together with other issues discussed on IRC. Please review it one >> more time. > > Thanks, ACK. > Thanks! But as I just found out, neither patch applies to ipa-4-1 branch. And as the merge is not straightforward, I would leave the backport rather either to Jan or David. Martin From abokovoy at redhat.com Thu Sep 4 12:40:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Sep 2014 15:40:23 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <540732E2.2030207@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> Message-ID: <20140904124023.GO3593@redhat.com> On Wed, 03 Sep 2014, Martin Kosek wrote: >On 09/03/2014 03:15 PM, Petr Viktorin wrote: >> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>> Hello, >>>> This adds managed read permissions to the compat tree. >>>> >>>> For users it grants anonymous access; authenticated users can read >>>> groups, hosts and netgroups. >>>> >>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>> Membership" is only granted to authenticated users by default, and the >>>> compat tree exposes memberuid. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4521 >>> >>> Self-NACK, there's a typo (though I could swear I tested this :/) >>> >>> >> >> Fixed patch attached. >> > >I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >see if there are no reservations from Alexander or Rob. I think we need a bit more fixes. Here is ACL log for an anonymous request: [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname="permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname="permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname="permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname= "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname= "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci matched the subject by aci(27): aciname="permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat Tree", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage any entry", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat Tree", acidn="dc=ipacloud,dc=test" [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to anonymous: cached allow by aci(38) [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: cached allow by aci(38) createTimestamp is operational attribute and is synthesized by slapi-nis, there is no problem allowing access to it. I think we can allow following operational attributes: createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, entryDN, hasSubordinates, numSubordinates Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't run ipa-adtrust-install on this machine yet. The same set should be allowed for primary tree. -- / Alexander Bokovoy From pspacek at redhat.com Thu Sep 4 12:43:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 14:43:39 +0200 Subject: [Freeipa-devel] [PATCH 0280] Use "master" subdirectory for temporary files related to zones Message-ID: <54085E7B.9040903@redhat.com> Hello, Use "master" subdirectory for temporary files related to zones. This allows us to separate zone and non-zone metadata and also to separate master and (hypothetical) slave zones. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0280-Use-master-subdirectory-for-temporary-files-related-.patch Type: text/x-patch Size: 1021 bytes Desc: not available URL: From jcholast at redhat.com Thu Sep 4 13:09:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 15:09:19 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54084F99.3060409@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> <54083F96.50509@redhat.com> <54084AA8.3020103@redhat.com> <54084F99.3060409@redhat.com> Message-ID: <5408647F.2040705@redhat.com> Dne 4.9.2014 v 13:40 Martin Kosek napsal(a): > On 09/04/2014 01:19 PM, Jan Cholasta wrote: >> Dne 4.9.2014 v 12:31 David Kupka napsal(a): >>> On 09/03/2014 04:45 PM, Jan Cholasta wrote: >>>> Dne 3.9.2014 v 16:25 David Kupka napsal(a): >>>>> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>>>>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>>>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>>>>> 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. >>>>>>>> >>>>>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>>>>> >>>>>>> >>>>>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>>>>> ipa-4-0. >>>>>> >>>>>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>>>>> patch. This is wrong: >>>>>> >>>>>> for request in requests: >>>>>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>>>>> = request >>>>>> criteria = { >>>>>> 'cert-database': nss_dir, >>>>>> 'cert-nickname': nickname, >>>>>> 'ca-name': ca_name, >>>>>> 'template-profile': profile, >>>>>> } >>>>>> >>>>>> It should be: >>>>>> >>>>>> for nss_dir, nickname, ca_name, pre_command, post_command in >>>>>> requests: >>>>>> criteria = { >>>>>> 'cert-database': nss_dir, >>>>>> 'cert-nickname': nickname, >>>>>> 'ca-name': ca_name, >>>>>> } >>>>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>> >>>>>>>> You removed the comments, but left the attributes there. You should >>>>>>>> remove them as well, they are not necessary, as you set them all in >>>>>>>> __init__(). >>>>>>>> >>>>>>> >>>>>>> Removed. >>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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(). >>>>>> >>>>>> You no longer check if the profile argument is set in modify() - either >>>>>> re-introduce the check, or remove the default value of the argument to >>>>>> make it mandatory. >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>> >>>>>>>> OK, no need to include the TODO comment though. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>>>>> API >>>>>>>> to request the host certificate, but since we plan on stopping doing >>>>>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you >>>>>>>> don't >>>>>>>> have to do anything about it. >>>>>>> >>>>>>> Ok. I will leave it on you since you are owner of this ticket. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>>>>> tuples >>>>>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>>>>> which >>>>>>>> makes them fail. >>>>>>> >>>>>>> Good point, fixed. >>>>>> >>>>>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>>>>> should be fixed as well. >>>>>> >>>>> I need to check my patches more carefully, thank for the patience. >>>>> >>>> >>>> And I need to do my reviews more carefully: in ca_renewal_master, the >>>> "cert-storage" criterium should in fact be "cert-database". >>>> >>>> ACK after you fix the above. >>>> >>> Fixed together with other issues discussed on IRC. Please review it one >>> more time. >> >> Thanks, ACK. >> > > Thanks! But as I just found out, neither patch applies to ipa-4-1 branch. And > as the merge is not straightforward, I would leave the backport rather either > to Jan or David. > > Martin > Here. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0008-8-ipa41-Use-certmonger-D-Bus-API-instead-of-messing-with-its.patch Type: text/x-patch Size: 34160 bytes Desc: not available URL: From pspacek at redhat.com Thu Sep 4 13:46:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 15:46:39 +0200 Subject: [Freeipa-devel] [PATCH 0281] Escape directory names generated from zone names Message-ID: <54086D3F.5070008@redhat.com> Hello, Escape directory names generated from zone names. Previously root zone '.' and zone names with characters like '/' caused scattering of temporary files all over dyndb-ldap working directory. https://fedorahosted.org/bind-dyndb-ldap/ticket/122 -- Petr^2 Spacek From mkosek at redhat.com Thu Sep 4 13:55:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 15:55:14 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140904124023.GO3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> Message-ID: <54086F42.8070102@redhat.com> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: > On Wed, 03 Sep 2014, Martin Kosek wrote: >> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> This adds managed read permissions to the compat tree. >>>>> >>>>> For users it grants anonymous access; authenticated users can read >>>>> groups, hosts and netgroups. >>>>> >>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>> Membership" is only granted to authenticated users by default, and the >>>>> compat tree exposes memberuid. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>> >>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>> >>>> >>> >>> Fixed patch attached. >>> >> >> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >> see if there are no reservations from Alexander or Rob. > I think we need a bit more fixes. Here is ACL log for an anonymous > request: > > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from > "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > aci matched the subject by aci(27): aciname="permission:System: Read DNS > Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > matched the subject by aci(27): aciname="permission:System: Read DNS > Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > aci matched the subject by aci(27): aciname="permission:System: Read DNS > Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > anonymous: no aci matched the subject by aci(27): aciname= > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > anonymous: no aci matched the subject by aci(27): aciname= > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > matched the subject by aci(27): aciname="permission:System: Read DNS > Configuration", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed > by aci(38): aciname= "permission:System: Read User > Compat Tree", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched > uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) > to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage > any entry", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to > anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat > Tree", acidn="dc=ipacloud,dc=test" > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to > anonymous: cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: > cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to > anonymous: cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to > anonymous: cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to > anonymous: cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to > anonymous: cached allow by aci(38) > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > cached allow by aci(38) > > createTimestamp is operational attribute and is synthesized by > slapi-nis, there is no problem allowing access to it. I think we can > allow following operational attributes: > > createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, > entryDN, hasSubordinates, numSubordinates Ah, ok, probably yes. At least for some of them - CCing Simo. For example entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed for whole FreeIPA DIT. So this change is not so related to these patches. Do we also want to expose attributes like creatorsName/modifiersName? Do we consider that a public information or juts audit-like information for DM only? > Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't > run ipa-adtrust-install on this machine yet. I do not think that this attribute is written to cn=compat (did not see it in config) - is it? > > The same set should be allowed for primary tree. > IMO this should be just one global permission/ACI, set for DIT root. Martin From abokovoy at redhat.com Thu Sep 4 14:10:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Sep 2014 17:10:27 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54086F42.8070102@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> Message-ID: <20140904141027.GQ3593@redhat.com> On Thu, 04 Sep 2014, Martin Kosek wrote: >On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >> On Wed, 03 Sep 2014, Martin Kosek wrote: >>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds managed read permissions to the compat tree. >>>>>> >>>>>> For users it grants anonymous access; authenticated users can read >>>>>> groups, hosts and netgroups. >>>>>> >>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>> Membership" is only granted to authenticated users by default, and the >>>>>> compat tree exposes memberuid. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>> >>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>> >>>>> >>>> >>>> Fixed patch attached. >>>> >>> >>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>> see if there are no reservations from Alexander or Rob. >> I think we need a bit more fixes. Here is ACL log for an anonymous >> request: >> >> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> aci matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> aci matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> anonymous: no aci matched the subject by aci(27): aciname= >> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> anonymous: no aci matched the subject by aci(27): aciname= >> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >> by aci(38): aciname= "permission:System: Read User >> Compat Tree", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage >> any entry", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >> Tree", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> >> createTimestamp is operational attribute and is synthesized by >> slapi-nis, there is no problem allowing access to it. I think we can >> allow following operational attributes: >> >> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >> entryDN, hasSubordinates, numSubordinates > >Ah, ok, probably yes. At least for some of them - CCing Simo. For example >entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >for whole FreeIPA DIT. So this change is not so related to these patches. > >Do we also want to expose attributes like creatorsName/modifiersName? Do we >consider that a public information or juts audit-like information for DM only? They are standard features of LDAP servers. RFC 4512 states: ============================================================================= 3.4 Operational attributes ... Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT. ============================================================================= This is, again, a question of policy. Active Directory forbids anonymous access to the tree; so they always expose these attributes to authenticated users only. If we allow anonymous access, we should allow these attributes too. >> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >> run ipa-adtrust-install on this machine yet. > >I do not think that this attribute is written to cn=compat (did not see it in >config) - is it? It is written for AD users synthesized with SSSD help. I think the lack of it for IPA users is an oversight. > >> >> The same set should be allowed for primary tree. >> > >IMO this should be just one global permission/ACI, set for DIT root. Yes, that would work. -- / Alexander Bokovoy From mbasti at redhat.com Thu Sep 4 14:13:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 16:13:22 +0200 Subject: [Freeipa-devel] [PATCH 0119] Fix dnsrecord-mod, regression in 4.x Message-ID: <54087382.5020107@redhat.com> Regression is caused by different output types for dnsrecord-mod and dnsrecord-del. dnsrecord-mod internally calls remove record, if there is no more records in owner name, which cause output validation error. [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= ipa: ERROR: an internal error has occurred ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): output['value']: need ; got : [] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 348, in wsgi_execute result = self.Command[name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, in __call__ self.validate_output(ret, options['version']) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, in validate_output o.validate(self, value, version) File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, in validate types[0], type(value), value)) TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): output['value']: need ; got : [] ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(, , nsrecord=None, rights=False, structured=False, all=False, raw=False, version=u'2.102'): TypeError Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0119-Fix-dnsrecord-mod-raise-error-if-last-record-attr-is.patch Type: text/x-patch Size: 2232 bytes Desc: not available URL: From ssorce at redhat.com Thu Sep 4 14:30:11 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 04 Sep 2014 10:30:11 -0400 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54086F42.8070102@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> Message-ID: <1409841011.8703.34.camel@willson.usersys.redhat.com> On Thu, 2014-09-04 at 15:55 +0200, Martin Kosek wrote: > On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: > > On Wed, 03 Sep 2014, Martin Kosek wrote: > >> On 09/03/2014 03:15 PM, Petr Viktorin wrote: > >>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: > >>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: > >>>>> Hello, > >>>>> This adds managed read permissions to the compat tree. > >>>>> > >>>>> For users it grants anonymous access; authenticated users can read > >>>>> groups, hosts and netgroups. > >>>>> > >>>>> I'm unsure if this is what we want to do for groups, but "Read Group > >>>>> Membership" is only granted to authenticated users by default, and the > >>>>> compat tree exposes memberuid. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/4521 > >>>> > >>>> Self-NACK, there's a typo (though I could swear I tested this :/) > >>>> > >>>> > >>> > >>> Fixed patch attached. > >>> > >> > >> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to > >> see if there are no reservations from Alexander or Rob. > > I think we need a bit more fixes. Here is ACL log for an anonymous > > request: > > > > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from > > "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > > aci matched the subject by aci(27): aciname="permission:System: Read DNS > > Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > > matched the subject by aci(27): aciname="permission:System: Read DNS > > Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > > aci matched the subject by aci(27): aciname="permission:System: Read DNS > > Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > > anonymous: no aci matched the subject by aci(27): aciname= > > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > > anonymous: no aci matched the subject by aci(27): aciname= > > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > > matched the subject by aci(27): aciname="permission:System: Read DNS > > Configuration", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed > > by aci(38): aciname= "permission:System: Read User > > Compat Tree", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched > > uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) > > to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage > > any entry", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to > > anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat > > Tree", acidn="dc=ipacloud,dc=test" > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to > > anonymous: cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: > > cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to > > anonymous: cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to > > anonymous: cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to > > anonymous: cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to > > anonymous: cached allow by aci(38) > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > cached allow by aci(38) > > > > createTimestamp is operational attribute and is synthesized by > > slapi-nis, there is no problem allowing access to it. I think we can > > allow following operational attributes: > > > > createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, > > entryDN, hasSubordinates, numSubordinates > > Ah, ok, probably yes. At least for some of them - CCing Simo. For example > entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed > for whole FreeIPA DIT. So this change is not so related to these patches. Indeed entryUSN should always be allowed, at least to authenticated users. > Do we also want to expose attributes like creatorsName/modifiersName? Do we > consider that a public information or juts audit-like information for DM only? Are you asking just for the compat tree or in general ? > > Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't > > run ipa-adtrust-install on this machine yet. > > I do not think that this attribute is written to cn=compat (did not see it in > config) - is it? No, and shouldn't > > > > The same set should be allowed for primary tree. > > > > IMO this should be just one global permission/ACI, set for DIT root. From jcholast at redhat.com Thu Sep 4 14:36:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 16:36:07 +0200 Subject: [Freeipa-devel] [PATCH 0119] Fix dnsrecord-mod, regression in 4.x In-Reply-To: <54087382.5020107@redhat.com> References: <54087382.5020107@redhat.com> Message-ID: <540878D7.5090107@redhat.com> Hi, Dne 4.9.2014 v 16:13 Martin Basti napsal(a): > Regression is caused by different output types for dnsrecord-mod and > dnsrecord-del. > dnsrecord-mod internally calls remove record, if there is no more > records in owner name, which cause output validation error. > > > [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= > ipa: ERROR: an internal error has occurred > > ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => > PrimaryKey.validate(): > output['value']: need ; got 'list'>: [] > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 348, in wsgi_execute > result = self.Command[name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, > in __call__ > self.validate_output(ret, options['version']) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, > in validate_output > o.validate(self, value, version) > File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, > in validate > types[0], type(value), value)) > TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): > output['value']: need ; got 'list'>: [] > ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod( name ipa.example.>, , nsrecord=None, rights=False, > structured=False, all=False, raw=False, version=u'2.102'): TypeError > > > Patch attached. NACK, the assert needs to be inside the if, otherwise old clients will fail on it. Honza -- Jan Cholasta From mkosek at redhat.com Thu Sep 4 14:38:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 16:38:31 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140904141027.GQ3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140904141027.GQ3593@redhat.com> Message-ID: <54087967.1030204@redhat.com> On 09/04/2014 04:10 PM, Alexander Bokovoy wrote: ... >>> createTimestamp is operational attribute and is synthesized by >>> slapi-nis, there is no problem allowing access to it. I think we can >>> allow following operational attributes: >>> >>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>> entryDN, hasSubordinates, numSubordinates >> >> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >> for whole FreeIPA DIT. So this change is not so related to these patches. >> >> Do we also want to expose attributes like creatorsName/modifiersName? Do we >> consider that a public information or juts audit-like information for DM only? > They are standard features of LDAP servers. RFC 4512 states: > ============================================================================= > 3.4 Operational attributes > ... > Servers SHOULD maintain the 'creatorsName', 'createTimestamp', > 'modifiersName', and 'modifyTimestamp' attributes for all entries of the > DIT. > ============================================================================= > > This is, again, a question of policy. Active Directory forbids anonymous > access to the tree; so they always expose these attributes to > authenticated users only. If we allow anonymous access, we should allow > these attributes too. Well, DS *does* maintain the attributes - question is whether we want to show them to anonymous/authenticated people or just the DM :) > > >>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>> run ipa-adtrust-install on this machine yet. >> >> I do not think that this attribute is written to cn=compat (did not see it in >> config) - is it? > It is written for AD users synthesized with SSSD help. I think the lack > of it for IPA users is an oversight. Ok. Petr, you know what to do. Martin From pspacek at redhat.com Thu Sep 4 14:41:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 16:41:53 +0200 Subject: [Freeipa-devel] [PATCH 0281] Escape directory names generated from zone names In-Reply-To: <540877E2.1060101@redhat.com> References: <54086D3F.5070008@redhat.com> <540877E2.1060101@redhat.com> Message-ID: <54087A31.9070302@redhat.com> On 4.9.2014 16:32, Martin Basti wrote: > On 04/09/14 15:46, Petr Spacek wrote: >> Hello, >> >> Escape directory names generated from zone names. >> >> Previously root zone '.' and zone names with characters like '/' caused >> scattering of temporary files all over dyndb-ldap working directory. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/122 >> > Patch please :-) > And here is the patch ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0281-Escape-directory-names-generated-from-zone-names.patch Type: text/x-patch Size: 3513 bytes Desc: not available URL: From lkrispen at redhat.com Thu Sep 4 14:44:04 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 04 Sep 2014 16:44:04 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54087967.1030204@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140904141027.GQ3593@redhat.com> <54087967.1030204@redhat.com> Message-ID: <54087AB4.3090109@redhat.com> On 09/04/2014 04:38 PM, Martin Kosek wrote: > On 09/04/2014 04:10 PM, Alexander Bokovoy wrote: > ... >>>> createTimestamp is operational attribute and is synthesized by >>>> slapi-nis, there is no problem allowing access to it. I think we can >>>> allow following operational attributes: >>>> >>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>> entryDN, hasSubordinates, numSubordinates >>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>> for whole FreeIPA DIT. So this change is not so related to these patches. >>> >>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>> consider that a public information or juts audit-like information for DM only? >> They are standard features of LDAP servers. RFC 4512 states: >> ============================================================================= >> 3.4 Operational attributes >> ... >> Servers SHOULD maintain the 'creatorsName', 'createTimestamp', >> 'modifiersName', and 'modifyTimestamp' attributes for all entries of the >> DIT. >> ============================================================================= >> >> This is, again, a question of policy. Active Directory forbids anonymous >> access to the tree; so they always expose these attributes to >> authenticated users only. If we allow anonymous access, we should allow >> these attributes too. > Well, DS *does* maintain the attributes - question is whether we want to show > them to anonymous/authenticated people or just the DM :) if you want to show them depends if it is useful or sensitive. I don't know why an anonymous user would need access to them. Are they sensitive ? Well, at least they expose a DN which has rights to create and modify entries and could be used trying to get more access > >> >>>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>>> run ipa-adtrust-install on this machine yet. >>> I do not think that this attribute is written to cn=compat (did not see it in >>> config) - is it? >> It is written for AD users synthesized with SSSD help. I think the lack >> of it for IPA users is an oversight. > Ok. Petr, you know what to do. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mbasti at redhat.com Thu Sep 4 14:45:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 16:45:01 +0200 Subject: [Freeipa-devel] [PATCH 0119] Fix dnsrecord-mod, regression in 4.x In-Reply-To: <540878D7.5090107@redhat.com> References: <54087382.5020107@redhat.com> <540878D7.5090107@redhat.com> Message-ID: <54087AED.7080904@redhat.com> On 04/09/14 16:36, Jan Cholasta wrote: > Hi, > > Dne 4.9.2014 v 16:13 Martin Basti napsal(a): >> Regression is caused by different output types for dnsrecord-mod and >> dnsrecord-del. >> dnsrecord-mod internally calls remove record, if there is no more >> records in owner name, which cause output validation error. >> >> >> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >> ipa: ERROR: an internal error has occurred >> >> ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => >> PrimaryKey.validate(): >> output['value']: need ; got > 'list'>: [] >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >> 348, in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, >> in __call__ >> self.validate_output(ret, options['version']) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, >> in validate_output >> o.validate(self, value, version) >> File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, >> in validate >> types[0], type(value), value)) >> TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): >> output['value']: need ; got > 'list'>: [] >> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(> name ipa.example.>, , nsrecord=None, rights=False, >> structured=False, all=False, raw=False, version=u'2.102'): TypeError >> >> >> Patch attached. > > NACK, the assert needs to be inside the if, otherwise old clients will > fail on it. > > Honza > Thanks Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0119.2-Fix-dnsrecord-mod-raise-error-if-last-record-attr-is.patch Type: text/x-patch Size: 2236 bytes Desc: not available URL: From jhrozek at redhat.com Thu Sep 4 14:49:11 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 4 Sep 2014 16:49:11 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <1409841011.8703.34.camel@willson.usersys.redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <1409841011.8703.34.camel@willson.usersys.redhat.com> Message-ID: <20140904144911.GA25980@hendrix.redhat.com> On Thu, Sep 04, 2014 at 10:30:11AM -0400, Simo Sorce wrote: > On Thu, 2014-09-04 at 15:55 +0200, Martin Kosek wrote: > > On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: > > > On Wed, 03 Sep 2014, Martin Kosek wrote: > > >> On 09/03/2014 03:15 PM, Petr Viktorin wrote: > > >>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: > > >>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: > > >>>>> Hello, > > >>>>> This adds managed read permissions to the compat tree. > > >>>>> > > >>>>> For users it grants anonymous access; authenticated users can read > > >>>>> groups, hosts and netgroups. > > >>>>> > > >>>>> I'm unsure if this is what we want to do for groups, but "Read Group > > >>>>> Membership" is only granted to authenticated users by default, and the > > >>>>> compat tree exposes memberuid. > > >>>>> > > >>>>> https://fedorahosted.org/freeipa/ticket/4521 > > >>>> > > >>>> Self-NACK, there's a typo (though I could swear I tested this :/) > > >>>> > > >>>> > > >>> > > >>> Fixed patch attached. > > >>> > > >> > > >> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to > > >> see if there are no reservations from Alexander or Rob. > > > I think we need a bit more fixes. Here is ACL log for an anonymous > > > request: > > > > > > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from > > > "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > > > aci matched the subject by aci(27): aciname="permission:System: Read DNS > > > Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > > > matched the subject by aci(27): aciname="permission:System: Read DNS > > > Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > > > aci matched the subject by aci(27): aciname="permission:System: Read DNS > > > Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > > > anonymous: no aci matched the subject by aci(27): aciname= > > > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > > > anonymous: no aci matched the subject by aci(27): aciname= > > > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > > > entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > > > matched the subject by aci(27): aciname="permission:System: Read DNS > > > Configuration", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > > entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed > > > by aci(38): aciname= "permission:System: Read User > > > Compat Tree", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > > entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > > cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > > cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched > > > uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) > > > to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage > > > any entry", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to > > > anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat > > > Tree", acidn="dc=ipacloud,dc=test" > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to > > > anonymous: cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: > > > cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to > > > anonymous: cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to > > > anonymous: cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to > > > anonymous: cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to > > > anonymous: cached allow by aci(38) > > > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > > > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > > > cached allow by aci(38) > > > > > > createTimestamp is operational attribute and is synthesized by > > > slapi-nis, there is no problem allowing access to it. I think we can > > > allow following operational attributes: > > > > > > createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, > > > entryDN, hasSubordinates, numSubordinates > > > > Ah, ok, probably yes. At least for some of them - CCing Simo. For example > > entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed > > for whole FreeIPA DIT. So this change is not so related to these patches. > > Indeed entryUSN should always be allowed, at least to authenticated > users. Right, otherwise enumeration will be *painfully* slow as it would download the whole tree every time. We also use entryUSN in the compat tree for sudo rules by default, so please leave that attribute readable :) From jcholast at redhat.com Thu Sep 4 15:08:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 17:08:17 +0200 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <54076AC3.5040503@redhat.com> References: <54076AC3.5040503@redhat.com> Message-ID: <54088061.4060007@redhat.com> Hi, Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): > No longer request and install a cert for the IPA client machine. > > rob The original plan was to keep generating the certificate, but in /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). I'm fine with either approach. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319-Do-not-use-etc-pki-nssdb-for-IPA-host-certificate-in.patch Type: text/x-patch Size: 7682 bytes Desc: not available URL: From abokovoy at redhat.com Thu Sep 4 15:10:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Sep 2014 18:10:13 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <1409841011.8703.34.camel@willson.usersys.redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <1409841011.8703.34.camel@willson.usersys.redhat.com> Message-ID: <20140904151013.GR3593@redhat.com> On Thu, 04 Sep 2014, Simo Sorce wrote: >On Thu, 2014-09-04 at 15:55 +0200, Martin Kosek wrote: >> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >> > On Wed, 03 Sep 2014, Martin Kosek wrote: >> >> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >> >>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >> >>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >> >>>>> Hello, >> >>>>> This adds managed read permissions to the compat tree. >> >>>>> >> >>>>> For users it grants anonymous access; authenticated users can read >> >>>>> groups, hosts and netgroups. >> >>>>> >> >>>>> I'm unsure if this is what we want to do for groups, but "Read Group >> >>>>> Membership" is only granted to authenticated users by default, and the >> >>>>> compat tree exposes memberuid. >> >>>>> >> >>>>> https://fedorahosted.org/freeipa/ticket/4521 >> >>>> >> >>>> Self-NACK, there's a typo (though I could swear I tested this :/) >> >>>> >> >>>> >> >>> >> >>> Fixed patch attached. >> >>> >> >> >> >> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >> >> see if there are no reservations from Alexander or Rob. >> > I think we need a bit more fixes. Here is ACL log for an anonymous >> > request: >> > >> > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >> > "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> > aci matched the subject by aci(27): aciname="permission:System: Read DNS >> > Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> > matched the subject by aci(27): aciname="permission:System: Read DNS >> > Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> > aci matched the subject by aci(27): aciname="permission:System: Read DNS >> > Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> > anonymous: no aci matched the subject by aci(27): aciname= >> > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> > anonymous: no aci matched the subject by aci(27): aciname= >> > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> > entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> > matched the subject by aci(27): aciname="permission:System: Read DNS >> > Configuration", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> > entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >> > by aci(38): aciname= "permission:System: Read User >> > Compat Tree", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> > entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> > cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> > cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >> > uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >> > to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage >> > any entry", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >> > anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >> > Tree", acidn="dc=ipacloud,dc=test" >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >> > anonymous: cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >> > cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >> > anonymous: cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >> > anonymous: cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >> > anonymous: cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >> > anonymous: cached allow by aci(38) >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> > cached allow by aci(38) >> > >> > createTimestamp is operational attribute and is synthesized by >> > slapi-nis, there is no problem allowing access to it. I think we can >> > allow following operational attributes: >> > >> > createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >> > entryDN, hasSubordinates, numSubordinates >> >> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >> for whole FreeIPA DIT. So this change is not so related to these patches. > >Indeed entryUSN should always be allowed, at least to authenticated >users. > >> Do we also want to expose attributes like creatorsName/modifiersName? Do we >> consider that a public information or juts audit-like information for DM only? > >Are you asking just for the compat tree or in general ? > >> > Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >> > run ipa-adtrust-install on this machine yet. >> >> I do not think that this attribute is written to cn=compat (did not see it in >> config) - is it? > >No, and shouldn't Simo, so are you telling that we shouldn't return SIDs at all, even for AD users we show in the compat tree? We currently return it for all users and configure additional rule in the cn=users,cn=compat set within the slapi-nis plugin if we are serving AD users to compat tree: if (ret.check_nsswitch != SCH_NSSWITCH_NONE) { backend_shr_add_strlist(&ret.attribute_format, "objectClass=%ifeq(\"%{ipaNTSecurityIdentifier}\",\"\",\"\",\"extensibleObject\")"); backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); } -- / Alexander Bokovoy From jcholast at redhat.com Thu Sep 4 15:12:52 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Sep 2014 17:12:52 +0200 Subject: [Freeipa-devel] [PATCH 0119] Fix dnsrecord-mod, regression in 4.x In-Reply-To: <54087AED.7080904@redhat.com> References: <54087382.5020107@redhat.com> <540878D7.5090107@redhat.com> <54087AED.7080904@redhat.com> Message-ID: <54088174.9030809@redhat.com> Dne 4.9.2014 v 16:45 Martin Basti napsal(a): > On 04/09/14 16:36, Jan Cholasta wrote: >> Hi, >> >> Dne 4.9.2014 v 16:13 Martin Basti napsal(a): >>> Regression is caused by different output types for dnsrecord-mod and >>> dnsrecord-del. >>> dnsrecord-mod internally calls remove record, if there is no more >>> records in owner name, which cause output validation error. >>> >>> >>> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >>> ipa: ERROR: an internal error has occurred >>> >>> ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => >>> PrimaryKey.validate(): >>> output['value']: need ; got >> 'list'>: [] >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>> 348, in wsgi_execute >>> result = self.Command[name](*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, >>> in __call__ >>> self.validate_output(ret, options['version']) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, >>> in validate_output >>> o.validate(self, value, version) >>> File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, >>> in validate >>> types[0], type(value), value)) >>> TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): >>> output['value']: need ; got >> 'list'>: [] >>> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(>> name ipa.example.>, , nsrecord=None, rights=False, >>> structured=False, all=False, raw=False, version=u'2.102'): TypeError >>> >>> >>> Patch attached. >> >> NACK, the assert needs to be inside the if, otherwise old clients will >> fail on it. >> >> Honza >> > Thanks > > Updated patch attached > > Thanks, ACK. -- Jan Cholasta From ssorce at redhat.com Thu Sep 4 15:12:03 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 04 Sep 2014 11:12:03 -0400 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140904151013.GR3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <1409841011.8703.34.camel@willson.usersys.redhat.com> <20140904151013.GR3593@redhat.com> Message-ID: <1409843523.8703.38.camel@willson.usersys.redhat.com> On Thu, 2014-09-04 at 18:10 +0300, Alexander Bokovoy wrote: > On Thu, 04 Sep 2014, Simo Sorce wrote: > >On Thu, 2014-09-04 at 15:55 +0200, Martin Kosek wrote: > >> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: > >> > On Wed, 03 Sep 2014, Martin Kosek wrote: > >> >> On 09/03/2014 03:15 PM, Petr Viktorin wrote: > >> >>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: > >> >>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: > >> >>>>> Hello, > >> >>>>> This adds managed read permissions to the compat tree. > >> >>>>> > >> >>>>> For users it grants anonymous access; authenticated users can read > >> >>>>> groups, hosts and netgroups. > >> >>>>> > >> >>>>> I'm unsure if this is what we want to do for groups, but "Read Group > >> >>>>> Membership" is only granted to authenticated users by default, and the > >> >>>>> compat tree exposes memberuid. > >> >>>>> > >> >>>>> https://fedorahosted.org/freeipa/ticket/4521 > >> >>>> > >> >>>> Self-NACK, there's a typo (though I could swear I tested this :/) > >> >>>> > >> >>>> > >> >>> > >> >>> Fixed patch attached. > >> >>> > >> >> > >> >> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to > >> >> see if there are no reservations from Alexander or Rob. > >> > I think we need a bit more fixes. Here is ACL log for an anonymous > >> > request: > >> > > >> > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from > >> > "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > >> > aci matched the subject by aci(27): aciname="permission:System: Read DNS > >> > Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > >> > matched the subject by aci(27): aciname="permission:System: Read DNS > >> > Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no > >> > aci matched the subject by aci(27): aciname="permission:System: Read DNS > >> > Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > >> > anonymous: no aci matched the subject by aci(27): aciname= > >> > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to > >> > anonymous: no aci matched the subject by aci(27): aciname= > >> > "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on > >> > entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci > >> > matched the subject by aci(27): aciname="permission:System: Read DNS > >> > Configuration", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > >> > entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed > >> > by aci(38): aciname= "permission:System: Read User > >> > Compat Tree", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > >> > entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > >> > cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > >> > cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched > >> > uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) > >> > to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage > >> > any entry", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to > >> > anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat > >> > Tree", acidn="dc=ipacloud,dc=test" > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to > >> > anonymous: cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: > >> > cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to > >> > anonymous: cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to > >> > anonymous: cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to > >> > anonymous: cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to > >> > anonymous: cached allow by aci(38) > >> > [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on > >> > entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: > >> > cached allow by aci(38) > >> > > >> > createTimestamp is operational attribute and is synthesized by > >> > slapi-nis, there is no problem allowing access to it. I think we can > >> > allow following operational attributes: > >> > > >> > createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, > >> > entryDN, hasSubordinates, numSubordinates > >> > >> Ah, ok, probably yes. At least for some of them - CCing Simo. For example > >> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed > >> for whole FreeIPA DIT. So this change is not so related to these patches. > > > >Indeed entryUSN should always be allowed, at least to authenticated > >users. > > > >> Do we also want to expose attributes like creatorsName/modifiersName? Do we > >> consider that a public information or juts audit-like information for DM only? > > > >Are you asking just for the compat tree or in general ? > > > >> > Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't > >> > run ipa-adtrust-install on this machine yet. > >> > >> I do not think that this attribute is written to cn=compat (did not see it in > >> config) - is it? > > > >No, and shouldn't > Simo, so are you telling that we shouldn't return SIDs at all, even for > AD users we show in the compat tree? We currently return it for all > users and configure additional rule in the cn=users,cn=compat set within > the slapi-nis plugin if we are serving AD users to compat tree: > > if (ret.check_nsswitch != SCH_NSSWITCH_NONE) { > backend_shr_add_strlist(&ret.attribute_format, "objectClass=%ifeq(\"%{ipaNTSecurityIdentifier}\",\"\",\"\",\"extensibleObject\")"); > backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); > } The compat tree was originally built as a way to show only Posix attributes to legacy clients. So unless there is a very good reason I tend to think no other attributes should be exposed through it by default. Simo. From rcritten at redhat.com Thu Sep 4 15:13:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Sep 2014 11:13:27 -0400 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <54088061.4060007@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> Message-ID: <54088197.80700@redhat.com> Jan Cholasta wrote: > Hi, > > Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >> No longer request and install a cert for the IPA client machine. >> >> rob > > The original plan was to keep generating the certificate, but in > /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). > > I'm fine with either approach. > The cert has never been used and is now actively causing issues in RHEL-7 with systemd and kickstart. It could be made optional, and move the location, but IMHO its time has come. rob From mbasti at redhat.com Thu Sep 4 15:40:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 17:40:58 +0200 Subject: [Freeipa-devel] [PATCH 0280] Use "master" subdirectory for temporary files related to zones In-Reply-To: <54085E7B.9040903@redhat.com> References: <54085E7B.9040903@redhat.com> Message-ID: <5408880A.4090607@redhat.com> On 04/09/14 14:43, Petr Spacek wrote: > Hello, > > Use "master" subdirectory for temporary files related to zones. > > This allows us to separate zone and non-zone metadata and also to > separate > master and (hypothetical) slave zones. > Works fine. ACK -- Martin Basti From mbasti at redhat.com Thu Sep 4 15:42:38 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 17:42:38 +0200 Subject: [Freeipa-devel] [PATCH 0281] Escape directory names generated from zone names In-Reply-To: <54087A31.9070302@redhat.com> References: <54086D3F.5070008@redhat.com> <540877E2.1060101@redhat.com> <54087A31.9070302@redhat.com> Message-ID: <5408886E.7050706@redhat.com> On 04/09/14 16:41, Petr Spacek wrote: > On 4.9.2014 16:32, Martin Basti wrote: >> On 04/09/14 15:46, Petr Spacek wrote: >>> Hello, >>> >>> Escape directory names generated from zone names. >>> >>> Previously root zone '.' and zone names with characters like '/' caused >>> scattering of temporary files all over dyndb-ldap working directory. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/122 >>> >> Patch please :-) >> > And here is the patch ... > Works for me. ACK > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Sep 4 15:55:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 17:55:51 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions Message-ID: <54088B87.2050300@redhat.com> Hello, Create temporary directories with ug=rwx,o= permissions. Zero group permissions do not allow to use POSIX ACLs which is undesirable. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0282-Create-temporary-directories-with-ug-rwx-o-permissio.patch Type: text/x-patch Size: 880 bytes Desc: not available URL: From mbasti at redhat.com Thu Sep 4 16:31:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Sep 2014 18:31:21 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <54088B87.2050300@redhat.com> References: <54088B87.2050300@redhat.com> Message-ID: <540893D9.2010206@redhat.com> On 04/09/14 17:55, Petr Spacek wrote: > Hello, > > Create temporary directories with ug=rwx,o= permissions. > > Zero group permissions do not allow to use POSIX ACLs which is > undesirable. > NACK It creates drwxr-x--- permissions (umask problem) > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Sep 4 18:33:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 04 Sep 2014 13:33:27 -0500 Subject: [Freeipa-devel] [PATCH] 744 webui: switch associators if default doesn't work In-Reply-To: <53F76FEA.9090806@redhat.com> References: <53F76FEA.9090806@redhat.com> Message-ID: <5408B077.9020001@redhat.com> On 8/22/2014 11:29 AM, Petr Vobornik wrote: > 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 ACK. -- Endi S. Dewata From edewata at redhat.com Thu Sep 4 18:37:05 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 04 Sep 2014 13:37:05 -0500 Subject: [Freeipa-devel] [PATCH] 745 webui: notify psw change success only once In-Reply-To: <54003C8B.6050109@redhat.com> References: <54003C8B.6050109@redhat.com> Message-ID: <5408B151.7000909@redhat.com> On 8/29/2014 3:40 AM, Petr Vobornik wrote: > 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/ ACK. -- Endi S. Dewata From edewata at redhat.com Thu Sep 4 19:26:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 04 Sep 2014 14:26:51 -0500 Subject: [Freeipa-devel] [PATCH] 746-747 append domain into network.negotiate-auth.trusted-uris In-Reply-To: <5400A39F.7000905@redhat.com> References: <5400A39F.7000905@redhat.com> Message-ID: <5408BCFB.1080108@redhat.com> On 8/29/2014 11:00 AM, Petr Vobornik wrote: > [PATCH] 746 webui: append network.negotiate-auth.trusted-uris > > https://fedorahosted.org/freeipa/ticket/4478 Some comments/questions: 1. If I'm reading this correctly, if the preference is currently empty, the method will just return without setting the new value. 2. If the new value already exists, the method will just return. Shouldn't it "continue" with the rest of the loop instead of "return"? This applies to #1 as well. 3. Using indexOf() to find a URI in a string can produce false matches. For example, aa.com will match baa.com. Ideally the existing value should be parsed into a collection of URI's, then the new URI should be matched using a proper URI matching algorithm. > [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 ACK. -- Endi S. Dewata From abokovoy at redhat.com Fri Sep 5 06:56:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 09:56:03 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54086F42.8070102@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> Message-ID: <20140905065603.GT3593@redhat.com> On Thu, 04 Sep 2014, Martin Kosek wrote: >On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >> On Wed, 03 Sep 2014, Martin Kosek wrote: >>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds managed read permissions to the compat tree. >>>>>> >>>>>> For users it grants anonymous access; authenticated users can read >>>>>> groups, hosts and netgroups. >>>>>> >>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>> Membership" is only granted to authenticated users by default, and the >>>>>> compat tree exposes memberuid. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>> >>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>> >>>>> >>>> >>>> Fixed patch attached. >>>> >>> >>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>> see if there are no reservations from Alexander or Rob. >> I think we need a bit more fixes. Here is ACL log for an anonymous >> request: >> >> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> aci matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >> aci matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> anonymous: no aci matched the subject by aci(27): aciname= >> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >> anonymous: no aci matched the subject by aci(27): aciname= >> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >> matched the subject by aci(27): aciname="permission:System: Read DNS >> Configuration", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >> by aci(38): aciname= "permission:System: Read User >> Compat Tree", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage >> any entry", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >> Tree", acidn="dc=ipacloud,dc=test" >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >> cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >> anonymous: cached allow by aci(38) >> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >> cached allow by aci(38) >> >> createTimestamp is operational attribute and is synthesized by >> slapi-nis, there is no problem allowing access to it. I think we can >> allow following operational attributes: >> >> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >> entryDN, hasSubordinates, numSubordinates > >Ah, ok, probably yes. At least for some of them - CCing Simo. For example >entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >for whole FreeIPA DIT. So this change is not so related to these patches. > >Do we also want to expose attributes like creatorsName/modifiersName? Do we >consider that a public information or juts audit-like information for DM only? > >> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >> run ipa-adtrust-install on this machine yet. > >I do not think that this attribute is written to cn=compat (did not see it in >config) - is it? > >> >> The same set should be allowed for primary tree. >> > >IMO this should be just one global permission/ACI, set for DIT root. I experimented a bit, by setting SSSD with a simple LDAP provider talking to a compat tree (with views enabled, but that doesn't change anything) and I think we need to move to ipabindpermruletype=anonymous or otherwise such setup will not work at all. Attached is my take at it on top of Petr's patchset. You can ignore views-related ACIs for time being. -- / Alexander Bokovoy -------------- next part -------------- diff --git a/ACI.txt b/ACI.txt index 6a4e646..8cce4a4 100644 --- a/ACI.txt +++ b/ACI.txt @@ -51,9 +51,11 @@ aci: (targetattr = "member")(targetfilter = "(&(!(cn=admins))(objectclass=ipause dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || description || gidnumber || ipauniqueid || mepmanagedby || objectclass")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Modify Groups";allow (write) groupdn = "ldap:///cn=System: Modify Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || memberuid || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=*,cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=*,cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || description || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -239,7 +241,7 @@ aci: (targetattr = "*")(target = "ldap:///cn=UPG Definition,cn=Definitions,cn=Ma dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "audio || businesscategory || carlicense || departmentnumber || destinationindicator || employeenumber || employeetype || fax || homephone || homepostaladdress || inetuserhttpurl || inetuserstatus || internationalisdnnumber || jpegphoto || l || labeleduri || mail || mobile || o || ou || pager || photo || physicaldeliveryofficename || postaladdress || postalcode || postofficebox || preferreddeliverymethod || preferredlanguage || registeredaddress || roomnumber || secretary || seealso || st || street || telephonenumber || teletexterminalidentifier || telexnumber || usercertificate || usersmimecertificate || x121address || x500uniqueidentifier")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Addressbook Attributes";allow (compare,read,search) userdn = "ldap:///all";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || gecos || gidnumber || homedirectory || loginshell || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///uid=*,cn=users,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "ipasshpubkey || ipauniqueid || ipauserauthtype || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User IPA Attributes";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -250,6 +252,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || description || displayname || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///uid=*,cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Remove Users";allow (delete) groupdn = "ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -276,6 +280,8 @@ dn: cn=dna,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || dnahostname || dnaportnum || dnaremainingvalues || dnaremotebindmethod || dnaremoteconnprotocol || dnasecureportnum || objectclass")(targetfilter = "(objectclass=dnasharedconfig)")(version 3.0;acl "permission:System: Read DNA Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || ipaconfigstring || objectclass")(targetfilter = "(objectclass=nscontainer)")(version 3.0;acl "permission:System: Read IPA Masters";allow (compare,read,search) groupdn = "ldap:///cn=System: Read IPA Masters,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: dc=ipa,dc=example +aci: (targetattr = "createtimestamp || creatorsname || entryusn || modifiersname || modifytimestamp")(targetfilter = "(objectclass=*)")(version 3.0;acl "permission:System: Read Operational Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=config aci: (targetattr = "cn || description || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || nsds5replicaautoreferral || nsds5replicabackoffmax || nsds5replicabackoffmin || nsds5replicabinddn || nsds5replicabindmethod || nsds5replicabusywaittime || nsds5replicachangecount || nsds5replicachangessentsincestartup || nsds5replicacleanruv || nsds5replicacleanruvnotified || nsds5replicacredentials || nsds5replicaenabled || nsds5replicahost || nsds5replicaid || nsds5replicalastinitend || nsds5replicalastinitstart || nsds5replicalastinitstatus || nsds5replicalastupdateend || nsds5replicalastupdatestart || nsds5replicalastupdatestatus || nsds5replicalegacyconsumer || nsds5replicaname || nsds5replicaport || nsds5replicaprotocoltimeout || nsds5replicapurgedelay || nsds5replicareferral || nsds5replicaroot || nsds5replicasessionpausetime || nsds5replicastripattrs || nsds5replicatedattributelist || nsds5replicatedattributelisttotal || nsds5replicatimeout || nsds5replicatombstonepurgeinterval || nsds5replicatransportinfo || nsds5replicatype || nsds5replicaupdateinprogress || nsds5replicaupdateschedule || nsds5task || nsds7directoryreplicasubtree || nsds7dirsynccookie || nsds7newwingroupsyncenabled || nsds7newwinusersyncenabled || nsds7windowsdomain || nsds7windowsreplicasubtree || nsruvreplicalastmodified || nsstate || objectclass || onewaysync || winsyncdirectoryfilter || winsyncinterval || winsyncmoveaction || winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: Read Replication Agreements";allow (compare,read,search) groupdn = "ldap:///cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=replication,cn=etc,dc=ipa,dc=example diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index a4340bb..ad96efe 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -204,12 +204,24 @@ class group(LDAPObject): }, 'System: Read Group Compat Tree': { 'non_object': True, - 'ipapermbindruletype': 'all', + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=groups', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'cn', 'memberuid', 'gidnumber', + 'createtimestamp', 'modifytimestamp', 'entryusn', + }, + }, + 'System: Read Group Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', 'ipapermlocation': api.env.basedn, - 'ipapermtarget': DN('cn=groups', 'cn=compat', api.env.basedn), + 'ipapermtarget': DN('cn=*', 'cn=groups', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { - 'objectclass', 'cn', 'memberuid', + 'objectclass', 'cn', 'memberuid', 'gidnumber', + 'createtimestamp', 'modifytimestamp', 'entryusn', }, }, } diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd..5c03a09 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -428,11 +428,24 @@ class user(LDAPObject): 'non_object': True, 'ipapermbindruletype': 'anonymous', 'ipapermlocation': api.env.basedn, - 'ipapermtarget': DN('cn=users', 'cn=compat', api.env.basedn), + 'ipapermtarget': DN('cn=users', 'cn=compat', api.env.basedn), 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', 'homedirectory', 'loginshell', + 'createtimestamp', 'modifytimestamp', 'entryusn', + }, + }, + 'System: Read User Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('uid=*', 'cn=users', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', + 'homedirectory', 'loginshell', + 'createtimestamp', 'modifytimestamp', 'entryusn', }, }, } diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py index 2051bd4..d2b7dea 100644 --- a/ipaserver/install/plugins/update_managed_permissions.py +++ b/ipaserver/install/plugins/update_managed_permissions.py @@ -96,6 +96,17 @@ from ipaserver.install.plugins.baseupdate import PostUpdate register = Registry() NONOBJECT_PERMISSIONS = { + 'System: Read Operational Attributes': { + 'replaces_global_anonymous_aci': True, + 'ipapermlocation': api.env.basedn, + 'ipapermtargetfilter': {'(objectclass=*)'}, + 'ipapermbindruletype': 'anonymous', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'createtimestamp', 'modifytimestamp', + 'creatorsname', 'modifiersname', 'entryusn', + }, + }, 'System: Read IPA Masters': { 'replaces_global_anonymous_aci': True, 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), From abokovoy at redhat.com Fri Sep 5 07:03:41 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 10:03:41 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140905065603.GT3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> Message-ID: <20140905070341.GU3593@redhat.com> On Fri, 05 Sep 2014, Alexander Bokovoy wrote: > On Thu, 04 Sep 2014, Martin Kosek wrote: >> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> This adds managed read permissions to the compat tree. >>>>>>> >>>>>>> For users it grants anonymous access; authenticated users can read >>>>>>> groups, hosts and netgroups. >>>>>>> >>>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>>> Membership" is only granted to authenticated users by default, and the >>>>>>> compat tree exposes memberuid. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>>> >>>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>>> >>>>>> >>>>> >>>>> Fixed patch attached. >>>>> >>>> >>>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>>> see if there are no reservations from Alexander or Rob. >>> I think we need a bit more fixes. Here is ACL log for an anonymous >>> request: >>> >>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >>> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>> Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>> matched the subject by aci(27): aciname="permission:System: Read DNS >>> Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>> Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>> anonymous: no aci matched the subject by aci(27): aciname= >>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>> anonymous: no aci matched the subject by aci(27): aciname= >>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>> matched the subject by aci(27): aciname="permission:System: Read DNS >>> Configuration", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >>> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >>> by aci(38): aciname= "permission:System: Read User >>> Compat Tree", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >>> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>> cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow search on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>> cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >>> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >>> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can manage >>> any entry", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >>> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >>> Tree", acidn="dc=ipacloud,dc=test" >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >>> anonymous: cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >>> cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >>> anonymous: cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >>> anonymous: cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >>> anonymous: cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >>> anonymous: cached allow by aci(38) >>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>> cached allow by aci(38) >>> >>> createTimestamp is operational attribute and is synthesized by >>> slapi-nis, there is no problem allowing access to it. I think we can >>> allow following operational attributes: >>> >>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>> entryDN, hasSubordinates, numSubordinates >> >> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >> for whole FreeIPA DIT. So this change is not so related to these patches. >> >> Do we also want to expose attributes like creatorsName/modifiersName? Do we >> consider that a public information or juts audit-like information for DM only? >> >>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>> run ipa-adtrust-install on this machine yet. >> >> I do not think that this attribute is written to cn=compat (did not see it in >> config) - is it? >> >>> >>> The same set should be allowed for primary tree. >>> >> >> IMO this should be just one global permission/ACI, set for DIT root. > > I experimented a bit, by setting SSSD with a simple LDAP provider > talking to a compat tree (with views enabled, but that doesn't change > anything) and I think we need to move to ipabindpermruletype=anonymous > or otherwise such setup will not work at all. Attached is my take at it > on top of Petr's patchset. > > You can ignore views-related ACIs for time being. Scratch that, it was older version with duplicate entries. Proper one is attached. -- / Alexander Bokovoy -------------- next part -------------- diff --git a/ACI.txt b/ACI.txt index 6a4e646..44e516c 100644 --- a/ACI.txt +++ b/ACI.txt @@ -51,9 +51,11 @@ aci: (targetattr = "member")(targetfilter = "(&(!(cn=admins))(objectclass=ipause dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || description || gidnumber || ipauniqueid || mepmanagedby || objectclass")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Modify Groups";allow (write) groupdn = "ldap:///cn=System: Modify Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || memberuid || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "cn || gidnumber || memberuid || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || gidnumber || memberuid || objectclass")(target = "ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || description || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -99,7 +101,7 @@ aci: (targetattr = "ipasshpubkey")(targetfilter = "(objectclass=ipahost)")(versi dn: cn=computers,cn=accounts,dc=ipa,dc=example aci: (targetattr = "description || l || macaddress || nshardwareplatform || nshostlocation || nsosversion || userclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Modify Hosts";allow (write) groupdn = "ldap:///cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || macaddress || objectclass")(target = "ldap:///cn=computers,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Host Compat Tree";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "cn || macaddress || objectclass")(target = "ldap:///cn=computers,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Host Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=computers,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Read Host Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=computers,cn=accounts,dc=ipa,dc=example @@ -131,7 +133,7 @@ aci: (targetattr = "externalhost || member || memberhost || memberuser")(targetf dn: cn=ng,cn=alt,dc=ipa,dc=example aci: (targetattr = "description")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Modify Netgroups";allow (write) groupdn = "ldap:///cn=System: Modify Netgroups,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || membernisnetgroup || nisnetgrouptriple || objectclass")(target = "ldap:///cn=ng,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Netgroup Compat Tree";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "cn || membernisnetgroup || nisnetgrouptriple || objectclass")(target = "ldap:///cn=ng,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Netgroup Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=ng,cn=alt,dc=ipa,dc=example aci: (targetattr = "externalhost || member || memberhost || memberof || memberuser || objectclass")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Read Netgroup Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ng,cn=alt,dc=ipa,dc=example @@ -219,7 +221,7 @@ aci: (targetattr = "cmdcategory || description || externalhost || externaluser | dn: cn=sudorules,cn=sudo,dc=ipa,dc=example aci: (targetattr = "cmdcategory || cn || description || externalhost || externaluser || hostcategory || hostmask || ipaenabledflag || ipasudoopt || ipasudorunas || ipasudorunasextgroup || ipasudorunasextuser || ipasudorunasextusergroup || ipasudorunasgroup || ipasudorunasgroupcategory || ipasudorunasusercategory || ipauniqueid || member || memberallowcmd || memberdenycmd || memberhost || memberuser || objectclass || sudonotafter || sudonotbefore || sudoorder || usercategory")(targetfilter = "(objectclass=ipasudorule)")(version 3.0;acl "permission:System: Read Sudo Rules";allow (compare,read,search) userdn = "ldap:///all";) dn: dc=ipa,dc=example -aci: (targetattr = "cn || description || objectclass || ou || sudocommand || sudohost || sudonotafter || sudonotbefore || sudooption || sudoorder || sudorunas || sudorunasgroup || sudorunasuser || sudouser")(target = "ldap:///ou=sudoers,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Sudoers compat tree";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "cn || description || objectclass || ou || sudocommand || sudohost || sudonotafter || sudonotbefore || sudooption || sudoorder || sudorunas || sudorunasgroup || sudorunasuser || sudouser")(target = "ldap:///ou=sudoers,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Sudoers compat tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=trusts,dc=ipa,dc=example aci: (targetattr = "cn || ipantflatname || ipantsecurityidentifier || ipantsidblacklistincoming || ipantsidblacklistoutgoing || ipanttrusteddomainsid || ipanttrustpartner || objectclass")(version 3.0;acl "permission:System: Read Trust Information";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=trusts,dc=ipa,dc=example @@ -250,6 +252,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || description || displayname || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || gecos || gidnumber || homedirectory || loginshell || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Remove Users";allow (delete) groupdn = "ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -276,6 +280,8 @@ dn: cn=dna,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || dnahostname || dnaportnum || dnaremainingvalues || dnaremotebindmethod || dnaremoteconnprotocol || dnasecureportnum || objectclass")(targetfilter = "(objectclass=dnasharedconfig)")(version 3.0;acl "permission:System: Read DNA Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || ipaconfigstring || objectclass")(targetfilter = "(objectclass=nscontainer)")(version 3.0;acl "permission:System: Read IPA Masters";allow (compare,read,search) groupdn = "ldap:///cn=System: Read IPA Masters,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: dc=ipa,dc=example +aci: (targetattr = "createtimestamp || creatorsname || entryusn || modifiersname || modifytimestamp")(targetfilter = "(objectclass=*)")(version 3.0;acl "permission:System: Read Operational Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=config aci: (targetattr = "cn || description || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || nsds5replicaautoreferral || nsds5replicabackoffmax || nsds5replicabackoffmin || nsds5replicabinddn || nsds5replicabindmethod || nsds5replicabusywaittime || nsds5replicachangecount || nsds5replicachangessentsincestartup || nsds5replicacleanruv || nsds5replicacleanruvnotified || nsds5replicacredentials || nsds5replicaenabled || nsds5replicahost || nsds5replicaid || nsds5replicalastinitend || nsds5replicalastinitstart || nsds5replicalastinitstatus || nsds5replicalastupdateend || nsds5replicalastupdatestart || nsds5replicalastupdatestatus || nsds5replicalegacyconsumer || nsds5replicaname || nsds5replicaport || nsds5replicaprotocoltimeout || nsds5replicapurgedelay || nsds5replicareferral || nsds5replicaroot || nsds5replicasessionpausetime || nsds5replicastripattrs || nsds5replicatedattributelist || nsds5replicatedattributelisttotal || nsds5replicatimeout || nsds5replicatombstonepurgeinterval || nsds5replicatransportinfo || nsds5replicatype || nsds5replicaupdateinprogress || nsds5replicaupdateschedule || nsds5task || nsds7directoryreplicasubtree || nsds7dirsynccookie || nsds7newwingroupsyncenabled || nsds7newwinusersyncenabled || nsds7windowsdomain || nsds7windowsreplicasubtree || nsruvreplicalastmodified || nsstate || objectclass || onewaysync || winsyncdirectoryfilter || winsyncinterval || winsyncmoveaction || winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: Read Replication Agreements";allow (compare,read,search) groupdn = "ldap:///cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=replication,cn=etc,dc=ipa,dc=example diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index a4340bb..620bb11 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -204,12 +204,22 @@ class group(LDAPObject): }, 'System: Read Group Compat Tree': { 'non_object': True, - 'ipapermbindruletype': 'all', + 'ipapermbindruletype': 'anonymous', 'ipapermlocation': api.env.basedn, 'ipapermtarget': DN('cn=groups', 'cn=compat', api.env.basedn), 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { - 'objectclass', 'cn', 'memberuid', + 'objectclass', 'cn', 'memberuid', 'gidnumber', + }, + }, + 'System: Read Group Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=groups', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'cn', 'memberuid', 'gidnumber', }, }, } diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py index 5301c1a..3f5e4e7 100644 --- a/ipalib/plugins/host.py +++ b/ipalib/plugins/host.py @@ -370,7 +370,7 @@ class host(LDAPObject): }, 'System: Read Host Compat Tree': { 'non_object': True, - 'ipapermbindruletype': 'all', + 'ipapermbindruletype': 'anonymous', 'ipapermlocation': api.env.basedn, 'ipapermtarget': DN('cn=computers', 'cn=compat', api.env.basedn), 'ipapermright': {'read', 'search', 'compare'}, diff --git a/ipalib/plugins/netgroup.py b/ipalib/plugins/netgroup.py index 4254526..da2808f 100644 --- a/ipalib/plugins/netgroup.py +++ b/ipalib/plugins/netgroup.py @@ -162,7 +162,7 @@ class netgroup(LDAPObject): }, 'System: Read Netgroup Compat Tree': { 'non_object': True, - 'ipapermbindruletype': 'all', + 'ipapermbindruletype': 'anonymous', 'ipapermlocation': api.env.basedn, 'ipapermtarget': DN('cn=ng', 'cn=compat', api.env.basedn), 'ipapermright': {'read', 'search', 'compare'}, diff --git a/ipalib/plugins/sudorule.py b/ipalib/plugins/sudorule.py index d2d30a1..f16d275 100644 --- a/ipalib/plugins/sudorule.py +++ b/ipalib/plugins/sudorule.py @@ -166,7 +166,7 @@ class sudorule(LDAPObject): 'non_object': True, 'ipapermlocation': api.env.basedn, 'ipapermtarget': DN('ou=sudoers', api.env.basedn), - 'ipapermbindruletype': 'all', + 'ipapermbindruletype': 'anonymous', 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectclass', 'cn', 'ou', diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd..e206289 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -435,6 +435,17 @@ class user(LDAPObject): 'homedirectory', 'loginshell', }, }, + 'System: Read User Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=users', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', + 'homedirectory', 'loginshell', + }, + }, } label = _('Users') diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py index 2051bd4..d2b7dea 100644 --- a/ipaserver/install/plugins/update_managed_permissions.py +++ b/ipaserver/install/plugins/update_managed_permissions.py @@ -96,6 +96,17 @@ from ipaserver.install.plugins.baseupdate import PostUpdate register = Registry() NONOBJECT_PERMISSIONS = { + 'System: Read Operational Attributes': { + 'replaces_global_anonymous_aci': True, + 'ipapermlocation': api.env.basedn, + 'ipapermtargetfilter': {'(objectclass=*)'}, + 'ipapermbindruletype': 'anonymous', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'createtimestamp', 'modifytimestamp', + 'creatorsname', 'modifiersname', 'entryusn', + }, + }, 'System: Read IPA Masters': { 'replaces_global_anonymous_aci': True, 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), From mkosek at redhat.com Fri Sep 5 07:18:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 09:18:02 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140905070341.GU3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> <20140905070341.GU3593@redhat.com> Message-ID: <540963AA.7040601@redhat.com> On 09/05/2014 09:03 AM, Alexander Bokovoy wrote: > On Fri, 05 Sep 2014, Alexander Bokovoy wrote: >> On Thu, 04 Sep 2014, Martin Kosek wrote: >>> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >>>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> This adds managed read permissions to the compat tree. >>>>>>>> >>>>>>>> For users it grants anonymous access; authenticated users can read >>>>>>>> groups, hosts and netgroups. >>>>>>>> >>>>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>>>> Membership" is only granted to authenticated users by default, and the >>>>>>>> compat tree exposes memberuid. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>>>> >>>>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>>>> >>>>>>> >>>>>> >>>>>> Fixed patch attached. >>>>>> >>>>> >>>>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>>>> see if there are no reservations from Alexander or Rob. >>>> I think we need a bit more fixes. Here is ACL log for an anonymous >>>> request: >>>> >>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >>>> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>> Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>> Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>> anonymous: no >>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>> Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>> anonymous: no aci matched the subject by aci(27): aciname= >>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>> anonymous: no aci matched the subject by aci(27): aciname= >>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>> Configuration", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>> search on >>>> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >>>> by aci(38): aciname= "permission:System: Read User >>>> Compat Tree", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>> search on >>>> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>>> cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>> search on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>> anonymous: >>>> cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >>>> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >>>> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can >>>> manage >>>> any entry", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >>>> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >>>> Tree", acidn="dc=ipacloud,dc=test" >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >>>> anonymous: cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >>>> cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >>>> anonymous: cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >>>> anonymous: cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >>>> anonymous: cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >>>> anonymous: cached allow by aci(38) >>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>> anonymous: >>>> cached allow by aci(38) >>>> >>>> createTimestamp is operational attribute and is synthesized by >>>> slapi-nis, there is no problem allowing access to it. I think we can >>>> allow following operational attributes: >>>> >>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>> entryDN, hasSubordinates, numSubordinates >>> >>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>> for whole FreeIPA DIT. So this change is not so related to these patches. >>> >>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>> consider that a public information or juts audit-like information for DM only? >>> >>>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>>> run ipa-adtrust-install on this machine yet. >>> >>> I do not think that this attribute is written to cn=compat (did not see it in >>> config) - is it? >>> >>>> >>>> The same set should be allowed for primary tree. >>>> >>> >>> IMO this should be just one global permission/ACI, set for DIT root. >> >> I experimented a bit, by setting SSSD with a simple LDAP provider >> talking to a compat tree (with views enabled, but that doesn't change >> anything) and I think we need to move to ipabindpermruletype=anonymous >> or otherwise such setup will not work at all. Attached is my take at it >> on top of Petr's patchset. >> >> You can ignore views-related ACIs for time being. > Scratch that, it was older version with duplicate entries. > > Proper one is attached. > Thanks! Looks sane to me. We would just need to remove Views related ACIs for the 4.0.x version that we will need for today. Martin From dkupka at redhat.com Fri Sep 5 07:25:18 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 05 Sep 2014 09:25:18 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <54084B64.4090007@redhat.com> References: <53FDC788.2060603@redhat.com> <54072F2D.4020502@redhat.com> <540841FB.5090301@redhat.com> <54084B64.4090007@redhat.com> Message-ID: <5409655E.1030808@redhat.com> On 09/04/2014 01:22 PM, Jan Cholasta wrote: > Dne 4.9.2014 v 12:42 David Kupka napsal(a): >> On 09/03/2014 05:09 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 27.8.2014 v 13:56 David Kupka napsal(a): >>>> 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 >>> >>> 1) I think you can log realm in search() as part of the "Starting IPA >>> discovery ..." message instead of a separate message. >>> >>> >>> 2) Also, no need to log the realm twice in search(). >> I forget to remove some redundant debug prints. >>> >>> >>> 3) It looks like you forgot to un-indent some code in >>> ipadnssearchkrbkdc(). >>> >> Fixed, thanks. > > What I meant is that this: > > def ipadnssearchkrbkdc(self, domain=None): > kdc = None > > if not domain: > domain = self.domain > > kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, > break_on_first=False) > > if kdc: > kdc = ','.join(kdc) > else: > root_logger.debug("SRV record for KDC not found! > Domain: %s" % domain) > kdc = None > > return kdc > > should be this: > > def ipadnssearchkrbkdc(self, domain=None): > if not domain: > domain = self.domain > > kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, > break_on_first=False) > if kdc: > kdc = ','.join(kdc) > else: > root_logger.debug("SRV record for KDC not found! Domain: > %s" % domain) > kdc = None > > return kdc > > Isn't that right? > Oh, you're right, again :) Thanks. >>> >>> Honza >>> >> > > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0011-3-Allow-user-to-force-Kerberos-realm-during-installati.patch Type: text/x-patch Size: 4660 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 5 08:34:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 10:34:46 +0200 Subject: [Freeipa-devel] [PATCH 0119] Fix dnsrecord-mod, regression in 4.x In-Reply-To: <54088174.9030809@redhat.com> References: <54087382.5020107@redhat.com> <540878D7.5090107@redhat.com> <54087AED.7080904@redhat.com> <54088174.9030809@redhat.com> Message-ID: <540975A6.5020808@redhat.com> On 09/04/2014 05:12 PM, Jan Cholasta wrote: > Dne 4.9.2014 v 16:45 Martin Basti napsal(a): >> On 04/09/14 16:36, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 4.9.2014 v 16:13 Martin Basti napsal(a): >>>> Regression is caused by different output types for dnsrecord-mod and >>>> dnsrecord-del. >>>> dnsrecord-mod internally calls remove record, if there is no more >>>> records in owner name, which cause output validation error. >>>> >>>> >>>> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >>>> ipa: ERROR: an internal error has occurred >>>> >>>> ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => >>>> PrimaryKey.validate(): >>>> output['value']: need ; got >>> 'list'>: [] >>>> Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>>> 348, in wsgi_execute >>>> result = self.Command[name](*args, **options) >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>> 451, >>>> in __call__ >>>> self.validate_output(ret, options['version']) >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>> 944, >>>> in validate_output >>>> o.validate(self, value, version) >>>> File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, >>>> in validate >>>> types[0], type(value), value)) >>>> TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): >>>> output['value']: need ; got >>> 'list'>: [] >>>> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(>>> name ipa.example.>, , nsrecord=None, rights=False, >>>> structured=False, all=False, raw=False, version=u'2.102'): TypeError >>>> >>>> >>>> Patch attached. >>> >>> NACK, the assert needs to be inside the if, otherwise old clients will >>> fail on it. >>> >>> Honza >>> >> Thanks >> >> Updated patch attached >> >> > > Thanks, ACK. Pushed to: master: 62a255949377d4a6b3cc197462223b5b0495d18d ipa-4-0: 1dc9db49db895f130c68c12c316c8946944e70cf ipa-4-1: 9e8aed8e53b91605685cd050cfdc27c41112ceb8 -- Petr? From mkosek at redhat.com Fri Sep 5 08:43:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 10:43:55 +0200 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <54088197.80700@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> Message-ID: <540977CB.9050705@redhat.com> On 09/04/2014 05:13 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>> No longer request and install a cert for the IPA client machine. >>> >>> rob >> >> The original plan was to keep generating the certificate, but in >> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >> >> I'm fine with either approach. >> > > The cert has never been used and is now actively causing issues in > RHEL-7 with systemd and kickstart. It could be made optional, and move > the location, but IMHO its time has come. > > rob One change that Rob's patch also do is that from now on, certmonger would not be enabled and running by default on client machines. It would only be enabled on IPA server. I am still not confident about the resolution to just stop generating the certificate, I was leaning more towards making it optional + generating to better database as Honza proposed. Simo, Alexander, what is your take on this? Thanks, Martin From mkosek at redhat.com Fri Sep 5 08:47:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 10:47:36 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54087AB4.3090109@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140904141027.GQ3593@redhat.com> <54087967.1030204@redhat.com> <54087AB4.3090109@redhat.com> Message-ID: <540978A8.9070609@redhat.com> On 09/04/2014 04:44 PM, Ludwig Krispenz wrote: > > On 09/04/2014 04:38 PM, Martin Kosek wrote: >> On 09/04/2014 04:10 PM, Alexander Bokovoy wrote: >> ... >>>>> createTimestamp is operational attribute and is synthesized by >>>>> slapi-nis, there is no problem allowing access to it. I think we can >>>>> allow following operational attributes: >>>>> >>>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>>> entryDN, hasSubordinates, numSubordinates >>>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>>> for whole FreeIPA DIT. So this change is not so related to these patches. >>>> >>>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>>> consider that a public information or juts audit-like information for DM only? >>> They are standard features of LDAP servers. RFC 4512 states: >>> ============================================================================= >>> 3.4 Operational attributes >>> ... >>> Servers SHOULD maintain the 'creatorsName', 'createTimestamp', >>> 'modifiersName', and 'modifyTimestamp' attributes for all entries of the >>> DIT. >>> ============================================================================= >>> >>> This is, again, a question of policy. Active Directory forbids anonymous >>> access to the tree; so they always expose these attributes to >>> authenticated users only. If we allow anonymous access, we should allow >>> these attributes too. >> Well, DS *does* maintain the attributes - question is whether we want to show >> them to anonymous/authenticated people or just the DM :) > if you want to show them depends if it is useful or sensitive. > I don't know why an anonymous user would need access to them. > Are they sensitive ? Well, at least they expose a DN which has rights to > create and modify entries and could be used trying to get more access Alexander, should we then show just + 'createtimestamp', 'modifytimestamp', 'entryusn', to authenticated users? I do not think that modifiers/creatorsDN is something that anonymous user need to see by default. Admin can allow it if he wants, but IMO it should not be the default. Martin From mkosek at redhat.com Fri Sep 5 08:59:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 10:59:14 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <5408647F.2040705@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> <54083F96.50509@redhat.com> <54084AA8.3020103@redhat.com> <54084F99.3060409@redhat.com> <5408647F.2040705@redhat.com> Message-ID: <54097B62.1080307@redhat.com> On 09/04/2014 03:09 PM, Jan Cholasta wrote: > Dne 4.9.2014 v 13:40 Martin Kosek napsal(a): >> On 09/04/2014 01:19 PM, Jan Cholasta wrote: >>> Dne 4.9.2014 v 12:31 David Kupka napsal(a): >>>> On 09/03/2014 04:45 PM, Jan Cholasta wrote: >>>>> Dne 3.9.2014 v 16:25 David Kupka napsal(a): >>>>>> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>>>>>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>>>>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>>>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>>>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>>>>>> >>>>>>>> >>>>>>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>>>>>> ipa-4-0. >>>>>>> >>>>>>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>>>>>> patch. This is wrong: >>>>>>> >>>>>>> for request in requests: >>>>>>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>>>>>> = request >>>>>>> criteria = { >>>>>>> 'cert-database': nss_dir, >>>>>>> 'cert-nickname': nickname, >>>>>>> 'ca-name': ca_name, >>>>>>> 'template-profile': profile, >>>>>>> } >>>>>>> >>>>>>> It should be: >>>>>>> >>>>>>> for nss_dir, nickname, ca_name, pre_command, post_command in >>>>>>> requests: >>>>>>> criteria = { >>>>>>> 'cert-database': nss_dir, >>>>>>> 'cert-nickname': nickname, >>>>>>> 'ca-name': ca_name, >>>>>>> } >>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> You removed the comments, but left the attributes there. You should >>>>>>>>> remove them as well, they are not necessary, as you set them all in >>>>>>>>> __init__(). >>>>>>>>> >>>>>>>> >>>>>>>> Removed. >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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(). >>>>>>> >>>>>>> You no longer check if the profile argument is set in modify() - either >>>>>>> re-introduce the check, or remove the default value of the argument to >>>>>>> make it mandatory. >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> OK, no need to include the TODO comment though. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>>>>>> API >>>>>>>>> to request the host certificate, but since we plan on stopping doing >>>>>>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you >>>>>>>>> don't >>>>>>>>> have to do anything about it. >>>>>>>> >>>>>>>> Ok. I will leave it on you since you are owner of this ticket. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>>>>>> tuples >>>>>>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>>>>>> which >>>>>>>>> makes them fail. >>>>>>>> >>>>>>>> Good point, fixed. >>>>>>> >>>>>>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>>>>>> should be fixed as well. >>>>>>> >>>>>> I need to check my patches more carefully, thank for the patience. >>>>>> >>>>> >>>>> And I need to do my reviews more carefully: in ca_renewal_master, the >>>>> "cert-storage" criterium should in fact be "cert-database". >>>>> >>>>> ACK after you fix the above. >>>>> >>>> Fixed together with other issues discussed on IRC. Please review it one >>>> more time. >>> >>> Thanks, ACK. >>> >> >> Thanks! But as I just found out, neither patch applies to ipa-4-1 branch. And >> as the merge is not straightforward, I would leave the backport rather either >> to Jan or David. >> >> Martin >> > > Here. > Thanks, I just had to remove one pylint bug: ipaserver/install/cainstance.py:324: [E0601(used-before-assignment), stop_tracking_certificates] Using variable 'e' before assignment) Pushed to master, ipa-4-1, ipa-4-0. Martin From abokovoy at redhat.com Fri Sep 5 09:07:24 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 12:07:24 +0300 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <540977CB.9050705@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> Message-ID: <20140905090724.GV3593@redhat.com> On Fri, 05 Sep 2014, Martin Kosek wrote: >On 09/04/2014 05:13 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>>> No longer request and install a cert for the IPA client machine. >>>> >>>> rob >>> >>> The original plan was to keep generating the certificate, but in >>> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >>> >>> I'm fine with either approach. >>> >> >> The cert has never been used and is now actively causing issues in >> RHEL-7 with systemd and kickstart. It could be made optional, and move >> the location, but IMHO its time has come. >> >> rob > >One change that Rob's patch also do is that from now on, certmonger would not >be enabled and running by default on client machines. It would only be enabled >on IPA server. > >I am still not confident about the resolution to just stop generating the >certificate, I was leaning more towards making it optional + generating to >better database as Honza proposed. > >Simo, Alexander, what is your take on this? I'm fine with making it optional. However, on client machine upgrades do not stop and disable certmonger if it is tracking more than just the host certificate. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Sep 5 09:12:41 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 12:12:41 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <540978A8.9070609@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140904141027.GQ3593@redhat.com> <54087967.1030204@redhat.com> <54087AB4.3090109@redhat.com> <540978A8.9070609@redhat.com> Message-ID: <20140905091241.GW3593@redhat.com> On Fri, 05 Sep 2014, Martin Kosek wrote: >On 09/04/2014 04:44 PM, Ludwig Krispenz wrote: >> >> On 09/04/2014 04:38 PM, Martin Kosek wrote: >>> On 09/04/2014 04:10 PM, Alexander Bokovoy wrote: >>> ... >>>>>> createTimestamp is operational attribute and is synthesized by >>>>>> slapi-nis, there is no problem allowing access to it. I think we can >>>>>> allow following operational attributes: >>>>>> >>>>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>>>> entryDN, hasSubordinates, numSubordinates >>>>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>>>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>>>> for whole FreeIPA DIT. So this change is not so related to these patches. >>>>> >>>>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>>>> consider that a public information or juts audit-like information for DM only? >>>> They are standard features of LDAP servers. RFC 4512 states: >>>> ============================================================================= >>>> 3.4 Operational attributes >>>> ... >>>> Servers SHOULD maintain the 'creatorsName', 'createTimestamp', >>>> 'modifiersName', and 'modifyTimestamp' attributes for all entries of the >>>> DIT. >>>> ============================================================================= >>>> >>>> This is, again, a question of policy. Active Directory forbids anonymous >>>> access to the tree; so they always expose these attributes to >>>> authenticated users only. If we allow anonymous access, we should allow >>>> these attributes too. >>> Well, DS *does* maintain the attributes - question is whether we want to show >>> them to anonymous/authenticated people or just the DM :) >> if you want to show them depends if it is useful or sensitive. >> I don't know why an anonymous user would need access to them. >> Are they sensitive ? Well, at least they expose a DN which has rights to >> create and modify entries and could be used trying to get more access > >Alexander, should we then show just >+ 'createtimestamp', 'modifytimestamp', 'entryusn', >to authenticated users? I do not think that modifiers/creatorsDN is something >that anonymous user need to see by default. createtimestamp, modifytimestamp, and entryusn are all needed for sssd LDAP provider. Not allowing them for anonymous will make legacy SSSD performance suboptimal. modifier/creator DNs can be given out only to authenticated users. -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 5 10:05:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 12:05:25 +0200 Subject: [Freeipa-devel] [PATCH] 318 Backup CS.cfg before modifying it In-Reply-To: <5407434B.5030104@redhat.com> References: <5407434B.5030104@redhat.com> Message-ID: <54098AE5.2040508@redhat.com> On 09/03/2014 06:35 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > ACK Neither patch applies to 4.1, though. Could you send a version for that as well? -- Petr? From mkosek at redhat.com Fri Sep 5 10:13:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 12:13:56 +0200 Subject: [Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation In-Reply-To: <540848D1.6090601@redhat.com> References: <53F4DA40.7060507@redhat.com> <5405DF33.9050108@redhat.com> <540728BE.6050707@redhat.com> <54083507.7040505@redhat.com> <540846D8.5030805@redhat.com> <540848D1.6090601@redhat.com> Message-ID: <54098CE4.2070401@redhat.com> On 09/04/2014 01:11 PM, Petr Spacek wrote: > On 4.9.2014 13:02, Martin Basti wrote: >> On 04/09/14 11:46, Petr Spacek wrote: >>> On 3.9.2014 16:42, Martin Basti wrote: >>>> On 02/09/14 17:16, Petr Spacek wrote: >>>>> On 20.8.2014 19:26, Martin Basti wrote: >>>>>> Part of DNSSEC >>>>>> Patches attached. >>>>> >>>>> NACK >>>>> >>>>> # ipa dnsrecord-add ipa.example. ds '--ds-rec=1 2 3 4' >>>>> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS >>>>> record (RFC 4529, section 4.6) >>>>> >>>>> RFC number is incorrect. IMHO it should also reference 'RFC 4035 section >>>>> 2.4'. >>>>> >>>>> Also, there is one hole: >>>>> Current code allows you to add DS RR to existing NS and then to remove NS. >>>>> >>>>> Let me know if adding a check to -del is too hard, maybe we can live without >>>>> it... >>>>> >>>> dnsrecord-del validation added >>>> >>>> Updated patch attached >>>> >>>> Required in ipa 4.1 but this could be pushed to 4.0.x too >>> >>> It almost works ... almost. I'm not sure if the problem is in your patch or >>> in existing code: >>> >>> [root at vm-035 git]# ipa dnsrecord-add ipa.example ds --ds-rec='1 2 3 4' >>> Record name: ds >>> DS record: 1 2 3 4 >>> NS record: vm-035.idm.lab.eng.brq.redhat.com. >>> >>> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >>> ipa: ERROR: invalid 'dsrecord': DS record requires to coexist with an NS >>> record (RFC 4592 section 4.6, RFC 4035 section 2.4) >>> >>> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ds-rec= >>> Record name: ds >>> NS record: vm-035.idm.lab.eng.brq.redhat.com. >>> >>> [root at vm-035 git]# ipa dnsrecord-mod ipa.example ds --ns-rec= >>> ipa: ERROR: an internal error has occurred >>> >>> # tail /var/log/httpd/error_log >>> >>> ipa: ERROR: non-public: TypeError: dnsrecord_mod.validate_output() => >>> PrimaryKey.validate(): >>> output['value']: need ; got >> 'list'>: [] >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 348, >>> in wsgi_execute >>> result = self.Command[name](*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 451, in >>> __call__ >>> self.validate_output(ret, options['version']) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 944, in >>> validate_output >>> o.validate(self, value, version) >>> File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 126, in >>> validate >>> types[0], type(value), value)) >>> TypeError: dnsrecord_mod.validate_output() => PrimaryKey.validate(): >>> output['value']: need ; got >> 'list'>: [] >>> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsrecord_mod(>> ipa.example.>, , nsrecord=None, rights=False, structured=False, >>> all=False, raw=False, version=u'2.102'): TypeError >>> >> This bug is not related with the patches. >> Error is raised when you try to delete the last record in RRset using >> dnsrecord-mod --any-rec="" > > Okay, functional ACK. Please send a separate patch for this problem or at least > open a ticket and describe what is wrong with it. > > It can be pushed if Python gurus are okay with the code. > > Thank you! > Ok, LGTM. Pushed to master, ipa-4-1. Martin From mkosek at redhat.com Fri Sep 5 10:14:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 12:14:01 +0200 Subject: [Freeipa-devel] [PATCHES 0111-0113] Fix NS record coexistence validation In-Reply-To: <54084915.9090103@redhat.com> References: <53F62A8D.30303@redhat.com> <5405E46F.6040703@redhat.com> <5406EDE0.3000806@redhat.com> <54072AFB.6060500@redhat.com> <54084915.9090103@redhat.com> Message-ID: <54098CE9.8050908@redhat.com> On 09/04/2014 01:12 PM, Petr Spacek wrote: > On 3.9.2014 16:51, Martin Basti wrote: >> On 03/09/14 12:30, Martin Kosek wrote: >>> On 09/02/2014 05:38 PM, Petr Spacek wrote: >>>> On 21.8.2014 19:21, Martin Basti wrote: >>>>> 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. >>>> Functional ACK. It can be pushed if Python gurus don't see any problem. >>>> >>> I think the patches will need a rebase before push, I cannot apply them to my >>> tree. The Python part itself looked good to me. >>> >>> Martin >>> >> Rebased patch attached, due changes in freeipa-mbasti-0109, >> patches mbasti-0109.2, mbasti-0110.2 are required. > > Rebased versions work for me. Functional ACK. > Ok, LGTM. Pushed to master, ipa-4-1. Martin From dkupka at redhat.com Fri Sep 5 10:17:17 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 05 Sep 2014 12:17:17 +0200 Subject: [Freeipa-devel] [PATCH] Do not restart apache server when not necessary. Message-ID: <54098DAD.4000902@redhat.com> https://fedorahosted.org/freeipa/ticket/4352 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0013-Do-not-restart-apache-server-when-not-necessary.patch Type: text/x-patch Size: 891 bytes Desc: not available URL: From pspacek at redhat.com Fri Sep 5 10:21:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 12:21:38 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <54070C36.80304@redhat.com> References: <53F4C0A5.6030408@redhat.com> <53F59524.3040506@redhat.com> <53F5B4C9.3060708@redhat.com> <5405E35A.2030801@redhat.com> <54070C36.80304@redhat.com> Message-ID: <54098EB2.4040100@redhat.com> On 3.9.2014 14:40, Martin Basti wrote: > On 02/09/14 17:33, Petr Spacek wrote: >> On 21.8.2014 10:58, Martin Basti wrote: >>> 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. >>> >> >> # ipa dnsrecord-add ipa.example. '*' --ns-rec='ns' >> ipa: ERROR: invalid 'idnsname': owner of DNAME, DS, NS records should not be >> a wildcard domain name (RFC 4592) >> >> It would be nice to have more specific reference to RFC: 'RFC 4592 section 4'. >> >> CondACK: It can be pushed if you amend the error message. >> > Updated patch attached. > Please push to branches: ipa 4.0.x, 4.1, master The error message seems okay, it can be pushed. -- Petr^2 Spacek From pviktori at redhat.com Fri Sep 5 10:30:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 12:30:17 +0200 Subject: [Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation In-Reply-To: <54098EB2.4040100@redhat.com> References: <53F4C0A5.6030408@redhat.com> <53F59524.3040506@redhat.com> <53F5B4C9.3060708@redhat.com> <5405E35A.2030801@redhat.com> <54070C36.80304@redhat.com> <54098EB2.4040100@redhat.com> Message-ID: <540990B9.8010406@redhat.com> On 09/05/2014 12:21 PM, Petr Spacek wrote: > On 3.9.2014 14:40, Martin Basti wrote: >> On 02/09/14 17:33, Petr Spacek wrote: >>> On 21.8.2014 10:58, Martin Basti wrote: >>>> 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. >>>> >>> >>> # ipa dnsrecord-add ipa.example. '*' --ns-rec='ns' >>> ipa: ERROR: invalid 'idnsname': owner of DNAME, DS, NS records should >>> not be >>> a wildcard domain name (RFC 4592) >>> >>> It would be nice to have more specific reference to RFC: 'RFC 4592 >>> section 4'. >>> >>> CondACK: It can be pushed if you amend the error message. >>> >> Updated patch attached. >> Please push to branches: ipa 4.0.x, 4.1, master > > The error message seems okay, it can be pushed. Pushed to: master: 028b3d1009122e01f32710463a96cacddd4d26c1 ipa-4-0: 3c6f83e41de097a23c4839c2d14b091c7bacc562 ipa-4-1: 031677c80b1b9a2706186421e651c6132b14e6e2 -- Petr? From mkosek at redhat.com Fri Sep 5 10:35:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 12:35:28 +0200 Subject: [Freeipa-devel] Fwd: [freeipa] update to Java/8 In-Reply-To: <20140902174113.7CF5532485@pkgs01.phx2.fedoraproject.org> References: <20140902174113.7CF5532485@pkgs01.phx2.fedoraproject.org> Message-ID: <540991F0.1060706@redhat.com> Petr, why do we require java-1.7.0-openjdk in BuildRequires anyway? Shouldn't rhino be enough? -------- Original Message -------- Subject: [freeipa] update to Java/8 Date: Tue, 2 Sep 2014 17:41:13 +0000 (UTC) From: P?draig Brady To: freeipa-owner at fedoraproject.org, scm-commits at lists.fedoraproject.org commit c1d3c76c37530d0608f710f986be1614d2ed848b Author: P?draig Brady

Date: Tue Sep 2 18:40:05 2014 +0100 update to Java/8 Java/7 is no longer available in rawhide, so update to allow rebuilds to proceed. freeipa.spec | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/freeipa.spec b/freeipa.spec index f871260..2f8eac0 100644 --- a/freeipa.spec +++ b/freeipa.spec @@ -67,7 +67,7 @@ BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel -BuildRequires: java-1.7.0-openjdk +BuildRequires: java-1.8.0-openjdk BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd From pspacek at redhat.com Fri Sep 5 10:43:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 12:43:27 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <540893D9.2010206@redhat.com> References: <54088B87.2050300@redhat.com> <540893D9.2010206@redhat.com> Message-ID: <540993CF.7050404@redhat.com> On 4.9.2014 18:31, Martin Basti wrote: > On 04/09/14 17:55, Petr Spacek wrote: >> Hello, >> >> Create temporary directories with ug=rwx,o= permissions. >> >> Zero group permissions do not allow to use POSIX ACLs which is >> undesirable. >> > NACK > It creates drwxr-x--- permissions (umask problem) Thank you for catching this. This version of the patch should fix the problem. It is not very nice but I don't see any better solution. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0282-2-Create-temporary-directories-with-ug-rwx-o-permissio.patch Type: text/x-patch Size: 1843 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 5 11:08:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 05 Sep 2014 13:08:48 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <540993CF.7050404@redhat.com> References: <54088B87.2050300@redhat.com> <540893D9.2010206@redhat.com> <540993CF.7050404@redhat.com> Message-ID: <540999C0.5020404@redhat.com> On 05/09/14 12:43, Petr Spacek wrote: > On 4.9.2014 18:31, Martin Basti wrote: >> On 04/09/14 17:55, Petr Spacek wrote: >>> Hello, >>> >>> Create temporary directories with ug=rwx,o= permissions. >>> >>> Zero group permissions do not allow to use POSIX ACLs which is >>> undesirable. >>> >> NACK >> It creates drwxr-x--- permissions (umask problem) > > Thank you for catching this. This version of the patch should fix the > problem. It is not very nice but I don't see any better solution. > It works! ACK with * * Patch doesn't change permissions for existing directories, but because patch pspacek-280, new version of bind plugin will create new file structure under new 'master' directory, so there is no problem with old directories with old permissions, isn't it? -- Martin Basti From pviktori at redhat.com Fri Sep 5 11:17:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 13:17:01 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <540963AA.7040601@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> <20140905070341.GU3593@redhat.com> <540963AA.7040601@redhat.com> Message-ID: <54099BAD.3000508@redhat.com> On 09/05/2014 09:18 AM, Martin Kosek wrote: > On 09/05/2014 09:03 AM, Alexander Bokovoy wrote: >> On Fri, 05 Sep 2014, Alexander Bokovoy wrote: >>> On Thu, 04 Sep 2014, Martin Kosek wrote: >>>> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >>>>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>>>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>>>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> This adds managed read permissions to the compat tree. >>>>>>>>> >>>>>>>>> For users it grants anonymous access; authenticated users can read >>>>>>>>> groups, hosts and netgroups. >>>>>>>>> >>>>>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>>>>> Membership" is only granted to authenticated users by default, and the >>>>>>>>> compat tree exposes memberuid. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>>>>> >>>>>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Fixed patch attached. >>>>>>> >>>>>> >>>>>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>>>>> see if there are no reservations from Alexander or Rob. >>>>> I think we need a bit more fixes. Here is ACL log for an anonymous >>>>> request: >>>>> >>>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >>>>> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >>>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>> anonymous: no >>>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>> anonymous: no aci matched the subject by aci(27): aciname= >>>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>> anonymous: no aci matched the subject by aci(27): aciname= >>>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>> search on >>>>> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >>>>> by aci(38): aciname= "permission:System: Read User >>>>> Compat Tree", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>> search on >>>>> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>>>> cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>> search on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>> anonymous: >>>>> cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >>>>> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >>>>> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can >>>>> manage >>>>> any entry", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >>>>> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >>>>> Tree", acidn="dc=ipacloud,dc=test" >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >>>>> anonymous: cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >>>>> cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >>>>> anonymous: cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >>>>> anonymous: cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >>>>> anonymous: cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >>>>> anonymous: cached allow by aci(38) >>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>> anonymous: >>>>> cached allow by aci(38) >>>>> >>>>> createTimestamp is operational attribute and is synthesized by >>>>> slapi-nis, there is no problem allowing access to it. I think we can >>>>> allow following operational attributes: >>>>> >>>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>>> entryDN, hasSubordinates, numSubordinates >>>> >>>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>>> for whole FreeIPA DIT. So this change is not so related to these patches. >>>> >>>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>>> consider that a public information or juts audit-like information for DM only? >>>> >>>>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>>>> run ipa-adtrust-install on this machine yet. >>>> >>>> I do not think that this attribute is written to cn=compat (did not see it in >>>> config) - is it? >>>> >>>>> >>>>> The same set should be allowed for primary tree. >>>>> >>>> >>>> IMO this should be just one global permission/ACI, set for DIT root. >>> >>> I experimented a bit, by setting SSSD with a simple LDAP provider >>> talking to a compat tree (with views enabled, but that doesn't change >>> anything) and I think we need to move to ipabindpermruletype=anonymous >>> or otherwise such setup will not work at all. Attached is my take at it >>> on top of Petr's patchset. >>> >>> You can ignore views-related ACIs for time being. >> Scratch that, it was older version with duplicate entries. >> >> Proper one is attached. >> > > Thanks! Looks sane to me. We would just need to remove Views related ACIs for > the 4.0.x version that we will need for today. Thanks indeed! Here is the patched patch. The Read Operational Attributes permission is split for createtimestamp/modifytimestamp/entryusn (anonymous) and creatorsname/modifiersname (authenticated). Only admins can read the cn=compat entry itself. I don't think that's an issue though. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0640.3-Add-managed-read-permissions-for-compat-tree-and-ope.patch Type: text/x-patch Size: 18263 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 5 11:24:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 13:24:26 +0200 Subject: [Freeipa-devel] [PATCH] Do not restart apache server when not necessary. In-Reply-To: <54098DAD.4000902@redhat.com> References: <54098DAD.4000902@redhat.com> Message-ID: <54099D6A.2020503@redhat.com> On 09/05/2014 12:17 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4352 Thanks, ACK. Pushed to master, ipa-4-1, ipa-4-0. Martin From abokovoy at redhat.com Fri Sep 5 11:34:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 14:34:30 +0300 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <54099BAD.3000508@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> <20140905070341.GU3593@redhat.com> <540963AA.7040601@redhat.com> <54099BAD.3000508@redhat.com> Message-ID: <20140905113430.GY3593@redhat.com> On Fri, 05 Sep 2014, Petr Viktorin wrote: > On 09/05/2014 09:18 AM, Martin Kosek wrote: >> On 09/05/2014 09:03 AM, Alexander Bokovoy wrote: >>> On Fri, 05 Sep 2014, Alexander Bokovoy wrote: >>>> On Thu, 04 Sep 2014, Martin Kosek wrote: >>>>> On 09/04/2014 02:40 PM, Alexander Bokovoy wrote: >>>>>> On Wed, 03 Sep 2014, Martin Kosek wrote: >>>>>>> On 09/03/2014 03:15 PM, Petr Viktorin wrote: >>>>>>>> On 09/03/2014 02:27 PM, Petr Viktorin wrote: >>>>>>>>> On 09/03/2014 01:27 PM, Petr Viktorin wrote: >>>>>>>>>> Hello, >>>>>>>>>> This adds managed read permissions to the compat tree. >>>>>>>>>> >>>>>>>>>> For users it grants anonymous access; authenticated users can read >>>>>>>>>> groups, hosts and netgroups. >>>>>>>>>> >>>>>>>>>> I'm unsure if this is what we want to do for groups, but "Read Group >>>>>>>>>> Membership" is only granted to authenticated users by default, and the >>>>>>>>>> compat tree exposes memberuid. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4521 >>>>>>>>> >>>>>>>>> Self-NACK, there's a typo (though I could swear I tested this :/) >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Fixed patch attached. >>>>>>>> >>>>>>> >>>>>>> I tested and it looks and works OK, ACK from me. We can wait till tomorrow to >>>>>>> see if there are no reservations from Alexander or Rob. >>>>>> I think we need a bit more fixes. Here is ACL log for an anonymous >>>>>> request: >>>>>> >>>>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - searching from >>>>>> "cn=compat,dc=ipacloud,dc=test" for "(uid=admin)" with scope 2 (sub) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=computers,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no >>>>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=ab,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>>> anonymous: no >>>>>> aci matched the subject by aci(27): aciname="permission:System: Read DNS >>>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=editors,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>>> anonymous: no aci matched the subject by aci(27): aciname= >>>>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=admins,cn=groups,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>>> anonymous: no aci matched the subject by aci(27): aciname= >>>>>> "permission:System: Read DNS Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny search on >>>>>> entry(cn=ng,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: no aci >>>>>> matched the subject by aci(27): aciname="permission:System: Read DNS >>>>>> Configuration", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>>> search on >>>>>> entry(cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: allowed >>>>>> by aci(38): aciname= "permission:System: Read User >>>>>> Compat Tree", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>>> search on >>>>>> entry(uid=ab,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to anonymous: >>>>>> cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow >>>>>> search on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>>> anonymous: >>>>>> cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] schema-compat-plugin - search matched >>>>>> uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - #### conn=18 op=1 binddn="" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Deny read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(createTimestamp) >>>>>> to anonymous: no aci matched the subject by aci(18): aciname= "Admin can >>>>>> manage >>>>>> any entry", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(objectClass) to >>>>>> anonymous: allowed by aci(38): aciname= "permission:System: Read User Compat >>>>>> Tree", acidn="dc=ipacloud,dc=test" >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gecos) to >>>>>> anonymous: cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(cn) to anonymous: >>>>>> cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uidNumber) to >>>>>> anonymous: cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(gidNumber) to >>>>>> anonymous: cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(loginShell) to >>>>>> anonymous: cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(homeDirectory) to >>>>>> anonymous: cached allow by aci(38) >>>>>> [04/Sep/2014:15:28:49 +0300] NSACLPlugin - conn=18 op=1 (main): Allow read on >>>>>> entry(uid=admin,cn=users,cn=compat,dc=ipacloud,dc=test).attr(uid) to >>>>>> anonymous: >>>>>> cached allow by aci(38) >>>>>> >>>>>> createTimestamp is operational attribute and is synthesized by >>>>>> slapi-nis, there is no problem allowing access to it. I think we can >>>>>> allow following operational attributes: >>>>>> >>>>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, >>>>>> entryDN, hasSubordinates, numSubordinates >>>>> >>>>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example >>>>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed >>>>> for whole FreeIPA DIT. So this change is not so related to these patches. >>>>> >>>>> Do we also want to expose attributes like creatorsName/modifiersName? Do we >>>>> consider that a public information or juts audit-like information for DM only? >>>>> >>>>>> Finally, ipaNTSecurityIdentifier may be allowed to access too, I didn't >>>>>> run ipa-adtrust-install on this machine yet. >>>>> >>>>> I do not think that this attribute is written to cn=compat (did not see it in >>>>> config) - is it? >>>>> >>>>>> >>>>>> The same set should be allowed for primary tree. >>>>>> >>>>> >>>>> IMO this should be just one global permission/ACI, set for DIT root. >>>> >>>> I experimented a bit, by setting SSSD with a simple LDAP provider >>>> talking to a compat tree (with views enabled, but that doesn't change >>>> anything) and I think we need to move to ipabindpermruletype=anonymous >>>> or otherwise such setup will not work at all. Attached is my take at it >>>> on top of Petr's patchset. >>>> >>>> You can ignore views-related ACIs for time being. >>> Scratch that, it was older version with duplicate entries. >>> >>> Proper one is attached. >>> >> >> Thanks! Looks sane to me. We would just need to remove Views related ACIs for >> the 4.0.x version that we will need for today. > > Thanks indeed! > > Here is the patched patch. The Read Operational Attributes permission is > split for createtimestamp/modifytimestamp/entryusn (anonymous) and > creatorsname/modifiersname (authenticated). Thanks! ACK. > > Only admins can read the cn=compat entry itself. I don't think that's an > issue though. It is an empty virtual entry that doesn't exist anywhere and is synthesized by slapi-nis on each request. -- / Alexander Bokovoy From jcholast at redhat.com Fri Sep 5 11:47:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 05 Sep 2014 13:47:09 +0200 Subject: [Freeipa-devel] [PATCH] 318 Backup CS.cfg before modifying it In-Reply-To: <54098AE5.2040508@redhat.com> References: <5407434B.5030104@redhat.com> <54098AE5.2040508@redhat.com> Message-ID: <5409A2BD.8070806@redhat.com> Dne 5.9.2014 v 12:05 Petr Viktorin napsal(a): > On 09/03/2014 06:35 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > ACK > Neither patch applies to 4.1, though. Could you send a version for that > as well? > > Sure. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-318-Backup-CS.cfg-before-modifying-it-ipa-4-1.patch Type: text/x-patch Size: 3257 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 5 11:51:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 13:51:47 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140905113430.GY3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> <20140905070341.GU3593@redhat.com> <540963AA.7040601@redhat.com> <54099BAD.3000508@redhat.com> <20140905113430.GY3593@redhat.com> Message-ID: <5409A3D3.308@redhat.com> On 09/05/2014 01:34 PM, Alexander Bokovoy wrote: > On Fri, 05 Sep 2014, Petr Viktorin wrote: >> On 09/05/2014 09:18 AM, Martin Kosek wrote: ... >>> Thanks! Looks sane to me. We would just need to remove Views related >>> ACIs for >>> the 4.0.x version that we will need for today. >> >> Thanks indeed! >> >> Here is the patched patch. The Read Operational Attributes permission >> is split for createtimestamp/modifytimestamp/entryusn (anonymous) and >> creatorsname/modifiersname (authenticated). > Thanks! ACK. Pushed to: master: 418ce870bfbe13cea694a7b862cafe35c703f660 ipa-4-0: 3e2c86aeabbd2e3c54ad73a40803ef2bf5b0cb17 ipa-4-1: 9bcd88589e30d31d3f533cd42d2f816ef01b07c7 >> Only admins can read the cn=compat entry itself. I don't think that's >> an issue though. > It is an empty virtual entry that doesn't exist anywhere and is > synthesized by slapi-nis on each request. As with most containers, it's not very interesting, but if it's hidden its contents won't be listed in GUI browsers. In the compat tree that's not much of an issue, hopefully. -- Petr? From pviktori at redhat.com Fri Sep 5 12:03:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 14:03:38 +0200 Subject: [Freeipa-devel] [PATCH] Make CA-less ipa-server-install option --root-ca-file optional In-Reply-To: <53E39F3E.3000007@redhat.com> References: <53E09611.3030903@redhat.com> <53E1DC6B.5030003@redhat.com> <53E39F3E.3000007@redhat.com> Message-ID: <5409A69A.8070807@redhat.com> On 08/07/2014 05:46 PM, Petr Viktorin wrote: > 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! Pushed to: master: 6ad8c464a43260f8f58dc262f841c35be35b57b5 ipa-4-0: 7c690d7e1238133677e49236595eb24483876ef8 ipa-4-1: be6568234002165fe11dd55407f8eb8e9b357790 >> 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 jcholast at redhat.com Fri Sep 5 12:44:55 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 05 Sep 2014 14:44:55 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <5409655E.1030808@redhat.com> References: <53FDC788.2060603@redhat.com> <54072F2D.4020502@redhat.com> <540841FB.5090301@redhat.com> <54084B64.4090007@redhat.com> <5409655E.1030808@redhat.com> Message-ID: <5409B047.2070205@redhat.com> Dne 5.9.2014 v 09:25 David Kupka napsal(a): > On 09/04/2014 01:22 PM, Jan Cholasta wrote: >> Dne 4.9.2014 v 12:42 David Kupka napsal(a): >>> On 09/03/2014 05:09 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 27.8.2014 v 13:56 David Kupka napsal(a): >>>>> 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 >>>> >>>> 1) I think you can log realm in search() as part of the "Starting IPA >>>> discovery ..." message instead of a separate message. >>>> >>>> >>>> 2) Also, no need to log the realm twice in search(). >>> I forget to remove some redundant debug prints. >>>> >>>> >>>> 3) It looks like you forgot to un-indent some code in >>>> ipadnssearchkrbkdc(). >>>> >>> Fixed, thanks. >> >> What I meant is that this: >> >> def ipadnssearchkrbkdc(self, domain=None): >> kdc = None >> >> if not domain: >> domain = self.domain >> >> kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, >> break_on_first=False) >> >> if kdc: >> kdc = ','.join(kdc) >> else: >> root_logger.debug("SRV record for KDC not found! >> Domain: %s" % domain) >> kdc = None >> >> return kdc >> >> should be this: >> >> def ipadnssearchkrbkdc(self, domain=None): >> if not domain: >> domain = self.domain >> >> kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, >> break_on_first=False) >> if kdc: >> kdc = ','.join(kdc) >> else: >> root_logger.debug("SRV record for KDC not found! Domain: >> %s" % domain) >> kdc = None >> >> return kdc >> >> Isn't that right? >> > > Oh, you're right, again :) Thanks. >>>> >>>> Honza >>>> >>> >> >> > ACK. -- Jan Cholasta From ssorce at redhat.com Fri Sep 5 12:49:13 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 05 Sep 2014 08:49:13 -0400 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <540977CB.9050705@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> Message-ID: <1409921353.8703.62.camel@willson.usersys.redhat.com> On Fri, 2014-09-05 at 10:43 +0200, Martin Kosek wrote: > On 09/04/2014 05:13 PM, Rob Crittenden wrote: > > Jan Cholasta wrote: > >> Hi, > >> > >> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): > >>> No longer request and install a cert for the IPA client machine. > >>> > >>> rob > >> > >> The original plan was to keep generating the certificate, but in > >> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). > >> > >> I'm fine with either approach. > >> > > > > The cert has never been used and is now actively causing issues in > > RHEL-7 with systemd and kickstart. It could be made optional, and move > > the location, but IMHO its time has come. > > > > rob > > One change that Rob's patch also do is that from now on, certmonger would not > be enabled and running by default on client machines. It would only be enabled > on IPA server. > > I am still not confident about the resolution to just stop generating the > certificate, I was leaning more towards making it optional + generating to > better database as Honza proposed. > > Simo, Alexander, what is your take on this? I'm with Rob, do not eanble and fetch certs we are not going to sue, this will also make the list of certs in the server more relevant. Simo. From ssorce at redhat.com Fri Sep 5 12:50:41 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 05 Sep 2014 08:50:41 -0400 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <20140905091241.GW3593@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140904141027.GQ3593@redhat.com> <54087967.1030204@redhat.com> <54087AB4.3090109@redhat.com> <540978A8.9070609@redhat.com> <20140905091241.GW3593@redhat.com> Message-ID: <1409921441.8703.63.camel@willson.usersys.redhat.com> On Fri, 2014-09-05 at 12:12 +0300, Alexander Bokovoy wrote: > On Fri, 05 Sep 2014, Martin Kosek wrote: > >On 09/04/2014 04:44 PM, Ludwig Krispenz wrote: > >> > >> On 09/04/2014 04:38 PM, Martin Kosek wrote: > >>> On 09/04/2014 04:10 PM, Alexander Bokovoy wrote: > >>> ... > >>>>>> createTimestamp is operational attribute and is synthesized by > >>>>>> slapi-nis, there is no problem allowing access to it. I think we can > >>>>>> allow following operational attributes: > >>>>>> > >>>>>> createTimestamp, modifyTimestamp, entryUSN, creatorsName, modifiersName, > >>>>>> entryDN, hasSubordinates, numSubordinates > >>>>> Ah, ok, probably yes. At least for some of them - CCing Simo. For example > >>>>> entryUSN is used by SSSD - CCing jhrozek to confirm. So it should be allowed > >>>>> for whole FreeIPA DIT. So this change is not so related to these patches. > >>>>> > >>>>> Do we also want to expose attributes like creatorsName/modifiersName? Do we > >>>>> consider that a public information or juts audit-like information for DM only? > >>>> They are standard features of LDAP servers. RFC 4512 states: > >>>> ============================================================================= > >>>> 3.4 Operational attributes > >>>> ... > >>>> Servers SHOULD maintain the 'creatorsName', 'createTimestamp', > >>>> 'modifiersName', and 'modifyTimestamp' attributes for all entries of the > >>>> DIT. > >>>> ============================================================================= > >>>> > >>>> This is, again, a question of policy. Active Directory forbids anonymous > >>>> access to the tree; so they always expose these attributes to > >>>> authenticated users only. If we allow anonymous access, we should allow > >>>> these attributes too. > >>> Well, DS *does* maintain the attributes - question is whether we want to show > >>> them to anonymous/authenticated people or just the DM :) > >> if you want to show them depends if it is useful or sensitive. > >> I don't know why an anonymous user would need access to them. > >> Are they sensitive ? Well, at least they expose a DN which has rights to > >> create and modify entries and could be used trying to get more access > > > >Alexander, should we then show just > >+ 'createtimestamp', 'modifytimestamp', 'entryusn', > >to authenticated users? I do not think that modifiers/creatorsDN is something > >that anonymous user need to see by default. > createtimestamp, modifytimestamp, and entryusn are all needed for sssd > LDAP provider. Not allowing them for anonymous will make legacy SSSD > performance suboptimal. > > modifier/creator DNs can be given out only to authenticated users. Yup, entryUSN is used to do quicker cache validation and modifyTimestamp too. ack to what Alexander proposed. Simo. From pviktori at redhat.com Fri Sep 5 12:51:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 14:51:08 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Allow user to force Kerberos realm during installation In-Reply-To: <5409B047.2070205@redhat.com> References: <53FDC788.2060603@redhat.com> <54072F2D.4020502@redhat.com> <540841FB.5090301@redhat.com> <54084B64.4090007@redhat.com> <5409655E.1030808@redhat.com> <5409B047.2070205@redhat.com> Message-ID: <5409B1BC.20303@redhat.com> On 09/05/2014 02:44 PM, Jan Cholasta wrote: > Dne 5.9.2014 v 09:25 David Kupka napsal(a): >> On 09/04/2014 01:22 PM, Jan Cholasta wrote: >>> Dne 4.9.2014 v 12:42 David Kupka napsal(a): >>>> On 09/03/2014 05:09 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 27.8.2014 v 13:56 David Kupka napsal(a): >>>>>> 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 >>>>> >>>>> 1) I think you can log realm in search() as part of the "Starting IPA >>>>> discovery ..." message instead of a separate message. >>>>> >>>>> >>>>> 2) Also, no need to log the realm twice in search(). >>>> I forget to remove some redundant debug prints. >>>>> >>>>> >>>>> 3) It looks like you forgot to un-indent some code in >>>>> ipadnssearchkrbkdc(). >>>>> >>>> Fixed, thanks. >>> >>> What I meant is that this: >>> >>> def ipadnssearchkrbkdc(self, domain=None): >>> kdc = None >>> >>> if not domain: >>> domain = self.domain >>> >>> kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, >>> break_on_first=False) >>> >>> if kdc: >>> kdc = ','.join(kdc) >>> else: >>> root_logger.debug("SRV record for KDC not found! >>> Domain: %s" % domain) >>> kdc = None >>> >>> return kdc >>> >>> should be this: >>> >>> def ipadnssearchkrbkdc(self, domain=None): >>> if not domain: >>> domain = self.domain >>> >>> kdc = self.ipadns_search_srv(domain, '_kerberos._udp', 88, >>> break_on_first=False) >>> if kdc: >>> kdc = ','.join(kdc) >>> else: >>> root_logger.debug("SRV record for KDC not found! Domain: >>> %s" % domain) >>> kdc = None >>> >>> return kdc >>> >>> Isn't that right? >>> >> >> Oh, you're right, again :) Thanks. >>>>> >>>>> Honza >>>>> >>>> >>> >>> >> > > ACK. > Pushed to: master: dc4bdd327ffffa639877b7d4553810b69943d996 ipa-4-1: a28d9b8f0a87633ac298676f47eadf0d7dc31cfb ipa-4-0: 0e077319046b8f8089b7b8590fafb824df4b8077 -- Petr? From pspacek at redhat.com Fri Sep 5 12:51:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 14:51:36 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <540999C0.5020404@redhat.com> References: <54088B87.2050300@redhat.com> <540893D9.2010206@redhat.com> <540993CF.7050404@redhat.com> <540999C0.5020404@redhat.com> Message-ID: <5409B1D8.7010203@redhat.com> On 5.9.2014 13:08, Martin Basti wrote: > On 05/09/14 12:43, Petr Spacek wrote: >> On 4.9.2014 18:31, Martin Basti wrote: >>> On 04/09/14 17:55, Petr Spacek wrote: >>>> Hello, >>>> >>>> Create temporary directories with ug=rwx,o= permissions. >>>> >>>> Zero group permissions do not allow to use POSIX ACLs which is >>>> undesirable. >>>> >>> NACK >>> It creates drwxr-x--- permissions (umask problem) >> >> Thank you for catching this. This version of the patch should fix the >> problem. It is not very nice but I don't see any better solution. >> > It works! ACK with * > > * Patch doesn't change permissions for existing directories, but because patch > pspacek-280, new version of bind plugin will create new file structure under > new 'master' directory, so there is no problem with old directories with old > permissions, isn't it? That is intentional. I don't want to change permissions if user decided to change them for some reason. -- Petr^2 Spacek From mkosek at redhat.com Fri Sep 5 13:11:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 15:11:36 +0200 Subject: [Freeipa-devel] [PATCH] 748 webui: extract complex pkey on Add and Edit In-Reply-To: <54079BDF.5090605@redhat.com> References: <5405DF02.7000209@redhat.com> <54079BDF.5090605@redhat.com> Message-ID: <5409B688.8030505@redhat.com> On 09/04/2014 12:53 AM, Endi Sukma Dewata wrote: > On 9/2/2014 10:15 AM, Petr Vobornik wrote: >> DNS zone 'Add and Edit' failed because of new DNS name encoding. >> >> This patch makes sure that keys are extracted properly. >> >> https://fedorahosted.org/freeipa/ticket/4520 > > ACK. > Pushed to: master: c50dff22827cefbb0b0838bf7e9b1e3fcf8752c0 ipa-4-1: 2fd4f40e361f4acb9b3383533432bfe90dbefe0f ipa-4-0: 3e987f6973314e4265f5f18723916b89e13cd1c6 Martin From rcritten at redhat.com Fri Sep 5 13:15:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Sep 2014 09:15:24 -0400 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <20140905090724.GV3593@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> <20140905090724.GV3593@redhat.com> Message-ID: <5409B76C.1020303@redhat.com> Alexander Bokovoy wrote: > On Fri, 05 Sep 2014, Martin Kosek wrote: >> On 09/04/2014 05:13 PM, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>>>> No longer request and install a cert for the IPA client machine. >>>>> >>>>> rob >>>> >>>> The original plan was to keep generating the certificate, but in >>>> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >>>> >>>> I'm fine with either approach. >>>> >>> >>> The cert has never been used and is now actively causing issues in >>> RHEL-7 with systemd and kickstart. It could be made optional, and move >>> the location, but IMHO its time has come. >>> >>> rob >> >> One change that Rob's patch also do is that from now on, certmonger >> would not >> be enabled and running by default on client machines. It would only be >> enabled >> on IPA server. >> >> I am still not confident about the resolution to just stop generating the >> certificate, I was leaning more towards making it optional + >> generating to >> better database as Honza proposed. >> >> Simo, Alexander, what is your take on this? > I'm fine with making it optional. However, on client machine upgrades do > not stop and disable certmonger if it is tracking more than just the > host certificate. > Well, that is unrelated to this change. Should that be a separate ticket? rob From mkosek at redhat.com Fri Sep 5 13:17:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 15:17:10 +0200 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <5409B76C.1020303@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> <20140905090724.GV3593@redhat.com> <5409B76C.1020303@redhat.com> Message-ID: <5409B7D6.3000903@redhat.com> On 09/05/2014 03:15 PM, Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Fri, 05 Sep 2014, Martin Kosek wrote: >>> On 09/04/2014 05:13 PM, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>>>>> No longer request and install a cert for the IPA client machine. >>>>>> >>>>>> rob >>>>> >>>>> The original plan was to keep generating the certificate, but in >>>>> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >>>>> >>>>> I'm fine with either approach. >>>>> >>>> >>>> The cert has never been used and is now actively causing issues in >>>> RHEL-7 with systemd and kickstart. It could be made optional, and move >>>> the location, but IMHO its time has come. >>>> >>>> rob >>> >>> One change that Rob's patch also do is that from now on, certmonger >>> would not >>> be enabled and running by default on client machines. It would only be >>> enabled >>> on IPA server. >>> >>> I am still not confident about the resolution to just stop generating the >>> certificate, I was leaning more towards making it optional + >>> generating to >>> better database as Honza proposed. >>> >>> Simo, Alexander, what is your take on this? >> I'm fine with making it optional. However, on client machine upgrades do >> not stop and disable certmonger if it is tracking more than just the >> host certificate. >> > > Well, that is unrelated to this change. Should that be a separate ticket? > > rob > I see it as very related. If we choose to do this optionally, instead of removing the code, we would do it conditionally (with different NSS database). But so far, it seems we choose only really simply just remove the code, i.e. no ticket needed. Martin From mkosek at redhat.com Fri Sep 5 13:19:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 15:19:36 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.2 Message-ID: <5409B868.3040709@redhat.com> Hello Team, The time has come and we are about to spin the release wheels for FreeIPA 4.0.2! Let us do quick check before the release. This version Release Man is Petr Viktorin. I created candidate release notes in http://www.freeipa.org/page/Releases/4.0.2. Please fee free to amend. == Missing work == I checked open tickets, the team worked great in lowering the number in the end of this week. Thank you! Out of the missing tickets, I only see this one potential candidate for inclusion: #4166 Backup CS.cfg before modifying it Any other patches that should land in 4.0.2? == Known Issues == I am aware of 2 related issues on 389-ds-base: #47889 DS crashed during ipa-server-install on test_ava_filter #47885 deref plugin should not return references with noc access rights Any other issues you are aware of? The 2 above can be just documented in the Release Notes, the fix will not be in FreeIPA anyway. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From rcritten at redhat.com Fri Sep 5 13:26:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Sep 2014 09:26:55 -0400 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <5409B7D6.3000903@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> <20140905090724.GV3593@redhat.com> <5409B76C.1020303@redhat.com> <5409B7D6.3000903@redhat.com> Message-ID: <5409BA1F.6030602@redhat.com> Martin Kosek wrote: > On 09/05/2014 03:15 PM, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> On Fri, 05 Sep 2014, Martin Kosek wrote: >>>> On 09/04/2014 05:13 PM, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>>>>>> No longer request and install a cert for the IPA client machine. >>>>>>> >>>>>>> rob >>>>>> >>>>>> The original plan was to keep generating the certificate, but in >>>>>> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >>>>>> >>>>>> I'm fine with either approach. >>>>>> >>>>> >>>>> The cert has never been used and is now actively causing issues in >>>>> RHEL-7 with systemd and kickstart. It could be made optional, and move >>>>> the location, but IMHO its time has come. >>>>> >>>>> rob >>>> >>>> One change that Rob's patch also do is that from now on, certmonger >>>> would not >>>> be enabled and running by default on client machines. It would only be >>>> enabled >>>> on IPA server. >>>> >>>> I am still not confident about the resolution to just stop generating the >>>> certificate, I was leaning more towards making it optional + >>>> generating to >>>> better database as Honza proposed. >>>> >>>> Simo, Alexander, what is your take on this? >>> I'm fine with making it optional. However, on client machine upgrades do >>> not stop and disable certmonger if it is tracking more than just the >>> host certificate. >>> >> >> Well, that is unrelated to this change. Should that be a separate ticket? >> >> rob >> > > I see it as very related. If we choose to do this optionally, instead of > removing the code, we would do it conditionally (with different NSS database). I'd prefer to remove it altogether and potentially add it back conditionally if anyone notices. > But so far, it seems we choose only really simply just remove the code, i.e. no > ticket needed. Alexander is pointing out that we disable certmonger at the end of ipa-client-install and this is not good if certmonger is tracking anything else (IPA or otherwise). This is a good point but not related to whether we issue and track a cert ourselves. In fact, to expand on his concerns, it is probably wise to do something similar to what we do in ipa-server-install during uninstall where we list the still-tracked certs for further investigation. rob From abokovoy at redhat.com Fri Sep 5 13:29:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 16:29:00 +0300 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <5409B76C.1020303@redhat.com> References: <54076AC3.5040503@redhat.com> <54088061.4060007@redhat.com> <54088197.80700@redhat.com> <540977CB.9050705@redhat.com> <20140905090724.GV3593@redhat.com> <5409B76C.1020303@redhat.com> Message-ID: <20140905132900.GZ3593@redhat.com> On Fri, 05 Sep 2014, Rob Crittenden wrote: >Alexander Bokovoy wrote: >> On Fri, 05 Sep 2014, Martin Kosek wrote: >>> On 09/04/2014 05:13 PM, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 3.9.2014 v 21:23 Rob Crittenden napsal(a): >>>>>> No longer request and install a cert for the IPA client machine. >>>>>> >>>>>> rob >>>>> >>>>> The original plan was to keep generating the certificate, but in >>>>> /etc/ipa/nssdb instead of /etc/pki/nssdb (see the attached patch). >>>>> >>>>> I'm fine with either approach. >>>>> >>>> >>>> The cert has never been used and is now actively causing issues in >>>> RHEL-7 with systemd and kickstart. It could be made optional, and move >>>> the location, but IMHO its time has come. >>>> >>>> rob >>> >>> One change that Rob's patch also do is that from now on, certmonger >>> would not >>> be enabled and running by default on client machines. It would only be >>> enabled >>> on IPA server. >>> >>> I am still not confident about the resolution to just stop generating the >>> certificate, I was leaning more towards making it optional + >>> generating to >>> better database as Honza proposed. >>> >>> Simo, Alexander, what is your take on this? >> I'm fine with making it optional. However, on client machine upgrades do >> not stop and disable certmonger if it is tracking more than just the >> host certificate. >> > >Well, that is unrelated to this change. Should that be a separate ticket? A separate ticket is fine too. -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 5 13:41:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 15:41:14 +0200 Subject: [Freeipa-devel] [PATCH] 0640 Add managed read permissions for compat tree In-Reply-To: <5409A3D3.308@redhat.com> References: <5406FB22.5090004@redhat.com> <54070936.3070003@redhat.com> <54071477.1020303@redhat.com> <540732E2.2030207@redhat.com> <20140904124023.GO3593@redhat.com> <54086F42.8070102@redhat.com> <20140905065603.GT3593@redhat.com> <20140905070341.GU3593@redhat.com> <540963AA.7040601@redhat.com> <54099BAD.3000508@redhat.com> <20140905113430.GY3593@redhat.com> <5409A3D3.308@redhat.com> Message-ID: <5409BD7A.3060801@redhat.com> On 09/05/2014 01:51 PM, Petr Viktorin wrote: > On 09/05/2014 01:34 PM, Alexander Bokovoy wrote: >> On Fri, 05 Sep 2014, Petr Viktorin wrote: >>> On 09/05/2014 09:18 AM, Martin Kosek wrote: > ... >>>> Thanks! Looks sane to me. We would just need to remove Views related >>>> ACIs for >>>> the 4.0.x version that we will need for today. >>> >>> Thanks indeed! >>> >>> Here is the patched patch. The Read Operational Attributes permission >>> is split for createtimestamp/modifytimestamp/entryusn (anonymous) and >>> creatorsname/modifiersname (authenticated). >> Thanks! ACK. > > Pushed to: > master: 418ce870bfbe13cea694a7b862cafe35c703f660 > ipa-4-0: 3e2c86aeabbd2e3c54ad73a40803ef2bf5b0cb17 > ipa-4-1: 9bcd88589e30d31d3f533cd42d2f816ef01b07c7 *@#$%, I committed the wrong patch by mistake. Fixed in: master: 68d656f80a483a57f5ed80b7ead03a071abb0ef0 ipa-4-0: b5870edb403572b19ffc91b1f3e504277b4c82a2 ipa-4-1: cd80528123a63250f0d0ebb167f6468ad008009f -- Petr? From pviktori at redhat.com Fri Sep 5 13:49:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 15:49:58 +0200 Subject: [Freeipa-devel] [PATCH] Make CA-less ipa-server-install option --root-ca-file optional In-Reply-To: <5409A69A.8070807@redhat.com> References: <53E09611.3030903@redhat.com> <53E1DC6B.5030003@redhat.com> <53E39F3E.3000007@redhat.com> <5409A69A.8070807@redhat.com> Message-ID: <5409BF86.2060806@redhat.com> On 09/05/2014 02:03 PM, Petr Viktorin wrote: > On 08/07/2014 05:46 PM, Petr Viktorin wrote: >> 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! > > Pushed to: > master: 6ad8c464a43260f8f58dc262f841c35be35b57b5 > ipa-4-0: 7c690d7e1238133677e49236595eb24483876ef8 > ipa-4-1: be6568234002165fe11dd55407f8eb8e9b357790 > Just after pushing I noticed the note in the ticket that Dmitri wants to take a look :( Dmitri, please reopen the ticket if there are more improvements to be made. I'm attaching the changed docs for reference. -- Petr? -------------- next part -------------- Usage: ipa-server-install [options] Options: --version show program's version number and exit -h, --help show this help message and exit basic options: -r REALM_NAME, --realm=REALM_NAME realm name -n DOMAIN_NAME, --domain=DOMAIN_NAME domain name -p DM_PASSWORD, --ds-password=DM_PASSWORD admin password -P MASTER_PASSWORD, --master-password=MASTER_PASSWORD kerberos master password (normally autogenerated) -a ADMIN_PASSWORD, --admin-password=ADMIN_PASSWORD admin user kerberos password --mkhomedir create home directories for users on their first login --hostname=HOST_NAME fully qualified name of server --ip-address=IP_ADDRESS Master Server IP Address -N, --no-ntp do not configure ntp --idstart=IDSTART The starting value for the IDs range (default random) --idmax=IDMAX The max value value for the IDs range (default: idstart+199999) --no_hbac_allow Don't install allow_all HBAC rule --no-ui-redirect Do not automatically redirect to the Web UI --ssh-trust-dns configure OpenSSH client to trust DNS SSHFP records --no-ssh do not configure OpenSSH client --no-sshd do not configure OpenSSH server -d, --debug print debugging information -U, --unattended unattended (un)installation never prompts the user certificate system options: --external-ca Generate a CSR for the IPA CA certificate to be signed by an external CA --external_cert_file=EXTERNAL_CERT_FILE File containing the IPA CA certificate signed by the external CA in PEM format --external_ca_file=EXTERNAL_CA_FILE File containing the external CA certificate chain in PEM format --no-pkinit disables pkinit setup steps --dirsrv_pkcs12=DIRSRV_PKCS12 PKCS#12 file containing the Directory Server SSL certificate --http_pkcs12=HTTP_PKCS12 PKCS#12 file containing the Apache Server SSL certificate --pkinit_pkcs12=PKINIT_PKCS12 PKCS#12 file containing the Kerberos KDC SSL certificate --dirsrv_pin=DIRSRV_PIN The password of the Directory Server PKCS#12 file --http_pin=HTTP_PIN The password of the Apache Server PKCS#12 file --pkinit_pin=PKINIT_PIN The password of the Kerberos KDC PKCS#12 file --root-ca-file=ROOT_CA_FILE PEM file containing the CA certificate for the PKCS#12 files --subject=SUBJECT The certificate subject base (default O=) DNS options: --setup-dns configure bind with our zone --forwarder=FORWARDERS Add a DNS forwarder --no-forwarders Do not add any DNS forwarders, use root servers instead --reverse-zone=REVERSE_ZONE The reverse DNS zone to use --no-reverse Do not create reverse DNS zone --zonemgr=ZONEMGR DNS zone manager e-mail address. Defaults to hostmaster at DOMAIN --no-host-dns Do not use DNS for hostname lookup during installation --no-dns-sshfp Do not automatically create DNS SSHFP records uninstall options: --uninstall uninstall an existing installation. The uninstall can be run with --unattended option -------------- next part -------------- ipa-server-install(1) FreeIPA Manual Pages ipa-server-install(1) NAME ipa-server-install - Configure an IPA server SYNOPSIS ipa-server-install [OPTION]... DESCRIPTION Configures the services needed by an IPA server. This includes setting up a Kerberos Key Distribution Center (KDC) and a Kadmin daemon with an LDAP back-end, configuring Apache, configuring NTP and optionally configuring and starting an LDAP-backed DNS server. By default a dogtag-based CA will be configured to issue server certificates. OPTIONS BASIC OPTIONS -r REALM_NAME, --realm=REALM_NAME The Kerberos realm name for the IPA server. You will not be able to estabilish trust with Active Directory unless the realm name is uppercased domain name. -n DOMAIN_NAME, --domain=DOMAIN_NAME Your DNS domain name -p DM_PASSWORD, --ds-password=DM_PASSWORD The password to be used by the Directory Server for the Directory Manager user -P MASTER_PASSWORD, --master-password=MASTER_PASSWORD The kerberos master password (normally autogenerated) -a ADMIN_PASSWORD, --admin-password=ADMIN_PASSWORD The password for the IPA admin user --mkhomedir Create home directories for users on their first login --hostname=HOST_NAME The fully-qualified DNS name of this server. If the hostname does not match system hostname, the system hostname will be updated accordingly to prevent service failures. --ip-address=IP_ADDRESS The IP address of this server. If this address does not match the address the host resolves to and --setup-dns is not selected the installation will fail. If the server hostname is not resolvable, a record for the hostname and IP_ADDRESS is added to /etc/hosts. -N, --no-ntp Do not configure NTP --idstart=IDSTART The starting user and group id number (default random) --idmax=IDMAX The maximum user and group id number (default: idstart+199999). If set to zero, the default value will be used. --no_hbac_allow Don't install allow_all HBAC rule. This rule lets any user from any host access any service on any other host. It is expected that users will remove this rule before moving to production. --no-ui-redirect Do not automatically redirect to the Web UI. --ssh-trust-dns Configure OpenSSH client to trust DNS SSHFP records. --no-ssh Do not configure OpenSSH client. --no-sshd Do not configure OpenSSH server. -d, --debug Enable debug logging when more verbose output is needed -U, --unattended An unattended installation that will never prompt for user input CERTIFICATE SYSTEM OPTIONS --external-ca Generate a CSR for the IPA CA certificate to be signed by an external CA. --external_cert_file=FILE File containing the IPA CA certificate signed by the external CA in PEM format. Must be given with --external_ca_file. --external_ca_file=FILE File containing the external CA certificate chain in PEM format. Must be given with --external_cert_file. If the CA certificate chain is in PKCS#7 format you can convert it to PEM using: openssl pkcs7 -in PKCS7_FILE -print_certs -out PEM_FILE --no-pkinit Disables pkinit setup steps --dirsrv_pkcs12=FILE PKCS#12 file containing the Directory Server SSL Certificate --http_pkcs12=FILE PKCS#12 file containing the Apache Server SSL Certificate --pkinit_pkcs12=FILE PKCS#12 file containing the Kerberos KDC SSL certificate --dirsrv_pin=DIRSRV_PIN The password of the Directory Server PKCS#12 file --http_pin=HTTP_PIN The password of the Apache Server PKCS#12 file --pkinit_pin=PKINIT_PIN The password of the Kerberos KDC PKCS#12 file --root-ca-file=FILE PEM file containing the CA certificate of the CA which issued the Directory Server, Apache Server and Kerberos KDC SSL certificates. Use this option if the CA certificate is not present in the PKCS#12 files. --subject=SUBJECT The certificate subject base (default O=REALM.NAME) DNS OPTIONS --setup-dns Generate a DNS zone if it does not exist already and configure the DNS server. This option requires that you either specify at least one DNS forwarder through the --forwarder option or use the --no-forwarders option. Note that you can set up a DNS at any time after the initial IPA server install by running ipa-dns-install (see ipa-dns-install(1)). --forwarder=IP_ADDRESS Add a DNS forwarder to the DNS configuration. You can use this option multiple times to specify more forwarders, but at least one must be provided, unless the --no-forwarders option is specified. --no-forwarders Do not add any DNS forwarders. Root DNS servers will be used instead. --reverse-zone=REVERSE_ZONE The reverse DNS zone to use --no-reverse Do not create reverse DNS zone --zonemgr The e-mail address of the DNS zone manager. Defaults to hostmaster at DOMAIN --no-host-dns Do not use DNS for hostname lookup during installation --no-dns-sshfp Do not automatically create DNS SSHFP records. UNINSTALL OPTIONS --uninstall Uninstall an existing IPA installation -U, --unattended An unattended uninstallation that will never prompt for user input EXIT STATUS 0 if the (un)installation was successful 1 if an error occurred SEE ALSO ipa-dns-install(1) FreeIPA Jun 28 2012 ipa-server-install(1) From mbasti at redhat.com Fri Sep 5 14:03:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 05 Sep 2014 16:03:15 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <5409B1D8.7010203@redhat.com> References: <54088B87.2050300@redhat.com> <540893D9.2010206@redhat.com> <540993CF.7050404@redhat.com> <540999C0.5020404@redhat.com> <5409B1D8.7010203@redhat.com> Message-ID: <5409C2A3.2080507@redhat.com> On 05/09/14 14:51, Petr Spacek wrote: > On 5.9.2014 13:08, Martin Basti wrote: >> On 05/09/14 12:43, Petr Spacek wrote: >>> On 4.9.2014 18:31, Martin Basti wrote: >>>> On 04/09/14 17:55, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Create temporary directories with ug=rwx,o= permissions. >>>>> >>>>> Zero group permissions do not allow to use POSIX ACLs which is >>>>> undesirable. >>>>> >>>> NACK >>>> It creates drwxr-x--- permissions (umask problem) >>> >>> Thank you for catching this. This version of the patch should fix the >>> problem. It is not very nice but I don't see any better solution. >>> >> It works! ACK with * >> >> * Patch doesn't change permissions for existing directories, but >> because patch >> pspacek-280, new version of bind plugin will create new file >> structure under >> new 'master' directory, so there is no problem with old directories >> with old >> permissions, isn't it? > > That is intentional. I don't want to change permissions if user > decided to change them for some reason. > ok, double ACK then :-) -- Martin Basti From pviktori at redhat.com Fri Sep 5 14:12:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 16:12:52 +0200 Subject: [Freeipa-devel] [PATCH] 318 Backup CS.cfg before modifying it In-Reply-To: <5409A2BD.8070806@redhat.com> References: <5407434B.5030104@redhat.com> <54098AE5.2040508@redhat.com> <5409A2BD.8070806@redhat.com> Message-ID: <5409C4E4.4070606@redhat.com> On 09/05/2014 01:47 PM, Jan Cholasta wrote: > Dne 5.9.2014 v 12:05 Petr Viktorin napsal(a): >> On 09/03/2014 06:35 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >> >> ACK >> Neither patch applies to 4.1, though. Could you send a version for that >> as well? >> >> > > Sure. > Thanks. Pushed to: master: 2ed6fb092eac2397f4d6395307c91a497d747ac0 ipa-4-0: 8292b228b89e056316a11590a263176a9c595f14 ipa-4-1: b6c7e5fd4cb8c91d8bd44f2fa8f3fb9e15194900 -- Petr? From pviktori at redhat.com Fri Sep 5 14:17:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 16:17:46 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.2 In-Reply-To: <5409B868.3040709@redhat.com> References: <5409B868.3040709@redhat.com> Message-ID: <5409C60A.70202@redhat.com> On 09/05/2014 03:19 PM, Martin Kosek wrote: > Hello Team, > > The time has come and we are about to spin the release wheels for FreeIPA > 4.0.2! Let us do quick check before the release. > > This version Release Man is Petr Viktorin. I can start the release process in a few hours, if the new bind-dyndb-ldap goes out by then. > I created candidate release notes in > http://www.freeipa.org/page/Releases/4.0.2. Please fee free to amend. > > == Missing work == > I checked open tickets, the team worked great in lowering the number in the end > of this week. Thank you! > > Out of the missing tickets, I only see this one potential candidate for inclusion: > > #4166 Backup CS.cfg before modifying it Just pushed. > Any other patches that should land in 4.0.2? We'll need to add a Conflicts: bind-dyndb-ldap < 5.1. > == Known Issues == > I am aware of 2 related issues on 389-ds-base: > > #47889 DS crashed during ipa-server-install on test_ava_filter https://fedorahosted.org/389/ticket/47889 > > #47885 deref plugin should not return references with noc access rights https://fedorahosted.org/389/ticket/47885 > > Any other issues you are aware of? The 2 above can be just documented in the > Release Notes, the fix will not be in FreeIPA anyway. -- Petr? From mkosek at redhat.com Fri Sep 5 14:32:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 16:32:35 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.2 In-Reply-To: <5409C60A.70202@redhat.com> References: <5409B868.3040709@redhat.com> <5409C60A.70202@redhat.com> Message-ID: <5409C983.7040906@redhat.com> On 09/05/2014 04:17 PM, Petr Viktorin wrote: > On 09/05/2014 03:19 PM, Martin Kosek wrote: >> Hello Team, >> >> The time has come and we are about to spin the release wheels for FreeIPA >> 4.0.2! Let us do quick check before the release. >> >> This version Release Man is Petr Viktorin. > > I can start the release process in a few hours, if the new bind-dyndb-ldap goes > out by then. > >> I created candidate release notes in >> http://www.freeipa.org/page/Releases/4.0.2. Please fee free to amend. >> >> == Missing work == >> I checked open tickets, the team worked great in lowering the number in the end >> of this week. Thank you! >> >> Out of the missing tickets, I only see this one potential candidate for >> inclusion: >> >> #4166 Backup CS.cfg before modifying it > > Just pushed. > >> Any other patches that should land in 4.0.2? > > We'll need to add a Conflicts: bind-dyndb-ldap < 5.1 Aaand I would really consider the proposed Rob's patch for removing host certificate also for 4.0.2 release. . > >> == Known Issues == >> I am aware of 2 related issues on 389-ds-base: >> >> #47889 DS crashed during ipa-server-install on test_ava_filter > https://fedorahosted.org/389/ticket/47889 >> >> #47885 deref plugin should not return references with noc access rights > https://fedorahosted.org/389/ticket/47885 >> >> Any other issues you are aware of? The 2 above can be just documented in the >> Release Notes, the fix will not be in FreeIPA anyway. > From abokovoy at redhat.com Fri Sep 5 14:47:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Sep 2014 17:47:02 +0300 Subject: [Freeipa-devel] FreeIPA 4.0.2 In-Reply-To: <5409B868.3040709@redhat.com> References: <5409B868.3040709@redhat.com> Message-ID: <20140905144702.GA3593@redhat.com> On Fri, 05 Sep 2014, Martin Kosek wrote: >Hello Team, > >The time has come and we are about to spin the release wheels for FreeIPA >4.0.2! Let us do quick check before the release. > >This version Release Man is Petr Viktorin. > >I created candidate release notes in >http://www.freeipa.org/page/Releases/4.0.2. Please fee free to amend. Fixed trust-related items and added information about schema-compat changes. -- / Alexander Bokovoy From pspacek at redhat.com Fri Sep 5 15:40:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 17:40:36 +0200 Subject: [Freeipa-devel] [PATCH 0283] Fix root zone handling Message-ID: <5409D974.7070602@redhat.com> Hello, Fix root zone handling. syncrepl_update() was buggy in a way which could cause accidental zone removal. Test case: A server with two zones: '.' and 'test.' Zone '.': . NS ns1.test. . NS ns2.test. test. NS ns1.test. test. NS ns2.test. Zone 'test.': test. NS ns1.test. test. NS ns2.test. ns1.test. A 192.0.2.1 ns2.test. A 192.0.2.2 Removing whole name 'test.' from zone '.' will cause removal of zone 'test.' instead of removing NS records from zone '.'. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0283-Fix-root-zone-handling.patch Type: text/x-patch Size: 9936 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 5 15:52:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Sep 2014 17:52:23 +0200 Subject: [Freeipa-devel] [PATCH] 1109 No client machine cert In-Reply-To: <54076AC3.5040503@redhat.com> References: <54076AC3.5040503@redhat.com> Message-ID: <5409DC37.5070802@redhat.com> On 09/03/2014 09:23 PM, Rob Crittenden wrote: > No longer request and install a cert for the IPA client machine. https://fedorahosted.org/freeipa/ticket/4449 ACK Pushed to: master: c1bf5203937827369c7ce023d03c75d2da6d83ee ipa-4-1: 058c1f453c4e2df38eec57ba605cd5dc492eb978 ipa-4-0: 2dd2fd7e1aa470ea8fa3fd09ebecacec7ee8bc77 -- Petr? From pspacek at redhat.com Fri Sep 5 17:47:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 19:47:36 +0200 Subject: [Freeipa-devel] [PATCH 0283] Fix root zone handling In-Reply-To: <5409D974.7070602@redhat.com> References: <5409D974.7070602@redhat.com> Message-ID: <5409F738.4080901@redhat.com> On 5.9.2014 17:40, Petr Spacek wrote: > Hello, > > Fix root zone handling. > > syncrepl_update() was buggy in a way which could cause accidental zone removal. > > Test case: A server with two zones: '.' and 'test.' > > Zone '.': > . NS ns1.test. > . NS ns2.test. > test. NS ns1.test. > test. NS ns2.test. > > Zone 'test.': > test. NS ns1.test. > test. NS ns2.test. > ns1.test. A 192.0.2.1 > ns2.test. A 192.0.2.2 > > Removing whole name 'test.' from zone '.' will cause removal of zone 'test.' > instead of removing NS records from zone '.'. And fix the fix ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0283-2-Fix-root-zone-handling.patch Type: text/x-patch Size: 9936 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 8 08:32:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:32:54 +0200 Subject: [Freeipa-devel] [PATCH 0282] Create temporary directories with ug=rwx, o= permissions In-Reply-To: <5409C2A3.2080507@redhat.com> References: <54088B87.2050300@redhat.com> <540893D9.2010206@redhat.com> <540993CF.7050404@redhat.com> <540999C0.5020404@redhat.com> <5409B1D8.7010203@redhat.com> <5409C2A3.2080507@redhat.com> Message-ID: <540D69B6.5040009@redhat.com> On 5.9.2014 16:03, Martin Basti wrote: > On 05/09/14 14:51, Petr Spacek wrote: >> On 5.9.2014 13:08, Martin Basti wrote: >>> On 05/09/14 12:43, Petr Spacek wrote: >>>> On 4.9.2014 18:31, Martin Basti wrote: >>>>> On 04/09/14 17:55, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> Create temporary directories with ug=rwx,o= permissions. >>>>>> >>>>>> Zero group permissions do not allow to use POSIX ACLs which is >>>>>> undesirable. >>>>>> >>>>> NACK >>>>> It creates drwxr-x--- permissions (umask problem) >>>> >>>> Thank you for catching this. This version of the patch should fix the >>>> problem. It is not very nice but I don't see any better solution. >>>> >>> It works! ACK with * >>> >>> * Patch doesn't change permissions for existing directories, but because patch >>> pspacek-280, new version of bind plugin will create new file structure under >>> new 'master' directory, so there is no problem with old directories with old >>> permissions, isn't it? >> >> That is intentional. I don't want to change permissions if user decided to >> change them for some reason. >> > ok, double ACK then :-) Pushed to master: 2bcf23d57eb67bf29d88bb1682ff32f58ee6a070 -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 8 08:32:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:32:56 +0200 Subject: [Freeipa-devel] [PATCH 0281] Escape directory names generated from zone names In-Reply-To: <5408886E.7050706@redhat.com> References: <54086D3F.5070008@redhat.com> <540877E2.1060101@redhat.com> <54087A31.9070302@redhat.com> <5408886E.7050706@redhat.com> Message-ID: <540D69B8.1060503@redhat.com> On 4.9.2014 17:42, Martin Basti wrote: > On 04/09/14 16:41, Petr Spacek wrote: >> On 4.9.2014 16:32, Martin Basti wrote: >>> On 04/09/14 15:46, Petr Spacek wrote: >>>> Hello, >>>> >>>> Escape directory names generated from zone names. >>>> >>>> Previously root zone '.' and zone names with characters like '/' caused >>>> scattering of temporary files all over dyndb-ldap working directory. >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/122 >>>> >>> Patch please :-) >>> >> And here is the patch ... >> > Works for me. ACK Pushed to master: e3da71fcf26c0bd024f739d23ce431408fb9246d -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 8 08:32:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:32:58 +0200 Subject: [Freeipa-devel] [PATCH 0280] Use "master" subdirectory for temporary files related to zones In-Reply-To: <5408880A.4090607@redhat.com> References: <54085E7B.9040903@redhat.com> <5408880A.4090607@redhat.com> Message-ID: <540D69BA.3080702@redhat.com> On 4.9.2014 17:40, Martin Basti wrote: > On 04/09/14 14:43, Petr Spacek wrote: >> Hello, >> >> Use "master" subdirectory for temporary files related to zones. >> >> This allows us to separate zone and non-zone metadata and also to separate >> master and (hypothetical) slave zones. >> > Works fine. ACK > Pushed to master: f942df399ded10399a1f5d378d5ca1cc959bb157 -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 8 08:33:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:33:00 +0200 Subject: [Freeipa-devel] [PATCH 0279] Always use task associated ISC event instead of global inst->task In-Reply-To: <540708BA.7020503@redhat.com> References: <5405F639.9090406@redhat.com> <540708BA.7020503@redhat.com> Message-ID: <540D69BC.1000007@redhat.com> On 3.9.2014 14:25, Martin Basti wrote: > On 02/09/14 18:54, Petr Spacek wrote: >> Hello, >> >> Always use task associated with ISC event instead of global inst->task. >> >> This is necessary to prevent random crashes like: >> REQUIRE(task->state == task_state_running) failed >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/138 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Functional ACK Pushed to master: e3da71fcf26c0bd024f739d23ce431408fb9246d -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 8 08:43:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:43:00 +0200 Subject: [Freeipa-devel] [PATCH 0284-0285] Update NEWS & Bump NVR to 3.7 Message-ID: <540D6C14.9000701@redhat.com> Hello, Update NEWS for 3.7 release. Pushed to master: e7e35ea7217e287bb1dc4aeca1185fcbc8bb5fae Bump NVR to 3.7. Pushed to master: 98725e5fedcfe9ff9e4e16ee1f2d7d20a1e00e30 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0284-Update-NEWS-for-3.7-release.patch Type: text/x-patch Size: 603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0285-Bump-NVR-to-3.7.patch Type: text/x-patch Size: 1193 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 8 08:49:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 10:49:48 +0200 Subject: [Freeipa-devel] [PATCH 0286-0287] Bump NVR to 4.5Update NEWS for 4.5 release Message-ID: <540D6DAC.5080205@redhat.com> Hello, Update NEWS for 4.5 release. Pushed to v4:7df9330f84316d6157663c0fa371d108a75e2621 Bump NVR to 4.5. Pushed to v4: ae718be25366575e0b41e55b862ce579527375ad -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0286-Update-NEWS-for-4.5-release.patch Type: text/x-patch Size: 654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0287-Bump-NVR-to-4.5.patch Type: text/x-patch Size: 1193 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 8 09:45:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 08 Sep 2014 11:45:13 +0200 Subject: [Freeipa-devel] [PATCH 0283] Fix root zone handling In-Reply-To: <5409F738.4080901@redhat.com> References: <5409D974.7070602@redhat.com> <5409F738.4080901@redhat.com> Message-ID: <540D7AA9.10703@redhat.com> On 05/09/14 19:47, Petr Spacek wrote: > On 5.9.2014 17:40, Petr Spacek wrote: >> Hello, >> >> Fix root zone handling. >> >> syncrepl_update() was buggy in a way which could cause accidental >> zone removal. >> >> Test case: A server with two zones: '.' and 'test.' >> >> Zone '.': >> . NS ns1.test. >> . NS ns2.test. >> test. NS ns1.test. >> test. NS ns2.test. >> >> Zone 'test.': >> test. NS ns1.test. >> test. NS ns2.test. >> ns1.test. A 192.0.2.1 >> ns2.test. A 192.0.2.2 >> >> Removing whole name 'test.' from zone '.' will cause removal of zone >> 'test.' >> instead of removing NS records from zone '.'. > > > And fix the fix ... ACK -- Martin Basti From pspacek at redhat.com Mon Sep 8 09:54:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 11:54:34 +0200 Subject: [Freeipa-devel] [PATCH 0283] Fix root zone handling In-Reply-To: <540D7AA9.10703@redhat.com> References: <5409D974.7070602@redhat.com> <5409F738.4080901@redhat.com> <540D7AA9.10703@redhat.com> Message-ID: <540D7CDA.8010906@redhat.com> On 8.9.2014 11:45, Martin Basti wrote: > On 05/09/14 19:47, Petr Spacek wrote: >> On 5.9.2014 17:40, Petr Spacek wrote: >>> Hello, >>> >>> Fix root zone handling. >>> >>> syncrepl_update() was buggy in a way which could cause accidental zone >>> removal. >>> >>> Test case: A server with two zones: '.' and 'test.' >>> >>> Zone '.': >>> . NS ns1.test. >>> . NS ns2.test. >>> test. NS ns1.test. >>> test. NS ns2.test. >>> >>> Zone 'test.': >>> test. NS ns1.test. >>> test. NS ns2.test. >>> ns1.test. A 192.0.2.1 >>> ns2.test. A 192.0.2.2 >>> >>> Removing whole name 'test.' from zone '.' will cause removal of zone 'test.' >>> instead of removing NS records from zone '.'. >> >> >> And fix the fix ... > ACK Thanks! Pushed to master: 2d4a48880ec6572214ccee531f4ff9afbc8c8367 -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 8 10:14:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 12:14:21 +0200 Subject: [Freeipa-devel] [PATCH 0288-0290] Clarify that idnsZoneActive attribute is not supportedUpdate naming rules for working directoriesUpdate link to patches for BIND Message-ID: <540D817D.1040009@redhat.com> Hello, Clarify that idnsZoneActive attribute is not supported. Pushed to master: 2481cdd2133741e987d5ab7c8995ccf156109461 Update naming rules for working directories. Pushed to master: 972c158cf330bc66da990b12f5cd41e57a39eb38 Update link to patches for BIND. Pushed to master: 282184e45fae28c28f8fd98b1fb1672d7382d3da -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0288-Update-link-to-patches-for-BIND.patch Type: text/x-patch Size: 840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0289-Update-naming-rules-for-working-directories.patch Type: text/x-patch Size: 2647 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0290-Clarify-that-idnsZoneActive-attribute-is-not-support.patch Type: text/x-patch Size: 2101 bytes Desc: not available URL: From pvoborni at redhat.com Mon Sep 8 10:41:11 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Sep 2014 12:41:11 +0200 Subject: [Freeipa-devel] [PATCH] 742 webui: adjust behavior of bounce url In-Reply-To: <5407A387.9070104@redhat.com> References: <53F61909.4070402@redhat.com> <5407A387.9070104@redhat.com> Message-ID: <540D87C7.2050403@redhat.com> On 4.9.2014 01:25, Endi Sukma Dewata wrote: > On 8/21/2014 11:06 AM, Petr Vobornik wrote: >> 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 > > ACK. Pushed to: master: 050431c4dd70f024b1644137fb0ad4881ed9e32b ipa-4-1: c946029ba304efe808106da13e1bfd58135821be > > Just one thing, when the delay=0 and the direction happens quickly, the > users might see the confirmation and the redirection messages displayed > briefly on the screen but they cannot read it because it's too quick, > which might leave them wondering what it was. > > I think delay=0 is a special case where we want a seamless integration > with 3rd party application. If the password reset is completed > successfully, it should just display the next page in the 3rd party > application. Users shouldn't see a 'redirection' message. To them it's > all one application. > On the other hand it is handy if they delay is not small, e.g., > 2s, because user sees that something is happening. Added to a list of things for discussion with Kyle. -- Petr Vobornik From pvoborni at redhat.com Mon Sep 8 10:44:24 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Sep 2014 12:44:24 +0200 Subject: [Freeipa-devel] [PATCH] 743 webui: do not show login error when switching back from otp sync screen In-Reply-To: <5407C9C3.9000409@redhat.com> References: <53F72EDE.3070307@redhat.com> <5407C9C3.9000409@redhat.com> Message-ID: <540D8888.2070507@redhat.com> On 4.9.2014 04:09, Endi Sukma Dewata wrote: > On 8/22/2014 6:51 AM, Petr Vobornik wrote: >> 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. > > ACK. > Pushed to: master: 5e36cc5215209294c9728fa4c2034d4c248acd68 ipa-4-1: e77f0b92ae9fafce148bd16093605dfb0358a41d -- Petr Vobornik From pvoborni at redhat.com Mon Sep 8 10:46:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Sep 2014 12:46:43 +0200 Subject: [Freeipa-devel] [PATCH] 744 webui: switch associators if default doesn't work In-Reply-To: <5408B077.9020001@redhat.com> References: <53F76FEA.9090806@redhat.com> <5408B077.9020001@redhat.com> Message-ID: <540D8913.7070604@redhat.com> On 4.9.2014 20:33, Endi Sukma Dewata wrote: > On 8/22/2014 11:29 AM, Petr Vobornik wrote: >> 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 > > ACK. > Pushed to: master: f70eafaedbdc4a511338979198f9459ee5b47807 ipa-4-1: cb2dc9c5efaee6344daa32a9717336345a22f022 -- Petr Vobornik From pvoborni at redhat.com Mon Sep 8 10:53:24 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Sep 2014 12:53:24 +0200 Subject: [Freeipa-devel] [PATCH] 745 webui: notify psw change success only once In-Reply-To: <5408B151.7000909@redhat.com> References: <54003C8B.6050109@redhat.com> <5408B151.7000909@redhat.com> Message-ID: <540D8AA4.1050501@redhat.com> On 4.9.2014 20:37, Endi Sukma Dewata wrote: > On 8/29/2014 3:40 AM, Petr Vobornik wrote: >> 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/ >> > > ACK. > Pushed to: ipa-4-1: f8fc3bbcd84e12d4f918fe05910c9e664fc0b07c master: ad6001fc2e70b6e7dbbe986f4243dd785f1bd3b2 -- Petr Vobornik From pviktori at redhat.com Mon Sep 8 12:08:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Sep 2014 14:08:42 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.2 Message-ID: <540D9C4A.2050108@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.0.2! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Highlights in 4.0.2 == === Enhancements === * TOTP watermark support was added. The last token interval is now being added to database and replicated in FreeIPA realm. Note that the number of writes is kept the same as an unnecessary LDAP write was eliminated. * Effective Attributes widget in the Add Permission Web UI page was improved * ipa-csreplica-manage can now set CA renewal master * trust-add is now capable of ensuring conditions for a Trust are met prior to establishing it in complex environments (e.g. only adding trust via AD DC with a PDC role in a forest root domain, falling back when no closest AD DC is available for the local site) === Bug fixes === * Server installation with certificates signed by external CA could crash with IndexError * ipa-client-install could add duplicate "sss" to /etc/nsswitch.conf when configuring sudo * ipa-client-install crashed when non-zero minSSF was set on FreeIPA server * Installers and helper tools now communicate with certmonger via its DBUS API instead of manipulating its configuration files, fixing the related intermittent uninstallation failures * idrange-* commands no longer allow unsupported range types (ipa-ad-winsync, ipa-ipa-trust) * user-add no longer fails when --user-auth-type is specified * Entries in Schema Compatibility tree are now accessible anonymously by default to aid legacy clients. == Known Issues == * The Directory Server may crash during install due to 389-ds bug 47889 (https://fedorahosted.org/389/ticket/47889). * Enumeration in SSSD may fail due to 389-ds bug 47885 (https://fedorahosted.org/389/ticket/47885). * Zone removal may misbehave due to a bind-dyndb-ldap bug. If FreeIPA is used to manage DNS root zones, bind-dyndb-ldap 5.1 or higher is recommended. Bind-dyndb-ldap 5.2 was built for Fedora 20 (http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/31135/), 21 (https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.2-1.fc21), rawhide (http://koji.fedoraproject.org/koji/buildinfo?buildID=575841). == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.1 == === Alexander Bokovoy (5) === * ipaserver/dcerpc.py: if search of a closest GC failed, try to find any GC * ipaserver/dcerpc.py: make PDC discovery more robust * ipaserver/dcerpc.py: Avoid hitting issue with transitive trusts on Windows Server prior to 2012 * ipaserver/dcerpc.py: be more open to what domains can be seen through the forest trust * ipaserver/dcerpc.py: Make sure trust is established only to forest root domain === David Kupka (7) === * Fix group-remove-member crash when group is removed from a protected group * test group: remove group from protected group. * Verify otptoken timespan is valid * Add record(s) to /etc/host when IPA is configured as DNS server. * Use certmonger D-Bus API instead of messing with its files. * Do not restart apache server when not necessary. * Allow user to force Kerberos realm during installation. === Gabe (1) === * ipa trust-add command should be interactive === Jakub Hrozek (1) === * CLIENT: Explicitly require python-backports-ssl_match_hostname === Jan Cholasta (11) === * Check if /root/ipa.csr exists when installing server with external CA. * Exclude attributelevelrights from --raw result processing in baseldap. * Add test for baseldap.entry_to_dict. * Convert external CA chain to PKCS#7 before passing it to pkispawn. * Allow changing CA renewal master in ipa-csreplica-manage. * Add method for setting CA renewal master in LDAP to CAInstance. * Pick new CA renewal master when deleting a replica. * Normalize external CA cert before passing it to pkispawn * Add new NSSDatabase method get_cert for getting certs from NSS databases. * Make CA-less ipa-server-install option --root-ca-file optional. * Backup CS.cfg before modifying it === Martin Ba?ti (7) === * Fix DNS upgrade plugin should check if DNS container exists * FIX: named_enable_dnssec should verify if DNS is installed * Allow to add host if AAAA record exists * Tests: host tests with dns * Fix dnsrecord-mod raise error if last record attr is removed * FIX DNS wildcard records (RFC4592) * Tests: DNS wildcard records === Martin Ko?ek (2) === * Do not crash client basedn discovery when SSF not met * ipa-adtrust-install does not re-add member in adtrust agents group === Nathaniel McCallum (1) === * Ensure ipaUserAuthTypeClass when needed on user creation === Petr Viktorin (8) === * Update API.txt * test_ipagetkeytab: Fix assertion in negative test * freeipa.spec.in: Add python-backports-ssl_match_hostname to BuildRequires * permission plugin: Make --target available in the CLI * permission plugin: Improve description of the target option * Add managed read permissions for compat tree * Fix: Add managed read permissions for compat tree and operational attrs * Become IPA 4.0.2 === Petr Voborn?k (10) === * webui: support wildcard attribute level rights * webui: fix nested items creation in dropdown list * webui: internet explorer fixes * webui: detach facet nodes * webui: replace action_buttons with action_widget * webui: remove remaining action-button-disabled occurrences * webui-ci: fix reset password check * webui: better error reporting * webui-ci: fix table widget add * webui: extract complex pkey on Add and Edit === Rob Crittenden (1) === * No longer generate a machine certificate on client installs === Stephen Gallagher (1) === * Change BuildRequires for Java === Tom?? Babej (3) === * ipalib: idrange: Make non-implemented range types fail the validation * ipatests: test_trust: Add test to cover lookup of trusdomains * ipa-client-install: Do not add already configured sources to nsswitch.conf entries -- Petr? From redhatrises at gmail.com Mon Sep 8 14:10:11 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 8 Sep 2014 08:10:11 -0600 Subject: [Freeipa-devel] [PATCH 0032] Hardcoded lib dir in freeipa.spec Message-ID: Hello, This patch should fix https://fedorahosted.org/freeipa/ticket/4528 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0032-Hardcoded-lib-dir-in-freeipa.spec.patch Type: text/x-patch Size: 1522 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 8 15:56:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 08 Sep 2014 17:56:05 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5405DA76.1020502@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> Message-ID: <540DD195.3070804@redhat.com> On 02/09/14 16:55, David Kupka wrote: > The patch now depends on freeipa-dkupka-0012 as both modifies the same > part of code. > > On 09/02/2014 10:29 AM, David Kupka wrote: >> Forget to add str() conversion to some places when removing map(). Now >> it should be working again. >> >> On 08/27/2014 02:24 PM, David Kupka wrote: >>> 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. >>>> >>>> I haven't tested it yet, I only take a look because there may be conflict with 'dns root zone support' refactoring 1) + for ns_ip_address in nameserver_ip_address: + add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, + ns_hostname=api.env.host, ns_ip_address=ns_ip_address, + force=True) Are you sure this will work? Domain name is the same, so no new zone will be created (DuplicateEntry exception is handled inside add_zone function). IMO you should call add_zone only once. BTW: I will change the add_zone function in refactoring , ns_hostname wil be remove, and ns_ip_address will take an p+ipv6 address 2) + resolv_txt = '' + for ip_address in self.ip_address: + resolv_txt += "search "+self.domain+"\nnameserver "+str(ip_address)+"\n" There is multiple search statements. search example.com nameserver 192.168.1.1 search example.com nameserver 2001:db8::1 ... and also there si a limit of namesevers which can be in resolv.conf, but I dont know if we care, statements over limit should be just ignored. http://linux.die.net/man/5/resolv.conf 3) self.ip_address is confusing for me, I'm expecting only one address. Could it be ip_addresses or ip_address_list? Ask the framework gurus :-) -- Martin Basti From mbasti at redhat.com Tue Sep 9 08:17:14 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Sep 2014 10:17:14 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <540DD195.3070804@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> Message-ID: <540EB78A.6040701@redhat.com> On 08/09/14 17:56, Martin Basti wrote: > On 02/09/14 16:55, David Kupka wrote: >> The patch now depends on freeipa-dkupka-0012 as both modifies the >> same part of code. >> >> On 09/02/2014 10:29 AM, David Kupka wrote: >>> Forget to add str() conversion to some places when removing map(). Now >>> it should be working again. >>> >>> On 08/27/2014 02:24 PM, David Kupka wrote: >>>> 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. >>>>> >>>>> > I haven't tested it yet, I only take a look because there may be > conflict with 'dns root zone support' refactoring > > 1) > + for ns_ip_address in nameserver_ip_address: > + add_zone(self.domain, self.zonemgr, > dns_backup=self.dns_backup, > + ns_hostname=api.env.host, > ns_ip_address=ns_ip_address, > + force=True) > Are you sure this will work? Domain name is the same, so no new zone > will be created (DuplicateEntry exception is handled inside add_zone > function). > IMO you should call add_zone only once. > > BTW: I will change the add_zone function in refactoring , ns_hostname > wil be remove, and ns_ip_address will take an p+ipv6 address > > 2) > + resolv_txt = '' > + for ip_address in self.ip_address: > + resolv_txt += "search "+self.domain+"\nnameserver > "+str(ip_address)+"\n" > There is multiple search statements. > > search example.com > nameserver 192.168.1.1 > search example.com > nameserver 2001:db8::1 > ... > > and also there si a limit of namesevers which can be in resolv.conf, > but I dont know if we care, statements over limit should be just > ignored. > http://linux.die.net/man/5/resolv.conf > > 3) > self.ip_address is confusing for me, I'm expecting only one address. > Could it be ip_addresses or ip_address_list? Ask the framework gurus :-) > We might add support for more ip addres for replica install too ipa-replica-prepare replica.example.com --ip-address=192.168.1.2 --ip-address=2001:db8::2 -- Martin Basti From pviktori at redhat.com Tue Sep 9 08:38:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Sep 2014 10:38:48 +0200 Subject: [Freeipa-devel] [PATCH] 0083 Remove internaldb pasword from password.conf In-Reply-To: <54058FEA.9070301@redhat.com> References: <527A376C.40006@redhat.com> <527A38EC.4090603@redhat.com> <54049C96.1050000@redhat.com> <54056BAA.40606@redhat.com> <54058FEA.9070301@redhat.com> Message-ID: <540EBC98.3040806@redhat.com> On 09/02/2014 11:37 AM, Jan Cholasta wrote: > Patch attached. > > Dne 2.9.2014 v 09:03 Jan Cholasta napsal(a): >> Also, Dogtag certificate renewal does not work with internaldb removed, >> I'm working on a patch to fix that. >> >> Dne 1.9.2014 v 18:19 Petr Viktorin napsal(a): >>> On 11/06/2013 01:41 PM, Ana Krivokapic wrote: >>>> On 11/06/2013 01:34 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses >>>>> tickethttps://fedorahosted.org/freeipa/ticket/4005. ACK to both patches, pushed to: master: 3acec1267ea3e1f4faa8757d384386d8035dd6cf ipa-4-1: be4d5bf86336825aed2a9038ebc5caff713d6b0a -- Petr? From pviktori at redhat.com Tue Sep 9 09:59:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Sep 2014 11:59:23 +0200 Subject: [Freeipa-devel] [PATCH 0032] Hardcoded lib dir in freeipa.spec In-Reply-To: References: Message-ID: <540ECF7B.9040808@redhat.com> On 09/08/2014 04:10 PM, Gabe Alford wrote: > Hello, > > This patch should fix https://fedorahosted.org/freeipa/ticket/4528 > > Thanks, > > Gabe Thank you! ACK, pushed to: master: 8cb27bfa4fe73fa4c236f5e7d9591a28ee064f2b ipa-4-1: ce86e5d874b86a5118a84459e0624f61c49210d6 -- Petr? From pvoborni at redhat.com Tue Sep 9 11:52:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Sep 2014 13:52:31 +0200 Subject: [Freeipa-devel] Fwd: [freeipa] update to Java/8 In-Reply-To: <540991F0.1060706@redhat.com> References: <20140902174113.7CF5532485@pkgs01.phx2.fedoraproject.org> <540991F0.1060706@redhat.com> Message-ID: <540EE9FF.9060008@redhat.com> On 5.9.2014 12:35, Martin Kosek wrote: > Petr, why do we require java-1.7.0-openjdk in BuildRequires anyway? Shouldn't > rhino be enough? I don't think that rhino pulls Java. The correct patch would be the one which we already used upstream: http://www.redhat.com/archives/freeipa-devel/2014-August/msg00111.html Basically replace java-1.7.0-openjdk with java-headless > > > -------- Original Message -------- > Subject: [freeipa] update to Java/8 > Date: Tue, 2 Sep 2014 17:41:13 +0000 (UTC) > From: P?draig Brady > To: freeipa-owner at fedoraproject.org, scm-commits at lists.fedoraproject.org > > commit c1d3c76c37530d0608f710f986be1614d2ed848b > Author: P?draig Brady

> Date: Tue Sep 2 18:40:05 2014 +0100 > > update to Java/8 > > Java/7 is no longer available in rawhide, > so update to allow rebuilds to proceed. > > freeipa.spec | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > --- > diff --git a/freeipa.spec b/freeipa.spec > index f871260..2f8eac0 100644 > --- a/freeipa.spec > +++ b/freeipa.spec > @@ -67,7 +67,7 @@ BuildRequires: m2crypto > BuildRequires: check > BuildRequires: libsss_idmap-devel > BuildRequires: libsss_nss_idmap-devel > -BuildRequires: java-1.7.0-openjdk > +BuildRequires: java-1.8.0-openjdk > BuildRequires: rhino > BuildRequires: libverto-devel > BuildRequires: systemd > > -- Petr Vobornik From pviktori at redhat.com Tue Sep 9 12:06:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Sep 2014 14:06:43 +0200 Subject: [Freeipa-devel] Fwd: [freeipa] update to Java/8 In-Reply-To: <540EE9FF.9060008@redhat.com> References: <20140902174113.7CF5532485@pkgs01.phx2.fedoraproject.org> <540991F0.1060706@redhat.com> <540EE9FF.9060008@redhat.com> Message-ID: <540EED53.7090402@redhat.com> On 09/09/2014 01:52 PM, Petr Vobornik wrote: > On 5.9.2014 12:35, Martin Kosek wrote: >> Petr, why do we require java-1.7.0-openjdk in BuildRequires anyway? >> Shouldn't >> rhino be enough? > > I don't think that rhino pulls Java. The correct patch would be the one > which we already used upstream: > > http://www.redhat.com/archives/freeipa-devel/2014-August/msg00111.html > > Basically replace java-1.7.0-openjdk with java-headless This is already in 4.0.2, released to f21 updates-testing a week after P?draig's update. -- Petr? From mbasti at redhat.com Tue Sep 9 14:25:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Sep 2014 16:25:03 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files. In-Reply-To: <54097B62.1080307@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> <54007359.1000102@redhat.com> <5405B080.4010509@redhat.com> <5406EF52.1000403@redhat.com> <5407203B.3030709@redhat.com> <540724D1.6020506@redhat.com> <540729A7.3020203@redhat.com> <54083F96.50509@redhat.com> <54084AA8.3020103@redhat.com> <54084F99.3060409@redhat.com> <5408647F.2040705@redhat.com> <54097B62.1080307@redhat.com> Message-ID: <540F0DBF.8070008@redhat.com> On 05/09/14 10:59, Martin Kosek wrote: > On 09/04/2014 03:09 PM, Jan Cholasta wrote: >> Dne 4.9.2014 v 13:40 Martin Kosek napsal(a): >>> On 09/04/2014 01:19 PM, Jan Cholasta wrote: >>>> Dne 4.9.2014 v 12:31 David Kupka napsal(a): >>>>> On 09/03/2014 04:45 PM, Jan Cholasta wrote: >>>>>> Dne 3.9.2014 v 16:25 David Kupka napsal(a): >>>>>>> On 09/03/2014 04:05 PM, Jan Cholasta wrote: >>>>>>>> Dne 3.9.2014 v 12:37 David Kupka napsal(a): >>>>>>>>> On 09/02/2014 01:56 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 29.8.2014 v 14:34 David Kupka napsal(a): >>>>>>>>>>> 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. >>>>>>>>>> I didn't notice the patch is targeted for 4.0. Can you please provide >>>>>>>>>> patches for both ipa-4-0 and ipa-4-1/master? >>>>>>>>>> >>>>>>>>> Attached, 0008-5 works on master/ipa-4-1 and 0008-5-ipa40 works on >>>>>>>>> ipa-4-0. >>>>>>>> There is a little bug in ipa-upgradeconfig in the 4.0 version of the >>>>>>>> patch. This is wrong: >>>>>>>> >>>>>>>> for request in requests: >>>>>>>> nss_dir, nickname, ca_name, pre_command, post_command, profile >>>>>>>> = request >>>>>>>> criteria = { >>>>>>>> 'cert-database': nss_dir, >>>>>>>> 'cert-nickname': nickname, >>>>>>>> 'ca-name': ca_name, >>>>>>>> 'template-profile': profile, >>>>>>>> } >>>>>>>> >>>>>>>> It should be: >>>>>>>> >>>>>>>> for nss_dir, nickname, ca_name, pre_command, post_command in >>>>>>>> requests: >>>>>>>> criteria = { >>>>>>>> 'cert-database': nss_dir, >>>>>>>> 'cert-nickname': nickname, >>>>>>>> 'ca-name': ca_name, >>>>>>>> } >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>> You removed the comments, but left the attributes there. You should >>>>>>>>>> remove them as well, they are not necessary, as you set them all in >>>>>>>>>> __init__(). >>>>>>>>>> >>>>>>>>> Removed. >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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(). >>>>>>>> You no longer check if the profile argument is set in modify() - either >>>>>>>> re-introduce the check, or remove the default value of the argument to >>>>>>>> make it mandatory. >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>> OK, no need to include the TODO comment though. >>>>>>>>>> >>>>>>>>>>>> I haven't done functional testing yet, expect more comments later. >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>> 12) ipa-client-install still uses ipa-getcert instead of certmonger >>>>>>>>>> API >>>>>>>>>> to request the host certificate, but since we plan on stopping doing >>>>>>>>>> that (https://fedorahosted.org/freeipa/ticket/4449), I guess you >>>>>>>>>> don't >>>>>>>>>> have to do anything about it. >>>>>>>>> Ok. I will leave it on you since you are owner of this ticket. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 13) You require dict for criteria in get_request_id, but you pass >>>>>>>>>> tuples >>>>>>>>>> to it in ipa-upgradeconfig, ipa-cacert-manage and ipa-certupdate, >>>>>>>>>> which >>>>>>>>>> makes them fail. >>>>>>>>> Good point, fixed. >>>>>>>> I forgot about ipaserver.install.plugins.ca_renewal_master (sorry), it >>>>>>>> should be fixed as well. >>>>>>>> >>>>>>> I need to check my patches more carefully, thank for the patience. >>>>>>> >>>>>> And I need to do my reviews more carefully: in ca_renewal_master, the >>>>>> "cert-storage" criterium should in fact be "cert-database". >>>>>> >>>>>> ACK after you fix the above. >>>>>> >>>>> Fixed together with other issues discussed on IRC. Please review it one >>>>> more time. >>>> Thanks, ACK. >>>> >>> Thanks! But as I just found out, neither patch applies to ipa-4-1 branch. And >>> as the merge is not straightforward, I would leave the backport rather either >>> to Jan or David. >>> >>> Martin >>> >> Here. >> > Thanks, I just had to remove one pylint bug: > > ipaserver/install/cainstance.py:324: [E0601(used-before-assignment), > stop_tracking_certificates] Using variable 'e' before assignment) > > Pushed to master, ipa-4-1, ipa-4-0. > > Martin > I found a problem during upgrade https://fedorahosted.org/freeipa/ticket/4529 -- Martin Basti From pvoborni at redhat.com Tue Sep 9 15:48:57 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Sep 2014 17:48:57 +0200 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <54076F94.4030100@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> <53F6FFE3.3070302@redhat.com> <54076F94.4030100@redhat.com> Message-ID: <540F2169.5000103@redhat.com> On 3.9.2014 21:44, Endi Sukma Dewata wrote: > On 8/22/2014 3:31 AM, Petr Vobornik wrote: >> 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 > >>>> [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. > > Can the users tell which type of token they have based on the existing > fields? There is a model field which is populated with the type (e.g. > totp or hotp). But since the value can be changed to anything it's not a > reliable way to determine the type. I don't think it's very > user-friendly to ask the user to see whether the type-specific fields > are shown in order to determine the type. > > I can't say there's a big benefit by adding the field, but maybe some > admins might find it useful, and it can be used to sort/filter out > search results. > >> 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. > > Yes, if people can add an attribute usually they will expect to be able > to see what they added. The issue is that it's not an attribute per se. Nathaniel: do you think we should add a virtual output param(computed from object class) for the token type since 'model' could be easily overwritten? I would prefer to do it both in Web UI and CLI. > >>> 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? > > On a read-only page I think it's OK to hide empty fields. But on edit > page I don't think we should do that by default. Maybe we should first clarify what is a read-only page. All details pages are writable if user has the rights or read-only if he doesn't. But mostly it depends on individual fields/attributes. > > Does "empty" mean "unset", or "blank" like empty string/array? Does > "unset" always mean "non-editable and invisible" and "blank" always mean > "editable and visible but it's just empty"? If this definition isn't > strictly followed there could be an editable field that accidentally > gets hidden because it's empty. My intent was to show everything what user can edit. And hide fields: 1. for which he doesn't have read rights 2. have no (undefined) or empty('') value 3. are explicitly hidden by other logic - not related to this patch When thinking about #1. Maybe we should base it on a presence or rather not presence of a specific objectclass, rather than on a value. That way it would be less confusing for newcomers. The logic is: if fields is bound to an object class and the class is not present (that also means we don't have attribute level rights) -> hide it. #2 is questionable. IMHO it would require user tests. Also hiding on '' value might not be always desirable. Nevertheless I like the behavior but it may be caused by the fact that I already know what to expect. > > Generally if a field is supposed to be hidden in an edit page because of > other condition (e.g. token type), not because of the value, the code > should also use that condition instead of relying on the value being > unset. In this particular case, instead of: > > if (field !== undefined) { > // display field > } > > we probably should do: > > var type = ... > > if (type == 'hotp') { > // display hotp fields > > } else { // totp > // display totp fields > } I agree - use case #3. > > For now the type can be determined by the availability of certain > type-specific fields, but in the future we may add the type itself. > btw somewhere is a rebase issue which leads too: if (that.readable !== undefined) { visible = visible && that.readable; } if (that.readable !== undefined) { visible = visible && that.readable; } I'll fix that when we agree on an approach. snip > >>> 4. If no "Owner" is specified when adding a token, it will default to >>> admin. Is this the intended behavior? >> >> Sadly yes. > > Maybe the adder dialog should show admin (or the current user?) as the > default owner instead of empty? > Note: all patches except for 727 are ACKed. -- Petr Vobornik From npmccallum at redhat.com Tue Sep 9 17:52:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 09 Sep 2014 13:52:42 -0400 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <540F2169.5000103@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> <53F6FFE3.3070302@redhat.com> <54076F94.4030100@redhat.com> <540F2169.5000103@redhat.com> Message-ID: <1410285162.3283.0.camel@redhat.com> On Tue, 2014-09-09 at 17:48 +0200, Petr Vobornik wrote: > Nathaniel: do you think we should add a virtual output param(computed > from object class) for the token type since 'model' could be easily > overwritten? I would prefer to do it both in Web UI and CLI. That seems reasonable to me. From dkupka at redhat.com Wed Sep 10 11:15:35 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 10 Sep 2014 13:15:35 +0200 Subject: [Freeipa-devel] [PATCH] 0014 Fix typo causing ipa-upgradeconfig to fail Message-ID: <541032D7.5050207@redhat.com> https://fedorahosted.org/freeipa/ticket/4529 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0014-Fix-typo-causing-ipa-upgradeconfig-to-fail.patch Type: text/x-patch Size: 1050 bytes Desc: not available URL: From pviktori at redhat.com Wed Sep 10 11:34:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Sep 2014 13:34:29 +0200 Subject: [Freeipa-devel] [PATCH] 11 - re-enable uninstall option in ipa-kra-install In-Reply-To: <1409627109.4471.8.camel@aleeredhat.laptop> References: <1409627109.4471.8.camel@aleeredhat.laptop> Message-ID: <54103745.2070101@redhat.com> On 09/02/2014 05:05 AM, Ade Lee wrote: > Re-enable uninstall feature for ipa-kra-install > > The underlying Dogtag issue (Dogtag ticket 1113) has been fixed. > We can therefore re-enable the uninstall option for ipa-kra-install. > Also, fixes an incorrect path in the ipa-pki-proxy.conf, and adds > a debug statement to provide status to the user when an uninstall > is done. Also, re-added the no_host_dns option which is used when > unpacking a replica file. > > Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 > > Please review. A new COPR Dogtag build with the relevant fix for ticket > 1113 has been built. (pki-core-10.2.0-0.8.fc20) Please update your > Dogtag build to this version. > > Thanks, > Ade ACK To be pushed to master when fedorahosted comes back online. -- Petr? From pviktori at redhat.com Wed Sep 10 13:10:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Sep 2014 15:10:59 +0200 Subject: [Freeipa-devel] [PATCHES 247-259] ID views - management part In-Reply-To: <53DB6C2E.1050501@redhat.com> References: <53DB6C2E.1050501@redhat.com> Message-ID: <54104DE3.2050309@redhat.com> On 08/01/2014 12:30 PM, Tomas Babej wrote: > 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. > Not tested yet, but here are my comments on the patches: 0247: The change to copy-schema-to-ca is not necessary. This is only used for servers installed with Dogtag 9; for such installs new schema is added online (to 99-user.ldif), so it will be replicated to the CA DS correctly. Did you register the new OIDs? 0248-0249 look good 0250: With so many names imported from one module, I find it more readable to `from ipalib.plugins import baseldap`, and use qualified names later. Same in the 2 other patches. This is personal preference/tip, feel free to disagree :) 0521: Could you also kill the backslash in _hostname_validator? 0252: Typo in __doc__, should be "This functionality is primarily used"? {idview,idoverride}.takes_params: flags needs to be a set -- here you've specified 11 single-letter flags. (Don't we all love Python's iterable strings.) Only one `ipa help` topic will be created for idview and idoverride. Is that intended? The pattern_errmsg in idoverride's uid should be expanded to fully describe the pattern. 0253 looks good 0254: The DN refactoring is done; I don't think the asserts in pre_callbacks are necessary any more. 0258: idview_apply: typo in hostgroup doc, should be "hosts to apply the ID view to" and "after running the idview-apply command". Typos in output params, should be e.g. "this ID view" idview_apply.execute: Is there a reason for calling idview_show instead of get_dn_if_exists? idview_apply.execute: failed['hostgroup'].append((hostgroup, str(e))) -- str(e) doesn't include the name of the exception, which is usually important Calling a Command (here, host_mod) from another Command is, at the very least, quite slow, with all the validation and detailed output. It's also a debugging nightmare when things go wrong. And the _exc_wrapper is an even worse debugging nightmare. If you need some functionality in the host plugin that you need, put it in a function and call that. Otherwise use ldap directly. Do we have some precedent for the 'No host was affected.' message? Consumers of the JSON API shouldn't need to cpecial-case this string. By subclassing idview_unapply from idview_apply you're violating Liskov's substitution principle. Make a common base class for them. 0259: show_id_overrides: cn is a MUST attribute in ipa*Override; use view.single_value['cn'] instead of get(). In enumerate_hosts, is None okay if cn is missing? -- Petr? From pviktori at redhat.com Wed Sep 10 13:15:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Sep 2014 15:15:53 +0200 Subject: [Freeipa-devel] [PATCHES 247-259] ID views - management part In-Reply-To: <54104DE3.2050309@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> Message-ID: <54104F09.7030007@redhat.com> On 09/10/2014 03:10 PM, Petr Viktorin wrote: > On 08/01/2014 12:30 PM, Tomas Babej wrote: >> 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. Oh, missed this for some reason, sorry. But I replied inline. I believe calling Commands from Commands is bad; if you need some common functionality it should be put in a Python function. Do exception callbacks help here in any way? >> >> The commands also need more helpful documentation, I am working on that. >> > > Not tested yet, but here are my comments on the patches: > > 0247: > The change to copy-schema-to-ca is not necessary. This is only used for > servers installed with Dogtag 9; for such installs new schema is added > online (to 99-user.ldif), so it will be replicated to the CA DS correctly. > > Did you register the new OIDs? > > 0248-0249 look good > > 0250: > With so many names imported from one module, I find it more readable to > `from ipalib.plugins import baseldap`, and use qualified names later. > Same in the 2 other patches. > This is personal preference/tip, feel free to disagree :) > > 0521: > Could you also kill the backslash in _hostname_validator? > > 0252: > Typo in __doc__, should be "This functionality is primarily used"? > > {idview,idoverride}.takes_params: flags needs to be a set -- here you've > specified 11 single-letter flags. (Don't we all love Python's iterable > strings.) > > Only one `ipa help` topic will be created for idview and idoverride. Is > that intended? > > The pattern_errmsg in idoverride's uid should be expanded to fully > describe the pattern. > > 0253 looks good > > 0254: > The DN refactoring is done; I don't think the asserts in pre_callbacks > are necessary any more. > > 0258: > idview_apply: typo in hostgroup doc, should be "hosts to apply the ID > view to" and "after running the idview-apply command". > Typos in output params, should be e.g. "this ID view" > > idview_apply.execute: Is there a reason for calling idview_show instead > of get_dn_if_exists? > > idview_apply.execute: > failed['hostgroup'].append((hostgroup, str(e))) -- str(e) doesn't > include the name of the exception, which is usually important > > Calling a Command (here, host_mod) from another Command is, at the very > least, quite slow, with all the validation and detailed output. It's > also a debugging nightmare when things go wrong. And the _exc_wrapper is > an even worse debugging nightmare. > If you need some functionality in the host plugin that you need, put it > in a function and call that. Otherwise use ldap directly. > > Do we have some precedent for the 'No host was affected.' message? > Consumers of the JSON API shouldn't need to cpecial-case this string. > > By subclassing idview_unapply from idview_apply you're violating > Liskov's substitution principle. Make a common base class for them. > > 0259: > show_id_overrides: cn is a MUST attribute in ipa*Override; use > view.single_value['cn'] instead of get(). In enumerate_hosts, is None > okay if cn is missing? > > -- Petr? From jcholast at redhat.com Wed Sep 10 13:18:34 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Sep 2014 15:18:34 +0200 Subject: [Freeipa-devel] [PATCH] 0014 Fix typo causing ipa-upgradeconfig to fail In-Reply-To: <541032D7.5050207@redhat.com> References: <541032D7.5050207@redhat.com> Message-ID: <54104FAA.3070605@redhat.com> Dne 10.9.2014 v 13:15 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4529 ACK. -- Jan Cholasta From pvoborni at redhat.com Wed Sep 10 14:59:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 10 Sep 2014 16:59:10 +0200 Subject: [Freeipa-devel] [PATCH] 746-747 append domain into network.negotiate-auth.trusted-uris In-Reply-To: <5408BCFB.1080108@redhat.com> References: <5400A39F.7000905@redhat.com> <5408BCFB.1080108@redhat.com> Message-ID: <5410673E.9040408@redhat.com> On 4.9.2014 21:26, Endi Sukma Dewata wrote: > On 8/29/2014 11:00 AM, Petr Vobornik wrote: >> [PATCH] 746 webui: append network.negotiate-auth.trusted-uris >> >> https://fedorahosted.org/freeipa/ticket/4478 > > Some comments/questions: > > 1. If I'm reading this correctly, if the preference is currently empty, > the method will just return without setting the new value. Fixed. Yes, even if there was 'continue', it would be wrong. > > 2. If the new value already exists, the method will just return. > Shouldn't it "continue" with the rest of the loop instead of "return"? > This applies to #1 as well. Yes, fixed. > > 3. Using indexOf() to find a URI in a string can produce false matches. > For example, aa.com will match baa.com. Ideally the existing value > should be parsed into a collection of URI's, then the new URI should be > matched using a proper URI matching algorithm. Fixed with function which matches splitted and striped values using strict equality. > >> [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 > > ACK. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0746-1-webui-append-network.negotiate-auth.trusted-uris.patch Type: text/x-patch Size: 2493 bytes Desc: not available URL: From edewata at redhat.com Wed Sep 10 17:01:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Sep 2014 12:01:52 -0500 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <540F2169.5000103@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> <53F6FFE3.3070302@redhat.com> <54076F94.4030100@redhat.com> <540F2169.5000103@redhat.com> Message-ID: <54108400.7030101@redhat.com> On 9/9/2014 10:48 AM, Petr Vobornik wrote: >>>>> [PATCH] 727 webui: hide empty fields and sections >>>> 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. ACK. >>> What do you think about setting `hide_empty_widgets` global setting to >>> True? >> >> On a read-only page I think it's OK to hide empty fields. But on edit >> page I don't think we should do that by default. > > Maybe we should first clarify what is a read-only page. All details > pages are writable if user has the rights or read-only if he doesn't. > But mostly it depends on individual fields/attributes. Read-only page is a page that does not provide editable interface for all fields displayed in the page. For example, the fields in the certificate details page are never editable, so suppose it has empty optional fields (e.g. cert extensions?) we probably can hide those fields without confusing users. Other details pages have read-only and edit modes, so it probably makes more sense to keep the structure identical in both modes so optional fields like 'Job Title' will always be visible. However, it's also possible to hide the empty fields in the read-only mode if necessary to clean up the display. >> Does "empty" mean "unset", or "blank" like empty string/array? Does >> "unset" always mean "non-editable and invisible" and "blank" always mean >> "editable and visible but it's just empty"? If this definition isn't >> strictly followed there could be an editable field that accidentally >> gets hidden because it's empty. > > My intent was to show everything what user can edit. And hide fields: > 1. for which he doesn't have read rights > 2. have no (undefined) or empty('') value > 3. are explicitly hidden by other logic - not related to this patch > > When thinking about #1. Maybe we should base it on a presence or rather > not presence of a specific objectclass, rather than on a value. That way > it would be less confusing for newcomers. The logic is: if fields is > bound to an object class and the class is not present (that also means > we don't have attribute level rights) -> hide it. That would be hiding/displaying based on structural reason instead of user rights. How about an attribute that exists but the user doesn't have the read permission? I think we need to check both structural and user rights. > #2 is questionable. IMHO it would require user tests. Also hiding on '' > value might not be always desirable. Nevertheless I like the behavior > but it may be caused by the fact that I already know what to expect. Before we can make this behavior the default/global, how do we make sure that optional fields such as 'Job Title' will always visible in the edit page even if it's empty? I think to avoid unexpected behavior hiding based on empty value should only be done in read-only page as I mentioned above. >> Generally if a field is supposed to be hidden in an edit page because of >> other condition (e.g. token type), not because of the value, the code >> should also use that condition instead of relying on the value being >> unset. In this particular case, instead of: >> >> if (field !== undefined) { >> // display field >> } >> >> we probably should do: >> >> var type = ... >> >> if (type == 'hotp') { >> // display hotp fields >> >> } else { // totp >> // display totp fields >> } > > I agree - use case #3. This is actually hiding/displaying based on structural reason too. In this case the structure is reflected in the (virtual) 'type' field. >>>> 4. If no "Owner" is specified when adding a token, it will default to >>>> admin. Is this the intended behavior? >>> >>> Sadly yes. >> >> Maybe the adder dialog should show admin (or the current user?) as the >> default owner instead of empty? >> > > Note: all patches except for 727 are ACKed. It's all ACKed now. Everything else can be handled separately. -- Endi S. Dewata From edewata at redhat.com Wed Sep 10 17:33:09 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 10 Sep 2014 12:33:09 -0500 Subject: [Freeipa-devel] [PATCH] 746-747 append domain into network.negotiate-auth.trusted-uris In-Reply-To: <5410673E.9040408@redhat.com> References: <5400A39F.7000905@redhat.com> <5408BCFB.1080108@redhat.com> <5410673E.9040408@redhat.com> Message-ID: <54108B55.60701@redhat.com> On 9/10/2014 9:59 AM, Petr Vobornik wrote: > On 4.9.2014 21:26, Endi Sukma Dewata wrote: >> On 8/29/2014 11:00 AM, Petr Vobornik wrote: >>> [PATCH] 746 webui: append network.negotiate-auth.trusted-uris >>> >>> https://fedorahosted.org/freeipa/ticket/4478 >> >> Some comments/questions: >> >> 1. If I'm reading this correctly, if the preference is currently empty, >> the method will just return without setting the new value. > > Fixed. Yes, even if there was 'continue', it would be wrong. > >> >> 2. If the new value already exists, the method will just return. >> Shouldn't it "continue" with the rest of the loop instead of "return"? >> This applies to #1 as well. > > Yes, fixed. > >> >> 3. Using indexOf() to find a URI in a string can produce false matches. >> For example, aa.com will match baa.com. Ideally the existing value >> should be parsed into a collection of URI's, then the new URI should be >> matched using a proper URI matching algorithm. > > Fixed with function which matches splitted and striped values using > strict equality. ACK. A possible improvement is to normalize the current value to remove excessive white spaces. -- Endi S. Dewata From npmccallum at redhat.com Wed Sep 10 21:41:56 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 10 Sep 2014 17:41:56 -0400 Subject: [Freeipa-devel] [PATCH 0063] Update qrcode support for newer python-qrcode Message-ID: <1410385316.3756.7.camel@redhat.com> This substantially reduces the FreeIPA dependencies and allows QR codes to fit in a standard terminal. https://fedorahosted.org/freeipa/ticket/4430 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0063-Update-qrcode-support-for-newer-python-qrcode.patch Type: text/x-patch Size: 2109 bytes Desc: not available URL: From npmccallum at redhat.com Wed Sep 10 21:50:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 10 Sep 2014 17:50:09 -0400 Subject: [Freeipa-devel] [PATCH 0063] Update qrcode support for newer python-qrcode In-Reply-To: <1410385316.3756.7.camel@redhat.com> References: <1410385316.3756.7.camel@redhat.com> Message-ID: <1410385809.3756.9.camel@redhat.com> On Wed, 2014-09-10 at 17:41 -0400, Nathaniel McCallum wrote: > This substantially reduces the FreeIPA dependencies and allows > QR codes to fit in a standard terminal. > > https://fedorahosted.org/freeipa/ticket/4430 A note about this patch: Quick review of this would be excellent. Even better would be someone volunteering to backport (patch should apply cleanly) this for Fedora 21 Alpha. This will substantially reduce the install media size for Fedora Server. A build-root override has already been requested for building against the new python-qrcode. Nathaniel From mkosek at redhat.com Thu Sep 11 07:25:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 09:25:51 +0200 Subject: [Freeipa-devel] Fwd: [freeipa] update to Java/8 In-Reply-To: <540EE9FF.9060008@redhat.com> References: <20140902174113.7CF5532485@pkgs01.phx2.fedoraproject.org> <540991F0.1060706@redhat.com> <540EE9FF.9060008@redhat.com> Message-ID: <54114E7F.7030006@redhat.com> My point was - we do not need Java for IPA package build (or do we?), we need rhino. Shouldn't then java be a dependency of rhino instead of freeipa package? On 09/09/2014 01:52 PM, Petr Vobornik wrote: > On 5.9.2014 12:35, Martin Kosek wrote: >> Petr, why do we require java-1.7.0-openjdk in BuildRequires anyway? Shouldn't >> rhino be enough? > > I don't think that rhino pulls Java. The correct patch would be the one which > we already used upstream: > > http://www.redhat.com/archives/freeipa-devel/2014-August/msg00111.html > > Basically replace java-1.7.0-openjdk with java-headless > >> >> >> -------- Original Message -------- >> Subject: [freeipa] update to Java/8 >> Date: Tue, 2 Sep 2014 17:41:13 +0000 (UTC) >> From: P?draig Brady >> To: freeipa-owner at fedoraproject.org, scm-commits at lists.fedoraproject.org >> >> commit c1d3c76c37530d0608f710f986be1614d2ed848b >> Author: P?draig Brady

>> Date: Tue Sep 2 18:40:05 2014 +0100 >> >> update to Java/8 >> >> Java/7 is no longer available in rawhide, >> so update to allow rebuilds to proceed. >> >> freeipa.spec | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> --- >> diff --git a/freeipa.spec b/freeipa.spec >> index f871260..2f8eac0 100644 >> --- a/freeipa.spec >> +++ b/freeipa.spec >> @@ -67,7 +67,7 @@ BuildRequires: m2crypto >> BuildRequires: check >> BuildRequires: libsss_idmap-devel >> BuildRequires: libsss_nss_idmap-devel >> -BuildRequires: java-1.7.0-openjdk >> +BuildRequires: java-1.8.0-openjdk >> BuildRequires: rhino >> BuildRequires: libverto-devel >> BuildRequires: systemd >> >> > > From pvoborni at redhat.com Thu Sep 11 07:44:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 09:44:33 +0200 Subject: [Freeipa-devel] [PATCH] 746-747 append domain into network.negotiate-auth.trusted-uris In-Reply-To: <54108B55.60701@redhat.com> References: <5400A39F.7000905@redhat.com> <5408BCFB.1080108@redhat.com> <5410673E.9040408@redhat.com> <54108B55.60701@redhat.com> Message-ID: <541152E1.20609@redhat.com> On 10.9.2014 19:33, Endi Sukma Dewata wrote: > On 9/10/2014 9:59 AM, Petr Vobornik wrote: >> On 4.9.2014 21:26, Endi Sukma Dewata wrote: >>> On 8/29/2014 11:00 AM, Petr Vobornik wrote: >>>> [PATCH] 746 webui: append network.negotiate-auth.trusted-uris >>>> >>>> https://fedorahosted.org/freeipa/ticket/4478 >>> >>> Some comments/questions: >>> >>> 1. If I'm reading this correctly, if the preference is currently empty, >>> the method will just return without setting the new value. >> >> Fixed. Yes, even if there was 'continue', it would be wrong. >> >>> >>> 2. If the new value already exists, the method will just return. >>> Shouldn't it "continue" with the rest of the loop instead of "return"? >>> This applies to #1 as well. >> >> Yes, fixed. >> >>> >>> 3. Using indexOf() to find a URI in a string can produce false matches. >>> For example, aa.com will match baa.com. Ideally the existing value >>> should be parsed into a collection of URI's, then the new URI should be >>> matched using a proper URI matching algorithm. >> >> Fixed with function which matches splitted and striped values using >> strict equality. > > ACK. A possible improvement is to normalize the current value to remove > excessive white spaces. > Pushed to: master: * 388a6432ed9c45ca84240c596f091268176d46f9 webui: append network.negotiate-auth.trusted-uris * 4e6a3c69b0e07e5ec32381a47281ad88e41aae5d install: create ff krb extension on every install, replica install and upgrade ipa-4-1: * de90d7d44930cfa615e50ed022de7ea48e31609a webui: append network.negotiate-auth.trusted-uris * 97aebf8635ba26398353c91de9ca60844bea8c27 install: create ff krb extension on every install, replica install and upgrade -- Petr Vobornik From pspacek at redhat.com Thu Sep 11 09:59:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Sep 2014 11:59:41 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks Message-ID: <5411728D.8050405@redhat.com> Hello, I was fighting with random crashes for couple of days ... and discovered that run_exclusive_enter()/isc_task_beginexclusive() usage was completely incorrect and didn't actually lock anything. This series of patches reworks internal locking (and related event system) to work around limitations of isc_task_beginexclusive() mechanism. It would be better to get rid of isc_task_beginexclusive() completely but IMHO it is not possible because of BIND's dns_view*() functions have to be guarded with it. Testing is going to be interesting because we are speaking about race conditions. I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside with random A/AAAA/TXT RRs. My LDIF is here: http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz I was able to randomly reproduce various crashes when BIND was running with more threads than usually. You can try to run BIND with this command (as root) and play games with -n parameter: $ export KRB5_KTNAME="/etc/named.keytab" $ named -4 -g -u named -m record -n 10 Please test also the case where BIND receives SIGINT during start-up. It is possible to run BIND with commands above and wait for message: 11-Sep-2014 11:54:58.092 running At this point send SIGINT (CTRL+C) to BIND and see what happens. It could crash or deadlock. It is necessary to send the signal before BIND prints this message: 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 Let me know if you need any assistance. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0291-Rework-locking-in-settings.c-module.patch Type: text/x-patch Size: 13083 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0292-Rework-locking-around-DNS-views.patch Type: text/x-patch Size: 18372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0293-Lock-syncrepl-queue-avoid-race-between-zones-and-res.patch Type: text/x-patch Size: 4052 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0294-Fix-deadlocks-on-shutdown-caused-by-sync_-_wait-call.patch Type: text/x-patch Size: 12826 bytes Desc: not available URL: From pviktori at redhat.com Thu Sep 11 10:27:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 12:27:42 +0200 Subject: [Freeipa-devel] [PATCH 0063] Update qrcode support for newer python-qrcode In-Reply-To: <1410385809.3756.9.camel@redhat.com> References: <1410385316.3756.7.camel@redhat.com> <1410385809.3756.9.camel@redhat.com> Message-ID: <5411791E.7050506@redhat.com> On 09/10/2014 11:50 PM, Nathaniel McCallum wrote: > On Wed, 2014-09-10 at 17:41 -0400, Nathaniel McCallum wrote: >> This substantially reduces the FreeIPA dependencies and allows >> QR codes to fit in a standard terminal. >> >> https://fedorahosted.org/freeipa/ticket/4430 > > A note about this patch: > > Quick review of this would be excellent. > > Even better would be someone volunteering to backport (patch should > apply cleanly) this for Fedora 21 Alpha. This will substantially reduce > the install media size for Fedora Server. A build-root override has > already been requested for building against the new python-qrcode. python-qrcode 5.0.1 is now built for f20 in the FreeIPA COPR: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ -- Petr? From pvoborni at redhat.com Thu Sep 11 10:49:23 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 12:49:23 +0200 Subject: [Freeipa-devel] [PATCH 0063] Update qrcode support for newer python-qrcode In-Reply-To: <1410385809.3756.9.camel@redhat.com> References: <1410385316.3756.7.camel@redhat.com> <1410385809.3756.9.camel@redhat.com> Message-ID: <54117E33.70301@redhat.com> On 10.9.2014 23:50, Nathaniel McCallum wrote: > On Wed, 2014-09-10 at 17:41 -0400, Nathaniel McCallum wrote: >> This substantially reduces the FreeIPA dependencies and allows >> QR codes to fit in a standard terminal. >> >> https://fedorahosted.org/freeipa/ticket/4430 > > A note about this patch: > > Quick review of this would be excellent. > > Even better would be someone volunteering to backport (patch should > apply cleanly) this for Fedora 21 Alpha. This will substantially reduce > the install media size for Fedora Server. A build-root override has > already been requested for building against the new python-qrcode. > > Nathaniel > ACK Pushed to: master: 9c50f9f957c98099ca5201b6ae742c166617e250 ipa-4-1: 04368580a2802fa415c45891858bde16b5d9feab ipa-4-0: 0f200143db67a3f56f1c15951e173a805a1b9ab1 -- Petr Vobornik From mkosek at redhat.com Thu Sep 11 11:31:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 13:31:44 +0200 Subject: [Freeipa-devel] [PATCH] 0014 Fix typo causing ipa-upgradeconfig to fail In-Reply-To: <54104FAA.3070605@redhat.com> References: <541032D7.5050207@redhat.com> <54104FAA.3070605@redhat.com> Message-ID: <54118820.6000107@redhat.com> On 09/10/2014 03:18 PM, Jan Cholasta wrote: > Dne 10.9.2014 v 13:15 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4529 > > ACK. > Pushed to master, ipa-4-1, ipa-4-0. Martin From mkosek at redhat.com Thu Sep 11 11:37:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 13:37:49 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? Message-ID: <5411898D.8000203@redhat.com> Hi team, It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking upgrade from older releases: https://fedorahosted.org/freeipa/ticket/4529 We also have packaging fix requested by Fedora Server roles group: https://fedorahosted.org/freeipa/ticket/4430 It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... Makes sense? Any other tickets or patches we would like to get in? Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Thu Sep 11 13:46:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 15:46:05 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411898D.8000203@redhat.com> References: <5411898D.8000203@redhat.com> Message-ID: <5411A79D.70208@redhat.com> On 09/11/2014 01:37 PM, Martin Kosek wrote: > Hi team, > > It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > upgrade from older releases: > > https://fedorahosted.org/freeipa/ticket/4529 > > We also have packaging fix requested by Fedora Server roles group: > > https://fedorahosted.org/freeipa/ticket/4430 > > It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > Makes sense? Any other tickets or patches we would like to get in? Looks like it's just those two. I'll start releasing shortly. -- Petr? From npmccallum at redhat.com Thu Sep 11 13:47:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 09:47:25 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411A79D.70208@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> Message-ID: <1410443245.2941.0.camel@redhat.com> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > On 09/11/2014 01:37 PM, Martin Kosek wrote: > > Hi team, > > > > It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > > upgrade from older releases: > > > > https://fedorahosted.org/freeipa/ticket/4529 > > > > We also have packaging fix requested by Fedora Server roles group: > > > > https://fedorahosted.org/freeipa/ticket/4430 > > > > It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > > Makes sense? Any other tickets or patches we would like to get in? > > Looks like it's just those two. I'll start releasing shortly. I'd like to get a fix in for the missing ciphers in the new NSS. I can have a patch on the list shortly. Nathaniel From mbasti at redhat.com Thu Sep 11 13:57:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Sep 2014 15:57:12 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks In-Reply-To: <5411728D.8050405@redhat.com> References: <5411728D.8050405@redhat.com> Message-ID: <5411AA38.4030309@redhat.com> On 11/09/14 11:59, Petr Spacek wrote: > Hello, > > I was fighting with random crashes for couple of days ... and > discovered that run_exclusive_enter()/isc_task_beginexclusive() usage > was completely incorrect and didn't actually lock anything. > > This series of patches reworks internal locking (and related event > system) to work around limitations of isc_task_beginexclusive() > mechanism. > > It would be better to get rid of isc_task_beginexclusive() completely > but IMHO it is not possible because of BIND's dns_view*() functions > have to be guarded with it. > > > Testing is going to be interesting because we are speaking about race > conditions. > > I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside > with random A/AAAA/TXT RRs. My LDIF is here: > http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz > > I was able to randomly reproduce various crashes when BIND was running > with more threads than usually. > > You can try to run BIND with this command (as root) and play games > with -n parameter: > $ export KRB5_KTNAME="/etc/named.keytab" > $ named -4 -g -u named -m record -n 10 > > Please test also the case where BIND receives SIGINT during start-up. > It is possible to run BIND with commands above and wait for message: > 11-Sep-2014 11:54:58.092 running > > At this point send SIGINT (CTRL+C) to BIND and see what happens. It > could crash or deadlock. > > It is necessary to send the signal before BIND prints this message: > 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 > > Let me know if you need any assistance. > I need your assistance, I haven't been able to reproduce it. Martin -- Martin Basti From mkosek at redhat.com Thu Sep 11 14:04:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 16:04:42 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410443245.2941.0.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> Message-ID: <5411ABFA.7010504@redhat.com> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>> Hi team, >>> >>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>> upgrade from older releases: >>> >>> https://fedorahosted.org/freeipa/ticket/4529 >>> >>> We also have packaging fix requested by Fedora Server roles group: >>> >>> https://fedorahosted.org/freeipa/ticket/4430 >>> >>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>> Makes sense? Any other tickets or patches we would like to get in? >> >> Looks like it's just those two. I'll start releasing shortly. > > I'd like to get a fix in for the missing ciphers in the new NSS. I can > have a patch on the list shortly. > > Nathaniel Isn't this related to https://fedorahosted.org/freeipa/ticket/4395 ? I think we do not work with the newest DS which fixed the default ciphers. Don't we need to set our SSL ciphers setting to https://fedorahosted.org/389/ticket/47838#comment:29 ? If yes, I think this is definitely a 4.0.3 candidate. Martin From lkrispen at redhat.com Thu Sep 11 14:09:54 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Sep 2014 16:09:54 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411ABFA.7010504@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> Message-ID: <5411AD32.9040206@redhat.com> On 09/11/2014 04:04 PM, Martin Kosek wrote: > On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>> Hi team, >>>> >>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>> upgrade from older releases: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4529 >>>> >>>> We also have packaging fix requested by Fedora Server roles group: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4430 >>>> >>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>> Makes sense? Any other tickets or patches we would like to get in? >>> Looks like it's just those two. I'll start releasing shortly. >> I'd like to get a fix in for the missing ciphers in the new NSS. I can >> have a patch on the list shortly. >> >> Nathaniel > Isn't this related to > https://fedorahosted.org/freeipa/ticket/4395 > ? I think we do not work with the newest DS which fixed the default ciphers. yes > > Don't we need to set our SSL ciphers setting to > > https://fedorahosted.org/389/ticket/47838#comment:29 yes tjhe attached patch tries this, but at the moment I failed to build and also to upgrade to F21 > > ? If yes, I think this is definitely a 4.0.3 candidate. > > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ticket-4395-change-ciphers-enabled-by-default.patch Type: text/x-patch Size: 2267 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 11 14:12:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:12:03 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411AD32.9040206@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> Message-ID: <1410444723.2941.1.camel@redhat.com> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: > On 09/11/2014 04:04 PM, Martin Kosek wrote: > > On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > >>> On 09/11/2014 01:37 PM, Martin Kosek wrote: > >>>> Hi team, > >>>> > >>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > >>>> upgrade from older releases: > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4529 > >>>> > >>>> We also have packaging fix requested by Fedora Server roles group: > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4430 > >>>> > >>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > >>>> Makes sense? Any other tickets or patches we would like to get in? > >>> Looks like it's just those two. I'll start releasing shortly. > >> I'd like to get a fix in for the missing ciphers in the new NSS. I can > >> have a patch on the list shortly. > >> > >> Nathaniel > > Isn't this related to > > https://fedorahosted.org/freeipa/ticket/4395 > > ? I think we do not work with the newest DS which fixed the default ciphers. > yes > > > > Don't we need to set our SSL ciphers setting to > > > > https://fedorahosted.org/389/ticket/47838#comment:29 > yes > tjhe attached patch tries this, but at the moment I failed to build and > also to upgrade to F21 I am reviewing this patch now as I am blocked on the issue. Nathaniel From npmccallum at redhat.com Thu Sep 11 14:17:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:17:39 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411AD32.9040206@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> Message-ID: <1410445059.2941.3.camel@redhat.com> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: > On 09/11/2014 04:04 PM, Martin Kosek wrote: > > On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > >>> On 09/11/2014 01:37 PM, Martin Kosek wrote: > >>>> Hi team, > >>>> > >>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > >>>> upgrade from older releases: > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4529 > >>>> > >>>> We also have packaging fix requested by Fedora Server roles group: > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4430 > >>>> > >>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > >>>> Makes sense? Any other tickets or patches we would like to get in? > >>> Looks like it's just those two. I'll start releasing shortly. > >> I'd like to get a fix in for the missing ciphers in the new NSS. I can > >> have a patch on the list shortly. > >> > >> Nathaniel > > Isn't this related to > > https://fedorahosted.org/freeipa/ticket/4395 > > ? I think we do not work with the newest DS which fixed the default ciphers. > yes > > > > Don't we need to set our SSL ciphers setting to > > > > https://fedorahosted.org/389/ticket/47838#comment:29 > yes > tjhe attached patch tries this, but at the moment I failed to build and > also to upgrade to F21 NACK LDAP error: OBJECT_CLASS_VIOLATION attribute "allowweakcipher" not allowed I suspect we are missing a spec file requirement on a newer version of 389... Nathaniel From lkrispen at redhat.com Thu Sep 11 14:21:48 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Sep 2014 16:21:48 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410445059.2941.3.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> Message-ID: <5411AFFC.60801@redhat.com> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>> Hi team, >>>>>> >>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>>>> upgrade from older releases: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>> >>>>>> We also have packaging fix requested by Fedora Server roles group: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>> >>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>>>> Makes sense? Any other tickets or patches we would like to get in? >>>>> Looks like it's just those two. I'll start releasing shortly. >>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can >>>> have a patch on the list shortly. >>>> >>>> Nathaniel >>> Isn't this related to >>> https://fedorahosted.org/freeipa/ticket/4395 >>> ? I think we do not work with the newest DS which fixed the default ciphers. >> yes >>> Don't we need to set our SSL ciphers setting to >>> >>> https://fedorahosted.org/389/ticket/47838#comment:29 >> yes >> tjhe attached patch tries this, but at the moment I failed to build and >> also to upgrade to F21 > NACKallowweakcipher > > > LDAP error: OBJECT_CLASS_VIOLATION > attribute "allowweakcipher" not allowed > > I suspect we are missing a spec file requirement on a newer version of 389... yes, you need the latest build of DS, Noriko added the allowweakcipher only yesterday. That's the problem, I wanted to wait with the ipa side patch until allowweakcipher was implemented and then on F21 ipa and 389 no longer played well and now there is a rush > > Nathaniel > From npmccallum at redhat.com Thu Sep 11 14:22:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:22:22 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411AFFC.60801@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> Message-ID: <1410445342.2941.4.camel@redhat.com> On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: > On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: > > On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: > >> On 09/11/2014 04:04 PM, Martin Kosek wrote: > >>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > >>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: > >>>>>> Hi team, > >>>>>> > >>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > >>>>>> upgrade from older releases: > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4529 > >>>>>> > >>>>>> We also have packaging fix requested by Fedora Server roles group: > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4430 > >>>>>> > >>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > >>>>>> Makes sense? Any other tickets or patches we would like to get in? > >>>>> Looks like it's just those two. I'll start releasing shortly. > >>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can > >>>> have a patch on the list shortly. > >>>> > >>>> Nathaniel > >>> Isn't this related to > >>> https://fedorahosted.org/freeipa/ticket/4395 > >>> ? I think we do not work with the newest DS which fixed the default ciphers. > >> yes > >>> Don't we need to set our SSL ciphers setting to > >>> > >>> https://fedorahosted.org/389/ticket/47838#comment:29 > >> yes > >> tjhe attached patch tries this, but at the moment I failed to build and > >> also to upgrade to F21 > > NACKallowweakcipher > > > > > > LDAP error: OBJECT_CLASS_VIOLATION > > attribute "allowweakcipher" not allowed > > > > I suspect we are missing a spec file requirement on a newer version of 389... > yes, you need the latest build of DS, Noriko added the allowweakcipher > only yesterday. > That's the problem, I wanted to wait with the ipa side patch until > allowweakcipher was implemented and then on F21 ipa and 389 no longer > played well and now there is a rush What is the status on the new 389 patch/build? From lkrispen at redhat.com Thu Sep 11 14:25:18 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Sep 2014 16:25:18 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410445342.2941.4.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> Message-ID: <5411B0CE.80303@redhat.com> On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: >> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>>>> Hi team, >>>>>>>> >>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>>>>>> upgrade from older releases: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>>>> >>>>>>>> We also have packaging fix requested by Fedora Server roles group: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>>>> >>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>>>>>> Makes sense? Any other tickets or patches we would like to get in? >>>>>>> Looks like it's just those two. I'll start releasing shortly. >>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can >>>>>> have a patch on the list shortly. >>>>>> >>>>>> Nathaniel >>>>> Isn't this related to >>>>> https://fedorahosted.org/freeipa/ticket/4395 >>>>> ? I think we do not work with the newest DS which fixed the default ciphers. >>>> yes >>>>> Don't we need to set our SSL ciphers setting to >>>>> >>>>> https://fedorahosted.org/389/ticket/47838#comment:29 >>>> yes >>>> tjhe attached patch tries this, but at the moment I failed to build and >>>> also to upgrade to F21 >>> NACKallowweakcipher >>> >>> >>> LDAP error: OBJECT_CLASS_VIOLATION >>> attribute "allowweakcipher" not allowed >>> >>> I suspect we are missing a spec file requirement on a newer version of 389... >> yes, you need the latest build of DS, Noriko added the allowweakcipher >> only yesterday. >> That's the problem, I wanted to wait with the ipa side patch until >> allowweakcipher was implemented and then on F21 ipa and 389 no longer >> played well and now there is a rush > What is the status on the new 389 patch/build? a build is here: http://copr-be.cloud.fedoraproject.org/results/nhosoi/389-ds-f21/fedora-21-x86_64/389-ds-base-1.3.3.2-a1.fc21/ > From mkosek at redhat.com Thu Sep 11 14:26:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 16:26:27 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410445342.2941.4.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> Message-ID: <5411B113.4060103@redhat.com> On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: >> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>>>> Hi team, >>>>>>>> >>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>>>>>> upgrade from older releases: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>>>> >>>>>>>> We also have packaging fix requested by Fedora Server roles group: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>>>> >>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>>>>>> Makes sense? Any other tickets or patches we would like to get in? >>>>>>> Looks like it's just those two. I'll start releasing shortly. >>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can >>>>>> have a patch on the list shortly. >>>>>> >>>>>> Nathaniel >>>>> Isn't this related to >>>>> https://fedorahosted.org/freeipa/ticket/4395 >>>>> ? I think we do not work with the newest DS which fixed the default ciphers. >>>> yes >>>>> Don't we need to set our SSL ciphers setting to >>>>> >>>>> https://fedorahosted.org/389/ticket/47838#comment:29 >>>> yes >>>> tjhe attached patch tries this, but at the moment I failed to build and >>>> also to upgrade to F21 >>> NACKallowweakcipher >>> >>> >>> LDAP error: OBJECT_CLASS_VIOLATION >>> attribute "allowweakcipher" not allowed >>> >>> I suspect we are missing a spec file requirement on a newer version of 389... >> yes, you need the latest build of DS, Noriko added the allowweakcipher >> only yesterday. >> That's the problem, I wanted to wait with the ipa side patch until >> allowweakcipher was implemented and then on F21 ipa and 389 no longer >> played well and now there is a rush Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all... Martin From npmccallum at redhat.com Thu Sep 11 14:28:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:28:59 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B0CE.80303@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B0CE.80303@redhat.com> Message-ID: <1410445739.2941.6.camel@redhat.com> On Thu, 2014-09-11 at 16:25 +0200, Ludwig Krispenz wrote: > On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: > > On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: > >> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: > >>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: > >>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: > >>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > >>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > >>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: > >>>>>>>> Hi team, > >>>>>>>> > >>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > >>>>>>>> upgrade from older releases: > >>>>>>>> > >>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 > >>>>>>>> > >>>>>>>> We also have packaging fix requested by Fedora Server roles group: > >>>>>>>> > >>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 > >>>>>>>> > >>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > >>>>>>>> Makes sense? Any other tickets or patches we would like to get in? > >>>>>>> Looks like it's just those two. I'll start releasing shortly. > >>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can > >>>>>> have a patch on the list shortly. > >>>>>> > >>>>>> Nathaniel > >>>>> Isn't this related to > >>>>> https://fedorahosted.org/freeipa/ticket/4395 > >>>>> ? I think we do not work with the newest DS which fixed the default ciphers. > >>>> yes > >>>>> Don't we need to set our SSL ciphers setting to > >>>>> > >>>>> https://fedorahosted.org/389/ticket/47838#comment:29 > >>>> yes > >>>> tjhe attached patch tries this, but at the moment I failed to build and > >>>> also to upgrade to F21 > >>> NACKallowweakcipher > >>> > >>> > >>> LDAP error: OBJECT_CLASS_VIOLATION > >>> attribute "allowweakcipher" not allowed > >>> > >>> I suspect we are missing a spec file requirement on a newer version of 389... > >> yes, you need the latest build of DS, Noriko added the allowweakcipher > >> only yesterday. > >> That's the problem, I wanted to wait with the ipa side patch until > >> allowweakcipher was implemented and then on F21 ipa and 389 no longer > >> played well and now there is a rush > > What is the status on the new 389 patch/build? > a build is here: > http://copr-be.cloud.fedoraproject.org/results/nhosoi/389-ds-f21/fedora-21-x86_64/389-ds-base-1.3.3.2-a1.fc21/ The upstream patch is not merged yet. We need 389 to merge the patch, do a release and get an official Fedora 20/21 build. Just to be clear, Fedora 21 IPA doesn't work *at all*. So this is an urgent fix. Martin, can you coordinate with 389 to prioritize a release with this fix? Nathaniel From pviktori at redhat.com Thu Sep 11 14:31:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 16:31:17 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B113.4060103@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> Message-ID: <5411B235.2070000@redhat.com> On 09/11/2014 04:26 PM, Martin Kosek wrote: > On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: >> On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: >>> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >>>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>>>>> Hi team, >>>>>>>>> >>>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>>>>>>> upgrade from older releases: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>>>>> >>>>>>>>> We also have packaging fix requested by Fedora Server roles group: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>>>>> >>>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>>>>>>> Makes sense? Any other tickets or patches we would like to get in? >>>>>>>> Looks like it's just those two. I'll start releasing shortly. >>>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can >>>>>>> have a patch on the list shortly. >>>>>>> >>>>>>> Nathaniel >>>>>> Isn't this related to >>>>>> https://fedorahosted.org/freeipa/ticket/4395 >>>>>> ? I think we do not work with the newest DS which fixed the default ciphers. >>>>> yes >>>>>> Don't we need to set our SSL ciphers setting to >>>>>> >>>>>> https://fedorahosted.org/389/ticket/47838#comment:29 >>>>> yes >>>>> tjhe attached patch tries this, but at the moment I failed to build and >>>>> also to upgrade to F21 >>>> NACKallowweakcipher >>>> >>>> >>>> LDAP error: OBJECT_CLASS_VIOLATION >>>> attribute "allowweakcipher" not allowed >>>> >>>> I suspect we are missing a spec file requirement on a newer version of 389... >>> yes, you need the latest build of DS, Noriko added the allowweakcipher >>> only yesterday. >>> That's the problem, I wanted to wait with the ipa side patch until >>> allowweakcipher was implemented and then on F21 ipa and 389 no longer >>> played well and now there is a rush > > Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > so that F20 users can upgrade to the newest FreeIPA. Are there any known issues > in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be > based on it? > > If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. -- Petr? From npmccallum at redhat.com Thu Sep 11 14:32:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:32:46 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B235.2070000@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> Message-ID: <1410445966.2941.7.camel@redhat.com> On Thu, 2014-09-11 at 16:31 +0200, Petr Viktorin wrote: > On 09/11/2014 04:26 PM, Martin Kosek wrote: > > On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: > >>> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: > >>>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: > >>>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: > >>>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: > >>>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: > >>>>>>>>> Hi team, > >>>>>>>>> > >>>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking > >>>>>>>>> upgrade from older releases: > >>>>>>>>> > >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 > >>>>>>>>> > >>>>>>>>> We also have packaging fix requested by Fedora Server roles group: > >>>>>>>>> > >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 > >>>>>>>>> > >>>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... > >>>>>>>>> Makes sense? Any other tickets or patches we would like to get in? > >>>>>>>> Looks like it's just those two. I'll start releasing shortly. > >>>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can > >>>>>>> have a patch on the list shortly. > >>>>>>> > >>>>>>> Nathaniel > >>>>>> Isn't this related to > >>>>>> https://fedorahosted.org/freeipa/ticket/4395 > >>>>>> ? I think we do not work with the newest DS which fixed the default ciphers. > >>>>> yes > >>>>>> Don't we need to set our SSL ciphers setting to > >>>>>> > >>>>>> https://fedorahosted.org/389/ticket/47838#comment:29 > >>>>> yes > >>>>> tjhe attached patch tries this, but at the moment I failed to build and > >>>>> also to upgrade to F21 > >>>> NACKallowweakcipher > >>>> > >>>> > >>>> LDAP error: OBJECT_CLASS_VIOLATION > >>>> attribute "allowweakcipher" not allowed > >>>> > >>>> I suspect we are missing a spec file requirement on a newer version of 389... > >>> yes, you need the latest build of DS, Noriko added the allowweakcipher > >>> only yesterday. > >>> That's the problem, I wanted to wait with the ipa side patch until > >>> allowweakcipher was implemented and then on F21 ipa and 389 no longer > >>> played well and now there is a rush > > > > Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > > http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > so that F20 users can upgrade to the newest FreeIPA. Are there any known issues > > in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be > > based on it? > > > > If yes, we may need to include the patch in Fedora 21 downstream only after all.. > > We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > couldn't include the patch even there. > There better be no such issues. Right now FreeIPA in Fedora 21 is completely broken. From pviktori at redhat.com Thu Sep 11 14:33:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 16:33:32 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410445739.2941.6.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B0CE.80303@redhat.com> <1410445739.2941.6.camel@redhat.com> Message-ID: <5411B2BC.4010504@redhat.com> On 09/11/2014 04:28 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:25 +0200, Ludwig Krispenz wrote: >> On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: >>>> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >>>>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>>>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>>>>>> Hi team, >>>>>>>>>> >>>>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 release, breaking >>>>>>>>>> upgrade from older releases: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>>>>>> >>>>>>>>>> We also have packaging fix requested by Fedora Server roles group: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>>>>>> >>>>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA 4.0.3 release... >>>>>>>>>> Makes sense? Any other tickets or patches we would like to get in? >>>>>>>>> Looks like it's just those two. I'll start releasing shortly. >>>>>>>> I'd like to get a fix in for the missing ciphers in the new NSS. I can >>>>>>>> have a patch on the list shortly. >>>>>>>> >>>>>>>> Nathaniel >>>>>>> Isn't this related to >>>>>>> https://fedorahosted.org/freeipa/ticket/4395 >>>>>>> ? I think we do not work with the newest DS which fixed the default ciphers. >>>>>> yes >>>>>>> Don't we need to set our SSL ciphers setting to >>>>>>> >>>>>>> https://fedorahosted.org/389/ticket/47838#comment:29 >>>>>> yes >>>>>> tjhe attached patch tries this, but at the moment I failed to build and >>>>>> also to upgrade to F21 >>>>> NACKallowweakcipher >>>>> >>>>> >>>>> LDAP error: OBJECT_CLASS_VIOLATION >>>>> attribute "allowweakcipher" not allowed >>>>> >>>>> I suspect we are missing a spec file requirement on a newer version of 389... >>>> yes, you need the latest build of DS, Noriko added the allowweakcipher >>>> only yesterday. >>>> That's the problem, I wanted to wait with the ipa side patch until >>>> allowweakcipher was implemented and then on F21 ipa and 389 no longer >>>> played well and now there is a rush >>> What is the status on the new 389 patch/build? >> a build is here: >> http://copr-be.cloud.fedoraproject.org/results/nhosoi/389-ds-f21/fedora-21-x86_64/389-ds-base-1.3.3.2-a1.fc21/ > > The upstream patch is not merged yet. We need 389 to merge the patch, do > a release and get an official Fedora 20/21 build. > > Just to be clear, Fedora 21 IPA doesn't work *at all*. So this is an > urgent fix. > > Martin, can you coordinate with 389 to prioritize a release with this > fix? Hi! It looks like I'll be the release manager for FreeIPA 4.0.3. Currently I'm waiting for the new build of 389 and possibly an updated IPA patch, when that's in I'll test and release. -- Petr? From lkrispen at redhat.com Thu Sep 11 14:38:17 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Sep 2014 16:38:17 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B235.2070000@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> Message-ID: <5411B3D9.7030702@redhat.com> On 09/11/2014 04:31 PM, Petr Viktorin wrote: > On 09/11/2014 04:26 PM, Martin Kosek wrote: >> On 09/11/2014 04:22 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:21 +0200, Ludwig Krispenz wrote: >>>> On 09/11/2014 04:17 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-09-11 at 16:09 +0200, Ludwig Krispenz wrote: >>>>>> On 09/11/2014 04:04 PM, Martin Kosek wrote: >>>>>>> On 09/11/2014 03:47 PM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-09-11 at 15:46 +0200, Petr Viktorin wrote: >>>>>>>>> On 09/11/2014 01:37 PM, Martin Kosek wrote: >>>>>>>>>> Hi team, >>>>>>>>>> >>>>>>>>>> It seems we have pretty serious bug in our FreeIPA 4.0.2 >>>>>>>>>> release, breaking >>>>>>>>>> upgrade from older releases: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4529 >>>>>>>>>> >>>>>>>>>> We also have packaging fix requested by Fedora Server roles >>>>>>>>>> group: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4430 >>>>>>>>>> >>>>>>>>>> It seems just these 2 bugs are enough for a quick FreeIPA >>>>>>>>>> 4.0.3 release... >>>>>>>>>> Makes sense? Any other tickets or patches we would like to >>>>>>>>>> get in? >>>>>>>>> Looks like it's just those two. I'll start releasing shortly. >>>>>>>> I'd like to get a fix in for the missing ciphers in the new >>>>>>>> NSS. I can >>>>>>>> have a patch on the list shortly. >>>>>>>> >>>>>>>> Nathaniel >>>>>>> Isn't this related to >>>>>>> https://fedorahosted.org/freeipa/ticket/4395 >>>>>>> ? I think we do not work with the newest DS which fixed the >>>>>>> default ciphers. >>>>>> yes >>>>>>> Don't we need to set our SSL ciphers setting to >>>>>>> >>>>>>> https://fedorahosted.org/389/ticket/47838#comment:29 >>>>>> yes >>>>>> tjhe attached patch tries this, but at the moment I failed to >>>>>> build and >>>>>> also to upgrade to F21 >>>>> NACKallowweakcipher >>>>> >>>>> >>>>> LDAP error: OBJECT_CLASS_VIOLATION >>>>> attribute "allowweakcipher" not allowed >>>>> >>>>> I suspect we are missing a spec file requirement on a newer >>>>> version of 389... >>>> yes, you need the latest build of DS, Noriko added the allowweakcipher >>>> only yesterday. >>>> That's the problem, I wanted to wait with the ipa side patch until >>>> allowweakcipher was implemented and then on F21 ipa and 389 no longer >>>> played well and now there is a rush >> >> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >> so that F20 users can upgrade to the newest FreeIPA. Are there any >> known issues >> in the F21 389-ds-base build that would prevent upstream FreeIPA >> 4.0.x to be >> based on it? >> >> If yes, we may need to include the patch in Fedora 21 downstream only >> after all.. > > We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > couldn't include the patch even there. > There better be no such issues. what do you mean by "no such issues" ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - From pviktori at redhat.com Thu Sep 11 14:39:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 16:39:17 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B3D9.7030702@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> Message-ID: <5411B415.4050401@redhat.com> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > > On 09/11/2014 04:31 PM, Petr Viktorin wrote: >> On 09/11/2014 04:26 PM, Martin Kosek wrote: ... >>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>> known issues >>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>> 4.0.x to be >>> based on it? >>> >>> If yes, we may need to include the patch in Fedora 21 downstream only >>> after all.. >> >> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >> couldn't include the patch even there. >> There better be no such issues. > what do you mean by "no such issues" ? I don't think that 389/F21 will > be the first bug free software. At the moment Thierry is investigating a > crash in dna-plugin and Noriko a memory leak, which could be in F21 - > any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Plugin crashes or memory leaks are bad, but we can release with them. -- Petr? From npmccallum at redhat.com Thu Sep 11 14:43:32 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:43:32 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B415.4050401@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> Message-ID: <1410446612.2941.9.camel@redhat.com> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > > > > On 09/11/2014 04:31 PM, Petr Viktorin wrote: > >> On 09/11/2014 04:26 PM, Martin Kosek wrote: > ... > >>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > >>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > >>> so that F20 users can upgrade to the newest FreeIPA. Are there any > >>> known issues > >>> in the F21 389-ds-base build that would prevent upstream FreeIPA > >>> 4.0.x to be > >>> based on it? > >>> > >>> If yes, we may need to include the patch in Fedora 21 downstream only > >>> after all.. > >> > >> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > >> couldn't include the patch even there. > >> There better be no such issues. > > what do you mean by "no such issues" ? I don't think that 389/F21 will > > be the first bug free software. At the moment Thierry is investigating a > > crash in dna-plugin and Noriko a memory leak, which could be in F21 - > > > > any known issues in the F21 389-ds-base build that would prevent > upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Then, we need an F21 build of 389-ds-base. Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. Then we release 4.0.3. > Plugin crashes or memory leaks are bad, but we can release with them. +1. The real problem is that without the above fixes, IPA doesn't work at all. Nathaniel From mkosek at redhat.com Thu Sep 11 14:46:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 16:46:08 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410446612.2941.9.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> Message-ID: <5411B5B0.6000108@redhat.com> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>> >>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >> ... >>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>> known issues >>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>> 4.0.x to be >>>>> based on it? >>>>> >>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>> after all.. >>>> >>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>> couldn't include the patch even there. >>>> There better be no such issues. >>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>> be the first bug free software. At the moment Thierry is investigating a >>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>> >> >> any known issues in the F21 389-ds-base build that would prevent >> upstream FreeIPA 4.0.x to be based on it > > Yes. 389 will not start if weak ciphers are specified. Currently, > FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > work at all because the DS will never start. > > We need this patch merged: https://fedorahosted.org/389/ticket/47838 Yes. > Then, we need an F21 build of 389-ds-base. Yes (and add the build to FreeIPA Copr). > Then we need to merge Ludwig's IPA patch from this thread with a > versioned dependency on the new 389-ds-base build. > > Then we release 4.0.3. Exactly, and we need all that very fast as we are blocking Fedora 21. CCing Noriko to be aware. Martin From pviktori at redhat.com Thu Sep 11 14:48:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 16:48:24 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410446612.2941.9.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> Message-ID: <5411B638.3080905@redhat.com> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>> >>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >> ... >>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>> known issues >>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>> 4.0.x to be >>>>> based on it? >>>>> >>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>> after all.. >>>> >>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>> couldn't include the patch even there. >>>> There better be no such issues. >>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>> be the first bug free software. At the moment Thierry is investigating a >>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>> >> >> any known issues in the F21 389-ds-base build that would prevent >> upstream FreeIPA 4.0.x to be based on it > > Yes. 389 will not start if weak ciphers are specified. Currently, > FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > work at all because the DS will never start. > > We need this patch merged: https://fedorahosted.org/389/ticket/47838 > > Then, we need an F21 build of 389-ds-base. > > Then we need to merge Ludwig's IPA patch from this thread with a > versioned dependency on the new 389-ds-base build. > > Then we release 4.0.3. That's what I understood, but thanks for confirming. We need to move fast; FreeIPA is an f21 alpha blocker. >> Plugin crashes or memory leaks are bad, but we can release with them. > > +1. The real problem is that without the above fixes, IPA doesn't work > at all. > > Nathaniel > > -- Petr? From tbordaz at redhat.com Thu Sep 11 14:49:35 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 11 Sep 2014 16:49:35 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B5B0.6000108@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B5B0.6000108@redhat.com> Message-ID: <5411B67F.9060600@redhat.com> On 09/11/2014 04:46 PM, Martin Kosek wrote: > On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>> ... >>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>> known issues >>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>> 4.0.x to be >>>>>> based on it? >>>>>> >>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>> after all.. >>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>> couldn't include the patch even there. >>>>> There better be no such issues. >>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>> be the first bug free software. At the moment Thierry is investigating a >>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>> >>> any known issues in the F21 389-ds-base build that would prevent >>> upstream FreeIPA 4.0.x to be based on it >> Yes. 389 will not start if weak ciphers are specified. Currently, >> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >> work at all because the DS will never start. >> >> We need this patch merged: https://fedorahosted.org/389/ticket/47838 > Yes. > >> Then, we need an F21 build of 389-ds-base. > Yes (and add the build to FreeIPA Copr). Note that Noriko also released a fix for https://fedorahosted.org/389/ticket/47838 on F21 and was waiting for Adam tests: http://koji.fedoraproject.org/koji/taskinfo?taskID=7566760 thierry > >> Then we need to merge Ludwig's IPA patch from this thread with a >> versioned dependency on the new 389-ds-base build. >> >> Then we release 4.0.3. > Exactly, and we need all that very fast as we are blocking Fedora 21. CCing > Noriko to be aware. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Thu Sep 11 14:50:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:50:34 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410446612.2941.9.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> Message-ID: <1410447034.2941.10.camel@redhat.com> On Thu, 2014-09-11 at 10:43 -0400, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > > On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > > > > > > On 09/11/2014 04:31 PM, Petr Viktorin wrote: > > >> On 09/11/2014 04:26 PM, Martin Kosek wrote: > > ... > > >>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > > >>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > >>> so that F20 users can upgrade to the newest FreeIPA. Are there any > > >>> known issues > > >>> in the F21 389-ds-base build that would prevent upstream FreeIPA > > >>> 4.0.x to be > > >>> based on it? > > >>> > > >>> If yes, we may need to include the patch in Fedora 21 downstream only > > >>> after all.. > > >> > > >> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > > >> couldn't include the patch even there. > > >> There better be no such issues. > > > what do you mean by "no such issues" ? I don't think that 389/F21 will > > > be the first bug free software. At the moment Thierry is investigating a > > > crash in dna-plugin and Noriko a memory leak, which could be in F21 - > > > > > > > any known issues in the F21 389-ds-base build that would prevent > > upstream FreeIPA 4.0.x to be based on it > > Yes. 389 will not start if weak ciphers are specified. Currently, > FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > work at all because the DS will never start. > > We need this patch merged: https://fedorahosted.org/389/ticket/47838 > > Then, we need an F21 build of 389-ds-base. > > Then we need to merge Ludwig's IPA patch from this thread with a > versioned dependency on the new 389-ds-base build. > > Then we release 4.0.3. > > > Plugin crashes or memory leaks are bad, but we can release with them. > > +1. The real problem is that without the above fixes, IPA doesn't work > at all. I can confirm that with the COPR build of 389 including the above patch and Ludwig's patch to FreeIPA, everything is working again in F21. Nathaniel From npmccallum at redhat.com Thu Sep 11 14:51:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 10:51:28 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B638.3080905@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> Message-ID: <1410447088.2941.11.camel@redhat.com> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: > On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > > On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > >> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > >>> > >>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: > >>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: > >> ... > >>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > >>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > >>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any > >>>>> known issues > >>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA > >>>>> 4.0.x to be > >>>>> based on it? > >>>>> > >>>>> If yes, we may need to include the patch in Fedora 21 downstream only > >>>>> after all.. > >>>> > >>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > >>>> couldn't include the patch even there. > >>>> There better be no such issues. > >>> what do you mean by "no such issues" ? I don't think that 389/F21 will > >>> be the first bug free software. At the moment Thierry is investigating a > >>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - > >>> > >> > >> any known issues in the F21 389-ds-base build that would prevent > >> upstream FreeIPA 4.0.x to be based on it > > > > Yes. 389 will not start if weak ciphers are specified. Currently, > > FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > > work at all because the DS will never start. > > > > We need this patch merged: https://fedorahosted.org/389/ticket/47838 > > > > Then, we need an F21 build of 389-ds-base. > > > > Then we need to merge Ludwig's IPA patch from this thread with a > > versioned dependency on the new 389-ds-base build. > > > > Then we release 4.0.3. > > That's what I understood, but thanks for confirming. > > We need to move fast; FreeIPA is an f21 alpha blocker. Have we filed a blocker bug? They are discussing go/no go right now. Nathaniel From pviktori at redhat.com Thu Sep 11 14:56:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Sep 2014 16:56:51 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410447088.2941.11.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410447088.2941.11.camel@redhat.com> Message-ID: <5411B833.1030305@redhat.com> On 09/11/2014 04:51 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>> >>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>> ... >>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>> known issues >>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>> 4.0.x to be >>>>>>> based on it? >>>>>>> >>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>>> after all.. >>>>>> >>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>> couldn't include the patch even there. >>>>>> There better be no such issues. >>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>>> be the first bug free software. At the moment Thierry is investigating a >>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>>> >>>> >>>> any known issues in the F21 389-ds-base build that would prevent >>>> upstream FreeIPA 4.0.x to be based on it >>> >>> Yes. 389 will not start if weak ciphers are specified. Currently, >>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>> work at all because the DS will never start. >>> >>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 >>> >>> Then, we need an F21 build of 389-ds-base. >>> >>> Then we need to merge Ludwig's IPA patch from this thread with a >>> versioned dependency on the new 389-ds-base build. >>> >>> Then we release 4.0.3. >> >> That's what I understood, but thanks for confirming. >> >> We need to move fast; FreeIPA is an f21 alpha blocker. > > Have we filed a blocker bug? They are discussing go/no go right now. The meeting starts in 2 hours, and AFAIK it's already certain it's no-go. Is there a 389 Fedora bug for the issue that I could reference in an IPA bug? -- Petr? From mkosek at redhat.com Thu Sep 11 15:03:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 17:03:23 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't Message-ID: <5411B9BB.6000001@redhat.com> Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding "objectclass" to "System: Read Timestamp and USN Operational Attributes". However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? Thank you. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From lkrispen at redhat.com Thu Sep 11 15:23:34 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Sep 2014 17:23:34 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5411B9BB.6000001@redhat.com> References: <5411B9BB.6000001@redhat.com> Message-ID: <5411BE76.2080006@redhat.com> On 09/11/2014 05:03 PM, Martin Kosek wrote: > Hello, > > We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings > cause older SSSD clients to fail as they get returned an LDAP deref call > results without objectclass attribute and just with entryusn attribute. Details > in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be > more tolerant in this case, it still breaks old clients which we should prevent. > > There are 2 ways how to fix I currently see: > > 1) Return objectclass for any entry, just like we do with operational attributes > > This would include adding "objectclass" to "System: Read Timestamp and USN > Operational Attributes". However, I am rather cautious about this approach as > even though objectclass does not usually carry a secret information, we could > still leak some information about our DIT to unprivileged user. yes, there is no need to open access up to anyone, it could be restricted to authenticated. Do the users sssd uses to authenticate have a common dn pattern or are in a specific group ? You could open access only for them, or combine access with a targetfilter (objectclass=groupofnames) to further restrict access > > > 2) Show objectclass+operational attributes in our Read ACIs > Other way I see is to update *all* our Read permissions allowing reading > objectclass attribute and also allow the chosen LDAP operational attribute. > This would let the LDAP caller to always get either all these discussed > attributes but none at all. > > > Do we want to do this? Any other (better) idea how to approach it? > > Thank you. > From ssorce at redhat.com Thu Sep 11 15:37:41 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Sep 2014 11:37:41 -0400 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5411B9BB.6000001@redhat.com> References: <5411B9BB.6000001@redhat.com> Message-ID: <1410449861.1199.6.camel@willson.usersys.redhat.com> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: > Hello, > > We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings > cause older SSSD clients to fail as they get returned an LDAP deref call > results without objectclass attribute and just with entryusn attribute. Details > in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be > more tolerant in this case, it still breaks old clients which we should prevent. > > There are 2 ways how to fix I currently see: > > 1) Return objectclass for any entry, just like we do with operational attributes > > This would include adding "objectclass" to "System: Read Timestamp and USN > Operational Attributes". However, I am rather cautious about this approach as > even though objectclass does not usually carry a secret information, we could > still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. > 2) Show objectclass+operational attributes in our Read ACIs > Other way I see is to update *all* our Read permissions allowing reading > objectclass attribute and also allow the chosen LDAP operational attribute. > This would let the LDAP caller to always get either all these discussed > attributes but none at all. > > > Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. From pvoborni at redhat.com Thu Sep 11 15:59:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 17:59:09 +0200 Subject: [Freeipa-devel] [PATCH] 720-729 OTP usability improvements In-Reply-To: <54108400.7030101@redhat.com> References: <53E0C08A.9000406@redhat.com> <53EA39C8.5020304@redhat.com> <53F6FFE3.3070302@redhat.com> <54076F94.4030100@redhat.com> <540F2169.5000103@redhat.com> <54108400.7030101@redhat.com> Message-ID: <5411C6CD.5010909@redhat.com> On 10.9.2014 19:01, Endi Sukma Dewata wrote: > On 9/9/2014 10:48 AM, Petr Vobornik wrote: >>>>>> [PATCH] 727 webui: hide empty fields and sections > >>>>> 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. > > ACK. > >>>> What do you think about setting `hide_empty_widgets` global setting to >>>> True? >>> >>> On a read-only page I think it's OK to hide empty fields. But on edit >>> page I don't think we should do that by default. >> >> Maybe we should first clarify what is a read-only page. All details >> pages are writable if user has the rights or read-only if he doesn't. >> But mostly it depends on individual fields/attributes. > > Read-only page is a page that does not provide editable interface for > all fields displayed in the page. For example, the fields in the > certificate details page are never editable, so suppose it has empty > optional fields (e.g. cert extensions?) we probably can hide those > fields without confusing users. > > Other details pages have read-only and edit modes, so it probably makes > more sense to keep the structure identical in both modes so optional > fields like 'Job Title' will always be visible. However, it's also > possible to hide the empty fields in the read-only mode if necessary to > clean up the display. > >>> Does "empty" mean "unset", or "blank" like empty string/array? Does >>> "unset" always mean "non-editable and invisible" and "blank" always mean >>> "editable and visible but it's just empty"? If this definition isn't >>> strictly followed there could be an editable field that accidentally >>> gets hidden because it's empty. >> >> My intent was to show everything what user can edit. And hide fields: >> 1. for which he doesn't have read rights >> 2. have no (undefined) or empty('') value >> 3. are explicitly hidden by other logic - not related to this patch >> >> When thinking about #1. Maybe we should base it on a presence or rather >> not presence of a specific objectclass, rather than on a value. That way >> it would be less confusing for newcomers. The logic is: if fields is >> bound to an object class and the class is not present (that also means >> we don't have attribute level rights) -> hide it. > > That would be hiding/displaying based on structural reason instead of > user rights. How about an attribute that exists but the user doesn't > have the read permission? I think we need to check both structural and > user rights. > >> #2 is questionable. IMHO it would require user tests. Also hiding on '' >> value might not be always desirable. Nevertheless I like the behavior >> but it may be caused by the fact that I already know what to expect. > > Before we can make this behavior the default/global, how do we make sure > that optional fields such as 'Job Title' will always visible in the edit > page even if it's empty? I think to avoid unexpected behavior hiding > based on empty value should only be done in read-only page as I > mentioned above. > >>> Generally if a field is supposed to be hidden in an edit page because of >>> other condition (e.g. token type), not because of the value, the code >>> should also use that condition instead of relying on the value being >>> unset. In this particular case, instead of: >>> >>> if (field !== undefined) { >>> // display field >>> } >>> >>> we probably should do: >>> >>> var type = ... >>> >>> if (type == 'hotp') { >>> // display hotp fields >>> >>> } else { // totp >>> // display totp fields >>> } >> >> I agree - use case #3. > > This is actually hiding/displaying based on structural reason too. In > this case the structure is reflected in the (virtual) 'type' field. > >>>>> 4. If no "Owner" is specified when adding a token, it will default to >>>>> admin. Is this the intended behavior? >>>> >>>> Sadly yes. >>> >>> Maybe the adder dialog should show admin (or the current user?) as the >>> default owner instead of empty? >>> >> >> Note: all patches except for 727 are ACKed. > > It's all ACKed now. Everything else can be handled separately. > Pushed to: master: * 72869e26877771900ebee7ea70a616715373a0aa webui: add measurement unit to otp token time fields * 475f6e293e3341f72f56bd9b75e6dc6231a10a59 webui: better otp token type label * 325bbf5bbf39da43e590b2dee2044683aaec3a66 webui: add token from user page * 15e85db8f873dc133cfd3962d5a58fdb92b17513 webui: add i18n for the rest of QR code strings * 2257f12652eb67ab9ece1f1aa79aa9f784adfb05 webui: display fields based on otp token type * 01a8175119233a4de10dddaf74db5750ff6e0c25 webui: better value-change reporting * 1f13e56ac6813eef9649b055b240a470acf034c8 webui: widget initialization * 2b2f37981147e7cd74a2e42f5802c717b01b6ca8 webui: hide empty fields and sections * 7e7fe57fc9098e81ce90f4d56b1a3154abfa6123 webui: hide non-readable fields * 854bc42913f663dce1f2e0fbb44a670a2812d87c webui: hide otp fields based on token type ipa-4-1: * 26d268849290911835f539f7197c37139f6a4348 webui: add measurement unit to otp token time fields * 46e5e69702cd48f7e9ca3a3510fbe4eb7c7f8af8 webui: better otp token type label * c1bf15237310a51f7c843cbe9a7f50050d2691be webui: add token from user page * bb114e3317e1b961f5ede9b186c430f81bc35636 webui: add i18n for the rest of QR code strings * 935a6a1b0bcdc7a4ce8e9e1d12606f4085411f71 webui: display fields based on otp token type * a43af5cd703319e1aff14bf6c8d2c8b2d8c4cf13 webui: better value-change reporting * 009d272d5396690699ef1c3aad4cf3322ed69905 webui: widget initialization * e27a774c2cfedcfe28e2188b56937da0d7495e19 webui: hide empty fields and sections * 53693168fddaa0dc3864abaea59ac032258310ca webui: hide non-readable fields * 50291e7b9a2295c38400d152428e1c3c71330935 webui: hide otp fields based on token type -- Petr Vobornik From pvoborni at redhat.com Thu Sep 11 16:10:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 18:10:02 +0200 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app In-Reply-To: <27C058BB-954B-41B2-978F-7ECCBBE346A1@redhat.com> References: <53E0F417.8050204@redhat.com> <27C058BB-954B-41B2-978F-7ECCBBE346A1@redhat.com> Message-ID: <5411C95A.4060705@redhat.com> On 5.8.2014 22:22, Nathaniel McCallum wrote: > > 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 > > Can we wait a few days on this patch? I?m working on a domain name for FreeOTP. > > Nathaniel > Any progress? -- Petr Vobornik From npmccallum at redhat.com Thu Sep 11 16:11:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 12:11:23 -0400 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app In-Reply-To: <5411C95A.4060705@redhat.com> References: <53E0F417.8050204@redhat.com> <27C058BB-954B-41B2-978F-7ECCBBE346A1@redhat.com> <5411C95A.4060705@redhat.com> Message-ID: <1410451883.2941.12.camel@redhat.com> On Thu, 2014-09-11 at 18:10 +0200, Petr Vobornik wrote: > On 5.8.2014 22:22, Nathaniel McCallum wrote: > > > > 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 > > > > > > Can we wait a few days on this patch? I?m working on a domain name for FreeOTP. > > > > Nathaniel > > > > Any progress? I pursued several options, but I haven't received responses on any of them. Dmitri, does Red Hat want to procure a domain? Fedora? Nathaniel From sbose at redhat.com Thu Sep 11 16:19:25 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Sep 2014 18:19:25 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5411BE76.2080006@redhat.com> References: <5411B9BB.6000001@redhat.com> <5411BE76.2080006@redhat.com> Message-ID: <20140911161925.GS2947@localhost.localdomain> On Thu, Sep 11, 2014 at 05:23:34PM +0200, Ludwig Krispenz wrote: > > On 09/11/2014 05:03 PM, Martin Kosek wrote: > >Hello, > > > >We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings > >cause older SSSD clients to fail as they get returned an LDAP deref call > >results without objectclass attribute and just with entryusn attribute. Details > >in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be > >more tolerant in this case, it still breaks old clients which we should prevent. > > > >There are 2 ways how to fix I currently see: > > > >1) Return objectclass for any entry, just like we do with operational attributes > > > >This would include adding "objectclass" to "System: Read Timestamp and USN > >Operational Attributes". However, I am rather cautious about this approach as > >even though objectclass does not usually carry a secret information, we could > >still leak some information about our DIT to unprivileged user. > yes, there is no need to open access up to anyone, it could be restricted to > authenticated. > > Do the users sssd uses to authenticate have a common dn pattern or are in a > specific group ? You could open access only for them, or combine access with > a targetfilter (objectclass=groupofnames) to further restrict access SSSD uses the host keytab to do a SASL bind, so the DN should look like: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX . HTH bye, Sumit > > > > > >2) Show objectclass+operational attributes in our Read ACIs > >Other way I see is to update *all* our Read permissions allowing reading > >objectclass attribute and also allow the chosen LDAP operational attribute. > >This would let the LDAP caller to always get either all these discussed > >attributes but none at all. > > > > > >Do we want to do this? Any other (better) idea how to approach it? > > > >Thank you. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Thu Sep 11 16:21:29 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Sep 2014 12:21:29 -0400 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <20140911161925.GS2947@localhost.localdomain> References: <5411B9BB.6000001@redhat.com> <5411BE76.2080006@redhat.com> <20140911161925.GS2947@localhost.localdomain> Message-ID: <1410452489.1199.11.camel@willson.usersys.redhat.com> On Thu, 2014-09-11 at 18:19 +0200, Sumit Bose wrote: > On Thu, Sep 11, 2014 at 05:23:34PM +0200, Ludwig Krispenz wrote: > > > > On 09/11/2014 05:03 PM, Martin Kosek wrote: > > >Hello, > > > > > >We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings > > >cause older SSSD clients to fail as they get returned an LDAP deref call > > >results without objectclass attribute and just with entryusn attribute. Details > > >in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be > > >more tolerant in this case, it still breaks old clients which we should prevent. > > > > > >There are 2 ways how to fix I currently see: > > > > > >1) Return objectclass for any entry, just like we do with operational attributes > > > > > >This would include adding "objectclass" to "System: Read Timestamp and USN > > >Operational Attributes". However, I am rather cautious about this approach as > > >even though objectclass does not usually carry a secret information, we could > > >still leak some information about our DIT to unprivileged user. > > yes, there is no need to open access up to anyone, it could be restricted to > > authenticated. > > > > Do the users sssd uses to authenticate have a common dn pattern or are in a > > specific group ? You could open access only for them, or combine access with > > a targetfilter (objectclass=groupofnames) to further restrict access > > SSSD uses the host keytab to do a SASL bind, so the DN should look like: > fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX . Other leagcy claints may be using accounts in sysaccounts or other locations, this fix should not be about SSSD alone imo. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Sep 11 16:34:44 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Sep 2014 18:34:44 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks In-Reply-To: <5411AA38.4030309@redhat.com> References: <5411728D.8050405@redhat.com> <5411AA38.4030309@redhat.com> Message-ID: <5411CF24.2030200@redhat.com> On 11/09/14 15:57, Martin Basti wrote: > On 11/09/14 11:59, Petr Spacek wrote: >> Hello, >> >> I was fighting with random crashes for couple of days ... and >> discovered that run_exclusive_enter()/isc_task_beginexclusive() usage >> was completely incorrect and didn't actually lock anything. >> >> This series of patches reworks internal locking (and related event >> system) to work around limitations of isc_task_beginexclusive() >> mechanism. >> >> It would be better to get rid of isc_task_beginexclusive() completely >> but IMHO it is not possible because of BIND's dns_view*() functions >> have to be guarded with it. >> >> >> Testing is going to be interesting because we are speaking about race >> conditions. >> >> I used ~ 100 DNS zones, each zone had ~ 100 random domain names >> inside with random A/AAAA/TXT RRs. My LDIF is here: >> http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz >> >> I was able to randomly reproduce various crashes when BIND was >> running with more threads than usually. >> >> You can try to run BIND with this command (as root) and play games >> with -n parameter: >> $ export KRB5_KTNAME="/etc/named.keytab" >> $ named -4 -g -u named -m record -n 10 >> >> Please test also the case where BIND receives SIGINT during start-up. >> It is possible to run BIND with commands above and wait for message: >> 11-Sep-2014 11:54:58.092 running >> >> At this point send SIGINT (CTRL+C) to BIND and see what happens. It >> could crash or deadlock. >> >> It is necessary to send the signal before BIND prints this message: >> 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 >> >> Let me know if you need any assistance. >> > I need your assistance, I haven't been able to reproduce it. > > Martin > I applied the patchset, and NACK #1 If named is running and I randomly choose few zones and delete them, it causes named failure dig @localhost A r1.z12.test ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> @localhost A r1.z12.test ; (2 servers found) ;; global options: +cmd ;; connection timed out; no servers could be reached * SIGINT doesn't work * rndc doesn't work * DS worksSIGINT signal stops working. Output: 11-Sep-2014 11:26:37.495 client 127.0.0.1#62615: received notify for zone 'z99.test' ^C^C^C^C^C^C^C^C Process: named 29125 1.1 2.9 789972 45976 pts/0 Sl+ 11:26 0:02 named -4 -g -u named -m record -n 10 I have to kill it with kill -9 #2 same as #1 If new zone is added, #3 same as #1 If new record is added #4 same as #1 If record is deleted -- Martin Basti From mkosek at redhat.com Thu Sep 11 18:28:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 20:28:03 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <1410449861.1199.6.camel@willson.usersys.redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> Message-ID: <5411E9B3.6010200@redhat.com> On 09/11/2014 05:37 PM, Simo Sorce wrote: > On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >> Hello, >> >> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings >> cause older SSSD clients to fail as they get returned an LDAP deref call >> results without objectclass attribute and just with entryusn attribute. Details >> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be >> more tolerant in this case, it still breaks old clients which we should prevent. >> >> There are 2 ways how to fix I currently see: >> >> 1) Return objectclass for any entry, just like we do with operational attributes >> >> This would include adding "objectclass" to "System: Read Timestamp and USN >> Operational Attributes". However, I am rather cautious about this approach as >> even though objectclass does not usually carry a secret information, we could >> still leak some information about our DIT to unprivileged user. > > Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. >> 2) Show objectclass+operational attributes in our Read ACIs >> Other way I see is to update *all* our Read permissions allowing reading >> objectclass attribute and also allow the chosen LDAP operational attribute. >> This would let the LDAP caller to always get either all these discussed >> attributes but none at all. >> >> >> Do we want to do this? Any other (better) idea how to approach it? > > I honestly am not sure I understand the distinction between 1 and 2, can > you provide the actual ACIs or a behavior example ? > > Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. ... # memberof: ;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: ;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only allowed to read entryusn for objects that they can really read (i.e. for objects where they can read at least objectclass). Did that clarify the options? Of course, there is still option 3) to close as wontfix and let older SSSDs be incompatible with FreeIPA 4.0+. Martin From ssorce at redhat.com Thu Sep 11 18:49:41 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Sep 2014 14:49:41 -0400 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5411E9B3.6010200@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> Message-ID: <1410461381.1199.15.camel@willson.usersys.redhat.com> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: > On 09/11/2014 05:37 PM, Simo Sorce wrote: > > On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: > >> Hello, > >> > >> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings > >> cause older SSSD clients to fail as they get returned an LDAP deref call > >> results without objectclass attribute and just with entryusn attribute. Details > >> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be > >> more tolerant in this case, it still breaks old clients which we should prevent. > >> > >> There are 2 ways how to fix I currently see: > >> > >> 1) Return objectclass for any entry, just like we do with operational attributes > >> > >> This would include adding "objectclass" to "System: Read Timestamp and USN > >> Operational Attributes". However, I am rather cautious about this approach as > >> even though objectclass does not usually carry a secret information, we could > >> still leak some information about our DIT to unprivileged user. > > > > Our DIT is public and known, I see no problem. > > I rather meant the LDAP tree and it's contents (custom groups, sudo rules, > roles, ...). > > I did one more test and found out we cannot do this as it would undermine the > ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch > returns every object even if no other attribute is returned: > > # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test > SASL/GSSAPI authentication started > SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > ... > # User Administrators, privileges, pbac, mkosek-fedora20.test > dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup > ... > > It would not show any more info before that, but even the list of permissions, > privileges and roles along with it's names is a leaked information. > > > >> 2) Show objectclass+operational attributes in our Read ACIs > >> Other way I see is to update *all* our Read permissions allowing reading > >> objectclass attribute and also allow the chosen LDAP operational attribute. > >> This would let the LDAP caller to always get either all these discussed > >> attributes but none at all. > >> > >> > >> Do we want to do this? Any other (better) idea how to approach it? > > > > I honestly am not sure I understand the distinction between 1 and 2, can > > you provide the actual ACIs or a behavior example ? > > > > Simo. > > Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) > running LDAP deref call gets entryusn from object it does not have a read > access to: > > # ldapsearch -h `hostname` -Y GSSAPI -b > uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E > 'deref=memberof:objectclass,entryusn' > SASL/GSSAPI authentication started > SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > ... > # memberof: ;cn=replication administrators,cn=privileges,cn=pba > c,dc=mkosek-fedora20,dc=test > > # memberof: ;cn=add replication agreements,cn=permissions,cn=pba > c,dc=mkosek-fedora20,dc=test > ... > > This confuses SSSD (sees entryusn but does not see objectclass attribute) + may > give out some information we do not want to give out. Fortunately, bare > ldapsearch does not show anything: > > # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication > administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn > SASL/GSSAPI authentication started > SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with scope subtree > # filter: (objectclass=*) > # requesting: entryusn > # > > # search result > search: 4 > result: 0 Success > > # numResponses: 1 > > > The idea behind Option 1 was to add ACI to allow reading objectclass attribute > globally, for our entire tree. (as noted above, not an option). > > The idea behind Option 2 was to: > - remove global ACI allowing reading entryusn (System: Read Timestamp and USN > Operational Attributes) > - update all our Read permissions to allow entryusn > > Then for example, if user (SSSD) is allowed to read RBAC role objects, he would > not be able to read either objectclass or entryusn attributes. This means users > would be only allowed to read entryusn for objects that they can really read > (i.e. for objects where they can read at least objectclass). > > Did that clarify the options? > > Of course, there is still option 3) to close as wontfix and let older SSSDs be > incompatible with FreeIPA 4.0+. No, 3 is definitely not on the table, I would rather do 1, but I guess 2 is the only good way for now ? Simo. From pspacek at redhat.com Thu Sep 11 19:58:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Sep 2014 21:58:17 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks In-Reply-To: <5411CF24.2030200@redhat.com> References: <5411728D.8050405@redhat.com> <5411AA38.4030309@redhat.com> <5411CF24.2030200@redhat.com> Message-ID: <5411FED9.9070908@redhat.com> On 11.9.2014 18:34, Martin Basti wrote: > On 11/09/14 15:57, Martin Basti wrote: >> On 11/09/14 11:59, Petr Spacek wrote: >>> Hello, >>> >>> I was fighting with random crashes for couple of days ... and discovered >>> that run_exclusive_enter()/isc_task_beginexclusive() usage was completely >>> incorrect and didn't actually lock anything. >>> >>> This series of patches reworks internal locking (and related event system) >>> to work around limitations of isc_task_beginexclusive() mechanism. >>> >>> It would be better to get rid of isc_task_beginexclusive() completely but >>> IMHO it is not possible because of BIND's dns_view*() functions have to be >>> guarded with it. >>> >>> >>> Testing is going to be interesting because we are speaking about race >>> conditions. >>> >>> I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside with >>> random A/AAAA/TXT RRs. My LDIF is here: >>> http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz >>> >>> I was able to randomly reproduce various crashes when BIND was running with >>> more threads than usually. >>> >>> You can try to run BIND with this command (as root) and play games with -n >>> parameter: >>> $ export KRB5_KTNAME="/etc/named.keytab" >>> $ named -4 -g -u named -m record -n 10 >>> >>> Please test also the case where BIND receives SIGINT during start-up. It is >>> possible to run BIND with commands above and wait for message: >>> 11-Sep-2014 11:54:58.092 running >>> >>> At this point send SIGINT (CTRL+C) to BIND and see what happens. It could >>> crash or deadlock. >>> >>> It is necessary to send the signal before BIND prints this message: >>> 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 >>> >>> Let me know if you need any assistance. >>> >> I need your assistance, I haven't been able to reproduce it. >> >> Martin >> > I applied the patchset, and NACK I don't understand how I could possibly miss this. I was convinced that the patch set was thoroughly tested ... Anyway, attached patch should fix the problem you were facing. Please re-test it. Thank you! Petr^2 Spacek > #1 > If named is running and I randomly choose few zones and delete them, it causes > named failure > > dig @localhost A r1.z12.test > > ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> @localhost A r1.z12.test > ; (2 servers found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > * SIGINT doesn't work > * rndc doesn't work > * DS worksSIGINT signal stops working. > > Output: > > 11-Sep-2014 11:26:37.495 client 127.0.0.1#62615: received notify for zone > 'z99.test' > > ^C^C^C^C^C^C^C^C > > > Process: > named 29125 1.1 2.9 789972 45976 pts/0 Sl+ 11:26 0:02 named -4 -g > -u named -m record -n 10 > > I have to kill it with kill -9 > > #2 > same as #1 If new zone is added, > > #3 > same as #1 If new record is added > > #4 > same as #1 If record is deleted -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0291-2-Rework-locking-in-settings.c-module.patch Type: text/x-patch Size: 13277 bytes Desc: not available URL: From mkosek at redhat.com Thu Sep 11 20:24:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Sep 2014 22:24:08 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <1410461381.1199.15.camel@willson.usersys.redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> Message-ID: <541204E8.3010006@redhat.com> On 09/11/2014 08:49 PM, Simo Sorce wrote: > On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >> On 09/11/2014 05:37 PM, Simo Sorce wrote: >>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>> Hello, >>>> >>>> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings >>>> cause older SSSD clients to fail as they get returned an LDAP deref call >>>> results without objectclass attribute and just with entryusn attribute. Details >>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be >>>> more tolerant in this case, it still breaks old clients which we should prevent. >>>> >>>> There are 2 ways how to fix I currently see: >>>> >>>> 1) Return objectclass for any entry, just like we do with operational attributes >>>> >>>> This would include adding "objectclass" to "System: Read Timestamp and USN >>>> Operational Attributes". However, I am rather cautious about this approach as >>>> even though objectclass does not usually carry a secret information, we could >>>> still leak some information about our DIT to unprivileged user. >>> >>> Our DIT is public and known, I see no problem. >> >> I rather meant the LDAP tree and it's contents (custom groups, sudo rules, >> roles, ...). >> >> I did one more test and found out we cannot do this as it would undermine the >> ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch >> returns every object even if no other attribute is returned: >> >> # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test >> SASL/GSSAPI authentication started >> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >> SASL SSF: 56 >> SASL data security layer installed. >> ... >> # User Administrators, privileges, pbac, mkosek-fedora20.test >> dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >> objectClass: top >> objectClass: groupofnames >> objectClass: nestedgroup >> ... >> >> It would not show any more info before that, but even the list of permissions, >> privileges and roles along with it's names is a leaked information. >> >> >>>> 2) Show objectclass+operational attributes in our Read ACIs >>>> Other way I see is to update *all* our Read permissions allowing reading >>>> objectclass attribute and also allow the chosen LDAP operational attribute. >>>> This would let the LDAP caller to always get either all these discussed >>>> attributes but none at all. >>>> >>>> >>>> Do we want to do this? Any other (better) idea how to approach it? >>> >>> I honestly am not sure I understand the distinction between 1 and 2, can >>> you provide the actual ACIs or a behavior example ? >>> >>> Simo. >> >> Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) >> running LDAP deref call gets entryusn from object it does not have a read >> access to: >> >> # ldapsearch -h `hostname` -Y GSSAPI -b >> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >> 'deref=memberof:objectclass,entryusn' >> SASL/GSSAPI authentication started >> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >> SASL SSF: 56 >> SASL data security layer installed. >> ... >> # memberof: ;cn=replication administrators,cn=privileges,cn=pba >> c,dc=mkosek-fedora20,dc=test >> >> # memberof: ;cn=add replication agreements,cn=permissions,cn=pba >> c,dc=mkosek-fedora20,dc=test >> ... >> >> This confuses SSSD (sees entryusn but does not see objectclass attribute) + may >> give out some information we do not want to give out. Fortunately, bare >> ldapsearch does not show anything: >> >> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn >> SASL/GSSAPI authentication started >> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base > administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with scope subtree >> # filter: (objectclass=*) >> # requesting: entryusn >> # >> >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 1 >> >> >> The idea behind Option 1 was to add ACI to allow reading objectclass attribute >> globally, for our entire tree. (as noted above, not an option). >> >> The idea behind Option 2 was to: >> - remove global ACI allowing reading entryusn (System: Read Timestamp and USN >> Operational Attributes) >> - update all our Read permissions to allow entryusn >> >> Then for example, if user (SSSD) is allowed to read RBAC role objects, he would >> not be able to read either objectclass or entryusn attributes. This means users >> would be only allowed to read entryusn for objects that they can really read >> (i.e. for objects where they can read at least objectclass). >> >> Did that clarify the options? >> >> Of course, there is still option 3) to close as wontfix and let older SSSDs be >> incompatible with FreeIPA 4.0+. > > No, 3 is definitely not on the table, I would rather do 1, but I guess 2 > is the only good way for now ? > > Simo. Yeah - 1) would be easy to implement, but it would be a step back in our ACI model (global allowing ACI again...). Something based on 2) is the only approach that I have in mind right now and that would work. It also looks as the right thing to do as then with changing visibility of objects by our permission system, visibility of entryusn would change too. Programatically it should not be difficult to do, we could add these attributes by default to all read permissions which have allow objectclass attribute so we would not have to update all our read permissions by hand... Martin From npmccallum at redhat.com Fri Sep 12 01:21:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Sep 2014 21:21:05 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5411B638.3080905@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> Message-ID: <1410484865.2941.14.camel@redhat.com> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: > On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > > On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > >> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > >>> > >>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: > >>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: > >> ... > >>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > >>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > >>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any > >>>>> known issues > >>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA > >>>>> 4.0.x to be > >>>>> based on it? > >>>>> > >>>>> If yes, we may need to include the patch in Fedora 21 downstream only > >>>>> after all.. > >>>> > >>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > >>>> couldn't include the patch even there. > >>>> There better be no such issues. > >>> what do you mean by "no such issues" ? I don't think that 389/F21 will > >>> be the first bug free software. At the moment Thierry is investigating a > >>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - > >>> > >> > >> any known issues in the F21 389-ds-base build that would prevent > >> upstream FreeIPA 4.0.x to be based on it > > > > Yes. 389 will not start if weak ciphers are specified. Currently, > > FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > > work at all because the DS will never start. > > > > We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! > > Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! > > Then we need to merge Ludwig's IPA patch from this thread with a > > versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. > > Then we release 4.0.3. > > That's what I understood, but thanks for confirming. > > We need to move fast; FreeIPA is an f21 alpha blocker. > > > >> Plugin crashes or memory leaks are bad, but we can release with them. > > > > +1. The real problem is that without the above fixes, IPA doesn't work > > at all. > > > > Nathaniel > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ticket-4395-change-ciphers-enabled-by-default.patch Type: text/x-patch Size: 3731 bytes Desc: not available URL: From lslebodn at redhat.com Fri Sep 12 05:47:28 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 12 Sep 2014 07:47:28 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <541204E8.3010006@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> Message-ID: <20140912054727.GA22608@mail.corp.redhat.com> On (11/09/14 22:24), Martin Kosek wrote: >On 09/11/2014 08:49 PM, Simo Sorce wrote: >>On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >>>On 09/11/2014 05:37 PM, Simo Sorce wrote: >>>>On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>>>Hello, >>>>> >>>>>We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings >>>>>cause older SSSD clients to fail as they get returned an LDAP deref call >>>>>results without objectclass attribute and just with entryusn attribute. Details >>>>>in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be >>>>>more tolerant in this case, it still breaks old clients which we should prevent. >>>>> >>>>>There are 2 ways how to fix I currently see: >>>>> >>>>>1) Return objectclass for any entry, just like we do with operational attributes >>>>> >>>>>This would include adding "objectclass" to "System: Read Timestamp and USN >>>>>Operational Attributes". However, I am rather cautious about this approach as >>>>>even though objectclass does not usually carry a secret information, we could >>>>>still leak some information about our DIT to unprivileged user. >>>> >>>>Our DIT is public and known, I see no problem. >>> >>>I rather meant the LDAP tree and it's contents (custom groups, sudo rules, >>>roles, ...). >>> >>>I did one more test and found out we cannot do this as it would undermine the >>>ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch >>>returns every object even if no other attribute is returned: >>> >>># ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test >>>SASL/GSSAPI authentication started >>>SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>SASL SSF: 56 >>>SASL data security layer installed. >>>... >>># User Administrators, privileges, pbac, mkosek-fedora20.test >>>dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >>>objectClass: top >>>objectClass: groupofnames >>>objectClass: nestedgroup >>>... >>> >>>It would not show any more info before that, but even the list of permissions, >>>privileges and roles along with it's names is a leaked information. >>> >>> >>>>>2) Show objectclass+operational attributes in our Read ACIs >>>>>Other way I see is to update *all* our Read permissions allowing reading >>>>>objectclass attribute and also allow the chosen LDAP operational attribute. >>>>>This would let the LDAP caller to always get either all these discussed >>>>>attributes but none at all. >>>>> >>>>> >>>>>Do we want to do this? Any other (better) idea how to approach it? >>>> >>>>I honestly am not sure I understand the distinction between 1 and 2, can >>>>you provide the actual ACIs or a behavior example ? >>>> >>>>Simo. >>> >>>Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) >>>running LDAP deref call gets entryusn from object it does not have a read >>>access to: >>> >>># ldapsearch -h `hostname` -Y GSSAPI -b >>>uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>>'deref=memberof:objectclass,entryusn' >>>SASL/GSSAPI authentication started >>>SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>SASL SSF: 56 >>>SASL data security layer installed. >>>... >>># memberof: ;cn=replication administrators,cn=privileges,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>> >>># memberof: ;cn=add replication agreements,cn=permissions,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>>... >>> >>>This confuses SSSD (sees entryusn but does not see objectclass attribute) + may >>>give out some information we do not want to give out. Fortunately, bare >>>ldapsearch does not show anything: >>> >>># ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >>>administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn >>>SASL/GSSAPI authentication started >>>SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>SASL SSF: 56 >>>SASL data security layer installed. >>># extended LDIF >>># >>># LDAPv3 >>># base >>administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with scope subtree >>># filter: (objectclass=*) >>># requesting: entryusn >>># >>> >>># search result >>>search: 4 >>>result: 0 Success >>> >>># numResponses: 1 >>> >>> >>>The idea behind Option 1 was to add ACI to allow reading objectclass attribute >>>globally, for our entire tree. (as noted above, not an option). >>> >>>The idea behind Option 2 was to: >>- remove global ACI allowing reading entryusn (System: Read Timestamp and USN >>>Operational Attributes) >>>- update all our Read permissions to allow entryusn >>> >>>Then for example, if user (SSSD) is allowed to read RBAC role objects, he would >>>not be able to read either objectclass or entryusn attributes. This means users >>>would be only allowed to read entryusn for objects that they can really read >>>(i.e. for objects where they can read at least objectclass). >>> >>>Did that clarify the options? >>> >>>Of course, there is still option 3) to close as wontfix and let older SSSDs be >>>incompatible with FreeIPA 4.0+. >> >>No, 3 is definitely not on the table, I would rather do 1, but I guess 2 >>is the only good way for now ? >> >>Simo. > >Yeah - 1) would be easy to implement, but it would be a step back in our ACI >model (global allowing ACI again...). > >Something based on 2) is the only approach that I have in mind right now and >that would work. It also looks as the right thing to do as then with changing >visibility of objects by our permission system, visibility of entryusn would >change too. > Not just entryUSN. We need also to change visibility of modifyTimestamp. SSSD tries to dereference following atributes: objectClass,cn,gidNumber,member,modifyTimestamp,entryUSN And here is almost equivalent version wit command line ldapsearch. ldapsearch -Y GSSAPI -h ipa.host.name \ -E deref=memberOf:objectClass,cn,gidNumber,member,modifyTimestamp,entryUSN \ -b +"uid=admin,cn=users,cn=accounts,dc=idm,$BASE_DN" "(objectClass=*)" \ objectClass cn userPassword gidNumber member ipaNTSecurityIdentifier \ modifyTimestamp entryUSN //snip # memberOf: ;;cn=replication administrators,cn=privileges,cn=pbac,dc=idm,dc=example,dc=test # memberOf: ;;cn=add replicati on agreements,cn=permissions,cn=pbac,dc=example,dc=test LS From pviktori at redhat.com Fri Sep 12 07:35:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 09:35:56 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <541204E8.3010006@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> Message-ID: <5412A25C.5040409@redhat.com> On 09/11/2014 10:24 PM, Martin Kosek wrote: > On 09/11/2014 08:49 PM, Simo Sorce wrote: >> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >>> On 09/11/2014 05:37 PM, Simo Sorce wrote: >>>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>>> Hello, >>>>> >>>>> We have another important issue to resolve. Current FreeIPA 4.0.2 >>>>> ACI settings >>>>> cause older SSSD clients to fail as they get returned an LDAP deref >>>>> call >>>>> results without objectclass attribute and just with entryusn >>>>> attribute. Details >>>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD >>>>> should be >>>>> more tolerant in this case, it still breaks old clients which we >>>>> should prevent. >>>>> >>>>> There are 2 ways how to fix I currently see: >>>>> >>>>> 1) Return objectclass for any entry, just like we do with >>>>> operational attributes >>>>> >>>>> This would include adding "objectclass" to "System: Read Timestamp >>>>> and USN >>>>> Operational Attributes". However, I am rather cautious about this >>>>> approach as >>>>> even though objectclass does not usually carry a secret >>>>> information, we could >>>>> still leak some information about our DIT to unprivileged user. >>>> >>>> Our DIT is public and known, I see no problem. >>> >>> I rather meant the LDAP tree and it's contents (custom groups, sudo >>> rules, >>> roles, ...). >>> >>> I did one more test and found out we cannot do this as it would >>> undermine the >>> ACIs we have right now. As soon as objectclass is allowed globally, >>> ldapsearch >>> returns every object even if no other attribute is returned: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b >>> cn=pbac,dc=mkosek-fedora20,dc=test >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> ... >>> # User Administrators, privileges, pbac, mkosek-fedora20.test >>> dn: cn=User >>> Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >>> objectClass: top >>> objectClass: groupofnames >>> objectClass: nestedgroup >>> ... >>> >>> It would not show any more info before that, but even the list of >>> permissions, >>> privileges and roles along with it's names is a leaked information. >>> >>> >>>>> 2) Show objectclass+operational attributes in our Read ACIs >>>>> Other way I see is to update *all* our Read permissions allowing >>>>> reading >>>>> objectclass attribute and also allow the chosen LDAP operational >>>>> attribute. >>>>> This would let the LDAP caller to always get either all these >>>>> discussed >>>>> attributes but none at all. >>>>> >>>>> >>>>> Do we want to do this? Any other (better) idea how to approach it? >>>> >>>> I honestly am not sure I understand the distinction between 1 and 2, >>>> can >>>> you provide the actual ACIs or a behavior example ? >>>> >>>> Simo. >>> >>> Currently, our ACI allows reading entryusn in any LDAP entry. So user >>> (SSSD) >>> running LDAP deref call gets entryusn from object it does not have a >>> read >>> access to: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b >>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>> 'deref=memberof:objectclass,entryusn' >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> ... >>> # memberof: ;cn=replication >>> administrators,cn=privileges,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>> >>> # memberof: ;cn=add replication >>> agreements,cn=permissions,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>> ... >>> >>> This confuses SSSD (sees entryusn but does not see objectclass >>> attribute) + may >>> give out some information we do not want to give out. Fortunately, bare >>> ldapsearch does not show anything: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" >>> entryusn >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base >> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with >>> scope subtree >>> # filter: (objectclass=*) >>> # requesting: entryusn >>> # >>> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # numResponses: 1 >>> >>> >>> The idea behind Option 1 was to add ACI to allow reading objectclass >>> attribute >>> globally, for our entire tree. (as noted above, not an option). >>> >>> The idea behind Option 2 was to: >>> - remove global ACI allowing reading entryusn (System: Read Timestamp >>> and USN >>> Operational Attributes) Removing a default ACI is difficult (read: new code that could go wrong) if we want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always add it back. Perhaps we should just say in the release notes that people should remove it manually if they're upgrading from 4.0.2? >>> - update all our Read permissions to allow entryusn >>> >>> Then for example, if user (SSSD) is allowed to read RBAC role >>> objects, he would >>> not be able to read either objectclass or entryusn attributes. This >>> means users >>> would be only allowed to read entryusn for objects that they can >>> really read >>> (i.e. for objects where they can read at least objectclass). >>> >>> Did that clarify the options? >>> >>> Of course, there is still option 3) to close as wontfix and let older >>> SSSDs be >>> incompatible with FreeIPA 4.0+. >> >> No, 3 is definitely not on the table, I would rather do 1, but I guess 2 >> is the only good way for now ? >> >> Simo. > > Yeah - 1) would be easy to implement, but it would be a step back in our > ACI model (global allowing ACI again...). > > Something based on 2) is the only approach that I have in mind right now > and that would work. It also looks as the right thing to do as then with > changing visibility of objects by our permission system, visibility of > entryusn would change too. > > Programatically it should not be difficult to do, we could add these > attributes by default to all read permissions which have allow > objectclass attribute so we would not have to update all our read > permissions by hand... > > Martin -- Petr? From mkosek at redhat.com Fri Sep 12 07:37:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 09:37:20 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410484865.2941.14.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> Message-ID: <5412A2B0.7050200@redhat.com> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: > On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>> >>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>> ... >>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>> known issues >>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>> 4.0.x to be >>>>>>> based on it? >>>>>>> >>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>>> after all.. >>>>>> >>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>> couldn't include the patch even there. >>>>>> There better be no such issues. >>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>>> be the first bug free software. At the moment Thierry is investigating a >>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>>> >>>> >>>> any known issues in the F21 389-ds-base build that would prevent >>>> upstream FreeIPA 4.0.x to be based on it >>> >>> Yes. 389 will not start if weak ciphers are specified. Currently, >>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>> work at all because the DS will never start. >>> >>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 > > Done: thanks everyone on the DS side! > >>> Then, we need an F21 build of 389-ds-base. > > Done: thanks nhosoi! > >>> Then we need to merge Ludwig's IPA patch from this thread with a >>> versioned dependency on the new 389-ds-base build. > > New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute "allowweakciphers" not allowed I think you simply use a wrong config name - have extra "s" in the end. It is defined as allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] Also, do we really need to put it to "off" in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to "on" (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. Martin From mkosek at redhat.com Fri Sep 12 07:42:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 09:42:25 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5412A25C.5040409@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412A25C.5040409@redhat.com> Message-ID: <5412A3E1.3070203@redhat.com> On 09/12/2014 09:35 AM, Petr Viktorin wrote: > On 09/11/2014 10:24 PM, Martin Kosek wrote: >> On 09/11/2014 08:49 PM, Simo Sorce wrote: >>> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >>>> On 09/11/2014 05:37 PM, Simo Sorce wrote: >>>>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>>>> Hello, >>>>>> >>>>>> We have another important issue to resolve. Current FreeIPA 4.0.2 >>>>>> ACI settings >>>>>> cause older SSSD clients to fail as they get returned an LDAP deref >>>>>> call >>>>>> results without objectclass attribute and just with entryusn >>>>>> attribute. Details >>>>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD >>>>>> should be >>>>>> more tolerant in this case, it still breaks old clients which we >>>>>> should prevent. >>>>>> >>>>>> There are 2 ways how to fix I currently see: >>>>>> >>>>>> 1) Return objectclass for any entry, just like we do with >>>>>> operational attributes >>>>>> >>>>>> This would include adding "objectclass" to "System: Read Timestamp >>>>>> and USN >>>>>> Operational Attributes". However, I am rather cautious about this >>>>>> approach as >>>>>> even though objectclass does not usually carry a secret >>>>>> information, we could >>>>>> still leak some information about our DIT to unprivileged user. >>>>> >>>>> Our DIT is public and known, I see no problem. >>>> >>>> I rather meant the LDAP tree and it's contents (custom groups, sudo >>>> rules, >>>> roles, ...). >>>> >>>> I did one more test and found out we cannot do this as it would >>>> undermine the >>>> ACIs we have right now. As soon as objectclass is allowed globally, >>>> ldapsearch >>>> returns every object even if no other attribute is returned: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b >>>> cn=pbac,dc=mkosek-fedora20,dc=test >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> ... >>>> # User Administrators, privileges, pbac, mkosek-fedora20.test >>>> dn: cn=User >>>> Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >>>> objectClass: top >>>> objectClass: groupofnames >>>> objectClass: nestedgroup >>>> ... >>>> >>>> It would not show any more info before that, but even the list of >>>> permissions, >>>> privileges and roles along with it's names is a leaked information. >>>> >>>> >>>>>> 2) Show objectclass+operational attributes in our Read ACIs >>>>>> Other way I see is to update *all* our Read permissions allowing >>>>>> reading >>>>>> objectclass attribute and also allow the chosen LDAP operational >>>>>> attribute. >>>>>> This would let the LDAP caller to always get either all these >>>>>> discussed >>>>>> attributes but none at all. >>>>>> >>>>>> >>>>>> Do we want to do this? Any other (better) idea how to approach it? >>>>> >>>>> I honestly am not sure I understand the distinction between 1 and 2, >>>>> can >>>>> you provide the actual ACIs or a behavior example ? >>>>> >>>>> Simo. >>>> >>>> Currently, our ACI allows reading entryusn in any LDAP entry. So user >>>> (SSSD) >>>> running LDAP deref call gets entryusn from object it does not have a >>>> read >>>> access to: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b >>>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>>> 'deref=memberof:objectclass,entryusn' >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> ... >>>> # memberof: ;cn=replication >>>> administrators,cn=privileges,cn=pba >>>> c,dc=mkosek-fedora20,dc=test >>>> >>>> # memberof: ;cn=add replication >>>> agreements,cn=permissions,cn=pba >>>> c,dc=mkosek-fedora20,dc=test >>>> ... >>>> >>>> This confuses SSSD (sees entryusn but does not see objectclass >>>> attribute) + may >>>> give out some information we do not want to give out. Fortunately, bare >>>> ldapsearch does not show anything: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >>>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" >>>> entryusn >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with >>>> scope subtree >>>> # filter: (objectclass=*) >>>> # requesting: entryusn >>>> # >>>> >>>> # search result >>>> search: 4 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> >>>> >>>> The idea behind Option 1 was to add ACI to allow reading objectclass >>>> attribute >>>> globally, for our entire tree. (as noted above, not an option). >>>> >>>> The idea behind Option 2 was to: >>>> - remove global ACI allowing reading entryusn (System: Read Timestamp >>>> and USN >>>> Operational Attributes) > > Removing a default ACI is difficult (read: new code that could go wrong) if we > want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always > add it back. > Perhaps we should just say in the release notes that people should remove it > manually if they're upgrading from 4.0.2? Well, I am not convinced that everyone reads the release notes, so I would rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 users. It seems as a lesser evil to me than having SSSD clients broken. >>>> - update all our Read permissions to allow entryusn >>>> >>>> Then for example, if user (SSSD) is allowed to read RBAC role >>>> objects, he would >>>> not be able to read either objectclass or entryusn attributes. This >>>> means users >>>> would be only allowed to read entryusn for objects that they can >>>> really read >>>> (i.e. for objects where they can read at least objectclass). >>>> >>>> Did that clarify the options? >>>> >>>> Of course, there is still option 3) to close as wontfix and let older >>>> SSSDs be >>>> incompatible with FreeIPA 4.0+. >>> >>> No, 3 is definitely not on the table, I would rather do 1, but I guess 2 >>> is the only good way for now ? >>> >>> Simo. >> >> Yeah - 1) would be easy to implement, but it would be a step back in our >> ACI model (global allowing ACI again...). >> >> Something based on 2) is the only approach that I have in mind right now >> and that would work. It also looks as the right thing to do as then with >> changing visibility of objects by our permission system, visibility of >> entryusn would change too. >> >> Programatically it should not be difficult to do, we could add these >> attributes by default to all read permissions which have allow >> objectclass attribute so we would not have to update all our read >> permissions by hand... >> >> Martin From abokovoy at redhat.com Fri Sep 12 07:48:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Sep 2014 10:48:09 +0300 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5412A3E1.3070203@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412A25C.5040409@redhat.com> <5412A3E1.3070203@redhat.com> Message-ID: <20140912074809.GG2541@redhat.com> On Fri, 12 Sep 2014, Martin Kosek wrote: >>>>>Operational Attributes) >> >>Removing a default ACI is difficult (read: new code that could go wrong) if we >>want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always >>add it back. >>Perhaps we should just say in the release notes that people should remove it >>manually if they're upgrading from 4.0.2? > >Well, I am not convinced that everyone reads the release notes, so I >would rather delete this permission in 4.0.3. Hopefully, there won't >be many 4.0.2 users. It seems as a lesser evil to me than having SSSD >clients broken. If we are going to replace other ACIs by adding to them a right to read these attributes, then removing a separate default ACI is not a problem, isn't it? -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 12 08:06:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 10:06:38 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <20140912074809.GG2541@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412A25C.5040409@redhat.com> <5412A3E1.3070203@redhat.com> <20140912074809.GG2541@redhat.com> Message-ID: <5412A98E.5000608@redhat.com> On 09/12/2014 09:48 AM, Alexander Bokovoy wrote: > On Fri, 12 Sep 2014, Martin Kosek wrote: >>>>>> Operational Attributes) >>> >>> Removing a default ACI is difficult (read: new code that could go >>> wrong) if we >>> want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 >>> will always >>> add it back. >>> Perhaps we should just say in the release notes that people should >>> remove it >>> manually if they're upgrading from 4.0.2? >> >> Well, I am not convinced that everyone reads the release notes, so I >> would rather delete this permission in 4.0.3. Hopefully, there won't >> be many 4.0.2 users. It seems as a lesser evil to me than having SSSD >> clients broken. > If we are going to replace other ACIs by adding to them a right to read > these attributes, then removing a separate default ACI is not a problem, > isn't it? It's not much of a policy problem, it's just adding new code this late in the cycle: The permission updater doesn't yet have a mechanism to remove a permission, so I'm writing it now. -- Petr? From lkrispen at redhat.com Fri Sep 12 08:13:09 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Sep 2014 10:13:09 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5412A2B0.7050200@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> Message-ID: <5412AB15.9000503@redhat.com> On 09/12/2014 09:37 AM, Martin Kosek wrote: > On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: >> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>>> >>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>>> ... >>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA >>>>>>>> Copr: >>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>>> known issues >>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>>> 4.0.x to be >>>>>>>> based on it? >>>>>>>> >>>>>>>> If yes, we may need to include the patch in Fedora 21 >>>>>>>> downstream only >>>>>>>> after all.. >>>>>>> >>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>>> couldn't include the patch even there. >>>>>>> There better be no such issues. >>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 >>>>>> will >>>>>> be the first bug free software. At the moment Thierry is >>>>>> investigating a >>>>>> crash in dna-plugin and Noriko a memory leak, which could be in >>>>>> F21 - >>>>>> >>>>> >>>>> any known issues in the F21 389-ds-base build that would prevent >>>>> upstream FreeIPA 4.0.x to be based on it >>>> >>>> Yes. 389 will not start if weak ciphers are specified. Currently, >>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>>> work at all because the DS will never start. >>>> >>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 >> >> Done: thanks everyone on the DS side! >> >>>> Then, we need an F21 build of 389-ds-base. >> >> Done: thanks nhosoi! >> >>>> Then we need to merge Ludwig's IPA patch from this thread with a >>>> versioned dependency on the new 389-ds-base build. >> >> New patch attached which includes a versioned dep on the new DS. > > ipa-server-install still fails for me, even when I use > 389-ds-base-1.3.3.2-1.fc20.x86_64: > > # ipa-server-install > ... > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Unexpected error - see /var/log/ipaserver-install.log for details: > ObjectclassViolation: attribute "allowweakciphers" not allowed > > > I think you simply use a wrong config name - have extra "s" in the > end. It is defined as that typo was already in my first draft of the patch, sorry > > allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] > > > Also, do we really need to put it to "off" in the updates? AFAIU, it > is off by default in our config and with current setting, users could > not put it to "on" (for whatever reason) without the value being > overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should "only:allowWeakCipher" be replaced by "addifnew" ? > > Martin From mkosek at redhat.com Fri Sep 12 08:25:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 10:25:37 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5412AB15.9000503@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> Message-ID: <5412AE01.8080609@redhat.com> On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: > > On 09/12/2014 09:37 AM, Martin Kosek wrote: >> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>>>> >>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>>>> ... >>>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>>>> known issues >>>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>>>> 4.0.x to be >>>>>>>>> based on it? >>>>>>>>> >>>>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>>>>> after all.. >>>>>>>> >>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>>>> couldn't include the patch even there. >>>>>>>> There better be no such issues. >>>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>>>>> be the first bug free software. At the moment Thierry is investigating a >>>>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>>>>> >>>>>> >>>>>> any known issues in the F21 389-ds-base build that would prevent >>>>>> upstream FreeIPA 4.0.x to be based on it >>>>> >>>>> Yes. 389 will not start if weak ciphers are specified. Currently, >>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>>>> work at all because the DS will never start. >>>>> >>>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 >>> >>> Done: thanks everyone on the DS side! >>> >>>>> Then, we need an F21 build of 389-ds-base. >>> >>> Done: thanks nhosoi! >>> >>>>> Then we need to merge Ludwig's IPA patch from this thread with a >>>>> versioned dependency on the new 389-ds-base build. >>> >>> New patch attached which includes a versioned dep on the new DS. >> >> ipa-server-install still fails for me, even when I use >> 389-ds-base-1.3.3.2-1.fc20.x86_64: >> >> # ipa-server-install >> ... >> [12/13]: restarting httpd >> [13/13]: configuring httpd to start on boot >> Done configuring the web interface (httpd). >> Applying LDAP updates >> Unexpected error - see /var/log/ipaserver-install.log for details: >> ObjectclassViolation: attribute "allowweakciphers" not allowed >> >> >> I think you simply use a wrong config name - have extra "s" in the end. It is >> defined as > that typo was already in my first draft of the patch, sorry >> >> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] >> >> >> Also, do we really need to put it to "off" in the updates? AFAIU, it is off >> by default in our config and with current setting, users could not put it to >> "on" (for whatever reason) without the value being overwritten with every run >> of FreeIPA upgrade. > could there be an upgrade from a install not yet using that params. should > "only:allowWeakCipher" be replaced by "addifnew" ? You can try "default:allowWeakCiphers: off" - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad "From" field - I would rather expect it to be "Ludwig Krispenz " than "lkrispen " Thanks, Martin From tbordaz at redhat.com Fri Sep 12 08:27:19 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 12 Sep 2014 10:27:19 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <541204E8.3010006@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> Message-ID: <5412AE67.4040500@redhat.com> On 09/11/2014 10:24 PM, Martin Kosek wrote: > On 09/11/2014 08:49 PM, Simo Sorce wrote: >> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >>> On 09/11/2014 05:37 PM, Simo Sorce wrote: >>>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>>> Hello, >>>>> >>>>> We have another important issue to resolve. Current FreeIPA 4.0.2 >>>>> ACI settings >>>>> cause older SSSD clients to fail as they get returned an LDAP >>>>> deref call >>>>> results without objectclass attribute and just with entryusn >>>>> attribute. Details >>>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree >>>>> SSSD should be >>>>> more tolerant in this case, it still breaks old clients which we >>>>> should prevent. >>>>> >>>>> There are 2 ways how to fix I currently see: >>>>> >>>>> 1) Return objectclass for any entry, just like we do with >>>>> operational attributes >>>>> >>>>> This would include adding "objectclass" to "System: Read Timestamp >>>>> and USN >>>>> Operational Attributes". However, I am rather cautious about this >>>>> approach as >>>>> even though objectclass does not usually carry a secret >>>>> information, we could >>>>> still leak some information about our DIT to unprivileged user. >>>> >>>> Our DIT is public and known, I see no problem. >>> >>> I rather meant the LDAP tree and it's contents (custom groups, sudo >>> rules, >>> roles, ...). >>> >>> I did one more test and found out we cannot do this as it would >>> undermine the >>> ACIs we have right now. As soon as objectclass is allowed globally, >>> ldapsearch >>> returns every object even if no other attribute is returned: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b >>> cn=pbac,dc=mkosek-fedora20,dc=test >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> ... >>> # User Administrators, privileges, pbac, mkosek-fedora20.test >>> dn: cn=User >>> Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >>> objectClass: top >>> objectClass: groupofnames >>> objectClass: nestedgroup >>> ... >>> >>> It would not show any more info before that, but even the list of >>> permissions, >>> privileges and roles along with it's names is a leaked information. >>> >>> >>>>> 2) Show objectclass+operational attributes in our Read ACIs >>>>> Other way I see is to update *all* our Read permissions allowing >>>>> reading >>>>> objectclass attribute and also allow the chosen LDAP operational >>>>> attribute. >>>>> This would let the LDAP caller to always get either all these >>>>> discussed >>>>> attributes but none at all. >>>>> >>>>> >>>>> Do we want to do this? Any other (better) idea how to approach it? >>>> >>>> I honestly am not sure I understand the distinction between 1 and >>>> 2, can >>>> you provide the actual ACIs or a behavior example ? >>>> >>>> Simo. >>> >>> Currently, our ACI allows reading entryusn in any LDAP entry. So >>> user (SSSD) >>> running LDAP deref call gets entryusn from object it does not have a >>> read >>> access to: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b >>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>> 'deref=memberof:objectclass,entryusn' >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> ... >>> # memberof: ;cn=replication >>> administrators,cn=privileges,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>> >>> # memberof: ;cn=add replication >>> agreements,cn=permissions,cn=pba >>> c,dc=mkosek-fedora20,dc=test >>> ... >>> >>> This confuses SSSD (sees entryusn but does not see objectclass >>> attribute) + may >>> give out some information we do not want to give out. Fortunately, bare >>> ldapsearch does not show anything: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" >>> entryusn >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base >> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> >>> with scope subtree >>> # filter: (objectclass=*) >>> # requesting: entryusn >>> # >>> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # numResponses: 1 >>> >>> >>> The idea behind Option 1 was to add ACI to allow reading objectclass >>> attribute >>> globally, for our entire tree. (as noted above, not an option). >>> >>> The idea behind Option 2 was to: >>> - remove global ACI allowing reading entryusn (System: Read >>> Timestamp and USN >>> Operational Attributes) >>> - update all our Read permissions to allow entryusn >>> >>> Then for example, if user (SSSD) is allowed to read RBAC role >>> objects, he would >>> not be able to read either objectclass or entryusn attributes. This >>> means users >>> would be only allowed to read entryusn for objects that they can >>> really read >>> (i.e. for objects where they can read at least objectclass). >>> >>> Did that clarify the options? >>> >>> Of course, there is still option 3) to close as wontfix and let >>> older SSSDs be >>> incompatible with FreeIPA 4.0+. >> >> No, 3 is definitely not on the table, I would rather do 1, but I guess 2 >> is the only good way for now ? >> >> Simo. > > Yeah - 1) would be easy to implement, but it would be a step back in > our ACI model (global allowing ACI again...). > > Something based on 2) is the only approach that I have in mind right > now and that would work. It also looks as the right thing to do as > then with changing visibility of objects by our permission system, > visibility of entryusn would change too. > > Programatically it should not be difficult to do, we could add these > attributes by default to all read permissions which have allow > objectclass attribute so we would not have to update all our read > permissions by hand... Hello, I was thinking to an other option that is looking more as a hack. It is to relax the aci checking (for a given list of attributes) in deref plugin. For example, if a user has access to at least one of the requested attribute (e.g. entryusn), in the deref req, then the derefenced entry could be returned with additional attributes (given in the deref plugin config.: 'objectclass', 'cn'). I honestly do not like this option but in case changing aci definitions is too risky/complex it is an option. regards thierry > ' > Martin > > _______________________________________________ > 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 mkosek at redhat.com Fri Sep 12 08:33:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 10:33:58 +0200 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5412AE67.4040500@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412AE67.4040500@redhat.com> Message-ID: <5412AFF6.9080008@redhat.com> On 09/12/2014 10:27 AM, thierry bordaz wrote: > On 09/11/2014 10:24 PM, Martin Kosek wrote: >> On 09/11/2014 08:49 PM, Simo Sorce wrote: >>> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: >>>> On 09/11/2014 05:37 PM, Simo Sorce wrote: >>>>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: >>>>>> Hello, >>>>>> >>>>>> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI >>>>>> settings >>>>>> cause older SSSD clients to fail as they get returned an LDAP deref call >>>>>> results without objectclass attribute and just with entryusn attribute. >>>>>> Details >>>>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD >>>>>> should be >>>>>> more tolerant in this case, it still breaks old clients which we should >>>>>> prevent. >>>>>> >>>>>> There are 2 ways how to fix I currently see: >>>>>> >>>>>> 1) Return objectclass for any entry, just like we do with operational >>>>>> attributes >>>>>> >>>>>> This would include adding "objectclass" to "System: Read Timestamp and USN >>>>>> Operational Attributes". However, I am rather cautious about this >>>>>> approach as >>>>>> even though objectclass does not usually carry a secret information, we >>>>>> could >>>>>> still leak some information about our DIT to unprivileged user. >>>>> >>>>> Our DIT is public and known, I see no problem. >>>> >>>> I rather meant the LDAP tree and it's contents (custom groups, sudo rules, >>>> roles, ...). >>>> >>>> I did one more test and found out we cannot do this as it would undermine the >>>> ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch >>>> returns every object even if no other attribute is returned: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> ... >>>> # User Administrators, privileges, pbac, mkosek-fedora20.test >>>> dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test >>>> objectClass: top >>>> objectClass: groupofnames >>>> objectClass: nestedgroup >>>> ... >>>> >>>> It would not show any more info before that, but even the list of permissions, >>>> privileges and roles along with it's names is a leaked information. >>>> >>>> >>>>>> 2) Show objectclass+operational attributes in our Read ACIs >>>>>> Other way I see is to update *all* our Read permissions allowing reading >>>>>> objectclass attribute and also allow the chosen LDAP operational attribute. >>>>>> This would let the LDAP caller to always get either all these discussed >>>>>> attributes but none at all. >>>>>> >>>>>> >>>>>> Do we want to do this? Any other (better) idea how to approach it? >>>>> >>>>> I honestly am not sure I understand the distinction between 1 and 2, can >>>>> you provide the actual ACIs or a behavior example ? >>>>> >>>>> Simo. >>>> >>>> Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) >>>> running LDAP deref call gets entryusn from object it does not have a read >>>> access to: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b >>>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>>> 'deref=memberof:objectclass,entryusn' >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> ... >>>> # memberof: ;cn=replication administrators,cn=privileges,cn=pba >>>> c,dc=mkosek-fedora20,dc=test >>>> >>>> # memberof: ;cn=add replication agreements,cn=permissions,cn=pba >>>> c,dc=mkosek-fedora20,dc=test >>>> ... >>>> >>>> This confuses SSSD (sees entryusn but does not see objectclass attribute) + >>>> may >>>> give out some information we do not want to give out. Fortunately, bare >>>> ldapsearch does not show anything: >>>> >>>> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication >>>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn >>>> SASL/GSSAPI authentication started >>>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with scope >>>> subtree >>>> # filter: (objectclass=*) >>>> # requesting: entryusn >>>> # >>>> >>>> # search result >>>> search: 4 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> >>>> >>>> The idea behind Option 1 was to add ACI to allow reading objectclass attribute >>>> globally, for our entire tree. (as noted above, not an option). >>>> >>>> The idea behind Option 2 was to: >>>> - remove global ACI allowing reading entryusn (System: Read Timestamp and USN >>>> Operational Attributes) >>>> - update all our Read permissions to allow entryusn >>>> >>>> Then for example, if user (SSSD) is allowed to read RBAC role objects, he >>>> would >>>> not be able to read either objectclass or entryusn attributes. This means >>>> users >>>> would be only allowed to read entryusn for objects that they can really read >>>> (i.e. for objects where they can read at least objectclass). >>>> >>>> Did that clarify the options? >>>> >>>> Of course, there is still option 3) to close as wontfix and let older SSSDs be >>>> incompatible with FreeIPA 4.0+. >>> >>> No, 3 is definitely not on the table, I would rather do 1, but I guess 2 >>> is the only good way for now ? >>> >>> Simo. >> >> Yeah - 1) would be easy to implement, but it would be a step back in our ACI >> model (global allowing ACI again...). >> >> Something based on 2) is the only approach that I have in mind right now and >> that would work. It also looks as the right thing to do as then with changing >> visibility of objects by our permission system, visibility of entryusn would >> change too. >> >> Programatically it should not be difficult to do, we could add these >> attributes by default to all read permissions which have allow objectclass >> attribute so we would not have to update all our read permissions by hand... > > Hello, > > I was thinking to an other option that is looking more as a hack. It is to > relax the aci checking (for a given list of attributes) in deref plugin. > For example, if a user has access to at least one of the requested > attribute (e.g. entryusn), in the deref req, then the derefenced entry > could be returned with additional attributes (given in the deref plugin > config.: 'objectclass', 'cn'). > > I honestly do not like this option but in case changing aci definitions is > too risky/complex it is an option. > > regards > thierry Hello Thierry, Thanks for the idea, though I share your skepticism to this approach. If adding the operational attributes to our Read ACIs is doable, I would also rather like to follow that path. Martin From dkupka at redhat.com Fri Sep 12 10:05:32 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 12 Sep 2014 12:05:32 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <540DD195.3070804@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> Message-ID: <5412C56C.7060404@redhat.com> On 09/08/2014 05:56 PM, Martin Basti wrote: > On 02/09/14 16:55, David Kupka wrote: >> The patch now depends on freeipa-dkupka-0012 as both modifies the same >> part of code. freeipa-dkupka-0012 is now accepted and merged upstream so there is no need to take this dependency into account. >> >> On 09/02/2014 10:29 AM, David Kupka wrote: >>> Forget to add str() conversion to some places when removing map(). Now >>> it should be working again. >>> >>> On 08/27/2014 02:24 PM, David Kupka wrote: >>>> 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. >>>>> >>>>> > I haven't tested it yet, I only take a look because there may be > conflict with 'dns root zone support' refactoring > > 1) > + for ns_ip_address in nameserver_ip_address: > + add_zone(self.domain, self.zonemgr, > dns_backup=self.dns_backup, > + ns_hostname=api.env.host, ns_ip_address=ns_ip_address, > + force=True) > Are you sure this will work? Domain name is the same, so no new zone > will be created (DuplicateEntry exception is handled inside add_zone > function). > IMO you should call add_zone only once. Fixed, thanks. > > BTW: I will change the add_zone function in refactoring , ns_hostname > wil be remove, and ns_ip_address will take an p+ipv6 address > > 2) > + resolv_txt = '' > + for ip_address in self.ip_address: > + resolv_txt += "search "+self.domain+"\nnameserver > "+str(ip_address)+"\n" > There is multiple search statements. > > search example.com > nameserver 192.168.1.1 > search example.com > nameserver 2001:db8::1 > ... > > and also there si a limit of namesevers which can be in resolv.conf, but > I dont know if we care, statements over limit should be just ignored. > http://linux.die.net/man/5/resolv.conf Since now, only localhost addresses (::1, 127.0.0.1) are placed inside this file when DNS server is part of the installation. > > 3) > self.ip_address is confusing for me, I'm expecting only one address. > Could it be ip_addresses or ip_address_list? Ask the framework gurus :-) > Changed to plural as there are other variables named this way. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-5-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 35783 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 12 11:17:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 13:17:40 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5412AE01.8080609@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> <5412AE01.8080609@redhat.com> Message-ID: <5412D654.3030601@redhat.com> On 09/12/2014 10:25 AM, Martin Kosek wrote: > On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: >> >> On 09/12/2014 09:37 AM, Martin Kosek wrote: >>> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: >>>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >>>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>>>>> >>>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>>>>> ... >>>>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>>>>> known issues >>>>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>>>>> 4.0.x to be >>>>>>>>>> based on it? >>>>>>>>>> >>>>>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>>>>>> after all.. >>>>>>>>> >>>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>>>>> couldn't include the patch even there. >>>>>>>>> There better be no such issues. >>>>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>>>>>> be the first bug free software. At the moment Thierry is investigating a >>>>>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>>>>>> >>>>>>> >>>>>>> any known issues in the F21 389-ds-base build that would prevent >>>>>>> upstream FreeIPA 4.0.x to be based on it >>>>>> >>>>>> Yes. 389 will not start if weak ciphers are specified. Currently, >>>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>>>>> work at all because the DS will never start. >>>>>> >>>>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 >>>> >>>> Done: thanks everyone on the DS side! >>>> >>>>>> Then, we need an F21 build of 389-ds-base. >>>> >>>> Done: thanks nhosoi! >>>> >>>>>> Then we need to merge Ludwig's IPA patch from this thread with a >>>>>> versioned dependency on the new 389-ds-base build. >>>> >>>> New patch attached which includes a versioned dep on the new DS. >>> >>> ipa-server-install still fails for me, even when I use >>> 389-ds-base-1.3.3.2-1.fc20.x86_64: >>> >>> # ipa-server-install >>> ... >>> [12/13]: restarting httpd >>> [13/13]: configuring httpd to start on boot >>> Done configuring the web interface (httpd). >>> Applying LDAP updates >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> ObjectclassViolation: attribute "allowweakciphers" not allowed >>> >>> >>> I think you simply use a wrong config name - have extra "s" in the end. It is >>> defined as >> that typo was already in my first draft of the patch, sorry >>> >>> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] >>> >>> >>> Also, do we really need to put it to "off" in the updates? AFAIU, it is off >>> by default in our config and with current setting, users could not put it to >>> "on" (for whatever reason) without the value being overwritten with every run >>> of FreeIPA upgrade. >> could there be an upgrade from a install not yet using that params. should >> "only:allowWeakCipher" be replaced by "addifnew" ? > > You can try "default:allowWeakCiphers: off" - it would set the attribute to off > if it was not there before. > > Given you are probably working on updated version, I would also recommend > following > > http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 > > as I saw couple nitpicks with your patch > - ticket number in patch description and not in it's body > - bad "From" field - I would rather expect it to be "Ludwig Krispenz > " than "lkrispen " > > Thanks, > Martin Hello, any update on this front? Are you or Nathaniel updating the patch? From lkrispen at redhat.com Fri Sep 12 11:21:52 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Sep 2014 13:21:52 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base Message-ID: <5412D750.5030608@redhat.com> please review attached patch for ticket: https://fedorahosted.org/freeipa/ticket/4395 use new options in 389-ds to configure enabled ciphers -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0001-Update-SSL-ciphers-configured-in-389-ds-base.patch Type: text/x-patch Size: 3919 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 12 11:53:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 13:53:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions Message-ID: <5412DEA4.9020300@redhat.com> https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0642-permission-plugin-Auto-add-operational-atttributes-t.patch Type: text/x-patch Size: 61379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0643-Allow-deleting-obsolete-permissions-remove-Timestamp.patch Type: text/x-patch Size: 5896 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 12 12:45:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 14:45:51 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks In-Reply-To: <5411FED9.9070908@redhat.com> References: <5411728D.8050405@redhat.com> <5411AA38.4030309@redhat.com> <5411CF24.2030200@redhat.com> <5411FED9.9070908@redhat.com> Message-ID: <5412EAFF.7030703@redhat.com> On 11/09/14 21:58, Petr Spacek wrote: > On 11.9.2014 18:34, Martin Basti wrote: >> On 11/09/14 15:57, Martin Basti wrote: >>> On 11/09/14 11:59, Petr Spacek wrote: >>>> Hello, >>>> >>>> I was fighting with random crashes for couple of days ... and >>>> discovered >>>> that run_exclusive_enter()/isc_task_beginexclusive() usage was >>>> completely >>>> incorrect and didn't actually lock anything. >>>> >>>> This series of patches reworks internal locking (and related event >>>> system) >>>> to work around limitations of isc_task_beginexclusive() mechanism. >>>> >>>> It would be better to get rid of isc_task_beginexclusive() >>>> completely but >>>> IMHO it is not possible because of BIND's dns_view*() functions >>>> have to be >>>> guarded with it. >>>> >>>> >>>> Testing is going to be interesting because we are speaking about race >>>> conditions. >>>> >>>> I used ~ 100 DNS zones, each zone had ~ 100 random domain names >>>> inside with >>>> random A/AAAA/TXT RRs. My LDIF is here: >>>> http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz >>>> >>>> I was able to randomly reproduce various crashes when BIND was >>>> running with >>>> more threads than usually. >>>> >>>> You can try to run BIND with this command (as root) and play games >>>> with -n >>>> parameter: >>>> $ export KRB5_KTNAME="/etc/named.keytab" >>>> $ named -4 -g -u named -m record -n 10 >>>> >>>> Please test also the case where BIND receives SIGINT during >>>> start-up. It is >>>> possible to run BIND with commands above and wait for message: >>>> 11-Sep-2014 11:54:58.092 running >>>> >>>> At this point send SIGINT (CTRL+C) to BIND and see what happens. It >>>> could >>>> crash or deadlock. >>>> >>>> It is necessary to send the signal before BIND prints this message: >>>> 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 >>>> >>>> Let me know if you need any assistance. >>>> >>> I need your assistance, I haven't been able to reproduce it. >>> >>> Martin >>> >> I applied the patchset, and NACK > > I don't understand how I could possibly miss this. I was convinced > that the patch set was thoroughly tested ... > > Anyway, attached patch should fix the problem you were facing. Please > re-test it. > > Thank you! > > Petr^2 Spacek > >> #1 >> If named is running and I randomly choose few zones and delete them, >> it causes >> named failure >> >> dig @localhost A r1.z12.test >> >> ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> @localhost A >> r1.z12.test >> ; (2 servers found) >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> * SIGINT doesn't work >> * rndc doesn't work >> * DS worksSIGINT signal stops working. >> >> Output: >> >> 11-Sep-2014 11:26:37.495 client 127.0.0.1#62615: received notify for >> zone >> 'z99.test' >> >> ^C^C^C^C^C^C^C^C >> >> >> Process: >> named 29125 1.1 2.9 789972 45976 pts/0 Sl+ 11:26 0:02 >> named -4 -g >> -u named -m record -n 10 >> >> I have to kill it with kill -9 >> >> #2 >> same as #1 If new zone is added, >> >> #3 >> same as #1 If new record is added >> >> #4 >> same as #1 If record is deleted Functional ACK -- Martin Basti From pspacek at redhat.com Fri Sep 12 13:09:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 15:09:16 +0200 Subject: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks In-Reply-To: <5412EAFF.7030703@redhat.com> References: <5411728D.8050405@redhat.com> <5411AA38.4030309@redhat.com> <5411CF24.2030200@redhat.com> <5411FED9.9070908@redhat.com> <5412EAFF.7030703@redhat.com> Message-ID: <5412F07C.8020604@redhat.com> On 12.9.2014 14:45, Martin Basti wrote: > On 11/09/14 21:58, Petr Spacek wrote: >> On 11.9.2014 18:34, Martin Basti wrote: >>> On 11/09/14 15:57, Martin Basti wrote: >>>> On 11/09/14 11:59, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> I was fighting with random crashes for couple of days ... and discovered >>>>> that run_exclusive_enter()/isc_task_beginexclusive() usage was completely >>>>> incorrect and didn't actually lock anything. >>>>> >>>>> This series of patches reworks internal locking (and related event system) >>>>> to work around limitations of isc_task_beginexclusive() mechanism. >>>>> >>>>> It would be better to get rid of isc_task_beginexclusive() completely but >>>>> IMHO it is not possible because of BIND's dns_view*() functions have to be >>>>> guarded with it. >>>>> >>>>> >>>>> Testing is going to be interesting because we are speaking about race >>>>> conditions. >>>>> >>>>> I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside with >>>>> random A/AAAA/TXT RRs. My LDIF is here: >>>>> http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz >>>>> >>>>> I was able to randomly reproduce various crashes when BIND was running with >>>>> more threads than usually. >>>>> >>>>> You can try to run BIND with this command (as root) and play games with -n >>>>> parameter: >>>>> $ export KRB5_KTNAME="/etc/named.keytab" >>>>> $ named -4 -g -u named -m record -n 10 >>>>> >>>>> Please test also the case where BIND receives SIGINT during start-up. It is >>>>> possible to run BIND with commands above and wait for message: >>>>> 11-Sep-2014 11:54:58.092 running >>>>> >>>>> At this point send SIGINT (CTRL+C) to BIND and see what happens. It could >>>>> crash or deadlock. >>>>> >>>>> It is necessary to send the signal before BIND prints this message: >>>>> 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 >>>>> >>>>> Let me know if you need any assistance. >>>>> >>>> I need your assistance, I haven't been able to reproduce it. >>>> >>>> Martin ... > Functional ACK Pushed to master: 1d23e27e0198cacdbbb14ac13ff039c33546d9af 09386eb446ac8d9c12110d21f2d4da36c1b792bf e7d8f6f175eae795c603eee00d06d5799b2d6c39 17a29e20406ad9db0b28fcb6ec4b02394385fe53 -- Petr^2 Spacek From pspacek at redhat.com Fri Sep 12 13:13:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 15:13:51 +0200 Subject: [Freeipa-devel] [PATCH 0295-0296] Release 5.3 Message-ID: <5412F18F.4080903@redhat.com> Hello, Update NEWS for upcoming 5.3 release. Pushed to master: b1a176d0b71127b428db3a901f736d1ca2ed6a65 Bump NVR to 5.3. Pushed to master: 9886db5772a6635bdc33f718685b7df0ea1a3ea1 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0295-Update-NEWS-for-upcoming-5.3-release.patch Type: text/x-patch Size: 626 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0296-Bump-NVR-to-5.3.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 12 13:19:09 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 15:19:09 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5406F162.4060409@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> Message-ID: <5412F2CD.4060202@redhat.com> On 03/09/14 12:45, Martin Basti wrote: > On 03/09/14 12:27, Martin Kosek wrote: >> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>> On 25.8.2014 14:52, Martin Basti wrote: >>>> 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 >>> Functional ACK, it works for me. It can be pushed if Python gurus >>> are okay with >>> the code. >> Is it safe to commit the change given that bind-dyndb-ldap still >> crash when "." >> is removed? Wouldn't it break our CI tests? >> >> Maybe we should wait until fixed bind-dydnb-ldap is released. >> Hopefully it >> would be soon. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > It will broke tests, don't push it until bind-dyndb-ldap is fixed. > Currently I'm testing bind-dyndb-ldap related patch. > Added patches 120 and 121, which are required by DNS to work correctly. Patches 120 and 121 add all DNS replicas to zone apex as NS, --name-server option doesn't add NS record, only changes the SOA MNAME attribute Original and new patches attached. -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 12029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9987 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 12 14:02:42 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 16:02:42 +0200 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile Message-ID: <5412FD02.6080200@redhat.com> I always forgot to install dogtag 10.2, so here is updated specfile. COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ Patch atached. ipa-4-1 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0122-dogtag-to-spec.file.patch Type: text/x-patch Size: 793 bytes Desc: not available URL: From abokovoy at redhat.com Fri Sep 12 14:07:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Sep 2014 17:07:55 +0300 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile In-Reply-To: <5412FD02.6080200@redhat.com> References: <5412FD02.6080200@redhat.com> Message-ID: <20140912140755.GL2541@redhat.com> On Fri, 12 Sep 2014, Martin Basti wrote: >I always forgot to install dogtag 10.2, so here is updated specfile. > >COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ ACK if you fix the commit message (see below), NACK for the link, as dogtag 10.2 is going to Rawhide and F21. https://admin.fedoraproject.org/updates/FEDORA-2014-10296/dogtag-pki-10.2.0-2.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10309/dogtag-pki-theme-10.2.0-1.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10300/pki-core-10.2.0-1.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10297/pki-console-10.2.0-1.fc21 They should have been pushed in the same update, though. Martin, can you please add a small blurb in the commit message that Dogtag 10.2 is required due to support of a Vault feature? -- / Alexander Bokovoy From npmccallum at redhat.com Fri Sep 12 14:08:32 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Sep 2014 10:08:32 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <5412D654.3030601@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> <5412AE01.8080609@redhat.com> <5412D654.3030601@redhat.com> Message-ID: <1410530912.2941.15.camel@redhat.com> On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: > On 09/12/2014 10:25 AM, Martin Kosek wrote: > > On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: > >> > >> On 09/12/2014 09:37 AM, Martin Kosek wrote: > >>> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: > >>>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > >>>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > >>>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > >>>>>>>> > >>>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: > >>>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: > >>>>>>> ... > >>>>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > >>>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > >>>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any > >>>>>>>>>> known issues > >>>>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA > >>>>>>>>>> 4.0.x to be > >>>>>>>>>> based on it? > >>>>>>>>>> > >>>>>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only > >>>>>>>>>> after all.. > >>>>>>>>> > >>>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > >>>>>>>>> couldn't include the patch even there. > >>>>>>>>> There better be no such issues. > >>>>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will > >>>>>>>> be the first bug free software. At the moment Thierry is investigating a > >>>>>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - > >>>>>>>> > >>>>>>> > >>>>>>> any known issues in the F21 389-ds-base build that would prevent > >>>>>>> upstream FreeIPA 4.0.x to be based on it > >>>>>> > >>>>>> Yes. 389 will not start if weak ciphers are specified. Currently, > >>>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > >>>>>> work at all because the DS will never start. > >>>>>> > >>>>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 > >>>> > >>>> Done: thanks everyone on the DS side! > >>>> > >>>>>> Then, we need an F21 build of 389-ds-base. > >>>> > >>>> Done: thanks nhosoi! > >>>> > >>>>>> Then we need to merge Ludwig's IPA patch from this thread with a > >>>>>> versioned dependency on the new 389-ds-base build. > >>>> > >>>> New patch attached which includes a versioned dep on the new DS. > >>> > >>> ipa-server-install still fails for me, even when I use > >>> 389-ds-base-1.3.3.2-1.fc20.x86_64: > >>> > >>> # ipa-server-install > >>> ... > >>> [12/13]: restarting httpd > >>> [13/13]: configuring httpd to start on boot > >>> Done configuring the web interface (httpd). > >>> Applying LDAP updates > >>> Unexpected error - see /var/log/ipaserver-install.log for details: > >>> ObjectclassViolation: attribute "allowweakciphers" not allowed > >>> > >>> > >>> I think you simply use a wrong config name - have extra "s" in the end. It is > >>> defined as > >> that typo was already in my first draft of the patch, sorry > >>> > >>> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] > >>> > >>> > >>> Also, do we really need to put it to "off" in the updates? AFAIU, it is off > >>> by default in our config and with current setting, users could not put it to > >>> "on" (for whatever reason) without the value being overwritten with every run > >>> of FreeIPA upgrade. > >> could there be an upgrade from a install not yet using that params. should > >> "only:allowWeakCipher" be replaced by "addifnew" ? > > > > You can try "default:allowWeakCiphers: off" - it would set the attribute to off > > if it was not there before. > > > > Given you are probably working on updated version, I would also recommend > > following > > > > http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 > > > > as I saw couple nitpicks with your patch > > - ticket number in patch description and not in it's body > > - bad "From" field - I would rather expect it to be "Ludwig Krispenz > > " than "lkrispen " > > > > Thanks, > > Martin > > Hello, any update on this front? Are you or Nathaniel updating the patch? Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-389-SSL-cipher-config.patch Type: text/x-patch Size: 4040 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 12 14:14:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 16:14:48 +0200 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile In-Reply-To: <5412FD02.6080200@redhat.com> References: <5412FD02.6080200@redhat.com> Message-ID: <5412FFD8.4050407@redhat.com> On 12/09/14 16:02, Martin Basti wrote: > I always forgot to install dogtag 10.2, so here is updated specfile. > > COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ > > Patch atached. ipa-4-1 > > I'm not sure if dogtag 10.2 is required in 4.1 -- Martin Basti From lkrispen at redhat.com Fri Sep 12 14:16:24 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Sep 2014 16:16:24 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <1410530912.2941.15.camel@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> <5412AE01.8080609@redhat.com> <5412D654.3030601@redhat.com> <1410530912.2941.15.camel@redhat.com> Message-ID: <54130038.3070703@redhat.com> Hi, I alread had sent a patch for review, It is exactly like yours with one exception: 65c61 < +default:allowWeakCipher: off --- > +addifnew:allowWeakCipher: off I tested with default, but it was ignored - is default only used for new entries ? On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: > On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: >> On 09/12/2014 10:25 AM, Martin Kosek wrote: >>> On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: >>>> On 09/12/2014 09:37 AM, Martin Kosek wrote: >>>>> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >>>>>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>>>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>>>>>>> ... >>>>>>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: >>>>>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any >>>>>>>>>>>> known issues >>>>>>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA >>>>>>>>>>>> 4.0.x to be >>>>>>>>>>>> based on it? >>>>>>>>>>>> >>>>>>>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only >>>>>>>>>>>> after all.. >>>>>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we >>>>>>>>>>> couldn't include the patch even there. >>>>>>>>>>> There better be no such issues. >>>>>>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will >>>>>>>>>> be the first bug free software. At the moment Thierry is investigating a >>>>>>>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - >>>>>>>>>> >>>>>>>>> any known issues in the F21 389-ds-base build that would prevent >>>>>>>>> upstream FreeIPA 4.0.x to be based on it >>>>>>>> Yes. 389 will not start if weak ciphers are specified. Currently, >>>>>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't >>>>>>>> work at all because the DS will never start. >>>>>>>> >>>>>>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 >>>>>> Done: thanks everyone on the DS side! >>>>>> >>>>>>>> Then, we need an F21 build of 389-ds-base. >>>>>> Done: thanks nhosoi! >>>>>> >>>>>>>> Then we need to merge Ludwig's IPA patch from this thread with a >>>>>>>> versioned dependency on the new 389-ds-base build. >>>>>> New patch attached which includes a versioned dep on the new DS. >>>>> ipa-server-install still fails for me, even when I use >>>>> 389-ds-base-1.3.3.2-1.fc20.x86_64: >>>>> >>>>> # ipa-server-install >>>>> ... >>>>> [12/13]: restarting httpd >>>>> [13/13]: configuring httpd to start on boot >>>>> Done configuring the web interface (httpd). >>>>> Applying LDAP updates >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> ObjectclassViolation: attribute "allowweakciphers" not allowed >>>>> >>>>> >>>>> I think you simply use a wrong config name - have extra "s" in the end. It is >>>>> defined as >>>> that typo was already in my first draft of the patch, sorry >>>>> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] >>>>> >>>>> >>>>> Also, do we really need to put it to "off" in the updates? AFAIU, it is off >>>>> by default in our config and with current setting, users could not put it to >>>>> "on" (for whatever reason) without the value being overwritten with every run >>>>> of FreeIPA upgrade. >>>> could there be an upgrade from a install not yet using that params. should >>>> "only:allowWeakCipher" be replaced by "addifnew" ? >>> You can try "default:allowWeakCiphers: off" - it would set the attribute to off >>> if it was not there before. >>> >>> Given you are probably working on updated version, I would also recommend >>> following >>> >>> http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 >>> >>> as I saw couple nitpicks with your patch >>> - ticket number in patch description and not in it's body >>> - bad "From" field - I would rather expect it to be "Ludwig Krispenz >>> " than "lkrispen " >>> >>> Thanks, >>> Martin >> Hello, any update on this front? Are you or Nathaniel updating the patch? > Attached. From npmccallum at redhat.com Fri Sep 12 14:16:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Sep 2014 10:16:53 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <54130038.3070703@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> <5412AE01.8080609@redhat.com> <5412D654.3030601@redhat.com> <1410530912.2941.15.camel@redhat.com> <54130038.3070703@redhat.com> Message-ID: <1410531413.2941.16.camel@redhat.com> Sorry, I missed that. Let's take your patch. On Fri, 2014-09-12 at 16:16 +0200, Ludwig Krispenz wrote: > Hi, > > I alread had sent a patch for review, It is exactly like yours with one > exception: > 65c61 > < +default:allowWeakCipher: off > --- > > +addifnew:allowWeakCipher: off > > I tested with default, but it was ignored - is default only used for new > entries ? > > On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: > > On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: > >> On 09/12/2014 10:25 AM, Martin Kosek wrote: > >>> On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: > >>>> On 09/12/2014 09:37 AM, Martin Kosek wrote: > >>>>> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: > >>>>>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: > >>>>>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: > >>>>>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: > >>>>>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: > >>>>>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: > >>>>>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: > >>>>>>>>> ... > >>>>>>>>>>>> Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: > >>>>>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > >>>>>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are there any > >>>>>>>>>>>> known issues > >>>>>>>>>>>> in the F21 389-ds-base build that would prevent upstream FreeIPA > >>>>>>>>>>>> 4.0.x to be > >>>>>>>>>>>> based on it? > >>>>>>>>>>>> > >>>>>>>>>>>> If yes, we may need to include the patch in Fedora 21 downstream only > >>>>>>>>>>>> after all.. > >>>>>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we > >>>>>>>>>>> couldn't include the patch even there. > >>>>>>>>>>> There better be no such issues. > >>>>>>>>>> what do you mean by "no such issues" ? I don't think that 389/F21 will > >>>>>>>>>> be the first bug free software. At the moment Thierry is investigating a > >>>>>>>>>> crash in dna-plugin and Noriko a memory leak, which could be in F21 - > >>>>>>>>>> > >>>>>>>>> any known issues in the F21 389-ds-base build that would prevent > >>>>>>>>> upstream FreeIPA 4.0.x to be based on it > >>>>>>>> Yes. 389 will not start if weak ciphers are specified. Currently, > >>>>>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't > >>>>>>>> work at all because the DS will never start. > >>>>>>>> > >>>>>>>> We need this patch merged: https://fedorahosted.org/389/ticket/47838 > >>>>>> Done: thanks everyone on the DS side! > >>>>>> > >>>>>>>> Then, we need an F21 build of 389-ds-base. > >>>>>> Done: thanks nhosoi! > >>>>>> > >>>>>>>> Then we need to merge Ludwig's IPA patch from this thread with a > >>>>>>>> versioned dependency on the new 389-ds-base build. > >>>>>> New patch attached which includes a versioned dep on the new DS. > >>>>> ipa-server-install still fails for me, even when I use > >>>>> 389-ds-base-1.3.3.2-1.fc20.x86_64: > >>>>> > >>>>> # ipa-server-install > >>>>> ... > >>>>> [12/13]: restarting httpd > >>>>> [13/13]: configuring httpd to start on boot > >>>>> Done configuring the web interface (httpd). > >>>>> Applying LDAP updates > >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: > >>>>> ObjectclassViolation: attribute "allowweakciphers" not allowed > >>>>> > >>>>> > >>>>> I think you simply use a wrong config name - have extra "s" in the end. It is > >>>>> defined as > >>>> that typo was already in my first draft of the patch, sorry > >>>>> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on | off] > >>>>> > >>>>> > >>>>> Also, do we really need to put it to "off" in the updates? AFAIU, it is off > >>>>> by default in our config and with current setting, users could not put it to > >>>>> "on" (for whatever reason) without the value being overwritten with every run > >>>>> of FreeIPA upgrade. > >>>> could there be an upgrade from a install not yet using that params. should > >>>> "only:allowWeakCipher" be replaced by "addifnew" ? > >>> You can try "default:allowWeakCiphers: off" - it would set the attribute to off > >>> if it was not there before. > >>> > >>> Given you are probably working on updated version, I would also recommend > >>> following > >>> > >>> http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 > >>> > >>> as I saw couple nitpicks with your patch > >>> - ticket number in patch description and not in it's body > >>> - bad "From" field - I would rather expect it to be "Ludwig Krispenz > >>> " than "lkrispen " > >>> > >>> Thanks, > >>> Martin > >> Hello, any update on this front? Are you or Nathaniel updating the patch? > > Attached. > From npmccallum at redhat.com Fri Sep 12 14:18:13 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Sep 2014 10:18:13 -0400 Subject: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base In-Reply-To: <5412D750.5030608@redhat.com> References: <5412D750.5030608@redhat.com> Message-ID: <1410531493.2941.17.camel@redhat.com> On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: > please review attached patch for ticket: > https://fedorahosted.org/freeipa/ticket/4395 > > use new options in 389-ds to configure enabled ciphers ACK. Let's get 4.0.3 out the door! :) From mkosek at redhat.com Fri Sep 12 14:25:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 16:25:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions In-Reply-To: <5412DEA4.9020300@redhat.com> References: <5412DEA4.9020300@redhat.com> Message-ID: <54130244.1060708@redhat.com> On 09/12/2014 01:53 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4534 > > The entryusn and timestamp operational attributes are now automatically added > to every read permission that targets objectclass, whether managed or > user-created. > > The 'System: Read Timestamp and USN Operational Attributes', which was added > for 4.0.2, is removed on upgrade. > > This looks good to me. deref search now return expected results: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # admin, users, accounts, mkosek-fedora20.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false ... # memberof: ;;;;;;;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc =test # memberof: ;;;;;;cn=t rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: top objectClass: person ... I.e. only the memberof objects that the host has access to are dereferenced. Updated permissions also look OK. Thus ACK from me of there are no other objections. What should we do about remaining Operational permission? -------------------- 1 permission matched -------------------- Permission name: System: Read Creator and Modifier Operational Attributes Granted rights: read, compare, search Effective attributes: creatorsname, modifiersname Default attributes: modifiersname, creatorsname Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test Extra target filter: (objectclass=*) ---------------------------- Number of entries returned 1 ---------------------------- ? Any host can still use deref to for example find creatorsname or modifiersname of memberof entries. I would personally rather delete the permission and keep the attributes only for DM (and admin) or make it permission-based as SSSD does not use it anyway, AFAIK. Martin From pspacek at redhat.com Fri Sep 12 14:25:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 16:25:11 +0200 Subject: [Freeipa-devel] [Freeipa-interest] Announcing bind-dyndb-ldap version 5.3 Message-ID: <54130247.50902@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 5.3. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.3-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 5.3 ==== [1] Internal locking was reworked to prevent crashes and deadlocks. 5.2 ==== [1] Kerberos ticket expiration is now handled correctly. https://fedorahosted.org/bind-dyndb-ldap/ticket/131 [2] BIND no longer crashes after removing root zone from LDAP. https://fedorahosted.org/bind-dyndb-ldap/ticket/138 [3] Root zone handling was fixed to prevent accidental child zone removal. https://fedorahosted.org/bind-dyndb-ldap/ticket/122 [4] Temporary files for idnsZone objects are now inside master/ subdirectory. [5] Temporary directories are created with ug=rwx,o= permissions to enable POSIX ACL usage. [6] Naming rules for working directories have changed: See README section 6. [7] Documentation clearly states that idnsZoneActive attribute is not supported. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. !!! CAUTION !!! idnsZone object class changed it's semantics in version 5.0. Please read https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README and update idnsForwarders and idnsForward policy attributes in your DNS zones accordingly. Transition from idnsZone to idnsForwardZone object class can be made seamless if you change data in LDAP before you upgrade to version 5.x. All bind-dyndb-ldap versions >= 3.0 support the idnsForwardZone object class. Users of FreeIPA < 4.0 should be careful when upgrading bind-dyndb-ldap to version >= 5.0 (if they do not upgrade to FreeIPA 4.x at the same time). Configuration semantics related to conditional (per-zone) forwarding has changed and FreeIPA < 4.0 doesn't have appropriate user interface and API. It is safe to upgrade if you use *only* global forwarders (shown by 'ipa dnsconfig-show') and *do not* use per-zone forwarders (shown by 'ipa dnszone-show'). Don't hesitate to ask freeipa-users mailing list if you need help with upgrade. !!! CAUTION !!! Downgrading back to any 4.x version is supported. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From ssorce at redhat.com Fri Sep 12 14:31:08 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Sep 2014 10:31:08 -0400 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5412A3E1.3070203@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412A25C.5040409@redhat.com> <5412A3E1.3070203@redhat.com> Message-ID: <1410532268.1199.33.camel@willson.usersys.redhat.com> On Fri, 2014-09-12 at 09:42 +0200, Martin Kosek wrote: > > Well, I am not convinced that everyone reads the release notes, so I > would rather delete this permission in 4.0.3. Hopefully, there won't > be many 4.0.2 users. It seems as a lesser evil to me than having SSSD > clients broken. +1 such fundamental issues *must* be handle automatically if we can. Simo. From ssorce at redhat.com Fri Sep 12 14:36:02 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Sep 2014 10:36:02 -0400 Subject: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't In-Reply-To: <5412AE67.4040500@redhat.com> References: <5411B9BB.6000001@redhat.com> <1410449861.1199.6.camel@willson.usersys.redhat.com> <5411E9B3.6010200@redhat.com> <1410461381.1199.15.camel@willson.usersys.redhat.com> <541204E8.3010006@redhat.com> <5412AE67.4040500@redhat.com> Message-ID: <1410532562.1199.36.camel@willson.usersys.redhat.com> On Fri, 2014-09-12 at 10:27 +0200, thierry bordaz wrote: > On 09/11/2014 10:24 PM, Martin Kosek wrote: > > On 09/11/2014 08:49 PM, Simo Sorce wrote: > >> On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: > >>> On 09/11/2014 05:37 PM, Simo Sorce wrote: > >>>> On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: > >>>>> Hello, > >>>>> > >>>>> We have another important issue to resolve. Current FreeIPA 4.0.2 > >>>>> ACI settings > >>>>> cause older SSSD clients to fail as they get returned an LDAP > >>>>> deref call > >>>>> results without objectclass attribute and just with entryusn > >>>>> attribute. Details > >>>>> in https://fedorahosted.org/freeipa/ticket/4534. While I agree > >>>>> SSSD should be > >>>>> more tolerant in this case, it still breaks old clients which we > >>>>> should prevent. > >>>>> > >>>>> There are 2 ways how to fix I currently see: > >>>>> > >>>>> 1) Return objectclass for any entry, just like we do with > >>>>> operational attributes > >>>>> > >>>>> This would include adding "objectclass" to "System: Read Timestamp > >>>>> and USN > >>>>> Operational Attributes". However, I am rather cautious about this > >>>>> approach as > >>>>> even though objectclass does not usually carry a secret > >>>>> information, we could > >>>>> still leak some information about our DIT to unprivileged user. > >>>> > >>>> Our DIT is public and known, I see no problem. > >>> > >>> I rather meant the LDAP tree and it's contents (custom groups, sudo > >>> rules, > >>> roles, ...). > >>> > >>> I did one more test and found out we cannot do this as it would > >>> undermine the > >>> ACIs we have right now. As soon as objectclass is allowed globally, > >>> ldapsearch > >>> returns every object even if no other attribute is returned: > >>> > >>> # ldapsearch -h `hostname` -Y GSSAPI -b > >>> cn=pbac,dc=mkosek-fedora20,dc=test > >>> SASL/GSSAPI authentication started > >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > >>> SASL SSF: 56 > >>> SASL data security layer installed. > >>> ... > >>> # User Administrators, privileges, pbac, mkosek-fedora20.test > >>> dn: cn=User > >>> Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test > >>> objectClass: top > >>> objectClass: groupofnames > >>> objectClass: nestedgroup > >>> ... > >>> > >>> It would not show any more info before that, but even the list of > >>> permissions, > >>> privileges and roles along with it's names is a leaked information. > >>> > >>> > >>>>> 2) Show objectclass+operational attributes in our Read ACIs > >>>>> Other way I see is to update *all* our Read permissions allowing > >>>>> reading > >>>>> objectclass attribute and also allow the chosen LDAP operational > >>>>> attribute. > >>>>> This would let the LDAP caller to always get either all these > >>>>> discussed > >>>>> attributes but none at all. > >>>>> > >>>>> > >>>>> Do we want to do this? Any other (better) idea how to approach it? > >>>> > >>>> I honestly am not sure I understand the distinction between 1 and > >>>> 2, can > >>>> you provide the actual ACIs or a behavior example ? > >>>> > >>>> Simo. > >>> > >>> Currently, our ACI allows reading entryusn in any LDAP entry. So > >>> user (SSSD) > >>> running LDAP deref call gets entryusn from object it does not have a > >>> read > >>> access to: > >>> > >>> # ldapsearch -h `hostname` -Y GSSAPI -b > >>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E > >>> 'deref=memberof:objectclass,entryusn' > >>> SASL/GSSAPI authentication started > >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > >>> SASL SSF: 56 > >>> SASL data security layer installed. > >>> ... > >>> # memberof: ;cn=replication > >>> administrators,cn=privileges,cn=pba > >>> c,dc=mkosek-fedora20,dc=test > >>> > >>> # memberof: ;cn=add replication > >>> agreements,cn=permissions,cn=pba > >>> c,dc=mkosek-fedora20,dc=test > >>> ... > >>> > >>> This confuses SSSD (sees entryusn but does not see objectclass > >>> attribute) + may > >>> give out some information we do not want to give out. Fortunately, bare > >>> ldapsearch does not show anything: > >>> > >>> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication > >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" > >>> entryusn > >>> SASL/GSSAPI authentication started > >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > >>> SASL SSF: 56 > >>> SASL data security layer installed. > >>> # extended LDIF > >>> # > >>> # LDAPv3 > >>> # base >>> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> > >>> with scope subtree > >>> # filter: (objectclass=*) > >>> # requesting: entryusn > >>> # > >>> > >>> # search result > >>> search: 4 > >>> result: 0 Success > >>> > >>> # numResponses: 1 > >>> > >>> > >>> The idea behind Option 1 was to add ACI to allow reading objectclass > >>> attribute > >>> globally, for our entire tree. (as noted above, not an option). > >>> > >>> The idea behind Option 2 was to: > >>> - remove global ACI allowing reading entryusn (System: Read > >>> Timestamp and USN > >>> Operational Attributes) > >>> - update all our Read permissions to allow entryusn > >>> > >>> Then for example, if user (SSSD) is allowed to read RBAC role > >>> objects, he would > >>> not be able to read either objectclass or entryusn attributes. This > >>> means users > >>> would be only allowed to read entryusn for objects that they can > >>> really read > >>> (i.e. for objects where they can read at least objectclass). > >>> > >>> Did that clarify the options? > >>> > >>> Of course, there is still option 3) to close as wontfix and let > >>> older SSSDs be > >>> incompatible with FreeIPA 4.0+. > >> > >> No, 3 is definitely not on the table, I would rather do 1, but I guess 2 > >> is the only good way for now ? > >> > >> Simo. > > > > Yeah - 1) would be easy to implement, but it would be a step back in > > our ACI model (global allowing ACI again...). > > > > Something based on 2) is the only approach that I have in mind right > > now and that would work. It also looks as the right thing to do as > > then with changing visibility of objects by our permission system, > > visibility of entryusn would change too. > > > > Programatically it should not be difficult to do, we could add these > > attributes by default to all read permissions which have allow > > objectclass attribute so we would not have to update all our read > > permissions by hand... > > Hello, > > I was thinking to an other option that is looking more as a hack. It > is to relax the aci checking (for a given list of attributes) in > deref plugin. > For example, if a user has access to at least one of the requested > attribute (e.g. entryusn), in the deref req, then the derefenced > entry could be returned with additional attributes (given in the > deref plugin config.: 'objectclass', 'cn'). > > I honestly do not like this option but in case changing aci > definitions is too risky/complex it is an option. NACK, it would make figuring out what a user has access to a nightmare, you'd be calling CVEs :-) Simo. From mkosek at redhat.com Fri Sep 12 14:38:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 16:38:32 +0200 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile In-Reply-To: <5412FFD8.4050407@redhat.com> References: <5412FD02.6080200@redhat.com> <5412FFD8.4050407@redhat.com> Message-ID: <54130568.8000703@redhat.com> On 09/12/2014 04:14 PM, Martin Basti wrote: > On 12/09/14 16:02, Martin Basti wrote: >> I always forgot to install dogtag 10.2, so here is updated specfile. >> >> COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ >> >> Patch atached. ipa-4-1 >> >> > > I'm not sure if dogtag 10.2 is required in 4.1 > It is not. It is only required for the DRM feature, i.e. FreeIPA 4.2, i.e. master branch. Martin From ssorce at redhat.com Fri Sep 12 14:43:49 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Sep 2014 10:43:49 -0400 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions In-Reply-To: <5412DEA4.9020300@redhat.com> References: <5412DEA4.9020300@redhat.com> Message-ID: <1410533029.1199.38.camel@willson.usersys.redhat.com> On Fri, 2014-09-12 at 13:53 +0200, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4534 > > The entryusn and timestamp operational attributes are now automatically > added to every read permission that targets objectclass, whether managed > or user-created. > > The 'System: Read Timestamp and USN Operational Attributes', which was > added for 4.0.2, is removed on upgrade. Not tested but LGTM. Simo. From rcritten at redhat.com Fri Sep 12 14:45:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Sep 2014 10:45:39 -0400 Subject: [Freeipa-devel] FreeIPA 4.0.3? In-Reply-To: <54130038.3070703@redhat.com> References: <5411898D.8000203@redhat.com> <5411A79D.70208@redhat.com> <1410443245.2941.0.camel@redhat.com> <5411ABFA.7010504@redhat.com> <5411AD32.9040206@redhat.com> <1410445059.2941.3.camel@redhat.com> <5411AFFC.60801@redhat.com> <1410445342.2941.4.camel@redhat.com> <5411B113.4060103@redhat.com> <5411B235.2070000@redhat.com> <5411B3D9.7030702@redhat.com> <5411B415.4050401@redhat.com> <1410446612.2941.9.camel@redhat.com> <5411B638.3080905@redhat.com> <1410484865.2941.14.camel@redhat.com> <5412A2B0.7050200@redhat.com> <5412AB15.9000503@redhat.com> <5412AE01.8080609@redhat.com> <5412D654.3030601@redhat.com> <1410530912.2941.15.camel@redhat.com> <54130038.3070703@redhat.com> Message-ID: <54130713.1070409@redhat.com> Ludwig Krispenz wrote: > Hi, > > I alread had sent a patch for review, It is exactly like yours with one > exception: > 65c61 > < +default:allowWeakCipher: off > --- >> +addifnew:allowWeakCipher: off > > I tested with default, but it was ignored - is default only used for new > entries ? Correct. A value for default is only added when creating an entirely new entry. addifnew adds the value to the entry only if it doesn't already exist. rob > > On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: >> On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: >>> On 09/12/2014 10:25 AM, Martin Kosek wrote: >>>> On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: >>>>> On 09/12/2014 09:37 AM, Martin Kosek wrote: >>>>>> On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: >>>>>>>> On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: >>>>>>>>> On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: >>>>>>>>>> On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: >>>>>>>>>>> On 09/11/2014 04:31 PM, Petr Viktorin wrote: >>>>>>>>>>>> On 09/11/2014 04:26 PM, Martin Kosek wrote: >>>>>>>>>> ... >>>>>>>>>>>>> Also, we will need to add the F21 389-ds-base build to >>>>>>>>>>>>> FreeIPA Copr: >>>>>>>>>>>>> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >>>>>>>>>>>>> so that F20 users can upgrade to the newest FreeIPA. Are >>>>>>>>>>>>> there any >>>>>>>>>>>>> known issues >>>>>>>>>>>>> in the F21 389-ds-base build that would prevent upstream >>>>>>>>>>>>> FreeIPA >>>>>>>>>>>>> 4.0.x to be >>>>>>>>>>>>> based on it? >>>>>>>>>>>>> >>>>>>>>>>>>> If yes, we may need to include the patch in Fedora 21 >>>>>>>>>>>>> downstream only >>>>>>>>>>>>> after all.. >>>>>>>>>>>> We're basing the Fedora 21 Alpha downstream on FreeIPA >>>>>>>>>>>> 4.0.3, so we >>>>>>>>>>>> couldn't include the patch even there. >>>>>>>>>>>> There better be no such issues. >>>>>>>>>>> what do you mean by "no such issues" ? I don't think that >>>>>>>>>>> 389/F21 will >>>>>>>>>>> be the first bug free software. At the moment Thierry is >>>>>>>>>>> investigating a >>>>>>>>>>> crash in dna-plugin and Noriko a memory leak, which could be >>>>>>>>>>> in F21 - >>>>>>>>>>> >>>>>>>>>> any known issues in the F21 389-ds-base build that would prevent >>>>>>>>>> upstream FreeIPA 4.0.x to be based on it >>>>>>>>> Yes. 389 will not start if weak ciphers are specified. Currently, >>>>>>>>> FreeIPA specifies weak ciphers. This means that FreeIPA in F21 >>>>>>>>> doesn't >>>>>>>>> work at all because the DS will never start. >>>>>>>>> >>>>>>>>> We need this patch merged: >>>>>>>>> https://fedorahosted.org/389/ticket/47838 >>>>>>> Done: thanks everyone on the DS side! >>>>>>> >>>>>>>>> Then, we need an F21 build of 389-ds-base. >>>>>>> Done: thanks nhosoi! >>>>>>> >>>>>>>>> Then we need to merge Ludwig's IPA patch from this thread with a >>>>>>>>> versioned dependency on the new 389-ds-base build. >>>>>>> New patch attached which includes a versioned dep on the new DS. >>>>>> ipa-server-install still fails for me, even when I use >>>>>> 389-ds-base-1.3.3.2-1.fc20.x86_64: >>>>>> >>>>>> # ipa-server-install >>>>>> ... >>>>>> [12/13]: restarting httpd >>>>>> [13/13]: configuring httpd to start on boot >>>>>> Done configuring the web interface (httpd). >>>>>> Applying LDAP updates >>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>> ObjectclassViolation: attribute "allowweakciphers" not allowed >>>>>> >>>>>> >>>>>> I think you simply use a wrong config name - have extra "s" in the >>>>>> end. It is >>>>>> defined as >>>>> that typo was already in my first draft of the patch, sorry >>>>>> allowWeakCipher in "cn=encryption,cn=config". allowWeakCipher: [on >>>>>> | off] >>>>>> >>>>>> >>>>>> Also, do we really need to put it to "off" in the updates? AFAIU, >>>>>> it is off >>>>>> by default in our config and with current setting, users could not >>>>>> put it to >>>>>> "on" (for whatever reason) without the value being overwritten >>>>>> with every run >>>>>> of FreeIPA upgrade. >>>>> could there be an upgrade from a install not yet using that params. >>>>> should >>>>> "only:allowWeakCipher" be replaced by "addifnew" ? >>>> You can try "default:allowWeakCiphers: off" - it would set the >>>> attribute to off >>>> if it was not there before. >>>> >>>> Given you are probably working on updated version, I would also >>>> recommend >>>> following >>>> >>>> http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 >>>> >>>> as I saw couple nitpicks with your patch >>>> - ticket number in patch description and not in it's body >>>> - bad "From" field - I would rather expect it to be "Ludwig Krispenz >>>> " than "lkrispen " >>>> >>>> Thanks, >>>> Martin >>> Hello, any update on this front? Are you or Nathaniel updating the >>> patch? >> Attached. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mbasti at redhat.com Fri Sep 12 14:46:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 16:46:16 +0200 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile In-Reply-To: <54130568.8000703@redhat.com> References: <5412FD02.6080200@redhat.com> <5412FFD8.4050407@redhat.com> <54130568.8000703@redhat.com> Message-ID: <54130738.5060706@redhat.com> On 12/09/14 16:38, Martin Kosek wrote: > On 09/12/2014 04:14 PM, Martin Basti wrote: >> On 12/09/14 16:02, Martin Basti wrote: >>> I always forgot to install dogtag 10.2, so here is updated specfile. >>> >>> COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ >>> >>> Patch atached. ipa-4-1 >>> >>> >> >> I'm not sure if dogtag 10.2 is required in 4.1 >> > > It is not. It is only required for the DRM feature, i.e. FreeIPA 4.2, > i.e. master branch. > > Martin Thank you. Updated patch attached. push only to master branch then -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0122.2-Dogtag-10.2-to-spec.file.patch Type: text/x-patch Size: 853 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 12 14:46:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 16:46:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions In-Reply-To: <54130244.1060708@redhat.com> References: <5412DEA4.9020300@redhat.com> <54130244.1060708@redhat.com> Message-ID: <54130753.3010103@redhat.com> On 09/12/2014 04:25 PM, Martin Kosek wrote: > On 09/12/2014 01:53 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4534 >> >> The entryusn and timestamp operational attributes are now >> automatically added >> to every read permission that targets objectclass, whether managed or >> user-created. >> >> The 'System: Read Timestamp and USN Operational Attributes', which was >> added >> for 4.0.2, is removed on upgrade. >> >> > > This looks good to me. deref search now return expected results: > > # ldapsearch -h `hostname` -Y GSSAPI -b > uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E > 'deref=memberof:objectclass,entryusn' > SASL/GSSAPI authentication started > SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with > scope subtree > # filter: (objectclass=*) > # requesting: ALL > # with dereference control > # > > # admin, users, accounts, mkosek-fedora20.test > dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test > control: 1.3.6.1.4.1.4203.666.5.16 false ... > # memberof: > ;; oup>;;; roup>;;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc > =test > > # memberof: > ;; es>;;;;cn=t > rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test > > objectClass: top > objectClass: person > ... > > > I.e. only the memberof objects that the host has access to are > dereferenced. Updated permissions also look OK. > > Thus ACK from me of there are no other objections. > > What should we do about remaining Operational permission? > > -------------------- > 1 permission matched > -------------------- > Permission name: System: Read Creator and Modifier Operational > Attributes > Granted rights: read, compare, search > Effective attributes: creatorsname, modifiersname > Default attributes: modifiersname, creatorsname > Bind rule type: all > Subtree: dc=mkosek-fedora20,dc=test > Extra target filter: (objectclass=*) > ---------------------------- > Number of entries returned 1 > ---------------------------- > ? Any host can still use deref to for example find creatorsname or > modifiersname of memberof entries. > > I would personally rather delete the permission and keep the attributes > only for DM (and admin) or make it permission-based as SSSD does not use > it anyway, AFAIK. > > Martin This version removes 'System: Read Creator and Modifier Operational Attributes' as well. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0642.2-permission-plugin-Auto-add-operational-atttributes-t.patch Type: text/x-patch Size: 61379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0643.2-Allow-deleting-obsolete-permissions-remove-operation.patch Type: text/x-patch Size: 7760 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 12 14:47:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 16:47:51 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base In-Reply-To: <1410531493.2941.17.camel@redhat.com> References: <5412D750.5030608@redhat.com> <1410531493.2941.17.camel@redhat.com> Message-ID: <54130797.4070003@redhat.com> On 09/12/2014 04:18 PM, Nathaniel McCallum wrote: > On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: >> please review attached patch for ticket: >> https://fedorahosted.org/freeipa/ticket/4395 >> >> use new options in 389-ds to configure enabled ciphers > > ACK. Let's get 4.0.3 out the door! :) Thanks! Works for me as well. Pushed to: master: ab196220fdd886fc2b1998eeee0f8e9a4b384845 ipa-4-1: 90e87310c6c8cb0bf88917afd0793a2a2ec1d5b6 ipa-4-0: 93b9d029ce147eb6b4c4ad36ce3c75e5fad37214 As we now depend on F21 version of 389-ds-base, I fired a build of the latest DS to the mkosek/freeipa Copr to not break the dependencies. I hope 389-ds-base will fix the install crash + the RI problems ASAP. I would not start a 4.0.3 release right now though, I would like to have fixes for ticket 4534 included too (patches on review, partially acked by me). Martin From mkosek at redhat.com Fri Sep 12 15:02:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 17:02:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions In-Reply-To: <54130753.3010103@redhat.com> References: <5412DEA4.9020300@redhat.com> <54130244.1060708@redhat.com> <54130753.3010103@redhat.com> Message-ID: <54130B0D.6090702@redhat.com> On 09/12/2014 04:46 PM, Petr Viktorin wrote: > On 09/12/2014 04:25 PM, Martin Kosek wrote: >> On 09/12/2014 01:53 PM, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/4534 >>> >>> The entryusn and timestamp operational attributes are now >>> automatically added >>> to every read permission that targets objectclass, whether managed or >>> user-created. >>> >>> The 'System: Read Timestamp and USN Operational Attributes', which was >>> added >>> for 4.0.2, is removed on upgrade. >>> >>> >> >> This looks good to me. deref search now return expected results: >> >> # ldapsearch -h `hostname` -Y GSSAPI -b >> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >> 'deref=memberof:objectclass,entryusn' >> SASL/GSSAPI authentication started >> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with >> scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # with dereference control >> # >> >> # admin, users, accounts, mkosek-fedora20.test >> dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test >> control: 1.3.6.1.4.1.4203.666.5.16 false ... >> # memberof: >> ;;> oup>;;;> roup>;;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc >> =test >> >> # memberof: >> ;;> es>;;;;cn=t >> rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test >> >> objectClass: top >> objectClass: person >> ... >> >> >> I.e. only the memberof objects that the host has access to are >> dereferenced. Updated permissions also look OK. >> >> Thus ACK from me of there are no other objections. >> >> What should we do about remaining Operational permission? >> >> -------------------- >> 1 permission matched >> -------------------- >> Permission name: System: Read Creator and Modifier Operational >> Attributes >> Granted rights: read, compare, search >> Effective attributes: creatorsname, modifiersname >> Default attributes: modifiersname, creatorsname >> Bind rule type: all >> Subtree: dc=mkosek-fedora20,dc=test >> Extra target filter: (objectclass=*) >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> ? Any host can still use deref to for example find creatorsname or >> modifiersname of memberof entries. >> >> I would personally rather delete the permission and keep the attributes >> only for DM (and admin) or make it permission-based as SSSD does not use >> it anyway, AFAIK. >> >> Martin > > This version removes 'System: Read Creator and Modifier Operational Attributes' > as well. > Works fine. ACK. (You will need to regenerate ACI.txt for each merged branch as there are conflicts). Thanks! Martin From mkosek at redhat.com Fri Sep 12 15:13:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 17:13:32 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base In-Reply-To: <54130797.4070003@redhat.com> References: <5412D750.5030608@redhat.com> <1410531493.2941.17.camel@redhat.com> <54130797.4070003@redhat.com> Message-ID: <54130D9C.5040306@redhat.com> On 09/12/2014 04:47 PM, Martin Kosek wrote: > On 09/12/2014 04:18 PM, Nathaniel McCallum wrote: >> On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: >>> please review attached patch for ticket: >>> https://fedorahosted.org/freeipa/ticket/4395 >>> >>> use new options in 389-ds to configure enabled ciphers >> >> ACK. Let's get 4.0.3 out the door! :) > > Thanks! Works for me as well. > > Pushed to: > master: ab196220fdd886fc2b1998eeee0f8e9a4b384845 > ipa-4-1: 90e87310c6c8cb0bf88917afd0793a2a2ec1d5b6 > ipa-4-0: 93b9d029ce147eb6b4c4ad36ce3c75e5fad37214 > > As we now depend on F21 version of 389-ds-base, I fired a build of the latest > DS to the mkosek/freeipa Copr to not break the dependencies. I hope 389-ds-base > will fix the install crash + the RI problems ASAP. > > I would not start a 4.0.3 release right now though, I would like to have fixes > for ticket 4534 included too (patches on review, partially acked by me). ... aand https://fedorahosted.org/freeipa/ticket/4537 which also needs to be included in 4.0.3. Martin From pviktori at redhat.com Fri Sep 12 15:35:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 17:35:11 +0200 Subject: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3 Message-ID: <541312AF.8010306@redhat.com> https://fedorahosted.org/freeipa/ticket/4537 See commit message for the story behind this one. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0644-Update-referential-integrity-config-for-DS-1.3.3.patch Type: text/x-patch Size: 4007 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 12 15:43:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 17:43:42 +0200 Subject: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3 In-Reply-To: <541312AF.8010306@redhat.com> References: <541312AF.8010306@redhat.com> Message-ID: <541314AE.5000600@redhat.com> On 09/12/2014 05:35 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4537 > > See commit message for the story behind this one. > Thanks. Works as a charm, so ACK. Pushed to: master: d61fb40542abb0aa66c49d987813099fda356adf ipa-4-1: f8771db202bcca4419be847c00f167362311e28e ipa-4-0: c6baecec1ec866d77f9a476d01c7931fce6d95da Martin From lkrispen at redhat.com Fri Sep 12 15:47:33 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Sep 2014 17:47:33 +0200 Subject: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3 In-Reply-To: <541314AE.5000600@redhat.com> References: <541312AF.8010306@redhat.com> <541314AE.5000600@redhat.com> Message-ID: <54131595.2030105@redhat.com> On 09/12/2014 05:43 PM, Martin Kosek wrote: > On 09/12/2014 05:35 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4537 >> >> See commit message for the story behind this one. >> > > Thanks. Works as a charm, so ACK. just for my understanding. what was install/share/referint-conf.ldif good for, why isn't adding the membership attrs needed there ? > > Pushed to: > master: d61fb40542abb0aa66c49d987813099fda356adf > ipa-4-1: f8771db202bcca4419be847c00f167362311e28e > ipa-4-0: c6baecec1ec866d77f9a476d01c7931fce6d95da > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Fri Sep 12 15:58:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 17:58:27 +0200 Subject: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3 In-Reply-To: <54131595.2030105@redhat.com> References: <541312AF.8010306@redhat.com> <541314AE.5000600@redhat.com> <54131595.2030105@redhat.com> Message-ID: <54131823.3080602@redhat.com> On 09/12/2014 05:47 PM, Ludwig Krispenz wrote: > > On 09/12/2014 05:43 PM, Martin Kosek wrote: >> On 09/12/2014 05:35 PM, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/4537 >>> >>> See commit message for the story behind this one. >>> >> >> Thanks. Works as a charm, so ACK. > just for my understanding. what was install/share/referint-conf.ldif > good for, why isn't adding the membership attrs needed there ? The ldif files are put in place on initial install only. The update files are applied both on initial install and on upgrades, and allow greater control over what gets done on update. At one point the policy was to put everything in both places, so ther would be a LDIF representation of what IPA puts in the directory. But that goal doesn't play well with updater plugins, and also the copies inevitably got out of sync. Now we prefer the update files for all new changes. One day we might get rid of the ldifs altogether. -- Petr? From pviktori at redhat.com Fri Sep 12 16:24:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 18:24:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn & timestamp entries to individual permissions In-Reply-To: <54130B0D.6090702@redhat.com> References: <5412DEA4.9020300@redhat.com> <54130244.1060708@redhat.com> <54130753.3010103@redhat.com> <54130B0D.6090702@redhat.com> Message-ID: <54131E45.2020807@redhat.com> On 09/12/2014 05:02 PM, Martin Kosek wrote: > On 09/12/2014 04:46 PM, Petr Viktorin wrote: >> On 09/12/2014 04:25 PM, Martin Kosek wrote: >>> On 09/12/2014 01:53 PM, Petr Viktorin wrote: >>>> https://fedorahosted.org/freeipa/ticket/4534 >>>> >>>> The entryusn and timestamp operational attributes are now >>>> automatically added >>>> to every read permission that targets objectclass, whether managed or >>>> user-created. >>>> >>>> The 'System: Read Timestamp and USN Operational Attributes', which was >>>> added >>>> for 4.0.2, is removed on upgrade. >>>> >>>> >>> >>> This looks good to me. deref search now return expected results: >>> >>> # ldapsearch -h `hostname` -Y GSSAPI -b >>> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E >>> 'deref=memberof:objectclass,entryusn' >>> SASL/GSSAPI authentication started >>> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST >>> SASL SSF: 56 >>> SASL data security layer installed. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with >>> scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # with dereference control >>> # >>> >>> # admin, users, accounts, mkosek-fedora20.test >>> dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test >>> control: 1.3.6.1.4.1.4203.666.5.16 false ... >>> # memberof: >>> ;;>> >>> oup>;;;>> >>> >>> roup>;;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc >>> >>> =test >>> >>> # memberof: >>> ;;>> >>> es>;;;;cn=t >>> >>> rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test >>> >>> objectClass: top >>> objectClass: person >>> ... >>> >>> >>> I.e. only the memberof objects that the host has access to are >>> dereferenced. Updated permissions also look OK. >>> >>> Thus ACK from me of there are no other objections. >>> >>> What should we do about remaining Operational permission? >>> >>> -------------------- >>> 1 permission matched >>> -------------------- >>> Permission name: System: Read Creator and Modifier Operational >>> Attributes >>> Granted rights: read, compare, search >>> Effective attributes: creatorsname, modifiersname >>> Default attributes: modifiersname, creatorsname >>> Bind rule type: all >>> Subtree: dc=mkosek-fedora20,dc=test >>> Extra target filter: (objectclass=*) >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> ? Any host can still use deref to for example find creatorsname or >>> modifiersname of memberof entries. >>> >>> I would personally rather delete the permission and keep the attributes >>> only for DM (and admin) or make it permission-based as SSSD does not use >>> it anyway, AFAIK. >>> >>> Martin >> >> This version removes 'System: Read Creator and Modifier Operational >> Attributes' >> as well. >> > > Works fine. ACK. Thanks! Pushed to: ipa-4-0: f47da6a761a97134668cf674c78f5f9271c98e8b ipa-4-1: a0e23ce210506be84716343982ef43099841177b master: 4fac4f4cf65b54bc0b194928341b31e3c67d63a5 > (You will need to regenerate ACI.txt for each merged branch as there are > conflicts). (Yeah, whoever invented this ACI.txt thing, I need to have a talk with him) -- Petr? From pviktori at redhat.com Fri Sep 12 16:36:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 18:36:02 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3 ? Message-ID: <541320F2.9050802@redhat.com> There were some critical issues in 4.0.2, mainly with integration: https://fedorahosted.org/freeipa/ticket/4529 - broken upgrades https://fedorahosted.org/freeipa/ticket/4430 - python-qrcode packaging fix https://fedorahosted.org/freeipa/ticket/4395 - update of SSL ciphers https://fedorahosted.org/freeipa/ticket/4534 - operational attribute ACIs https://fedorahosted.org/freeipa/ticket/4537 - referential integrity configuration All the fixes are pushed now. Please test! If nothing else shows up, I will release 4.0.3 today. -- Petr? From mkosek at redhat.com Fri Sep 12 17:20:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 19:20:45 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.3 ? In-Reply-To: <541320F2.9050802@redhat.com> References: <541320F2.9050802@redhat.com> Message-ID: <54132B6D.3030804@redhat.com> On 09/12/2014 06:36 PM, Petr Viktorin wrote: > There were some critical issues in 4.0.2, mainly with integration: > > https://fedorahosted.org/freeipa/ticket/4529 - broken upgrades > https://fedorahosted.org/freeipa/ticket/4430 - python-qrcode packaging fix > https://fedorahosted.org/freeipa/ticket/4395 - update of SSL ciphers > https://fedorahosted.org/freeipa/ticket/4534 - operational attribute ACIs > https://fedorahosted.org/freeipa/ticket/4537 - referential integrity configuration > > All the fixes are pushed now. Please test! +1. > If nothing else shows up, I will release 4.0.3 today. I also sent fixed 389-ds-base-1.3.3.2-2.fc21.src.rpm to our Copr to have it ready for F20. Martin From mbasti at redhat.com Fri Sep 12 17:24:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Sep 2014 19:24:05 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5412C56C.7060404@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> Message-ID: <54132C35.6080004@redhat.com> Be careful, reviewed on friday! :-) 1) whitespace error + pep8 error patch:76: trailing whitespace. # there is reverse zone for every ip address warning: 1 line adds whitespace errors. ./ipaserver/install/bindinstance.py:640:9: E265 block comment should start with '# ' 2) (server install) + for ip in ip_addresses: + for rev_zone in reverse_zones: + if bindinstance.verify_reverse_zone(rev_zone, str(ip)): + break + else: + sys.exit(1) Please add there error message instead 1 to exit function 3) (server install) Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): IMHO this will cause errors (not tested) try: rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] ip_addreses: [10.10.10.1, 172.16.0.1] it should be any() of zone can handle ip 4) (replica-install) I'm not sure about behavior of combination ip addresses, and reverse zones, In original code, if user specify reverse zone, the ip address must match. In patched version, you just add new zones for ip-addresses which doesn't math the user zones. IMO we should check if all addresses belongs to user specified zones, otherwise raise an error. But I'm open to suggestions. 5) Code for ipa-replica-install, and ipa-server-install, differs in parts where we expecting same behavior - ip addresses and reverse zones 6) + # there is at least one ip address in every zone + if options.reverse_zones: + for reverse_zone in options.reverse_zones: + for ip in config.ips: <---------------------------------------------------------------------------------- A + if bindinstance.verify_reverse_zone(reverse_zone, ip): + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) + break + else: + sys.exit(1) <------------------------------------------------------------------------------------------------* + # there is reverse zone for every ip address + for ip in config.ips: + for reverse_zone in options.reverse_zones: <------------------------------------------------------- B + if bindinstance.verify_reverse_zone(reverse_zone, ip): + if reverse_zone not in reverse_zones: + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) + break + else: <------------------------------------------------------------------------------------------------------------ C + reverse_zone = bindinstance.find_reverse_zone(ip) + if reverse_zone is None and not options.no_reverse: + reverse_zone = util.get_reverse_zone_default(ip) <----------------------------------------- D1 + if not options.unattended and bindinstance.create_reverse(): <------------------------- D + reverse_zone = bindinstance.read_reverse_zone(reverse_zone, ip) + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) <------------- D2 You added all possible zones in step A, B step is not needed. If user doesn't specify reverse_zones you can just jump to C step *add error message C: elif not options.no_reverse D: you asked user if wants to create zone, but you don't care about answer, and in step D2 append zone from D1 note: --no-reverse and --reverse-zones cant be used together, you can use it in new code, test it before cycle 7) # Always use force=True as named is not set up yet add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, - ns_hostname=api.env.host, ns_ip_address=nameserver_ip_address, - force=True) + ns_hostname=api.env.host, ns_ip_address=None, force=True) + #for ns_ip_address in nameserver_ip_address: + # add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, + # ns_hostname=api.env.host, ns_ip_address=ns_ip_address, + # force=True) Please remove commented section You can remove 'ns_ip_address=None' from function 8) + if set(options.ip_addresses) <= set(ips): + ips = options.ip_addresses + else: + print >>sys.stderr, "Error: the hostname resolves to an IP address that is different" + print >>sys.stderr, "from the one provided on the command line. Please fix your DNS" + print >>sys.stderr, "or /etc/hosts file and restart the installation." + sys.exit(1) Could you write those extra addresses to output? We need to improve usability of our error messages -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Sep 12 20:26:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 22:26:53 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 Message-ID: <5413570D.3040708@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21 Beta. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Bug fixes in 4.0.3 == * Several issues concerning integration with 389 Directory Server 1.3.3 were fixed. * An upgrade crash was fixed. == Known Issues == * On Fedora 21 Alpha, FreeIPA server configuration should be done after upgrading packages from updates-testing. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.2 == === David Kupka (1) === * Fix typo causing ipa-upgradeconfig to fail. === Ludwig Krispenz (1) === * Update SSL ciphers configured in 389-ds-base === Nathaniel McCallum (1) === * Update qrcode support for newer python-qrcode === Petr Viktorin (4) === * Update referential integrity config for DS 1.3.3 * permission plugin: Auto-add operational atttributes to read permissions * Allow deleting obsolete permissions; remove operational attribute permissions * Become IPA 4.0.3 From pviktori at redhat.com Mon Sep 15 08:59:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Sep 2014 10:59:09 +0200 Subject: [Freeipa-devel] [PATCH] 11 - re-enable uninstall option in ipa-kra-install In-Reply-To: <54103745.2070101@redhat.com> References: <1409627109.4471.8.camel@aleeredhat.laptop> <54103745.2070101@redhat.com> Message-ID: <5416AA5D.20209@redhat.com> On 09/10/2014 01:34 PM, Petr Viktorin wrote: > On 09/02/2014 05:05 AM, Ade Lee wrote: >> Re-enable uninstall feature for ipa-kra-install >> >> The underlying Dogtag issue (Dogtag ticket 1113) has been fixed. >> We can therefore re-enable the uninstall option for ipa-kra-install. >> Also, fixes an incorrect path in the ipa-pki-proxy.conf, and adds >> a debug statement to provide status to the user when an uninstall >> is done. Also, re-added the no_host_dns option which is used when >> unpacking a replica file. >> >> Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 >> >> Please review. A new COPR Dogtag build with the relevant fix for ticket >> 1113 has been built. (pki-core-10.2.0-0.8.fc20) Please update your >> Dogtag build to this version. >> >> Thanks, >> Ade > > ACK > To be pushed to master when fedorahosted comes back online. Pushed to master: 9ca5a4e42084ba43e106fa3be9dac9965216e710 -- Petr? From npmccallum at redhat.com Mon Sep 15 14:45:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 10:45:05 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <5413570D.3040708@redhat.com> References: <5413570D.3040708@redhat.com> Message-ID: <1410792305.4238.3.camel@redhat.com> FYI, for any Fedora testers out there, we have updated to 4.0.3 in Fedora 21 in part because it substantially reduces the size of the install media for the upcoming Alpha release. If you'd like to test and provide feedback on the packages, the link is here: https://admin.fedoraproject.org/updates/FEDORA-2014-10811 On Fri, 2014-09-12 at 22:26 +0200, Petr Viktorin wrote: > The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! > > It can be downloaded from http://www.freeipa.org/page/Downloads. The > builds will be available for Fedora 21 Beta. Builds for Fedora 20 are > available in the official > [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. > > == Bug fixes in 4.0.3 == > * Several issues concerning integration with 389 Directory Server 1.3.3 > were fixed. > * An upgrade crash was fixed. > > == Known Issues == > * On Fedora 21 Alpha, FreeIPA server configuration should be done after > upgrading packages from updates-testing. > > == Upgrading == > An IPA server can be upgraded simply by installing updated rpms. The > server does not need to be shut down in advance. > > Please note that if you are doing the upgrade in special environment > (e.g. FedUp) which does not allow running the LDAP server during upgrade > process, upgrade scripts need to be run manually after the first boot: > > # ipa-ldap-updater --upgrade > # ipa-upgradeconfig > > Also note that the performance improvements require an extended set of > indexes to be configured. RPM update for an IPA server with a excessive > number of users may require several minutes to finish. > > If you have multiple servers you may upgrade them one at a time. It is > expected that all servers will be upgraded in a relatively short period > (days or weeks, not months). They should be able to co-exist peacefully > but new features will not be available on old servers and enrolling a > new client against an old server will result in the SSH keys not being > uploaded. > > Downgrading a server once upgraded is not supported. > > Upgrading from 3.3.0 and later versions is supported. Upgrading from > previous versions is not supported and has not been tested. > > An enrolled client does not need the new packages installed unless you > want to re-enroll it. SSH keys for already installed clients are not > uploaded, you will have to re-enroll the client or manually upload the keys. > > == Feedback == > Please provide comments, bugs and other feedback via the freeipa-users > mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or > #freeipa channel on Freenode. > > == Detailed Changelog since 4.0.2 == > === David Kupka (1) === > * Fix typo causing ipa-upgradeconfig to fail. > > === Ludwig Krispenz (1) === > * Update SSL ciphers configured in 389-ds-base > > === Nathaniel McCallum (1) === > * Update qrcode support for newer python-qrcode > > === Petr Viktorin (4) === > * Update referential integrity config for DS 1.3.3 > * permission plugin: Auto-add operational atttributes to read permissions > * Allow deleting obsolete permissions; remove operational attribute > permissions > * Become IPA 4.0.3 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Mon Sep 15 15:10:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Sep 2014 17:10:33 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5412F2CD.4060202@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> Message-ID: <54170169.7080607@redhat.com> On 12.9.2014 15:19, Martin Basti wrote: > On 03/09/14 12:45, Martin Basti wrote: >> On 03/09/14 12:27, Martin Kosek wrote: >>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>> 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 >>>> Functional ACK, it works for me. It can be pushed if Python gurus are okay >>>> with >>>> the code. >>> Is it safe to commit the change given that bind-dyndb-ldap still crash when >>> "." >>> is removed? Wouldn't it break our CI tests? >>> >>> Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it >>> would be soon. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >> Currently I'm testing bind-dyndb-ldap related patch. >> > Added patches 120 and 121, which are required by DNS to work correctly. > Patches 120 and 121 add all DNS replicas to zone apex as NS, --name-server > option doesn't add NS record, only changes the SOA MNAME attribute > > Original and new patches attached. NACK, unfortunately it doesn't work for me: # ipa dnszone-add tri.test. --name-server=ns.test. Administrator e-mail address [hostmaster.tri.test.]: ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME record. To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ --ns-rec=nameserver'. Zone name: tri.test. Active zone: TRUE Authoritative nameserver: ns.test. Administrator e-mail address: hostmaster.tri.test. SOA serial: 1410793406 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example idnsname: tri.test. idnszoneactive: TRUE idnssoamname: ns.test. idnssoarname: hostmaster.tri.test. idnssoaserial: 1410793408 idnssoarefresh: 3600 idnssoaretry: 900 idnssoaexpire: 1209600 idnssoaminimum: 3600 idnsallowquery: any; idnsallowtransfer: none; idnsAllowDynUpdate: FALSE idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; nsrecord: vm-035.idm.lab.eng.brq.redhat.com. objectClass: idnszone objectClass: top objectClass: idnsrecord [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). ipa: ERROR: tri.test.: DNS resource record not found -- Petr^2 Spacek From mbasti at redhat.com Mon Sep 15 15:16:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 15 Sep 2014 17:16:21 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <54170169.7080607@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> Message-ID: <541702C5.5060203@redhat.com> On 15/09/14 17:10, Petr Spacek wrote: > On 12.9.2014 15:19, Martin Basti wrote: >> On 03/09/14 12:45, Martin Basti wrote: >>> On 03/09/14 12:27, Martin Kosek wrote: >>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>> 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 >>>>> Functional ACK, it works for me. It can be pushed if Python gurus >>>>> are okay >>>>> with >>>>> the code. >>>> Is it safe to commit the change given that bind-dyndb-ldap still >>>> crash when >>>> "." >>>> is removed? Wouldn't it break our CI tests? >>>> >>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>> Hopefully it >>>> would be soon. >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>> Currently I'm testing bind-dyndb-ldap related patch. >>> >> Added patches 120 and 121, which are required by DNS to work correctly. >> Patches 120 and 121 add all DNS replicas to zone apex as NS, >> --name-server >> option doesn't add NS record, only changes the SOA MNAME attribute >> >> Original and new patches attached. > > NACK, unfortunately it doesn't work for me: > # ipa dnszone-add tri.test. --name-server=ns.test. > Administrator e-mail address [hostmaster.tri.test.]: > ipa: WARNING: '--name-server' is used only for setting up the SOA > MNAME record. > To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ > --ns-rec=nameserver'. > Zone name: tri.test. > Active zone: TRUE > Authoritative nameserver: ns.test. > Administrator e-mail address: hostmaster.tri.test. > SOA serial: 1410793406 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant > IPA.EXAMPLE krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; > Dynamic update: FALSE > Allow query: any; > Allow transfer: none; > > [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw > dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example > idnsname: tri.test. > idnszoneactive: TRUE > idnssoamname: ns.test. > idnssoarname: hostmaster.tri.test. > idnssoaserial: 1410793408 > idnssoarefresh: 3600 > idnssoaretry: 900 > idnssoaexpire: 1209600 > idnssoaminimum: 3600 > idnsallowquery: any; > idnsallowtransfer: none; > idnsAllowDynUpdate: FALSE > idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE > krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; > nsrecord: vm-035.idm.lab.eng.brq.redhat.com. > objectClass: idnszone > objectClass: top > objectClass: idnsrecord > > [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). > ipa: ERROR: tri.test.: DNS resource record not found > NACKing NACK ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). you switched order zone and record, it should be ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). -- Martin Basti From tbabej at redhat.com Mon Sep 15 15:21:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Sep 2014 17:21:40 +0200 Subject: [Freeipa-devel] Required descriptions Message-ID: <54170404.4060606@redhat.com> Hi folks, while developing parts of the upcoming views feature (http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust), we stumbled upon the question of having descriptions required by the framework. There are arguments for the description being required, at least for overriding attributes of IPA users. However, nothing stops irresponsible admins from entering descriptions like 'foo'. There is related ticket in the Trac: https://fedorahosted.org/freeipa/ticket/4387 I'd like to avoid having this argument over again. Can we establish a guideline we wish to follow? Having tickets like #4387 and requiring descriptions in new features is too inconsistent for my taste :) we should either: 1.) Define a clear line - when it makes sense to require description and when not. 2.) Decide never to require description, since it is a non-enforcible requirement (nothing stops you from entering meaningless description). -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Mon Sep 15 15:26:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Sep 2014 17:26:16 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <1410792305.4238.3.camel@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> Message-ID: <54170518.1060508@redhat.com> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: > FYI, for any Fedora testers out there, we have updated to 4.0.3 in > Fedora 21 in part because it substantially reduces the size of the > install media for the upcoming Alpha release. If you'd like to test and > provide feedback on the packages, the link is here: > > https://admin.fedoraproject.org/updates/FEDORA-2014-10811 Actually, this update came too late for the Alpha. It will be considered for Beta. Use the updates-testing repo if you want to test FreeIPA in f21 Alpha. -- Petr? From pvoborni at redhat.com Mon Sep 15 15:37:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 15 Sep 2014 17:37:12 +0200 Subject: [Freeipa-devel] Required descriptions In-Reply-To: <54170404.4060606@redhat.com> References: <54170404.4060606@redhat.com> Message-ID: <541707A8.9040405@redhat.com> On 15.9.2014 17:21, Tomas Babej wrote: > Hi folks, > > while developing parts of the upcoming views feature > (http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust), > we stumbled upon the question of having descriptions required by the > framework. > > There are arguments for the description being required, at least for > overriding attributes of IPA users. However, nothing stops irresponsible > admins from entering descriptions like 'foo'. > > There is related ticket in the Trac: > > https://fedorahosted.org/freeipa/ticket/4387 > > I'd like to avoid having this argument over again. Can we establish a > guideline we wish to follow? Having tickets like #4387 and requiring > descriptions in new features is too inconsistent for my taste :) we > should either: > > 1.) Define a clear line - when it makes sense to require description and > when not. > 2.) Decide never to require description, since it is a non-enforcible > requirement (nothing stops you from entering meaningless description). > Description is a helper tool for users and it's not required for any functionality. Ideally user (company policy) should choose whether it should be required. We should only give recommendations, e.g., in documentation. Making it configurable seems like a lot of effort with little added value. I'm for #2. Btw, idview plugin is inconsistent by itself atm - overrides have it required but idview doesn't. my 2c -- Petr Vobornik From npmccallum at redhat.com Mon Sep 15 16:16:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 12:16:35 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <54170518.1060508@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> <54170518.1060508@redhat.com> Message-ID: <1410797795.4238.4.camel@redhat.com> On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: > On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: > > FYI, for any Fedora testers out there, we have updated to 4.0.3 in > > Fedora 21 in part because it substantially reduces the size of the > > install media for the upcoming Alpha release. If you'd like to test and > > provide feedback on the packages, the link is here: > > > > https://admin.fedoraproject.org/updates/FEDORA-2014-10811 > > Actually, this update came too late for the Alpha. It will be considered > for Beta. > > > Use the updates-testing repo if you want to test FreeIPA in f21 Alpha. https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist See bug: 1117432. From sgallagh at redhat.com Mon Sep 15 18:29:36 2014 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 15 Sep 2014 14:29:36 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <1410797795.4238.4.camel@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> <54170518.1060508@redhat.com> <1410797795.4238.4.camel@redhat.com> Message-ID: <54173010.9080405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/15/2014 12:16 PM, Nathaniel McCallum wrote: > On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: >> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: >>> FYI, for any Fedora testers out there, we have updated to 4.0.3 >>> in Fedora 21 in part because it substantially reduces the size >>> of the install media for the upcoming Alpha release. If you'd >>> like to test and provide feedback on the packages, the link is >>> here: >>> >>> https://admin.fedoraproject.org/updates/FEDORA-2014-10811 >> >> Actually, this update came too late for the Alpha. It will be >> considered for Beta. >> >> >> Use the updates-testing repo if you want to test FreeIPA in f21 >> Alpha. > > https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist > > See bug: 1117432. Actually, we need to get that removed from Freeze Exception. The original plan was for python-qrcode and a simple rebuild of FreeIPA to go in. However, FreeIPA has made significant changes (pulling in new 389 and dogtag packages) and it is now too risky to include in the already-very-late-Alpha. It's unfortunate, but that's going to have to go in for Beta. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQXMBAACgkQeiVVYja6o6MdGQCcDGvTVvdZfdYNrClAeZa5eYKL 0KQAn11ahaY2BbA5boyiR4SPwef6HGuv =zHrh -----END PGP SIGNATURE----- From mkosek at redhat.com Mon Sep 15 18:31:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Sep 2014 20:31:03 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <541702C5.5060203@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> Message-ID: <54173067.2080106@redhat.com> On 09/15/2014 05:16 PM, Martin Basti wrote: > On 15/09/14 17:10, Petr Spacek wrote: >> On 12.9.2014 15:19, Martin Basti wrote: >>> On 03/09/14 12:45, Martin Basti wrote: >>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>> 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 >>>>>> Functional ACK, it works for me. It can be pushed if Python gurus are okay >>>>>> with >>>>>> the code. >>>>> Is it safe to commit the change given that bind-dyndb-ldap still crash when >>>>> "." >>>>> is removed? Wouldn't it break our CI tests? >>>>> >>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it >>>>> would be soon. >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>> Currently I'm testing bind-dyndb-ldap related patch. >>>> >>> Added patches 120 and 121, which are required by DNS to work correctly. >>> Patches 120 and 121 add all DNS replicas to zone apex as NS, --name-server >>> option doesn't add NS record, only changes the SOA MNAME attribute >>> >>> Original and new patches attached. >> >> NACK, unfortunately it doesn't work for me: >> # ipa dnszone-add tri.test. --name-server=ns.test. >> Administrator e-mail address [hostmaster.tri.test.]: >> ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME record. >> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >> --ns-rec=nameserver'. >> Zone name: tri.test. >> Active zone: TRUE >> Authoritative nameserver: ns.test. >> Administrator e-mail address: hostmaster.tri.test. >> SOA serial: 1410793406 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >> Dynamic update: FALSE >> Allow query: any; >> Allow transfer: none; >> >> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >> idnsname: tri.test. >> idnszoneactive: TRUE >> idnssoamname: ns.test. >> idnssoarname: hostmaster.tri.test. >> idnssoaserial: 1410793408 >> idnssoarefresh: 3600 >> idnssoaretry: 900 >> idnssoaexpire: 1209600 >> idnssoaminimum: 3600 >> idnsallowquery: any; >> idnsallowtransfer: none; >> idnsAllowDynUpdate: FALSE >> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >> objectClass: idnszone >> objectClass: top >> objectClass: idnsrecord >> >> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >> ipa: ERROR: tri.test.: DNS resource record not found >> > NACKing NACK > ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). > you switched order zone and record, it should be > ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). > BTW, since we are so nicely breaking the dnszone-add interface, can we also get rid of always asking for "Administrator e-mail address"? >> # ipa dnszone-add tri.test. --name-server=ns.test. >> Administrator e-mail address [hostmaster.tri.test.]: ... Is there any risk in filling that with default as any other attribute? IMO it would simplify adding zones for one more redundant step. CCing Rob in case he knows some historical reasons why this is requested every time. Martin From npmccallum at redhat.com Mon Sep 15 19:04:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 15:04:25 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <54173010.9080405@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> <54170518.1060508@redhat.com> <1410797795.4238.4.camel@redhat.com> <54173010.9080405@redhat.com> Message-ID: <1410807865.4238.5.camel@redhat.com> On Mon, 2014-09-15 at 14:29 -0400, Stephen Gallagher wrote: > On 09/15/2014 12:16 PM, Nathaniel McCallum wrote: > > On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: > >> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: > >>> FYI, for any Fedora testers out there, we have updated to 4.0.3 > >>> in Fedora 21 in part because it substantially reduces the size > >>> of the install media for the upcoming Alpha release. If you'd > >>> like to test and provide feedback on the packages, the link is > >>> here: > >>> > >>> https://admin.fedoraproject.org/updates/FEDORA-2014-10811 > >> > >> Actually, this update came too late for the Alpha. It will be > >> considered for Beta. > >> > >> > >> Use the updates-testing repo if you want to test FreeIPA in f21 > >> Alpha. > > > > https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist > > > > See bug: 1117432. > > Actually, we need to get that removed from Freeze Exception. The > original plan was for python-qrcode and a simple rebuild of FreeIPA to > go in. However, FreeIPA has made significant changes (pulling in new > 389 and dogtag packages) and it is now too risky to include in the > already-very-late-Alpha. > > It's unfortunate, but that's going to have to go in for Beta. Fine by me. We still need testing though. :) From npmccallum at redhat.com Mon Sep 15 19:05:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 15:05:11 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin Message-ID: <1410807911.4238.6.camel@redhat.com> This plugin ensures that all counter/watermark operations are atomic and never decrement. Also, deletion is not permitted. https://fedorahosted.org/freeipa/ticket/4494 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064-Create-ipa-otp-decrement-389DS-plugin.patch Type: text/x-patch Size: 18454 bytes Desc: not available URL: From npmccallum at redhat.com Mon Sep 15 19:08:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 15:08:14 -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: <1410808094.4238.7.camel@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 I still need a review of this. This is targeted for 4.1. Nathaniel From mkosek at redhat.com Mon Sep 15 20:35:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Sep 2014 22:35:04 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <1410807865.4238.5.camel@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> <54170518.1060508@redhat.com> <1410797795.4238.4.camel@redhat.com> <54173010.9080405@redhat.com> <1410807865.4238.5.camel@redhat.com> Message-ID: <54174D78.2020807@redhat.com> On 09/15/2014 09:04 PM, Nathaniel McCallum wrote: > On Mon, 2014-09-15 at 14:29 -0400, Stephen Gallagher wrote: >> On 09/15/2014 12:16 PM, Nathaniel McCallum wrote: >>> On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: >>>> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: >>>>> FYI, for any Fedora testers out there, we have updated to 4.0.3 >>>>> in Fedora 21 in part because it substantially reduces the size >>>>> of the install media for the upcoming Alpha release. If you'd >>>>> like to test and provide feedback on the packages, the link is >>>>> here: >>>>> >>>>> https://admin.fedoraproject.org/updates/FEDORA-2014-10811 >>>> >>>> Actually, this update came too late for the Alpha. It will be >>>> considered for Beta. >>>> >>>> >>>> Use the updates-testing repo if you want to test FreeIPA in f21 >>>> Alpha. >>> >>> https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist >>> >>> See bug: 1117432. >> >> Actually, we need to get that removed from Freeze Exception. The >> original plan was for python-qrcode and a simple rebuild of FreeIPA to >> go in. However, FreeIPA has made significant changes (pulling in new >> 389 and dogtag packages) and it is now too risky to include in the >> already-very-late-Alpha. >> >> It's unfortunate, but that's going to have to go in for Beta. > > Fine by me. We still need testing though. :) Sure, it is your call. I added my comment to https://bugzilla.redhat.com/show_bug.cgi?id=1117432#c13 I just hope that not many people would run on FreeIPA 4.0.2, it contains couple major bugs or limitations. List of fixed bugs is in https://admin.fedoraproject.org/updates/FEDORA-2014-10811/ Martin From mkosek at redhat.com Tue Sep 16 06:14:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Sep 2014 08:14:41 +0200 Subject: [Freeipa-devel] Required descriptions In-Reply-To: <541707A8.9040405@redhat.com> References: <54170404.4060606@redhat.com> <541707A8.9040405@redhat.com> Message-ID: <5417D551.3060707@redhat.com> On 09/15/2014 05:37 PM, Petr Vobornik wrote: > On 15.9.2014 17:21, Tomas Babej wrote: >> Hi folks, >> >> while developing parts of the upcoming views feature >> (http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust), >> we stumbled upon the question of having descriptions required by the >> framework. >> >> There are arguments for the description being required, at least for >> overriding attributes of IPA users. However, nothing stops irresponsible >> admins from entering descriptions like 'foo'. >> >> There is related ticket in the Trac: >> >> https://fedorahosted.org/freeipa/ticket/4387 >> >> I'd like to avoid having this argument over again. Can we establish a >> guideline we wish to follow? Having tickets like #4387 and requiring >> descriptions in new features is too inconsistent for my taste :) we >> should either: >> >> 1.) Define a clear line - when it makes sense to require description and >> when not. >> 2.) Decide never to require description, since it is a non-enforcible >> requirement (nothing stops you from entering meaningless description). >> > > Description is a helper tool for users and it's not required for any > functionality. Ideally user (company policy) should choose whether it should be > required. We should only give recommendations, e.g., in documentation. > > Making it configurable seems like a lot of effort with little added value. > > I'm for #2. > > Btw, idview plugin is inconsistent by itself atm - overrides have it required > but idview doesn't. > > my 2c +1, please don't require description unless it is really required for the actual functionality. As already discussed wrt #4387, we cannot force admins to enter something sensible in the description, so let us not punish those who do not want to document it and make adding views, SUDO rules, ... easier. Adding description to MUST part of objectclass is rather unprecedented move. Just for fun I listed all objectclasses in my DS that use description field and neither of them had it in MUST part. I could partially live with description being in MAY part of objectclass + the framework requiring it, but I do not think it is a good idea either. Martin From mbasti at redhat.com Tue Sep 16 07:32:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Sep 2014 09:32:05 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <54173067.2080106@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> Message-ID: <5417E775.4050905@redhat.com> On 15/09/14 20:31, Martin Kosek wrote: > On 09/15/2014 05:16 PM, Martin Basti wrote: >> On 15/09/14 17:10, Petr Spacek wrote: >>> On 12.9.2014 15:19, Martin Basti wrote: >>>> On 03/09/14 12:45, Martin Basti wrote: >>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>> 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 >>>>>>> Functional ACK, it works for me. It can be pushed if Python >>>>>>> gurus are okay >>>>>>> with >>>>>>> the code. >>>>>> Is it safe to commit the change given that bind-dyndb-ldap still >>>>>> crash when >>>>>> "." >>>>>> is removed? Wouldn't it break our CI tests? >>>>>> >>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>> Hopefully it >>>>>> would be soon. >>>>>> >>>>>> Martin >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>> >>>> Added patches 120 and 121, which are required by DNS to work >>>> correctly. >>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>> --name-server >>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>> >>>> Original and new patches attached. >>> >>> NACK, unfortunately it doesn't work for me: >>> # ipa dnszone-add tri.test. --name-server=ns.test. >>> Administrator e-mail address [hostmaster.tri.test.]: >>> ipa: WARNING: '--name-server' is used only for setting up the SOA >>> MNAME record. >>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>> --ns-rec=nameserver'. >>> Zone name: tri.test. >>> Active zone: TRUE >>> Authoritative nameserver: ns.test. >>> Administrator e-mail address: hostmaster.tri.test. >>> SOA serial: 1410793406 >>> SOA refresh: 3600 >>> SOA retry: 900 >>> SOA expire: 1209600 >>> SOA minimum: 3600 >>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant >>> IPA.EXAMPLE >>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>> Dynamic update: FALSE >>> Allow query: any; >>> Allow transfer: none; >>> >>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>> idnsname: tri.test. >>> idnszoneactive: TRUE >>> idnssoamname: ns.test. >>> idnssoarname: hostmaster.tri.test. >>> idnssoaserial: 1410793408 >>> idnssoarefresh: 3600 >>> idnssoaretry: 900 >>> idnssoaexpire: 1209600 >>> idnssoaminimum: 3600 >>> idnsallowquery: any; >>> idnsallowtransfer: none; >>> idnsAllowDynUpdate: FALSE >>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>> objectClass: idnszone >>> objectClass: top >>> objectClass: idnsrecord >>> >>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>> ipa: ERROR: tri.test.: DNS resource record not found >>> >> NACKing NACK >> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >> you switched order zone and record, it should be >> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >> > > BTW, since we are so nicely breaking the dnszone-add interface, can we > also get rid of always asking for "Administrator e-mail address"? > > >> # ipa dnszone-add tri.test. --name-server=ns.test. > >> Administrator e-mail address [hostmaster.tri.test.]: > ... > > Is there any risk in filling that with default as any other attribute? > IMO it would simplify adding zones for one more redundant step. CCing > Rob in case he knows some historical reasons why this is requested > every time. > > Martin There is no risk, because ipa-replica-prepare do that with default values -- Martin Basti From mbasti at redhat.com Tue Sep 16 07:57:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Sep 2014 09:57:49 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417E775.4050905@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> Message-ID: <5417ED7D.8000701@redhat.com> On 16/09/14 09:32, Martin Basti wrote: > On 15/09/14 20:31, Martin Kosek wrote: >> On 09/15/2014 05:16 PM, Martin Basti wrote: >>> On 15/09/14 17:10, Petr Spacek wrote: >>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>> 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 >>>>>>>> Functional ACK, it works for me. It can be pushed if Python >>>>>>>> gurus are okay >>>>>>>> with >>>>>>>> the code. >>>>>>> Is it safe to commit the change given that bind-dyndb-ldap still >>>>>>> crash when >>>>>>> "." >>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>> >>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>>> Hopefully it >>>>>>> would be soon. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>> >>>>> Added patches 120 and 121, which are required by DNS to work >>>>> correctly. >>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>>> --name-server >>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>> >>>>> Original and new patches attached. >>>> >>>> NACK, unfortunately it doesn't work for me: >>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>> Administrator e-mail address [hostmaster.tri.test.]: >>>> ipa: WARNING: '--name-server' is used only for setting up the SOA >>>> MNAME record. >>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>>> --ns-rec=nameserver'. >>>> Zone name: tri.test. >>>> Active zone: TRUE >>>> Authoritative nameserver: ns.test. >>>> Administrator e-mail address: hostmaster.tri.test. >>>> SOA serial: 1410793406 >>>> SOA refresh: 3600 >>>> SOA retry: 900 >>>> SOA expire: 1209600 >>>> SOA minimum: 3600 >>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant >>>> IPA.EXAMPLE >>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>> Dynamic update: FALSE >>>> Allow query: any; >>>> Allow transfer: none; >>>> >>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>> idnsname: tri.test. >>>> idnszoneactive: TRUE >>>> idnssoamname: ns.test. >>>> idnssoarname: hostmaster.tri.test. >>>> idnssoaserial: 1410793408 >>>> idnssoarefresh: 3600 >>>> idnssoaretry: 900 >>>> idnssoaexpire: 1209600 >>>> idnssoaminimum: 3600 >>>> idnsallowquery: any; >>>> idnsallowtransfer: none; >>>> idnsAllowDynUpdate: FALSE >>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>> objectClass: idnszone >>>> objectClass: top >>>> objectClass: idnsrecord >>>> >>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. >>>> --ns-rec=$(hostname). >>>> ipa: ERROR: tri.test.: DNS resource record not found >>>> >>> NACKing NACK >>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>> you switched order zone and record, it should be >>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>> >> >> BTW, since we are so nicely breaking the dnszone-add interface, can >> we also get rid of always asking for "Administrator e-mail address"? >> >> >> # ipa dnszone-add tri.test. --name-server=ns.test. >> >> Administrator e-mail address [hostmaster.tri.test.]: >> ... >> >> Is there any risk in filling that with default as any other >> attribute? IMO it would simplify adding zones for one more redundant >> step. CCing Rob in case he knows some historical reasons why this is >> requested every time. >> >> Martin > There is no risk, because ipa-replica-prepare do that with default values > However, this will not work with root zone ".", and I'm not sure how often an admin email is used. I think whois is better utility to get contact email. Also RIPE-203 [1] recommends to use 'hostmaster' alias. [1] http://www.ripe.net/ripe/docs/ripe-203 -- Martin Basti From mkosek at redhat.com Tue Sep 16 08:09:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Sep 2014 10:09:07 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417ED7D.8000701@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> Message-ID: <5417F023.90109@redhat.com> On 09/16/2014 09:57 AM, Martin Basti wrote: > On 16/09/14 09:32, Martin Basti wrote: >> On 15/09/14 20:31, Martin Kosek wrote: >>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>> 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 >>>>>>>>> Functional ACK, it works for me. It can be pushed if Python gurus are >>>>>>>>> okay >>>>>>>>> with >>>>>>>>> the code. >>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap still crash >>>>>>>> when >>>>>>>> "." >>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>> >>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it >>>>>>>> would be soon. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>> >>>>>> Added patches 120 and 121, which are required by DNS to work correctly. >>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, --name-server >>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>> >>>>>> Original and new patches attached. >>>>> >>>>> NACK, unfortunately it doesn't work for me: >>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>> ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME >>>>> record. >>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>>>> --ns-rec=nameserver'. >>>>> Zone name: tri.test. >>>>> Active zone: TRUE >>>>> Authoritative nameserver: ns.test. >>>>> Administrator e-mail address: hostmaster.tri.test. >>>>> SOA serial: 1410793406 >>>>> SOA refresh: 3600 >>>>> SOA retry: 900 >>>>> SOA expire: 1209600 >>>>> SOA minimum: 3600 >>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>> Dynamic update: FALSE >>>>> Allow query: any; >>>>> Allow transfer: none; >>>>> >>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>> idnsname: tri.test. >>>>> idnszoneactive: TRUE >>>>> idnssoamname: ns.test. >>>>> idnssoarname: hostmaster.tri.test. >>>>> idnssoaserial: 1410793408 >>>>> idnssoarefresh: 3600 >>>>> idnssoaretry: 900 >>>>> idnssoaexpire: 1209600 >>>>> idnssoaminimum: 3600 >>>>> idnsallowquery: any; >>>>> idnsallowtransfer: none; >>>>> idnsAllowDynUpdate: FALSE >>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>> objectClass: idnszone >>>>> objectClass: top >>>>> objectClass: idnsrecord >>>>> >>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>> >>>> NACKing NACK >>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>> you switched order zone and record, it should be >>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>> >>> >>> BTW, since we are so nicely breaking the dnszone-add interface, can we also >>> get rid of always asking for "Administrator e-mail address"? >>> >>> >> # ipa dnszone-add tri.test. --name-server=ns.test. >>> >> Administrator e-mail address [hostmaster.tri.test.]: >>> ... >>> >>> Is there any risk in filling that with default as any other attribute? IMO >>> it would simplify adding zones for one more redundant step. CCing Rob in >>> case he knows some historical reasons why this is requested every time. >>> >>> Martin >> There is no risk, because ipa-replica-prepare do that with default values Then let us do this, as we are already simplifying the dnszone-add command. > However, this will not work with root zone ".", and I'm not sure how often an > admin email is used. I think whois is better utility to get contact email. > > Also RIPE-203 [1] recommends to use 'hostmaster' alias. > > [1] http://www.ripe.net/ripe/docs/ripe-203 DNS zone "." is quite an exception, you are not adding that zone every day. So I would not keep asking for admin mail just for this one. You can add a interactive prompt callback to ask in this case and otherwise just use the default - up to you. As for the mail alias, this can be an RFE. Martin From pspacek at redhat.com Tue Sep 16 08:29:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Sep 2014 10:29:41 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417F023.90109@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> Message-ID: <5417F4F5.1050907@redhat.com> On 16.9.2014 10:09, Martin Kosek wrote: > On 09/16/2014 09:57 AM, Martin Basti wrote: >> On 16/09/14 09:32, Martin Basti wrote: >>> On 15/09/14 20:31, Martin Kosek wrote: >>>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>>> 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 >>>>>>>>>> Functional ACK, it works for me. It can be pushed if Python gurus are >>>>>>>>>> okay >>>>>>>>>> with >>>>>>>>>> the code. >>>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap still crash >>>>>>>>> when >>>>>>>>> "." >>>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>>> >>>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. Hopefully it >>>>>>>>> would be soon. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>>> >>>>>>> Added patches 120 and 121, which are required by DNS to work correctly. >>>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, --name-server >>>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>>> >>>>>>> Original and new patches attached. >>>>>> >>>>>> NACK, unfortunately it doesn't work for me: >>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>> ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME >>>>>> record. >>>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>>>>> --ns-rec=nameserver'. >>>>>> Zone name: tri.test. >>>>>> Active zone: TRUE >>>>>> Authoritative nameserver: ns.test. >>>>>> Administrator e-mail address: hostmaster.tri.test. >>>>>> SOA serial: 1410793406 >>>>>> SOA refresh: 3600 >>>>>> SOA retry: 900 >>>>>> SOA expire: 1209600 >>>>>> SOA minimum: 3600 >>>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>> Dynamic update: FALSE >>>>>> Allow query: any; >>>>>> Allow transfer: none; >>>>>> >>>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>>> idnsname: tri.test. >>>>>> idnszoneactive: TRUE >>>>>> idnssoamname: ns.test. >>>>>> idnssoarname: hostmaster.tri.test. >>>>>> idnssoaserial: 1410793408 >>>>>> idnssoarefresh: 3600 >>>>>> idnssoaretry: 900 >>>>>> idnssoaexpire: 1209600 >>>>>> idnssoaminimum: 3600 >>>>>> idnsallowquery: any; >>>>>> idnsallowtransfer: none; >>>>>> idnsAllowDynUpdate: FALSE >>>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>>> objectClass: idnszone >>>>>> objectClass: top >>>>>> objectClass: idnsrecord >>>>>> >>>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>>> >>>>> NACKing NACK >>>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>> you switched order zone and record, it should be >>>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>>> >>>> >>>> BTW, since we are so nicely breaking the dnszone-add interface, can we also >>>> get rid of always asking for "Administrator e-mail address"? >>>> >>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>> ... >>>> >>>> Is there any risk in filling that with default as any other attribute? IMO >>>> it would simplify adding zones for one more redundant step. CCing Rob in >>>> case he knows some historical reasons why this is requested every time. >>>> >>>> Martin >>> There is no risk, because ipa-replica-prepare do that with default values > > Then let us do this, as we are already simplifying the dnszone-add command. > >> However, this will not work with root zone ".", and I'm not sure how often an >> admin email is used. I think whois is better utility to get contact email. >> >> Also RIPE-203 [1] recommends to use 'hostmaster' alias. >> >> [1] http://www.ripe.net/ripe/docs/ripe-203 This will likely generate tons of invalid e-mail addresses which is somehow unfortunate. Please keep in mind that: 1) E-mail hostmaster at ipa.domain.example. will be useful only if ipa.domain.example. has MX record or at least A/AAAA record (which is usually not the case for domains). 2) WHOIS is not useful for internal domains which is the main deployment scenario for IPA, right? > DNS zone "." is quite an exception, you are not adding that zone every day. So > I would not keep asking for admin mail just for this one. You can add a > interactive prompt callback to ask in this case and otherwise just use the > default - up to you. > > As for the mail alias, this can be an RFE. It would be nice to have some IPA-global default like 'DNS administrator e-mail address' and to use this value for all DNS zones by default. -- Petr^2 Spacek From mbasti at redhat.com Tue Sep 16 08:30:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Sep 2014 10:30:18 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417F4F5.1050907@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> Message-ID: <5417F51A.2030005@redhat.com> On 16/09/14 10:29, Petr Spacek wrote: > On 16.9.2014 10:09, Martin Kosek wrote: >> On 09/16/2014 09:57 AM, Martin Basti wrote: >>> On 16/09/14 09:32, Martin Basti wrote: >>>> On 15/09/14 20:31, Martin Kosek wrote: >>>>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>>>> 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 >>>>>>>>>>> Functional ACK, it works for me. It can be pushed if Python >>>>>>>>>>> gurus are >>>>>>>>>>> okay >>>>>>>>>>> with >>>>>>>>>>> the code. >>>>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap >>>>>>>>>> still crash >>>>>>>>>> when >>>>>>>>>> "." >>>>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>>>> >>>>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>>>>>> Hopefully it >>>>>>>>>> would be soon. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is >>>>>>>>> fixed. >>>>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>>>> >>>>>>>> Added patches 120 and 121, which are required by DNS to work >>>>>>>> correctly. >>>>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>>>>>> --name-server >>>>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>>>> >>>>>>>> Original and new patches attached. >>>>>>> >>>>>>> NACK, unfortunately it doesn't work for me: >>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>>> ipa: WARNING: '--name-server' is used only for setting up the >>>>>>> SOA MNAME >>>>>>> record. >>>>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod >>>>>>> [zone] @ >>>>>>> --ns-rec=nameserver'. >>>>>>> Zone name: tri.test. >>>>>>> Active zone: TRUE >>>>>>> Authoritative nameserver: ns.test. >>>>>>> Administrator e-mail address: hostmaster.tri.test. >>>>>>> SOA serial: 1410793406 >>>>>>> SOA refresh: 3600 >>>>>>> SOA retry: 900 >>>>>>> SOA expire: 1209600 >>>>>>> SOA minimum: 3600 >>>>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant >>>>>>> IPA.EXAMPLE >>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>> Dynamic update: FALSE >>>>>>> Allow query: any; >>>>>>> Allow transfer: none; >>>>>>> >>>>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>>>> idnsname: tri.test. >>>>>>> idnszoneactive: TRUE >>>>>>> idnssoamname: ns.test. >>>>>>> idnssoarname: hostmaster.tri.test. >>>>>>> idnssoaserial: 1410793408 >>>>>>> idnssoarefresh: 3600 >>>>>>> idnssoaretry: 900 >>>>>>> idnssoaexpire: 1209600 >>>>>>> idnssoaminimum: 3600 >>>>>>> idnsallowquery: any; >>>>>>> idnsallowtransfer: none; >>>>>>> idnsAllowDynUpdate: FALSE >>>>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant >>>>>>> IPA.EXAMPLE >>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>>>> objectClass: idnszone >>>>>>> objectClass: top >>>>>>> objectClass: idnsrecord >>>>>>> >>>>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. >>>>>>> --ns-rec=$(hostname). >>>>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>>>> >>>>>> NACKing NACK >>>>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>> you switched order zone and record, it should be >>>>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>>>> >>>>> >>>>> BTW, since we are so nicely breaking the dnszone-add interface, >>>>> can we also >>>>> get rid of always asking for "Administrator e-mail address"? >>>>> >>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>> ... >>>>> >>>>> Is there any risk in filling that with default as any other >>>>> attribute? IMO >>>>> it would simplify adding zones for one more redundant step. CCing >>>>> Rob in >>>>> case he knows some historical reasons why this is requested every >>>>> time. >>>>> >>>>> Martin >>>> There is no risk, because ipa-replica-prepare do that with default >>>> values >> >> Then let us do this, as we are already simplifying the dnszone-add >> command. >> >>> However, this will not work with root zone ".", and I'm not sure >>> how often an >>> admin email is used. I think whois is better utility to get contact >>> email. >>> >>> Also RIPE-203 [1] recommends to use 'hostmaster' alias. >>> >>> [1] http://www.ripe.net/ripe/docs/ripe-203 > > This will likely generate tons of invalid e-mail addresses which is > somehow unfortunate. > > Please keep in mind that: > 1) E-mail hostmaster at ipa.domain.example. will be useful only if > ipa.domain.example. has MX record or at least A/AAAA record (which is > usually not the case for domains). > > 2) WHOIS is not useful for internal domains which is the main > deployment scenario for IPA, right? > >> DNS zone "." is quite an exception, you are not adding that zone >> every day. So >> I would not keep asking for admin mail just for this one. You can add a >> interactive prompt callback to ask in this case and otherwise just >> use the >> default - up to you. >> >> As for the mail alias, this can be an RFE. > > It would be nice to have some IPA-global default like 'DNS > administrator e-mail address' and to use this value for all DNS zones > by default. > +1 -- Martin Basti From mkosek at redhat.com Tue Sep 16 08:36:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Sep 2014 10:36:50 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417F51A.2030005@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> <5417F51A.2030005@redhat.com> Message-ID: <5417F6A2.9060006@redhat.com> On 09/16/2014 10:30 AM, Martin Basti wrote: > On 16/09/14 10:29, Petr Spacek wrote: >> On 16.9.2014 10:09, Martin Kosek wrote: >>> On 09/16/2014 09:57 AM, Martin Basti wrote: >>>> On 16/09/14 09:32, Martin Basti wrote: >>>>> On 15/09/14 20:31, Martin Kosek wrote: >>>>>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>>>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>>>>> 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 >>>>>>>>>>>> Functional ACK, it works for me. It can be pushed if Python gurus are >>>>>>>>>>>> okay >>>>>>>>>>>> with >>>>>>>>>>>> the code. >>>>>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap still crash >>>>>>>>>>> when >>>>>>>>>>> "." >>>>>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>>>>> >>>>>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>>>>>>> Hopefully it >>>>>>>>>>> would be soon. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>>>>> >>>>>>>>> Added patches 120 and 121, which are required by DNS to work correctly. >>>>>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>>>>>>> --name-server >>>>>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>>>>> >>>>>>>>> Original and new patches attached. >>>>>>>> >>>>>>>> NACK, unfortunately it doesn't work for me: >>>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>>>> ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME >>>>>>>> record. >>>>>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>>>>>>> --ns-rec=nameserver'. >>>>>>>> Zone name: tri.test. >>>>>>>> Active zone: TRUE >>>>>>>> Authoritative nameserver: ns.test. >>>>>>>> Administrator e-mail address: hostmaster.tri.test. >>>>>>>> SOA serial: 1410793406 >>>>>>>> SOA refresh: 3600 >>>>>>>> SOA retry: 900 >>>>>>>> SOA expire: 1209600 >>>>>>>> SOA minimum: 3600 >>>>>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>>> Dynamic update: FALSE >>>>>>>> Allow query: any; >>>>>>>> Allow transfer: none; >>>>>>>> >>>>>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>>>>> idnsname: tri.test. >>>>>>>> idnszoneactive: TRUE >>>>>>>> idnssoamname: ns.test. >>>>>>>> idnssoarname: hostmaster.tri.test. >>>>>>>> idnssoaserial: 1410793408 >>>>>>>> idnssoarefresh: 3600 >>>>>>>> idnssoaretry: 900 >>>>>>>> idnssoaexpire: 1209600 >>>>>>>> idnssoaminimum: 3600 >>>>>>>> idnsallowquery: any; >>>>>>>> idnsallowtransfer: none; >>>>>>>> idnsAllowDynUpdate: FALSE >>>>>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>>>>> objectClass: idnszone >>>>>>>> objectClass: top >>>>>>>> objectClass: idnsrecord >>>>>>>> >>>>>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>>>>> >>>>>>> NACKing NACK >>>>>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>>> you switched order zone and record, it should be >>>>>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>>>>> >>>>>> >>>>>> BTW, since we are so nicely breaking the dnszone-add interface, can we also >>>>>> get rid of always asking for "Administrator e-mail address"? >>>>>> >>>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>> ... >>>>>> >>>>>> Is there any risk in filling that with default as any other attribute? IMO >>>>>> it would simplify adding zones for one more redundant step. CCing Rob in >>>>>> case he knows some historical reasons why this is requested every time. >>>>>> >>>>>> Martin >>>>> There is no risk, because ipa-replica-prepare do that with default values >>> >>> Then let us do this, as we are already simplifying the dnszone-add command. >>> >>>> However, this will not work with root zone ".", and I'm not sure how often an >>>> admin email is used. I think whois is better utility to get contact email. >>>> >>>> Also RIPE-203 [1] recommends to use 'hostmaster' alias. >>>> >>>> [1] http://www.ripe.net/ripe/docs/ripe-203 >> >> This will likely generate tons of invalid e-mail addresses which is somehow >> unfortunate. >> >> Please keep in mind that: >> 1) E-mail hostmaster at ipa.domain.example. will be useful only if >> ipa.domain.example. has MX record or at least A/AAAA record (which is usually >> not the case for domains). >> >> 2) WHOIS is not useful for internal domains which is the main deployment >> scenario for IPA, right? >> >>> DNS zone "." is quite an exception, you are not adding that zone every day. So >>> I would not keep asking for admin mail just for this one. You can add a >>> interactive prompt callback to ask in this case and otherwise just use the >>> default - up to you. >>> >>> As for the mail alias, this can be an RFE. >> >> It would be nice to have some IPA-global default like 'DNS administrator >> e-mail address' and to use this value for all DNS zones by default. >> > +1 Please file an RFE for this part (requires schema update, doc update, ...). For now I would stick just with using the defaults without asking (like in other commands). I think it involves just setting autofill to True. Martin From tbabej at redhat.com Tue Sep 16 11:21:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Sep 2014 13:21:33 +0200 Subject: [Freeipa-devel] [PATCHES 247-259] ID views - management part In-Reply-To: <54104DE3.2050309@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> Message-ID: <54181D3D.9070400@redhat.com> Petr, thanks for the review, your input is, as always, much to the point. My responses are inline. Also, I'm attaching a new patchset, rebased on master, please, have a look at that. Most of the patches have at least minor changes, since I rebased another ~15 patches into this patchset, and there are additional 9 patches on top. Patch 254 was deprecated, as we decided to go with more explicit way of having two separate commands for user and group ID overrides. Also, the test suite (around 80 tests) for ID views is attached - patch 270. It depends on patch 269, sent in separate thread. Tomas On 09/10/2014 03:10 PM, Petr Viktorin wrote: > On 08/01/2014 12:30 PM, Tomas Babej wrote: >> 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. >> > > Not tested yet, but here are my comments on the patches: > > 0247: > The change to copy-schema-to-ca is not necessary. This is only used > for servers installed with Dogtag 9; for such installs new schema is > added online (to 99-user.ldif), so it will be replicated to the CA DS > correctly. Removed. > > Did you register the new OIDs? Yep. > > 0248-0249 look good > > 0250: > With so many names imported from one module, I find it more readable > to `from ipalib.plugins import baseldap`, and use qualified names > later. Same in the 2 other patches. > This is personal preference/tip, feel free to disagree :) I was just trying to be consistent here, rest of the IPA plugins seem to use non-qualified names for plugins. Even tough the main reason is probably that thay use evil star imports :) Let's keep it this way for now. > > 0521: > Could you also kill the backslash in _hostname_validator? Done. > > 0252: > Typo in __doc__, should be "This functionality is primarily used"? > Done. > {idview,idoverride}.takes_params: flags needs to be a set -- here > you've specified 11 single-letter flags. (Don't we all love Python's > iterable strings.) No longer applies. > > Only one `ipa help` topic will be created for idview and idoverride. > Is that intended? Yes, but the documentation needs to be extended, making a note so that we don't forget that. > > The pattern_errmsg in idoverride's uid should be expanded to fully > describe the pattern. If we want to expand it, then it should be corrected in user.py plugin too (I have taken it from there). Still, it's a tradeoff between conciseness and and exactness, do we really want to specify that user login may be at most 253 letters long or the $ character may only be used as terminal one? Or the fact that - can't be used at the beggining? This is probably the way it was since forever in user plugin. > > 0253 looks good > > 0254: > The DN refactoring is done; I don't think the asserts in pre_callbacks > are necessary any more. Fixed in other places. BTW, I killed this patch. > > 0258: > idview_apply: typo in hostgroup doc, should be "hosts to apply the ID > view to" and "after running the idview-apply command". > Typos in output params, should be e.g. "this ID view" Fixed the second and third complaint ( IMHO this is clear from context, but I added "this" to be explicit), I'm not so sure about the first one though. Can we get a native speaker input on that? > > idview_apply.execute: Is there a reason for calling idview_show > instead of get_dn_if_exists? Fixed. > > idview_apply.execute: > failed['hostgroup'].append((hostgroup, str(e))) -- str(e) doesn't > include the name of the exception, which is usually important Fixed. > > Calling a Command (here, host_mod) from another Command is, at the > very least, quite slow, with all the validation and detailed output. > It's also a debugging nightmare when things go wrong. And the > _exc_wrapper is an even worse debugging nightmare. > If you need some functionality in the host plugin that you need, put > it in a function and call that. Otherwise use ldap directly. > > Do we have some precedent for the 'No host was affected.' message? > Consumers of the JSON API shouldn't need to cpecial-case this string. I don't think so, this was just me being over user-friendly. I think we can remove it, and I have done so. > > By subclassing idview_unapply from idview_apply you're violating > Liskov's substitution principle. Make a common base class for them. Done. > > 0259: > show_id_overrides: cn is a MUST attribute in ipa*Override; use > view.single_value['cn'] instead of get(). In enumerate_hosts, is None > okay if cn is missing? This was actually an error, fixed in updated version of patches. New code uses 'ipaanchoruuid' (which is a MUST) and converts it (with your objections addressed.) As for the hosts, the 'cn' attribute is required by the nsHost objectclass. > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0270-ipatests-Add-xmlrpc-tests-for-idviews-plugin.patch Type: text/x-patch Size: 48997 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0268-idviews-Resolve-anchors-to-object-names-in-idview-sh.patch Type: text/x-patch Size: 11025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0267-idviews-Raise-NotFound-errors-if-object-to-override-.patch Type: text/x-patch Size: 1570 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0266-idviews-Change-format-of-IPA-anchor-to-include-domai.patch Type: text/x-patch Size: 2134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0265-idviews-Alter-idoverride-methods-to-work-with-splitt.patch Type: text/x-patch Size: 5021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0264-idviews-Split-the-idoverride-commands-into-iduserove.patch Type: text/x-patch Size: 17677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0263-idviews-Split-the-idoverride-object-into-iduseroverr.patch Type: text/x-patch Size: 6644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0262-idviews-Support-specifying-object-names-instead-of-r.patch Type: text/x-patch Size: 7388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0261-trusts-Add-conversion-from-SID-to-object-name.patch Type: text/x-patch Size: 2997 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0259-2-idviews-Extend-idview-show-command-to-display-assign.patch Type: text/x-patch Size: 8412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0258-2-idviews-Add-ipa-idview-apply-and-idview-unapply-comm.patch Type: text/x-patch Size: 9584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0257-2-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-0256-2-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-0255-2-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-0253-2-idvies-Add-managed-permissions-for-idview-and-idover.patch Type: text/x-patch Size: 4094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0252-2-idviews-Create-basic-idview-plugin-structure.patch Type: text/x-patch Size: 17680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0251-2-ipalib-PEP8-fixes-for-host-plugin.patch Type: text/x-patch Size: 6958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0250-2-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-0249-2-idviews-Add-ipaAssignedIDVIew-reference-to-the-host-.patch Type: text/x-patch Size: 9760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0248-2-idviews-Create-container-for-ID-views-under-cn-accou.patch Type: text/x-patch Size: 1903 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0247-2-idviews-Add-necessary-schema-for-the-ID-views.patch Type: text/x-patch Size: 4697 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 16 11:21:51 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Sep 2014 13:21:51 +0200 Subject: [Freeipa-devel] [PATCH 0269] ipalib: host_del: Extend LDAPDelete's takes_options instead Message-ID: <54181D4F.2090003@redhat.com> Hi, The host-del command did not accept --continue option, since the takes_options was overriden and did not take the options from LDAPDelete. Fix the behaviour. https://fedorahosted.org/freeipa/ticket/4473 -- 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-0269-ipalib-host_del-Extend-LDAPDelete-s-takes_options-in.patch Type: text/x-patch Size: 2686 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 16 12:46:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Sep 2014 14:46:11 +0200 Subject: [Freeipa-devel] [PATCH 0269] ipalib: host_del: Extend LDAPDelete's takes_options instead In-Reply-To: <54181D4F.2090003@redhat.com> References: <54181D4F.2090003@redhat.com> Message-ID: <54183113.9030708@redhat.com> Dne 16.9.2014 v 13:21 Tomas Babej napsal(a): > Hi, > > The host-del command did not accept --continue option, since the > takes_options was overriden and did not take the options from LDAPDelete. > > Fix the behaviour. > > https://fedorahosted.org/freeipa/ticket/4473 ACK. -- Jan Cholasta From dkupka at redhat.com Tue Sep 16 13:59:54 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 16 Sep 2014 15:59:54 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54132C35.6080004@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> Message-ID: <5418425A.4040509@redhat.com> On 09/12/2014 07:24 PM, Martin Basti wrote: > > > Be careful, reviewed on friday! :-) > > 1) > whitespace error + pep8 error > patch:76: trailing whitespace. > # there is reverse zone for every ip address > warning: 1 line adds whitespace errors. > > ./ipaserver/install/bindinstance.py:640:9: E265 block comment should > start with '# ' > Stupid mistake, sorry. > > 2) (server install) > + for ip in ip_addresses: > + for rev_zone in reverse_zones: > + if bindinstance.verify_reverse_zone(rev_zone, str(ip)): > + break > + else: > + sys.exit(1) > > Please add there error message instead 1 to exit function You are right, it's better to say what's wrong. > > 3) (server install) > Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): > IMHO this will cause errors (not tested) try: > rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] > ip_addreses: [10.10.10.1, 172.16.0.1] > > it should be any() of zone can handle ip I indented the else branch more that I wanted. > > 4) (replica-install) > I'm not sure about behavior of combination ip addresses, and reverse zones, > In original code, if user specify reverse zone, the ip address must match. > > In patched version, you just add new zones for ip-addresses which > doesn't math the user zones. > > IMO we should check if all addresses belongs to user specified zones, > otherwise raise an error. > But I'm open to suggestions. The behavior now basically is: Check if IP address matches any specified zone a. if yes we are good b. else search if there is existing zone that can be used ba. if yes we are good bb. else ask user for zone or create default if --unattended > > 5) > Code for ipa-replica-install, and ipa-server-install, differs in parts > where we expecting same behavior > - ip addresses and reverse zones The behavoir now should be almost the same. The only difference is that when installing replica we need to search for existing reverse zones as they could be added during on another server. > > 6) > + # there is at > least one ip address in every zone > + if options.reverse_zones: > + for reverse_zone in options.reverse_zones: > + for ip in config.ips: > <---------------------------------------------------------------------------------- > A > + if bindinstance.verify_reverse_zone(reverse_zone, ip): > + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) > + break > + else: > + sys.exit(1) > <------------------------------------------------------------------------------------------------* > + # there is reverse zone for every ip address > + for ip in config.ips: > + for reverse_zone in options.reverse_zones: > <------------------------------------------------------- B > + if bindinstance.verify_reverse_zone(reverse_zone, ip): > + if reverse_zone not in reverse_zones: > + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) > + break > + else: > <------------------------------------------------------------------------------------------------------------ > C > + reverse_zone = bindinstance.find_reverse_zone(ip) > + if reverse_zone is None and not options.no_reverse: > + reverse_zone = util.get_reverse_zone_default(ip) > <----------------------------------------- D1 > + if not options.unattended and > bindinstance.create_reverse(): <------------------------- D > + reverse_zone = > bindinstance.read_reverse_zone(reverse_zone, ip) > + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) > <------------- D2 > > You added all possible zones in step A, B step is not needed. > If user doesn't specify reverse_zones you can just jump to C step > *add error message > C: elif not options.no_reverse > D: you asked user if wants to create zone, but you don't care about > answer, and in step D2 append zone from D1 > note: --no-reverse and --reverse-zones cant be used together, you can > use it in new code, test it before cycle Rewritten. > > 7) > # Always use force=True as named is not set up yet > add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, > - ns_hostname=api.env.host, > ns_ip_address=nameserver_ip_address, > - force=True) > + ns_hostname=api.env.host, ns_ip_address=None, force=True) > + #for ns_ip_address in nameserver_ip_address: > + # add_zone(self.domain, self.zonemgr, > dns_backup=self.dns_backup, > + # ns_hostname=api.env.host, ns_ip_address=ns_ip_address, > + # force=True) > > Please remove commented section I forget to clean the trash, thanks. > > You can remove 'ns_ip_address=None' from function > > 8) > + if set(options.ip_addresses) <= set(ips): > + ips = options.ip_addresses > + else: > + print >>sys.stderr, "Error: the hostname resolves to an > IP address that is different" > + print >>sys.stderr, "from the one provided on the > command line. Please fix your DNS" > + print >>sys.stderr, "or /etc/hosts file and restart the > installation." > + sys.exit(1) > > Could you write those extra addresses to output? We need to improve > usability of our error messages > > UX is the king :) > -- > Martin Basti > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-6-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 37732 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-6-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 37869 bytes Desc: not available URL: From npmccallum at redhat.com Tue Sep 16 15:26:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 11:26:26 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1408482648.3505.8.camel@redhat.com> References: <1408482648.3505.8.camel@redhat.com> Message-ID: <1410881186.3889.7.camel@redhat.com> On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > 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? Nobody has responded to this. :) However, since investigating it a bit more, this approach won't really work without further effort. Here is the problem. First, the UUID plugin doesn't currently support this kind of operation. Either it needs to be modified or a new plugin needs to be created. Second, the client needs to know the ID in order to generate the token URI. If we generate the UUID inside the DS, the UUID is unknown to the client and the URI can't be generated. This would mean a new control. As I see it we have three options: 1. Remove the option to specify the ipatokenUniqueID from the GUI. Don't make any change in the CLI. ENFORCEMENT: none EFFORT: low 2. Perform a server-side check for admin membership. Raise an exception if the ipatokenUniqueID is specified and the user is not an admin. ENFORCEMENT: API-level EFFORT: medium 3. Modify otptoken-add to create tokens with a magical ipatokenUniqueID value by default. An ACI would prevent normal users from adding tokens without this magic value. Create/modify a plugin to generate UUIDs when the magic value is found. Send a control back to the client indicating the real ipatokenUniqueID value. Modify otptoken-add to read this control. ENFORCEMENT: DS-level EFFORT: high I think my preference for now is #1. Thoughts? Nathaniel From pvoborni at redhat.com Tue Sep 16 15:51:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 16 Sep 2014 17:51:16 +0200 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1410881186.3889.7.camel@redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> Message-ID: <54185C74.7090204@redhat.com> On 16.9.2014 17:26, Nathaniel McCallum wrote: > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: >> 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? > > Nobody has responded to this. :) > > However, since investigating it a bit more, this approach won't really > work without further effort. Here is the problem. > > First, the UUID plugin doesn't currently support this kind of operation. > Either it needs to be modified or a new plugin needs to be created. > > Second, the client needs to know the ID in order to generate the token > URI. If we generate the UUID inside the DS, the UUID is unknown to the > client and the URI can't be generated. This would mean a new control. > > As I see it we have three options: > 1. Remove the option to specify the ipatokenUniqueID from the GUI. Don't > make any change in the CLI. > > ENFORCEMENT: none > EFFORT: low > > 2. Perform a server-side check for admin membership. Raise an exception > if the ipatokenUniqueID is specified and the user is not an admin. > > ENFORCEMENT: API-level > EFFORT: medium > > 3. Modify otptoken-add to create tokens with a magical ipatokenUniqueID > value by default. An ACI would prevent normal users from adding tokens > without this magic value. Create/modify a plugin to generate UUIDs when > the magic value is found. Send a control back to the client indicating > the real ipatokenUniqueID value. Modify otptoken-add to read this > control. > > ENFORCEMENT: DS-level > EFFORT: high > > I think my preference for now is #1. Thoughts? > > Nathaniel > I want to raise a question if we really want to disable this feature for normal users. Wouldn't it be better to improve error message or check if the name is taken? UUID is the value which is displayed in the Soft. Token application as name. Sure, one can rename it there to match the description in IPA but that seems quite unpleasant to me. Also user has to know that he can rename the token in FreeOTP,.... Atm the existence check might be little problematic - disclose of information which is not readable to user by default. But current state is basically it, just unfriendly. -- Petr Vobornik From npmccallum at redhat.com Tue Sep 16 15:52:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 11:52:43 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <54185C74.7090204@redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> Message-ID: <1410882763.3889.8.camel@redhat.com> On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > >> 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? > > > > Nobody has responded to this. :) > > > > However, since investigating it a bit more, this approach won't really > > work without further effort. Here is the problem. > > > > First, the UUID plugin doesn't currently support this kind of operation. > > Either it needs to be modified or a new plugin needs to be created. > > > > Second, the client needs to know the ID in order to generate the token > > URI. If we generate the UUID inside the DS, the UUID is unknown to the > > client and the URI can't be generated. This would mean a new control. > > > > As I see it we have three options: > > 1. Remove the option to specify the ipatokenUniqueID from the GUI. Don't > > make any change in the CLI. > > > > ENFORCEMENT: none > > EFFORT: low > > > > 2. Perform a server-side check for admin membership. Raise an exception > > if the ipatokenUniqueID is specified and the user is not an admin. > > > > ENFORCEMENT: API-level > > EFFORT: medium > > > > 3. Modify otptoken-add to create tokens with a magical ipatokenUniqueID > > value by default. An ACI would prevent normal users from adding tokens > > without this magic value. Create/modify a plugin to generate UUIDs when > > the magic value is found. Send a control back to the client indicating > > the real ipatokenUniqueID value. Modify otptoken-add to read this > > control. > > > > ENFORCEMENT: DS-level > > EFFORT: high > > > > I think my preference for now is #1. Thoughts? > > > > Nathaniel > > > > I want to raise a question if we really want to disable this feature for > normal users. Wouldn't it be better to improve error message or check if > the name is taken? > > UUID is the value which is displayed in the Soft. Token application as > name. Sure, one can rename it there to match the description in IPA but > that seems quite unpleasant to me. Also user has to know that he can > rename the token in FreeOTP,.... > > Atm the existence check might be little problematic - disclose of > information which is not readable to user by default. But current state > is basically it, just unfriendly. The existence check is impossible: users can't see tokens they don't own. From mbasti at redhat.com Tue Sep 16 16:09:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Sep 2014 18:09:51 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5418425A.4040509@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> Message-ID: <541860CF.20109@redhat.com> On 16/09/14 15:59, David Kupka wrote: > On 09/12/2014 07:24 PM, Martin Basti wrote: >> >> >> Be careful, reviewed on friday! :-) >> >> 1) >> whitespace error + pep8 error >> patch:76: trailing whitespace. >> # there is reverse zone for every ip address >> warning: 1 line adds whitespace errors. >> >> ./ipaserver/install/bindinstance.py:640:9: E265 block comment should >> start with '# ' >> > > Stupid mistake, sorry. > >> >> 2) (server install) >> + for ip in ip_addresses: >> + for rev_zone in reverse_zones: >> + if bindinstance.verify_reverse_zone(rev_zone, str(ip)): >> + break >> + else: >> + sys.exit(1) >> >> Please add there error message instead 1 to exit function > > You are right, it's better to say what's wrong. > >> >> 3) (server install) >> Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): >> IMHO this will cause errors (not tested) try: >> rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] >> ip_addreses: [10.10.10.1, 172.16.0.1] >> >> it should be any() of zone can handle ip > > I indented the else branch more that I wanted. > >> >> 4) (replica-install) >> I'm not sure about behavior of combination ip addresses, and reverse >> zones, >> In original code, if user specify reverse zone, the ip address must >> match. >> >> In patched version, you just add new zones for ip-addresses which >> doesn't math the user zones. >> >> IMO we should check if all addresses belongs to user specified zones, >> otherwise raise an error. >> But I'm open to suggestions. > > The behavior now basically is: > > Check if IP address matches any specified zone > a. if yes we are good > b. else search if there is existing zone that can be used > ba. if yes we are good > bb. else ask user for zone or create default if --unattended > >> >> 5) >> Code for ipa-replica-install, and ipa-server-install, differs in parts >> where we expecting same behavior >> - ip addresses and reverse zones > > The behavoir now should be almost the same. The only difference is > that when installing replica we need to search for existing reverse > zones as they could be added during on another server. > >> >> 6) >> + # there is at >> least one ip address in every zone >> + if options.reverse_zones: >> + for reverse_zone in options.reverse_zones: >> + for ip in config.ips: >> <---------------------------------------------------------------------------------- >> >> A >> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >> + break >> + else: >> + sys.exit(1) >> <------------------------------------------------------------------------------------------------* >> >> + # there is reverse zone for every ip address >> + for ip in config.ips: >> + for reverse_zone in options.reverse_zones: >> <------------------------------------------------------- B >> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >> + if reverse_zone not in reverse_zones: >> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >> + break >> + else: >> <------------------------------------------------------------------------------------------------------------ >> >> C >> + reverse_zone = bindinstance.find_reverse_zone(ip) >> + if reverse_zone is None and not options.no_reverse: >> + reverse_zone = util.get_reverse_zone_default(ip) >> <----------------------------------------- D1 >> + if not options.unattended and >> bindinstance.create_reverse(): <------------------------- D >> + reverse_zone = >> bindinstance.read_reverse_zone(reverse_zone, ip) >> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >> <------------- D2 >> >> You added all possible zones in step A, B step is not needed. >> If user doesn't specify reverse_zones you can just jump to C step >> *add error message >> C: elif not options.no_reverse >> D: you asked user if wants to create zone, but you don't care about >> answer, and in step D2 append zone from D1 >> note: --no-reverse and --reverse-zones cant be used together, you can >> use it in new code, test it before cycle > > Rewritten. > >> >> 7) >> # Always use force=True as named is not set up yet >> add_zone(self.domain, self.zonemgr, >> dns_backup=self.dns_backup, >> - ns_hostname=api.env.host, >> ns_ip_address=nameserver_ip_address, >> - force=True) >> + ns_hostname=api.env.host, ns_ip_address=None, >> force=True) >> + #for ns_ip_address in nameserver_ip_address: >> + # add_zone(self.domain, self.zonemgr, >> dns_backup=self.dns_backup, >> + # ns_hostname=api.env.host, >> ns_ip_address=ns_ip_address, >> + # force=True) >> >> Please remove commented section > > I forget to clean the trash, thanks. > >> >> You can remove 'ns_ip_address=None' from function >> >> 8) >> + if set(options.ip_addresses) <= set(ips): >> + ips = options.ip_addresses >> + else: >> + print >>sys.stderr, "Error: the hostname resolves to an >> IP address that is different" >> + print >>sys.stderr, "from the one provided on the >> command line. Please fix your DNS" >> + print >>sys.stderr, "or /etc/hosts file and restart the >> installation." >> + sys.exit(1) >> >> Could you write those extra addresses to output? We need to improve >> usability of our error messages >> >> > > UX is the king :) > >> -- >> Martin Basti >> > Thank you for patch. 1) + if not options.no_reverse: + # check that there is reverse zone for every IP + if options.unattended: + for ip in config.ip_addresses: + if bindinstance.find_reverse_zone(str(ip)): + # reverse zone is already in LDAP + continue + for rz in reverse_zones: + if bindinstance.verify_reverse_zone(rz, ip): + # reverse zone is entered by user + break + else: + rz = util.get_reverse_zone_default(str(ip)) + reverse_zones.append(rz) + elif options.reverse_zones or (not(options.no_reverse) and bindinstance.create_reverse()): -----------------------------------------------------^^^^^ There is double check of "options.no_reverse", you are in block inside if not options.no_reverse, so not(options.no_reverse) is always True 2) + # check that there is IP address in every reverse zone + if options.reverse_zones: + for rz in options.reverse_zones: + for ip in config.ip_addresses: + if bindinstance.verify_reverse_zone(rz, ip): + reverse_zones.append(bindinstance.normalize_zone(rz)) + break + else: + sys.exit("There is no IP address matching reverze_zone %s." % rz) + if not options.no_reverse: + # check that there is reverse zone for every IP + if options.unattended: + for ip in config.ip_addresses: + if bindinstance.find_reverse_zone(str(ip)): + # reverse zone is already in LDAP + continue + for rz in reverse_zones: + if bindinstance.verify_reverse_zone(rz, ip): + # reverse zone is entered by user + break + else: + rz = util.get_reverse_zone_default(str(ip)) + reverse_zones.append(rz) + elif options.reverse_zones or (not(options.no_reverse) and bindinstance.create_reverse()): + for ip in config.ip_addresses: + if bindinstance.find_reverse_zone(str(ip)): + # reverse zone is already in LDAP + continue + for rz in reverse_zones: + if bindinstance.verify_reverse_zone(rz, ip): + # reverse zone is entered by user + break + else: + rz = util.get_reverse_zone_default(str(ip)) + rz = bindinstance.read_reverse_zone(rz, str(ip)) + reverse_zones.append(rz) + else: + options.no_reverse = True + reverse_zones = [] Code above is duplicated in replica-install and server-install, with small difference, could you put it inside function, for example into bindinstance module? Also there are duplicated parts inside in if and elif code block, could you add it to one function as well? Example: def check_ip_reversezones(...., unattended=False, try_to_find_zone = False): reverse_zones = [] if options['reverse_zones']....#check reverse zones if not unattended and not bindinstance.create_reverse(): # user doesn't want to create additional reverse zones return reverse_zones for ip in config.ip_addresses: if try_to_find_zone and bindinstance.find_reverse_zone(str(ip)): # reverse zone is already in LDAP continue for rz in reverse_zones: if bindinstance.verify_reverse_zone(rz, ip): # reverse zone is entered by user break else: rz = util.get_reverse_zone_default(str(ip)) if not unattended: rz = bindinstance.read_reverse_zone(rz, str(ip)) reverse_zones.append(rz) 3) + elif options.reverse_zones or (not(options.no_reverse) and bindinstance.create_reverse()): OR operator, this will create additional zones (non-specified by user) even if user write NO 4) IF user specify zone 10.in-addr.arpa, and ip addresses 10.0.0.1, 192.168.1.1, and answer to not create additional zones, how is this case handled? -- Martin Basti From ssorce at redhat.com Tue Sep 16 16:22:18 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2014 12:22:18 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1410882763.3889.8.camel@redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> Message-ID: <20140916122218.786ca568@willson.usersys.redhat.com> On Tue, 16 Sep 2014 11:52:43 -0400 Nathaniel McCallum wrote: > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > > >> 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? > > > > > > Nobody has responded to this. :) > > > > > > However, since investigating it a bit more, this approach won't > > > really work without further effort. Here is the problem. > > > > > > First, the UUID plugin doesn't currently support this kind of > > > operation. Either it needs to be modified or a new plugin needs > > > to be created. > > > > > > Second, the client needs to know the ID in order to generate the > > > token URI. If we generate the UUID inside the DS, the UUID is > > > unknown to the client and the URI can't be generated. This would > > > mean a new control. > > > > > > As I see it we have three options: > > > 1. Remove the option to specify the ipatokenUniqueID from the > > > GUI. Don't make any change in the CLI. > > > > > > ENFORCEMENT: none > > > EFFORT: low > > > > > > 2. Perform a server-side check for admin membership. Raise an > > > exception if the ipatokenUniqueID is specified and the user is > > > not an admin. > > > > > > ENFORCEMENT: API-level > > > EFFORT: medium > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > ipatokenUniqueID value by default. An ACI would prevent normal > > > users from adding tokens without this magic value. Create/modify > > > a plugin to generate UUIDs when the magic value is found. Send a > > > control back to the client indicating the real ipatokenUniqueID > > > value. Modify otptoken-add to read this control. > > > > > > ENFORCEMENT: DS-level > > > EFFORT: high > > > > > > I think my preference for now is #1. Thoughts? > > > > > > Nathaniel > > > > > > > I want to raise a question if we really want to disable this > > feature for normal users. Wouldn't it be better to improve error > > message or check if the name is taken? > > > > UUID is the value which is displayed in the Soft. Token application > > as name. Sure, one can rename it there to match the description in > > IPA but that seems quite unpleasant to me. Also user has to know > > that he can rename the token in FreeOTP,.... > > > > Atm the existence check might be little problematic - disclose of > > information which is not readable to user by default. But current > > state is basically it, just unfriendly. > > The existence check is impossible: users can't see tokens they don't > own. Why don't we simply allow user to use an arbitrary name of their choosing (or a random string if not specified) and then append their uid string to it in the UI ? I wonder if we have ACIs where the value must match a pattern defined by the bound user ... Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Sep 16 16:23:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 12:23:51 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20140916122218.786ca568@willson.usersys.redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> <20140916122218.786ca568@willson.usersys.redhat.com> Message-ID: <1410884631.3889.9.camel@redhat.com> On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote: > On Tue, 16 Sep 2014 11:52:43 -0400 > Nathaniel McCallum wrote: > > > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > > > >> 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? > > > > > > > > Nobody has responded to this. :) > > > > > > > > However, since investigating it a bit more, this approach won't > > > > really work without further effort. Here is the problem. > > > > > > > > First, the UUID plugin doesn't currently support this kind of > > > > operation. Either it needs to be modified or a new plugin needs > > > > to be created. > > > > > > > > Second, the client needs to know the ID in order to generate the > > > > token URI. If we generate the UUID inside the DS, the UUID is > > > > unknown to the client and the URI can't be generated. This would > > > > mean a new control. > > > > > > > > As I see it we have three options: > > > > 1. Remove the option to specify the ipatokenUniqueID from the > > > > GUI. Don't make any change in the CLI. > > > > > > > > ENFORCEMENT: none > > > > EFFORT: low > > > > > > > > 2. Perform a server-side check for admin membership. Raise an > > > > exception if the ipatokenUniqueID is specified and the user is > > > > not an admin. > > > > > > > > ENFORCEMENT: API-level > > > > EFFORT: medium > > > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > > ipatokenUniqueID value by default. An ACI would prevent normal > > > > users from adding tokens without this magic value. Create/modify > > > > a plugin to generate UUIDs when the magic value is found. Send a > > > > control back to the client indicating the real ipatokenUniqueID > > > > value. Modify otptoken-add to read this control. > > > > > > > > ENFORCEMENT: DS-level > > > > EFFORT: high > > > > > > > > I think my preference for now is #1. Thoughts? > > > > > > > > Nathaniel > > > > > > > > > > I want to raise a question if we really want to disable this > > > feature for normal users. Wouldn't it be better to improve error > > > message or check if the name is taken? > > > > > > UUID is the value which is displayed in the Soft. Token application > > > as name. Sure, one can rename it there to match the description in > > > IPA but that seems quite unpleasant to me. Also user has to know > > > that he can rename the token in FreeOTP,.... > > > > > > Atm the existence check might be little problematic - disclose of > > > information which is not readable to user by default. But current > > > state is basically it, just unfriendly. > > > > The existence check is impossible: users can't see tokens they don't > > own. > > Why don't we simply allow user to use an arbitrary name of their > choosing (or a random string if not specified) and then append their > uid string to it in the UI ? > > I wonder if we have ACIs where the value must match a pattern defined > by the bound user ... This would present a strange scenario where a token is created and then reassigned to another user. Nathaniel From ssorce at redhat.com Tue Sep 16 16:28:46 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2014 12:28:46 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1410884631.3889.9.camel@redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> <20140916122218.786ca568@willson.usersys.redhat.com> <1410884631.3889.9.camel@redhat.com> Message-ID: <20140916122846.2f276eb0@willson.usersys.redhat.com> On Tue, 16 Sep 2014 12:23:51 -0400 Nathaniel McCallum wrote: > On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote: > > On Tue, 16 Sep 2014 11:52:43 -0400 > > Nathaniel McCallum wrote: > > > > > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > > > > >> 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? > > > > > > > > > > Nobody has responded to this. :) > > > > > > > > > > However, since investigating it a bit more, this approach > > > > > won't really work without further effort. Here is the problem. > > > > > > > > > > First, the UUID plugin doesn't currently support this kind of > > > > > operation. Either it needs to be modified or a new plugin > > > > > needs to be created. > > > > > > > > > > Second, the client needs to know the ID in order to generate > > > > > the token URI. If we generate the UUID inside the DS, the > > > > > UUID is unknown to the client and the URI can't be generated. > > > > > This would mean a new control. > > > > > > > > > > As I see it we have three options: > > > > > 1. Remove the option to specify the ipatokenUniqueID from the > > > > > GUI. Don't make any change in the CLI. > > > > > > > > > > ENFORCEMENT: none > > > > > EFFORT: low > > > > > > > > > > 2. Perform a server-side check for admin membership. Raise an > > > > > exception if the ipatokenUniqueID is specified and the user is > > > > > not an admin. > > > > > > > > > > ENFORCEMENT: API-level > > > > > EFFORT: medium > > > > > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > > > ipatokenUniqueID value by default. An ACI would prevent normal > > > > > users from adding tokens without this magic value. > > > > > Create/modify a plugin to generate UUIDs when the magic value > > > > > is found. Send a control back to the client indicating the > > > > > real ipatokenUniqueID value. Modify otptoken-add to read this > > > > > control. > > > > > > > > > > ENFORCEMENT: DS-level > > > > > EFFORT: high > > > > > > > > > > I think my preference for now is #1. Thoughts? > > > > > > > > > > Nathaniel > > > > > > > > > > > > > I want to raise a question if we really want to disable this > > > > feature for normal users. Wouldn't it be better to improve error > > > > message or check if the name is taken? > > > > > > > > UUID is the value which is displayed in the Soft. Token > > > > application as name. Sure, one can rename it there to match the > > > > description in IPA but that seems quite unpleasant to me. Also > > > > user has to know that he can rename the token in FreeOTP,.... > > > > > > > > Atm the existence check might be little problematic - disclose > > > > of information which is not readable to user by default. But > > > > current state is basically it, just unfriendly. > > > > > > The existence check is impossible: users can't see tokens they > > > don't own. > > > > Why don't we simply allow user to use an arbitrary name of their > > choosing (or a random string if not specified) and then append their > > uid string to it in the UI ? > > > > I wonder if we have ACIs where the value must match a pattern > > defined by the bound user ... > > This would present a strange scenario where a token is created and > then reassigned to another user. The idea is to strip away the tail when visualizing to the user, so it wouldn't really bee seen ? Or perhaps the token can simply be renamed when assigned. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Sep 16 16:33:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 12:33:16 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20140916122846.2f276eb0@willson.usersys.redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> <20140916122218.786ca568@willson.usersys.redhat.com> <1410884631.3889.9.camel@redhat.com> <20140916122846.2f276eb0@willson.usersys.redhat.com> Message-ID: <1410885196.3889.11.camel@redhat.com> On Tue, 2014-09-16 at 12:28 -0400, Simo Sorce wrote: > On Tue, 16 Sep 2014 12:23:51 -0400 > Nathaniel McCallum wrote: > > > On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote: > > > On Tue, 16 Sep 2014 11:52:43 -0400 > > > Nathaniel McCallum wrote: > > > > > > > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > > > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote: > > > > > >> 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? > > > > > > > > > > > > Nobody has responded to this. :) > > > > > > > > > > > > However, since investigating it a bit more, this approach > > > > > > won't really work without further effort. Here is the problem. > > > > > > > > > > > > First, the UUID plugin doesn't currently support this kind of > > > > > > operation. Either it needs to be modified or a new plugin > > > > > > needs to be created. > > > > > > > > > > > > Second, the client needs to know the ID in order to generate > > > > > > the token URI. If we generate the UUID inside the DS, the > > > > > > UUID is unknown to the client and the URI can't be generated. > > > > > > This would mean a new control. > > > > > > > > > > > > As I see it we have three options: > > > > > > 1. Remove the option to specify the ipatokenUniqueID from the > > > > > > GUI. Don't make any change in the CLI. > > > > > > > > > > > > ENFORCEMENT: none > > > > > > EFFORT: low > > > > > > > > > > > > 2. Perform a server-side check for admin membership. Raise an > > > > > > exception if the ipatokenUniqueID is specified and the user is > > > > > > not an admin. > > > > > > > > > > > > ENFORCEMENT: API-level > > > > > > EFFORT: medium > > > > > > > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > > > > ipatokenUniqueID value by default. An ACI would prevent normal > > > > > > users from adding tokens without this magic value. > > > > > > Create/modify a plugin to generate UUIDs when the magic value > > > > > > is found. Send a control back to the client indicating the > > > > > > real ipatokenUniqueID value. Modify otptoken-add to read this > > > > > > control. > > > > > > > > > > > > ENFORCEMENT: DS-level > > > > > > EFFORT: high > > > > > > > > > > > > I think my preference for now is #1. Thoughts? > > > > > > > > > > > > Nathaniel > > > > > > > > > > > > > > > > I want to raise a question if we really want to disable this > > > > > feature for normal users. Wouldn't it be better to improve error > > > > > message or check if the name is taken? > > > > > > > > > > UUID is the value which is displayed in the Soft. Token > > > > > application as name. Sure, one can rename it there to match the > > > > > description in IPA but that seems quite unpleasant to me. Also > > > > > user has to know that he can rename the token in FreeOTP,.... > > > > > > > > > > Atm the existence check might be little problematic - disclose > > > > > of information which is not readable to user by default. But > > > > > current state is basically it, just unfriendly. > > > > > > > > The existence check is impossible: users can't see tokens they > > > > don't own. > > > > > > Why don't we simply allow user to use an arbitrary name of their > > > choosing (or a random string if not specified) and then append their > > > uid string to it in the UI ? > > > > > > I wonder if we have ACIs where the value must match a pattern > > > defined by the bound user ... > > > > This would present a strange scenario where a token is created and > > then reassigned to another user. > > > The idea is to strip away the tail when visualizing to the user, so it > wouldn't really bee seen ? > Or perhaps the token can simply be renamed when assigned. It just feels like a kludge to me. Also, automated stripping may run afoul of names assigned by the imports. What is wrong with the three options I provided above? We can do #1 now and #2 or #3 later. From ssorce at redhat.com Tue Sep 16 16:52:30 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2014 12:52:30 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1410885196.3889.11.camel@redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> <20140916122218.786ca568@willson.usersys.redhat.com> <1410884631.3889.9.camel@redhat.com> <20140916122846.2f276eb0@willson.usersys.redhat.com> <1410885196.3889.11.camel@redhat.com> Message-ID: <20140916125230.06701439@willson.usersys.redhat.com> On Tue, 16 Sep 2014 12:33:16 -0400 Nathaniel McCallum wrote: > On Tue, 2014-09-16 at 12:28 -0400, Simo Sorce wrote: > > On Tue, 16 Sep 2014 12:23:51 -0400 > > Nathaniel McCallum wrote: > > > > > On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote: > > > > On Tue, 16 Sep 2014 11:52:43 -0400 > > > > Nathaniel McCallum wrote: > > > > > > > > > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > > > > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > > > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum > > > > > > > wrote: > > > > > > >> 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? > > > > > > > > > > > > > > Nobody has responded to this. :) > > > > > > > > > > > > > > However, since investigating it a bit more, this approach > > > > > > > won't really work without further effort. Here is the > > > > > > > problem. > > > > > > > > > > > > > > First, the UUID plugin doesn't currently support this > > > > > > > kind of operation. Either it needs to be modified or a > > > > > > > new plugin needs to be created. > > > > > > > > > > > > > > Second, the client needs to know the ID in order to > > > > > > > generate the token URI. If we generate the UUID inside > > > > > > > the DS, the UUID is unknown to the client and the URI > > > > > > > can't be generated. This would mean a new control. > > > > > > > > > > > > > > As I see it we have three options: > > > > > > > 1. Remove the option to specify the ipatokenUniqueID from > > > > > > > the GUI. Don't make any change in the CLI. > > > > > > > > > > > > > > ENFORCEMENT: none > > > > > > > EFFORT: low > > > > > > > > > > > > > > 2. Perform a server-side check for admin membership. > > > > > > > Raise an exception if the ipatokenUniqueID is specified > > > > > > > and the user is not an admin. > > > > > > > > > > > > > > ENFORCEMENT: API-level > > > > > > > EFFORT: medium > > > > > > > > > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > > > > > ipatokenUniqueID value by default. An ACI would prevent > > > > > > > normal users from adding tokens without this magic value. > > > > > > > Create/modify a plugin to generate UUIDs when the magic > > > > > > > value is found. Send a control back to the client > > > > > > > indicating the real ipatokenUniqueID value. Modify > > > > > > > otptoken-add to read this control. > > > > > > > > > > > > > > ENFORCEMENT: DS-level > > > > > > > EFFORT: high > > > > > > > > > > > > > > I think my preference for now is #1. Thoughts? > > > > > > > > > > > > > > Nathaniel > > > > > > > > > > > > > > > > > > > I want to raise a question if we really want to disable this > > > > > > feature for normal users. Wouldn't it be better to improve > > > > > > error message or check if the name is taken? > > > > > > > > > > > > UUID is the value which is displayed in the Soft. Token > > > > > > application as name. Sure, one can rename it there to match > > > > > > the description in IPA but that seems quite unpleasant to > > > > > > me. Also user has to know that he can rename the token in > > > > > > FreeOTP,.... > > > > > > > > > > > > Atm the existence check might be little problematic - > > > > > > disclose of information which is not readable to user by > > > > > > default. But current state is basically it, just unfriendly. > > > > > > > > > > The existence check is impossible: users can't see tokens they > > > > > don't own. > > > > > > > > Why don't we simply allow user to use an arbitrary name of their > > > > choosing (or a random string if not specified) and then append > > > > their uid string to it in the UI ? > > > > > > > > I wonder if we have ACIs where the value must match a pattern > > > > defined by the bound user ... > > > > > > This would present a strange scenario where a token is created and > > > then reassigned to another user. > > > > > > The idea is to strip away the tail when visualizing to the user, so > > it wouldn't really bee seen ? > > Or perhaps the token can simply be renamed when assigned. > > It just feels like a kludge to me. Also, automated stripping may run > afoul of names assigned by the imports. > > What is wrong with the three options I provided above? We can do #1 > now and #2 or #3 later. Nothing wrong, really, #1 is fine by me. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Sep 16 17:24:17 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 16 Sep 2014 19:24:17 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1410807911.4238.6.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> Message-ID: <54187241.4000202@redhat.com> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: > This plugin ensures that all counter/watermark operations are atomic > and never decrement. Also, deletion is not permitted. > > https://fedorahosted.org/freeipa/ticket/4494 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Starting looking at it, I have just a question about sanitize_input. If the modification (replace) is related to counter/watermark, it triggers an internal search on the target entry itself. The original/modified entry is also present in the pblock. The internal search will check the filter but except that what is the benefit vs taking the entry directly in the pblock. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Tue Sep 16 17:25:58 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 13:25:58 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54187241.4000202@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54187241.4000202@redhat.com> Message-ID: <1410888358.3889.13.camel@redhat.com> On Tue, 2014-09-16 at 19:24 +0200, thierry bordaz wrote: > On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: > > > This plugin ensures that all counter/watermark operations are atomic > > and never decrement. Also, deletion is not permitted. > > > > https://fedorahosted.org/freeipa/ticket/4494 > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello Nathaniel, > > Starting looking at it, I have just a question about > sanitize_input. > If the modification (replace) is related to counter/watermark, > it triggers an internal search on the target entry itself. > The original/modified entry is also present in the pblock. The > internal search will check the filter but except that what is > the benefit vs > taking the entry directly in the pblock. I didn't know the entry was already in the pblock. What loads it? And when? How do I access it? Nathaniel From npmccallum at redhat.com Tue Sep 16 17:32:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 13:32:23 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID Message-ID: <1410888743.3889.15.camel@redhat.com> We perform this enforcement at the API level since: * DS level enforcement would be difficult * ipatokenUniqueID generation already happens at the API level It may be nice in the future to perform enforcement in the DS itself. However, the question of the location of enforcement is largely an aesthetic issue. https://fedorahosted.org/freeipa/ticket/4456 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0065-Don-t-allow-users-to-create-tokens-with-a-specified-.patch Type: text/x-patch Size: 1763 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 16 17:32:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Sep 2014 19:32:39 +0200 Subject: [Freeipa-devel] [PATCH] [dyndb] Fix error handling in configure_view() to prevent deadlocks Message-ID: <54187437.3040604@redhat.com> Hello, attached patches fix https://bugzilla.redhat.com/show_bug.cgi?id=1142150 https://bugzilla.redhat.com/show_bug.cgi?id=1142152 ... and improve related error messages. I will push it to https://github.com/spacekpe/bind-dynamic_db if you are okay with it. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-error-handling-in-configure_view-to-prevent-dead.patch Type: text/x-patch Size: 3379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Log-error-if-dynamic-database-configuration-failed.patch Type: text/x-patch Size: 1020 bytes Desc: not available URL: From npmccallum at redhat.com Tue Sep 16 17:35:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 16 Sep 2014 13:35:18 -0400 Subject: [Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20140916125230.06701439@willson.usersys.redhat.com> References: <1408482648.3505.8.camel@redhat.com> <1410881186.3889.7.camel@redhat.com> <54185C74.7090204@redhat.com> <1410882763.3889.8.camel@redhat.com> <20140916122218.786ca568@willson.usersys.redhat.com> <1410884631.3889.9.camel@redhat.com> <20140916122846.2f276eb0@willson.usersys.redhat.com> <1410885196.3889.11.camel@redhat.com> <20140916125230.06701439@willson.usersys.redhat.com> Message-ID: <1410888918.3889.17.camel@redhat.com> On Tue, 2014-09-16 at 12:52 -0400, Simo Sorce wrote: > On Tue, 16 Sep 2014 12:33:16 -0400 > Nathaniel McCallum wrote: > > > On Tue, 2014-09-16 at 12:28 -0400, Simo Sorce wrote: > > > On Tue, 16 Sep 2014 12:23:51 -0400 > > > Nathaniel McCallum wrote: > > > > > > > On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote: > > > > > On Tue, 16 Sep 2014 11:52:43 -0400 > > > > > Nathaniel McCallum wrote: > > > > > > > > > > > On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote: > > > > > > > On 16.9.2014 17:26, Nathaniel McCallum wrote: > > > > > > > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum > > > > > > > > wrote: > > > > > > > >> 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? > > > > > > > > > > > > > > > > Nobody has responded to this. :) > > > > > > > > > > > > > > > > However, since investigating it a bit more, this approach > > > > > > > > won't really work without further effort. Here is the > > > > > > > > problem. > > > > > > > > > > > > > > > > First, the UUID plugin doesn't currently support this > > > > > > > > kind of operation. Either it needs to be modified or a > > > > > > > > new plugin needs to be created. > > > > > > > > > > > > > > > > Second, the client needs to know the ID in order to > > > > > > > > generate the token URI. If we generate the UUID inside > > > > > > > > the DS, the UUID is unknown to the client and the URI > > > > > > > > can't be generated. This would mean a new control. > > > > > > > > > > > > > > > > As I see it we have three options: > > > > > > > > 1. Remove the option to specify the ipatokenUniqueID from > > > > > > > > the GUI. Don't make any change in the CLI. > > > > > > > > > > > > > > > > ENFORCEMENT: none > > > > > > > > EFFORT: low > > > > > > > > > > > > > > > > 2. Perform a server-side check for admin membership. > > > > > > > > Raise an exception if the ipatokenUniqueID is specified > > > > > > > > and the user is not an admin. > > > > > > > > > > > > > > > > ENFORCEMENT: API-level > > > > > > > > EFFORT: medium > > > > > > > > > > > > > > > > 3. Modify otptoken-add to create tokens with a magical > > > > > > > > ipatokenUniqueID value by default. An ACI would prevent > > > > > > > > normal users from adding tokens without this magic value. > > > > > > > > Create/modify a plugin to generate UUIDs when the magic > > > > > > > > value is found. Send a control back to the client > > > > > > > > indicating the real ipatokenUniqueID value. Modify > > > > > > > > otptoken-add to read this control. > > > > > > > > > > > > > > > > ENFORCEMENT: DS-level > > > > > > > > EFFORT: high > > > > > > > > > > > > > > > > I think my preference for now is #1. Thoughts? > > > > > > > > > > > > > > > > Nathaniel > > > > > > > > > > > > > > > > > > > > > > I want to raise a question if we really want to disable this > > > > > > > feature for normal users. Wouldn't it be better to improve > > > > > > > error message or check if the name is taken? > > > > > > > > > > > > > > UUID is the value which is displayed in the Soft. Token > > > > > > > application as name. Sure, one can rename it there to match > > > > > > > the description in IPA but that seems quite unpleasant to > > > > > > > me. Also user has to know that he can rename the token in > > > > > > > FreeOTP,.... > > > > > > > > > > > > > > Atm the existence check might be little problematic - > > > > > > > disclose of information which is not readable to user by > > > > > > > default. But current state is basically it, just unfriendly. > > > > > > > > > > > > The existence check is impossible: users can't see tokens they > > > > > > don't own. > > > > > > > > > > Why don't we simply allow user to use an arbitrary name of their > > > > > choosing (or a random string if not specified) and then append > > > > > their uid string to it in the UI ? > > > > > > > > > > I wonder if we have ACIs where the value must match a pattern > > > > > defined by the bound user ... > > > > > > > > This would present a strange scenario where a token is created and > > > > then reassigned to another user. > > > > > > > > > The idea is to strip away the tail when visualizing to the user, so > > > it wouldn't really bee seen ? > > > Or perhaps the token can simply be renamed when assigned. > > > > It just feels like a kludge to me. Also, automated stripping may run > > afoul of names assigned by the imports. > > > > What is wrong with the three options I provided above? We can do #1 > > now and #2 or #3 later. > > Nothing wrong, really, #1 is fine by me. I settled on #2 since it turned out to be somewhat easy. I think we also need an update to the UI (aka #1). This should be an easy review: https://www.redhat.com/archives/freeipa-devel/2014-September/msg00351.html Nathaniel From tbordaz at redhat.com Tue Sep 16 19:56:30 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 16 Sep 2014 21:56:30 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1410888358.3889.13.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54187241.4000202@redhat.com> <1410888358.3889.13.camel@redhat.com> Message-ID: <541895EE.4060601@redhat.com> On 09/16/2014 07:25 PM, Nathaniel McCallum wrote: > On Tue, 2014-09-16 at 19:24 +0200, thierry bordaz wrote: >> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: >> >>> This plugin ensures that all counter/watermark operations are atomic >>> and never decrement. Also, deletion is not permitted. >>> >>> https://fedorahosted.org/freeipa/ticket/4494 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello Nathaniel, >> >> Starting looking at it, I have just a question about >> sanitize_input. >> If the modification (replace) is related to counter/watermark, >> it triggers an internal search on the target entry itself. >> The original/modified entry is also present in the pblock. The >> internal search will check the filter but except that what is >> the benefit vs >> taking the entry directly in the pblock. > I didn't know the entry was already in the pblock. What loads it? And > when? How do I access it? > > Nathaniel > Hello Nathaniel, You may retrieve the entry with slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &e) [Slapi_Entry *e;]. This is the original entry, before the other be-preop plugin are called and modifications occured. If you need to check that the entry match a filter you may also do: filter_str = slapi_ch_strdup("(|(objectClass=ipatokenHOTP)(objectClass=ipatokenTOTP))"); filter = slapi_str2filter(filter_str); if (slapi_filter_test_simple(e, filter) != 0) { /* do not match */ } or directly checking the objectclass values slapi_entry_attr_find/slapi_attr_value_find thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Sep 17 05:25:17 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 17 Sep 2014 07:25:17 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <541860CF.20109@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> Message-ID: <54191B3D.6090205@redhat.com> On 09/16/2014 06:09 PM, Martin Basti wrote: > On 16/09/14 15:59, David Kupka wrote: >> On 09/12/2014 07:24 PM, Martin Basti wrote: >>> >>> >>> Be careful, reviewed on friday! :-) >>> >>> 1) >>> whitespace error + pep8 error >>> patch:76: trailing whitespace. >>> # there is reverse zone for every ip address >>> warning: 1 line adds whitespace errors. >>> >>> ./ipaserver/install/bindinstance.py:640:9: E265 block comment should >>> start with '# ' >>> >> >> Stupid mistake, sorry. >> >>> >>> 2) (server install) >>> + for ip in ip_addresses: >>> + for rev_zone in reverse_zones: >>> + if bindinstance.verify_reverse_zone(rev_zone, str(ip)): >>> + break >>> + else: >>> + sys.exit(1) >>> >>> Please add there error message instead 1 to exit function >> >> You are right, it's better to say what's wrong. >> >>> >>> 3) (server install) >>> Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): >>> IMHO this will cause errors (not tested) try: >>> rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] >>> ip_addreses: [10.10.10.1, 172.16.0.1] >>> >>> it should be any() of zone can handle ip >> >> I indented the else branch more that I wanted. >> >>> >>> 4) (replica-install) >>> I'm not sure about behavior of combination ip addresses, and reverse >>> zones, >>> In original code, if user specify reverse zone, the ip address must >>> match. >>> >>> In patched version, you just add new zones for ip-addresses which >>> doesn't math the user zones. >>> >>> IMO we should check if all addresses belongs to user specified zones, >>> otherwise raise an error. >>> But I'm open to suggestions. >> >> The behavior now basically is: >> >> Check if IP address matches any specified zone >> a. if yes we are good >> b. else search if there is existing zone that can be used >> ba. if yes we are good >> bb. else ask user for zone or create default if --unattended >> >>> >>> 5) >>> Code for ipa-replica-install, and ipa-server-install, differs in parts >>> where we expecting same behavior >>> - ip addresses and reverse zones >> >> The behavoir now should be almost the same. The only difference is >> that when installing replica we need to search for existing reverse >> zones as they could be added during on another server. >> >>> >>> 6) >>> + # there is at >>> least one ip address in every zone >>> + if options.reverse_zones: >>> + for reverse_zone in options.reverse_zones: >>> + for ip in config.ips: >>> <---------------------------------------------------------------------------------- >>> >>> A >>> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>> + break >>> + else: >>> + sys.exit(1) >>> <------------------------------------------------------------------------------------------------* >>> >>> + # there is reverse zone for every ip address >>> + for ip in config.ips: >>> + for reverse_zone in options.reverse_zones: >>> <------------------------------------------------------- B >>> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >>> + if reverse_zone not in reverse_zones: >>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>> + break >>> + else: >>> <------------------------------------------------------------------------------------------------------------ >>> >>> C >>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>> + if reverse_zone is None and not options.no_reverse: >>> + reverse_zone = util.get_reverse_zone_default(ip) >>> <----------------------------------------- D1 >>> + if not options.unattended and >>> bindinstance.create_reverse(): <------------------------- D >>> + reverse_zone = >>> bindinstance.read_reverse_zone(reverse_zone, ip) >>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>> <------------- D2 >>> >>> You added all possible zones in step A, B step is not needed. >>> If user doesn't specify reverse_zones you can just jump to C step >>> *add error message >>> C: elif not options.no_reverse >>> D: you asked user if wants to create zone, but you don't care about >>> answer, and in step D2 append zone from D1 >>> note: --no-reverse and --reverse-zones cant be used together, you can >>> use it in new code, test it before cycle >> >> Rewritten. >> >>> >>> 7) >>> # Always use force=True as named is not set up yet >>> add_zone(self.domain, self.zonemgr, >>> dns_backup=self.dns_backup, >>> - ns_hostname=api.env.host, >>> ns_ip_address=nameserver_ip_address, >>> - force=True) >>> + ns_hostname=api.env.host, ns_ip_address=None, >>> force=True) >>> + #for ns_ip_address in nameserver_ip_address: >>> + # add_zone(self.domain, self.zonemgr, >>> dns_backup=self.dns_backup, >>> + # ns_hostname=api.env.host, >>> ns_ip_address=ns_ip_address, >>> + # force=True) >>> >>> Please remove commented section >> >> I forget to clean the trash, thanks. >> >>> >>> You can remove 'ns_ip_address=None' from function >>> >>> 8) >>> + if set(options.ip_addresses) <= set(ips): >>> + ips = options.ip_addresses >>> + else: >>> + print >>sys.stderr, "Error: the hostname resolves to an >>> IP address that is different" >>> + print >>sys.stderr, "from the one provided on the >>> command line. Please fix your DNS" >>> + print >>sys.stderr, "or /etc/hosts file and restart the >>> installation." >>> + sys.exit(1) >>> >>> Could you write those extra addresses to output? We need to improve >>> usability of our error messages >>> >>> >> >> UX is the king :) >> >>> -- >>> Martin Basti >>> >> > Thank you for patch. > > 1) > + if not options.no_reverse: > + # check that there is reverse zone for every IP > + if options.unattended: > + for ip in config.ip_addresses: > + if bindinstance.find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in reverse_zones: > + if bindinstance.verify_reverse_zone(rz, ip): > + # reverse zone is entered by user > + break > + else: > + rz = util.get_reverse_zone_default(str(ip)) > + reverse_zones.append(rz) > + elif options.reverse_zones or (not(options.no_reverse) and > bindinstance.create_reverse()): > -----------------------------------------------------^^^^^ > > There is double check of "options.no_reverse", you are in block inside > if not options.no_reverse, so not(options.no_reverse) is always True > Good point, will remove the redundancy. > 2) > > + # check that there is IP address in every reverse zone > + if options.reverse_zones: > + for rz in options.reverse_zones: > + for ip in config.ip_addresses: > + if bindinstance.verify_reverse_zone(rz, ip): > + reverse_zones.append(bindinstance.normalize_zone(rz)) > + break > + else: > + sys.exit("There is no IP address matching reverze_zone > %s." % rz) > + if not options.no_reverse: > + # check that there is reverse zone for every IP > + if options.unattended: > + for ip in config.ip_addresses: > + if bindinstance.find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in reverse_zones: > + if bindinstance.verify_reverse_zone(rz, ip): > + # reverse zone is entered by user > + break > + else: > + rz = util.get_reverse_zone_default(str(ip)) > + reverse_zones.append(rz) > + elif options.reverse_zones or (not(options.no_reverse) and > bindinstance.create_reverse()): > + for ip in config.ip_addresses: > + if bindinstance.find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in reverse_zones: > + if bindinstance.verify_reverse_zone(rz, ip): > + # reverse zone is entered by user > + break > + else: > + rz = util.get_reverse_zone_default(str(ip)) > + rz = bindinstance.read_reverse_zone(rz, str(ip)) > + reverse_zones.append(rz) > + else: > + options.no_reverse = True > + reverse_zones = [] > > Code above is duplicated in replica-install and server-install, with > small difference, could you put it inside function, for example into > bindinstance module? Also there are duplicated parts inside in if and > elif code block, could you add it to one function as well? > > Example: > > def check_ip_reversezones(...., unattended=False, try_to_find_zone = > False): > reverse_zones = [] > > if options['reverse_zones']....#check reverse zones > > if not unattended and not bindinstance.create_reverse(): > # user doesn't want to create additional reverse zones > return reverse_zones > > for ip in config.ip_addresses: > if try_to_find_zone and bindinstance.find_reverse_zone(str(ip)): > # reverse zone is already in LDAP > continue > for rz in reverse_zones: > if bindinstance.verify_reverse_zone(rz, ip): > # reverse zone is entered by user > break > else: > rz = util.get_reverse_zone_default(str(ip)) > if not unattended: > rz = bindinstance.read_reverse_zone(rz, str(ip)) > reverse_zones.append(rz) > This makes sense. There is one more difference in the code but it is reasonably solvable. > > 3) > + elif options.reverse_zones or (not(options.no_reverse) and > bindinstance.create_reverse()): > > OR operator, this will create additional zones (non-specified by user) > even if user write NO When user specifies some reverse zone (using --reverse-zone) we can assume that he wants to configure reverse zones (otherwise his is kind of indecisive, at least). So there is no reason to ask him again. The question is asked only when the user didn't provided any reverse zone nor specified --no-reverse. > > 4) > IF user specify zone 10.in-addr.arpa, and ip addresses 10.0.0.1, > 192.168.1.1, and answer to not create additional zones, how is this case > handled? > The question is not asked. See the answer to 3). -- David Kupka From jcholast at redhat.com Wed Sep 17 06:51:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Sep 2014 08:51:09 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <1410888743.3889.15.camel@redhat.com> References: <1410888743.3889.15.camel@redhat.com> Message-ID: <54192F5D.7020208@redhat.com> Hi, Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): > We perform this enforcement at the API level since: > * DS level enforcement would be difficult > * ipatokenUniqueID generation already happens at the API level > > It may be nice in the future to perform enforcement in the DS itself. > However, the question of the location of enforcement is largely an > aesthetic issue. > > https://fedorahosted.org/freeipa/ticket/4456 That's a rather beefy check. I would prefer something like this (untested): group_dn = self.api.Object.group.get_dn(u'admins') filter = ldap.make_filter( {'krbprincipalname': context.principal, 'memberof': group_dn}, ldap.MATCH_ALL) try: ldap.find_entries( base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) except errors.NotFound: raise ValidationError(name='ipatokenuniqueid', error='can only be specified by admins') Honza -- Jan Cholasta From pviktori at redhat.com Wed Sep 17 07:36:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Sep 2014 09:36:54 +0200 Subject: [Freeipa-devel] [PATCH 0269] ipalib: host_del: Extend LDAPDelete's takes_options instead In-Reply-To: <54183113.9030708@redhat.com> References: <54181D4F.2090003@redhat.com> <54183113.9030708@redhat.com> Message-ID: <54193A16.1010309@redhat.com> On 09/16/2014 02:46 PM, Jan Cholasta wrote: > Dne 16.9.2014 v 13:21 Tomas Babej napsal(a): >> Hi, >> >> The host-del command did not accept --continue option, since the >> takes_options was overriden and did not take the options from LDAPDelete. >> >> Fix the behaviour. >> >> https://fedorahosted.org/freeipa/ticket/4473 > > ACK. > Pushed to: ipa-4-1: adc4abcbe3bd497b8602fce0ef9b4340ed15f0a7 master: 1f8f762b84e7448cb279b6db5158f93b5f517827 -- Petr? From jcholast at redhat.com Wed Sep 17 10:31:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Sep 2014 12:31:53 +0200 Subject: [Freeipa-devel] [PATCHES] 319-321 Build and packaging fixes Message-ID: <54196319.5010302@redhat.com> Hi, the attached patches fix , and . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319-Allow-RPM-upgrade-from-ipa-packages.patch Type: text/x-patch Size: 3231 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-320-Include-ipaplatform-in-client-only-build.patch Type: text/x-patch Size: 2724 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-321-Include-the-ipa-command-in-client-only-build.patch Type: text/x-patch Size: 2302 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 17 10:31:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Sep 2014 12:31:34 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <54192F5D.7020208@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> Message-ID: <54196306.3020805@redhat.com> On 09/17/2014 08:51 AM, Jan Cholasta wrote: > Hi, > > Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): >> We perform this enforcement at the API level since: >> * DS level enforcement would be difficult >> * ipatokenUniqueID generation already happens at the API level >> >> It may be nice in the future to perform enforcement in the DS itself. >> However, the question of the location of enforcement is largely an >> aesthetic issue. >> >> https://fedorahosted.org/freeipa/ticket/4456 > > That's a rather beefy check. I would prefer something like this (untested): > > group_dn = self.api.Object.group.get_dn(u'admins') > filter = ldap.make_filter( > {'krbprincipalname': context.principal, 'memberof': group_dn}, > ldap.MATCH_ALL) > try: > ldap.find_entries( > base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) > except errors.NotFound: > raise ValidationError(name='ipatokenuniqueid', > error='can only be specified by admins') > > Honza > Also, do we want to hard code it to admins group only? Wouldn't it be more flexible to create a new Virtual Operation and let realm admin configure who can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1 for an example how that's done. Martin From tbordaz at redhat.com Wed Sep 17 10:32:38 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 17 Sep 2014 12:32:38 +0200 Subject: [Freeipa-devel] [PATCH] 0003-2 User life cycle: new stageuser plugin with add verb In-Reply-To: <54045399.3030404@redhat.com> References: <53E4D6AE.6050505@redhat.com> <54045399.3030404@redhat.com> Message-ID: <54196346.5070500@redhat.com> On 09/01/2014 01:08 PM, Petr Viktorin wrote: > On 08/08/2014 03:54 PM, thierry bordaz wrote: >> 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 > > Avoid `from ipalib.plugins.baseldap import *` in new code; instead > import the module itself and use e.g. `baseldap.LDAPObject`. > > The stageuser help (docstring) is copied from the user plugin, and > discusses things like account lockout and disabling users. It should > rather explain what stageuser itself does. (And I don't very much like > the Note about the interface being badly designed...) > Also decide if the docs should call it "staged user" or "stage user" > or "stageuser". > > A lot of the code is copied and pasted over from the users plugin. > Don't do that. Either import things (e.g. validate_nsaccountlock) from > the users plugin, or move the reused code into a shared module. > > For the `user` object, since so much is the same, it might be best to > create a common base class for user and stageuser; and similarly for > the Command plugins. > > The default permissions need different names, and you don't need > another copy of the 'non_object' ones. Also, run the makeaci script. > Hello, This modified patch is mainly moving common base class into a new plugin: accounts.py. user/stageuser plugin inherits from accounts. It also creates a better description of what are stage user, how to add a new stage user, updates ACI.txt and separate active/stage user managed permissions. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0003-2-User-life-cycle-new-stageuser-plugin.patch Type: text/x-patch Size: 99167 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 17 10:34:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Sep 2014 12:34:36 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <541860CF.20109@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> Message-ID: <541963BC.6050404@redhat.com> On 09/16/2014 06:09 PM, Martin Basti wrote: > On 16/09/14 15:59, David Kupka wrote: ... > 2) > > + # check that there is IP address in every reverse zone > + if options.reverse_zones: > + for rz in options.reverse_zones: > + for ip in config.ip_addresses: > + if bindinstance.verify_reverse_zone(rz, ip): > + reverse_zones.append(bindinstance.normalize_zone(rz)) > + break > + else: > + sys.exit("There is no IP address matching reverze_zone %s." % rz) > + if not options.no_reverse: > + # check that there is reverse zone for every IP > + if options.unattended: > + for ip in config.ip_addresses: > + if bindinstance.find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in reverse_zones: > + if bindinstance.verify_reverse_zone(rz, ip): > + # reverse zone is entered by user > + break > + else: > + rz = util.get_reverse_zone_default(str(ip)) > + reverse_zones.append(rz) > + elif options.reverse_zones or (not(options.no_reverse) and > bindinstance.create_reverse()): > + for ip in config.ip_addresses: > + if bindinstance.find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in reverse_zones: > + if bindinstance.verify_reverse_zone(rz, ip): > + # reverse zone is entered by user > + break > + else: > + rz = util.get_reverse_zone_default(str(ip)) > + rz = bindinstance.read_reverse_zone(rz, str(ip)) > + reverse_zones.append(rz) > + else: > + options.no_reverse = True > + reverse_zones = [] > > Code above is duplicated in replica-install and server-install, with small > difference, could you put it inside function, for example into bindinstance > module? Also there are duplicated parts inside in if and elif code block, could > you add it to one function as well? +1, I wanted to comment the exactly same idea. Keep in mind that we plan to refactor the installers in FreeIPA 4.2 so we will want the installer to be rather calling shared logic and shared functions instead of duplicating code across bare installers. Martin From mkosek at redhat.com Wed Sep 17 10:47:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Sep 2014 12:47:42 +0200 Subject: [Freeipa-devel] [PATCHES] 319-321 Build and packaging fixes In-Reply-To: <54196319.5010302@redhat.com> References: <54196319.5010302@redhat.com> Message-ID: <541966CE.8000406@redhat.com> On 09/17/2014 12:31 PM, Jan Cholasta wrote: > > +Conflicts: %{alt_name}-server-trust-ad > +Obsoletes: %{alt_name}-server-trust-ad < %{version}-%{release} Just one question - should we check also for %{release}? Generally, release number does not have much value, we could rebuild our version of the package 10 times, but it does not mean it is newer. I.e. freeipa-server-4.0.0-10 should probably not obsolete ipa-server-4.0.0-1 but only ipa-server-3.3.3-10, right? Martin From mbasti at redhat.com Wed Sep 17 10:57:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Sep 2014 12:57:16 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54191B3D.6090205@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> Message-ID: <5419690C.9090301@redhat.com> On 17/09/14 07:25, David Kupka wrote: > >> >> 3) >> + elif options.reverse_zones or (not(options.no_reverse) and >> bindinstance.create_reverse()): >> >> OR operator, this will create additional zones (non-specified by user) >> even if user write NO > > When user specifies some reverse zone (using --reverse-zone) we can > assume that he wants to configure reverse zones (otherwise his is kind > of indecisive, at least). So there is no reason to ask him again. > The question is asked only when the user didn't provided any reverse > zone nor specified --no-reverse. >> >> 4) >> IF user specify zone 10.in-addr.arpa, and ip addresses 10.0.0.1, >> 192.168.1.1, and answer to not create additional zones, how is this case >> handled? >> > > The question is not asked. See the answer to 3). Sorry my bad. -- Martin Basti From abokovoy at redhat.com Wed Sep 17 11:07:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Sep 2014 14:07:51 +0300 Subject: [Freeipa-devel] [PATCHES] 319-321 Build and packaging fixes In-Reply-To: <541966CE.8000406@redhat.com> References: <54196319.5010302@redhat.com> <541966CE.8000406@redhat.com> Message-ID: <20140917110751.GY2541@redhat.com> On Wed, 17 Sep 2014, Martin Kosek wrote: >On 09/17/2014 12:31 PM, Jan Cholasta wrote: >> >> +Conflicts: %{alt_name}-server-trust-ad >> +Obsoletes: %{alt_name}-server-trust-ad < %{version}-%{release} > >Just one question - should we check also for %{release}? Generally, release >number does not have much value, we could rebuild our version of the package 10 >times, but it does not mean it is newer. > >I.e. freeipa-server-4.0.0-10 should probably not obsolete ipa-server-4.0.0-1 >but only ipa-server-3.3.3-10, right? I agree with the %{release} idea. We definitely don't need to be so picky with it. -- / Alexander Bokovoy From pspacek at redhat.com Wed Sep 17 11:33:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Sep 2014 13:33:16 +0200 Subject: [Freeipa-devel] [PATCH 0297] Add log message about initial LDAP synchronization Message-ID: <5419717C.4070103@redhat.com> Hello, Add log message about initial LDAP synchronization. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0297-Add-log-message-about-initial-LDAP-synchronization.patch Type: text/x-patch Size: 981 bytes Desc: not available URL: From jcholast at redhat.com Wed Sep 17 11:58:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Sep 2014 13:58:36 +0200 Subject: [Freeipa-devel] [PATCHES] 319-321 Build and packaging fixes In-Reply-To: <20140917110751.GY2541@redhat.com> References: <54196319.5010302@redhat.com> <541966CE.8000406@redhat.com> <20140917110751.GY2541@redhat.com> Message-ID: <5419776C.2000900@redhat.com> Dne 17.9.2014 v 13:07 Alexander Bokovoy napsal(a): > On Wed, 17 Sep 2014, Martin Kosek wrote: >> On 09/17/2014 12:31 PM, Jan Cholasta wrote: >>> >>> +Conflicts: %{alt_name}-server-trust-ad >>> +Obsoletes: %{alt_name}-server-trust-ad < %{version}-%{release} >> >> Just one question - should we check also for %{release}? Generally, >> release >> number does not have much value, we could rebuild our version of the >> package 10 >> times, but it does not mean it is newer. >> >> I.e. freeipa-server-4.0.0-10 should probably not obsolete >> ipa-server-4.0.0-1 >> but only ipa-server-3.3.3-10, right? > I agree with the %{release} idea. We definitely don't need to be so > picky with it. OK, fixed. I used wrong numbers for the patches, they should be 320-322. Fixed as well. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-320.1-Allow-RPM-upgrade-from-ipa-packages.patch Type: text/x-patch Size: 3165 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-321.1-Include-ipaplatform-in-client-only-build.patch Type: text/x-patch Size: 2724 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-322.1-Include-the-ipa-command-in-client-only-build.patch Type: text/x-patch Size: 2302 bytes Desc: not available URL: From tbordaz at redhat.com Wed Sep 17 13:33:23 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 17 Sep 2014 15:33:23 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1410807911.4238.6.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> Message-ID: <54198DA3.5090603@redhat.com> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: > This plugin ensures that all counter/watermark operations are atomic > and never decrement. Also, deletion is not permitted. > > https://fedorahosted.org/freeipa/ticket/4494 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, More thoughts.. I think being "betxnpreoperation" you are safe with parallel client ops and the check is atomic. I have few comments: * Shouldn't be implemented SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, even if they are empty. * In load_counters, in case we have a target entry that has not 'objectclass' 'ipatokenHOTP|ipatokenTOTP' and the mod operation: dn: changetype: modify replace: ipatokenHOTPcounter ipatokenHOTPcounter: 200 - add: objectclass objectclass: ipatokenHOTP I wonder if the operation will not fail although IMHO it should succeeds. Shouldn't let the schema checking reject the operation if the attribute is not granted by the entry objectclass * in load_counters, I am under the impression it may return ipatokenHOTPcounter or ipatokenTOTPwatermark (ipatokenHOTPcounter is missing). But then how the caller knows that the returned value is a counter or a watermark ? * in ldapmod_is_attrs you may prefer PL_strcasecmp to strcasecmp About replicated updates, if updates of counters/watermark are done on several servers. Then a replicated operation may want to set counters/watermark with a smaller value that the existing one. In that case, it will return unwilling to perform. That could break replication. If the update comes from replication and the value is going backward, we could make the operation a nop operation (setting the attribute to its current value). thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Sep 17 13:57:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Sep 2014 15:57:01 +0200 Subject: [Freeipa-devel] [PATCH] 323 Fix certmonger code causing the ca_renewal_master update plugin to fail Message-ID: <5419932D.9040006@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-323-Fix-certmonger-code-causing-the-ca_renewal_master-up.patch Type: text/x-patch Size: 1911 bytes Desc: not available URL: From tbabej at redhat.com Wed Sep 17 15:28:31 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Sep 2014 17:28:31 +0200 Subject: [Freeipa-devel] [PATCH 0271] baseldap: Properly handle the case of renaming object to the Message-ID: <5419A89F.9080105@redhat.com> Hi, When renaming a object to the same name, errors.EmptyModList is raised. This is not properly handled, and can cause other modifications in the LDAPUpdate command to be ignored. https://fedorahosted.org/freeipa/ticket/4548 -- 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-0271-baseldap-Properly-handle-the-case-of-renaming-object.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From thozza at redhat.com Wed Sep 17 18:04:20 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 17 Sep 2014 20:04:20 +0200 Subject: [Freeipa-devel] [PATCH] [dyndb] Fix error handling in configure_view() to prevent deadlocks In-Reply-To: <54187437.3040604@redhat.com> References: <54187437.3040604@redhat.com> Message-ID: <5419CD24.2080408@redhat.com> On Tue 16 Sep 2014 07:32:39 PM CEST, Petr Spacek wrote: > Hello, > > attached patches fix > https://bugzilla.redhat.com/show_bug.cgi?id=1142150 > https://bugzilla.redhat.com/show_bug.cgi?id=1142152 > > ... and improve related error messages. > > I will push it to https://github.com/spacekpe/bind-dynamic_db if you are okay > with it. > I think there is a mistake in the first patch: 0001-Fix-error-handling-in-configure_view-to-prevent-dead.patch diff --git a/lib/dns/dynamic_db.c b/lib/dns/dynamic_db.c index bf831617b391778ec540b2a5ca0df341937f2427..30c56a65c7227497c3e772c3e1b58ff49eacbd35 100644 --- a/lib/dns/dynamic_db.c +++ b/lib/dns/dynamic_db.c @@ -280,16 +280,24 @@ dns_dyndb_arguments_create(isc_mem_t *mctx) } void -dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t *args) +dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t **argsp) { + dns_dyndb_arguments_t *args; + REQUIRE(args != NULL); ^^^^ args is not initialized here. I think it should be "argsp" + args = *argsp; + if (args == NULL) + return; + dns_dyndb_set_view(args, NULL); dns_dyndb_set_zonemgr(args, NULL); dns_dyndb_set_task(args, NULL); dns_dyndb_set_timermgr(args, NULL); isc_mem_put(mctx, args, sizeof(*args)); + + *argsp = NULL; } Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From rcritten at redhat.com Thu Sep 18 00:10:08 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Sep 2014 20:10:08 -0400 Subject: [Freeipa-devel] [PATCH 0271] baseldap: Properly handle the case of renaming object to the In-Reply-To: <5419A89F.9080105@redhat.com> References: <5419A89F.9080105@redhat.com> Message-ID: <541A22E0.1040505@redhat.com> Tomas Babej wrote: > Hi, > > When renaming a object to the same name, errors.EmptyModList is raised. > This is not properly handled, and can cause other modifications in the > LDAPUpdate command to be ignored. > > https://fedorahosted.org/freeipa/ticket/4548 Needs some tests... rob From pspacek at redhat.com Thu Sep 18 06:49:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Sep 2014 08:49:05 +0200 Subject: [Freeipa-devel] [PATCH] [dyndb] Fix error handling in configure_view() to prevent deadlocks In-Reply-To: <5419CD24.2080408@redhat.com> References: <54187437.3040604@redhat.com> <5419CD24.2080408@redhat.com> Message-ID: <541A8061.4060609@redhat.com> On 17.9.2014 20:04, Tomas Hozza wrote: > On Tue 16 Sep 2014 07:32:39 PM CEST, Petr Spacek wrote: >> Hello, >> >> attached patches fix >> https://bugzilla.redhat.com/show_bug.cgi?id=1142150 >> https://bugzilla.redhat.com/show_bug.cgi?id=1142152 >> >> ... and improve related error messages. >> >> I will push it to https://github.com/spacekpe/bind-dynamic_db if you are okay >> with it. >> > > I think there is a mistake in the first patch: > 0001-Fix-error-handling-in-configure_view-to-prevent-dead.patch > > diff --git a/lib/dns/dynamic_db.c b/lib/dns/dynamic_db.c > index > bf831617b391778ec540b2a5ca0df341937f2427..30c56a65c7227497c3e772c3e1b58ff49eacbd35 > 100644 > --- a/lib/dns/dynamic_db.c > +++ b/lib/dns/dynamic_db.c > @@ -280,16 +280,24 @@ dns_dyndb_arguments_create(isc_mem_t *mctx) > } > > void > -dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t > *args) > +dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t > **argsp) > { > + dns_dyndb_arguments_t *args; > + > REQUIRE(args != NULL); > ^^^^ args is not initialized here. I think it should be "argsp" Good point! I will fix that. Do I have your ACK then? :-) -- Petr^2 Spacek From thozza at redhat.com Thu Sep 18 07:12:03 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 18 Sep 2014 09:12:03 +0200 Subject: [Freeipa-devel] [PATCH] [dyndb] Fix error handling in configure_view() to prevent deadlocks In-Reply-To: <541A8061.4060609@redhat.com> References: <54187437.3040604@redhat.com> <5419CD24.2080408@redhat.com> <541A8061.4060609@redhat.com> Message-ID: <541A85C3.7080207@redhat.com> On Thu 18 Sep 2014 08:49:05 AM CEST, Petr Spacek wrote: > On 17.9.2014 20:04, Tomas Hozza wrote: >> On Tue 16 Sep 2014 07:32:39 PM CEST, Petr Spacek wrote: >>> Hello, >>> >>> attached patches fix >>> https://bugzilla.redhat.com/show_bug.cgi?id=1142150 >>> https://bugzilla.redhat.com/show_bug.cgi?id=1142152 >>> >>> ... and improve related error messages. >>> >>> I will push it to https://github.com/spacekpe/bind-dynamic_db if you are okay >>> with it. >>> >> >> I think there is a mistake in the first patch: >> 0001-Fix-error-handling-in-configure_view-to-prevent-dead.patch >> >> diff --git a/lib/dns/dynamic_db.c b/lib/dns/dynamic_db.c >> index >> bf831617b391778ec540b2a5ca0df341937f2427..30c56a65c7227497c3e772c3e1b58ff49eacbd35 >> >> 100644 >> --- a/lib/dns/dynamic_db.c >> +++ b/lib/dns/dynamic_db.c >> @@ -280,16 +280,24 @@ dns_dyndb_arguments_create(isc_mem_t *mctx) >> } >> >> void >> -dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t >> *args) >> +dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t >> **argsp) >> { >> + dns_dyndb_arguments_t *args; >> + >> REQUIRE(args != NULL); >> ^^^^ args is not initialized here. I think it should be "argsp" > > Good point! I will fix that. Do I have your ACK then? :-) > Yes, It worked with the change I proposed. So ACK with the fix ;) Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Thu Sep 18 07:28:35 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Sep 2014 09:28:35 +0200 Subject: [Freeipa-devel] [PATCH] [dyndb] Fix error handling in configure_view() to prevent deadlocks In-Reply-To: <541A85C3.7080207@redhat.com> References: <54187437.3040604@redhat.com> <5419CD24.2080408@redhat.com> <541A8061.4060609@redhat.com> <541A85C3.7080207@redhat.com> Message-ID: <541A89A3.8090309@redhat.com> On 18.9.2014 09:12, Tomas Hozza wrote: > On Thu 18 Sep 2014 08:49:05 AM CEST, Petr Spacek wrote: >> On 17.9.2014 20:04, Tomas Hozza wrote: >>> On Tue 16 Sep 2014 07:32:39 PM CEST, Petr Spacek wrote: >>>> Hello, >>>> >>>> attached patches fix >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1142150 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1142152 >>>> >>>> ... and improve related error messages. >>>> >>>> I will push it to https://github.com/spacekpe/bind-dynamic_db if you are okay >>>> with it. >>>> >>> >>> I think there is a mistake in the first patch: >>> 0001-Fix-error-handling-in-configure_view-to-prevent-dead.patch >>> >>> diff --git a/lib/dns/dynamic_db.c b/lib/dns/dynamic_db.c >>> index >>> bf831617b391778ec540b2a5ca0df341937f2427..30c56a65c7227497c3e772c3e1b58ff49eacbd35 >>> >>> 100644 >>> --- a/lib/dns/dynamic_db.c >>> +++ b/lib/dns/dynamic_db.c >>> @@ -280,16 +280,24 @@ dns_dyndb_arguments_create(isc_mem_t *mctx) >>> } >>> >>> void >>> -dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t >>> *args) >>> +dns_dyndb_arguments_destroy(isc_mem_t *mctx, dns_dyndb_arguments_t >>> **argsp) >>> { >>> + dns_dyndb_arguments_t *args; >>> + >>> REQUIRE(args != NULL); >>> ^^^^ args is not initialized here. I think it should be "argsp" >> >> Good point! I will fix that. Do I have your ACK then? :-) >> > > Yes, It worked with the change I proposed. > > So ACK with the fix ;) Thanks, pushed to dyndb_bind9_9 branch: e3616f0922a45fdb5942013318bbf3eef0415bf0 7fc676122191c567511a0a6eaa6f1558ffbecac5 -- Petr^2 Spacek From dkupka at redhat.com Thu Sep 18 08:19:54 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Sep 2014 10:19:54 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test Message-ID: <541A95AA.70902@redhat.com> https://fedorahosted.org/freeipa/ticket/4421 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0015-Allow-multiple-krbprincipalnames.patch Type: text/x-patch Size: 6327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0016-Test-Allow-multiple-krbPrincipalNames.patch Type: text/x-patch Size: 6779 bytes Desc: not available URL: From mkosek at redhat.com Thu Sep 18 08:34:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Sep 2014 10:34:34 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541A95AA.70902@redhat.com> References: <541A95AA.70902@redhat.com> Message-ID: <541A991A.8090002@redhat.com> On 09/18/2014 10:19 AM, David Kupka wrote: > + 'System: Add krbCanonicalName to a Host': { > + 'ipapermright': {'write'}, > + 'ipapermdefaultattr': {'krbcanonicalname'}, > + 'default_privileges': {'Host Administrators'}, > + }, Would it make sense to add the krbCanonicalName to "System: Add krbPrincipalName to a Host" permission as they are semantically connected? I.e. having one ACI without the other does not make much sense? Martin From pvoborni at redhat.com Thu Sep 18 12:00:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Sep 2014 14:00:29 +0200 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates In-Reply-To: <1410808094.4238.7.camel@redhat.com> References: <1409280891.9966.11.camel@redhat.com> <1410808094.4238.7.camel@redhat.com> Message-ID: <541AC95D.6090202@redhat.com> On 15.9.2014 21:08, Nathaniel McCallum wrote: > 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 > > I still need a review of this. This is targeted for 4.1. > > Nathaniel > Works fine with HTOP but fails for new TOTP tokens. New TOTP token doesn't have a watermark attribute set so there is nothing to delete and therefore standard login procedure fails on writeattr call (libotp.c:223). -- Petr Vobornik From dkupka at redhat.com Thu Sep 18 13:07:18 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Sep 2014 15:07:18 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54191B3D.6090205@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> Message-ID: <541AD906.4000006@redhat.com> On 09/17/2014 07:25 AM, David Kupka wrote: > On 09/16/2014 06:09 PM, Martin Basti wrote: >> On 16/09/14 15:59, David Kupka wrote: >>> On 09/12/2014 07:24 PM, Martin Basti wrote: >>>> >>>> >>>> Be careful, reviewed on friday! :-) >>>> >>>> 1) >>>> whitespace error + pep8 error >>>> patch:76: trailing whitespace. >>>> # there is reverse zone for every ip address >>>> warning: 1 line adds whitespace errors. >>>> >>>> ./ipaserver/install/bindinstance.py:640:9: E265 block comment should >>>> start with '# ' >>>> >>> >>> Stupid mistake, sorry. >>> >>>> >>>> 2) (server install) >>>> + for ip in ip_addresses: >>>> + for rev_zone in reverse_zones: >>>> + if bindinstance.verify_reverse_zone(rev_zone, str(ip)): >>>> + break >>>> + else: >>>> + sys.exit(1) >>>> >>>> Please add there error message instead 1 to exit function >>> >>> You are right, it's better to say what's wrong. >>> >>>> >>>> 3) (server install) >>>> Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): >>>> IMHO this will cause errors (not tested) try: >>>> rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] >>>> ip_addreses: [10.10.10.1, 172.16.0.1] >>>> >>>> it should be any() of zone can handle ip >>> >>> I indented the else branch more that I wanted. >>> >>>> >>>> 4) (replica-install) >>>> I'm not sure about behavior of combination ip addresses, and reverse >>>> zones, >>>> In original code, if user specify reverse zone, the ip address must >>>> match. >>>> >>>> In patched version, you just add new zones for ip-addresses which >>>> doesn't math the user zones. >>>> >>>> IMO we should check if all addresses belongs to user specified zones, >>>> otherwise raise an error. >>>> But I'm open to suggestions. >>> >>> The behavior now basically is: >>> >>> Check if IP address matches any specified zone >>> a. if yes we are good >>> b. else search if there is existing zone that can be used >>> ba. if yes we are good >>> bb. else ask user for zone or create default if --unattended >>> >>>> >>>> 5) >>>> Code for ipa-replica-install, and ipa-server-install, differs in parts >>>> where we expecting same behavior >>>> - ip addresses and reverse zones >>> >>> The behavoir now should be almost the same. The only difference is >>> that when installing replica we need to search for existing reverse >>> zones as they could be added during on another server. >>> >>>> >>>> 6) >>>> + # there is at >>>> least one ip address in every zone >>>> + if options.reverse_zones: >>>> + for reverse_zone in options.reverse_zones: >>>> + for ip in config.ips: >>>> <---------------------------------------------------------------------------------- >>>> >>>> >>>> A >>>> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >>>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>>> + break >>>> + else: >>>> + sys.exit(1) >>>> <------------------------------------------------------------------------------------------------* >>>> >>>> >>>> + # there is reverse zone for every ip address >>>> + for ip in config.ips: >>>> + for reverse_zone in options.reverse_zones: >>>> <------------------------------------------------------- B >>>> + if bindinstance.verify_reverse_zone(reverse_zone, ip): >>>> + if reverse_zone not in reverse_zones: >>>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>>> + break >>>> + else: >>>> <------------------------------------------------------------------------------------------------------------ >>>> >>>> >>>> C >>>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>>> + if reverse_zone is None and not options.no_reverse: >>>> + reverse_zone = util.get_reverse_zone_default(ip) >>>> <----------------------------------------- D1 >>>> + if not options.unattended and >>>> bindinstance.create_reverse(): <------------------------- D >>>> + reverse_zone = >>>> bindinstance.read_reverse_zone(reverse_zone, ip) >>>> + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) >>>> <------------- D2 >>>> >>>> You added all possible zones in step A, B step is not needed. >>>> If user doesn't specify reverse_zones you can just jump to C step >>>> *add error message >>>> C: elif not options.no_reverse >>>> D: you asked user if wants to create zone, but you don't care about >>>> answer, and in step D2 append zone from D1 >>>> note: --no-reverse and --reverse-zones cant be used together, you can >>>> use it in new code, test it before cycle >>> >>> Rewritten. >>> >>>> >>>> 7) >>>> # Always use force=True as named is not set up yet >>>> add_zone(self.domain, self.zonemgr, >>>> dns_backup=self.dns_backup, >>>> - ns_hostname=api.env.host, >>>> ns_ip_address=nameserver_ip_address, >>>> - force=True) >>>> + ns_hostname=api.env.host, ns_ip_address=None, >>>> force=True) >>>> + #for ns_ip_address in nameserver_ip_address: >>>> + # add_zone(self.domain, self.zonemgr, >>>> dns_backup=self.dns_backup, >>>> + # ns_hostname=api.env.host, >>>> ns_ip_address=ns_ip_address, >>>> + # force=True) >>>> >>>> Please remove commented section >>> >>> I forget to clean the trash, thanks. >>> >>>> >>>> You can remove 'ns_ip_address=None' from function >>>> >>>> 8) >>>> + if set(options.ip_addresses) <= set(ips): >>>> + ips = options.ip_addresses >>>> + else: >>>> + print >>sys.stderr, "Error: the hostname resolves >>>> to an >>>> IP address that is different" >>>> + print >>sys.stderr, "from the one provided on the >>>> command line. Please fix your DNS" >>>> + print >>sys.stderr, "or /etc/hosts file and restart >>>> the >>>> installation." >>>> + sys.exit(1) >>>> >>>> Could you write those extra addresses to output? We need to improve >>>> usability of our error messages >>>> >>>> >>> >>> UX is the king :) >>> >>>> -- >>>> Martin Basti >>>> >>> >> Thank you for patch. >> >> 1) >> + if not options.no_reverse: >> + # check that there is reverse zone for every IP >> + if options.unattended: >> + for ip in config.ip_addresses: >> + if bindinstance.find_reverse_zone(str(ip)): >> + # reverse zone is already in LDAP >> + continue >> + for rz in reverse_zones: >> + if bindinstance.verify_reverse_zone(rz, ip): >> + # reverse zone is entered by user >> + break >> + else: >> + rz = util.get_reverse_zone_default(str(ip)) >> + reverse_zones.append(rz) >> + elif options.reverse_zones or (not(options.no_reverse) and >> bindinstance.create_reverse()): >> -----------------------------------------------------^^^^^ >> >> There is double check of "options.no_reverse", you are in block inside >> if not options.no_reverse, so not(options.no_reverse) is always True >> > > Good point, will remove the redundancy. Removed. > >> 2) >> >> + # check that there is IP address in every reverse zone >> + if options.reverse_zones: >> + for rz in options.reverse_zones: >> + for ip in config.ip_addresses: >> + if bindinstance.verify_reverse_zone(rz, ip): >> + reverse_zones.append(bindinstance.normalize_zone(rz)) >> + break >> + else: >> + sys.exit("There is no IP address matching reverze_zone >> %s." % rz) >> + if not options.no_reverse: >> + # check that there is reverse zone for every IP >> + if options.unattended: >> + for ip in config.ip_addresses: >> + if bindinstance.find_reverse_zone(str(ip)): >> + # reverse zone is already in LDAP >> + continue >> + for rz in reverse_zones: >> + if bindinstance.verify_reverse_zone(rz, ip): >> + # reverse zone is entered by user >> + break >> + else: >> + rz = util.get_reverse_zone_default(str(ip)) >> + reverse_zones.append(rz) >> + elif options.reverse_zones or (not(options.no_reverse) and >> bindinstance.create_reverse()): >> + for ip in config.ip_addresses: >> + if bindinstance.find_reverse_zone(str(ip)): >> + # reverse zone is already in LDAP >> + continue >> + for rz in reverse_zones: >> + if bindinstance.verify_reverse_zone(rz, ip): >> + # reverse zone is entered by user >> + break >> + else: >> + rz = util.get_reverse_zone_default(str(ip)) >> + rz = bindinstance.read_reverse_zone(rz, str(ip)) >> + reverse_zones.append(rz) >> + else: >> + options.no_reverse = True >> + reverse_zones = [] >> >> Code above is duplicated in replica-install and server-install, with >> small difference, could you put it inside function, for example into >> bindinstance module? Also there are duplicated parts inside in if and >> elif code block, could you add it to one function as well? >> >> Example: >> >> def check_ip_reversezones(...., unattended=False, try_to_find_zone = >> False): >> reverse_zones = [] >> >> if options['reverse_zones']....#check reverse zones >> >> if not unattended and not bindinstance.create_reverse(): >> # user doesn't want to create additional reverse zones >> return reverse_zones >> >> for ip in config.ip_addresses: >> if try_to_find_zone and bindinstance.find_reverse_zone(str(ip)): >> # reverse zone is already in LDAP >> continue >> for rz in reverse_zones: >> if bindinstance.verify_reverse_zone(rz, ip): >> # reverse zone is entered by user >> break >> else: >> rz = util.get_reverse_zone_default(str(ip)) >> if not unattended: >> rz = bindinstance.read_reverse_zone(rz, str(ip)) >> reverse_zones.append(rz) >> > > This makes sense. There is one more difference in the code but it is > reasonably solvable. Done. > >> >> 3) >> + elif options.reverse_zones or (not(options.no_reverse) and >> bindinstance.create_reverse()): >> >> OR operator, this will create additional zones (non-specified by user) >> even if user write NO > > When user specifies some reverse zone (using --reverse-zone) we can > assume that he wants to configure reverse zones (otherwise his is kind > of indecisive, at least). So there is no reason to ask him again. > The question is asked only when the user didn't provided any reverse > zone nor specified --no-reverse. >> >> 4) >> IF user specify zone 10.in-addr.arpa, and ip addresses 10.0.0.1, >> 192.168.1.1, and answer to not create additional zones, how is this case >> handled? >> > > The question is not asked. See the answer to 3). > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-7-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 36481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-7-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 36465 bytes Desc: not available URL: From rcritten at redhat.com Thu Sep 18 13:44:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 09:44:55 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541A95AA.70902@redhat.com> References: <541A95AA.70902@redhat.com> Message-ID: <541AE1D7.3000903@redhat.com> David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4421 You are removing an ACI in this patch. It is always possible it is no longer needed. Did you test all the client enrollment scenarios? rob From dkupka at redhat.com Thu Sep 18 14:06:48 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Sep 2014 16:06:48 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541AE1D7.3000903@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> Message-ID: <541AE6F8.5020309@redhat.com> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4421 > > You are removing an ACI in this patch. It is always possible it is no > longer needed. Did you test all the client enrollment scenarios? > > rob > As far as I'm aware I'm not removing any ACI. I'm modifying ACI so it is possible to add krbPrincipalName to host even when there is already one (or more). And adding one ACI to allow writing krbCanonicalName to host. But I'm still not really familiar with ACI so please correct me if I'm wrong. -- David Kupka From mkosek at redhat.com Thu Sep 18 14:28:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Sep 2014 16:28:19 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541AE6F8.5020309@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> Message-ID: <541AEC03.9080304@redhat.com> On 09/18/2014 04:06 PM, David Kupka wrote: > On 09/18/2014 03:44 PM, Rob Crittenden wrote: >> David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4421 >> >> You are removing an ACI in this patch. It is always possible it is no >> longer needed. Did you test all the client enrollment scenarios? >> >> rob >> > > As far as I'm aware I'm not removing any ACI. I'm modifying ACI so it is > possible to add krbPrincipalName to host even when there is already one (or > more). And adding one ACI to allow writing krbCanonicalName to host. > But I'm still not really familiar with ACI so please correct me if I'm wrong. > What refers to is probably the update in ACI.txt - the ACI alternative to API.txt. David updated an ACI, not removed it. On that note, what is the reason for this permission change: - 'ipapermtargetfilter': [ - '(objectclass=ipahost)', - '(!(krbprincipalname=*))', - ], ? Martin From simo at redhat.com Thu Sep 18 14:40:27 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 10:40:27 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541AEC03.9080304@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> Message-ID: <20140918104027.4165205d@willson.usersys.redhat.com> On Thu, 18 Sep 2014 16:28:19 +0200 Martin Kosek wrote: > On 09/18/2014 04:06 PM, David Kupka wrote: > > On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >> David Kupka wrote: > >>> https://fedorahosted.org/freeipa/ticket/4421 > >> > >> You are removing an ACI in this patch. It is always possible it is > >> no longer needed. Did you test all the client enrollment scenarios? > >> > >> rob > >> > > > > As far as I'm aware I'm not removing any ACI. I'm modifying ACI so > > it is possible to add krbPrincipalName to host even when there is > > already one (or more). And adding one ACI to allow writing > > krbCanonicalName to host. But I'm still not really familiar with > > ACI so please correct me if I'm wrong. > > > > What refers to is probably the update in ACI.txt - the ACI > alternative to API.txt. David updated an ACI, not removed it. > > On that note, what is the reason for this permission change: > > - 'ipapermtargetfilter': [ > - '(objectclass=ipahost)', > - '(!(krbprincipalname=*))', > - ], > > ? I think also both the code and the tests are missing to ensure that the krbPrincipalName *also* *always* lists the krbCanonicalName. I think with the current code you can end up in a situation where you can have a value in KrbCanonicalName and completely different values in KrbPrincipalName. Simo. -- Simo Sorce * Red Hat, Inc * New York From dkupka at redhat.com Thu Sep 18 14:41:48 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Sep 2014 16:41:48 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541AEC03.9080304@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> Message-ID: <541AEF2C.8020507@redhat.com> On 09/18/2014 04:28 PM, Martin Kosek wrote: > On 09/18/2014 04:06 PM, David Kupka wrote: >> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>> David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4421 >>> >>> You are removing an ACI in this patch. It is always possible it is no >>> longer needed. Did you test all the client enrollment scenarios? >>> >>> rob >>> >> >> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so it is >> possible to add krbPrincipalName to host even when there is already one (or >> more). And adding one ACI to allow writing krbCanonicalName to host. >> But I'm still not really familiar with ACI so please correct me if I'm wrong. >> > > What refers to is probably the update in ACI.txt - the ACI alternative to > API.txt. David updated an ACI, not removed it. > > On that note, what is the reason for this permission change: > > - 'ipapermtargetfilter': [ > - '(objectclass=ipahost)', > - '(!(krbprincipalname=*))', > - ], > > ? To allow additional krbPrincipalNames. This behavior is requested by the ticket. > > Martin > -- David Kupka From dkupka at redhat.com Thu Sep 18 14:44:50 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Sep 2014 16:44:50 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <20140918104027.4165205d@willson.usersys.redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <20140918104027.4165205d@willson.usersys.redhat.com> Message-ID: <541AEFE2.10504@redhat.com> On 09/18/2014 04:40 PM, Simo Sorce wrote: > On Thu, 18 Sep 2014 16:28:19 +0200 > Martin Kosek wrote: > >> On 09/18/2014 04:06 PM, David Kupka wrote: >>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>>> David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4421 >>>> >>>> You are removing an ACI in this patch. It is always possible it is >>>> no longer needed. Did you test all the client enrollment scenarios? >>>> >>>> rob >>>> >>> >>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so >>> it is possible to add krbPrincipalName to host even when there is >>> already one (or more). And adding one ACI to allow writing >>> krbCanonicalName to host. But I'm still not really familiar with >>> ACI so please correct me if I'm wrong. >>> >> >> What refers to is probably the update in ACI.txt - the ACI >> alternative to API.txt. David updated an ACI, not removed it. >> >> On that note, what is the reason for this permission change: >> >> - 'ipapermtargetfilter': [ >> - '(objectclass=ipahost)', >> - '(!(krbprincipalname=*))', >> - ], >> >> ? > > I think also both the code and the tests are missing to ensure that > the krbPrincipalName *also* *always* lists the krbCanonicalName. > > I think with the current code you can end up in a situation where you > can have a value in KrbCanonicalName and completely different values in > KrbPrincipalName. I didn't realize that there is such requirement although it's logical. I will fix it, thanks. > > Simo. > -- David Kupka From mbasti at redhat.com Thu Sep 18 16:34:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Sep 2014 18:34:36 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <541AD906.4000006@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> Message-ID: <541B099C.9060606@redhat.com> ... 1) + if options.unattended: + for ip in ip_addresses: + if search_reverse_zones and find_reverse_zone(str(ip)): + # reverse zone is already in LDAP + continue + for rz in ret_reverse_zones: + if verify_reverse_zone(rz, ip): + # reverse zone was entered by user + break + else: + rz = get_reverse_zone_default(str(ip)) + ret_reverse_zones.append(rz) + elif options.reverse_zones or create_reverse(): + for ip in ip_addresses: + if search_reverse_zones and find_reverse_zone(str(ip)): + # reverse zone is already in LDAP + continue + for rz in ret_reverse_zones: + if verify_reverse_zone(rz, ip): + # reverse zone was entered by user + break + else: + rz = get_reverse_zone_default(str(ip)) + rz = read_reverse_zone(rz, str(ip)) + ret_reverse_zones.append(rz) + else: + options.no_reverse = True + ret_reverse_zones = [] You can make it shorter without duplications: # this ifs can be in one line if not options.unatended: if not options.reverse_zones if not create_reverse(): options.no_reverse=True return [] for ip in ip_addresses: if search_reverse_zones and find_reverse_zone(str(ip)): # reverse zone is already in LDAP continue for rz in ret_reverse_zones: if verify_reverse_zone(rz, ip): # reverse zone was entered by user break else: rz = get_reverse_zone_default(str(ip)) if not options.unattended: rz = read_reverse_zone(rz, str(ip)) ret_reverse_zones.append(rz) 2) Typo? There is no IP address matching reverze_zone %s." ---------------------------------------------^^ 3) Would be nice to ask user to create new zones only if new zones are required. (If all required zones exist in LDAP, you ask user anyway) 4) Ask framework gurus, if installutils module is better place for function above -- Martin Basti From npmccallum at redhat.com Thu Sep 18 17:56:44 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Sep 2014 13:56:44 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute Message-ID: <1411063004.3757.2.camel@redhat.com> This makes ipatokenTOTPwatermark have exactly the same semantics as ipatokenHOTPcounter. NOTE: This patch includes an update plugin which will update existing token objects. This should be low impact since it only updates TOTP tokens which have never been used. TOTP tokens which have already been used should already have ipatokenTOTPwatermark set. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0066-Make-ipatokenTOTPwatermark-a-required-attribute.patch Type: text/x-patch Size: 6383 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 18 17:59:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Sep 2014 13:59:34 -0400 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates In-Reply-To: <541AC95D.6090202@redhat.com> References: <1409280891.9966.11.camel@redhat.com> <1410808094.4238.7.camel@redhat.com> <541AC95D.6090202@redhat.com> Message-ID: <1411063174.3757.4.camel@redhat.com> On Thu, 2014-09-18 at 14:00 +0200, Petr Vobornik wrote: > On 15.9.2014 21:08, Nathaniel McCallum wrote: > > 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 > > > > I still need a review of this. This is targeted for 4.1. > > > > Nathaniel > > > > > Works fine with HTOP but fails for new TOTP tokens. > > New TOTP token doesn't have a watermark attribute set so there is > nothing to delete and therefore standard login procedure fails on > writeattr call (libotp.c:223). I have fixed this by making ipatokenTOTPwatermark a required attribute (MAY -> MUST). I did this in a separate patch (0066) because I thought it was cleaner. https://www.redhat.com/archives/freeipa-devel/2014-September/msg00386.html There is no change to this patch, but it now depends on my patch 0066 (linked above). Nathaniel From npmccallum at redhat.com Thu Sep 18 18:00:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Sep 2014 14:00:23 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <1411063004.3757.2.camel@redhat.com> References: <1411063004.3757.2.camel@redhat.com> Message-ID: <1411063223.3757.5.camel@redhat.com> On Thu, 2014-09-18 at 13:56 -0400, Nathaniel McCallum wrote: > This makes ipatokenTOTPwatermark have exactly the same semantics as > ipatokenHOTPcounter. > > NOTE: This patch includes an update plugin which will update existing > token objects. This should be low impact since it only updates TOTP > tokens which have never been used. TOTP tokens which have already been > used should already have ipatokenTOTPwatermark set. FYI, this patch is now a prerequisite of my patch 0062. From simo at redhat.com Thu Sep 18 18:18:49 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 14:18:49 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <1411063004.3757.2.camel@redhat.com> References: <1411063004.3757.2.camel@redhat.com> Message-ID: <20140918141849.71a27138@willson.usersys.redhat.com> On Thu, 18 Sep 2014 13:56:44 -0400 Nathaniel McCallum wrote: > -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' > SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ > ipatokenTOTPtimeStep) MAY (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > +objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' > SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ > ipatokenTOTPtimeStep $ ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') NACK, you cannot move from MAY to MUST. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Sep 18 18:20:14 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 14:20:14 -0400 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates In-Reply-To: <1411063174.3757.4.camel@redhat.com> References: <1409280891.9966.11.camel@redhat.com> <1410808094.4238.7.camel@redhat.com> <541AC95D.6090202@redhat.com> <1411063174.3757.4.camel@redhat.com> Message-ID: <20140918142014.4b76280c@willson.usersys.redhat.com> On Thu, 18 Sep 2014 13:59:34 -0400 Nathaniel McCallum wrote: > On Thu, 2014-09-18 at 14:00 +0200, Petr Vobornik wrote: > > On 15.9.2014 21:08, Nathaniel McCallum wrote: > > > 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 > > > > > > I still need a review of this. This is targeted for 4.1. > > > > > > Nathaniel > > > > > > > > > Works fine with HTOP but fails for new TOTP tokens. > > > > New TOTP token doesn't have a watermark attribute set so there is > > nothing to delete and therefore standard login procedure fails on > > writeattr call (libotp.c:223). > > I have fixed this by making ipatokenTOTPwatermark a required attribute > (MAY -> MUST). I did this in a separate patch (0066) because I thought > it was cleaner. This can easily break stuff, and is not allowed, sorry you need to find a way that will not cause objects, even temporarily to be incomplete. (think of a replica getting the new schema while an older one pushes the object via replication) Simo. > https://www.redhat.com/archives/freeipa-devel/2014-September/msg00386.html > > There is no change to this patch, but it now depends on my patch 0066 > (linked above). > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Sep 18 18:22:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Sep 2014 14:22:07 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <20140918141849.71a27138@willson.usersys.redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> Message-ID: <1411064527.3757.8.camel@redhat.com> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: > On Thu, 18 Sep 2014 13:56:44 -0400 > Nathaniel McCallum wrote: > > > -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' > > SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ > > ipatokenTOTPtimeStep) MAY (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > > +objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' > > SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ > > ipatokenTOTPtimeStep $ ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > > NACK, you cannot move from MAY to MUST. This is precisely what we have been discussing on IRC today. The consensus was that this was acceptable because of the update plugin and the rarity of the state in which a token would not have ipatokenTOTPwatermark set (the token has to be created an never used). Nathaniel From simo at redhat.com Thu Sep 18 18:27:09 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 14:27:09 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <1411064527.3757.8.camel@redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> <1411064527.3757.8.camel@redhat.com> Message-ID: <20140918142709.030c230b@willson.usersys.redhat.com> On Thu, 18 Sep 2014 14:22:07 -0400 Nathaniel McCallum wrote: > On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: > > On Thu, 18 Sep 2014 13:56:44 -0400 > > Nathaniel McCallum wrote: > > > > > -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME > > > 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' > > > MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ > > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY > > > (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses: > > > (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken > > > STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > > > ipatokenOTPalgorithm $ ipatokenOTPdigits $ > > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $ > > > ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > > > > NACK, you cannot move from MAY to MUST. > > This is precisely what we have been discussing on IRC today. The > consensus was that this was acceptable because of the update plugin > and the rarity of the state in which a token would not have > ipatokenTOTPwatermark set (the token has to be created an never used). Sorry I was not around, but it is never acceptable, as it may cause replication failures. This has been a long (albeit perhaps unspoken) rule in changing schema in FreeIPA. Existing objectlasses can *never* gain new MUST attributes. This rule is rigid and is non-negotiable. Sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Sep 18 18:57:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 14:57:45 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541AEC03.9080304@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> Message-ID: <541B2B29.6060005@redhat.com> Martin Kosek wrote: > On 09/18/2014 04:06 PM, David Kupka wrote: >> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>> David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4421 >>> >>> You are removing an ACI in this patch. It is always possible it is no >>> longer needed. Did you test all the client enrollment scenarios? >>> >>> rob >>> >> >> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so it is >> possible to add krbPrincipalName to host even when there is already one (or >> more). And adding one ACI to allow writing krbCanonicalName to host. >> But I'm still not really familiar with ACI so please correct me if I'm wrong. >> > > What refers to is probably the update in ACI.txt - the ACI alternative to > API.txt. David updated an ACI, not removed it. > > On that note, what is the reason for this permission change: > > - 'ipapermtargetfilter': [ > - '(objectclass=ipahost)', > - '(!(krbprincipalname=*))', > - ], > > ? Yes, this is exactly the change I was referring to. Permission changes within a plugin now translate automatically to ACI changes. Sorry I wasn't clearer. This ACI gets replaced with a much simpler one and I'm not 100% sure it will work with all enrollments: -aci: (targetattr = "krbprincipalname")(targetfilter = "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl "permission:System: Add krbPrincipalName to a Host";allow (write) groupdn = "ldap:///cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) +aci: (targetattr = "krbprincipalname")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add krbPrincipalName to a Host";allow (write) groupdn = "ldap:///cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) The first one restricts writing the attribute only if it isn't already set. The second lets it be changed unconditionally. rob From simo at redhat.com Thu Sep 18 19:11:55 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 15:11:55 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541B2B29.6060005@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> Message-ID: <20140918151155.52e96806@willson.usersys.redhat.com> On Thu, 18 Sep 2014 14:57:45 -0400 Rob Crittenden wrote: > Martin Kosek wrote: > > On 09/18/2014 04:06 PM, David Kupka wrote: > >> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >>> David Kupka wrote: > >>>> https://fedorahosted.org/freeipa/ticket/4421 > >>> > >>> You are removing an ACI in this patch. It is always possible it > >>> is no longer needed. Did you test all the client enrollment > >>> scenarios? > >>> > >>> rob > >>> > >> > >> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so > >> it is possible to add krbPrincipalName to host even when there is > >> already one (or more). And adding one ACI to allow writing > >> krbCanonicalName to host. But I'm still not really familiar with > >> ACI so please correct me if I'm wrong. > >> > > > > What refers to is probably the update in ACI.txt - the ACI > > alternative to API.txt. David updated an ACI, not removed it. > > > > On that note, what is the reason for this permission change: > > > > - 'ipapermtargetfilter': [ > > - '(objectclass=ipahost)', > > - '(!(krbprincipalname=*))', > > - ], > > > > ? > > Yes, this is exactly the change I was referring to. Permission changes > within a plugin now translate automatically to ACI changes. Sorry I > wasn't clearer. > > This ACI gets replaced with a much simpler one and I'm not 100% sure > it will work with all enrollments: > > -aci: (targetattr = "krbprincipalname")(targetfilter = > "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl > "permission:System: Add krbPrincipalName to a Host";allow (write) > groupdn = "ldap:///cn=System: Add krbPrincipalName to a > Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > +aci: (targetattr = "krbprincipalname")(targetfilter = > "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add > krbPrincipalName to a Host";allow (write) groupdn = > "ldap:///cn=System: Add krbPrincipalName to a > Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > The first one restricts writing the attribute only if it isn't already > set. The second lets it be changed unconditionally. Yeah this is wrong indeed, the point of the ACI is to allow setting the principal only when it is not already set, which is the OTP enrollment case. But if krbprincipal is set then this specific permission should not grant rights to change it. At least this was my understanding. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Sep 18 19:42:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Sep 2014 21:42:33 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <20140918151155.52e96806@willson.usersys.redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> Message-ID: <541B35A9.7010404@redhat.com> On 09/18/2014 09:11 PM, Simo Sorce wrote: > On Thu, 18 Sep 2014 14:57:45 -0400 > Rob Crittenden wrote: > >> Martin Kosek wrote: >>> On 09/18/2014 04:06 PM, David Kupka wrote: >>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>>>> David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4421 >>>>> >>>>> You are removing an ACI in this patch. It is always possible it >>>>> is no longer needed. Did you test all the client enrollment >>>>> scenarios? >>>>> >>>>> rob >>>>> >>>> >>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so >>>> it is possible to add krbPrincipalName to host even when there is >>>> already one (or more). And adding one ACI to allow writing >>>> krbCanonicalName to host. But I'm still not really familiar with >>>> ACI so please correct me if I'm wrong. >>>> >>> >>> What refers to is probably the update in ACI.txt - the ACI >>> alternative to API.txt. David updated an ACI, not removed it. >>> >>> On that note, what is the reason for this permission change: >>> >>> - 'ipapermtargetfilter': [ >>> - '(objectclass=ipahost)', >>> - '(!(krbprincipalname=*))', >>> - ], >>> >>> ? >> >> Yes, this is exactly the change I was referring to. Permission changes >> within a plugin now translate automatically to ACI changes. Sorry I >> wasn't clearer. >> >> This ACI gets replaced with a much simpler one and I'm not 100% sure >> it will work with all enrollments: >> >> -aci: (targetattr = "krbprincipalname")(targetfilter = >> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >> "permission:System: Add krbPrincipalName to a Host";allow (write) >> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> >> +aci: (targetattr = "krbprincipalname")(targetfilter = >> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >> krbPrincipalName to a Host";allow (write) groupdn = >> "ldap:///cn=System: Add krbPrincipalName to a >> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> >> The first one restricts writing the attribute only if it isn't already >> set. The second lets it be changed unconditionally. > > Yeah this is wrong indeed, the point of the ACI is to allow setting the > principal only when it is not already set, which is the OTP enrollment > case. But if krbprincipal is set then this specific permission should > not grant rights to change it. > > At least this was my understanding. > > Simo. Right. It seems to me we should add keep this permission intact and add a new permission allowing adding krbPrincipalName aliases. This would allow writing both krbPrincipalName and krbCanonicalName. Martin From lkrispen at redhat.com Fri Sep 19 07:08:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 19 Sep 2014 09:08:46 +0200 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <20140918142709.030c230b@willson.usersys.redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> <1411064527.3757.8.camel@redhat.com> <20140918142709.030c230b@willson.usersys.redhat.com> Message-ID: <541BD67E.6070003@redhat.com> On 09/18/2014 08:27 PM, Simo Sorce wrote: > On Thu, 18 Sep 2014 14:22:07 -0400 > Nathaniel McCallum wrote: > >> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: >>> On Thu, 18 Sep 2014 13:56:44 -0400 >>> Nathaniel McCallum wrote: >>> >>>> -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME >>>> 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' >>>> MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY >>>> (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses: >>>> (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken >>>> STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ >>>> ipatokenOTPalgorithm $ ipatokenOTPdigits $ >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $ >>>> ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') >>> NACK, you cannot move from MAY to MUST. >> This is precisely what we have been discussing on IRC today. The >> consensus was that this was acceptable because of the update plugin >> and the rarity of the state in which a token would not have >> ipatokenTOTPwatermark set (the token has to be created an never used). > Sorry I was not around, but it is never acceptable, as it may cause > replication failures. I agree that this shouldn't be done, although replication should not be a problem, the consumer relies on the schema checking of the server where the operation was originally applied. But problems may show up for existing entries, if you have an an entry without attr A, which now becomes MUST and then do any modification on this entry, after the mod the entry will be schema checked, the missing attribute detected and the mod rejected > > This has been a long (albeit perhaps unspoken) rule in changing schema > in FreeIPA. if you want to define the rules for schema change somewhere, you should add this as well: never make a multivalued attribute singlevalued > > Existing objectlasses can *never* gain new MUST attributes. This rule > is rigid and is non-negotiable. If you want to ensure that every entry has a specific attribute, but connot enforce this by the schema, an option would be to define a CoS rule for this attr which defines a default and gives the real attr precedence > > Sorry. > Simo. > From mbasti at redhat.com Fri Sep 19 11:25:47 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 13:25:47 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121, 0123-0125] DNS: allow to add root zone '.' In-Reply-To: <5417F4F5.1050907@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> Message-ID: <541C12BB.6000901@redhat.com> On 16/09/14 10:29, Petr Spacek wrote: > On 16.9.2014 10:09, Martin Kosek wrote: >> On 09/16/2014 09:57 AM, Martin Basti wrote: >>> On 16/09/14 09:32, Martin Basti wrote: >>>> On 15/09/14 20:31, Martin Kosek wrote: >>>>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>>>> 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 >>>>>>>>>>> Functional ACK, it works for me. It can be pushed if Python >>>>>>>>>>> gurus are >>>>>>>>>>> okay >>>>>>>>>>> with >>>>>>>>>>> the code. >>>>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap >>>>>>>>>> still crash >>>>>>>>>> when >>>>>>>>>> "." >>>>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>>>> >>>>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>>>>>> Hopefully it >>>>>>>>>> would be soon. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is >>>>>>>>> fixed. >>>>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>>>> >>>>>>>> Added patches 120 and 121, which are required by DNS to work >>>>>>>> correctly. >>>>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>>>>>> --name-server >>>>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>>>> >>>>>>>> Original and new patches attached. >>>>>>> >>>>>>> NACK, unfortunately it doesn't work for me: >>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>>> ipa: WARNING: '--name-server' is used only for setting up the >>>>>>> SOA MNAME >>>>>>> record. >>>>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod >>>>>>> [zone] @ >>>>>>> --ns-rec=nameserver'. >>>>>>> Zone name: tri.test. >>>>>>> Active zone: TRUE >>>>>>> Authoritative nameserver: ns.test. >>>>>>> Administrator e-mail address: hostmaster.tri.test. >>>>>>> SOA serial: 1410793406 >>>>>>> SOA refresh: 3600 >>>>>>> SOA retry: 900 >>>>>>> SOA expire: 1209600 >>>>>>> SOA minimum: 3600 >>>>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant >>>>>>> IPA.EXAMPLE >>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>> Dynamic update: FALSE >>>>>>> Allow query: any; >>>>>>> Allow transfer: none; >>>>>>> >>>>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>>>> idnsname: tri.test. >>>>>>> idnszoneactive: TRUE >>>>>>> idnssoamname: ns.test. >>>>>>> idnssoarname: hostmaster.tri.test. >>>>>>> idnssoaserial: 1410793408 >>>>>>> idnssoarefresh: 3600 >>>>>>> idnssoaretry: 900 >>>>>>> idnssoaexpire: 1209600 >>>>>>> idnssoaminimum: 3600 >>>>>>> idnsallowquery: any; >>>>>>> idnsallowtransfer: none; >>>>>>> idnsAllowDynUpdate: FALSE >>>>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant >>>>>>> IPA.EXAMPLE >>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>>>> objectClass: idnszone >>>>>>> objectClass: top >>>>>>> objectClass: idnsrecord >>>>>>> >>>>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. >>>>>>> --ns-rec=$(hostname). >>>>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>>>> >>>>>> NACKing NACK >>>>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>> you switched order zone and record, it should be >>>>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>>>> >>>>> >>>>> BTW, since we are so nicely breaking the dnszone-add interface, >>>>> can we also >>>>> get rid of always asking for "Administrator e-mail address"? >>>>> >>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>> ... >>>>> >>>>> Is there any risk in filling that with default as any other >>>>> attribute? IMO >>>>> it would simplify adding zones for one more redundant step. CCing >>>>> Rob in >>>>> case he knows some historical reasons why this is requested every >>>>> time. >>>>> >>>>> Martin >>>> There is no risk, because ipa-replica-prepare do that with default >>>> values >> >> Then let us do this, as we are already simplifying the dnszone-add >> command. >> >>> However, this will not work with root zone ".", and I'm not sure >>> how often an >>> admin email is used. I think whois is better utility to get contact >>> email. >>> >>> Also RIPE-203 [1] recommends to use 'hostmaster' alias. >>> >>> [1] http://www.ripe.net/ripe/docs/ripe-203 > > This will likely generate tons of invalid e-mail addresses which is > somehow unfortunate. > > Please keep in mind that: > 1) E-mail hostmaster at ipa.domain.example. will be useful only if > ipa.domain.example. has MX record or at least A/AAAA record (which is > usually not the case for domains). > > 2) WHOIS is not useful for internal domains which is the main > deployment scenario for IPA, right? > >> DNS zone "." is quite an exception, you are not adding that zone >> every day. So >> I would not keep asking for admin mail just for this one. You can add a >> interactive prompt callback to ask in this case and otherwise just >> use the >> default - up to you. >> >> As for the mail alias, this can be an RFE. > > It would be nice to have some IPA-global default like 'DNS > administrator e-mail address' and to use this value for all DNS zones > by default. > Updated patches attached. Design page: http://www.freeipa.org/page/V4/DNS:_Automatic_Zone_NS/SOA_Record_Maintenance -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114.2-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.2-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120.2-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 12536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121.2-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0123.2-DNS-autofill-admin-email.patch Type: text/x-patch Size: 4778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0124.2-WebUI-DNS-Remove-ip-address-admin-email-options.patch Type: text/x-patch Size: 3281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0125.2-DNS-tests-tests-update-to-due-to-change-in-options.patch Type: text/x-patch Size: 61976 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 19 11:30:26 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 13:30:26 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <54048358.9000604@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> Message-ID: <541C13D2.10800@redhat.com> On 01/09/14 16:31, Martin Basti wrote: > On 24/07/14 09:06, Martin Basti wrote: >> On 23/07/14 15:17, Martin Basti wrote: >>> This patch fixes ordering problem of schema updates >>> >>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>> (will be in Fedora 21) >>> >>> Patch attached >>> >>> >> I found a bug there, but before I send updated version, I need to >> decide how print modlist: >> >> 1. Print modlist before each LDAP update (if changes exist), show >> modlist per incremental update >> >> 2. Print modlist only at once with all updates >> >> 3. Use [1] for live_run, [2] for test >> > Print modlis before each LDAP update > Updated patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please review, this should be in 4.1 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 19 11:32:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 13:32:51 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <54048203.4060708@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> Message-ID: <541C1463.6080502@redhat.com> On 01/09/14 16:26, Martin Basti wrote: > On 28/08/14 14:01, Jan Cholasta wrote: >> 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 >> > 3) skipped as we discuss on IRC > > Updated patch attached > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please review, this should be in 4.1 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 19 11:33:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 13:33:56 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <540594F3.2030001@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> Message-ID: <541C14A4.2010907@redhat.com> On 02/09/14 11:59, Martin Basti wrote: > On 02/09/14 09:10, Jan Cholasta wrote: >> Hi, >> >> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>> This patch allows to disable service in LDAP to prevents service to be >>> started by "ipactl restart" >>> >>> Required by DNSSEC >>> >>> Patch attached >> >> I don't think the extra argument in ldap_enable is necessary. It >> should enable the service no matter if the entry existed before or not. >> >> Similarly, in ldap_disable you should not raise an error when the >> entry is not found, because that already makes the service disabled. >> >> Honza >> > Updated patch attached > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please review, this should be in 4.1 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 19 11:50:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 13:50:21 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? Message-ID: <541C187D.3010903@redhat.com> Hello list, I need to use systemd mask/unmask in ipa service. But as Honza wrote: "IMO masking/unmasking should be part of disabling/enabling a service in systemd. AFAIK in most other init systems when you disable a service, it has the same effect as masking the service in systemd - it will never be started until it is enabled/unmasked again. " So my questions is, should be masking part of disabling service in systemd, to be platform independent? Or should we add mask/unmask methods to ipaplatform.base.services.PlatformService where mask is alias for disable? Martin^2 -- Martin Basti From mkosek at redhat.com Fri Sep 19 11:54:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Sep 2014 13:54:45 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121, 0123-0125] DNS: allow to add root zone '.' In-Reply-To: <541C12BB.6000901@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> <541C12BB.6000901@redhat.com> Message-ID: <541C1985.9070802@redhat.com> I did not review, just found something that hit me in the eyes: On 09/19/2014 01:25 PM, Martin Basti wrote: > +class OptionDeprecatedWarning(PublicMessage): > + """ > + **13004** Used when user uses a deprecated option > + """ > + > + errno = 13004 > + type = "warning" > + format = _(u"'%(option)s' option is deprecated. %(additional_info)s") > + > + > +class OptionNameServerWarning(PublicMessage): > + """ > + **13005** Used when user uses a dnszone-add/mod --name-server option > + """ > + > + errno = 13005 > + type = "warning" > + format = _(u"'--name-server' is used only for setting up the SOA MNAME attribute.\n" > + u"To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ --ns-rec=nameserver'.") OptionNameServerWarning has a nice generic name, but the format is not that generic, compared to OptionDeprecatedWarning. I think we should follow the approach as in OptionDeprecatedWarning so that the warning can be reused. This is not urgent though, you can wait with the fix until Petr2 or somebody else sends you other notes... Martin From jcholast at redhat.com Fri Sep 19 12:30:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 19 Sep 2014 14:30:03 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <541C1463.6080502@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> Message-ID: <541C21CB.8050202@redhat.com> Dne 19.9.2014 v 13:32 Martin Basti napsal(a): > On 01/09/14 16:26, Martin Basti wrote: >> On 28/08/14 14:01, Jan Cholasta wrote: >>> 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 >>> >> 3) skipped as we discuss on IRC >> >> Updated patch attached >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Please review, this should be in 4.1 1) The patch need a rebase on top of current ipa-4-1. 2) You can remove import pwd from service.py, it is no longer used there. 3) Are named constants for the autobind argument the right thing to do? It is a tri-state which can be expressed with None/True/False. (I'm just asking, I don't have a strong opinion on this.) -- Jan Cholasta From pvoborni at redhat.com Fri Sep 19 12:29:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Sep 2014 14:29:13 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section Message-ID: <541C2199.8010404@redhat.com> Hello, attached patches implements Web UI part of ID Views. Backend is currently on review as well - thread "[PATCHES 247-259] ID views - management part". https://fedorahosted.org/freeipa/ticket/4535 I expect that backed can change and that the UI might influence it as well. Therefore no UI integration tests nor static data files are included in this patchset. They will follow when backend is stable. First 5 patches extends UI framework to support the main patch (#754). == [PATCH] 749 webui: improve breadcrumb navigation == Fixes issue when: - user navigates to a nested facet - refreshes browser - uses breadcrumb navigation to go to parent entity page which requires a pkey. E.g. from automount keys to maps. The old code relies on the facet, that user visited the parent facet before and therefore the facet has pkey stored. It fails after the browser reload. Allows to specify a containing_facet. It allows breadcrumb navigation to return to a different facet than the 'default'. == [PATCH] 750 webui: treat value as pkey in link widget == Current default mechanism of a link widget assumes that pkeys of a current facet are pkeys for the link. It works for the only usage - in password policy. It's rather inflexible since it can't be used if the keys are in other attribute. This behavior is also bad in nested entities - creates a link to itself which is pointless. This patch changes the default behavior to assume that the supplied value are the pkeys and that the last pkey is the value to display. It also keeps the old method of overriding `other_pkeys` method so if the last and only pkey is the actual value to display then the method can tranform it into the pkeys which keeps compatibility with descendant widgets (`host_dnsrecord_entity_link_widget`, `dnsrecord_host_link_widget`). == [PATCH] 751 webui: do not show internal facet name to user == == [PATCH] 752 webui: allow to skip link widget link validation == == [PATCH] 753 webui: add simple link column suppor == Usual link columns are link with primary key of current entity. This patch allows to create a link to arbitrary non-nested entity. == [PATCH] 754 webui: new ID views section == -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0754-webui-new-ID-views-section.patch Type: text/x-patch Size: 31851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0753-webui-add-simple-link-column-support.patch Type: text/x-patch Size: 2305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0752-webui-allow-to-skip-link-widget-link-validation.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0751-webui-do-not-show-internal-facet-name-to-user.patch Type: text/x-patch Size: 867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0750-webui-treat-value-as-pkey-in-link-widget.patch Type: text/x-patch Size: 2011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0749-webui-improve-breadcrumb-navigation.patch Type: text/x-patch Size: 3833 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 19 12:39:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 14:39:22 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <541C21CB.8050202@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> Message-ID: <541C23FA.70809@redhat.com> On 19/09/14 14:30, Jan Cholasta wrote: > Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >> On 01/09/14 16:26, Martin Basti wrote: >>> On 28/08/14 14:01, Jan Cholasta wrote: >>>> 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 >>>> >>> 3) skipped as we discuss on IRC >>> >>> Updated patch attached >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Please review, this should be in 4.1 > Thank you for review > 1) The patch need a rebase on top of current ipa-4-1. > > > 2) You can remove import pwd from service.py, it is no longer used there. > > > 3) Are named constants for the autobind argument the right thing to > do? It is a tri-state which can be expressed with None/True/False. > (I'm just asking, I don't have a strong opinion on this.) > Seems like good Idea to me, is clear enough to have AUTO=None, DISABLED=False, ENABLED=True? -- Martin Basti From jcholast at redhat.com Fri Sep 19 12:47:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 19 Sep 2014 14:47:07 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <541C14A4.2010907@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> <541C14A4.2010907@redhat.com> Message-ID: <541C25CB.8060801@redhat.com> Dne 19.9.2014 v 13:33 Martin Basti napsal(a): > On 02/09/14 11:59, Martin Basti wrote: >> On 02/09/14 09:10, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>>> This patch allows to disable service in LDAP to prevents service to be >>>> started by "ipactl restart" >>>> >>>> Required by DNSSEC >>>> >>>> Patch attached >>> >>> I don't think the extra argument in ldap_enable is necessary. It >>> should enable the service no matter if the entry existed before or not. >>> >>> Similarly, in ldap_disable you should not raise an error when the >>> entry is not found, because that already makes the service disabled. >>> >>> Honza >>> >> Updated patch attached >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Please review, this should be in 4.1 > > -- > Martin Basti 1) ipaConfigString is case-insensitive, so you need to look for the string "enabledService" in a case-insensitive way. 2) Don't say "failed to enable ..." when the service is already enabled. It is not a failure. Same for disabled. 3) Missing ipaConfigString is nothing to warn about. 4) You should log success in both ldap_enable/ldap_disable. 5) The except below update_entry should say "except errors.EmptyModlist". -- Jan Cholasta From jcholast at redhat.com Fri Sep 19 12:48:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 19 Sep 2014 14:48:03 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <541C23FA.70809@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> <541C23FA.70809@redhat.com> Message-ID: <541C2603.70204@redhat.com> Dne 19.9.2014 v 14:39 Martin Basti napsal(a): > On 19/09/14 14:30, Jan Cholasta wrote: >> Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >>> On 01/09/14 16:26, Martin Basti wrote: >>>> On 28/08/14 14:01, Jan Cholasta wrote: >>>>> 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 >>>>> >>>> 3) skipped as we discuss on IRC >>>> >>>> Updated patch attached >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Please review, this should be in 4.1 >> > Thank you for review > >> 1) The patch need a rebase on top of current ipa-4-1. >> >> >> 2) You can remove import pwd from service.py, it is no longer used there. >> >> >> 3) Are named constants for the autobind argument the right thing to >> do? It is a tri-state which can be expressed with None/True/False. >> (I'm just asking, I don't have a strong opinion on this.) >> > Seems like good Idea to me, > is clear enough to have AUTO=None, DISABLED=False, ENABLED=True? > Well, I'm not sure, that's why I'm asking :) -- Jan Cholasta From pspacek at redhat.com Fri Sep 19 13:46:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Sep 2014 15:46:26 +0200 Subject: [Freeipa-devel] [PATCH 0298-0302] Implement handling of inactive master zones Message-ID: <541C33B2.7070303@redhat.com> Hello, This patch set fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/127 https://bugzilla.redhat.com/show_bug.cgi?id=1138317 Please review it ASAP, it targets IPA 4.1/Fedora 21. Tomas and Martin, please communicate who is going to review what :-) Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0298-Rework-all-functions-in-zone_register.c-to-work-with.patch Type: text/x-patch Size: 23670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0299-Remove-redundant-code-from-zone_register.c.patch Type: text/x-patch Size: 6899 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0300-Rework-all-functions-in-fwd_register.c-to-work-with-.patch Type: text/x-patch Size: 3301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0301-Rework-handling-of-inactive-forward-zones.patch Type: text/x-patch Size: 3734 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0302-Implement-handling-of-inactive-master-zones.patch Type: text/x-patch Size: 9763 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 19 13:55:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Sep 2014 15:55:15 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541B35A9.7010404@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> Message-ID: <541C35C3.6040304@redhat.com> On 09/18/2014 09:42 PM, Martin Kosek wrote: > On 09/18/2014 09:11 PM, Simo Sorce wrote: >> On Thu, 18 Sep 2014 14:57:45 -0400 >> Rob Crittenden wrote: >> >>> Martin Kosek wrote: >>>> On 09/18/2014 04:06 PM, David Kupka wrote: >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>>>>> David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 >>>>>> >>>>>> You are removing an ACI in this patch. It is always possible it >>>>>> is no longer needed. Did you test all the client enrollment >>>>>> scenarios? >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so >>>>> it is possible to add krbPrincipalName to host even when there is >>>>> already one (or more). And adding one ACI to allow writing >>>>> krbCanonicalName to host. But I'm still not really familiar with >>>>> ACI so please correct me if I'm wrong. >>>>> >>>> >>>> What refers to is probably the update in ACI.txt - the ACI >>>> alternative to API.txt. David updated an ACI, not removed it. >>>> >>>> On that note, what is the reason for this permission change: >>>> >>>> - 'ipapermtargetfilter': [ >>>> - '(objectclass=ipahost)', >>>> - '(!(krbprincipalname=*))', >>>> - ], >>>> >>>> ? >>> >>> Yes, this is exactly the change I was referring to. Permission changes >>> within a plugin now translate automatically to ACI changes. Sorry I >>> wasn't clearer. >>> >>> This ACI gets replaced with a much simpler one and I'm not 100% sure >>> it will work with all enrollments: >>> >>> -aci: (targetattr = "krbprincipalname")(targetfilter = >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >>> "permission:System: Add krbPrincipalName to a Host";allow (write) >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> +aci: (targetattr = "krbprincipalname")(targetfilter = >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >>> krbPrincipalName to a Host";allow (write) groupdn = >>> "ldap:///cn=System: Add krbPrincipalName to a >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> The first one restricts writing the attribute only if it isn't already >>> set. The second lets it be changed unconditionally. >> >> Yeah this is wrong indeed, the point of the ACI is to allow setting the >> principal only when it is not already set, which is the OTP enrollment >> case. But if krbprincipal is set then this specific permission should >> not grant rights to change it. >> >> At least this was my understanding. >> >> Simo. > > Right. It seems to me we should add keep this permission intact and add a new > permission allowing adding krbPrincipalName aliases. This would allow writing > both krbPrincipalName and krbCanonicalName. > > Martin Simo, Rob - are you OK with this approach? I.e. having a new permission just for allowing adding aliases and not touching the enrollment-related permission? I would assign that new permission to Host Administrators privilege by default. Martin From simo at redhat.com Fri Sep 19 14:09:12 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Sep 2014 10:09:12 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541C35C3.6040304@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <541C35C3.6040304@redhat.com> Message-ID: <20140919100912.031536d4@willson.usersys.redhat.com> On Fri, 19 Sep 2014 15:55:15 +0200 Martin Kosek wrote: > On 09/18/2014 09:42 PM, Martin Kosek wrote: > > On 09/18/2014 09:11 PM, Simo Sorce wrote: > >> On Thu, 18 Sep 2014 14:57:45 -0400 > >> Rob Crittenden wrote: > >> > >>> Martin Kosek wrote: > >>>> On 09/18/2014 04:06 PM, David Kupka wrote: > >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >>>>>> David Kupka wrote: > >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 > >>>>>> > >>>>>> You are removing an ACI in this patch. It is always possible it > >>>>>> is no longer needed. Did you test all the client enrollment > >>>>>> scenarios? > >>>>>> > >>>>>> rob > >>>>>> > >>>>> > >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI > >>>>> so it is possible to add krbPrincipalName to host even when > >>>>> there is already one (or more). And adding one ACI to allow > >>>>> writing krbCanonicalName to host. But I'm still not really > >>>>> familiar with ACI so please correct me if I'm wrong. > >>>>> > >>>> > >>>> What refers to is probably the update in ACI.txt - the ACI > >>>> alternative to API.txt. David updated an ACI, not removed it. > >>>> > >>>> On that note, what is the reason for this permission change: > >>>> > >>>> - 'ipapermtargetfilter': [ > >>>> - '(objectclass=ipahost)', > >>>> - '(!(krbprincipalname=*))', > >>>> - ], > >>>> > >>>> ? > >>> > >>> Yes, this is exactly the change I was referring to. Permission > >>> changes within a plugin now translate automatically to ACI > >>> changes. Sorry I wasn't clearer. > >>> > >>> This ACI gets replaced with a much simpler one and I'm not 100% > >>> sure it will work with all enrollments: > >>> > >>> -aci: (targetattr = "krbprincipalname")(targetfilter = > >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl > >>> "permission:System: Add krbPrincipalName to a Host";allow (write) > >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a > >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> > >>> +aci: (targetattr = "krbprincipalname")(targetfilter = > >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add > >>> krbPrincipalName to a Host";allow (write) groupdn = > >>> "ldap:///cn=System: Add krbPrincipalName to a > >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> > >>> The first one restricts writing the attribute only if it isn't > >>> already set. The second lets it be changed unconditionally. > >> > >> Yeah this is wrong indeed, the point of the ACI is to allow > >> setting the principal only when it is not already set, which is > >> the OTP enrollment case. But if krbprincipal is set then this > >> specific permission should not grant rights to change it. > >> > >> At least this was my understanding. > >> > >> Simo. > > > > Right. It seems to me we should add keep this permission intact and > > add a new permission allowing adding krbPrincipalName aliases. This > > would allow writing both krbPrincipalName and krbCanonicalName. > > > > Martin > > Simo, Rob - are you OK with this approach? I.e. having a new > permission just for allowing adding aliases and not touching the > enrollment-related permission? > > I would assign that new permission to Host Administrators privilege > by default. Yeah, sounds like that would be better. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Sep 19 14:15:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 16:15:49 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option Message-ID: <541C3A95.9050504@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/3414 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0126-DNS-remove-class-option.patch Type: text/x-patch Size: 1788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0127-WebUI-DNS-remove-class-option.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 19 14:25:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Sep 2014 16:25:18 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121, 0123-0125] DNS: allow to add root zone '.' In-Reply-To: <541C1985.9070802@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> <541C12BB.6000901@redhat.com> <541C1985.9070802@redhat.com> Message-ID: <541C3CCE.1050700@redhat.com> On 19/09/14 13:54, Martin Kosek wrote: > I did not review, just found something that hit me in the eyes: > > > On 09/19/2014 01:25 PM, Martin Basti wrote: >> +class OptionDeprecatedWarning(PublicMessage): >> + """ >> + **13004** Used when user uses a deprecated option >> + """ >> + >> + errno = 13004 >> + type = "warning" >> + format = _(u"'%(option)s' option is deprecated. >> %(additional_info)s") >> + >> + >> +class OptionNameServerWarning(PublicMessage): >> + """ >> + **13005** Used when user uses a dnszone-add/mod --name-server >> option >> + """ >> + >> + errno = 13005 >> + type = "warning" >> + format = _(u"'--name-server' is used only for setting up the SOA >> MNAME attribute.\n" >> + u"To edit NS record(s) in zone apex, use command >> 'dnsrecord-mod [zone] @ --ns-rec=nameserver'.") > > > OptionNameServerWarning has a nice generic name, but the format is not > that generic, compared to OptionDeprecatedWarning. I think we should > follow the approach as in OptionDeprecatedWarning so that the warning > can be reused. > > This is not urgent though, you can wait with the fix until Petr2 or > somebody else sends you other notes... > > Martin Could be: +class OptionSemanticChangedWarning(PublicMessage): + """ + **13005** Used when user uses a dnszone-add/mod --name-server option + """ + + errno = 13005 + type = "warning" + format = _(u"' semantic of %(option)s' option was changed: %(current_behavior)s.\n %(hint)s") Example: Warning: semantic of '--name-server' option was changed: the option is used only for setting up the SOA MNAME attribute. To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ --ns-rec=nameserver'. ? -- Martin Basti From simo at redhat.com Fri Sep 19 15:06:03 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Sep 2014 11:06:03 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <541BD67E.6070003@redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> <1411064527.3757.8.camel@redhat.com> <20140918142709.030c230b@willson.usersys.redhat.com> <541BD67E.6070003@redhat.com> Message-ID: <20140919110603.0fca29e9@willson.usersys.redhat.com> On Fri, 19 Sep 2014 09:08:46 +0200 Ludwig Krispenz wrote: > > On 09/18/2014 08:27 PM, Simo Sorce wrote: > > On Thu, 18 Sep 2014 14:22:07 -0400 > > Nathaniel McCallum wrote: > > > >> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: > >>> On Thu, 18 Sep 2014 13:56:44 -0400 > >>> Nathaniel McCallum wrote: > >>> > >>>> -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME > >>>> 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' > >>>> MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ > >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY > >>>> (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses: > >>>> (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken > >>>> STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > >>>> ipatokenOTPalgorithm $ ipatokenOTPdigits $ > >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $ > >>>> ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > >>> NACK, you cannot move from MAY to MUST. > >> This is precisely what we have been discussing on IRC today. The > >> consensus was that this was acceptable because of the update plugin > >> and the rarity of the state in which a token would not have > >> ipatokenTOTPwatermark set (the token has to be created an never > >> used). > > Sorry I was not around, but it is never acceptable, as it may cause > > replication failures. > I agree that this shouldn't be done, although replication should not > be a problem, the consumer relies on the schema checking of the > server where the operation was originally applied. > But problems may show up for existing entries, if you have an an > entry without attr A, which now becomes MUST and then do any > modification on this entry, after the mod the entry will be schema > checked, the missing attribute detected and the mod rejected > > > > This has been a long (albeit perhaps unspoken) rule in changing > > schema in FreeIPA. > if you want to define the rules for schema change somewhere, you > should add this as well: never make a multivalued attribute > singlevalued Ok I added this new page: http://www.freeipa.org/page/Schema_Handling I would like to add a link to it in http://www.freeipa.org/page/Contribute/Code if I get a review and an ack for the page. > > > > Existing objectlasses can *never* gain new MUST attributes. This > > rule is rigid and is non-negotiable. > > If you want to ensure that every entry has a specific attribute, but > connot enforce this by the schema, an option would be to define a CoS > rule for this attr which defines a default and gives the real attr > precedence Yeah this is a good idea, should we add a section in that page with advice on how to handle situations where you'd like to change an objectclass/attribute but are not allowed by our rules ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Sep 19 15:21:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Sep 2014 17:21:22 +0200 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <20140919110603.0fca29e9@willson.usersys.redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> <1411064527.3757.8.camel@redhat.com> <20140918142709.030c230b@willson.usersys.redhat.com> <541BD67E.6070003@redhat.com> <20140919110603.0fca29e9@willson.usersys.redhat.com> Message-ID: <541C49F2.60500@redhat.com> On 19.9.2014 17:06, Simo Sorce wrote: > On Fri, 19 Sep 2014 09:08:46 +0200 > Ludwig Krispenz wrote: > >> >> On 09/18/2014 08:27 PM, Simo Sorce wrote: >>> On Thu, 18 Sep 2014 14:22:07 -0400 >>> Nathaniel McCallum wrote: >>> >>>> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: >>>>> On Thu, 18 Sep 2014 13:56:44 -0400 >>>>> Nathaniel McCallum wrote: >>>>> snip >>>>> NACK, you cannot move from MAY to MUST. >>>> This is precisely what we have been discussing on IRC today. The >>>> consensus was that this was acceptable because of the update plugin >>>> and the rarity of the state in which a token would not have >>>> ipatokenTOTPwatermark set (the token has to be created an never >>>> used). >>> Sorry I was not around, but it is never acceptable, as it may cause >>> replication failures. >> I agree that this shouldn't be done, although replication should not >> be a problem, the consumer relies on the schema checking of the >> server where the operation was originally applied. >> But problems may show up for existing entries, if you have an an >> entry without attr A, which now becomes MUST and then do any >> modification on this entry, after the mod the entry will be schema >> checked, the missing attribute detected and the mod rejected >>> >>> This has been a long (albeit perhaps unspoken) rule in changing >>> schema in FreeIPA. >> if you want to define the rules for schema change somewhere, you >> should add this as well: never make a multivalued attribute >> singlevalued > > Ok I added this new page: http://www.freeipa.org/page/Schema_Handling Thanks for the page, very helpful. > > I would like to add a link to it in > http://www.freeipa.org/page/Contribute/Code if I get a review and an > ack for the page. > >>> >>> Existing objectlasses can *never* gain new MUST attributes. This >>> rule is rigid and is non-negotiable. >> >> If you want to ensure that every entry has a specific attribute, but >> connot enforce this by the schema, an option would be to define a CoS >> rule for this attr which defines a default and gives the real attr >> precedence > > Yeah this is a good idea, should we add a section in that page with > advice on how to handle situations where you'd like to change an > objectclass/attribute but are not allowed by our rules ? > +1 Would be helpful as well. -- Petr Vobornik From rcritten at redhat.com Fri Sep 19 15:23:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Sep 2014 11:23:45 -0400 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541C187D.3010903@redhat.com> References: <541C187D.3010903@redhat.com> Message-ID: <541C4A81.4050108@redhat.com> Martin Basti wrote: > Hello list, > > I need to use systemd mask/unmask in ipa service. > > But as Honza wrote: > "IMO masking/unmasking should be part of disabling/enabling a service in > systemd. AFAIK in most other init systems when you disable a service, it > has the same effect as masking the service in systemd - it will never be > started until it is enabled/unmasked again. " > > So my questions is, should be masking part of disabling service in > systemd, to be platform independent? > Or should we add mask/unmask methods to > ipaplatform.base.services.PlatformService where mask is alias for disable? > > Martin^2 > After reading http://0pointer.de/blog/projects/three-levels-of-off I disagree that disabling in SysV is the same as masking in systemd, though I guess it depends on the meaning of disable. According to that page chkconfig off is equivalent to systemctl disable .service, which is what we do now AFAIR. Why do you need to mask a service, e.g. render it completely unstartable? rob From mkosek at redhat.com Fri Sep 19 15:50:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Sep 2014 17:50:16 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541C4A81.4050108@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> Message-ID: <541C50B8.2040901@redhat.com> On 09/19/2014 05:23 PM, Rob Crittenden wrote: > Martin Basti wrote: >> Hello list, >> >> I need to use systemd mask/unmask in ipa service. >> >> But as Honza wrote: >> "IMO masking/unmasking should be part of disabling/enabling a service in >> systemd. AFAIK in most other init systems when you disable a service, it >> has the same effect as masking the service in systemd - it will never be >> started until it is enabled/unmasked again. " >> >> So my questions is, should be masking part of disabling service in >> systemd, to be platform independent? >> Or should we add mask/unmask methods to >> ipaplatform.base.services.PlatformService where mask is alias for disable? >> >> Martin^2 >> > > After reading http://0pointer.de/blog/projects/three-levels-of-off I > disagree that disabling in SysV is the same as masking in systemd, > though I guess it depends on the meaning of disable. According to that > page chkconfig off is equivalent to systemctl disable > .service, which is what we do now AFAIR. > > Why do you need to mask a service, e.g. render it completely unstartable? > > rob I do not have full context, but looks like a good question. We only enable ipa "service" and starts via ipactl all other services. So we can disable/enable/mask services on the LDAP level, not on systemd level. Martin From simo at redhat.com Fri Sep 19 16:33:51 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Sep 2014 12:33:51 -0400 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541C50B8.2040901@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> Message-ID: <20140919123351.5a841ef5@willson.usersys.redhat.com> On Fri, 19 Sep 2014 17:50:16 +0200 Martin Kosek wrote: > On 09/19/2014 05:23 PM, Rob Crittenden wrote: > > Martin Basti wrote: > >> Hello list, > >> > >> I need to use systemd mask/unmask in ipa service. > >> > >> But as Honza wrote: > >> "IMO masking/unmasking should be part of disabling/enabling a > >> service in systemd. AFAIK in most other init systems when you > >> disable a service, it has the same effect as masking the service > >> in systemd - it will never be started until it is enabled/unmasked > >> again. " > >> > >> So my questions is, should be masking part of disabling service in > >> systemd, to be platform independent? > >> Or should we add mask/unmask methods to > >> ipaplatform.base.services.PlatformService where mask is alias for > >> disable? > >> > >> Martin^2 > >> > > > > After reading http://0pointer.de/blog/projects/three-levels-of-off I > > disagree that disabling in SysV is the same as masking in systemd, > > though I guess it depends on the meaning of disable. According to > > that page chkconfig off is equivalent to systemctl disable > > .service, which is what we do now AFAIR. > > > > Why do you need to mask a service, e.g. render it completely > > unstartable? > > > > rob > > I do not have full context, but looks like a good question. We only > enable ipa "service" and starts via ipactl all other services. So we > can disable/enable/mask services on the LDAP level, not on systemd > level. I do not think masking is right for now, however I'd like to chime in given there is work around this. The current ipactl method was necessary due to issues in using systemd fully, however if newer systemds have bugs about enabling/disabling unit files from another one fixed then we should look into making the ipa.service use ipactl *only* to enable/disable unit files. This way if we can create the various unit files as eg: ipa-httpd.service where the only thing we do is add an After: ipa.service and then include the system's httpd.service file we will be in a better situation. Especially on shutdown, as no matter what changed in LDAP on shutdown we do not even lookup anything and just let systemd tear down all services in the ipa group (I guess there is a way to tell systemd that if ipa.service goes down all it's dependent services also need to go down. I know this is a major refactoring, but if we can pull it off, this is the correct way to go with systemd integration in the longer term. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Sep 19 17:29:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Sep 2014 19:29:29 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable Message-ID: <541C67F9.5060309@redhat.com> https://fedorahosted.org/freeipa/ticket/4551 See ticket & commit message for details. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0645-ipa-replica-prepare-Wait-for-the-DNS-entry-to-be-res.patch Type: text/x-patch Size: 3613 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 19 17:39:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 13:39:29 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54198DA3.5090603@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> Message-ID: <1411148369.18665.1.camel@redhat.com> The attached version of the patch should solve all of these issues. It should also be more performant and use less memory. Nathaniel On Wed, 2014-09-17 at 15:33 +0200, thierry bordaz wrote: > On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: > > > This plugin ensures that all counter/watermark operations are atomic > > and never decrement. Also, deletion is not permitted. > > > > https://fedorahosted.org/freeipa/ticket/4494 > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello Nathaniel, > > More thoughts.. I think being "betxnpreoperation" you are safe > with parallel client ops and the check is atomic. I have few > comments: > * Shouldn't be implemented > SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, > even if they are empty. > * In load_counters, in case we have a target entry that > has not 'objectclass' 'ipatokenHOTP|ipatokenTOTP' and > the mod operation: > dn: > changetype: modify > replace: ipatokenHOTPcounter > ipatokenHOTPcounter: 200 > - > add: objectclass > objectclass: ipatokenHOTP > > > I wonder if the operation will not fail although IMHO > it should succeeds. > Shouldn't let the schema checking reject the operation > if the attribute is not granted by the entry > objectclass > * in load_counters, I am under the impression it may > return ipatokenHOTPcounter or ipatokenTOTPwatermark > (ipatokenHOTPcounter is missing). > But then how the caller knows that the returned value > is a counter or a watermark ? > * in ldapmod_is_attrs you may prefer PL_strcasecmp to > strcasecmp > > About replicated updates, if updates of counters/watermark are > done on several servers. Then a replicated operation may want > to set counters/watermark with a smaller value that the > existing one. In that case, it will return unwilling to > perform. That could break replication. > If the update comes from replication and the value is going > backward, we could make the operation a nop operation (setting > the attribute to its current value). > > > thanks > theirry > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.1-Create-ipa-otp-decrement-389DS-plugin.patch Type: text/x-patch Size: 17891 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 19 17:40:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 13:40:45 -0400 Subject: [Freeipa-devel] [PATCH 0066] Make ipatokenTOTPwatermark a required attribute In-Reply-To: <20140918142709.030c230b@willson.usersys.redhat.com> References: <1411063004.3757.2.camel@redhat.com> <20140918141849.71a27138@willson.usersys.redhat.com> <1411064527.3757.8.camel@redhat.com> <20140918142709.030c230b@willson.usersys.redhat.com> Message-ID: <1411148445.18665.2.camel@redhat.com> On Thu, 2014-09-18 at 14:27 -0400, Simo Sorce wrote: > On Thu, 18 Sep 2014 14:22:07 -0400 > Nathaniel McCallum wrote: > > > On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: > > > On Thu, 18 Sep 2014 13:56:44 -0400 > > > Nathaniel McCallum wrote: > > > > > > > -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME > > > > 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' > > > > MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ > > > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY > > > > (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses: > > > > (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken > > > > STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > > > > ipatokenOTPalgorithm $ ipatokenOTPdigits $ > > > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $ > > > > ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > > > > > > NACK, you cannot move from MAY to MUST. > > > > This is precisely what we have been discussing on IRC today. The > > consensus was that this was acceptable because of the update plugin > > and the rarity of the state in which a token would not have > > ipatokenTOTPwatermark set (the token has to be created an never used). > > Sorry I was not around, but it is never acceptable, as it may cause > replication failures. > > This has been a long (albeit perhaps unspoken) rule in changing schema > in FreeIPA. > > Existing objectlasses can *never* gain new MUST attributes. This rule > is rigid and is non-negotiable. I rescind this patch. It is no longer necessary. From npmccallum at redhat.com Fri Sep 19 17:41:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 13:41:17 -0400 Subject: [Freeipa-devel] [PATCH 0062] Use delete/add for OTP counter/watermark updates In-Reply-To: <20140918142014.4b76280c@willson.usersys.redhat.com> References: <1409280891.9966.11.camel@redhat.com> <1410808094.4238.7.camel@redhat.com> <541AC95D.6090202@redhat.com> <1411063174.3757.4.camel@redhat.com> <20140918142014.4b76280c@willson.usersys.redhat.com> Message-ID: <1411148477.18665.3.camel@redhat.com> On Thu, 2014-09-18 at 14:20 -0400, Simo Sorce wrote: > On Thu, 18 Sep 2014 13:59:34 -0400 > Nathaniel McCallum wrote: > > > On Thu, 2014-09-18 at 14:00 +0200, Petr Vobornik wrote: > > > On 15.9.2014 21:08, Nathaniel McCallum wrote: > > > > 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 > > > > > > > > I still need a review of this. This is targeted for 4.1. > > > > > > > > Nathaniel > > > > > > > > > > > > > Works fine with HTOP but fails for new TOTP tokens. > > > > > > New TOTP token doesn't have a watermark attribute set so there is > > > nothing to delete and therefore standard login procedure fails on > > > writeattr call (libotp.c:223). > > > > I have fixed this by making ipatokenTOTPwatermark a required attribute > > (MAY -> MUST). I did this in a separate patch (0066) because I thought > > it was cleaner. > > This can easily break stuff, and is not allowed, sorry you need to find > a way that will not cause objects, even temporarily to be incomplete. > > (think of a replica getting the new schema while an older one pushes > the object via replication) I rescind this patch. It is no longer necessary. From npmccallum at redhat.com Fri Sep 19 17:49:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 13:49:35 -0400 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth Message-ID: <1411148975.18665.5.camel@redhat.com> This is an optimization from patch 0062 (rescinded) which I think is worth keeping. There is no ticket for this. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0067-Use-stack-allocation-when-writing-values-during-otp-.patch Type: text/x-patch Size: 2304 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 19 17:53:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 13:53:59 -0400 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback Message-ID: <1411149239.18665.7.camel@redhat.com> This prevents synchronization when an authentication collision occurs. https://fedorahosted.org/freeipa/ticket/4493 NOTE: this patch is related to the above ticket, but does not solve it. For the solution, please see patch 0064. This behavior fix is from patch 0062 (rescinded) and is worth keeping. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0068-Move-OTP-synchronization-step-to-after-counter-write.patch Type: text/x-patch Size: 1846 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 19 18:31:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Sep 2014 20:31:52 +0200 Subject: [Freeipa-devel] [PATCH] 0647 test_permission_plugin: Check legacy permissions Message-ID: <541C7698.3000109@redhat.com> This has been wrong for some time, now I got around to fixing it properly. It should go to all branches (4.0, 4.1, master). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0647-test_permission_plugin-Check-legacy-permissions.patch Type: text/x-patch Size: 2009 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 19 20:15:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 19 Sep 2014 16:15:43 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411148369.18665.1.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> Message-ID: <1411157743.18665.12.camel@redhat.com> This new version fixes a small style issue pointed out to me by richm (thanks!). On Fri, 2014-09-19 at 13:39 -0400, Nathaniel McCallum wrote: > The attached version of the patch should solve all of these issues. It > should also be more performant and use less memory. > > Nathaniel > > > On Wed, 2014-09-17 at 15:33 +0200, thierry bordaz wrote: > > On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: > > > > > This plugin ensures that all counter/watermark operations are atomic > > > and never decrement. Also, deletion is not permitted. > > > > > > https://fedorahosted.org/freeipa/ticket/4494 > > > > > > > > > _______________________________________________ > > > Freeipa-devel mailing list > > > Freeipa-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hello Nathaniel, > > > > More thoughts.. I think being "betxnpreoperation" you are safe > > with parallel client ops and the check is atomic. I have few > > comments: > > * Shouldn't be implemented > > SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, > > even if they are empty. > > * In load_counters, in case we have a target entry that > > has not 'objectclass' 'ipatokenHOTP|ipatokenTOTP' and > > the mod operation: > > dn: > > changetype: modify > > replace: ipatokenHOTPcounter > > ipatokenHOTPcounter: 200 > > - > > add: objectclass > > objectclass: ipatokenHOTP > > > > > > I wonder if the operation will not fail although IMHO > > it should succeeds. > > Shouldn't let the schema checking reject the operation > > if the attribute is not granted by the entry > > objectclass > > * in load_counters, I am under the impression it may > > return ipatokenHOTPcounter or ipatokenTOTPwatermark > > (ipatokenHOTPcounter is missing). > > But then how the caller knows that the returned value > > is a counter or a watermark ? > > * in ldapmod_is_attrs you may prefer PL_strcasecmp to > > strcasecmp > > > > About replicated updates, if updates of counters/watermark are > > done on several servers. Then a replicated operation may want > > to set counters/watermark with a smaller value that the > > existing one. In that case, it will return unwilling to > > perform. That could break replication. > > If the update comes from replication and the value is going > > backward, we could make the operation a nop operation (setting > > the attribute to its current value). > > > > > > thanks > > theirry > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.2-Create-ipa-otp-decrement-389DS-plugin.patch Type: text/x-patch Size: 17895 bytes Desc: not available URL: From tbordaz at redhat.com Fri Sep 19 22:25:34 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Sat, 20 Sep 2014 00:25:34 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411157743.18665.12.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> Message-ID: <541CAD5E.3070008@redhat.com> Hello Nathaniel, sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It looks good but difficult to think to all possible cases. I think to the following corner case: The initial entry has ipatokenHOTPcounter=5 ldapmodify.. changetype: modify add: ipatokenHOTPcounter ipatokenHOTPcounter: 6 - replace: ipatokenHOTPcounter ipatokenHOTPcounter: 7 It translates add: 6 del: 5 add: 7 This operation will fail because ipatokenHOTPcounter is single-valued although IMHO it should succeed. This is a so special operation that is may not really be a concern. It is important that attribute are single valued. The replication changelog will replicated MOD/DEL + MOD/ADD for a MOD/REPL. That means that if the attributes are updated on several masters, the number of values can likely increase. Where for single value it should only keep the most recent value. thanks theirry On 09/19/2014 10:15 PM, Nathaniel McCallum wrote: > This new version fixes a small style issue pointed out to me by richm > (thanks!). > > On Fri, 2014-09-19 at 13:39 -0400, Nathaniel McCallum wrote: >> The attached version of the patch should solve all of these issues. It >> should also be more performant and use less memory. >> >> Nathaniel >> >> >> On Wed, 2014-09-17 at 15:33 +0200, thierry bordaz wrote: >>> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: >>> >>>> This plugin ensures that all counter/watermark operations are atomic >>>> and never decrement. Also, deletion is not permitted. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4494 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Hello Nathaniel, >>> >>> More thoughts.. I think being "betxnpreoperation" you are safe >>> with parallel client ops and the check is atomic. I have few >>> comments: >>> * Shouldn't be implemented >>> SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, >>> even if they are empty. >>> * In load_counters, in case we have a target entry that >>> has not 'objectclass' 'ipatokenHOTP|ipatokenTOTP' and >>> the mod operation: >>> dn: >>> changetype: modify >>> replace: ipatokenHOTPcounter >>> ipatokenHOTPcounter: 200 >>> - >>> add: objectclass >>> objectclass: ipatokenHOTP >>> >>> >>> I wonder if the operation will not fail although IMHO >>> it should succeeds. >>> Shouldn't let the schema checking reject the operation >>> if the attribute is not granted by the entry >>> objectclass >>> * in load_counters, I am under the impression it may >>> return ipatokenHOTPcounter or ipatokenTOTPwatermark >>> (ipatokenHOTPcounter is missing). >>> But then how the caller knows that the returned value >>> is a counter or a watermark ? >>> * in ldapmod_is_attrs you may prefer PL_strcasecmp to >>> strcasecmp >>> >>> About replicated updates, if updates of counters/watermark are >>> done on several servers. Then a replicated operation may want >>> to set counters/watermark with a smaller value that the >>> existing one. In that case, it will return unwilling to >>> perform. That could break replication. >>> If the update comes from replication and the value is going >>> backward, we could make the operation a nop operation (setting >>> the attribute to its current value). >>> >>> >>> thanks >>> theirry >>> >>> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Sep 19 22:46:31 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Sep 2014 18:46:31 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <541CAD5E.3070008@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> Message-ID: <20140919184631.159f1b45@willson.usersys.redhat.com> On Sat, 20 Sep 2014 00:25:34 +0200 thierry bordaz wrote: > Hello Nathaniel, > > sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It > looks good but difficult to think to all possible cases. > I think to the following corner case: > The initial entry has ipatokenHOTPcounter=5 > ldapmodify.. > changetype: modify > add: ipatokenHOTPcounter > ipatokenHOTPcounter: 6 > - > replace: ipatokenHOTPcounter > ipatokenHOTPcounter: 7 > > It translates > add: 6 > del: 5 > add: 7 > > This operation will fail because ipatokenHOTPcounter is > single-valued although IMHO it should succeed. > This is a so special operation that is may not really be a > concern. > > It is important that attribute are single valued. The replication > changelog will replicated MOD/DEL + MOD/ADD for a MOD/REPL. > That means that if the attributes are updated on several masters, > the number of values can likely increase. Where for single value > it should only keep the most recent value. Hi thierry, this behavior is actually intentional, and we want to fail the operation if someone else updates the counter because it means a replay attack has happened. We will not replicate the counters via normal replication, because it would be too much traffic anyway, we have drafted a plan to use a special plugin to handle multi-master updates specific for OTPs and their requirements. See: http://www.freeipa.org/page/V4/OTP_Replay_Prevention#Replication_Counter_Race Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Sat Sep 20 19:39:48 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sat, 20 Sep 2014 15:39:48 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <541CAD5E.3070008@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> Message-ID: <1411241988.3483.2.camel@redhat.com> On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote: > Hello Nathaniel, > > sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It > looks good but difficult to think to all possible cases. > I think to the following corner case: > The initial entry has ipatokenHOTPcounter=5 > ldapmodify.. > changetype: modify > add: ipatokenHOTPcounter > ipatokenHOTPcounter: 6 > - > replace: ipatokenHOTPcounter > ipatokenHOTPcounter: 7 > > It translates > add: 6 > del: 5 > add: 7 > > This operation will fail because ipatokenHOTPcounter is > single-valued although IMHO it should succeed. No. It should fail. There can only ever be one ipatokenHOTPcounter. > This is a so special operation that is may not really be a > concern. +1 > It is important that attribute are single valued. The > replication changelog will replicated MOD/DEL + MOD/ADD for a > MOD/REPL. > That means that if the attributes are updated on several > masters, the number of values can likely increase. Where for > single value it should only keep the most recent value. That is a concern, at least for now. Eventually we won't use replication for this at all. But for now, we will. Here is the problem I foresee. You have two servers: A and B. The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1). Replication is sent to server B. Before the replication is performed on server B, the user authenticates with the next token. This triggers a MOD/DEL(0)+MOD/ADD(2). Replication is sent to server A. This replication will fail because A has a value of 1, not a value of 0. The end result is that there will be different values for ipatokenHOTPcounter on the two different servers. A will have 1 and B will have 2. Once this happens, the replications can never reconcile (this is a big problem). I see two options here, both theoretical. Option #1 is to hook 389 in a different place: before the mods are performed by after the replication changelog is generated. Alternatively, we could insert a hook after the replication changelog is generated, but before it is sent. We could consolidate the MOD/DEL +MOD/ADD here into a single MOD/REPLACE operation. Option #2 is to have some way to translate the MOD/REPLACE(X) into a MOD/DEL(<=X)+MOD/ADD(X). Are either of these possible? Is there another option? Nathaniel From npmccallum at redhat.com Sat Sep 20 19:40:27 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sat, 20 Sep 2014 15:40:27 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <20140919184631.159f1b45@willson.usersys.redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <20140919184631.159f1b45@willson.usersys.redhat.com> Message-ID: <1411242027.3483.3.camel@redhat.com> On Fri, 2014-09-19 at 18:46 -0400, Simo Sorce wrote: > On Sat, 20 Sep 2014 00:25:34 +0200 > thierry bordaz wrote: > > > Hello Nathaniel, > > > > sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It > > looks good but difficult to think to all possible cases. > > I think to the following corner case: > > The initial entry has ipatokenHOTPcounter=5 > > ldapmodify.. > > changetype: modify > > add: ipatokenHOTPcounter > > ipatokenHOTPcounter: 6 > > - > > replace: ipatokenHOTPcounter > > ipatokenHOTPcounter: 7 > > > > It translates > > add: 6 > > del: 5 > > add: 7 > > > > This operation will fail because ipatokenHOTPcounter is > > single-valued although IMHO it should succeed. > > This is a so special operation that is may not really be a > > concern. > > > > It is important that attribute are single valued. The replication > > changelog will replicated MOD/DEL + MOD/ADD for a MOD/REPL. > > That means that if the attributes are updated on several masters, > > the number of values can likely increase. Where for single value > > it should only keep the most recent value. > > Hi thierry, this behavior is actually intentional, and we want to fail > the operation if someone else updates the counter because it means a > replay attack has happened. +1 > We will not replicate the counters via normal replication, because it > would be too much traffic anyway, we have drafted a plan to use a > special plugin to handle multi-master updates specific for OTPs and > their requirements. > See: > http://www.freeipa.org/page/V4/OTP_Replay_Prevention#Replication_Counter_Race This is a short-term concern since in the meantime we will be using replication. Nathaniel From npmccallum at redhat.com Sat Sep 20 20:21:33 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sat, 20 Sep 2014 16:21:33 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <54192F5D.7020208@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> Message-ID: <1411244493.3483.4.camel@redhat.com> On Wed, 2014-09-17 at 08:51 +0200, Jan Cholasta wrote: > Hi, > > Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): > > We perform this enforcement at the API level since: > > * DS level enforcement would be difficult > > * ipatokenUniqueID generation already happens at the API level > > > > It may be nice in the future to perform enforcement in the DS itself. > > However, the question of the location of enforcement is largely an > > aesthetic issue. > > > > https://fedorahosted.org/freeipa/ticket/4456 > > That's a rather beefy check. I would prefer something like this (untested): > > group_dn = self.api.Object.group.get_dn(u'admins') > filter = ldap.make_filter( > {'krbprincipalname': context.principal, 'memberof': group_dn}, > ldap.MATCH_ALL) > try: > ldap.find_entries( > base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) > except errors.NotFound: > raise ValidationError(name='ipatokenuniqueid', > error='can only be specified by admins') Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0065.1-Don-t-allow-users-to-create-tokens-with-a-specified-.patch Type: text/x-patch Size: 2544 bytes Desc: not available URL: From npmccallum at redhat.com Sat Sep 20 20:22:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sat, 20 Sep 2014 16:22:53 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <54196306.3020805@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> Message-ID: <1411244573.3483.6.camel@redhat.com> On Wed, 2014-09-17 at 12:31 +0200, Martin Kosek wrote: > On 09/17/2014 08:51 AM, Jan Cholasta wrote: > > Hi, > > > > Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): > >> We perform this enforcement at the API level since: > >> * DS level enforcement would be difficult > >> * ipatokenUniqueID generation already happens at the API level > >> > >> It may be nice in the future to perform enforcement in the DS itself. > >> However, the question of the location of enforcement is largely an > >> aesthetic issue. > >> > >> https://fedorahosted.org/freeipa/ticket/4456 > > > > That's a rather beefy check. I would prefer something like this (untested): > > > > group_dn = self.api.Object.group.get_dn(u'admins') > > filter = ldap.make_filter( > > {'krbprincipalname': context.principal, 'memberof': group_dn}, > > ldap.MATCH_ALL) > > try: > > ldap.find_entries( > > base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) > > except errors.NotFound: > > raise ValidationError(name='ipatokenuniqueid', > > error='can only be specified by admins') > > > > Honza > > > > Also, do we want to hard code it to admins group only? Preferably, no. But I don't have another workable solution. > Wouldn't it be more > flexible to create a new Virtual Operation and let realm admin configure who > can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1 > for an example how that's done. Modifications are already not permitted. The problem is that we need to restrict the format of an attribute for only some users on add only. Nathaniel From simo at redhat.com Sat Sep 20 21:33:07 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 20 Sep 2014 17:33:07 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411241988.3483.2.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> Message-ID: <20140920173307.32e76f95@willson.usersys.redhat.com> On Sat, 20 Sep 2014 15:39:48 -0400 Nathaniel McCallum wrote: > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote: > > Hello Nathaniel, > > > > sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. > > It looks good but difficult to think to all possible cases. > > I think to the following corner case: > > The initial entry has ipatokenHOTPcounter=5 > > ldapmodify.. > > changetype: modify > > add: ipatokenHOTPcounter > > ipatokenHOTPcounter: 6 > > - > > replace: ipatokenHOTPcounter > > ipatokenHOTPcounter: 7 > > > > It translates > > add: 6 > > del: 5 > > add: 7 > > > > This operation will fail because ipatokenHOTPcounter is > > single-valued although IMHO it should succeed. > > No. It should fail. There can only ever be one ipatokenHOTPcounter. > > > This is a so special operation that is may not really be a > > concern. > > +1 > > > It is important that attribute are single valued. The > > replication changelog will replicated MOD/DEL + MOD/ADD for > > a MOD/REPL. > > That means that if the attributes are updated on several > > masters, the number of values can likely increase. Where for > > single value it should only keep the most recent value. > > That is a concern, at least for now. Eventually we won't use > replication for this at all. But for now, we will. > > Here is the problem I foresee. You have two servers: A and B. > > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1). > Replication is sent to server B. > > Before the replication is performed on server B, the user > authenticates with the next token. This triggers a > MOD/DEL(0)+MOD/ADD(2). Replication is sent to server A. This > replication will fail because A has a value of 1, not a value of 0. > > The end result is that there will be different values for > ipatokenHOTPcounter on the two different servers. A will have 1 and B > will have 2. Once this happens, the replications can never reconcile > (this is a big problem). I see two options here, both theoretical. > > Option #1 is to hook 389 in a different place: before the mods are > performed by after the replication changelog is generated. > Alternatively, we could insert a hook after the replication changelog > is generated, but before it is sent. We could consolidate the MOD/DEL > +MOD/ADD here into a single MOD/REPLACE operation. > > Option #2 is to have some way to translate the MOD/REPLACE(X) into a > MOD/DEL(<=X)+MOD/ADD(X). > > Are either of these possible? Is there another option? I think the only option would be to intercept modifications on replicas, check that the mod is due to a replication event and discard/change the delete and change the add into a replace. This means replay attacks will still be possible, but there is no way around that until we handle the replication/quorum thing ourselves. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Sun Sep 21 19:07:27 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sun, 21 Sep 2014 15:07:27 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs Message-ID: <1411326447.3483.8.camel@redhat.com> Users that can rename the token (such as admins) can also create non-UUID token names. https://fedorahosted.org/freeipa/ticket/4456 NOTE: this patch is an alternate approach to my patch 0065. This version has two main advantages compared to 0065: 1. Permissions are more flexible (not tied to the admin group). 2. Enforcement occurs at the DS-level It should also be noted that this patch does not enforce UUID randomness, only syntax. Users can still specify a token ID so long as it is in UUID format. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0069-Adds-389DS-plugin-to-enforce-UUID-token-IDs.patch Type: text/x-patch Size: 12594 bytes Desc: not available URL: From npmccallum at redhat.com Sun Sep 21 19:11:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sun, 21 Sep 2014 15:11:03 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <1411244493.3483.4.camel@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <1411244493.3483.4.camel@redhat.com> Message-ID: <1411326663.3483.9.camel@redhat.com> On Sat, 2014-09-20 at 16:21 -0400, Nathaniel McCallum wrote: > On Wed, 2014-09-17 at 08:51 +0200, Jan Cholasta wrote: > > Hi, > > > > Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): > > > We perform this enforcement at the API level since: > > > * DS level enforcement would be difficult > > > * ipatokenUniqueID generation already happens at the API level > > > > > > It may be nice in the future to perform enforcement in the DS itself. > > > However, the question of the location of enforcement is largely an > > > aesthetic issue. > > > > > > https://fedorahosted.org/freeipa/ticket/4456 > > > > That's a rather beefy check. I would prefer something like this (untested): > > > > group_dn = self.api.Object.group.get_dn(u'admins') > > filter = ldap.make_filter( > > {'krbprincipalname': context.principal, 'memberof': group_dn}, > > ldap.MATCH_ALL) > > try: > > ldap.find_entries( > > base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) > > except errors.NotFound: > > raise ValidationError(name='ipatokenuniqueid', > > error='can only be specified by admins') > > Fixed. Please note that another approach has been posted here: https://www.redhat.com/archives/freeipa-devel/2014-September/msg00433.html From npmccallum at redhat.com Mon Sep 22 02:33:47 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sun, 21 Sep 2014 22:33:47 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <20140920173307.32e76f95@willson.usersys.redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> Message-ID: <1411353227.3483.11.camel@redhat.com> On Sat, 2014-09-20 at 17:33 -0400, Simo Sorce wrote: > On Sat, 20 Sep 2014 15:39:48 -0400 > Nathaniel McCallum wrote: > > > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote: > > > Hello Nathaniel, > > > > > > sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. > > > It looks good but difficult to think to all possible cases. > > > I think to the following corner case: > > > The initial entry has ipatokenHOTPcounter=5 > > > ldapmodify.. > > > changetype: modify > > > add: ipatokenHOTPcounter > > > ipatokenHOTPcounter: 6 > > > - > > > replace: ipatokenHOTPcounter > > > ipatokenHOTPcounter: 7 > > > > > > It translates > > > add: 6 > > > del: 5 > > > add: 7 > > > > > > This operation will fail because ipatokenHOTPcounter is > > > single-valued although IMHO it should succeed. > > > > No. It should fail. There can only ever be one ipatokenHOTPcounter. > > > > > This is a so special operation that is may not really be a > > > concern. > > > > +1 > > > > > It is important that attribute are single valued. The > > > replication changelog will replicated MOD/DEL + MOD/ADD for > > > a MOD/REPL. > > > That means that if the attributes are updated on several > > > masters, the number of values can likely increase. Where for > > > single value it should only keep the most recent value. > > > > That is a concern, at least for now. Eventually we won't use > > replication for this at all. But for now, we will. > > > > Here is the problem I foresee. You have two servers: A and B. > > > > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1). > > Replication is sent to server B. > > > > Before the replication is performed on server B, the user > > authenticates with the next token. This triggers a > > MOD/DEL(0)+MOD/ADD(2). Replication is sent to server A. This > > replication will fail because A has a value of 1, not a value of 0. > > > > The end result is that there will be different values for > > ipatokenHOTPcounter on the two different servers. A will have 1 and B > > will have 2. Once this happens, the replications can never reconcile > > (this is a big problem). I see two options here, both theoretical. > > > > Option #1 is to hook 389 in a different place: before the mods are > > performed by after the replication changelog is generated. > > Alternatively, we could insert a hook after the replication changelog > > is generated, but before it is sent. We could consolidate the MOD/DEL > > +MOD/ADD here into a single MOD/REPLACE operation. > > > > Option #2 is to have some way to translate the MOD/REPLACE(X) into a > > MOD/DEL(<=X)+MOD/ADD(X). > > > > Are either of these possible? Is there another option? > > I think the only option would be to intercept modifications on > replicas, check that the mod is due to a replication event and > discard/change the delete and change the add into a replace. This means > replay attacks will still be possible, but there is no way around that > until we handle the replication/quorum thing ourselves. Attached is a new version. This version replays the counter value through the mod steps. This allows us to discard delete values when doing replication and fill them in with the current counter value. It also allows us to play all the steps and check our parameters on the final state. I've tested with some fairly complex ldifs and I haven't seen any bugs. I think this should fix all the outstanding problems. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.3-Create-ipa-otp-decrement-389DS-plugin.patch Type: text/x-patch Size: 17758 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 22 06:36:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Sep 2014 08:36:23 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <20140919123351.5a841ef5@willson.usersys.redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> Message-ID: <541FC367.6010703@redhat.com> On 19.9.2014 18:33, Simo Sorce wrote: > On Fri, 19 Sep 2014 17:50:16 +0200 > Martin Kosek wrote: > >> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>> Martin Basti wrote: >>>> Hello list, >>>> >>>> I need to use systemd mask/unmask in ipa service. >>>> >>>> But as Honza wrote: >>>> "IMO masking/unmasking should be part of disabling/enabling a >>>> service in systemd. AFAIK in most other init systems when you >>>> disable a service, it has the same effect as masking the service >>>> in systemd - it will never be started until it is enabled/unmasked >>>> again. " >>>> >>>> So my questions is, should be masking part of disabling service in >>>> systemd, to be platform independent? >>>> Or should we add mask/unmask methods to >>>> ipaplatform.base.services.PlatformService where mask is alias for >>>> disable? >>>> >>>> Martin^2 >>>> >>> >>> After reading http://0pointer.de/blog/projects/three-levels-of-off I >>> disagree that disabling in SysV is the same as masking in systemd, >>> though I guess it depends on the meaning of disable. According to >>> that page chkconfig off is equivalent to systemctl disable >>> .service, which is what we do now AFAIR. >>> >>> Why do you need to mask a service, e.g. render it completely >>> unstartable? This is my requirement for DNSSEC implementation. IPA replaces original ods-signerd daemon from opendnssec package with IPA-specific implementation of ods-signerd daemon. Bad things will happen if the original daemon is started before the IPA-version so I asked Martin^2 Basti to mask the old service to prevent it from running. I expect that admins familiar with OpenDNSSEC but not-yet-familiar with IPA integration could mess with it accidentally. Also I'm not 100 % that some problem can not be caused by socket activation on a shared socket etc. Petr^2 Spacek >>> rob >> >> I do not have full context, but looks like a good question. We only >> enable ipa "service" and starts via ipactl all other services. So we >> can disable/enable/mask services on the LDAP level, not on systemd >> level. > > I do not think masking is right for now, however I'd like to chime in > given there is work around this. > > The current ipactl method was necessary due to issues in using systemd > fully, however if newer systemds have bugs about enabling/disabling unit > files from another one fixed then we should look into making the > ipa.service use ipactl *only* to enable/disable unit files. > This way if we can create the various unit files as eg: > ipa-httpd.service where the only thing we do is add an After: > ipa.service and then include the system's httpd.service file we will be > in a better situation. > Especially on shutdown, as no matter what changed in LDAP on shutdown > we do not even lookup anything and just let systemd tear down all > services in the ipa group (I guess there is a way to tell systemd that > if ipa.service goes down all it's dependent services also need to go > down. > > I know this is a major refactoring, but if we can pull it off, this is > the correct way to go with systemd integration in the longer term. > > Simo. > -- Petr^2 Spacek From mkosek at redhat.com Mon Sep 22 06:53:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 08:53:18 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <20140919123351.5a841ef5@willson.usersys.redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> Message-ID: <541FC75E.4060304@redhat.com> On 09/19/2014 06:33 PM, Simo Sorce wrote: > On Fri, 19 Sep 2014 17:50:16 +0200 > Martin Kosek wrote: > >> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>> Martin Basti wrote: >>>> Hello list, >>>> >>>> I need to use systemd mask/unmask in ipa service. >>>> >>>> But as Honza wrote: >>>> "IMO masking/unmasking should be part of disabling/enabling a >>>> service in systemd. AFAIK in most other init systems when you >>>> disable a service, it has the same effect as masking the service >>>> in systemd - it will never be started until it is enabled/unmasked >>>> again. " >>>> >>>> So my questions is, should be masking part of disabling service in >>>> systemd, to be platform independent? >>>> Or should we add mask/unmask methods to >>>> ipaplatform.base.services.PlatformService where mask is alias for >>>> disable? >>>> >>>> Martin^2 >>>> >>> >>> After reading http://0pointer.de/blog/projects/three-levels-of-off I >>> disagree that disabling in SysV is the same as masking in systemd, >>> though I guess it depends on the meaning of disable. According to >>> that page chkconfig off is equivalent to systemctl disable >>> .service, which is what we do now AFAIR. >>> >>> Why do you need to mask a service, e.g. render it completely >>> unstartable? >>> >>> rob >> >> I do not have full context, but looks like a good question. We only >> enable ipa "service" and starts via ipactl all other services. So we >> can disable/enable/mask services on the LDAP level, not on systemd >> level. > > I do not think masking is right for now, however I'd like to chime in > given there is work around this. > > The current ipactl method was necessary due to issues in using systemd > fully, however if newer systemds have bugs about enabling/disabling unit > files from another one fixed then we should look into making the > ipa.service use ipactl *only* to enable/disable unit files. > This way if we can create the various unit files as eg: > ipa-httpd.service where the only thing we do is add an After: > ipa.service and then include the system's httpd.service file we will be > in a better situation. > Especially on shutdown, as no matter what changed in LDAP on shutdown > we do not even lookup anything and just let systemd tear down all > services in the ipa group (I guess there is a way to tell systemd that > if ipa.service goes down all it's dependent services also need to go > down. > > I know this is a major refactoring, but if we can pull it off, this is > the correct way to go with systemd integration in the longer term. > > Simo. > Probably yes, I already had a discussion with systemd folks about a native systemd way to manage the services. I filed a ticket: https://fedorahosted.org/freeipa/ticket/4552 This shouldn't stop these patches though, especially if they are required for the DNSSEC feature. Martin From mkosek at redhat.com Mon Sep 22 07:23:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 09:23:02 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <1411244573.3483.6.camel@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> Message-ID: <541FCE56.4040109@redhat.com> On 09/20/2014 10:22 PM, Nathaniel McCallum wrote: > On Wed, 2014-09-17 at 12:31 +0200, Martin Kosek wrote: >> On 09/17/2014 08:51 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): >>>> We perform this enforcement at the API level since: >>>> * DS level enforcement would be difficult >>>> * ipatokenUniqueID generation already happens at the API level >>>> >>>> It may be nice in the future to perform enforcement in the DS itself. >>>> However, the question of the location of enforcement is largely an >>>> aesthetic issue. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4456 >>> >>> That's a rather beefy check. I would prefer something like this (untested): >>> >>> group_dn = self.api.Object.group.get_dn(u'admins') >>> filter = ldap.make_filter( >>> {'krbprincipalname': context.principal, 'memberof': group_dn}, >>> ldap.MATCH_ALL) >>> try: >>> ldap.find_entries( >>> base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) >>> except errors.NotFound: >>> raise ValidationError(name='ipatokenuniqueid', >>> error='can only be specified by admins') >>> >>> Honza >>> >> >> Also, do we want to hard code it to admins group only? > > Preferably, no. But I don't have another workable solution. > >> Wouldn't it be more >> flexible to create a new Virtual Operation and let realm admin configure who >> can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1 >> for an example how that's done. > > Modifications are already not permitted. The problem is that we need to > restrict the format of an attribute for only some users on add only. > > Nathaniel > Hmm, however note that we have a mechanism to limit even the values of the added object. See this example with groups. This is the ACI: # ipa permission-show "System: Add Groups" --all --raw | grep aci aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Add Groups";allow (add) groupdn = "ldap:///cn=System: Add Groups,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test";) Now I add custom user with this ACI: # ipa role-add test --desc test # ipa role-add-privilege test --privileges 'Group Administrators' # ipa role-add-member test --users fbar Now I try to add LDAP object that does not fit the ACI: # kinit fbar # ldapadd -h `hostname` -Y GSSAPI SASL/GSSAPI authentication started SASL username: fbar at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. dn: cn=test,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectclass: nscontainer objectclass: top cn: test adding new entry "cn=test,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test" ldap_add: Insufficient access (50) additional info: Insufficient 'add' privilege to add the entry 'cn=test,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test'. Now the right one: # ldapadd -h `hostname` -Y GSSAPI SASL/GSSAPI authentication started SASL username: fbar at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. dn: cn=test,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectclass: nscontainer objectclass: top objectclass: ipausergroup cn: test adding new entry "cn=test,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test" Could we use that mechanism and only allow setting ipatokenUniqueID to "-1" so that it is always generated for normal users? The attribute is single valued so user should not be able to circumvent it with multiple values. Martin From tbordaz at redhat.com Mon Sep 22 07:33:20 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 22 Sep 2014 09:33:20 +0200 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <1411326447.3483.8.camel@redhat.com> References: <1411326447.3483.8.camel@redhat.com> Message-ID: <541FD0C0.7000703@redhat.com> Hello Nathaniel, Just a remark, in is_token if the entry is objectclass=ipaToken it returns without freeing the 'objectclass' char array. thanks thierry On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > Users that can rename the token (such as admins) can also create > non-UUID token names. > > https://fedorahosted.org/freeipa/ticket/4456 > > NOTE: this patch is an alternate approach to my patch 0065. This version > has two main advantages compared to 0065: > 1. Permissions are more flexible (not tied to the admin group). > 2. Enforcement occurs at the DS-level > > It should also be noted that this patch does not enforce UUID > randomness, only syntax. Users can still specify a token ID so long as > it is in UUID format. > > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Sep 22 07:52:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Sep 2014 09:52:38 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541C4A81.4050108@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> Message-ID: <541FD546.9080505@redhat.com> Dne 19.9.2014 v 17:23 Rob Crittenden napsal(a): > Martin Basti wrote: >> Hello list, >> >> I need to use systemd mask/unmask in ipa service. >> >> But as Honza wrote: >> "IMO masking/unmasking should be part of disabling/enabling a service in >> systemd. AFAIK in most other init systems when you disable a service, it >> has the same effect as masking the service in systemd - it will never be >> started until it is enabled/unmasked again. " >> >> So my questions is, should be masking part of disabling service in >> systemd, to be platform independent? >> Or should we add mask/unmask methods to >> ipaplatform.base.services.PlatformService where mask is alias for disable? >> >> Martin^2 >> > > After reading http://0pointer.de/blog/projects/three-levels-of-off I > disagree that disabling in SysV is the same as masking in systemd, > though I guess it depends on the meaning of disable. According to that > page chkconfig off is equivalent to systemctl disable > .service, which is what we do now AFAIR. I don't think that's entirely correct. They are equivalent mechanically (a symlink is added/removed when a service is enabled/disabled), but effectively they are different. AFAIK in SysV, services can be started either manually or automatically on boot and if you disable a service the only way it will start is when you do it manually. In systemd, there are more ways services can be started automatically (socket, D-Bus, etc.) and disabling a service will only disable automatic start *on boot*, but it can still be started automatically, which contrasts with what SysV does. > > Why do you need to mask a service, e.g. render it completely unstartable? > > rob > -- Jan Cholasta From mkosek at redhat.com Mon Sep 22 08:14:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 10:14:32 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <541C67F9.5060309@redhat.com> References: <541C67F9.5060309@redhat.com> Message-ID: <541FDA68.9020402@redhat.com> On 09/19/2014 07:29 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4551 > > See ticket & commit message for details. Shouldn't we add a 1 sec sleep between tries? Wouldn't current version just hammer DNS server with as many DNS queries as it can send? Martin From pspacek at redhat.com Mon Sep 22 08:31:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Sep 2014 10:31:45 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <541FDA68.9020402@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> Message-ID: <541FDE71.4090701@redhat.com> On 22.9.2014 10:14, Martin Kosek wrote: > On 09/19/2014 07:29 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4551 >> >> See ticket & commit message for details. > > Shouldn't we add a 1 sec sleep between tries? Wouldn't current version just > hammer DNS server with as many DNS queries as it can send? Oh yes, please add some time.sleep() call :-) Also I would like to see more detailed message: + self.log.info('Waiting for hostname %s to be resolvable', + self.replica_fqdn) => 'Waiting for hostname %s to be resolvable to A or AAAA record' Thank you! -- Petr^2 Spacek From mkosek at redhat.com Mon Sep 22 08:34:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 10:34:54 +0200 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <541FD0C0.7000703@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> Message-ID: <541FDF2E.909@redhat.com> On 09/22/2014 09:33 AM, thierry bordaz wrote: > Hello Nathaniel, > > Just a remark, in is_token if the entry is objectclass=ipaToken it > returns without freeing the 'objectclass' char array. > > thanks > thierry > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: >> Users that can rename the token (such as admins) can also create >> non-UUID token names. >> >> https://fedorahosted.org/freeipa/ticket/4456 >> >> NOTE: this patch is an alternate approach to my patch 0065. This version >> has two main advantages compared to 0065: >> 1. Permissions are more flexible (not tied to the admin group). >> 2. Enforcement occurs at the DS-level >> >> It should also be noted that this patch does not enforce UUID >> randomness, only syntax. Users can still specify a token ID so long as >> it is in UUID format. >> >> Nathaniel I am still thinking we may be overcomplicating it. Why cannot we use the similar UUID generation mechanism as we do for SUDO commands for example: # ipa sudocmd-add barbar --all --raw --------------------------- Added Sudo Command "barbar" --------------------------- dn: ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test sudocmd: barbar ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 objectClass: ipasudocmd objectClass: ipaobject It lets DS generate&rename the object's DN when it finds out that the ipaUniqueID is set to "autogenerate" (in baseldap.py). We could let DS generate the UUID and only add the "autogenerate" keyword in otptoken-add command. For authorization, we can simply allow users to only add tokens with "autogenerate" ID, see my example here: http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html Admin's or special privilege-owners would have more generous ACI allowing other values than just "autogenerate". IMO, then the whole ipatoken-add mechanism would be a lot simpler and we would not need a special DS plugin (unless we want regular users to generate their own UUIDs instead of letting IPA DS to generate it - which I do not think is the case). Martin From mkosek at redhat.com Mon Sep 22 08:38:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 10:38:36 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <541FDE71.4090701@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> Message-ID: <541FE00C.7060405@redhat.com> On 09/22/2014 10:31 AM, Petr Spacek wrote: > On 22.9.2014 10:14, Martin Kosek wrote: >> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/4551 >>> >>> See ticket & commit message for details. >> >> Shouldn't we add a 1 sec sleep between tries? Wouldn't current version just >> hammer DNS server with as many DNS queries as it can send? > > Oh yes, please add some time.sleep() call :-) > > Also I would like to see more detailed message: > + self.log.info('Waiting for hostname %s to be resolvable', > + self.replica_fqdn) > > => 'Waiting for hostname %s to be resolvable to A or AAAA record' Really? Shouldn't term "resolvable" already have that covered? A good software should work on all network types, whether it is IPv4, IPv6 or IPv8. So I personally do not think we need to be that specific and can stick to original proposal. Martin From tbordaz at redhat.com Mon Sep 22 09:22:33 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 22 Sep 2014 11:22:33 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411241988.3483.2.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> Message-ID: <541FEA59.3010907@redhat.com> On 09/20/2014 09:39 PM, Nathaniel McCallum wrote: > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote: >> Hello Nathaniel, >> >> sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It >> looks good but difficult to think to all possible cases. >> I think to the following corner case: >> The initial entry has ipatokenHOTPcounter=5 >> ldapmodify.. >> changetype: modify >> add: ipatokenHOTPcounter >> ipatokenHOTPcounter: 6 >> - >> replace: ipatokenHOTPcounter >> ipatokenHOTPcounter: 7 >> >> It translates >> add: 6 >> del: 5 >> add: 7 >> >> This operation will fail because ipatokenHOTPcounter is >> single-valued although IMHO it should succeed. > No. It should fail. There can only ever be one ipatokenHOTPcounter. > >> This is a so special operation that is may not really be a >> concern. > +1 > >> It is important that attribute are single valued. The >> replication changelog will replicated MOD/DEL + MOD/ADD for a >> MOD/REPL. >> That means that if the attributes are updated on several >> masters, the number of values can likely increase. Where for >> single value it should only keep the most recent value. > That is a concern, at least for now. Eventually we won't use replication > for this at all. But for now, we will. > > Here is the problem I foresee. You have two servers: A and B. > > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1). > Replication is sent to server B. > > Before the replication is performed on server B, the user authenticates > with the next token. This triggers a MOD/DEL(0)+MOD/ADD(2). Replication > is sent to server A. This replication will fail because A has a value of > 1, not a value of 0. > > The end result is that there will be different values for > ipatokenHOTPcounter on the two different servers. A will have 1 and B > will have 2. Once this happens, the replications can never reconcile > (this is a big problem). I see two options here, both theoretical. The final value (when all updates has been replicated/applied) will rely on the timestamp of the operation (CSN). When a CSN is generated on a master it is guaranteed that it is greater (more recent) than any known CSNs. In your scenario "nothing" can guaranty that the CSN of the second update (B) is larger than the CSN of the first update. If CSN(B) > CSN(A), the final value will be '2' else it will be '1'. When the server B will receive the first update ('1') its current value is '2'. So it will reject the update, that may break replication. If we decide to not control replicated update and if CSN(A) > CSN(B), then the final value will go backward. > > Option #1 is to hook 389 in a different place: before the mods are > performed by after the replication changelog is generated. > Alternatively, we could insert a hook after the replication changelog is > generated, but before it is sent. We could consolidate the MOD/DEL > +MOD/ADD here into a single MOD/REPLACE operation. With current replication it would be major change. Update of the changelog is done in betxn_postop based on the operations mods. > > Option #2 is to have some way to translate the MOD/REPLACE(X) into a > MOD/DEL(<=X)+MOD/ADD(X). I think it is already what the plugin is doing. It retrieves the current value from the entry and do a mod/del on this value then a mod/add of the new value. (at the condition new_value>current_value). My concern is that in your scenario, due to parallel update with several new_values we may select an incorrect new_value. The 'Dynamic Master proxy' ( http://www.freeipa.org/page/V4/OTP_Replay_Prevention#Replication_Counter_Race) solution looks as a good one. > > Are either of these possible? Is there another option? > > Nathaniel > > From thozza at redhat.com Mon Sep 22 09:52:14 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 22 Sep 2014 11:52:14 +0200 Subject: [Freeipa-devel] [PATCH 0297] Add log message about initial LDAP synchronization In-Reply-To: <5419717C.4070103@redhat.com> References: <5419717C.4070103@redhat.com> Message-ID: <541FF14E.9050607@redhat.com> On 09/17/2014 01:33 PM, Petr Spacek wrote: > Hello, > > Add log message about initial LDAP synchronization. > ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pviktori at redhat.com Mon Sep 22 10:24:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Sep 2014 12:24:41 +0200 Subject: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile In-Reply-To: <54130738.5060706@redhat.com> References: <5412FD02.6080200@redhat.com> <5412FFD8.4050407@redhat.com> <54130568.8000703@redhat.com> <54130738.5060706@redhat.com> Message-ID: <541FF8E9.8000502@redhat.com> On 09/12/2014 04:46 PM, Martin Basti wrote: > On 12/09/14 16:38, Martin Kosek wrote: >> On 09/12/2014 04:14 PM, Martin Basti wrote: >>> On 12/09/14 16:02, Martin Basti wrote: >>>> I always forgot to install dogtag 10.2, so here is updated specfile. >>>> >>>> COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ >>>> >>>> Patch atached. ipa-4-1 >>>> >>>> >>> >>> I'm not sure if dogtag 10.2 is required in 4.1 >>> >> >> It is not. It is only required for the DRM feature, i.e. FreeIPA 4.2, >> i.e. master branch. >> >> Martin > > Thank you. > > Updated patch attached. > push only to master branch then Thanks, ACK, pushed to master: 846123cfc2768d15cee72fa5fe740d82bb99e8ef -- Petr? From pvoborni at redhat.com Mon Sep 22 11:17:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Sep 2014 13:17:45 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <541C3A95.9050504@redhat.com> References: <541C3A95.9050504@redhat.com> Message-ID: <54200559.6060604@redhat.com> On 19.9.2014 16:15, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/3414 > Patch attached. > Patch 126: 1. I think that just DeprecatedParam('dnsclass?'), should be enough. Also 2. You forgot to update API.txt and VERSION Patch 127: ACK -- Petr Vobornik From pspacek at redhat.com Mon Sep 22 11:48:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Sep 2014 13:48:03 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <541FE00C.7060405@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> Message-ID: <54200C73.1070407@redhat.com> On 22.9.2014 10:38, Martin Kosek wrote: > On 09/22/2014 10:31 AM, Petr Spacek wrote: >> On 22.9.2014 10:14, Martin Kosek wrote: >>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>> https://fedorahosted.org/freeipa/ticket/4551 >>>> >>>> See ticket & commit message for details. >>> >>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current version just >>> hammer DNS server with as many DNS queries as it can send? >> >> Oh yes, please add some time.sleep() call :-) >> >> Also I would like to see more detailed message: >> + self.log.info('Waiting for hostname %s to be resolvable', >> + self.replica_fqdn) >> >> => 'Waiting for hostname %s to be resolvable to A or AAAA record' > > > > Really? Shouldn't term "resolvable" already have that covered? A good software > should work on all network types, whether it is IPv4, IPv6 or IPv8. So I > personally do not think we need to be that specific and can stick to original > proposal. I will agree with you if you post magic code which will work with DNS records for IPv8 :-) The code is not going to work with IPv8 just because we didn't mention 'A/AAAA' in the error message, A and AAAA RRtypes are hardcoded in the code. My point is that user should see what exactly IPA wants and thus exactly why it failed. Imagine that IPv8 is deployed and IPv8 addresses are stored in new RR type AAAAAAAA. Now somebody is installing/upgrading an old IPA installation and it gets stuck on 'Waiting for hostname %s to be resolvable' message. So he runs 'host new-replica.ipa.test.' command and it will return an IPv8 address. And here is the WTF moment: 'The message tells me that the name should be resolvable, it *is* resolvable but it still doesn't work!' This is exactly the problem I would like to address in ticket "[RFE] Make DNS error messages more clear - say exactly what is wrong" https://fedorahosted.org/freeipa/ticket/3298 -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 22 11:52:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Sep 2014 13:52:18 +0200 Subject: [Freeipa-devel] [PATCH 0297] Add log message about initial LDAP synchronization In-Reply-To: <541FF14E.9050607@redhat.com> References: <5419717C.4070103@redhat.com> <541FF14E.9050607@redhat.com> Message-ID: <54200D72.6050609@redhat.com> On 22.9.2014 11:52, Tomas Hozza wrote: > On 09/17/2014 01:33 PM, Petr Spacek wrote: >> >Hello, >> > >> >Add log message about initial LDAP synchronization. >> > > ACK. Thanks! Pushed to master: ce1b8f400d236d0da5b76c90ddc93adbf6980691 v4: f03ff4d877240f13db419fde28e51d216277b87c -- Petr^2 Spacek From mbasti at redhat.com Mon Sep 22 12:01:59 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 14:01:59 +0200 Subject: [Freeipa-devel] [PATCH 0298-0302] Implement handling of inactive master zones In-Reply-To: <541C33B2.7070303@redhat.com> References: <541C33B2.7070303@redhat.com> Message-ID: <54200FB7.5020806@redhat.com> On 19/09/14 15:46, Petr Spacek wrote: > Hello, > > This patch set fixes > https://fedorahosted.org/bind-dyndb-ldap/ticket/127 > https://bugzilla.redhat.com/show_bug.cgi?id=1138317 > > Please review it ASAP, it targets IPA 4.1/Fedora 21. > > Tomas and Martin, please communicate who is going to review what :-) > > Thank you for your time! > functional ACK, but wait for Tomas' ACK as well. my tests: * disable zone * enable zone * add record to disabled zone * delete record from disabled zone * add record to enabled zone * delete record from enabled zone * disable DNSSEC, enabled zone * enable DNSSEC, enabled zone * disable DNSSEC, disabled zone * enable DNSSEC, disabled zone * add disabled zone * delete disabled zone * add disabled zone with dnssec * delete disabled zone with dnssec * add zone * delete zone * disable zone without valid NS record * enable zone without valid NS record * Enable zone, Enable DNSSEC, Disable DNSSEC, disable zone, Enable DNSSEC in Disabled zone, Enable zone * freeIPA DNS tests * some random tests -- Martin Basti From pviktori at redhat.com Mon Sep 22 12:04:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Sep 2014 14:04:17 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <54048358.9000604@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> Message-ID: <54201041.2050201@redhat.com> On 09/01/2014 04:31 PM, Martin Basti wrote: > On 24/07/14 09:06, Martin Basti wrote: >> On 23/07/14 15:17, Martin Basti wrote: >>> This patch fixes ordering problem of schema updates >>> >>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>> (will be in Fedora 21) >>> >>> Patch attached >>> >>> >> I found a bug there, but before I send updated version, I need to >> decide how print modlist: >> >> 1. Print modlist before each LDAP update (if changes exist), show >> modlist per incremental update >> >> 2. Print modlist only at once with all updates >> >> 3. Use [1] for live_run, [2] for test >> > Print modlis before each LDAP update > Updated patch attached. Thanks! This works nicely, just some comments: The required python-ldap is quite new, not even built in Koji yet. We need to get it to the IPA COPR repo before this is merged. The _get_oid_dependency_order function is not indented well. It would be nice if it was a bit more obvious that the loop in _get_oid_dependency_order is guaranteed to terminate. Could you assert that len(unordered_oids) decreases in each iteration? > +SCHEMA_ELEMENT_CLASSES_KEYS = (x[0] for x in SCHEMA_ELEMENT_CLASSES) You're creating a generator here, which is only good for one use. Use a list instead. Also, this is used just once so it doesn't need to be a module-level constant. > + # FIXME: We should have a better way to display the modlist, > + # for now display raw output of our internal routine Not entirely related to your change, but you can drop this comment. Since 61887ac we don't use an internal routine. -- Petr? From pviktori at redhat.com Mon Sep 22 12:09:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Sep 2014 14:09:15 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <54200C73.1070407@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> Message-ID: <5420116B.7010303@redhat.com> On 09/22/2014 01:48 PM, Petr Spacek wrote: > On 22.9.2014 10:38, Martin Kosek wrote: >> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>> On 22.9.2014 10:14, Martin Kosek wrote: >>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>> >>>>> See ticket & commit message for details. >>>> >>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>> version just >>>> hammer DNS server with as many DNS queries as it can send? >>> >>> Oh yes, please add some time.sleep() call :-) Wow, no idea how that slipped out. Thanks for the catch. >>> Also I would like to see more detailed message: >>> + self.log.info('Waiting for hostname %s to be resolvable', >>> + self.replica_fqdn) >>> >>> => 'Waiting for hostname %s to be resolvable to A or AAAA record' >> >> >> >> Really? Shouldn't term "resolvable" already have that covered? A good >> software >> should work on all network types, whether it is IPv4, IPv6 or IPv8. So I >> personally do not think we need to be that specific and can stick to >> original >> proposal. > > I will agree with you if you post magic code which will work with DNS > records for IPv8 :-) The code is not going to work with IPv8 just > because we didn't mention 'A/AAAA' in the error message, A and AAAA > RRtypes are hardcoded in the code. +1; we're checking A and AAAA so that's what we should say we're doing. Is this wording OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0645.2-ipa-replica-prepare-Wait-for-the-DNS-entry-to-be-res.patch Type: text/x-patch Size: 3687 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 22 12:12:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Sep 2014 14:12:12 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes Message-ID: <5420121C.3050907@redhat.com> Hi, the attached patches fix various bugs and shortcomings in the CA management and renewal code. Related tickets: , . (Patch 319 was originally posted at .) Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319.1-Introduce-NSS-database-etc-ipa-nssdb.patch Type: text/x-patch Size: 15754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-324-Move-NSSDatabase-from-ipaserver.certs-to-ipapython.c.patch Type: text/x-patch Size: 20092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-325-Add-NSSDatabase.has_nickname-for-checking-nickname-p.patch Type: text/x-patch Size: 953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-326-Use-NSSDatabase-instead-of-direct-certutil-calls-in-.patch Type: text/x-patch Size: 9182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-327-Use-etc-ipa-nssdb-to-get-nicknames-of-IPA-certs-inst.patch Type: text/x-patch Size: 9095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-328-Check-if-IPA-client-is-configured-in-ipa-certupdate.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-329-Get-server-hostname-from-jsonrpc_uri-in-ipa-certupda.patch Type: text/x-patch Size: 1164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-330-Remove-ipa-ca.crt-from-systemwide-CA-store-on-client.patch Type: text/x-patch Size: 3574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-331-Fix-certmonger.wait_for_request.patch Type: text/x-patch Size: 972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-332-Refactor-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 20633 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-333-Restart-request-in-dogtag-ipa-ca-renew-agent-if-prof.patch Type: text/x-patch Size: 2085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-334-Do-not-wait-for-new-CA-certificate-to-appear-in-LDAP.patch Type: text/x-patch Size: 5051 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-335-Fail-if-certmonger-can-t-see-new-CA-certificate-in-L.patch Type: text/x-patch Size: 3102 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 22 12:11:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Sep 2014 14:11:29 +0200 Subject: [Freeipa-devel] [PATCH 0298-0302] Implement handling of inactive master zones In-Reply-To: <54200FB7.5020806@redhat.com> References: <541C33B2.7070303@redhat.com> <54200FB7.5020806@redhat.com> Message-ID: <542011F1.60502@redhat.com> On 09/22/2014 02:01 PM, Martin Basti wrote: > On 19/09/14 15:46, Petr Spacek wrote: >> Hello, >> >> This patch set fixes >> https://fedorahosted.org/bind-dyndb-ldap/ticket/127 >> https://bugzilla.redhat.com/show_bug.cgi?id=1138317 >> >> Please review it ASAP, it targets IPA 4.1/Fedora 21. >> >> Tomas and Martin, please communicate who is going to review what :-) >> >> Thank you for your time! >> > functional ACK, but wait for Tomas' ACK as well. > > my tests: > * disable zone > * enable zone > * add record to disabled zone > * delete record from disabled zone > * add record to enabled zone > * delete record from enabled zone > * disable DNSSEC, enabled zone > * enable DNSSEC, enabled zone > * disable DNSSEC, disabled zone > * enable DNSSEC, disabled zone > * add disabled zone > * delete disabled zone > * add disabled zone with dnssec > * delete disabled zone with dnssec > * add zone > * delete zone > * disable zone without valid NS record > * enable zone without valid NS record > * Enable zone, Enable DNSSEC, Disable DNSSEC, disable zone, Enable > DNSSEC in Disabled zone, Enable zone > * freeIPA DNS tests > * some random tests Could you ideally send a patch with these? Integration tests aren't very hard to write -- see ipatests/test_integration/test_service_permissions.py -- Petr? From npmccallum at redhat.com Mon Sep 22 12:38:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 22 Sep 2014 08:38:05 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <541FEA59.3010907@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <541FEA59.3010907@redhat.com> Message-ID: <1411389485.3483.13.camel@redhat.com> On Mon, 2014-09-22 at 11:22 +0200, thierry bordaz wrote: > On 09/20/2014 09:39 PM, Nathaniel McCallum wrote: > > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote: > >> Hello Nathaniel, > >> > >> sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It > >> looks good but difficult to think to all possible cases. > >> I think to the following corner case: > >> The initial entry has ipatokenHOTPcounter=5 > >> ldapmodify.. > >> changetype: modify > >> add: ipatokenHOTPcounter > >> ipatokenHOTPcounter: 6 > >> - > >> replace: ipatokenHOTPcounter > >> ipatokenHOTPcounter: 7 > >> > >> It translates > >> add: 6 > >> del: 5 > >> add: 7 > >> > >> This operation will fail because ipatokenHOTPcounter is > >> single-valued although IMHO it should succeed. > > No. It should fail. There can only ever be one ipatokenHOTPcounter. > > > >> This is a so special operation that is may not really be a > >> concern. > > +1 > > > >> It is important that attribute are single valued. The > >> replication changelog will replicated MOD/DEL + MOD/ADD for a > >> MOD/REPL. > >> That means that if the attributes are updated on several > >> masters, the number of values can likely increase. Where for > >> single value it should only keep the most recent value. > > That is a concern, at least for now. Eventually we won't use replication > > for this at all. But for now, we will. > > > > Here is the problem I foresee. You have two servers: A and B. > > > > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1). > > Replication is sent to server B. > > > > Before the replication is performed on server B, the user authenticates > > with the next token. This triggers a MOD/DEL(0)+MOD/ADD(2). Replication > > is sent to server A. This replication will fail because A has a value of > > 1, not a value of 0. > > > > The end result is that there will be different values for > > ipatokenHOTPcounter on the two different servers. A will have 1 and B > > will have 2. Once this happens, the replications can never reconcile > > (this is a big problem). I see two options here, both theoretical. > > The final value (when all updates has been replicated/applied) will rely > on the timestamp of the operation (CSN). When a CSN is generated on a > master it is guaranteed that it is greater (more recent) than any known > CSNs. In your scenario "nothing" can guaranty that the CSN of the > second update (B) is larger than the CSN of the first update. If CSN(B) > > CSN(A), the final value will be '2' else it will be '1'. > > When the server B will receive the first update ('1') its current value > is '2'. So it will reject the update, that may break replication. > If we decide to not control replicated update and if CSN(A) > CSN(B), > then the final value will go backward. The whole point of this plugin is, in a sense, to break replication. CSN is *not* sufficient to determine valid updates for the counter/watermark. We don't care what the CSN is, we only care whether the counter/watermark has increased. The counter/watermark MUST NEVER decrease. Please see my new patch here: http://www.redhat.com/archives/freeipa-devel/2014-September/msg00435.html > > Option #1 is to hook 389 in a different place: before the mods are > > performed by after the replication changelog is generated. > > Alternatively, we could insert a hook after the replication changelog is > > generated, but before it is sent. We could consolidate the MOD/DEL > > +MOD/ADD here into a single MOD/REPLACE operation. > With current replication it would be major change. Update of the > changelog is done in betxn_postop based on the operations mods. > > > > Option #2 is to have some way to translate the MOD/REPLACE(X) into a > > MOD/DEL(<=X)+MOD/ADD(X). > I think it is already what the plugin is doing. It retrieves the current > value from the entry and do a mod/del on this value then a mod/add of > the new value. (at the condition new_value>current_value). > My concern is that in your scenario, due to parallel update with several > new_values we may select an incorrect new_value. > > The 'Dynamic Master proxy' ( > http://www.freeipa.org/page/V4/OTP_Replay_Prevention#Replication_Counter_Race) > solution looks as a good one. Synchronous synchronization is the better plan on that page. But this is a *huge* task. Too big for 4.1. From thozza at redhat.com Mon Sep 22 13:10:58 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 22 Sep 2014 15:10:58 +0200 Subject: [Freeipa-devel] [PATCH 0298-0302] Implement handling of inactive master zones In-Reply-To: <541C33B2.7070303@redhat.com> References: <541C33B2.7070303@redhat.com> Message-ID: <54201FE2.6090801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/19/2014 03:46 PM, Petr Spacek wrote: > Hello, > > This patch set fixes > https://fedorahosted.org/bind-dyndb-ldap/ticket/127 > https://bugzilla.redhat.com/show_bug.cgi?id=1138317 > > Please review it ASAP, it targets IPA 4.1/Fedora 21. > > Tomas and Martin, please communicate who is going to review what :-) > > Thank you for your time! > The code seems to be fine. ACK. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUIB/eAAoJEMWIetUdnzwtTdUH/iJX0CY5c5inZVXqOv+5Tt+V pcAwe/vlh6/3qJbZaA2sUc+i3M9dNhM2v2TPAugzfF1ZDGKwCjn8T+7XROsit/17 67XfZDhw/3Q4wsmsxR24YUXG5Q7TlX9NdlvFOUtsbeGfKdQKxsZB+cResv5dz6O8 p/gyNvvKJOE8nbJ33yE5A2tUocdgJHDcgsgCKWiYP3pOleJuKHYK0uyQZmAxxOJ+ q09KTBoEUg7fOI+ekReCzUysdDzOJSc+6zpJQ8LbK/g8Fa5Pg/+q9zBKVN5xng9l 4TCvVzz8kkVp8ArNAl4nE5eLVaYksT4xUWmf2RMzbtxOzJ+gmrYmce4mHRR6zcM= =ViAQ -----END PGP SIGNATURE----- From simo at redhat.com Mon Sep 22 13:32:05 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 09:32:05 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411353227.3483.11.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> Message-ID: <20140922093205.67d082c9@willson.usersys.redhat.com> On Sun, 21 Sep 2014 22:33:47 -0400 Nathaniel McCallum wrote: Comments inline. > + > +#define ch_malloc(type) \ > + (type*) slapi_ch_malloc(sizeof(type)) > +#define ch_calloc(count, type) \ > + (type*) slapi_ch_calloc(count, sizeof(type)) > +#define ch_free(p) \ > + slapi_ch_free((void**) &(p)) please do not redefine slapi functions, it just makes it harder to know what you used. > +typedef struct { > + bool exists; > + long long value; > +} counter; please no typedefs of structures, use "struct counter { ... };" and reference it as "struct counter" in the code. Btw, FWIW you could use a value of -1 to indicate non-existence of the counter value, given counters can only be positive, this would avoid the need for a struct. > +static int > +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > +{ > + va_list ap; > + int res; > + > + va_start(ap, template); > + res = vsnprintf(NULL, 0, template, ap); > + va_end(ap); > + > + if (res > 0) { > + char str[res + 1]; > + > + va_start(ap, template); > + res = vsnprintf(str, sizeof(str), template, ap); > + va_end(ap); > + > + if (res > 0) > + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > + } > + > + if (res <= 0) > + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > + > + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > + return rc; > +} This function seem not really useful, you use send_error() only at the end of one single function where you could have the classic scheme of using a done: label and just use directly slapi_ch_smprintf. This would remove the need to use vsnprintf and all the va_ machinery which is more than 50% of this function. > +static long long > +get_value(const LDAPMod *mod, long long def) > +{ > + const struct berval *bv; > + long long val; > + > + if (mod == NULL) > + return def; > + > + if (mod->mod_vals.modv_bvals == NULL) > + return def; > + > + bv = mod->mod_vals.modv_bvals[0]; > + if (bv == NULL) > + return def; In general (here and elsewhere) I prefer to always use {} in if clauses. I have been bitten enough time by people adding an instruction that should be in the braces but forgot to add braces (defensive programming style). But up to you. > + char buf[bv->bv_len + 1]; > + memcpy(buf, bv->bv_val, bv->bv_len); > + buf[sizeof(buf)-1] = '\0'; > + > + val = strtoll(buf, NULL, 10); > + if (val == LLONG_MIN || val == LLONG_MAX) > + return def; > + > + return val; > +} > + > +static struct berval ** > +make_berval_array(long long value) > +{ > + struct berval **bvs; > + > + bvs = ch_calloc(2, struct berval*); > + bvs[0] = ch_malloc(struct berval); > + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > + > + return bvs; > +} > + > +static LDAPMod * > +make_ldapmod(int op, const char *attr, long long value) > +{ > + LDAPMod *mod; > + > + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > + mod->mod_op = op | LDAP_MOD_BVALUES; > + mod->mod_type = slapi_ch_strdup(attr); > + mod->mod_bvalues = make_berval_array(value); > + > + return mod; > +} > + > +static void > +convert_ldapmod_to_bval(LDAPMod *mod) > +{ > + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > + return; > + > + mod->mod_op |= LDAP_MOD_BVALUES; > + > + if (mod->mod_values == NULL) { > + mod->mod_bvalues = NULL; > + return; > + } > + > + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > + struct berval *bv = ch_malloc(struct berval); > + bv->bv_val = mod->mod_values[i]; > + bv->bv_len = strlen(bv->bv_val); > + mod->mod_bvalues[i] = bv; > + } > +} > + > +static counter > +get_counter(Slapi_Entry *entry, const char *attr) > +{ > + Slapi_Attr *sattr = NULL; > + > + return (counter) { > + slapi_entry_attr_find(entry, attr, &sattr) == 0, > + slapi_entry_attr_get_longlong(entry, attr) > + }; > +} > + > +static void > +berval_free_array(struct berval ***bvals) > +{ > + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > + ch_free((*bvals)[i]->bv_val); > + ch_free((*bvals)[i]); > + } > + > + slapi_ch_free((void**) bvals); > +} > + > +static bool > +is_replication(Slapi_PBlock *pb) > +{ > + int repl = 0; > + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > + return repl != 0; > +} > + > +static const char * > +get_attribute(Slapi_Entry *entry) > +{ > + static struct { > + const char *clss; > + const char *attr; > + } table[] = { > + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > + { NULL, NULL } > + }; > + > + const char *attr = NULL; > + char **clsses = NULL; > + > + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > + if (clsses == NULL) > + return NULL; > + > + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > j++) { > + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > + attr = table[j].attr; > + } > + } > + > + slapi_ch_array_free(clsses); > + return attr; > +} Can you put a comment here that explains what you are going to do in each cases in plain English ? This will help people in future figuring out if/how to modify the code or why something happens a specific way. It will also help the reviewer follow what is going on. > +static int > +preop_mod(Slapi_PBlock *pb) > +{ > + size_t count = 0, attrs = 0, extras = 0; > + Slapi_Entry *entry = NULL; > + const char *attr = NULL; > + LDAPMod **inmods = NULL; > + LDAPMod **mods = NULL; > + counter ctr, orig; > + > + /* Get the input values. */ > + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > + if (entry == NULL || inmods == NULL) > + return 0; > + > + /* Get the attribute name. */ > + attr = get_attribute(entry); > + if (attr == NULL) > + return 0; /* Not a token. */ > + > + /* Count items. */ > + while (inmods != NULL && inmods[count] != NULL) { ^^ this one would read much better as: for (count = 0; inmods[count] != NULL; count++) { You do not need to check for insmods != NULL as you already check for it and return 0 a few lines above. > + LDAPMod *mod = inmods[count++]; > + > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > + continue; > + > + attrs++; > + switch (mod->mod_op & LDAP_MOD_OP) { > + case LDAP_MOD_REPLACE: > + case LDAP_MOD_INCREMENT: > + extras++; > + break; > + } > + } > + > + /* Not operating on the counter/watermark. */ > + if (attrs == 0) > + return 0; > + > + /* Get the counter. */ > + orig = ctr = get_counter(entry, attr); > + > + /* Filter the modify operations. */ > + mods = ch_calloc(count + extras + 1, LDAPMod*); > + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > mods[j++] = inmods[i++]) { Please remove check for insmods != NULL, it is useless, and removing it will bring back the line under 80columns > + LDAPMod *mod = inmods[i]; > + > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > + continue; > + > + convert_ldapmod_to_bval(mod); > + > + switch (mod->mod_op & LDAP_MOD_OP) { > + case LDAP_MOD_DELETE: > + ctr.exists = false; > + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > NULL) > + berval_free_array(&mod->mod_bvalues); > + > + if (is_replication(pb)) > + berval_free_array(&mod->mod_bvalues); > + > + if (mod->mod_bvalues == NULL) > + mod->mod_bvalues = make_berval_array(ctr.value); > + break; I am not sure I understand this segment, why are you touching the delete operation outside of a replication event ? Doesn't this defeat and admin tool trying to correctly delete/add to avoid races ? > + case LDAP_MOD_INCREMENT: > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > ctr.value); + > + ctr.value += get_value(mod, 1); uhmmm if you had an ADD followed by INCREMENT operation, would this cause the value to become value*2+1 instead of just value+1 ? > + berval_free_array(&mod->mod_bvalues); > + mod->mod_op &= ~LDAP_MOD_OP; > + mod->mod_op |= LDAP_MOD_ADD; > + mod->mod_bvalues = make_berval_array(ctr.value); > + break; uhmm why are you converting mod_increment in all cases ? (including replication) > + case LDAP_MOD_REPLACE: > + if (ctr.exists) > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > ctr.value); + > + mod->mod_op &= ~LDAP_MOD_OP; > + mod->mod_op |= LDAP_MOD_ADD; same question here, why are you converting a replace coming from replication into a delete/add ? > + case LDAP_MOD_ADD: > + ctr.value = get_value(mod, 0); > + ctr.exists = true; > + break; > + } > + } > + > + /* Set the modified operations. */ > + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > + ch_free(inmods); > + > + /* Ensure we aren't deleting the counter. */ > + if (orig.exists && !ctr.exists) > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > + "Will not delete %s", attr); > + > + /* Ensure we aren't rolling back the counter. */ > + if (orig.value > ctr.value) > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > + "Will not decrement %s", attr); > + > + return 0; > +} see above about send_error(). I think what is needed most is the comment that explains the process at the to of the main function. Simo. -- Simo Sorce * Red Hat, Inc * New York From dkupka at redhat.com Mon Sep 22 13:36:01 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 22 Sep 2014 15:36:01 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <541B35A9.7010404@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> Message-ID: <542025C1.1050708@redhat.com> On 09/18/2014 09:42 PM, Martin Kosek wrote: > On 09/18/2014 09:11 PM, Simo Sorce wrote: >> On Thu, 18 Sep 2014 14:57:45 -0400 >> Rob Crittenden wrote: >> >>> Martin Kosek wrote: >>>> On 09/18/2014 04:06 PM, David Kupka wrote: >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>>>>> David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 >>>>>> >>>>>> You are removing an ACI in this patch. It is always possible it >>>>>> is no longer needed. Did you test all the client enrollment >>>>>> scenarios? >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI so >>>>> it is possible to add krbPrincipalName to host even when there is >>>>> already one (or more). And adding one ACI to allow writing >>>>> krbCanonicalName to host. But I'm still not really familiar with >>>>> ACI so please correct me if I'm wrong. >>>>> >>>> >>>> What refers to is probably the update in ACI.txt - the ACI >>>> alternative to API.txt. David updated an ACI, not removed it. >>>> >>>> On that note, what is the reason for this permission change: >>>> >>>> - 'ipapermtargetfilter': [ >>>> - '(objectclass=ipahost)', >>>> - '(!(krbprincipalname=*))', >>>> - ], >>>> >>>> ? >>> >>> Yes, this is exactly the change I was referring to. Permission changes >>> within a plugin now translate automatically to ACI changes. Sorry I >>> wasn't clearer. >>> >>> This ACI gets replaced with a much simpler one and I'm not 100% sure >>> it will work with all enrollments: >>> >>> -aci: (targetattr = "krbprincipalname")(targetfilter = >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >>> "permission:System: Add krbPrincipalName to a Host";allow (write) >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> +aci: (targetattr = "krbprincipalname")(targetfilter = >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >>> krbPrincipalName to a Host";allow (write) groupdn = >>> "ldap:///cn=System: Add krbPrincipalName to a >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> The first one restricts writing the attribute only if it isn't already >>> set. The second lets it be changed unconditionally. >> >> Yeah this is wrong indeed, the point of the ACI is to allow setting the >> principal only when it is not already set, which is the OTP enrollment >> case. But if krbprincipal is set then this specific permission should >> not grant rights to change it. >> >> At least this was my understanding. >> >> Simo. > > Right. It seems to me we should add keep this permission intact and add > a new permission allowing adding krbPrincipalName aliases. This would > allow writing both krbPrincipalName and krbCanonicalName. > > Martin > Thank you all for explanation and help. I rewrote the patch so it should work as requested now. Also I added tests to reassure the behavior is correct. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0015-2-Allow-multiple-krbprincipalnames.patch Type: text/x-patch Size: 7526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0016-2-Test-Allow-multiple-krbPrincipalNames.patch Type: text/x-patch Size: 7348 bytes Desc: not available URL: From tbordaz at redhat.com Mon Sep 22 13:48:21 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 22 Sep 2014 15:48:21 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1411157743.18665.12.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> Message-ID: <542028A5.4040309@redhat.com> Hello Nathaniel, I have a separated remark about updating the mods. modifications of the entry occurs in two phases: * call BE_PREOP plugins then apply the mods on the entry * call BE_TXN_PREOP plugin then apply *only* extra mods on the entry The plugin (BE_TXN_PREOP) translates a MOD/replace from MOD/DEL (current value) + MOD/ADD(new value). The translation is done like this: MOD[0]: MOD/REPL ipatokenHOTPcounter new_value MOD[1]: MOD/REPL modifiersname MOD[2]: MOD/REPL modifytimestamp MOD[3]: MOD/REPL entryusn --> MOD[0]: MOD/DEL ipatokenHOTPcounter current_value MOD[1]: MOD/ADD ipatokenHOTPcounter new_value MOD[2]: MOD/REPL modifiersname MOD[3]: MOD/REPL modifytimestamp MOD[4]: MOD/REPL entryusn That means, we have one added mod (MOD[4]=entryusn) after BE_TXN_PREOP that will be (re)applied on the second phase. So the MOD/DEL+MOD/ADD will not be processed. MOD/REPL will be processed before MOD/DEL+MOD/ADD are generated. If MOD/DEL+MOD/ADD is needed, then we may need to replace REPL->DEL/ADD in BE_PREOP callback. The control done in plugin BE_TXN_PREOP is working fine and guaranties the counter does not decrease. thanks thierry On 09/19/2014 10:15 PM, Nathaniel McCallum wrote: > This new version fixes a small style issue pointed out to me by richm > (thanks!). > > On Fri, 2014-09-19 at 13:39 -0400, Nathaniel McCallum wrote: >> The attached version of the patch should solve all of these issues. It >> should also be more performant and use less memory. >> >> Nathaniel >> >> >> On Wed, 2014-09-17 at 15:33 +0200, thierry bordaz wrote: >>> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote: >>> >>>> This plugin ensures that all counter/watermark operations are atomic >>>> and never decrement. Also, deletion is not permitted. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4494 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Hello Nathaniel, >>> >>> More thoughts.. I think being "betxnpreoperation" you are safe >>> with parallel client ops and the check is atomic. I have few >>> comments: >>> * Shouldn't be implemented >>> SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, >>> even if they are empty. >>> * In load_counters, in case we have a target entry that >>> has not 'objectclass' 'ipatokenHOTP|ipatokenTOTP' and >>> the mod operation: >>> dn: >>> changetype: modify >>> replace: ipatokenHOTPcounter >>> ipatokenHOTPcounter: 200 >>> - >>> add: objectclass >>> objectclass: ipatokenHOTP >>> >>> >>> I wonder if the operation will not fail although IMHO >>> it should succeeds. >>> Shouldn't let the schema checking reject the operation >>> if the attribute is not granted by the entry >>> objectclass >>> * in load_counters, I am under the impression it may >>> return ipatokenHOTPcounter or ipatokenTOTPwatermark >>> (ipatokenHOTPcounter is missing). >>> But then how the caller knows that the returned value >>> is a counter or a watermark ? >>> * in ldapmod_is_attrs you may prefer PL_strcasecmp to >>> strcasecmp >>> >>> About replicated updates, if updates of counters/watermark are >>> done on several servers. Then a replicated operation may want >>> to set counters/watermark with a smaller value that the >>> existing one. In that case, it will return unwilling to >>> perform. That could break replication. >>> If the update comes from replication and the value is going >>> backward, we could make the operation a nop operation (setting >>> the attribute to its current value). >>> >>> >>> thanks >>> theirry >>> >>> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Sep 22 13:50:13 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 09:50:13 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <541FDF2E.909@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> Message-ID: <20140922095013.3c71bafd@willson.usersys.redhat.com> On Mon, 22 Sep 2014 10:34:54 +0200 Martin Kosek wrote: > On 09/22/2014 09:33 AM, thierry bordaz wrote: > > Hello Nathaniel, > > > > Just a remark, in is_token if the entry is objectclass=ipaToken > > it returns without freeing the 'objectclass' char array. > > > > thanks > > thierry > > > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > >> Users that can rename the token (such as admins) can also create > >> non-UUID token names. > >> > >> https://fedorahosted.org/freeipa/ticket/4456 > >> > >> NOTE: this patch is an alternate approach to my patch 0065. This > >> version has two main advantages compared to 0065: > >> 1. Permissions are more flexible (not tied to the admin group). > >> 2. Enforcement occurs at the DS-level > >> > >> It should also be noted that this patch does not enforce UUID > >> randomness, only syntax. Users can still specify a token ID so > >> long as it is in UUID format. > >> > >> Nathaniel > > I am still thinking we may be overcomplicating it. Why cannot we use > the similar UUID generation mechanism as we do for SUDO commands for > example: > > # ipa sudocmd-add barbar --all --raw > --------------------------- > Added Sudo Command "barbar" > --------------------------- > dn: > ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > sudocmd: barbar > ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > objectClass: ipasudocmd > objectClass: ipaobject > > It lets DS generate&rename the object's DN when it finds out that the > ipaUniqueID is set to "autogenerate" (in baseldap.py). We could let > DS generate the UUID and only add the "autogenerate" keyword in > otptoken-add command. > > For authorization, we can simply allow users to only add tokens with > "autogenerate" ID, see my example here: > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > > Admin's or special privilege-owners would have more generous ACI > allowing other values than just "autogenerate". > > IMO, then the whole ipatoken-add mechanism would be a lot simpler and > we would not need a special DS plugin (unless we want regular users > to generate their own UUIDs instead of letting IPA DS to generate it > - which I do not think is the case). Good point Martin. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Mon Sep 22 14:02:01 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 22 Sep 2014 10:02:01 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <20140922095013.3c71bafd@willson.usersys.redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> Message-ID: <1411394521.3483.20.camel@redhat.com> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: > On Mon, 22 Sep 2014 10:34:54 +0200 > Martin Kosek wrote: > > > On 09/22/2014 09:33 AM, thierry bordaz wrote: > > > Hello Nathaniel, > > > > > > Just a remark, in is_token if the entry is objectclass=ipaToken > > > it returns without freeing the 'objectclass' char array. > > > > > > thanks > > > thierry > > > > > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > > >> Users that can rename the token (such as admins) can also create > > >> non-UUID token names. > > >> > > >> https://fedorahosted.org/freeipa/ticket/4456 > > >> > > >> NOTE: this patch is an alternate approach to my patch 0065. This > > >> version has two main advantages compared to 0065: > > >> 1. Permissions are more flexible (not tied to the admin group). > > >> 2. Enforcement occurs at the DS-level > > >> > > >> It should also be noted that this patch does not enforce UUID > > >> randomness, only syntax. Users can still specify a token ID so > > >> long as it is in UUID format. > > >> > > >> Nathaniel > > > > I am still thinking we may be overcomplicating it. Why cannot we use > > the similar UUID generation mechanism as we do for SUDO commands for > > example: > > > > # ipa sudocmd-add barbar --all --raw > > --------------------------- > > Added Sudo Command "barbar" > > --------------------------- > > dn: > > ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > > sudocmd: barbar > > ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > > objectClass: ipasudocmd > > objectClass: ipaobject > > > > It lets DS generate&rename the object's DN when it finds out that the > > ipaUniqueID is set to "autogenerate" (in baseldap.py). We could let > > DS generate the UUID and only add the "autogenerate" keyword in > > otptoken-add command. > > > > For authorization, we can simply allow users to only add tokens with > > "autogenerate" ID, see my example here: > > > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > > > > Admin's or special privilege-owners would have more generous ACI > > allowing other values than just "autogenerate". > > > > IMO, then the whole ipatoken-add mechanism would be a lot simpler and > > we would not need a special DS plugin (unless we want regular users > > to generate their own UUIDs instead of letting IPA DS to generate it > > - which I do not think is the case). > > Good point Martin. This is the avenue I first pursued. The problem is that the client has no way to look up the DN after the entry is added. In the case of sudocmd-add, the lookup is performed using the sudocmd attribute (see sudocmd.get_dn()). We have no similar attribute in this case and the lookup cannot be performed. Nathaniel From simo at redhat.com Mon Sep 22 14:16:48 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 10:16:48 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <542025C1.1050708@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> Message-ID: <20140922101648.5abe7031@willson.usersys.redhat.com> On Mon, 22 Sep 2014 15:36:01 +0200 David Kupka wrote: > On 09/18/2014 09:42 PM, Martin Kosek wrote: > > On 09/18/2014 09:11 PM, Simo Sorce wrote: > >> On Thu, 18 Sep 2014 14:57:45 -0400 > >> Rob Crittenden wrote: > >> > >>> Martin Kosek wrote: > >>>> On 09/18/2014 04:06 PM, David Kupka wrote: > >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >>>>>> David Kupka wrote: > >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 > >>>>>> > >>>>>> You are removing an ACI in this patch. It is always possible it > >>>>>> is no longer needed. Did you test all the client enrollment > >>>>>> scenarios? > >>>>>> > >>>>>> rob > >>>>>> > >>>>> > >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI > >>>>> so it is possible to add krbPrincipalName to host even when > >>>>> there is already one (or more). And adding one ACI to allow > >>>>> writing krbCanonicalName to host. But I'm still not really > >>>>> familiar with ACI so please correct me if I'm wrong. > >>>>> > >>>> > >>>> What refers to is probably the update in ACI.txt - the ACI > >>>> alternative to API.txt. David updated an ACI, not removed it. > >>>> > >>>> On that note, what is the reason for this permission change: > >>>> > >>>> - 'ipapermtargetfilter': [ > >>>> - '(objectclass=ipahost)', > >>>> - '(!(krbprincipalname=*))', > >>>> - ], > >>>> > >>>> ? > >>> > >>> Yes, this is exactly the change I was referring to. Permission > >>> changes within a plugin now translate automatically to ACI > >>> changes. Sorry I wasn't clearer. > >>> > >>> This ACI gets replaced with a much simpler one and I'm not 100% > >>> sure it will work with all enrollments: > >>> > >>> -aci: (targetattr = "krbprincipalname")(targetfilter = > >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl > >>> "permission:System: Add krbPrincipalName to a Host";allow (write) > >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a > >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> > >>> +aci: (targetattr = "krbprincipalname")(targetfilter = > >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add > >>> krbPrincipalName to a Host";allow (write) groupdn = > >>> "ldap:///cn=System: Add krbPrincipalName to a > >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> > >>> The first one restricts writing the attribute only if it isn't > >>> already set. The second lets it be changed unconditionally. > >> > >> Yeah this is wrong indeed, the point of the ACI is to allow > >> setting the principal only when it is not already set, which is > >> the OTP enrollment case. But if krbprincipal is set then this > >> specific permission should not grant rights to change it. > >> > >> At least this was my understanding. > >> > >> Simo. > > > > Right. It seems to me we should add keep this permission intact and > > add a new permission allowing adding krbPrincipalName aliases. This > > would allow writing both krbPrincipalName and krbCanonicalName. > > > > Martin > > > > Thank you all for explanation and help. I rewrote the patch so it > should work as requested now. Also I added tests to reassure the > behavior is correct. Sorry for not catching this earlier, but should we also add new IPA MODRDN configuration ? We currently change krbPrincipalName if the user uid changes. However perhaps what we should do is instead to allows aliases only for service/host principals but not for ipa users, at least for now. Should we also change permissions so that host/service entries *cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN configuration so that if a service/host krbprincipalname is changed then krbcanonicalname is too. Last but not least, and here I regret we may have a BIG issue, I just realize we use krbprincipalname in the Services DN, if we add additional values there does it mean we end up with a multivalued RDN ? That may be a problem, in such case should we rename services to use krbcanonicalname as the rnd instead ? We can do this in a compatible manner I think by renaming on the fly old entries if the still use krbprincipalname and changing our code to start always setting krbcanonicalname on new entries and set both canmonical and principal name on every new entry. Opinions ? -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon Sep 22 14:41:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Sep 2014 16:41:33 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <541C2199.8010404@redhat.com> References: <541C2199.8010404@redhat.com> Message-ID: <5420351D.5050605@redhat.com> On 19.9.2014 14:29, Petr Vobornik wrote: > Hello, > > attached patches implements Web UI part of ID Views. Backend is > currently on review as well - thread "[PATCHES 247-259] ID views - > management part". > > https://fedorahosted.org/freeipa/ticket/4535 > > I expect that backed can change and that the UI might influence it as > well. Therefore no UI integration tests nor static data files are > included in this patchset. They will follow when backend is stable. > > First 5 patches extends UI framework to support the main patch (#754). > > > == [PATCH] 749 webui: improve breadcrumb navigation == > > Fixes issue when: > - user navigates to a nested facet > - refreshes browser > - uses breadcrumb navigation to go to parent entity page which requires > a pkey. E.g. from automount keys to maps. > > The old code relies on the facet, that user visited the parent facet > before and therefore the facet has pkey stored. It fails after the > browser reload. > > Allows to specify a containing_facet. It allows breadcrumb navigation to > return to a different facet than the 'default'. > > == [PATCH] 750 webui: treat value as pkey in link widget == > > Current default mechanism of a link widget assumes that pkeys of a > current facet are pkeys for the link. It works for the only usage - in > password policy. It's rather inflexible since it can't be used if the > keys are in other attribute. This behavior is also bad in nested > entities - creates a link to itself which is pointless. > > This patch changes the default behavior to assume that the supplied > value are the pkeys and that the last pkey is the value to display. > > It also keeps the old method of overriding `other_pkeys` method so if > the last and only pkey is the actual value to display then the method > can tranform it into the pkeys which keeps compatibility with descendant > widgets (`host_dnsrecord_entity_link_widget`, > `dnsrecord_host_link_widget`). > > == [PATCH] 751 webui: do not show internal facet name to user == > > == [PATCH] 752 webui: allow to skip link widget link validation == > > == [PATCH] 753 webui: add simple link column suppor == > > Usual link columns are link with primary key of current entity. > > This patch allows to create a link to arbitrary non-nested entity. > > == [PATCH] 754 webui: new ID views section == > Attaching new version of #754. It: - makes anchor fields in id override adder dialogs editable in order to allow specifying trusted domain users/groups - adds tooltip to explain that search doesn't list users/groups from trusted domains a ticket to offer prefixes of trusted domains filed: https://fedorahosted.org/freeipa/ticket/4554 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0754-1-webui-new-ID-views-section.patch Type: text/x-patch Size: 32915 bytes Desc: not available URL: From pvoborni at redhat.com Mon Sep 22 14:49:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Sep 2014 16:49:16 +0200 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check Message-ID: <542036EC.90304@redhat.com> [PATCH] webui-ci: case-insensitive record check Indirect association are no longer lower cased, which caused a issue in CI. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0755-webui-ci-case-insensitive-record-check.patch Type: text/x-patch Size: 1676 bytes Desc: not available URL: From pvoborni at redhat.com Mon Sep 22 14:50:01 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Sep 2014 16:50:01 +0200 Subject: [Freeipa-devel] [PATCH] 756 webui: fix regression in association facet preop Message-ID: <54203719.1040304@redhat.com> Association facet specs use 'add_method' instead of 'add_command' origin: https://fedorahosted.org/freeipa/ticket/4507 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0756-webui-fix-regression-in-association-facet-preop.patch Type: text/x-patch Size: 1276 bytes Desc: not available URL: From simo at redhat.com Mon Sep 22 14:55:44 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 10:55:44 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <1411394521.3483.20.camel@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> Message-ID: <20140922105544.44ac8885@willson.usersys.redhat.com> On Mon, 22 Sep 2014 10:02:01 -0400 Nathaniel McCallum wrote: > On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: > > On Mon, 22 Sep 2014 10:34:54 +0200 > > Martin Kosek wrote: > > > > > On 09/22/2014 09:33 AM, thierry bordaz wrote: > > > > Hello Nathaniel, > > > > > > > > Just a remark, in is_token if the entry is > > > > objectclass=ipaToken it returns without freeing the > > > > 'objectclass' char array. > > > > > > > > thanks > > > > thierry > > > > > > > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > > > >> Users that can rename the token (such as admins) can also > > > >> create non-UUID token names. > > > >> > > > >> https://fedorahosted.org/freeipa/ticket/4456 > > > >> > > > >> NOTE: this patch is an alternate approach to my patch 0065. > > > >> This version has two main advantages compared to 0065: > > > >> 1. Permissions are more flexible (not tied to the admin group). > > > >> 2. Enforcement occurs at the DS-level > > > >> > > > >> It should also be noted that this patch does not enforce UUID > > > >> randomness, only syntax. Users can still specify a token ID so > > > >> long as it is in UUID format. > > > >> > > > >> Nathaniel > > > > > > I am still thinking we may be overcomplicating it. Why cannot we > > > use the similar UUID generation mechanism as we do for SUDO > > > commands for example: > > > > > > # ipa sudocmd-add barbar --all --raw > > > --------------------------- > > > Added Sudo Command "barbar" > > > --------------------------- > > > dn: > > > ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > > > sudocmd: barbar > > > ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > > > objectClass: ipasudocmd > > > objectClass: ipaobject > > > > > > It lets DS generate&rename the object's DN when it finds out that > > > the ipaUniqueID is set to "autogenerate" (in baseldap.py). We > > > could let DS generate the UUID and only add the "autogenerate" > > > keyword in otptoken-add command. > > > > > > For authorization, we can simply allow users to only add tokens > > > with "autogenerate" ID, see my example here: > > > > > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > > > > > > Admin's or special privilege-owners would have more generous ACI > > > allowing other values than just "autogenerate". > > > > > > IMO, then the whole ipatoken-add mechanism would be a lot simpler > > > and we would not need a special DS plugin (unless we want regular > > > users to generate their own UUIDs instead of letting IPA DS to > > > generate it > > > - which I do not think is the case). > > > > Good point Martin. > > This is the avenue I first pursued. The problem is that the client has > no way to look up the DN after the entry is added. In the case of > sudocmd-add, the lookup is performed using the sudocmd attribute (see > sudocmd.get_dn()). We have no similar attribute in this case and the > lookup cannot be performed. Well in theory we could search with creatorName and createTimestamp set to the user's own DN and a range a few seconds in the past ... It is not robust if you add multiple tokens at the same time, but would this be a concern for user created tokens ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Sep 22 15:02:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Sep 2014 18:02:03 +0300 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <20140922101648.5abe7031@willson.usersys.redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> <20140922101648.5abe7031@willson.usersys.redhat.com> Message-ID: <20140922150203.GA11503@redhat.com> On Mon, 22 Sep 2014, Simo Sorce wrote: >On Mon, 22 Sep 2014 15:36:01 +0200 >David Kupka wrote: > >> On 09/18/2014 09:42 PM, Martin Kosek wrote: >> > On 09/18/2014 09:11 PM, Simo Sorce wrote: >> >> On Thu, 18 Sep 2014 14:57:45 -0400 >> >> Rob Crittenden wrote: >> >> >> >>> Martin Kosek wrote: >> >>>> On 09/18/2014 04:06 PM, David Kupka wrote: >> >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >> >>>>>> David Kupka wrote: >> >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 >> >>>>>> >> >>>>>> You are removing an ACI in this patch. It is always possible it >> >>>>>> is no longer needed. Did you test all the client enrollment >> >>>>>> scenarios? >> >>>>>> >> >>>>>> rob >> >>>>>> >> >>>>> >> >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI >> >>>>> so it is possible to add krbPrincipalName to host even when >> >>>>> there is already one (or more). And adding one ACI to allow >> >>>>> writing krbCanonicalName to host. But I'm still not really >> >>>>> familiar with ACI so please correct me if I'm wrong. >> >>>>> >> >>>> >> >>>> What refers to is probably the update in ACI.txt - the ACI >> >>>> alternative to API.txt. David updated an ACI, not removed it. >> >>>> >> >>>> On that note, what is the reason for this permission change: >> >>>> >> >>>> - 'ipapermtargetfilter': [ >> >>>> - '(objectclass=ipahost)', >> >>>> - '(!(krbprincipalname=*))', >> >>>> - ], >> >>>> >> >>>> ? >> >>> >> >>> Yes, this is exactly the change I was referring to. Permission >> >>> changes within a plugin now translate automatically to ACI >> >>> changes. Sorry I wasn't clearer. >> >>> >> >>> This ACI gets replaced with a much simpler one and I'm not 100% >> >>> sure it will work with all enrollments: >> >>> >> >>> -aci: (targetattr = "krbprincipalname")(targetfilter = >> >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >> >>> "permission:System: Add krbPrincipalName to a Host";allow (write) >> >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> >>> >> >>> +aci: (targetattr = "krbprincipalname")(targetfilter = >> >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >> >>> krbPrincipalName to a Host";allow (write) groupdn = >> >>> "ldap:///cn=System: Add krbPrincipalName to a >> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> >>> >> >>> The first one restricts writing the attribute only if it isn't >> >>> already set. The second lets it be changed unconditionally. >> >> >> >> Yeah this is wrong indeed, the point of the ACI is to allow >> >> setting the principal only when it is not already set, which is >> >> the OTP enrollment case. But if krbprincipal is set then this >> >> specific permission should not grant rights to change it. >> >> >> >> At least this was my understanding. >> >> >> >> Simo. >> > >> > Right. It seems to me we should add keep this permission intact and >> > add a new permission allowing adding krbPrincipalName aliases. This >> > would allow writing both krbPrincipalName and krbCanonicalName. >> > >> > Martin >> > >> >> Thank you all for explanation and help. I rewrote the patch so it >> should work as requested now. Also I added tests to reassure the >> behavior is correct. > > >Sorry for not catching this earlier, but should we also add new IPA >MODRDN configuration ? >We currently change krbPrincipalName if the user uid changes. > >However perhaps what we should do is instead to allows aliases only for >service/host principals but not for ipa users, at least for now. I think it is sensible approach to limit aliases for service/host principals only. >Should we also change permissions so that host/service entries >*cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN >configuration so that if a service/host krbprincipalname is changed >then krbcanonicalname is too. Yes, host/service shouldn't be renamed. Additionally, this would make also their certificates "obsolete", in certain sense. >Last but not least, and here I regret we may have a BIG issue, I just >realize we use krbprincipalname in the Services DN, if we add >additional values there does it mean we end up with a multivalued RDN ? Unfortunately, this is what happens right now if you add more than one krbprincipalname already. Things seem to work fine except you cannot address such objects in Web UI and CLI. >That may be a problem, in such case should we rename services to use >krbcanonicalname as the rnd instead ? We can do this in a compatible >manner I think by renaming on the fly old entries if the still use >krbprincipalname and changing our code to start always setting >krbcanonicalname on new entries and set both canmonical and principal >name on every new entry. Sounds reasonable to me. -- / Alexander Bokovoy From mbasti at redhat.com Mon Sep 22 15:05:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 17:05:15 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541FC75E.4060304@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> Message-ID: <54203AAB.70607@redhat.com> On 22/09/14 08:53, Martin Kosek wrote: > On 09/19/2014 06:33 PM, Simo Sorce wrote: >> On Fri, 19 Sep 2014 17:50:16 +0200 >> Martin Kosek wrote: >> >>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>>> Martin Basti wrote: >>>>> Hello list, >>>>> >>>>> I need to use systemd mask/unmask in ipa service. >>>>> >>>>> But as Honza wrote: >>>>> "IMO masking/unmasking should be part of disabling/enabling a >>>>> service in systemd. AFAIK in most other init systems when you >>>>> disable a service, it has the same effect as masking the service >>>>> in systemd - it will never be started until it is enabled/unmasked >>>>> again. " >>>>> >>>>> So my questions is, should be masking part of disabling service in >>>>> systemd, to be platform independent? >>>>> Or should we add mask/unmask methods to >>>>> ipaplatform.base.services.PlatformService where mask is alias for >>>>> disable? >>>>> >>>>> Martin^2 >>>>> >>>> After readinghttp://0pointer.de/blog/projects/three-levels-of-off I >>>> disagree that disabling in SysV is the same as masking in systemd, >>>> though I guess it depends on the meaning of disable. According to >>>> that page chkconfig off is equivalent to systemctl disable >>>> .service, which is what we do now AFAIR. >>>> >>>> Why do you need to mask a service, e.g. render it completely >>>> unstartable? >>>> >>>> rob >>> I do not have full context, but looks like a good question. We only >>> enable ipa "service" and starts via ipactl all other services. So we >>> can disable/enable/mask services on the LDAP level, not on systemd >>> level. >> I do not think masking is right for now, however I'd like to chime in >> given there is work around this. >> >> The current ipactl method was necessary due to issues in using systemd >> fully, however if newer systemds have bugs about enabling/disabling unit >> files from another one fixed then we should look into making the >> ipa.service use ipactl *only* to enable/disable unit files. >> This way if we can create the various unit files as eg: >> ipa-httpd.service where the only thing we do is add an After: >> ipa.service and then include the system's httpd.service file we will be >> in a better situation. >> Especially on shutdown, as no matter what changed in LDAP on shutdown >> we do not even lookup anything and just let systemd tear down all >> services in the ipa group (I guess there is a way to tell systemd that >> if ipa.service goes down all it's dependent services also need to go >> down. >> >> I know this is a major refactoring, but if we can pull it off, this is >> the correct way to go with systemd integration in the longer term. >> >> Simo. >> > Probably yes, I already had a discussion with systemd folks about a native > systemd way to manage the services. I filed a ticket: > > https://fedorahosted.org/freeipa/ticket/4552 > > This shouldn't stop these patches though, especially if they are required for > the DNSSEC feature. > > Martin Back to my question. Should we use the mask as systemd specific and use it in disable, or create the mask method in platform module? IMHO, IPA is mainly used on systemd platforms, so we could add mask method, which can be used as alias for disabling on other systems. -- Martin Basti From npmccallum at redhat.com Mon Sep 22 15:14:31 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 22 Sep 2014 11:14:31 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <20140922105544.44ac8885@willson.usersys.redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> Message-ID: <1411398871.3483.22.camel@redhat.com> On Mon, 2014-09-22 at 10:55 -0400, Simo Sorce wrote: > On Mon, 22 Sep 2014 10:02:01 -0400 > Nathaniel McCallum wrote: > > > On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: > > > On Mon, 22 Sep 2014 10:34:54 +0200 > > > Martin Kosek wrote: > > > > > > > On 09/22/2014 09:33 AM, thierry bordaz wrote: > > > > > Hello Nathaniel, > > > > > > > > > > Just a remark, in is_token if the entry is > > > > > objectclass=ipaToken it returns without freeing the > > > > > 'objectclass' char array. > > > > > > > > > > thanks > > > > > thierry > > > > > > > > > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > > > > >> Users that can rename the token (such as admins) can also > > > > >> create non-UUID token names. > > > > >> > > > > >> https://fedorahosted.org/freeipa/ticket/4456 > > > > >> > > > > >> NOTE: this patch is an alternate approach to my patch 0065. > > > > >> This version has two main advantages compared to 0065: > > > > >> 1. Permissions are more flexible (not tied to the admin group). > > > > >> 2. Enforcement occurs at the DS-level > > > > >> > > > > >> It should also be noted that this patch does not enforce UUID > > > > >> randomness, only syntax. Users can still specify a token ID so > > > > >> long as it is in UUID format. > > > > >> > > > > >> Nathaniel > > > > > > > > I am still thinking we may be overcomplicating it. Why cannot we > > > > use the similar UUID generation mechanism as we do for SUDO > > > > commands for example: > > > > > > > > # ipa sudocmd-add barbar --all --raw > > > > --------------------------- > > > > Added Sudo Command "barbar" > > > > --------------------------- > > > > dn: > > > > ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > > > > sudocmd: barbar > > > > ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > > > > objectClass: ipasudocmd > > > > objectClass: ipaobject > > > > > > > > It lets DS generate&rename the object's DN when it finds out that > > > > the ipaUniqueID is set to "autogenerate" (in baseldap.py). We > > > > could let DS generate the UUID and only add the "autogenerate" > > > > keyword in otptoken-add command. > > > > > > > > For authorization, we can simply allow users to only add tokens > > > > with "autogenerate" ID, see my example here: > > > > > > > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > > > > > > > > Admin's or special privilege-owners would have more generous ACI > > > > allowing other values than just "autogenerate". > > > > > > > > IMO, then the whole ipatoken-add mechanism would be a lot simpler > > > > and we would not need a special DS plugin (unless we want regular > > > > users to generate their own UUIDs instead of letting IPA DS to > > > > generate it > > > > - which I do not think is the case). > > > > > > Good point Martin. > > > > This is the avenue I first pursued. The problem is that the client has > > no way to look up the DN after the entry is added. In the case of > > sudocmd-add, the lookup is performed using the sudocmd attribute (see > > sudocmd.get_dn()). We have no similar attribute in this case and the > > lookup cannot be performed. > > Well in theory we could search with creatorName and createTimestamp set > to the user's own DN and a range a few seconds in the past ... > It is not robust if you add multiple tokens at the same time, but would > this be a concern for user created tokens ? That would fundamentally break the import script in which many tokens are being created by the same user rapidly. In a phone call with mkosek, we tossed around the idea of framework support for a (preexisting?) control which notifies the client of changes to the operation. This would notify the client that the ipatokenUniqueID changed from "autogenerate" to "86725e75-a307-4c10-9de5-3ce15b963552". This would resolve all ambiguity. Nathaniel From mkosek at redhat.com Mon Sep 22 15:25:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 17:25:27 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <20140922101648.5abe7031@willson.usersys.redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> <20140922101648.5abe7031@willson.usersys.redhat.com> Message-ID: <54203F67.4010809@redhat.com> On 09/22/2014 04:16 PM, Simo Sorce wrote: > On Mon, 22 Sep 2014 15:36:01 +0200 > David Kupka wrote: > >> On 09/18/2014 09:42 PM, Martin Kosek wrote: >>> On 09/18/2014 09:11 PM, Simo Sorce wrote: >>>> On Thu, 18 Sep 2014 14:57:45 -0400 >>>> Rob Crittenden wrote: >>>> >>>>> Martin Kosek wrote: >>>>>> On 09/18/2014 04:06 PM, David Kupka wrote: >>>>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>>>>>>> David Kupka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4421 >>>>>>>> >>>>>>>> You are removing an ACI in this patch. It is always possible it >>>>>>>> is no longer needed. Did you test all the client enrollment >>>>>>>> scenarios? >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI >>>>>>> so it is possible to add krbPrincipalName to host even when >>>>>>> there is already one (or more). And adding one ACI to allow >>>>>>> writing krbCanonicalName to host. But I'm still not really >>>>>>> familiar with ACI so please correct me if I'm wrong. >>>>>>> >>>>>> >>>>>> What refers to is probably the update in ACI.txt - the ACI >>>>>> alternative to API.txt. David updated an ACI, not removed it. >>>>>> >>>>>> On that note, what is the reason for this permission change: >>>>>> >>>>>> - 'ipapermtargetfilter': [ >>>>>> - '(objectclass=ipahost)', >>>>>> - '(!(krbprincipalname=*))', >>>>>> - ], >>>>>> >>>>>> ? >>>>> >>>>> Yes, this is exactly the change I was referring to. Permission >>>>> changes within a plugin now translate automatically to ACI >>>>> changes. Sorry I wasn't clearer. >>>>> >>>>> This ACI gets replaced with a much simpler one and I'm not 100% >>>>> sure it will work with all enrollments: >>>>> >>>>> -aci: (targetattr = "krbprincipalname")(targetfilter = >>>>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >>>>> "permission:System: Add krbPrincipalName to a Host";allow (write) >>>>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >>>>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>>>> >>>>> +aci: (targetattr = "krbprincipalname")(targetfilter = >>>>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >>>>> krbPrincipalName to a Host";allow (write) groupdn = >>>>> "ldap:///cn=System: Add krbPrincipalName to a >>>>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>>>> >>>>> The first one restricts writing the attribute only if it isn't >>>>> already set. The second lets it be changed unconditionally. >>>> >>>> Yeah this is wrong indeed, the point of the ACI is to allow >>>> setting the principal only when it is not already set, which is >>>> the OTP enrollment case. But if krbprincipal is set then this >>>> specific permission should not grant rights to change it. >>>> >>>> At least this was my understanding. >>>> >>>> Simo. >>> >>> Right. It seems to me we should add keep this permission intact and >>> add a new permission allowing adding krbPrincipalName aliases. This >>> would allow writing both krbPrincipalName and krbCanonicalName. >>> >>> Martin >>> >> >> Thank you all for explanation and help. I rewrote the patch so it >> should work as requested now. Also I added tests to reassure the >> behavior is correct. > > > Sorry for not catching this earlier, but should we also add new IPA > MODRDN configuration ? > We currently change krbPrincipalName if the user uid changes. > > However perhaps what we should do is instead to allows aliases only for > service/host principals but not for ipa users, at least for now. Right. But this patch does not allow aliases for users, so we do not do any changes on that side. > Should we also change permissions so that host/service entries > *cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN > configuration so that if a service/host krbprincipalname is changed > then krbcanonicalname is too. Hmm, I think only admin is allowed to rename hosts right now. But you have a good point about the renames though. > Last but not least, and here I regret we may have a BIG issue, I just > realize we use krbprincipalname in the Services DN, if we add > additional values there does it mean we end up with a multivalued RDN ? Oh, this one is a major issue then. It would mean that, yes. But is that a problem? I think DS is OK with just one attribute from multi-valued attribute to be in the DN, right? Though it may become awkward to manipulate in the framework. Another issue, are we handling the services correctly? They contain check for the host existence & given they krbPrincipalName they are also bound to one of the aliases actually. What if somebody creates a service for alias.ipa.server.test and then deletes that alias? We will need to address it too. > That may be a problem, in such case should we rename services to use > krbcanonicalname as the rnd instead ? We can do this in a compatible > manner I think by renaming on the fly old entries if the still use > krbprincipalname and changing our code to start always setting > krbcanonicalname on new entries and set both canmonical and principal > name on every new entry. > > Opinions ? I am a bit afraid of renaming all services, there may be a *lot* of them. However, with new ACIs there should not be a problem having objects with different RDNs. I am thinking host plugin could change RDN to krbCanonicalName when a second krbPrincipalName is added. Hmm, I am thinking there may be too many issues related to this patch to make us consider deferring for now... Martin From simo at redhat.com Mon Sep 22 15:29:11 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 11:29:11 -0400 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <54203AAB.70607@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> <54203AAB.70607@redhat.com> Message-ID: <20140922112911.5b4f13a5@willson.usersys.redhat.com> On Mon, 22 Sep 2014 17:05:15 +0200 Martin Basti wrote: > On 22/09/14 08:53, Martin Kosek wrote: > > On 09/19/2014 06:33 PM, Simo Sorce wrote: > >> On Fri, 19 Sep 2014 17:50:16 +0200 > >> Martin Kosek wrote: > >> > >>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: > >>>> Martin Basti wrote: > >>>>> Hello list, > >>>>> > >>>>> I need to use systemd mask/unmask in ipa service. > >>>>> > >>>>> But as Honza wrote: > >>>>> "IMO masking/unmasking should be part of disabling/enabling a > >>>>> service in systemd. AFAIK in most other init systems when you > >>>>> disable a service, it has the same effect as masking the service > >>>>> in systemd - it will never be started until it is > >>>>> enabled/unmasked again. " > >>>>> > >>>>> So my questions is, should be masking part of disabling service > >>>>> in systemd, to be platform independent? > >>>>> Or should we add mask/unmask methods to > >>>>> ipaplatform.base.services.PlatformService where mask is alias > >>>>> for disable? > >>>>> > >>>>> Martin^2 > >>>>> > >>>> After > >>>> readinghttp://0pointer.de/blog/projects/three-levels-of-off I > >>>> disagree that disabling in SysV is the same as masking in > >>>> systemd, though I guess it depends on the meaning of disable. > >>>> According to that page chkconfig off is equivalent to > >>>> systemctl disable .service, which is what we do now > >>>> AFAIR. > >>>> > >>>> Why do you need to mask a service, e.g. render it completely > >>>> unstartable? > >>>> > >>>> rob > >>> I do not have full context, but looks like a good question. We > >>> only enable ipa "service" and starts via ipactl all other > >>> services. So we can disable/enable/mask services on the LDAP > >>> level, not on systemd level. > >> I do not think masking is right for now, however I'd like to chime > >> in given there is work around this. > >> > >> The current ipactl method was necessary due to issues in using > >> systemd fully, however if newer systemds have bugs about > >> enabling/disabling unit files from another one fixed then we > >> should look into making the ipa.service use ipactl *only* to > >> enable/disable unit files. This way if we can create the various > >> unit files as eg: ipa-httpd.service where the only thing we do is > >> add an After: ipa.service and then include the system's > >> httpd.service file we will be in a better situation. > >> Especially on shutdown, as no matter what changed in LDAP on > >> shutdown we do not even lookup anything and just let systemd tear > >> down all services in the ipa group (I guess there is a way to tell > >> systemd that if ipa.service goes down all it's dependent services > >> also need to go down. > >> > >> I know this is a major refactoring, but if we can pull it off, > >> this is the correct way to go with systemd integration in the > >> longer term. > >> > >> Simo. > >> > > Probably yes, I already had a discussion with systemd folks about a > > native systemd way to manage the services. I filed a ticket: > > > > https://fedorahosted.org/freeipa/ticket/4552 > > > > This shouldn't stop these patches though, especially if they are > > required for the DNSSEC feature. > > > > Martin > > Back to my question. > > Should we use the mask as systemd specific and use it in disable, or > create the mask method in platform module? > > IMHO, IPA is mainly used on systemd platforms, so we could add mask > method, which can be used as alias for disabling on other systems. I do not understand why you would mask something, why isn't it sufficient to disable a service ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Sep 22 15:36:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 17:36:01 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <20140922112911.5b4f13a5@willson.usersys.redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> <54203AAB.70607@redhat.com> <20140922112911.5b4f13a5@willson.usersys.redhat.com> Message-ID: <542041E1.4080208@redhat.com> On 22/09/14 17:29, Simo Sorce wrote: > On Mon, 22 Sep 2014 17:05:15 +0200 > Martin Basti wrote: > >> On 22/09/14 08:53, Martin Kosek wrote: >>> On 09/19/2014 06:33 PM, Simo Sorce wrote: >>>> On Fri, 19 Sep 2014 17:50:16 +0200 >>>> Martin Kosek wrote: >>>> >>>>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>>>>> Martin Basti wrote: >>>>>>> Hello list, >>>>>>> >>>>>>> I need to use systemd mask/unmask in ipa service. >>>>>>> >>>>>>> But as Honza wrote: >>>>>>> "IMO masking/unmasking should be part of disabling/enabling a >>>>>>> service in systemd. AFAIK in most other init systems when you >>>>>>> disable a service, it has the same effect as masking the service >>>>>>> in systemd - it will never be started until it is >>>>>>> enabled/unmasked again. " >>>>>>> >>>>>>> So my questions is, should be masking part of disabling service >>>>>>> in systemd, to be platform independent? >>>>>>> Or should we add mask/unmask methods to >>>>>>> ipaplatform.base.services.PlatformService where mask is alias >>>>>>> for disable? >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> After >>>>>> readinghttp://0pointer.de/blog/projects/three-levels-of-off I >>>>>> disagree that disabling in SysV is the same as masking in >>>>>> systemd, though I guess it depends on the meaning of disable. >>>>>> According to that page chkconfig off is equivalent to >>>>>> systemctl disable .service, which is what we do now >>>>>> AFAIR. >>>>>> >>>>>> Why do you need to mask a service, e.g. render it completely >>>>>> unstartable? >>>>>> >>>>>> rob >>>>> I do not have full context, but looks like a good question. We >>>>> only enable ipa "service" and starts via ipactl all other >>>>> services. So we can disable/enable/mask services on the LDAP >>>>> level, not on systemd level. >>>> I do not think masking is right for now, however I'd like to chime >>>> in given there is work around this. >>>> >>>> The current ipactl method was necessary due to issues in using >>>> systemd fully, however if newer systemds have bugs about >>>> enabling/disabling unit files from another one fixed then we >>>> should look into making the ipa.service use ipactl *only* to >>>> enable/disable unit files. This way if we can create the various >>>> unit files as eg: ipa-httpd.service where the only thing we do is >>>> add an After: ipa.service and then include the system's >>>> httpd.service file we will be in a better situation. >>>> Especially on shutdown, as no matter what changed in LDAP on >>>> shutdown we do not even lookup anything and just let systemd tear >>>> down all services in the ipa group (I guess there is a way to tell >>>> systemd that if ipa.service goes down all it's dependent services >>>> also need to go down. >>>> >>>> I know this is a major refactoring, but if we can pull it off, >>>> this is the correct way to go with systemd integration in the >>>> longer term. >>>> >>>> Simo. >>>> >>> Probably yes, I already had a discussion with systemd folks about a >>> native systemd way to manage the services. I filed a ticket: >>> >>> https://fedorahosted.org/freeipa/ticket/4552 >>> >>> This shouldn't stop these patches though, especially if they are >>> required for the DNSSEC feature. >>> >>> Martin >> Back to my question. >> >> Should we use the mask as systemd specific and use it in disable, or >> create the mask method in platform module? >> >> IMHO, IPA is mainly used on systemd platforms, so we could add mask >> method, which can be used as alias for disabling on other systems. > I do not understand why you would mask something, why isn't it > sufficient to disable a service ? > > Simo. > As Petr^2 wrote, user must not run original DNSSEC signer daemon, which is replaced by IPA signer daemon, otherwise it could broke DNSSEC signing. -- Martin Basti From mkosek at redhat.com Mon Sep 22 15:37:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 17:37:14 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <1411244573.3483.6.camel@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> Message-ID: <5420422A.3040600@redhat.com> On 09/20/2014 10:22 PM, Nathaniel McCallum wrote: > On Wed, 2014-09-17 at 12:31 +0200, Martin Kosek wrote: >> On 09/17/2014 08:51 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): >>>> We perform this enforcement at the API level since: >>>> * DS level enforcement would be difficult >>>> * ipatokenUniqueID generation already happens at the API level >>>> >>>> It may be nice in the future to perform enforcement in the DS itself. >>>> However, the question of the location of enforcement is largely an >>>> aesthetic issue. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4456 >>> >>> That's a rather beefy check. I would prefer something like this (untested): >>> >>> group_dn = self.api.Object.group.get_dn(u'admins') >>> filter = ldap.make_filter( >>> {'krbprincipalname': context.principal, 'memberof': group_dn}, >>> ldap.MATCH_ALL) >>> try: >>> ldap.find_entries( >>> base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) >>> except errors.NotFound: >>> raise ValidationError(name='ipatokenuniqueid', >>> error='can only be specified by admins') >>> >>> Honza >>> >> >> Also, do we want to hard code it to admins group only? > > Preferably, no. But I don't have another workable solution. > >> Wouldn't it be more >> flexible to create a new Virtual Operation and let realm admin configure who >> can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1 >> for an example how that's done. > > Modifications are already not permitted. The problem is that we need to > restrict the format of an attribute for only some users on add only. > > Nathaniel Ah, that's a valid point. We need some way to get the modified DN after UUID generation. I discussed this issue briefly with Nathaniel and I had an idea. Doesn't DS have a control for modification to return an updated object after ldapmodify? Then we could trigger it, get the DN and work with that DN in the token plugin. We do not need to make it super general in the framework right now, but we could do at least some minimal version for the token use case. Martin From rcritten at redhat.com Mon Sep 22 15:37:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Sep 2014 11:37:49 -0400 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <20140922112911.5b4f13a5@willson.usersys.redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> <54203AAB.70607@redhat.com> <20140922112911.5b4f13a5@willson.usersys.redhat.com> Message-ID: <5420424D.6070608@redhat.com> Simo Sorce wrote: > On Mon, 22 Sep 2014 17:05:15 +0200 > Martin Basti wrote: > >> On 22/09/14 08:53, Martin Kosek wrote: >>> On 09/19/2014 06:33 PM, Simo Sorce wrote: >>>> On Fri, 19 Sep 2014 17:50:16 +0200 >>>> Martin Kosek wrote: >>>> >>>>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>>>>> Martin Basti wrote: >>>>>>> Hello list, >>>>>>> >>>>>>> I need to use systemd mask/unmask in ipa service. >>>>>>> >>>>>>> But as Honza wrote: >>>>>>> "IMO masking/unmasking should be part of disabling/enabling a >>>>>>> service in systemd. AFAIK in most other init systems when you >>>>>>> disable a service, it has the same effect as masking the service >>>>>>> in systemd - it will never be started until it is >>>>>>> enabled/unmasked again. " >>>>>>> >>>>>>> So my questions is, should be masking part of disabling service >>>>>>> in systemd, to be platform independent? >>>>>>> Or should we add mask/unmask methods to >>>>>>> ipaplatform.base.services.PlatformService where mask is alias >>>>>>> for disable? >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> After >>>>>> readinghttp://0pointer.de/blog/projects/three-levels-of-off I >>>>>> disagree that disabling in SysV is the same as masking in >>>>>> systemd, though I guess it depends on the meaning of disable. >>>>>> According to that page chkconfig off is equivalent to >>>>>> systemctl disable .service, which is what we do now >>>>>> AFAIR. >>>>>> >>>>>> Why do you need to mask a service, e.g. render it completely >>>>>> unstartable? >>>>>> >>>>>> rob >>>>> I do not have full context, but looks like a good question. We >>>>> only enable ipa "service" and starts via ipactl all other >>>>> services. So we can disable/enable/mask services on the LDAP >>>>> level, not on systemd level. >>>> I do not think masking is right for now, however I'd like to chime >>>> in given there is work around this. >>>> >>>> The current ipactl method was necessary due to issues in using >>>> systemd fully, however if newer systemds have bugs about >>>> enabling/disabling unit files from another one fixed then we >>>> should look into making the ipa.service use ipactl *only* to >>>> enable/disable unit files. This way if we can create the various >>>> unit files as eg: ipa-httpd.service where the only thing we do is >>>> add an After: ipa.service and then include the system's >>>> httpd.service file we will be in a better situation. >>>> Especially on shutdown, as no matter what changed in LDAP on >>>> shutdown we do not even lookup anything and just let systemd tear >>>> down all services in the ipa group (I guess there is a way to tell >>>> systemd that if ipa.service goes down all it's dependent services >>>> also need to go down. >>>> >>>> I know this is a major refactoring, but if we can pull it off, >>>> this is the correct way to go with systemd integration in the >>>> longer term. >>>> >>>> Simo. >>>> >>> Probably yes, I already had a discussion with systemd folks about a >>> native systemd way to manage the services. I filed a ticket: >>> >>> https://fedorahosted.org/freeipa/ticket/4552 >>> >>> This shouldn't stop these patches though, especially if they are >>> required for the DNSSEC feature. >>> >>> Martin >> >> Back to my question. >> >> Should we use the mask as systemd specific and use it in disable, or >> create the mask method in platform module? >> >> IMHO, IPA is mainly used on systemd platforms, so we could add mask >> method, which can be used as alias for disabling on other systems. > > I do not understand why you would mask something, why isn't it > sufficient to disable a service ? Think of the case of kadmind with the old KDB. IIRC just starting the service would corrupt the database. Preventing it from starting at all would have been a really nice thing to have. If DNSSEC has similar needs I can see it. I guess the question is, other than DNSSSEC, what is the use case? Typically when we disable something it is during uninstall in which case we should be restoring things to the way they were initially, which probably means not masked (but I didn't check). rob From tbordaz at redhat.com Mon Sep 22 15:42:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 22 Sep 2014 17:42:39 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <5420422A.3040600@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> <5420422A.3040600@redhat.com> Message-ID: <5420436F.90705@redhat.com> On 09/22/2014 05:37 PM, Martin Kosek wrote: > On 09/20/2014 10:22 PM, Nathaniel McCallum wrote: >> On Wed, 2014-09-17 at 12:31 +0200, Martin Kosek wrote: >>> On 09/17/2014 08:51 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a): >>>>> We perform this enforcement at the API level since: >>>>> * DS level enforcement would be difficult >>>>> * ipatokenUniqueID generation already happens at the API level >>>>> >>>>> It may be nice in the future to perform enforcement in the DS itself. >>>>> However, the question of the location of enforcement is largely an >>>>> aesthetic issue. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>> That's a rather beefy check. I would prefer something like this (untested): >>>> >>>> group_dn = self.api.Object.group.get_dn(u'admins') >>>> filter = ldap.make_filter( >>>> {'krbprincipalname': context.principal, 'memberof': group_dn}, >>>> ldap.MATCH_ALL) >>>> try: >>>> ldap.find_entries( >>>> base_dn=self.api.env.basedn, filter=filter, attrs_list=['']) >>>> except errors.NotFound: >>>> raise ValidationError(name='ipatokenuniqueid', >>>> error='can only be specified by admins') >>>> >>>> Honza >>>> >>> Also, do we want to hard code it to admins group only? >> Preferably, no. But I don't have another workable solution. >> >>> Wouldn't it be more >>> flexible to create a new Virtual Operation and let realm admin configure who >>> can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1 >>> for an example how that's done. >> Modifications are already not permitted. The problem is that we need to >> restrict the format of an attribute for only some users on add only. >> >> Nathaniel > Ah, that's a valid point. We need some way to get the modified DN after UUID > generation. > > I discussed this issue briefly with Nathaniel and I had an idea. Doesn't DS > have a control for modification to return an updated object after ldapmodify? Do you mean RFC 4527 (read entry control). Ability to read our writes. thierry > Then we could trigger it, get the DN and work with that DN in the token plugin. > We do not need to make it super general in the framework right now, but we > could do at least some minimal version for the token use case. > > Martin From mbasti at redhat.com Mon Sep 22 15:42:59 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 17:42:59 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <5420424D.6070608@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> <54203AAB.70607@redhat.com> <20140922112911.5b4f13a5@willson.usersys.redhat.com> <5420424D.6070608@redhat.com> Message-ID: <54204383.8080001@redhat.com> On 22/09/14 17:37, Rob Crittenden wrote: > Simo Sorce wrote: >> On Mon, 22 Sep 2014 17:05:15 +0200 >> Martin Basti wrote: >> >>> On 22/09/14 08:53, Martin Kosek wrote: >>>> On 09/19/2014 06:33 PM, Simo Sorce wrote: >>>>> On Fri, 19 Sep 2014 17:50:16 +0200 >>>>> Martin Kosek wrote: >>>>> >>>>>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: >>>>>>> Martin Basti wrote: >>>>>>>> Hello list, >>>>>>>> >>>>>>>> I need to use systemd mask/unmask in ipa service. >>>>>>>> >>>>>>>> But as Honza wrote: >>>>>>>> "IMO masking/unmasking should be part of disabling/enabling a >>>>>>>> service in systemd. AFAIK in most other init systems when you >>>>>>>> disable a service, it has the same effect as masking the service >>>>>>>> in systemd - it will never be started until it is >>>>>>>> enabled/unmasked again. " >>>>>>>> >>>>>>>> So my questions is, should be masking part of disabling service >>>>>>>> in systemd, to be platform independent? >>>>>>>> Or should we add mask/unmask methods to >>>>>>>> ipaplatform.base.services.PlatformService where mask is alias >>>>>>>> for disable? >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>> After >>>>>>> readinghttp://0pointer.de/blog/projects/three-levels-of-off I >>>>>>> disagree that disabling in SysV is the same as masking in >>>>>>> systemd, though I guess it depends on the meaning of disable. >>>>>>> According to that page chkconfig off is equivalent to >>>>>>> systemctl disable .service, which is what we do now >>>>>>> AFAIR. >>>>>>> >>>>>>> Why do you need to mask a service, e.g. render it completely >>>>>>> unstartable? >>>>>>> >>>>>>> rob >>>>>> I do not have full context, but looks like a good question. We >>>>>> only enable ipa "service" and starts via ipactl all other >>>>>> services. So we can disable/enable/mask services on the LDAP >>>>>> level, not on systemd level. >>>>> I do not think masking is right for now, however I'd like to chime >>>>> in given there is work around this. >>>>> >>>>> The current ipactl method was necessary due to issues in using >>>>> systemd fully, however if newer systemds have bugs about >>>>> enabling/disabling unit files from another one fixed then we >>>>> should look into making the ipa.service use ipactl *only* to >>>>> enable/disable unit files. This way if we can create the various >>>>> unit files as eg: ipa-httpd.service where the only thing we do is >>>>> add an After: ipa.service and then include the system's >>>>> httpd.service file we will be in a better situation. >>>>> Especially on shutdown, as no matter what changed in LDAP on >>>>> shutdown we do not even lookup anything and just let systemd tear >>>>> down all services in the ipa group (I guess there is a way to tell >>>>> systemd that if ipa.service goes down all it's dependent services >>>>> also need to go down. >>>>> >>>>> I know this is a major refactoring, but if we can pull it off, >>>>> this is the correct way to go with systemd integration in the >>>>> longer term. >>>>> >>>>> Simo. >>>>> >>>> Probably yes, I already had a discussion with systemd folks about a >>>> native systemd way to manage the services. I filed a ticket: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4552 >>>> >>>> This shouldn't stop these patches though, especially if they are >>>> required for the DNSSEC feature. >>>> >>>> Martin >>> Back to my question. >>> >>> Should we use the mask as systemd specific and use it in disable, or >>> create the mask method in platform module? >>> >>> IMHO, IPA is mainly used on systemd platforms, so we could add mask >>> method, which can be used as alias for disabling on other systems. >> I do not understand why you would mask something, why isn't it >> sufficient to disable a service ? > Think of the case of kadmind with the old KDB. IIRC just starting the > service would corrupt the database. Preventing it from starting at all > would have been a really nice thing to have. If DNSSEC has similar needs > I can see it. > > I guess the question is, other than DNSSSEC, what is the use case? > Typically when we disable something it is during uninstall in which case > we should be restoring things to the way they were initially, which > probably means not masked (but I didn't check). > > rob > Currently during IPA service creation status of affected services is stored, and during uninstall IPA services status of the services is restored. -- Martin Basti From mbasti at redhat.com Mon Sep 22 15:45:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 17:45:55 +0200 Subject: [Freeipa-devel] Krb service delegation rules in CLI Message-ID: <54204433.4010308@redhat.com> Hello, Related ticket: https://fedorahosted.org/freeipa/ticket/3644 1) API The ipaKrb5DelegationACL objectclass requires targets which are stored in extra objectclass. A) we allow users to create groups of principals and then associate them as targets -- user can use same group for multiple delegation ACL B) users specify only list of target principals (no groups) B seems better to me. 2) We should create extra subtree for delegation targets (cn=user_targets,cn=s4u2proxy) to separate targets and rules. Any objections? Martin^2 -- Martin Basti From rmeggins at redhat.com Mon Sep 22 15:45:58 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 22 Sep 2014 09:45:58 -0600 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <1411398871.3483.22.camel@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> <1411398871.3483.22.camel@redhat.com> Message-ID: <54204436.3050602@redhat.com> On 09/22/2014 09:14 AM, Nathaniel McCallum wrote: > On Mon, 2014-09-22 at 10:55 -0400, Simo Sorce wrote: >> On Mon, 22 Sep 2014 10:02:01 -0400 >> Nathaniel McCallum wrote: >> >>> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: >>>> On Mon, 22 Sep 2014 10:34:54 +0200 >>>> Martin Kosek wrote: >>>> >>>>> On 09/22/2014 09:33 AM, thierry bordaz wrote: >>>>>> Hello Nathaniel, >>>>>> >>>>>> Just a remark, in is_token if the entry is >>>>>> objectclass=ipaToken it returns without freeing the >>>>>> 'objectclass' char array. >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> >>>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: >>>>>>> Users that can rename the token (such as admins) can also >>>>>>> create non-UUID token names. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>> >>>>>>> NOTE: this patch is an alternate approach to my patch 0065. >>>>>>> This version has two main advantages compared to 0065: >>>>>>> 1. Permissions are more flexible (not tied to the admin group). >>>>>>> 2. Enforcement occurs at the DS-level >>>>>>> >>>>>>> It should also be noted that this patch does not enforce UUID >>>>>>> randomness, only syntax. Users can still specify a token ID so >>>>>>> long as it is in UUID format. >>>>>>> >>>>>>> Nathaniel >>>>> I am still thinking we may be overcomplicating it. Why cannot we >>>>> use the similar UUID generation mechanism as we do for SUDO >>>>> commands for example: >>>>> >>>>> # ipa sudocmd-add barbar --all --raw >>>>> --------------------------- >>>>> Added Sudo Command "barbar" >>>>> --------------------------- >>>>> dn: >>>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test >>>>> sudocmd: barbar >>>>> ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 >>>>> objectClass: ipasudocmd >>>>> objectClass: ipaobject >>>>> >>>>> It lets DS generate&rename the object's DN when it finds out that >>>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We >>>>> could let DS generate the UUID and only add the "autogenerate" >>>>> keyword in otptoken-add command. >>>>> >>>>> For authorization, we can simply allow users to only add tokens >>>>> with "autogenerate" ID, see my example here: >>>>> >>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html >>>>> >>>>> Admin's or special privilege-owners would have more generous ACI >>>>> allowing other values than just "autogenerate". >>>>> >>>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler >>>>> and we would not need a special DS plugin (unless we want regular >>>>> users to generate their own UUIDs instead of letting IPA DS to >>>>> generate it >>>>> - which I do not think is the case). >>>> Good point Martin. >>> This is the avenue I first pursued. The problem is that the client has >>> no way to look up the DN after the entry is added. In the case of >>> sudocmd-add, the lookup is performed using the sudocmd attribute (see >>> sudocmd.get_dn()). We have no similar attribute in this case and the >>> lookup cannot be performed. >> Well in theory we could search with creatorName and createTimestamp set >> to the user's own DN and a range a few seconds in the past ... >> It is not robust if you add multiple tokens at the same time, but would >> this be a concern for user created tokens ? > That would fundamentally break the import script in which many tokens > are being created by the same user rapidly. > > In a phone call with mkosek, we tossed around the idea of framework > support for a (preexisting?) control which notifies the client of > changes to the operation. This would notify the client that the > ipatokenUniqueID changed from "autogenerate" to > "86725e75-a307-4c10-9de5-3ce15b963552". This would resolve all > ambiguity. What about the POST READ control? The purpose of this control is to return the contents of the entry (e.g. what would be returned by an LDAP search request) after the update has been applied. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Mon Sep 22 16:23:49 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 12:23:49 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <1411398871.3483.22.camel@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> <1411398871.3483.22.camel@redhat.com> Message-ID: <20140922122349.23b90d12@willson.usersys.redhat.com> On Mon, 22 Sep 2014 11:14:31 -0400 Nathaniel McCallum wrote: > On Mon, 2014-09-22 at 10:55 -0400, Simo Sorce wrote: > > On Mon, 22 Sep 2014 10:02:01 -0400 > > Nathaniel McCallum wrote: > > > > > On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: > > > > On Mon, 22 Sep 2014 10:34:54 +0200 > > > > Martin Kosek wrote: > > > > > > > > > On 09/22/2014 09:33 AM, thierry bordaz wrote: > > > > > > Hello Nathaniel, > > > > > > > > > > > > Just a remark, in is_token if the entry is > > > > > > objectclass=ipaToken it returns without freeing the > > > > > > 'objectclass' char array. > > > > > > > > > > > > thanks > > > > > > thierry > > > > > > > > > > > > On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > > > > > >> Users that can rename the token (such as admins) can also > > > > > >> create non-UUID token names. > > > > > >> > > > > > >> https://fedorahosted.org/freeipa/ticket/4456 > > > > > >> > > > > > >> NOTE: this patch is an alternate approach to my patch 0065. > > > > > >> This version has two main advantages compared to 0065: > > > > > >> 1. Permissions are more flexible (not tied to the admin > > > > > >> group). 2. Enforcement occurs at the DS-level > > > > > >> > > > > > >> It should also be noted that this patch does not enforce > > > > > >> UUID randomness, only syntax. Users can still specify a > > > > > >> token ID so long as it is in UUID format. > > > > > >> > > > > > >> Nathaniel > > > > > > > > > > I am still thinking we may be overcomplicating it. Why cannot > > > > > we use the similar UUID generation mechanism as we do for SUDO > > > > > commands for example: > > > > > > > > > > # ipa sudocmd-add barbar --all --raw > > > > > --------------------------- > > > > > Added Sudo Command "barbar" > > > > > --------------------------- > > > > > dn: > > > > > ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > > > > > sudocmd: barbar > > > > > ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > > > > > objectClass: ipasudocmd > > > > > objectClass: ipaobject > > > > > > > > > > It lets DS generate&rename the object's DN when it finds out > > > > > that the ipaUniqueID is set to "autogenerate" (in > > > > > baseldap.py). We could let DS generate the UUID and only add > > > > > the "autogenerate" keyword in otptoken-add command. > > > > > > > > > > For authorization, we can simply allow users to only add > > > > > tokens with "autogenerate" ID, see my example here: > > > > > > > > > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > > > > > > > > > > Admin's or special privilege-owners would have more generous > > > > > ACI allowing other values than just "autogenerate". > > > > > > > > > > IMO, then the whole ipatoken-add mechanism would be a lot > > > > > simpler and we would not need a special DS plugin (unless we > > > > > want regular users to generate their own UUIDs instead of > > > > > letting IPA DS to generate it > > > > > - which I do not think is the case). > > > > > > > > Good point Martin. > > > > > > This is the avenue I first pursued. The problem is that the > > > client has no way to look up the DN after the entry is added. In > > > the case of sudocmd-add, the lookup is performed using the > > > sudocmd attribute (see sudocmd.get_dn()). We have no similar > > > attribute in this case and the lookup cannot be performed. > > > > Well in theory we could search with creatorName and createTimestamp > > set to the user's own DN and a range a few seconds in the past ... > > It is not robust if you add multiple tokens at the same time, but > > would this be a concern for user created tokens ? > > That would fundamentally break the import script in which many tokens > are being created by the same user rapidly. But why would you need this in the script ? > In a phone call with mkosek, we tossed around the idea of framework > support for a (preexisting?) control which notifies the client of > changes to the operation. This would notify the client that the > ipatokenUniqueID changed from "autogenerate" to > "86725e75-a307-4c10-9de5-3ce15b963552". This would resolve all > ambiguity. Notifications can be obtained via syncrepl, but that's not a control, it is a full search and wait mechanism, A little too heavy weight for this use IMO. We could add a control that will return you a DN in the operation result though. IT would be relatively simnple to add one, and would be a generic feature useful in all these cases (including sudo as it would allow us to avoid the search, or at least make it a base search which is faster). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Sep 22 16:52:28 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 12:52:28 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <54203F67.4010809@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> <20140922101648.5abe7031@willson.usersys.redhat.com> <54203F67.4010809@redhat.com> Message-ID: <20140922125228.533644b9@willson.usersys.redhat.com> On Mon, 22 Sep 2014 17:25:27 +0200 Martin Kosek wrote: > On 09/22/2014 04:16 PM, Simo Sorce wrote: > > On Mon, 22 Sep 2014 15:36:01 +0200 > > David Kupka wrote: > > > >> On 09/18/2014 09:42 PM, Martin Kosek wrote: > >>> On 09/18/2014 09:11 PM, Simo Sorce wrote: > >>>> On Thu, 18 Sep 2014 14:57:45 -0400 > >>>> Rob Crittenden wrote: > >>>> > >>>>> Martin Kosek wrote: > >>>>>> On 09/18/2014 04:06 PM, David Kupka wrote: > >>>>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >>>>>>>> David Kupka wrote: > >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4421 > >>>>>>>> > >>>>>>>> You are removing an ACI in this patch. It is always possible > >>>>>>>> it is no longer needed. Did you test all the client > >>>>>>>> enrollment scenarios? > >>>>>>>> > >>>>>>>> rob > >>>>>>>> > >>>>>>> > >>>>>>> As far as I'm aware I'm not removing any ACI. I'm modifying > >>>>>>> ACI so it is possible to add krbPrincipalName to host even > >>>>>>> when there is already one (or more). And adding one ACI to > >>>>>>> allow writing krbCanonicalName to host. But I'm still not > >>>>>>> really familiar with ACI so please correct me if I'm wrong. > >>>>>>> > >>>>>> > >>>>>> What refers to is probably the update in ACI.txt - the ACI > >>>>>> alternative to API.txt. David updated an ACI, not removed it. > >>>>>> > >>>>>> On that note, what is the reason for this permission change: > >>>>>> > >>>>>> - 'ipapermtargetfilter': [ > >>>>>> - '(objectclass=ipahost)', > >>>>>> - '(!(krbprincipalname=*))', > >>>>>> - ], > >>>>>> > >>>>>> ? > >>>>> > >>>>> Yes, this is exactly the change I was referring to. Permission > >>>>> changes within a plugin now translate automatically to ACI > >>>>> changes. Sorry I wasn't clearer. > >>>>> > >>>>> This ACI gets replaced with a much simpler one and I'm not 100% > >>>>> sure it will work with all enrollments: > >>>>> > >>>>> -aci: (targetattr = "krbprincipalname")(targetfilter = > >>>>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version > >>>>> 3.0;acl "permission:System: Add krbPrincipalName to a > >>>>> Host";allow (write) groupdn = "ldap:///cn=System: Add > >>>>> krbPrincipalName to a > >>>>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>>>> > >>>>> +aci: (targetattr = "krbprincipalname")(targetfilter = > >>>>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add > >>>>> krbPrincipalName to a Host";allow (write) groupdn = > >>>>> "ldap:///cn=System: Add krbPrincipalName to a > >>>>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>>>> > >>>>> The first one restricts writing the attribute only if it isn't > >>>>> already set. The second lets it be changed unconditionally. > >>>> > >>>> Yeah this is wrong indeed, the point of the ACI is to allow > >>>> setting the principal only when it is not already set, which is > >>>> the OTP enrollment case. But if krbprincipal is set then this > >>>> specific permission should not grant rights to change it. > >>>> > >>>> At least this was my understanding. > >>>> > >>>> Simo. > >>> > >>> Right. It seems to me we should add keep this permission intact > >>> and add a new permission allowing adding krbPrincipalName > >>> aliases. This would allow writing both krbPrincipalName and > >>> krbCanonicalName. > >>> > >>> Martin > >>> > >> > >> Thank you all for explanation and help. I rewrote the patch so it > >> should work as requested now. Also I added tests to reassure the > >> behavior is correct. > > > > > > Sorry for not catching this earlier, but should we also add new IPA > > MODRDN configuration ? > > We currently change krbPrincipalName if the user uid changes. > > > > However perhaps what we should do is instead to allows aliases only > > for service/host principals but not for ipa users, at least for now. > > Right. But this patch does not allow aliases for users, so we do not > do any changes on that side. > > > Should we also change permissions so that host/service entries > > *cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN > > configuration so that if a service/host krbprincipalname is changed > > then krbcanonicalname is too. > > Hmm, I think only admin is allowed to rename hosts right now. But you > have a good point about the renames though. > > > Last but not least, and here I regret we may have a BIG issue, I > > just realize we use krbprincipalname in the Services DN, if we add > > additional values there does it mean we end up with a multivalued > > RDN ? > > Oh, this one is a major issue then. It would mean that, yes. But is > that a problem? I think DS is OK with just one attribute from > multi-valued attribute to be in the DN, right? Though it may become > awkward to manipulate in the framework. > > Another issue, are we handling the services correctly? They contain > check for the host existence & given they krbPrincipalName they are > also bound to one of the aliases actually. What if somebody creates a > service for alias.ipa.server.test and then deletes that alias? We > will need to address it too. > > > That may be a problem, in such case should we rename services to use > > krbcanonicalname as the rnd instead ? We can do this in a compatible > > manner I think by renaming on the fly old entries if the still use > > krbprincipalname and changing our code to start always setting > > krbcanonicalname on new entries and set both canmonical and > > principal name on every new entry. > > > > Opinions ? > > I am a bit afraid of renaming all services, there may be a *lot* of > them. However, with new ACIs there should not be a problem having > objects with different RDNs. > > I am thinking host plugin could change RDN to krbCanonicalName when a > second krbPrincipalName is added. This is what I was proposing, renaming existing ones only if they are "touched". > Hmm, I am thinking there may be too many issues related to this patch > to make us consider deferring for now... The only issue seem to be the change to krbCanonicalNAme, but of course this will take time, this patch should not hold a release, though we are getting closer, we shouldn't just defer it forever. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Sep 22 16:55:13 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 12:55:13 -0400 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <542041E1.4080208@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541C50B8.2040901@redhat.com> <20140919123351.5a841ef5@willson.usersys.redhat.com> <541FC75E.4060304@redhat.com> <54203AAB.70607@redhat.com> <20140922112911.5b4f13a5@willson.usersys.redhat.com> <542041E1.4080208@redhat.com> Message-ID: <20140922125513.5b1aca57@willson.usersys.redhat.com> On Mon, 22 Sep 2014 17:36:01 +0200 Martin Basti wrote: > On 22/09/14 17:29, Simo Sorce wrote: > > On Mon, 22 Sep 2014 17:05:15 +0200 > > Martin Basti wrote: > > > >> On 22/09/14 08:53, Martin Kosek wrote: > >>> On 09/19/2014 06:33 PM, Simo Sorce wrote: > >>>> On Fri, 19 Sep 2014 17:50:16 +0200 > >>>> Martin Kosek wrote: > >>>> > >>>>> On 09/19/2014 05:23 PM, Rob Crittenden wrote: > >>>>>> Martin Basti wrote: > >>>>>>> Hello list, > >>>>>>> > >>>>>>> I need to use systemd mask/unmask in ipa service. > >>>>>>> > >>>>>>> But as Honza wrote: > >>>>>>> "IMO masking/unmasking should be part of disabling/enabling a > >>>>>>> service in systemd. AFAIK in most other init systems when you > >>>>>>> disable a service, it has the same effect as masking the > >>>>>>> service in systemd - it will never be started until it is > >>>>>>> enabled/unmasked again. " > >>>>>>> > >>>>>>> So my questions is, should be masking part of disabling > >>>>>>> service in systemd, to be platform independent? > >>>>>>> Or should we add mask/unmask methods to > >>>>>>> ipaplatform.base.services.PlatformService where mask is alias > >>>>>>> for disable? > >>>>>>> > >>>>>>> Martin^2 > >>>>>>> > >>>>>> After > >>>>>> readinghttp://0pointer.de/blog/projects/three-levels-of-off I > >>>>>> disagree that disabling in SysV is the same as masking in > >>>>>> systemd, though I guess it depends on the meaning of disable. > >>>>>> According to that page chkconfig off is equivalent to > >>>>>> systemctl disable .service, which is what we do now > >>>>>> AFAIR. > >>>>>> > >>>>>> Why do you need to mask a service, e.g. render it completely > >>>>>> unstartable? > >>>>>> > >>>>>> rob > >>>>> I do not have full context, but looks like a good question. We > >>>>> only enable ipa "service" and starts via ipactl all other > >>>>> services. So we can disable/enable/mask services on the LDAP > >>>>> level, not on systemd level. > >>>> I do not think masking is right for now, however I'd like to > >>>> chime in given there is work around this. > >>>> > >>>> The current ipactl method was necessary due to issues in using > >>>> systemd fully, however if newer systemds have bugs about > >>>> enabling/disabling unit files from another one fixed then we > >>>> should look into making the ipa.service use ipactl *only* to > >>>> enable/disable unit files. This way if we can create the various > >>>> unit files as eg: ipa-httpd.service where the only thing we do is > >>>> add an After: ipa.service and then include the system's > >>>> httpd.service file we will be in a better situation. > >>>> Especially on shutdown, as no matter what changed in LDAP on > >>>> shutdown we do not even lookup anything and just let systemd tear > >>>> down all services in the ipa group (I guess there is a way to > >>>> tell systemd that if ipa.service goes down all it's dependent > >>>> services also need to go down. > >>>> > >>>> I know this is a major refactoring, but if we can pull it off, > >>>> this is the correct way to go with systemd integration in the > >>>> longer term. > >>>> > >>>> Simo. > >>>> > >>> Probably yes, I already had a discussion with systemd folks about > >>> a native systemd way to manage the services. I filed a ticket: > >>> > >>> https://fedorahosted.org/freeipa/ticket/4552 > >>> > >>> This shouldn't stop these patches though, especially if they are > >>> required for the DNSSEC feature. > >>> > >>> Martin > >> Back to my question. > >> > >> Should we use the mask as systemd specific and use it in disable, > >> or create the mask method in platform module? > >> > >> IMHO, IPA is mainly used on systemd platforms, so we could add mask > >> method, which can be used as alias for disabling on other systems. > > I do not understand why you would mask something, why isn't it > > sufficient to disable a service ? > > > > Simo. > > > As Petr^2 wrote, user must not run original DNSSEC signer daemon, > which is replaced by IPA signer daemon, otherwise it could broke > DNSSEC signing. Ok I completely misunderstood the environment then. Yes if we have a custom unit file for DNSSEC we should definitely mask the original one. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Sep 22 16:58:58 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 12:58:58 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <5420436F.90705@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> <5420422A.3040600@redhat.com> <5420436F.90705@redhat.com> Message-ID: <20140922125858.6008906f@willson.usersys.redhat.com> On Mon, 22 Sep 2014 17:42:39 +0200 thierry bordaz wrote: > RFC 4527 Thanks a lot Thierry, this is exactly the control I had in mind last week. If we could implement it then we could solve any issue where the RDN needs to be modified by the ADD operation. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Sep 22 17:18:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 19:18:55 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121, 0123-0125] DNS: allow to add root zone '.' In-Reply-To: <541C1985.9070802@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> <541C12BB.6000901@redhat.com> <541C1985.9070802@redhat.com> Message-ID: <542059FF.2050503@redhat.com> On 19/09/14 13:54, Martin Kosek wrote: > I did not review, just found something that hit me in the eyes: > > > On 09/19/2014 01:25 PM, Martin Basti wrote: >> +class OptionDeprecatedWarning(PublicMessage): >> + """ >> + **13004** Used when user uses a deprecated option >> + """ >> + >> + errno = 13004 >> + type = "warning" >> + format = _(u"'%(option)s' option is deprecated. >> %(additional_info)s") >> + >> + >> +class OptionNameServerWarning(PublicMessage): >> + """ >> + **13005** Used when user uses a dnszone-add/mod --name-server >> option >> + """ >> + >> + errno = 13005 >> + type = "warning" >> + format = _(u"'--name-server' is used only for setting up the SOA >> MNAME attribute.\n" >> + u"To edit NS record(s) in zone apex, use command >> 'dnsrecord-mod [zone] @ --ns-rec=nameserver'.") > > > OptionNameServerWarning has a nice generic name, but the format is not > that generic, compared to OptionDeprecatedWarning. I think we should > follow the approach as in OptionDeprecatedWarning so that the warning > can be reused. > > This is not urgent though, you can wait with the fix until Petr2 or > somebody else sends you other notes... > > Martin Updated patchset attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114.3-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.3-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120.3-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 12753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121.3-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0123.3-DNS-autofill-admin-email.patch Type: text/x-patch Size: 7403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0124.3-WebUI-DNS-Remove-ip-address-admin-email-options.patch Type: text/x-patch Size: 3281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0125.3-DNS-tests-tests-update-to-due-to-change-in-options.patch Type: text/x-patch Size: 62061 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 22 17:21:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 19:21:12 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <54200559.6060604@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> Message-ID: <54205A88.8050207@redhat.com> On 22/09/14 13:17, Petr Vobornik wrote: > On 19.9.2014 16:15, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >> Patch attached. >> > > Patch 126: > > 1. I think that just > DeprecatedParam('dnsclass?'), > > should be enough. > > Also > > 2. You forgot to update API.txt and VERSION > > Patch 127: > ACK > Updated patchset attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0126.2-DNS-remove-class-option.patch Type: text/x-patch Size: 10208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0127.2-WebUI-DNS-remove-class-option.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 22 17:24:32 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 19:24:32 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <54200559.6060604@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> Message-ID: <54205B50.4090702@redhat.com> On 22/09/14 13:17, Petr Vobornik wrote: > On 19.9.2014 16:15, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >> Patch attached. >> > > Patch 126: > > 1. I think that just > DeprecatedParam('dnsclass?'), > > should be enough. Sorry I forgot to reply, I was getting error without removing "values" option > > Also > > 2. You forgot to update API.txt and VERSION > > Patch 127: > ACK > -- Martin Basti From mbasti at redhat.com Mon Sep 22 17:30:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Sep 2014 19:30:17 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <541C25CB.8060801@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> <541C14A4.2010907@redhat.com> <541C25CB.8060801@redhat.com> Message-ID: <54205CA9.8000708@redhat.com> On 19/09/14 14:47, Jan Cholasta wrote: > Dne 19.9.2014 v 13:33 Martin Basti napsal(a): >> On 02/09/14 11:59, Martin Basti wrote: >>> On 02/09/14 09:10, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>>>> This patch allows to disable service in LDAP to prevents service >>>>> to be >>>>> started by "ipactl restart" >>>>> >>>>> Required by DNSSEC >>>>> >>>>> Patch attached >>>> >>>> I don't think the extra argument in ldap_enable is necessary. It >>>> should enable the service no matter if the entry existed before or >>>> not. >>>> >>>> Similarly, in ldap_disable you should not raise an error when the >>>> entry is not found, because that already makes the service disabled. >>>> >>>> Honza >>>> >>> Updated patch attached >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Please review, this should be in 4.1 >> >> -- >> Martin Basti > > 1) ipaConfigString is case-insensitive, so you need to look for the > string "enabledService" in a case-insensitive way. > > > 2) Don't say "failed to enable ..." when the service is already > enabled. It is not a failure. Same for disabled. > > > 3) Missing ipaConfigString is nothing to warn about. > > > 4) You should log success in both ldap_enable/ldap_disable. > > > 5) The except below update_entry should say "except errors.EmptyModlist". > > Thank you, updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0118.3-LDAP-disable-service.patch Type: text/x-patch Size: 3505 bytes Desc: not available URL: From simo at redhat.com Mon Sep 22 17:48:03 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 13:48:03 -0400 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <20140922125858.6008906f@willson.usersys.redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> <5420422A.3040600@redhat.com> <5420436F.90705@redhat.com> <20140922125858.6008906f@willson.usersys.redhat.com> Message-ID: <20140922134803.6961dabb@willson.usersys.redhat.com> On Mon, 22 Sep 2014 12:58:58 -0400 Simo Sorce wrote: > On Mon, 22 Sep 2014 17:42:39 +0200 > thierry bordaz wrote: > > > RFC 4527 > > Thanks a lot Thierry, this is exactly the control I had in mind last > week. If we could implement it then we could solve any issue where the > RDN needs to be modified by the ADD operation. Ha, Rich confirmed on IRC that we do have this control available since DS 1.3.2 Given this I think this is the best solution as it allows us to use a simple ACI and no code to solve the problem. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Sep 22 19:21:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 21:21:04 +0200 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <20140922105544.44ac8885@willson.usersys.redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> Message-ID: <542076A0.3060407@redhat.com> On 09/22/2014 04:55 PM, Simo Sorce wrote: > On Mon, 22 Sep 2014 10:02:01 -0400 > Nathaniel McCallum wrote: > >> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: >>> On Mon, 22 Sep 2014 10:34:54 +0200 >>> Martin Kosek wrote: >>> >>>> On 09/22/2014 09:33 AM, thierry bordaz wrote: >>>>> Hello Nathaniel, >>>>> >>>>> Just a remark, in is_token if the entry is >>>>> objectclass=ipaToken it returns without freeing the >>>>> 'objectclass' char array. >>>>> >>>>> thanks >>>>> thierry >>>>> >>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: >>>>>> Users that can rename the token (such as admins) can also >>>>>> create non-UUID token names. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>> >>>>>> NOTE: this patch is an alternate approach to my patch 0065. >>>>>> This version has two main advantages compared to 0065: >>>>>> 1. Permissions are more flexible (not tied to the admin group). >>>>>> 2. Enforcement occurs at the DS-level >>>>>> >>>>>> It should also be noted that this patch does not enforce UUID >>>>>> randomness, only syntax. Users can still specify a token ID so >>>>>> long as it is in UUID format. >>>>>> >>>>>> Nathaniel >>>> >>>> I am still thinking we may be overcomplicating it. Why cannot we >>>> use the similar UUID generation mechanism as we do for SUDO >>>> commands for example: >>>> >>>> # ipa sudocmd-add barbar --all --raw >>>> --------------------------- >>>> Added Sudo Command "barbar" >>>> --------------------------- >>>> dn: >>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test >>>> sudocmd: barbar >>>> ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 >>>> objectClass: ipasudocmd >>>> objectClass: ipaobject >>>> >>>> It lets DS generate&rename the object's DN when it finds out that >>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We >>>> could let DS generate the UUID and only add the "autogenerate" >>>> keyword in otptoken-add command. >>>> >>>> For authorization, we can simply allow users to only add tokens >>>> with "autogenerate" ID, see my example here: >>>> >>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html >>>> >>>> Admin's or special privilege-owners would have more generous ACI >>>> allowing other values than just "autogenerate". >>>> >>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler >>>> and we would not need a special DS plugin (unless we want regular >>>> users to generate their own UUIDs instead of letting IPA DS to >>>> generate it >>>> - which I do not think is the case). >>> >>> Good point Martin. >> >> This is the avenue I first pursued. The problem is that the client has >> no way to look up the DN after the entry is added. In the case of >> sudocmd-add, the lookup is performed using the sudocmd attribute (see >> sudocmd.get_dn()). We have no similar attribute in this case and the >> lookup cannot be performed. > > Well in theory we could search with creatorName and createTimestamp set > to the user's own DN and a range a few seconds in the past ... > It is not robust if you add multiple tokens at the same time, but would > this be a concern for user created tokens ? > > Simo. Ugh, no offense, but this approach sounds really ugly :-) I will wait for Thierry or Ludwig's assessment, but I still think there is either existing control for the modify operation to return an updated entry or we could create one as you suggest down the thread - as this may be useful for other use cases too. Martin From mkosek at redhat.com Mon Sep 22 19:28:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 21:28:31 +0200 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <20140922125858.6008906f@willson.usersys.redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> <5420422A.3040600@redhat.com> <5420436F.90705@redhat.com> <20140922125858.6008906f@willson.usersys.redhat.com> Message-ID: <5420785F.4070109@redhat.com> On 09/22/2014 06:58 PM, Simo Sorce wrote: > On Mon, 22 Sep 2014 17:42:39 +0200 > thierry bordaz wrote: > >> RFC 4527 > > Thanks a lot Thierry, this is exactly the control I had in mind last > week. If we could implement it then we could solve any issue where the > RDN needs to be modified by the ADD operation. > > Simo. > Ah, so do I understand it correctly that we do not have that control in the DS implemented yet? If this is the case, we should file a DS ticket and do some simple temporary solution in FreeIPA for now. I would personally did not want to go with the custom DS plugin or other complicated route is it takes development time and may be difficult to get rid of it later. Martin From simo at redhat.com Mon Sep 22 19:28:58 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 15:28:58 -0400 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <542076A0.3060407@redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> <542076A0.3060407@redhat.com> Message-ID: <20140922152858.42d186fa@willson.usersys.redhat.com> On Mon, 22 Sep 2014 21:21:04 +0200 Martin Kosek wrote: > On 09/22/2014 04:55 PM, Simo Sorce wrote: > > On Mon, 22 Sep 2014 10:02:01 -0400 > > Nathaniel McCallum wrote: > > > >> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: > >>> On Mon, 22 Sep 2014 10:34:54 +0200 > >>> Martin Kosek wrote: > >>> > >>>> On 09/22/2014 09:33 AM, thierry bordaz wrote: > >>>>> Hello Nathaniel, > >>>>> > >>>>> Just a remark, in is_token if the entry is > >>>>> objectclass=ipaToken it returns without freeing the > >>>>> 'objectclass' char array. > >>>>> > >>>>> thanks > >>>>> thierry > >>>>> > >>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: > >>>>>> Users that can rename the token (such as admins) can also > >>>>>> create non-UUID token names. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4456 > >>>>>> > >>>>>> NOTE: this patch is an alternate approach to my patch 0065. > >>>>>> This version has two main advantages compared to 0065: > >>>>>> 1. Permissions are more flexible (not tied to the admin group). > >>>>>> 2. Enforcement occurs at the DS-level > >>>>>> > >>>>>> It should also be noted that this patch does not enforce UUID > >>>>>> randomness, only syntax. Users can still specify a token ID so > >>>>>> long as it is in UUID format. > >>>>>> > >>>>>> Nathaniel > >>>> > >>>> I am still thinking we may be overcomplicating it. Why cannot we > >>>> use the similar UUID generation mechanism as we do for SUDO > >>>> commands for example: > >>>> > >>>> # ipa sudocmd-add barbar --all --raw > >>>> --------------------------- > >>>> Added Sudo Command "barbar" > >>>> --------------------------- > >>>> dn: > >>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test > >>>> sudocmd: barbar > >>>> ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 > >>>> objectClass: ipasudocmd > >>>> objectClass: ipaobject > >>>> > >>>> It lets DS generate&rename the object's DN when it finds out that > >>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We > >>>> could let DS generate the UUID and only add the "autogenerate" > >>>> keyword in otptoken-add command. > >>>> > >>>> For authorization, we can simply allow users to only add tokens > >>>> with "autogenerate" ID, see my example here: > >>>> > >>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html > >>>> > >>>> Admin's or special privilege-owners would have more generous ACI > >>>> allowing other values than just "autogenerate". > >>>> > >>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler > >>>> and we would not need a special DS plugin (unless we want regular > >>>> users to generate their own UUIDs instead of letting IPA DS to > >>>> generate it > >>>> - which I do not think is the case). > >>> > >>> Good point Martin. > >> > >> This is the avenue I first pursued. The problem is that the client > >> has no way to look up the DN after the entry is added. In the case > >> of sudocmd-add, the lookup is performed using the sudocmd > >> attribute (see sudocmd.get_dn()). We have no similar attribute in > >> this case and the lookup cannot be performed. > > > > Well in theory we could search with creatorName and createTimestamp > > set to the user's own DN and a range a few seconds in the past ... > > It is not robust if you add multiple tokens at the same time, but > > would this be a concern for user created tokens ? > > > > Simo. > > Ugh, no offense, but this approach sounds really ugly :-) I will wait > for Thierry or Ludwig's assessment, but I still think there is either > existing control for the modify operation to return an updated entry > or we could create one as you suggest down the thread - as this may > be useful for other use cases too. See following mails, the right approach is to use the POST READ control. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Sep 22 19:48:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Sep 2014 22:48:55 +0300 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <54204433.4010308@redhat.com> References: <54204433.4010308@redhat.com> Message-ID: <20140922194855.GB11503@redhat.com> On Mon, 22 Sep 2014, Martin Basti wrote: >Hello, > >Related ticket: https://fedorahosted.org/freeipa/ticket/3644 > > >1) API > >The ipaKrb5DelegationACL objectclass requires targets which are stored >in extra objectclass. > >A) we allow users to create groups of principals and then associate >them as targets -- user can use same group for multiple delegation ACL > >B) users specify only list of target principals (no groups) > >B seems better to me. No. You have three clearly separate object types here: 1. Principals -- any object in the tree that has krbPrincipalAux supplemental auxiliary object class. These objects can be anywhere in the tree, we can decide on limiting subtrees to search. 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL supplemental structural object class. These objects can be anywhere under cn=s4u2proxy,$SUFFIX 3. Groups of principals -- any object that has groupOfPrincipals _and_ doesn't have ipaKrb5DelegationACL object classes. These objects can be anywhere in the tree, we can decide on limiting subtrees to search and can decide on a specific subtree to put new groups of principals. For (1) you just need to be able to reference principals, this only requires a search filter to define DN of the principal based on krbPrincipalName or krbCanonicalName, with support for 'shortcuts' (specifying principal without realm which is our realm). (1) is only used to resolve principals for (2) and (3). For (2) you need to implement a proper object handling, like any other IPA object that supports: -- multiple values for ipaAllowToImpersonate -- multiple values for ipaAllowedTarget CLI would look something like this: ipa krbdelegation-add -show -find -mod -add-source -add-target -del-source -del-target -del For (3) you need to implement a proper object handling where creating the object would happen in the predefined subtree but search or modify would be possible for any object matched by a proper filter. CLI would look something like this: ipa krbprincipalgroup-add -show -find -mod -add-member -del-member The way we use right now groupOfPrincipals, the objects referenced are placed in different subtrees, according to their primary role. That's right, as krbPrincipalAux is an auxiliary class, and is added on top of other object classes to turn other objects into principals. We also use groupOfPrincipals not only for Kerberos delegation ACLs, that's why support for multiple subtrees is needed. Creating new groupOfPrincipals objects can be allowed in a single designated place, cn=s4u2proxy,$SUFFIX, because this is primary use of this API. -- / Alexander Bokovoy From rmeggins at redhat.com Mon Sep 22 19:57:03 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 22 Sep 2014 13:57:03 -0600 Subject: [Freeipa-devel] [PATCH 0065] Don't allow users to create tokens with a specified ID In-Reply-To: <5420785F.4070109@redhat.com> References: <1410888743.3889.15.camel@redhat.com> <54192F5D.7020208@redhat.com> <54196306.3020805@redhat.com> <1411244573.3483.6.camel@redhat.com> <5420422A.3040600@redhat.com> <5420436F.90705@redhat.com> <20140922125858.6008906f@willson.usersys.redhat.com> <5420785F.4070109@redhat.com> Message-ID: <54207F0F.8040101@redhat.com> On 09/22/2014 01:28 PM, Martin Kosek wrote: > On 09/22/2014 06:58 PM, Simo Sorce wrote: >> On Mon, 22 Sep 2014 17:42:39 +0200 >> thierry bordaz wrote: >> >>> RFC 4527 >> >> Thanks a lot Thierry, this is exactly the control I had in mind last >> week. If we could implement it then we could solve any issue where the >> RDN needs to be modified by the ADD operation. >> >> Simo. >> > > Ah, so do I understand it correctly that we do not have that control > in the DS implemented yet? It was implemented in 1.3.2, which means Fedora 20 and later. > If this is the case, we should file a DS ticket and do some simple > temporary solution in FreeIPA for now. > > I would personally did not want to go with the custom DS plugin or > other complicated route is it takes development time and may be > difficult to get rid of it later. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Mon Sep 22 21:59:18 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 17:59:18 -0400 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <54204433.4010308@redhat.com> References: <54204433.4010308@redhat.com> Message-ID: <20140922175918.71cf6d25@willson.usersys.redhat.com> On Mon, 22 Sep 2014 17:45:55 +0200 Martin Basti wrote: > Hello, > > Related ticket: https://fedorahosted.org/freeipa/ticket/3644 > > > 1) API > > The ipaKrb5DelegationACL objectclass requires targets which are > stored in extra objectclass. > > A) we allow users to create groups of principals and then associate > them as targets -- user can use same group for multiple delegation ACL > > B) users specify only list of target principals (no groups) > > B seems better to me. Why would you want to limit reusability of target groups ? I think it will be rather common to allow multiple services to be allowed to target the same group of services (like LDAP servers). > 2) > We should create extra subtree for delegation targets > (cn=user_targets,cn=s4u2proxy) to separate targets and rules. > > Any objections? I am not against a subtree for convenience, it should just be called cn=targets or cn=delegation-targets though, the targets are never users so user_targets doesn't make much sense. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Sep 23 06:59:35 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 23 Sep 2014 08:59:35 +0200 Subject: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs In-Reply-To: <20140922152858.42d186fa@willson.usersys.redhat.com> References: <1411326447.3483.8.camel@redhat.com> <541FD0C0.7000703@redhat.com> <541FDF2E.909@redhat.com> <20140922095013.3c71bafd@willson.usersys.redhat.com> <1411394521.3483.20.camel@redhat.com> <20140922105544.44ac8885@willson.usersys.redhat.com> <542076A0.3060407@redhat.com> <20140922152858.42d186fa@willson.usersys.redhat.com> Message-ID: <54211A57.8040002@redhat.com> On 09/22/2014 09:28 PM, Simo Sorce wrote: > On Mon, 22 Sep 2014 21:21:04 +0200 > Martin Kosek wrote: > >> On 09/22/2014 04:55 PM, Simo Sorce wrote: >>> On Mon, 22 Sep 2014 10:02:01 -0400 >>> Nathaniel McCallum wrote: >>> >>>> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: >>>>> On Mon, 22 Sep 2014 10:34:54 +0200 >>>>> Martin Kosek wrote: >>>>> >>>>>> On 09/22/2014 09:33 AM, thierry bordaz wrote: >>>>>>> Hello Nathaniel, >>>>>>> >>>>>>> Just a remark, in is_token if the entry is >>>>>>> objectclass=ipaToken it returns without freeing the >>>>>>> 'objectclass' char array. >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>>> >>>>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote: >>>>>>>> Users that can rename the token (such as admins) can also >>>>>>>> create non-UUID token names. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>>> >>>>>>>> NOTE: this patch is an alternate approach to my patch 0065. >>>>>>>> This version has two main advantages compared to 0065: >>>>>>>> 1. Permissions are more flexible (not tied to the admin group). >>>>>>>> 2. Enforcement occurs at the DS-level >>>>>>>> >>>>>>>> It should also be noted that this patch does not enforce UUID >>>>>>>> randomness, only syntax. Users can still specify a token ID so >>>>>>>> long as it is in UUID format. >>>>>>>> >>>>>>>> Nathaniel >>>>>> I am still thinking we may be overcomplicating it. Why cannot we >>>>>> use the similar UUID generation mechanism as we do for SUDO >>>>>> commands for example: >>>>>> >>>>>> # ipa sudocmd-add barbar --all --raw >>>>>> --------------------------- >>>>>> Added Sudo Command "barbar" >>>>>> --------------------------- >>>>>> dn: >>>>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test >>>>>> sudocmd: barbar >>>>>> ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9 >>>>>> objectClass: ipasudocmd >>>>>> objectClass: ipaobject >>>>>> >>>>>> It lets DS generate&rename the object's DN when it finds out that >>>>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We >>>>>> could let DS generate the UUID and only add the "autogenerate" >>>>>> keyword in otptoken-add command. >>>>>> >>>>>> For authorization, we can simply allow users to only add tokens >>>>>> with "autogenerate" ID, see my example here: >>>>>> >>>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html >>>>>> >>>>>> Admin's or special privilege-owners would have more generous ACI >>>>>> allowing other values than just "autogenerate". >>>>>> >>>>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler >>>>>> and we would not need a special DS plugin (unless we want regular >>>>>> users to generate their own UUIDs instead of letting IPA DS to >>>>>> generate it >>>>>> - which I do not think is the case). >>>>> Good point Martin. >>>> This is the avenue I first pursued. The problem is that the client >>>> has no way to look up the DN after the entry is added. In the case >>>> of sudocmd-add, the lookup is performed using the sudocmd >>>> attribute (see sudocmd.get_dn()). We have no similar attribute in >>>> this case and the lookup cannot be performed. >>> Well in theory we could search with creatorName and createTimestamp >>> set to the user's own DN and a range a few seconds in the past ... >>> It is not robust if you add multiple tokens at the same time, but >>> would this be a concern for user created tokens ? >>> >>> Simo. >> Ugh, no offense, but this approach sounds really ugly :-) I will wait >> for Thierry or Ludwig's assessment, but I still think there is either >> existing control for the modify operation to return an updated entry >> or we could create one as you suggest down the thread - as this may >> be useful for other use cases too. > See following mails, the right approach is to use the POST READ control. > > Simo. > Hello, Yes that is correct. Mark implemented it with https://fedorahosted.org/389/ticket/589 and is present since 1.3.2.18 (F20) [root at vm-046 ~]# ldapsearch -LLL -h localhost -p 389 -x -b "" -s base supportedcontrol | grep 1.3.6.1.1.13.2 supportedcontrol: 1.3.6.1.1.13.2 [root at vm-046 ~]# uname -a Linux vm-046.idm.lab.bos.redhat.com 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Sep 23 08:07:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 10:07:11 +0200 Subject: [Freeipa-devel] [PATCH 0298-0302] Implement handling of inactive master zones In-Reply-To: <54201FE2.6090801@redhat.com> References: <541C33B2.7070303@redhat.com> <54201FE2.6090801@redhat.com> Message-ID: <54212A2F.4090609@redhat.com> On 22.9.2014 15:10, Tomas Hozza wrote: > On 09/19/2014 03:46 PM, Petr Spacek wrote: >> >Hello, >> > >> >This patch set fixes >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/127 >> >https://bugzilla.redhat.com/show_bug.cgi?id=1138317 >> > >> >Please review it ASAP, it targets IPA 4.1/Fedora 21. >> > >> >Tomas and Martin, please communicate who is going to review what:-) >> > >> >Thank you for your time! >> > > The code seems to be fine. > > ACK. Thank you for review! I'm branching v5 at this point (before the push). In other words v5 branch will not contain this patch set and master branch will contain the patch set. Pushed to master (to-be-v6): 23f2ddb317ab46419ea83725f458caae1b432fb5 27a911cae9de911938d90c94c61cecd494136fc1 3dd95594e664b7b59a9f8c1d15cb1280eebeb3e7 169f5e5f2a551253bc489edf109eab71a8331c3f 5ef943a39cfdfbadeb2a41cc3efd707caeca36bd -- Petr^2 Spacek From pviktori at redhat.com Tue Sep 23 08:07:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Sep 2014 10:07:19 +0200 Subject: [Freeipa-devel] [PATCHES 247-259] ID views - management part In-Reply-To: <54181D3D.9070400@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> Message-ID: <54212A37.3050503@redhat.com> On 09/16/2014 01:21 PM, Tomas Babej wrote: > Petr, > > thanks for the review, your input is, as always, much to the point. > > My responses are inline. Also, I'm attaching a new patchset, rebased on > master, please, have a look at that. > > Most of the patches have at least minor changes, since I rebased another > ~15 patches into this patchset, and there are additional 9 patches on > top. Patch 254 was deprecated, as we decided to go with more explicit > way of having two separate commands for user and group ID overrides. > > Also, the test suite (around 80 tests) for ID views is attached - patch > 270. It depends on patch 269, sent in separate thread. > > Tomas > > On 09/10/2014 03:10 PM, Petr Viktorin wrote: >> On 08/01/2014 12:30 PM, Tomas Babej wrote: >>> 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. >>> >> >> Not tested yet, but here are my comments on the patches: >> 0247 looks good In 0248 you deleted a newline at EOF in 71-idviews.update 0249 looks good >> >> 0250: >> With so many names imported from one module, I find it more readable >> to `from ipalib.plugins import baseldap`, and use qualified names >> later. Same in the 2 other patches. >> This is personal preference/tip, feel free to disagree :) > > I was just trying to be consistent here, rest of the IPA plugins seem to > use non-qualified names for plugins. Even tough the main reason is > probably that thay use evil star imports :) Let's keep it this way for now. Yes, the rest of the plugins are using star imports; no consistency to be kept here. I think that after these patches nobody will touch it again, so "for now" is basically forever. 0521 looks good >> 0252: >> The pattern_errmsg in idoverride's uid should be expanded to fully >> describe the pattern. > > If we want to expand it, then it should be corrected in user.py plugin > too (I have taken it from there). Still, it's a tradeoff between > conciseness and and exactness, do we really want to specify that user > login may be at most 253 letters long or the $ character may only be > used as terminal one? Or the fact that - can't be used at the beggining? > This is probably the way it was since forever in user plugin. I think the message should at be free of false positives. Using e.e. "-test-name-" and getting back "may only include letters, numbers, _, -, . and $" would be extremely frustrating. Should I file a ticket? 0253 looks good 0255-0256 looks good >> 0258: >> idview_apply: typo in hostgroup doc, should be "hosts to apply the ID >> view to" and "after running the idview-apply command". >> Typos in output params, should be e.g. "this ID view" > > Fixed the second and third complaint ( IMHO this is clear from context, > but I added "this" to be explicit), I'm not so sure about the first one > though. Can we get a native speaker input on that? Actually both just need an article, doesn't matter much if it's "the" or "this". >> >> By subclassing idview_unapply from idview_apply you're violating >> Liskov's substitution principle. Make a common base class for them. > > Done. In the wrong patch, it seems :) >> >> 0259: >> show_id_overrides: cn is a MUST attribute in ipa*Override; use >> view.single_value['cn'] instead of get(). In enumerate_hosts, is None >> okay if cn is missing? > > This was actually an error, fixed in updated version of patches. New > code uses 'ipaanchoruuid' (which is a MUST) and converts it (with your > objections addressed.) If it's MUST, use simply `single_value['ipaanchoruuid']` instead of get(). 0260: The get() method on dict-like objects returns None (or a given default) if the item is missing. If sAMAccountName is MUST, use regular dict item access. If sAMAccountName is MAY, then you're not handling the None you might get. Also look at the other uses of get() to see if you're doing the right thing. I've looked at help(pysss_nss_idmap.getnamebysid). Shouldn't you use pysss_nss_idmap.NAME_KEY and TYPE_KEY? 0261: Again you're using get() on MUST attributes. 0262: ipalib/constants.py - No newline at end of file Is IPA_ANCHOR_PREFIX and SID_ANCHOR_PREFIX to be used outside idviews.py? Do we want it in constants? > + if anchor.startswith(IPA_ANCHOR_PREFIX): > + uuid = anchor.split(IPA_ANCHOR_PREFIX)[1].strip() This is a dangerous idiom to use for removing a prefix, since it will silently give wrong results if the string contains the prefix. Prefer: anchor[len(IPA_ANCHOR_PREFIX):] Same with SID_ANCHOR_PREFIX below. In get_dn, why do you resolve only the last key? In set_anchoruuid_from_dn, an entry is a dict of lists, use either single_value or put the dn[0].value in brackets. 0263: Note that permission_filter_objectclasses are ORed together; I don't think you want ipaOverrideAnchor there. You forgot to regenerate ACI.txt in this patch. 0264 looks OK 0265: Instead of: > + objectclass, name_attr = ( > + ('posixaccount', 'uid') > + if self.override_object == 'user' else > + ('ipausergroup', 'cn') > + ) prefer: objectclass, name_attr = { 'user': ('posixaccount', 'uid'), 'group': ('ipausergroup', 'cn'), }[self.override_object] This generalizes better to more cases, and fails loudly on bad input. You're misusing get() again. 0266: To build strings, prefer formatting: return '%s%s:%s' % (IPA_ANCHOR_PREFIX, domain, uuid) rather than adding the separator to one of the strings and concatenating. Instead of: anchor.split(':')[-1] prefer: anchor.rpartition(':')[-1] which does less work. 0267: resolve_object_to_anchor: For the error message, use Object[...].handle_not_found() 0268 looks good 0270: get_idoverride_dn: Use re.escape() when inserting literal strings in regexes. -- Petr? From pspacek at redhat.com Tue Sep 23 08:40:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 10:40:53 +0200 Subject: [Freeipa-devel] [PATCH 0303-0305] Preparation for 6.0 release Message-ID: <54213215.2010806@redhat.com> Hello, Pushed to master: Bump NVR to 6.0. aeba2eacd5bc85cd4b2872e87a6db5f6d680c266 Update NEWS for upcoming 6.0 release. 92164653b0b8a44d19dea547ddb4917069398e82 Update idnsZoneActive description in README. 8863b85b509984259052d47cbaadf2e7b84a881b -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0303-Update-idnsZoneActive-description-in-README.patch Type: text/x-patch Size: 1655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0304-Update-NEWS-for-upcoming-6.0-release.patch Type: text/x-patch Size: 737 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0305-Bump-NVR-to-6.0.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 23 09:46:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Sep 2014 11:46:09 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <53E25526.4080109@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> Message-ID: <54214161.4080900@redhat.com> Dne 6.8.2014 v 18:17 Jan Cholasta napsal(a): > 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. Turns out Dogtag does not like them, so I removed them. > >> >> Seeing the context makes me wonder if we should eventually add options >> for CA key size and signing alg as well. >> >> rob >> > > Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-314.1-Allow-specifying-key-algorithm-of-the-IPA-CA-cert-in.patch Type: text/x-patch Size: 5753 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 23 10:10:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Sep 2014 12:10:01 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} In-Reply-To: <53FC6C74.1060907@redhat.com> References: <53D7B77A.5010802@redhat.com> <53D7C5DE.6000004@redhat.com> <53D9008E.7060404@redhat.com> <53FC6C74.1060907@redhat.com> Message-ID: <542146F9.50105@redhat.com> On 08/26/2014 01:16 PM, Petr Viktorin wrote: > 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. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I like the approach, solves the issue quite neatly. I didn't find any issues in the changes themselves, or during the testing, so ACK from me for the whole patcheset (which means patches 624-627, despite the subject). -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Sep 23 10:17:54 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Sep 2014 12:17:54 +0200 Subject: [Freeipa-devel] [PATCHES] 0631-0632 Integration tests for backup & restore In-Reply-To: <53E2411B.2010301@redhat.com> References: <53E23D75.2040005@redhat.com> <53E2411B.2010301@redhat.com> Message-ID: <542148D2.1000603@redhat.com> On 08/06/2014 04:52 PM, Petr Viktorin wrote: > 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 > > Thank you for these patches, the tests themselves seem all right to me. My only objection is that I don't think that the coverage for the basic backup-restore test is exhaustive enough. Right now we only check the presence of the admin entry in the LDAP via raw ldap calls and CLI, and the output of the cert-find command. In the future, I'd like this to be extended with basic functionality tests for each of the services, i.e. does DNS work after the restore? Are all the services up and running? However, this does not block the patches, I think they can be pushed now (this means a ACK from me) in their current form and extended later. If you agree, I can file a ticket. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Tue Sep 23 10:30:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Sep 2014 12:30:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} In-Reply-To: <542146F9.50105@redhat.com> References: <53D7B77A.5010802@redhat.com> <53D7C5DE.6000004@redhat.com> <53D9008E.7060404@redhat.com> <53FC6C74.1060907@redhat.com> <542146F9.50105@redhat.com> Message-ID: <54214BB9.6070507@redhat.com> On 09/23/2014 12:10 PM, Tomas Babej wrote: > > On 08/26/2014 01:16 PM, Petr Viktorin wrote: >> 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. > I like the approach, solves the issue quite neatly. I didn't find any > issues in the changes themselves, or during the testing, so ACK from me > for the whole patcheset (which means patches 624-627, despite the subject). Thanks! Pushed to: master: abba25c8269f4928d659cfcaf8363ad2491bd736 ipa-4-1: 127e7a1dcc2ed0624f65597292ac58535ccc0602 -- Petr? From dkupka at redhat.com Tue Sep 23 11:23:38 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 23 Sep 2014 13:23:38 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <541B099C.9060606@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> Message-ID: <5421583A.8040303@redhat.com> On 09/18/2014 06:34 PM, Martin Basti wrote: > ... > 1) > + if options.unattended: > + for ip in ip_addresses: > + if search_reverse_zones and find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in ret_reverse_zones: > + if verify_reverse_zone(rz, ip): > + # reverse zone was entered by user > + break > + else: > + rz = get_reverse_zone_default(str(ip)) > + ret_reverse_zones.append(rz) > + elif options.reverse_zones or create_reverse(): > + for ip in ip_addresses: > + if search_reverse_zones and find_reverse_zone(str(ip)): > + # reverse zone is already in LDAP > + continue > + for rz in ret_reverse_zones: > + if verify_reverse_zone(rz, ip): > + # reverse zone was entered by user > + break > + else: > + rz = get_reverse_zone_default(str(ip)) > + rz = read_reverse_zone(rz, str(ip)) > + ret_reverse_zones.append(rz) > + else: > + options.no_reverse = True > + ret_reverse_zones = [] > > You can make it shorter without duplications: > > # this ifs can be in one line > if not options.unatended: > if not options.reverse_zones > if not create_reverse(): > options.no_reverse=True > return [] > > for ip in ip_addresses: > if search_reverse_zones and find_reverse_zone(str(ip)): > # reverse zone is already in LDAP > continue > for rz in ret_reverse_zones: > if verify_reverse_zone(rz, ip): > # reverse zone was entered by user > break > else: > rz = get_reverse_zone_default(str(ip)) > if not options.unattended: > rz = read_reverse_zone(rz, str(ip)) > ret_reverse_zones.append(rz) > Thanks, I modified it bit different way to alse address recommendation 3). > > 2) > Typo? There is no IP address matching reverze_zone %s." > ---------------------------------------------^^ > Thanks, fixed. > > 3) > Would be nice to ask user to create new zones only if new zones are > required. (If all required zones exist in LDAP, you ask user anyway) > I added one more variable and ask only once. > 4) > Ask framework gurus, if installutils module is better place for function > above > > Petr^3 said that it's ok to have it in bindinstance.py. > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-8-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 36230 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-8-ipa-41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 36214 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 23 11:24:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 13:24:21 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 6.0 Message-ID: <54215865.7010004@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 6.0. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-6.0-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 6.0 ==== [1] idnsZoneActive attribute is supported again and zones can be activated and deactivated at run-time. https://fedorahosted.org/bind-dyndb-ldap/ticket/127 == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. Downgrading back to any 5.x version is supported if idnsZoneActive is always set to TRUE. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From dkupka at redhat.com Tue Sep 23 12:34:36 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 23 Sep 2014 14:34:36 +0200 Subject: [Freeipa-devel] [PATCH] 323 Fix certmonger code causing the ca_renewal_master update plugin to fail In-Reply-To: <5419932D.9040006@redhat.com> References: <5419932D.9040006@redhat.com> Message-ID: <542168DC.5010609@redhat.com> On 09/17/2014 03:57 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Works for me, thanks for patch. ACK. -- David Kupka From mbasti at redhat.com Tue Sep 23 12:51:37 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Sep 2014 14:51:37 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <54201041.2050201@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> <54201041.2050201@redhat.com> Message-ID: <54216CD9.80708@redhat.com> On 22/09/14 14:04, Petr Viktorin wrote: > On 09/01/2014 04:31 PM, Martin Basti wrote: >> On 24/07/14 09:06, Martin Basti wrote: >>> On 23/07/14 15:17, Martin Basti wrote: >>>> This patch fixes ordering problem of schema updates >>>> >>>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>>> (will be in Fedora 21) >>>> >>>> Patch attached >>>> >>>> >>> I found a bug there, but before I send updated version, I need to >>> decide how print modlist: >>> >>> 1. Print modlist before each LDAP update (if changes exist), show >>> modlist per incremental update >>> >>> 2. Print modlist only at once with all updates >>> >>> 3. Use [1] for live_run, [2] for test >>> >> Print modlis before each LDAP update >> Updated patch attached. > > Thanks! This works nicely, just some comments: > > The required python-ldap is quite new, not even built in Koji yet. We > need to get it to the IPA COPR repo before this is merged. > > > The _get_oid_dependency_order function is not indented well. > > It would be nice if it was a bit more obvious that the loop in > _get_oid_dependency_order is guaranteed to terminate. Could you assert > that len(unordered_oids) decreases in each iteration? > >> +SCHEMA_ELEMENT_CLASSES_KEYS = (x[0] for x in SCHEMA_ELEMENT_CLASSES) > > You're creating a generator here, which is only good for one use. Use > a list instead. > Also, this is used just once so it doesn't need to be a module-level > constant. > >> + # FIXME: We should have a better way to display >> the modlist, >> + # for now display raw output of our internal >> routine > > Not entirely related to your change, but you can drop this comment. > Since 61887ac we don't use an internal routine. > > Thank you! updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0105.4-FIX-ldap-schmema-updater-needs-correct-ordering-of-t.patch Type: text/x-patch Size: 8499 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 23 13:13:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Sep 2014 15:13:28 +0200 Subject: [Freeipa-devel] [PATCH] JSON client: Log pretty-printed request and response with -vvv or above Message-ID: <542171F8.90501@redhat.com> https://fedorahosted.org/freeipa/ticket/4233 $ ipa -vvv user-show admin ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json ipa: INFO: Forwarding 'user_show' to json server 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' ipa: INFO: Request: { "id": 0, "method": "user_show", "params": [ [ "admin" ], { "all": false, "no_members": false, "raw": false, "rights": false, "version": "2.102" } ] } [...bunch of output omitted...] ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", "result": { "result": { "dn": "uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com", "gidnumber": [ "364800000" ], "has_keytab": true, "has_password": true, "homedirectory": [ "/home/admin" ], "loginshell": [ "/bin/bash" ], "memberof_group": [ "admins", "trust admins" ], "nsaccountlock": false, "sn": [ "Administrator" ], "uid": [ "admin" ], "uidnumber": [ "364800000" ] }, "summary": null, "value": "admin" }, "version": "4.0.0GIT88bea65" } User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 364800000 GID: 364800000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: True -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0648-JSON-client-Log-pretty-printed-request-and-response-.patch Type: text/x-patch Size: 2718 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 23 14:15:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Sep 2014 16:15:31 +0200 Subject: [Freeipa-devel] [PATCH] JSON client: Log pretty-printed request and response with -vv or above In-Reply-To: <542171F8.90501@redhat.com> References: <542171F8.90501@redhat.com> Message-ID: <54218083.5070402@redhat.com> On 09/23/2014 03:13 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4233 After talking to Rob, I've changed what the -v means a bit more: A single -v just turns on INFO logging, as before: $ ipa -v ping ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json ipa: INFO: Forwarding 'ping' to json server 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' ----------------------------------------------------- IPA server version 4.0.0GIT8543d4c. API version 2.102 ----------------------------------------------------- Two -v's pretty-print the request & response: $ ipa -vv ping ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json ipa: INFO: Forwarding 'ping' to json server 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' ipa: INFO: Request: { "id": 0, "method": "ping", "params": [ [], { "version": "2.102" } ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", "result": { "summary": "IPA server version 4.0.0GIT8543d4c. API version 2.102" }, "version": "4.0.0GIT8543d4c" } ----------------------------------------------------- IPA server version 4.0.0GIT8543d4c. API version 2.102 ----------------------------------------------------- And three -v's print everything -- the pretty-printed JSON and all of the HTTP communication. Also, when using XML-RPC, a single -v will now also print all the HTTP stuff. It could respond to two -v's as before I don't think it's worth complicating the code (keep in mind this is client only, XML-RPC is not used unless requested in the env). This patch also updates the man page. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0648.2-JSON-client-Log-pretty-printed-request-and-response-.patch Type: text/x-patch Size: 3490 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 23 14:29:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Sep 2014 16:29:04 +0200 Subject: [Freeipa-devel] [PATCH] 323 Fix certmonger code causing the ca_renewal_master update plugin to fail In-Reply-To: <542168DC.5010609@redhat.com> References: <5419932D.9040006@redhat.com> <542168DC.5010609@redhat.com> Message-ID: <542183B0.5030301@redhat.com> On 09/23/2014 02:34 PM, David Kupka wrote: > On 09/17/2014 03:57 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > Works for me, thanks for patch. > > ACK. > Pushed to: master: f680a63158d172042c91537a1cb7f6f53766e2ad ipa-4-1: 1a327cf42929919219c2f0bfa9b48eb2d0b039f4 ipa-4-0: 26188d7610170ff2fb89b12cd63a0c698a2381cb -- Petr? From sbose at redhat.com Tue Sep 23 15:11:01 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Sep 2014 17:11:01 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version Message-ID: <20140923151101.GE2947@localhost.localdomain> Hi, this patch should fix https://fedorahosted.org/freeipa/ticket/4031 and with the corresponding SSSD part it would be possible to get the full list of group memberships with the id command even for user who didn't log in before. bye, Sumit -------------- next part -------------- From 23ff38cdea85995b211e73f474bcb4b0d7fb8039 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 23 Sep 2014 15:55:43 +0200 Subject: [PATCH] extdom: add support for new version Currently the extdom plugin is basically used to translate SIDs of AD users and groups to names and POSIX IDs. With this patch a new version is added which will return the full member list for groups and the full list of group memberships for a user. Additionally the gecos field, the home directory and the login shell of a user are returned and an optional list of key-value pairs which currently will contain the SID of the requested object if available. https://fedorahosted.org/freeipa/ticket/4031 --- .../ipa-extdom-extop/ipa_extdom.h | 29 +- .../ipa-extdom-extop/ipa_extdom_common.c | 850 +++++++++++++++------ .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- 3 files changed, 640 insertions(+), 267 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 5f834a047a579104cd2589ce417c580c1c5388d3..548ee74f561c474854c049726c4c3e71da5cbbea 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -64,6 +64,7 @@ #include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" +#define EXOP_EXTDOM_V2_OID "2.16.840.1.113730.3.8.10.4.1" #define IPA_EXTDOM_PLUGIN_NAME "ipa-extdom-extop" #define IPA_EXTDOM_FEATURE_DESC "IPA trusted domain ID mapper" @@ -71,6 +72,11 @@ #define IPA_PLUGIN_NAME IPA_EXTDOM_PLUGIN_NAME +enum extdom_version { + EXTDOM_V1 = 1, + EXTDOM_V2 +}; + enum input_types { INP_SID = 1, INP_NAME, @@ -80,14 +86,17 @@ enum input_types { enum request_types { REQ_SIMPLE = 1, - REQ_FULL + REQ_FULL, + REQ_FULL_WITH_GROUPS }; enum response_types { RESP_SID = 1, RESP_NAME, RESP_USER, - RESP_GROUP + RESP_GROUP, + RESP_USER_GROUPLIST, + RESP_GROUP_MEMBERS }; struct extdom_req { @@ -123,11 +132,18 @@ struct extdom_res { char *user_name; uid_t uid; gid_t gid; + char *gecos; + char *home; + char *shell; + size_t ngroups; + char **groups; } user; struct { char *domain_name; char *group_name; gid_t gid; + size_t nmembers; + char **members; } group; } data; }; @@ -150,15 +166,14 @@ struct pwd_grp { struct passwd pwd; struct group grp; } data; + int ngroups; + gid_t *groups; }; int parse_request_data(struct berval *req_val, struct extdom_req **_req); void free_req_data(struct extdom_req *req); +int check_request(struct extdom_req *req, enum extdom_version version); int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res); -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res); -void free_resp_data(struct extdom_res *res); + struct berval **berval); int pack_response(struct extdom_res *res, struct berval **ret_val); #endif /* _IPA_EXTDOM_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 025d37dc5eda05c8db43d4e8176fd7898ed32fe7..5c1ae79c818676c3660d5cd5b8ca5515a4f0f18d 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -70,6 +70,7 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) * requestType ENUMERATED { * simple (1), * full (2) + * full_with_groups (3) * }, * data InputData * } @@ -179,23 +180,23 @@ void free_req_data(struct extdom_req *req) free(req); } -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res) +int check_request(struct extdom_req *req, enum extdom_version version) +{ + if (version == EXTDOM_V1) { + if (req->request_type == REQ_FULL_WITH_GROUPS) { + return LDAP_PROTOCOL_ERROR; + } + } + + return LDAP_SUCCESS; +} + +static int get_buffer(size_t *_buf_len, char **_buf) { - int ret; - char *domain_name = NULL; - char *sid_str = NULL; - size_t buf_len; - char *buf = NULL; long pw_max; long gr_max; - struct pwd_grp pg_data; - struct passwd *pwd_result = NULL; - struct group *grp_result = NULL; - enum sss_id_type id_type; - char *fq_name = NULL; - char *sep; - + size_t buf_len; + char *buf; pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); @@ -211,302 +212,655 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, return LDAP_OPERATIONS_ERROR; } - switch (req->input_type) { - case INP_POSIX_UID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); + *_buf_len = buf_len; + *_buf = buf; + + return LDAP_SUCCESS; +} + +static int get_user_grouplist(const char *name, gid_t gid, + size_t *_ngroups, gid_t **_groups ) +{ + int ret; + int ngroups; + gid_t *groups; + gid_t *new_groups; + + ngroups = 128; + groups = malloc(ngroups * sizeof(gid_t)); + if (groups == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + new_groups = realloc(groups, ngroups); + if (new_groups == NULL) { + free(groups); + return LDAP_OPERATIONS_ERROR; + } + groups = new_groups; + + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + free(groups); + ret = LDAP_OPERATIONS_ERROR; + } + } + + *_ngroups = ngroups; + *_groups = groups; + + return LDAP_SUCCESS; +} + +static int pack_ber_sid(const char *sid, struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{es}", RESP_SID, sid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +#define SSSD_SYSDB_SID_STR "objectSIDString" + +static int pack_ber_user(const char *domain_name, const char *user_name, + uid_t uid, gid_t gid, + const char *gecos, const char *homedir, + const char *shell, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + enum response_types response_type; + size_t ngroups; + gid_t *groups = NULL; + size_t buf_len; + char *buf = NULL; + struct group grp; + struct group *grp_result; + size_t c; + char *locat; + char *short_user_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + if (gecos == NULL && homedir == NULL && shell == NULL) { + response_type = RESP_USER; + } else { + response_type = RESP_USER_GROUPLIST; + } + + short_user_name = strdup(user_name); + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, - buf_len, &pwd_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; } + } - domain_name = strdup(req->data.posix_uid.domain_name); - break; - case INP_POSIX_GID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, + uid, gid); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (response_type == RESP_USER_GROUPLIST) { + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = ber_printf(ber,"sss", gecos, homedir, shell); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_printf(ber,"{"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + for (c = 0; c < ngroups; c++) { + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = ber_printf(ber, "s", grp.gr_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } + + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; +done: + free(short_user_name); + free(groups); + free(buf); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_group(const char *domain_name, const char *group_name, + gid_t gid, char **members, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + size_t c; + char *locat; + char *short_group_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + short_group_name = strdup(group_name); + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_GID; - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, - buf_len, &grp_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; } + } - domain_name = strdup(req->data.posix_gid.domain_name); - break; - case INP_SID: - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); - if (ret != 0) { + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssi", members == NULL ? RESP_GROUP + : RESP_GROUP_MEMBERS, + domain_name, short_group_name, gid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + if (members != NULL) { + ret = ber_printf(ber,"{"); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); - if (sep == NULL) { + for (c = 0; members[c] != NULL; c++) { + ret = ber_printf(ber, "s", members[c]); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - ret = asprintf(&domain_name, "%s", sep+1); + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; - domain_name = NULL; /* content is undefined according to - asprintf(3) */ - goto done; - } - - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - break; - case SSS_ID_TYPE_GID: - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); - break; - default: + goto done; + } + + } + + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; + +done: + free(short_group_name); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_name(const char *domain_name, const char *name, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ss}}", RESP_NAME, domain_name, name); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +static int handle_uid_request(enum request_types request_type, uid_t uid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(uid, &sid_str, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getpwuid_r(uid, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (request_type == REQ_FULL) { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, NULL, NULL, NULL, NULL, berval); + } else { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_gid_request(enum request_types request_type, gid_t gid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); + if (ret != 0 || !id_type != SSS_ID_TYPE_GID) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (request_type == REQ_FULL) { + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, NULL, + NULL, berval); + } else { + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_sid_request(enum request_types request_type, const char *sid, + struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *domain_name = NULL; + char *fq_name = NULL; + char *object_name = NULL; + char *sep; + size_t buf_len; + char *buf = NULL; + enum sss_id_type id_type; + + ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + + sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); + if (sep == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + object_name = strndup(fq_name, (sep - fq_name)); + domain_name = strdup(sep + 1); + if (object_name == NULL || domain_name == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_name(domain_name, object_name, berval); + goto done; + } + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + switch(id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { ret = LDAP_OPERATIONS_ERROR; goto done; } + + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (request_type == REQ_FULL) { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, NULL, NULL, NULL, NULL, berval); + } else { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid, berval); + } break; - case INP_NAME: - ret = asprintf(&fq_name, "%s%c%s", req->data.name.object_name, - SSSD_DOMAIN_SEPARATOR, - req->data.name.domain_name); - if (ret == -1) { + case SSS_ID_TYPE_GID: + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { ret = LDAP_OPERATIONS_ERROR; - fq_name = NULL; /* content is undefined according to - asprintf(3) */ goto done; } - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (request_type == REQ_FULL) { + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, + NULL, NULL, berval); } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - if (ret == 0 && pwd_result == NULL) { /* no user entry found */ - id_type = SSS_ID_TYPE_GID; - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); - } + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid, berval); } - domain_name = strdup(req->data.name.domain_name); break; default: - ret = LDAP_PROTOCOL_ERROR; - goto done; - } - - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } else if (ret == 0 && pwd_result == NULL && grp_result == NULL && - sid_str == NULL) { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - - if (domain_name == NULL) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - - ret = create_response(req, &pg_data, sid_str, id_type, domain_name, res); - if (ret != 0) { ret = LDAP_OPERATIONS_ERROR; goto done; } - - ret = LDAP_SUCCESS; - done: - free(buf); free(fq_name); + free(object_name); free(domain_name); - free(sid_str); + free(buf); return ret; } -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res) +static int handle_name_request(enum request_types request_type, + const char *name, const char *domain_name, + struct berval **berval) { - int ret = EFAULT; - char *locat = NULL; - struct extdom_res *res; - - res = calloc(1, sizeof(struct extdom_res)); - if (res == NULL) { - return ENOMEM; + int ret; + char *fq_name = NULL; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, + domain_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + fq_name = NULL; /* content is undefined according to + asprintf(3) */ + goto done; } - switch (req->request_type) { - case REQ_SIMPLE: - switch (req->input_type) { - case INP_SID: - res->response_type = RESP_NAME; - res->data.name.domain_name = strdup(domain_name); - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0 ) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.pwd.pw_name); - break; - case SSS_ID_TYPE_GID: - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.grp.gr_name); - break; - default: - ret = EINVAL; - goto done; - } - - if (res->data.name.domain_name == NULL - || res->data.name.object_name == NULL) { - ret = ENOMEM; - goto done; - } - break; - case INP_NAME: - case INP_POSIX_UID: - case INP_POSIX_GID: - res->response_type = RESP_SID; - res->data.sid = strdup(sid_str); - if (res->data.sid == NULL) { - ret = ENOMEM; - goto done; - } - break; - default: - ret = EINVAL; - goto done; - } - break; - case REQ_FULL: - switch (id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - res->response_type = RESP_USER; - res->data.user.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.user.user_name = - strdup(pg_data->data.pwd.pw_name); - - if (res->data.user.domain_name == NULL - || res->data.user.user_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.user.uid = pg_data->data.pwd.pw_uid; - res->data.user.gid = pg_data->data.pwd.pw_gid; - break; - case SSS_ID_TYPE_GID: - res->response_type = RESP_GROUP; - res->data.group.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.group.group_name = - strdup(pg_data->data.grp.gr_name); - - if (res->data.group.domain_name == NULL - || res->data.group.group_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.group.gid = pg_data->data.grp.gr_gid; - break; - default: - ret = EINVAL; - goto done; + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; } - break; - default: - ret = EINVAL; - goto done; + goto done; + } } - ret = 0; - -done: - if (ret == 0) { - *_res = res; + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); } else { - free_resp_data(res); - } + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (pwd_result != NULL) { + if (request_type == REQ_FULL) { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, NULL, NULL, NULL, NULL, berval); + } else { + ret = pack_ber_user(domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } + } else { /* no user entry found */ + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } - if (locat != NULL) { - locat[0] = SSSD_DOMAIN_SEPARATOR; + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (request_type == REQ_FULL) { + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, + NULL, NULL, berval); + } else { + ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } + } } +done: + free(fq_name); + free(sid_str); + free(buf); + return ret; } -void free_resp_data(struct extdom_res *res) +int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, + struct berval **berval) { - if (res == NULL) { - return; - } + int ret; + + switch (req->input_type) { + case INP_POSIX_UID: + ret = handle_uid_request(req->request_type, req->data.posix_uid.uid, + req->data.posix_uid.domain_name, berval); - switch (res->response_type) { - case RESP_SID: - free(res->data.sid); break; - case RESP_NAME: - free(res->data.name.domain_name); - free(res->data.name.object_name); + case INP_POSIX_GID: + ret = handle_gid_request(req->request_type, req->data.posix_gid.gid, + req->data.posix_uid.domain_name, berval); + break; - case RESP_USER: - free(res->data.user.domain_name); - free(res->data.user.user_name); + case INP_SID: + ret = handle_sid_request(req->request_type, req->data.sid, berval); break; - case RESP_GROUP: - free(res->data.group.domain_name); - free(res->data.group.group_name); + case INP_NAME: + ret = handle_name_request(req->request_type, req->data.name.object_name, + req->data.name.domain_name, berval); + break; + default: + ret = LDAP_PROTOCOL_ERROR; + goto done; } - free(res); + +done: + + return ret; } - int pack_response(struct extdom_res *res, struct berval **ret_val) { BerElement *ber = NULL; diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index 9315da260ee3de660ea8ff708950945110da37e3..24191095d5d23705054bc62a2e861fd02db8807c 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -49,6 +49,7 @@ Slapi_PluginDesc ipa_extdom_plugin_desc = { static char *ipa_extdom_oid_list[] = { EXOP_EXTDOM_OID, + EXOP_EXTDOM_V2_OID, NULL }; @@ -71,8 +72,8 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) struct berval *req_val = NULL; struct berval *ret_val = NULL; struct extdom_req *req = NULL; - struct extdom_res *res = NULL; struct ipa_extdom_ctx *ctx; + enum extdom_version version; ret = slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid); if (ret != 0) { @@ -82,7 +83,11 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) } LOG("Received extended operation request with OID %s\n", oid); - if (strcasecmp(oid, EXOP_EXTDOM_OID) != 0) { + if (strcasecmp(oid, EXOP_EXTDOM_OID) == 0) { + version = EXTDOM_V1; + } else if (strcasecmp(oid, EXOP_EXTDOM_V2_OID) == 0) { + version = EXTDOM_V2; + } else { return SLAPI_PLUGIN_EXTENDED_NOT_HANDLED; } @@ -107,21 +112,21 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) goto done; } - ret = handle_request(ctx, req, &res); + ret = check_request(req, version); + if (ret != LDAP_SUCCESS) { + rc = LDAP_UNWILLING_TO_PERFORM; + err_msg = "Error in request data.\n"; + goto done; + } + + ret = handle_request(ctx, req, &ret_val); if (ret != LDAP_SUCCESS) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to handle the request.\n"; goto done; } - ret = pack_response(res, &ret_val); - if (ret != LDAP_SUCCESS) { - rc = LDAP_OPERATIONS_ERROR; - err_msg = "Failed to pack the response.\n"; - goto done; - } - - ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, EXOP_EXTDOM_OID); + ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); if (ret != 0) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to set the OID for the response.\n"; @@ -139,7 +144,6 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) done: free_req_data(req); - free_resp_data(res); if (err_msg != NULL) { LOG("%s", err_msg); } -- 1.8.5.3 From mkosek at redhat.com Tue Sep 23 15:18:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Sep 2014 17:18:38 +0200 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <20140922194855.GB11503@redhat.com> References: <54204433.4010308@redhat.com> <20140922194855.GB11503@redhat.com> Message-ID: <54218F4E.7080502@redhat.com> On 09/22/2014 09:48 PM, Alexander Bokovoy wrote: > On Mon, 22 Sep 2014, Martin Basti wrote: >> Hello, >> >> Related ticket: https://fedorahosted.org/freeipa/ticket/3644 >> >> >> 1) API >> >> The ipaKrb5DelegationACL objectclass requires targets which are stored in >> extra objectclass. >> >> A) we allow users to create groups of principals and then associate them as >> targets -- user can use same group for multiple delegation ACL >> >> B) users specify only list of target principals (no groups) >> >> B seems better to me. > No. > > You have three clearly separate object types here: > > 1. Principals -- any object in the tree that has krbPrincipalAux > supplemental auxiliary object class. These objects can be anywhere in > the tree, we can decide on limiting subtrees to search. > > 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL > supplemental structural object class. These objects can be anywhere > under cn=s4u2proxy,$SUFFIX > > 3. Groups of principals -- any object that has groupOfPrincipals _and_ > doesn't have ipaKrb5DelegationACL object classes. These objects can be > anywhere in the tree, we can decide on limiting subtrees to search and > can decide on a specific subtree to put new groups of principals. > > For (1) you just need to be able to reference principals, this only > requires a search filter to define DN of the principal based on > krbPrincipalName or krbCanonicalName, with support for 'shortcuts' > (specifying principal without realm which is our realm). > > (1) is only used to resolve principals for (2) and (3). > > For (2) you need to implement a proper object handling, like any other > IPA object that supports: > -- multiple values for ipaAllowToImpersonate > -- multiple values for ipaAllowedTarget > CLI would look something like this: > ipa krbdelegation-add > -show > -find > -mod > -add-source > -add-target > -del-source > -del-target > -del > > For (3) you need to implement a proper object handling where creating > the object would happen in the predefined subtree but search or modify > would be possible for any object matched by a proper filter. > > CLI would look something like this: > ipa krbprincipalgroup-add > -show > -find > -mod > -add-member > -del-member > > > The way we use right now groupOfPrincipals, the objects referenced are > placed in different subtrees, according to their primary role. That's > right, as krbPrincipalAux is an auxiliary class, and is added on top of > other object classes to turn other objects into principals. We also use > groupOfPrincipals not only for Kerberos delegation ACLs, that's why > support for multiple subtrees is needed. > > Creating new groupOfPrincipals objects can be allowed in a single > designated place, cn=s4u2proxy,$SUFFIX, because this is primary use of > this API. Alexander's proposal makes sense to me. I would just personally name the commands differently to share the same prefix. I.e. ipa krbdelegation-* and ipa krbdelegationgroup-* as we are not creating general purpose principal groups but only groups for S4U2Proxy usage. I would also reconsider your request to search for the objects in the whole s4u2proxy tree. Across FreeIPA framework, we handle objects in static and defined location of our tree, not in the entire subtree. I think we should although indeed consider adding group of principals to own nsContainer (like cn=targets) as otherwise we will have a clash between krbdelegation rule names and krbdelegationgroup names. Martin From pvoborni at redhat.com Tue Sep 23 15:45:11 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Sep 2014 17:45:11 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <53FB3191.7090102@redhat.com> References: <53FB3191.7090102@redhat.com> Message-ID: <54219587.4020600@redhat.com> On 25.8.2014 14:52, Martin Basti wrote: > 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 > > Review of: http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html 1. Please follow pep8 for the new code. # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 Produces 25 erros. Only E124 and E128 could be ignored if they are part of old code. Patch 114: 2. Also should mention reverse zones: - # except for our own domain + # except for our own domain, and root zone Patch 115: looks ok (except #1) Patch 120: 3. This patch uses term 'deprecated' in a different meaning than a DeprecatedParam. It creates inconsistency -> future confusion. IMHO this usage is correct since the usual understanding of deprecation is that the param is still usable but user should be prepared that it will be removed in a future. IMHO DeprecatedParam is badly designed but that's not an issue of this patch. I think we can leave this as is and create a ticket to rename DeprecatedParam e.g. to RemovedParam. What do you think? That said, I don't see a reason for keeping 'doc', 'label', _validate_ipaddr in 'ip_address' param definition since the param is not used anywhere, and is not present in CLI nor Web UI. 4. Convention for defining optional param is to use '?' at the end of name not: `required=False,` (idnssoamname) 5. You've removed 'idnssoamname' and 'force' from Web UI but dnszone-add precallback still uses these params. What is the intended purpose? Patch 121: 6. Could this be evaluated as 'None' string? idnssoamname=unicode(ns_hostname), the method doesn't guarantee that 'hostname is not None' and ipa_replica_prepare calls it without args: `add_zone(domain)` 7. This line is too long: + self.step("adding NS record to the zones", self.__add_self_ns) # all zones must be created before this step 8. Forgotten debugging lines: print "no ldap2 connection" #TODO remove and maybe: print "entry", repr(entry) 9. Is the LDAP connection check in remove_server_ns_records required? Other RR removal methods are called before this one and they don't have it. IMO if it has to be done, it should be done by a caller. Note: I have not tested replica installation and removal in this round of review process. Patch 123: 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' shouldn't it be normalized to contain '.' at the end? Or is it handled by bind-dyndb-ldap? 11. You can remove `validate_zonemgr` import from dns.py Patch 124: 12. 'idnssoamname' field in dnszone details page should be hidden or marked as required since the LDAP attribute is a MUST 13. You can completely remove `IPA.dnszone_adder_dialog` class since it existed only to contain the logic for idnssamname and ip_address fields (depends on #5). Then remove `$factory: IPA.dnszone_adder_dialog,` from the dialog spec. Patch 125: 14. Got: File "/home/pvoborni/dev/freeipa/ipatests/test_xmlrpc/test_dns_plugin.py", line 332, in class test_dns(Declarative): File "/home/pvoborni/dev/freeipa/ipatests/test_xmlrpc/test_dns_plugin.py", line 422, in test_dns 'nsrecord': nameservers, NameError: name 'nameservers' is not defined Did not investigate much.. but this line is weird: `e = "No DNS servers found in LDAP"` shouldn't 'e' be 'get_nameservers_error'? Unrelated to this patch set: a. One is able to run: # ipa dnszone-remove-permission $zone multiple times and it always returns success Is it intentional? b. Web UI doesn't have means to call dnszone-mod with --force option -- Petr Vobornik From pspacek at redhat.com Tue Sep 23 16:00:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 18:00:04 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <5420116B.7010303@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> Message-ID: <54219904.1040004@redhat.com> On 22.9.2014 14:09, Petr Viktorin wrote: > On 09/22/2014 01:48 PM, Petr Spacek wrote: >> On 22.9.2014 10:38, Martin Kosek wrote: >>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>> >>>>>> See ticket & commit message for details. >>>>> >>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>> version just >>>>> hammer DNS server with as many DNS queries as it can send? >>>> >>>> Oh yes, please add some time.sleep() call :-) > > Wow, no idea how that slipped out. Thanks for the catch. > >>>> Also I would like to see more detailed message: >>>> + self.log.info('Waiting for hostname %s to be resolvable', >>>> + self.replica_fqdn) >>>> >>>> => 'Waiting for hostname %s to be resolvable to A or AAAA record' >>> >>> >>> >>> Really? Shouldn't term "resolvable" already have that covered? A good >>> software >>> should work on all network types, whether it is IPv4, IPv6 or IPv8. So I >>> personally do not think we need to be that specific and can stick to >>> original >>> proposal. >> >> I will agree with you if you post magic code which will work with DNS >> records for IPv8 :-) The code is not going to work with IPv8 just >> because we didn't mention 'A/AAAA' in the error message, A and AAAA >> RRtypes are hardcoded in the code. > > +1; we're checking A and AAAA so that's what we should say we're doing. > > Is this wording OK? Little NACK. (However, the wording is fine.) Tcpdump revealed this: IP vm-117.test.34067 > vm-133.test.domain: 38467+ A? vm-092.test. (51) IP vm-133.test.domain > vm-117.test.34067: 38467 NXDomain* 0/1/0 (116) IP vm-117.test.36006 > vm-133.test.domain: 20194+ A? vm-092.test.ipa.example. (63) IP vm-133.test.domain > vm-117.test.36006: 20194 NXDomain* 0/1/0 (143) IP vm-117.test.51333 > vm-133.test.domain: 34027+ AAAA? vm-092.test. (51) IP vm-133.test.domain > vm-117.test.51333: 34027 NXDomain* 0/1/0 (116) IP vm-117.test.60373 > vm-133.test.domain: 45679+ AAAA? vm-092.test.ipa.example. (63) You can see that the query for each A/AAAA type is repeated twice, the second time with 'ipa.example.' suffix. This is caused by search list processing (search directive in /etc/resolv.conf) and is highly undesirable. (Read this [1] e-mail if you want to hear it from Paul Vixie.) The fix is simple: You have to be sure that self.replica_fqdn is actually absolute FQDN - with the trailing period. Naive solution would be to use dns_answer = resolver.query(self.replica_fqdn + '.', 'A', 'IN') but I don't know if self.replica_fqdn variable can contain trailing period or not. Mbasti can show you more advanced code snippets using 'dns.name'. [1] https://lists.dns-oarc.net/pipermail/dns-operations/2014-September/012157.html -- Petr^2 Spacek From pspacek at redhat.com Tue Sep 23 16:35:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 18:35:32 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <54205A88.8050207@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> Message-ID: <5421A154.4090304@redhat.com> On 22.9.2014 19:21, Martin Basti wrote: > On 22/09/14 13:17, Petr Vobornik wrote: >> On 19.9.2014 16:15, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >>> Patch attached. >>> >> >> Patch 126: >> >> 1. I think that just >> DeprecatedParam('dnsclass?'), >> >> should be enough. >> >> Also >> >> 2. You forgot to update API.txt and VERSION >> >> Patch 127: >> ACK >> > Updated patchset attached ACK, it works for me. -- Petr^2 Spacek From mbasti at redhat.com Tue Sep 23 16:53:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Sep 2014 18:53:27 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <5421A154.4090304@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> <5421A154.4090304@redhat.com> Message-ID: <5421A587.3020502@redhat.com> On 23/09/14 18:35, Petr Spacek wrote: > On 22.9.2014 19:21, Martin Basti wrote: >> On 22/09/14 13:17, Petr Vobornik wrote: >>> On 19.9.2014 16:15, Martin Basti wrote: >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >>>> Patch attached. >>>> >>> >>> Patch 126: >>> >>> 1. I think that just >>> DeprecatedParam('dnsclass?'), >>> >>> should be enough. >>> >>> Also >>> >>> 2. You forgot to update API.txt and VERSION >>> >>> Patch 127: >>> ACK >>> >> Updated patchset attached > > ACK, it works for me. > Please don't push, we discuss this and we will nit use the DeprecatedParam. -- Martin Basti From mbasti at redhat.com Tue Sep 23 18:25:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Sep 2014 20:25:15 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5421583A.8040303@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> Message-ID: <5421BB0B.9050500@redhat.com> On 23/09/14 13:23, David Kupka wrote: > On 09/18/2014 06:34 PM, Martin Basti wrote: >> ... >> 1) >> + if options.unattended: >> + for ip in ip_addresses: >> + if search_reverse_zones and find_reverse_zone(str(ip)): >> + # reverse zone is already in LDAP >> + continue >> + for rz in ret_reverse_zones: >> + if verify_reverse_zone(rz, ip): >> + # reverse zone was entered by user >> + break >> + else: >> + rz = get_reverse_zone_default(str(ip)) >> + ret_reverse_zones.append(rz) >> + elif options.reverse_zones or create_reverse(): >> + for ip in ip_addresses: >> + if search_reverse_zones and find_reverse_zone(str(ip)): >> + # reverse zone is already in LDAP >> + continue >> + for rz in ret_reverse_zones: >> + if verify_reverse_zone(rz, ip): >> + # reverse zone was entered by user >> + break >> + else: >> + rz = get_reverse_zone_default(str(ip)) >> + rz = read_reverse_zone(rz, str(ip)) >> + ret_reverse_zones.append(rz) >> + else: >> + options.no_reverse = True >> + ret_reverse_zones = [] >> >> You can make it shorter without duplications: >> >> # this ifs can be in one line >> if not options.unatended: >> if not options.reverse_zones >> if not create_reverse(): >> options.no_reverse=True >> return [] >> >> for ip in ip_addresses: >> if search_reverse_zones and find_reverse_zone(str(ip)): >> # reverse zone is already in LDAP >> continue >> for rz in ret_reverse_zones: >> if verify_reverse_zone(rz, ip): >> # reverse zone was entered by user >> break >> else: >> rz = get_reverse_zone_default(str(ip)) >> if not options.unattended: >> rz = read_reverse_zone(rz, str(ip)) >> ret_reverse_zones.append(rz) >> > > Thanks, I modified it bit different way to alse address recommendation > 3). > >> >> 2) >> Typo? There is no IP address matching reverze_zone %s." >> ---------------------------------------------^^ >> > > Thanks, fixed. > >> >> 3) >> Would be nice to ask user to create new zones only if new zones are >> required. (If all required zones exist in LDAP, you ask user anyway) >> > > I added one more variable and ask only once. > >> 4) >> Ask framework gurus, if installutils module is better place for function >> above >> >> > > Petr^3 said that it's ok to have it in bindinstance.py. > >> > NACK, most important point is 7 1) I'm not sure if this is bug, but interactively is allowed to add only one ip address Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 2001:db8::2 The kerberos protocol requires a Realm name to be defined. 2) I'm getting error message Invalid reverse zone 10.in-addr.arpa. for IP address 2001:db8::dead:beef Invalid reverse zone 10.in-addr.arpa. for IP address fed0:babe:baab:0:21a:4aff:fe10:4e18 - or - Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP address fed0:babe:baab:0:21a:4aff:fe10:4e18 Please specify the reverse zone name [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. This shouldn't be there Could be better to ask user to specific zone for ip address a.b.c.d. 4) just nitpick The IPA Master Server will be configured with: ... IP address(es): 2001:db8::dead:beef, fed0:babe:baab:0:21a:4aff:fe10:4e18 ... Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. You have label "IP address(es)", so you should use label "Reverse zone(s)" 5) ipa-server-install --ip-address=10.16.78.105 --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. --setup-dns Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not sure if this is wrong, but we prevents user to add zone without address in it, so we should prevents, to add empty zone. 6) ipa-replica-prepare --ip-address 10.16.78.105 --ip-address 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. vm-105.example.com Directory Manager (existing master) password: Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 Invalid reverse zone 1.0.0.2.ip6.arpa. IMO This should work, right? + sys.exit("There is no IP address matching reverse zone %s." % rz) I expected at least this error to be shown. 7) ipa-replica-prepare --ip-address 10.16.78.105 --ip-address 2001:db8::dead:beef vm-105.example.com Directory Manager (existing master) password: ....... Adding DNS records for vm-105.example.com Values instance has no attribute 'ip_address' Command returns the attribute error. It fails with one --ip-address too. *) Not related with your patch Problem with installation: I'm getting message: IPA server is already configured on this system. Even if I validation wasn't successful and installation was aborted. IPA install detects previous installations by checking state file and restore files. Function get_server_ip_address() stores some data and hosts file and modify the host file, before user agreed installation. This error was there before your patch. https://fedorahosted.org/freeipa/ticket/4561 -- Martin Basti From pvoborni at redhat.com Tue Sep 23 18:31:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Sep 2014 20:31:48 +0200 Subject: [Freeipa-devel] [PATCHES] 319-321 Build and packaging fixes In-Reply-To: <5419776C.2000900@redhat.com> References: <54196319.5010302@redhat.com> <541966CE.8000406@redhat.com> <20140917110751.GY2541@redhat.com> <5419776C.2000900@redhat.com> Message-ID: <5421BC94.2060509@redhat.com> On 17.9.2014 13:58, Jan Cholasta wrote: > Dne 17.9.2014 v 13:07 Alexander Bokovoy napsal(a): >> On Wed, 17 Sep 2014, Martin Kosek wrote: >>> On 09/17/2014 12:31 PM, Jan Cholasta wrote: >>>> >>>> +Conflicts: %{alt_name}-server-trust-ad >>>> +Obsoletes: %{alt_name}-server-trust-ad < %{version}-%{release} >>> >>> Just one question - should we check also for %{release}? Generally, >>> release >>> number does not have much value, we could rebuild our version of the >>> package 10 >>> times, but it does not mean it is newer. >>> >>> I.e. freeipa-server-4.0.0-10 should probably not obsolete >>> ipa-server-4.0.0-1 >>> but only ipa-server-3.3.3-10, right? >> I agree with the %{release} idea. We definitely don't need to be so >> picky with it. > > OK, fixed. > > I used wrong numbers for the patches, they should be 320-322. Fixed as > well. > > Updated patches attached. > Patch 320: ACK Patch 321: ACK Patch 322: ACK All pushed: master: * 0e2dc70d8ec4d96914190a38dac9a240605cab1d Allow RPM upgrade from ipa-* packages * 9fa8cff6da6b6b85aa5b03028386f159fc816124 Include ipaplatform in client-only build * 449d10b85cf2fe6a5b41bf167419f2432e752ad1 Include the ipa command in client-only build ipa-4-1: * 9486f3dc8d549b83f5a64b3dc8e57bf4896588d8 Allow RPM upgrade from ipa-* packages * 72a82b855b77e04a0e672eaffc59e33256a66721 Include ipaplatform in client-only build * fbc6345153391213d59e1c7c267e6425fdf7b77e Include the ipa command in client-only build ipa-4-0: * faba3f060e7513790d584bde3a9901793031fcf1 Allow RPM upgrade from ipa-* packages * df187a4b4a9a2eeac8b11152de0cdc250e55cfb1 Include ipaplatform in client-only build * 22ce015913c482308d499572bd24389bca98a0e5 Include the ipa command in client-only build -- Petr Vobornik From rcritten at redhat.com Tue Sep 23 18:39:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Sep 2014 14:39:16 -0400 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5420121C.3050907@redhat.com> References: <5420121C.3050907@redhat.com> Message-ID: <5421BE54.8050802@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patches fix various bugs and shortcomings in the CA > management and renewal code. Related tickets: > , > . > > (Patch 319 was originally posted at > .) Only two of the patches includes what ticket(s) they address. Most have the tersest of commit messages. If got more and more difficult to see why the changes were needed at all, as you'll see. As a side note, it was rather difficult to review parts of this as different patches modify exactly the same code in different ways. General: These patches don't replace /etc/pki/nssdb, they just add a new location. Do we need to keep using the shared db because of p11-kit? 319: The post-install script tries to get a cert with nickname 'IPA CA'. It should also look for '$REALM IPA CA'. I'd use ipapythhon.certdb.py:CA_NICKNAME_FMT. Having a similar option for External CA is probably not a bad idea. You don't need the password file to import a cert into an NSS database. It may be too complex in a spec file but would it be better to try to fetch things out of LDAP? This nearly screams for a separate script to do the work. Are these operations important enough to be logged to /var/log/ipaupgrade.log? I suspect it's the kind of thing that might fail and never be noticed. At some point we'll upgrade to sql NSS databases. Is this going to complicate things? There are some places you do str(e[2]) that aren't necessary. Might be worthwhile to clean up the comments regarding XML-RPC while you're at it and just refer to RPC. I'd rename ca_certs_nss to ca_certs_trust for clarity. Is the separate helper create_ipa_nssdb() necessary? Should create_db() be extended to do this extra work? 324: ACK 325: The exception from get_cert() is very rough so wouldn't cover the case of file permissions, missing database, etc, but since the overall behavior isn't changing, ACK. Might be worth a comment though indicating a potential source of oddness for the uninitiated. 326: ACK 327: @@ -133,6 +116,7 @@ class CertUpdate(admintool.AdminTool): criteria = { 'cert-database': dogtag_constants.ALIAS_DIR, 'cert-nickname': nickname, + 'ca-name': 'dogtag-ipa-ca-renew-agent', } request_id = certmonger.get_request_id(criteria) if request_id is not None: Doesn't seem related to this change. 328: ACK 329: ACK 330: I don't understand the reference to ipa.p11-kit (an unowned file, btw). Are you removing any cert that may be left over from some previous install? If the file were to exist it could cause update-ca-trust to be executed twice. Is that needed? I think more clarity in the commit message will clear things up. 331: ACK 332: What is the reason for this refactoring? 333: Seems reasonable but why would a CA profile change in the middle of a request? 334: Same boat, why? 335: I kinda get the picture, along with previous patches, but need more info. Some tips on testing would be helpful. rob From pspacek at redhat.com Tue Sep 23 18:39:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 14:39:46 -0400 (EDT) Subject: [Freeipa-devel] Continuous Integration & dependency tree testing In-Reply-To: <1294167567.28224500.1411497463480.JavaMail.zimbra@redhat.com> Message-ID: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> Hello, The recent problem with Tomcat forced me to think how we can detect that some other package broke IPA before it hit users. After all, it seems pretty easy. 0) Get a VM for testing purposes (preferably with minimal set of IPA dependencies). The VM has to be reverted to snapshot after every run. (This is pretty simple with RHEV-M/libvirt.) 1) Detect all changes in the minimal set of packages installed on the test VM. It is easy because we can simply hash output of YUM/DNF "upgrade" command: # echo "n" | dnf upgrade | md5sum > changeset.id changeset.id will change every time when a package which is present on test system changes but stays the same if there were no updates from last run. (There could be false positives but it doesn't matter - the test will be simply run twice.) 2) if (changeset.id != previous_changeset.id) run_tests() 3) This machinery could be triggered by cron or even by a message on fedmsg about a new package pushed to updates-testing... Tests could use released versions of IPA (present in fedora-updates) to get better signal/noise ratio. Okay, it is time to stop dreaming and go to bed. Good night from Europe :-) -- Petr^2 Spacek From abokovoy at redhat.com Tue Sep 23 18:46:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Sep 2014 21:46:12 +0300 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <54218F4E.7080502@redhat.com> References: <54204433.4010308@redhat.com> <20140922194855.GB11503@redhat.com> <54218F4E.7080502@redhat.com> Message-ID: <20140923184612.GD11503@redhat.com> On Tue, 23 Sep 2014, Martin Kosek wrote: >On 09/22/2014 09:48 PM, Alexander Bokovoy wrote: >> On Mon, 22 Sep 2014, Martin Basti wrote: >>> Hello, >>> >>> Related ticket: https://fedorahosted.org/freeipa/ticket/3644 >>> >>> >>> 1) API >>> >>> The ipaKrb5DelegationACL objectclass requires targets which are stored in >>> extra objectclass. >>> >>> A) we allow users to create groups of principals and then associate them as >>> targets -- user can use same group for multiple delegation ACL >>> >>> B) users specify only list of target principals (no groups) >>> >>> B seems better to me. >> No. >> >> You have three clearly separate object types here: >> >> 1. Principals -- any object in the tree that has krbPrincipalAux >> supplemental auxiliary object class. These objects can be anywhere in >> the tree, we can decide on limiting subtrees to search. >> >> 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL >> supplemental structural object class. These objects can be anywhere >> under cn=s4u2proxy,$SUFFIX >> >> 3. Groups of principals -- any object that has groupOfPrincipals _and_ >> doesn't have ipaKrb5DelegationACL object classes. These objects can be >> anywhere in the tree, we can decide on limiting subtrees to search and >> can decide on a specific subtree to put new groups of principals. >> >> For (1) you just need to be able to reference principals, this only >> requires a search filter to define DN of the principal based on >> krbPrincipalName or krbCanonicalName, with support for 'shortcuts' >> (specifying principal without realm which is our realm). >> >> (1) is only used to resolve principals for (2) and (3). >> >> For (2) you need to implement a proper object handling, like any other >> IPA object that supports: >> -- multiple values for ipaAllowToImpersonate >> -- multiple values for ipaAllowedTarget >> CLI would look something like this: >> ipa krbdelegation-add >> -show >> -find >> -mod >> -add-source >> -add-target >> -del-source >> -del-target >> -del >> >> For (3) you need to implement a proper object handling where creating >> the object would happen in the predefined subtree but search or modify >> would be possible for any object matched by a proper filter. >> >> CLI would look something like this: >> ipa krbprincipalgroup-add >> -show >> -find >> -mod >> -add-member >> -del-member >> >> >> The way we use right now groupOfPrincipals, the objects referenced are >> placed in different subtrees, according to their primary role. That's >> right, as krbPrincipalAux is an auxiliary class, and is added on top of >> other object classes to turn other objects into principals. We also use >> groupOfPrincipals not only for Kerberos delegation ACLs, that's why >> support for multiple subtrees is needed. >> >> Creating new groupOfPrincipals objects can be allowed in a single >> designated place, cn=s4u2proxy,$SUFFIX, because this is primary use of >> this API. > >Alexander's proposal makes sense to me. I would just personally name the >commands differently to share the same prefix. I.e. > >ipa krbdelegation-* >and >ipa krbdelegationgroup-* > >as we are not creating general purpose principal groups but only groups for >S4U2Proxy usage. > >I would also reconsider your request to search for the objects in the whole >s4u2proxy tree. Across FreeIPA framework, we handle objects in static and >defined location of our tree, not in the entire subtree. You have to deal with the fact that we already have established uses and need to support them. New entities can be created where they are but existing ones cannot be moved for the sake of moving because DNs of some objects are used in external config files. -- / Alexander Bokovoy From simo at redhat.com Tue Sep 23 18:58:58 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Sep 2014 14:58:58 -0400 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <54218F4E.7080502@redhat.com> References: <54204433.4010308@redhat.com> <20140922194855.GB11503@redhat.com> <54218F4E.7080502@redhat.com> Message-ID: <20140923145858.100f72ca@willson.usersys.redhat.com> On Tue, 23 Sep 2014 17:18:38 +0200 Martin Kosek wrote: > On 09/22/2014 09:48 PM, Alexander Bokovoy wrote: > > On Mon, 22 Sep 2014, Martin Basti wrote: > >> Hello, > >> > >> Related ticket: https://fedorahosted.org/freeipa/ticket/3644 > >> > >> > >> 1) API > >> > >> The ipaKrb5DelegationACL objectclass requires targets which are > >> stored in extra objectclass. > >> > >> A) we allow users to create groups of principals and then > >> associate them as targets -- user can use same group for multiple > >> delegation ACL > >> > >> B) users specify only list of target principals (no groups) > >> > >> B seems better to me. > > No. > > > > You have three clearly separate object types here: > > > > 1. Principals -- any object in the tree that has krbPrincipalAux > > supplemental auxiliary object class. These objects can be anywhere > > in the tree, we can decide on limiting subtrees to search. > > > > 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL > > supplemental structural object class. These objects can be anywhere > > under cn=s4u2proxy,$SUFFIX > > > > 3. Groups of principals -- any object that has groupOfPrincipals > > _and_ doesn't have ipaKrb5DelegationACL object classes. These > > objects can be anywhere in the tree, we can decide on limiting > > subtrees to search and can decide on a specific subtree to put new > > groups of principals. > > > > For (1) you just need to be able to reference principals, this only > > requires a search filter to define DN of the principal based on > > krbPrincipalName or krbCanonicalName, with support for 'shortcuts' > > (specifying principal without realm which is our realm). > > > > (1) is only used to resolve principals for (2) and (3). > > > > For (2) you need to implement a proper object handling, like any > > other IPA object that supports: > > -- multiple values for ipaAllowToImpersonate > > -- multiple values for ipaAllowedTarget > > CLI would look something like this: > > ipa krbdelegation-add > > -show > > -find > > -mod > > -add-source > > -add-target > > -del-source > > -del-target > > -del > > > > For (3) you need to implement a proper object handling where > > creating the object would happen in the predefined subtree but > > search or modify would be possible for any object matched by a > > proper filter. > > > > CLI would look something like this: > > ipa krbprincipalgroup-add > > -show > > -find > > -mod > > -add-member > > -del-member > > > > > > The way we use right now groupOfPrincipals, the objects referenced > > are placed in different subtrees, according to their primary role. > > That's right, as krbPrincipalAux is an auxiliary class, and is > > added on top of other object classes to turn other objects into > > principals. We also use groupOfPrincipals not only for Kerberos > > delegation ACLs, that's why support for multiple subtrees is needed. > > > > Creating new groupOfPrincipals objects can be allowed in a single > > designated place, cn=s4u2proxy,$SUFFIX, because this is primary use > > of this API. > > Alexander's proposal makes sense to me. I would just personally name > the commands differently to share the same prefix. I.e. > > ipa krbdelegation-* > and > ipa krbdelegationgroup-* > > as we are not creating general purpose principal groups but only > groups for S4U2Proxy usage. > > I would also reconsider your request to search for the objects in the > whole s4u2proxy tree. Across FreeIPA framework, we handle objects in > static and defined location of our tree, not in the entire subtree. > > I think we should although indeed consider adding group of principals > to own nsContainer (like cn=targets) as otherwise we will have a > clash between krbdelegation rule names and krbdelegationgroup names. Keep in mind that we already have a few rules in there and the groups are in the same container, the names are different as the groups are named -targets, so we'll have to keep using a subtree search, but that is fine cn=s4u2proxy has no subtree atm. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed Sep 24 02:43:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Sep 2014 21:43:15 -0500 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <542036EC.90304@redhat.com> References: <542036EC.90304@redhat.com> Message-ID: <54222FC3.8080508@redhat.com> On 9/22/2014 9:49 AM, Petr Vobornik wrote: > [PATCH] webui-ci: case-insensitive record check > > Indirect association are no longer lower cased, which caused a issue in CI. Is the use of "|=" operator intentional? I don't see the "has" variable defined anywhere else in this method. has |= self.has_record(pkey.lower(), parent, table_name) If this has been tested to work, then ACK. -- Endi S. Dewata From edewata at redhat.com Wed Sep 24 02:43:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Sep 2014 21:43:18 -0500 Subject: [Freeipa-devel] [PATCH] 756 webui: fix regression in association facet preop In-Reply-To: <54203719.1040304@redhat.com> References: <54203719.1040304@redhat.com> Message-ID: <54222FC6.9080508@redhat.com> On 9/22/2014 9:50 AM, Petr Vobornik wrote: > Association facet specs use 'add_method' instead of 'add_command' > > origin: https://fedorahosted.org/freeipa/ticket/4507 ACK. -- Endi S. Dewata From mkosek at redhat.com Wed Sep 24 06:35:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 08:35:22 +0200 Subject: [Freeipa-devel] Krb service delegation rules in CLI In-Reply-To: <20140923145858.100f72ca@willson.usersys.redhat.com> References: <54204433.4010308@redhat.com> <20140922194855.GB11503@redhat.com> <54218F4E.7080502@redhat.com> <20140923145858.100f72ca@willson.usersys.redhat.com> Message-ID: <5422662A.8070506@redhat.com> On 09/23/2014 08:58 PM, Simo Sorce wrote: > On Tue, 23 Sep 2014 17:18:38 +0200 > Martin Kosek wrote: > >> On 09/22/2014 09:48 PM, Alexander Bokovoy wrote: >>> On Mon, 22 Sep 2014, Martin Basti wrote: >>>> Hello, >>>> >>>> Related ticket: https://fedorahosted.org/freeipa/ticket/3644 >>>> >>>> >>>> 1) API >>>> >>>> The ipaKrb5DelegationACL objectclass requires targets which are >>>> stored in extra objectclass. >>>> >>>> A) we allow users to create groups of principals and then >>>> associate them as targets -- user can use same group for multiple >>>> delegation ACL >>>> >>>> B) users specify only list of target principals (no groups) >>>> >>>> B seems better to me. >>> No. >>> >>> You have three clearly separate object types here: >>> >>> 1. Principals -- any object in the tree that has krbPrincipalAux >>> supplemental auxiliary object class. These objects can be anywhere >>> in the tree, we can decide on limiting subtrees to search. >>> >>> 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL >>> supplemental structural object class. These objects can be anywhere >>> under cn=s4u2proxy,$SUFFIX >>> >>> 3. Groups of principals -- any object that has groupOfPrincipals >>> _and_ doesn't have ipaKrb5DelegationACL object classes. These >>> objects can be anywhere in the tree, we can decide on limiting >>> subtrees to search and can decide on a specific subtree to put new >>> groups of principals. >>> >>> For (1) you just need to be able to reference principals, this only >>> requires a search filter to define DN of the principal based on >>> krbPrincipalName or krbCanonicalName, with support for 'shortcuts' >>> (specifying principal without realm which is our realm). >>> >>> (1) is only used to resolve principals for (2) and (3). >>> >>> For (2) you need to implement a proper object handling, like any >>> other IPA object that supports: >>> -- multiple values for ipaAllowToImpersonate >>> -- multiple values for ipaAllowedTarget >>> CLI would look something like this: >>> ipa krbdelegation-add >>> -show >>> -find >>> -mod >>> -add-source >>> -add-target >>> -del-source >>> -del-target >>> -del >>> >>> For (3) you need to implement a proper object handling where >>> creating the object would happen in the predefined subtree but >>> search or modify would be possible for any object matched by a >>> proper filter. >>> >>> CLI would look something like this: >>> ipa krbprincipalgroup-add >>> -show >>> -find >>> -mod >>> -add-member >>> -del-member >>> >>> >>> The way we use right now groupOfPrincipals, the objects referenced >>> are placed in different subtrees, according to their primary role. >>> That's right, as krbPrincipalAux is an auxiliary class, and is >>> added on top of other object classes to turn other objects into >>> principals. We also use groupOfPrincipals not only for Kerberos >>> delegation ACLs, that's why support for multiple subtrees is needed. >>> >>> Creating new groupOfPrincipals objects can be allowed in a single >>> designated place, cn=s4u2proxy,$SUFFIX, because this is primary use >>> of this API. >> >> Alexander's proposal makes sense to me. I would just personally name >> the commands differently to share the same prefix. I.e. >> >> ipa krbdelegation-* >> and >> ipa krbdelegationgroup-* >> >> as we are not creating general purpose principal groups but only >> groups for S4U2Proxy usage. >> >> I would also reconsider your request to search for the objects in the >> whole s4u2proxy tree. Across FreeIPA framework, we handle objects in >> static and defined location of our tree, not in the entire subtree. >> >> I think we should although indeed consider adding group of principals >> to own nsContainer (like cn=targets) as otherwise we will have a >> clash between krbdelegation rule names and krbdelegationgroup names. > > Keep in mind that we already have a few rules in there and the groups > are in the same container, the names are different as the groups are > named -targets, so we'll have to keep using a subtree > search, but that is fine cn=s4u2proxy has no subtree atm. > > Simo. Ok, it is true I was also thinking how to deal with existing s4u2 proxy rules. It would be best to simply move current targets to cn=targets too, but if they are already referred to from elsewhere it may be a too drastic move (though would allow us to start with clean approach and no exceptions). However, I still think we should have a special container for user custom rules (cn=targets or similar) to not deal with name clashes on targets groups and delegation rules. Martin From mkosek at redhat.com Wed Sep 24 06:47:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 08:47:57 +0200 Subject: [Freeipa-devel] Continuous Integration & dependency tree testing In-Reply-To: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> References: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> Message-ID: <5422691D.50003@redhat.com> On 09/23/2014 08:39 PM, Petr Spacek wrote: > Hello, > > The recent problem with Tomcat forced me to think how we can detect that some other package broke IPA before it hit users. > > After all, it seems pretty easy. > > 0) Get a VM for testing purposes (preferably with minimal set of IPA dependencies). The VM has to be reverted to snapshot after every run. (This is pretty simple with RHEV-M/libvirt.) > > 1) Detect all changes in the minimal set of packages installed on the test VM. > > It is easy because we can simply hash output of YUM/DNF "upgrade" command: > > # echo "n" | dnf upgrade | md5sum > changeset.id > > changeset.id will change every time when a package which is present on test system changes but stays the same if there were no updates from last run. (There could be false positives but it doesn't matter - the test will be simply run twice.) > > 2) if (changeset.id != previous_changeset.id) > run_tests() > > 3) This machinery could be triggered by cron or even by a message on fedmsg about a new package pushed to updates-testing... > > Tests could use released versions of IPA (present in fedora-updates) to get better signal/noise ratio. > > Okay, it is time to stop dreaming and go to bed. Good night from Europe :-) The current answer to this is current FreeIPA Jenkins CI instance. It is run on top of updates-testing, so as soon as some breaking package gets in updates-testing, the job should break. There is a good question though how the test should be triggered when our dependency changes and the code does not (especially in stable branches). This may be the part where the mechanism you propose would come in play. Martin From mkosek at redhat.com Wed Sep 24 08:05:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 10:05:07 +0200 Subject: [Freeipa-devel] [PATCH 0242] Set the default attributes for RootDSE In-Reply-To: <53C4D49F.5010908@redhat.com> References: <53C4D49F.5010908@redhat.com> Message-ID: <54227B33.4050900@redhat.com> On 07/15/2014 09:13 AM, Tomas Babej wrote: > Hi, > > With 389 DS 1.3.3 upwards we can leverage the nsslapd-return-default-opattr > attribute to enumerate the list of attributes that should be returned > even if not specified explicitly. Use the behaviour to get the same > attributes > returned from searches on rootDSE as in 1.3.1. > > https://fedorahosted.org/freeipa/ticket/4288 Given that DS 1.3.3 is not available in our COPR and this DS is required in ipa-4-0, we can resolve this ticket - the first patch version works fine. ACK (sorry to Petr for stealing this review). Pushed to: master: 1c022646d2aa92ec0eb33e0e260c086376e0f08b ipa-4-1: 38fe3a5c308f4273d78cac951d91edf009f2cdc6 ipa-4-0: e629763af9b4b7ce19109ec6ea915d43bb054879 Martin From pviktori at redhat.com Wed Sep 24 08:12:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 10:12:59 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <54219587.4020600@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> Message-ID: <54227D0B.9040304@redhat.com> On 09/23/2014 05:45 PM, Petr Vobornik wrote: > On 25.8.2014 14:52, Martin Basti wrote: [...] > 1. Please follow pep8 for the new code. > # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 > Produces 25 erros. > > Only E124 and E128 could be ignored if they are part of old code. FWIW, our style guide is PEP 8 the document [0], not pep8 the tool. The document lists these "other good reasons to ignore a particular guideline": 1. When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP. 2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess (in true XP style). 3. Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code. 4. When the code needs to remain compatible with older versions of Python that don't support the feature recommended by the style guide. Anyway: there is no blanket exception for "Limit all lines to a maximum of 79 characters" (which pep8 calls E501). Some IPA developers do use several columns of code side by side. [0] http://legacy.python.org/dev/peps/pep-0008/ -- Petr? From mkosek at redhat.com Wed Sep 24 08:22:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 10:22:29 +0200 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <20140922150203.GA11503@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> <20140922101648.5abe7031@willson.usersys.redhat.com> <20140922150203.GA11503@redhat.com> Message-ID: <54227F45.8080606@redhat.com> On 09/22/2014 05:02 PM, Alexander Bokovoy wrote: > On Mon, 22 Sep 2014, Simo Sorce wrote: >> On Mon, 22 Sep 2014 15:36:01 +0200 >> David Kupka wrote: >> >>> On 09/18/2014 09:42 PM, Martin Kosek wrote: >>> > On 09/18/2014 09:11 PM, Simo Sorce wrote: >>> >> On Thu, 18 Sep 2014 14:57:45 -0400 >>> >> Rob Crittenden wrote: >>> >> >>> >>> Martin Kosek wrote: >>> >>>> On 09/18/2014 04:06 PM, David Kupka wrote: >>> >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: >>> >>>>>> David Kupka wrote: >>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 >>> >>>>>> >>> >>>>>> You are removing an ACI in this patch. It is always possible it >>> >>>>>> is no longer needed. Did you test all the client enrollment >>> >>>>>> scenarios? >>> >>>>>> >>> >>>>>> rob >>> >>>>>> >>> >>>>> >>> >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying ACI >>> >>>>> so it is possible to add krbPrincipalName to host even when >>> >>>>> there is already one (or more). And adding one ACI to allow >>> >>>>> writing krbCanonicalName to host. But I'm still not really >>> >>>>> familiar with ACI so please correct me if I'm wrong. >>> >>>>> >>> >>>> >>> >>>> What refers to is probably the update in ACI.txt - the ACI >>> >>>> alternative to API.txt. David updated an ACI, not removed it. >>> >>>> >>> >>>> On that note, what is the reason for this permission change: >>> >>>> >>> >>>> - 'ipapermtargetfilter': [ >>> >>>> - '(objectclass=ipahost)', >>> >>>> - '(!(krbprincipalname=*))', >>> >>>> - ], >>> >>>> >>> >>>> ? >>> >>> >>> >>> Yes, this is exactly the change I was referring to. Permission >>> >>> changes within a plugin now translate automatically to ACI >>> >>> changes. Sorry I wasn't clearer. >>> >>> >>> >>> This ACI gets replaced with a much simpler one and I'm not 100% >>> >>> sure it will work with all enrollments: >>> >>> >>> >>> -aci: (targetattr = "krbprincipalname")(targetfilter = >>> >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version 3.0;acl >>> >>> "permission:System: Add krbPrincipalName to a Host";allow (write) >>> >>> groupdn = "ldap:///cn=System: Add krbPrincipalName to a >>> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> >>> >>> +aci: (targetattr = "krbprincipalname")(targetfilter = >>> >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Add >>> >>> krbPrincipalName to a Host";allow (write) groupdn = >>> >>> "ldap:///cn=System: Add krbPrincipalName to a >>> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) >>> >>> >>> >>> The first one restricts writing the attribute only if it isn't >>> >>> already set. The second lets it be changed unconditionally. >>> >> >>> >> Yeah this is wrong indeed, the point of the ACI is to allow >>> >> setting the principal only when it is not already set, which is >>> >> the OTP enrollment case. But if krbprincipal is set then this >>> >> specific permission should not grant rights to change it. >>> >> >>> >> At least this was my understanding. >>> >> >>> >> Simo. >>> > >>> > Right. It seems to me we should add keep this permission intact and >>> > add a new permission allowing adding krbPrincipalName aliases. This >>> > would allow writing both krbPrincipalName and krbCanonicalName. >>> > >>> > Martin >>> > >>> >>> Thank you all for explanation and help. I rewrote the patch so it >>> should work as requested now. Also I added tests to reassure the >>> behavior is correct. >> >> >> Sorry for not catching this earlier, but should we also add new IPA >> MODRDN configuration ? >> We currently change krbPrincipalName if the user uid changes. >> >> However perhaps what we should do is instead to allows aliases only for >> service/host principals but not for ipa users, at least for now. > I think it is sensible approach to limit aliases for service/host > principals only. Currently, David was only adding aliases for hosts - should we then expand the logic also for services? >> Should we also change permissions so that host/service entries >> *cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN >> configuration so that if a service/host krbprincipalname is changed >> then krbcanonicalname is too. > Yes, host/service shouldn't be renamed. Additionally, this would make > also their certificates "obsolete", in certain sense. Ok, this requirement will make it simpler. Here is the logic as I would see it: 1) Whenever an alias is added to existing service with the single krbPrincipalName, also krbCanonicalName is added targetting the original value, object is renamed to the CanonicalName. 2) Framework would prohibit changing the canonical name as that would always be the first name used when running host-add. (if someone does that via ldapmodify, that's their problem). >> Last but not least, and here I regret we may have a BIG issue, I just >> realize we use krbprincipalname in the Services DN, if we add >> additional values there does it mean we end up with a multivalued RDN ? > Unfortunately, this is what happens right now if you add more than one > krbprincipalname already. Things seem to work fine except you cannot > address such objects in Web UI and CLI. > >> That may be a problem, in such case should we rename services to use >> krbcanonicalname as the rnd instead ? We can do this in a compatible >> manner I think by renaming on the fly old entries if the still use >> krbprincipalname and changing our code to start always setting >> krbcanonicalname on new entries and set both canmonical and principal >> name on every new entry. > Sounds reasonable to me. BTW I now also hit https://fedorahosted.org/freeipa/ticket/3864 Simo, should we then do these changes in 4.1 given the schema may not be OK yet? Martin From mkosek at redhat.com Wed Sep 24 08:43:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 10:43:09 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure In-Reply-To: <53F76AB4.5000708@redhat.com> References: <53F76AB4.5000708@redhat.com> Message-ID: <5422841D.8080205@redhat.com> On 08/22/2014 06:07 PM, Petr Viktorin wrote: > 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? This works pretty nicely, I liked the service.py extension. My test output: # ipa-ldap-updater --upgrade Upgrading IPA: [1/10]: stopping directory server [2/10]: saving configuration [3/10]: disabling listeners [4/10]: starting directory server [5/10]: preparing server upgrade PRE_SCHEMA_UPDATE [6/10]: updating schema ... [7/10]: upgrading server [error] ValueError: Ha! [cleanup]: stopping directory server [cleanup]: restoring configuration # ipactl start # netstat -putna | grep 389 ... tcp6 0 0 10.16.78.147:389 10.16.78.147:37490 ESTABLISHED 5956/ns-slapd So I am willing to ACK if there are no other objections. Martin From mkosek at redhat.com Wed Sep 24 09:00:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 11:00:21 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 Message-ID: <54228825.4020900@redhat.com> Hello, I just rebuilt latest fixed pki-core&tomcat for our Copr (http://copr.fedoraproject.org/coprs/mkosek/freeipa/builds/). We are now very close to having a functional repo for RHEL/CentOS 7.0. With couple minor changes to the spec file, I was able to install FreeIPA 4.0.3 and it's dependencies to 7.0, ipa-server-install *almost* finished (client installation failed). I filed the remaining issues in https://fedorahosted.org/freeipa/ticket/4562 1. and 3, should be straightforward. However, I wonder about 2. Should FreeIPA Copr be in a business of building system selinux-policy for supported platforms? I personally think it shouldn't as otherwise different Coprs enabled on a system may clash with their system policies. I see 2 paths: 1) The better but very difficult one - for other platforms ship own SELinux policy with rules and changes that are missing in the oldest supported version SELinux policy and that cause AVCs with latest upstream FreeIPA. 2) The worse but easy: Change selinux-policy Requires so that it matches the oldest selinux-policy version and recommend people to run the Copr FreeIPA version with permissive SELinux. Thoughts? Thank you. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Wed Sep 24 10:06:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 12:06:56 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <54216CD9.80708@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> <54201041.2050201@redhat.com> <54216CD9.80708@redhat.com> Message-ID: <542297C0.5020108@redhat.com> On 09/23/2014 02:51 PM, Martin Basti wrote: > On 22/09/14 14:04, Petr Viktorin wrote: >> On 09/01/2014 04:31 PM, Martin Basti wrote: >>> On 24/07/14 09:06, Martin Basti wrote: >>>> On 23/07/14 15:17, Martin Basti wrote: >>>>> This patch fixes ordering problem of schema updates >>>>> >>>>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>>>> (will be in Fedora 21) >>>>> [...] > Thank you! > updated patch attached. ACK We should wait with pushing until the rebased ldap-python *is* in Fedora, or at least in a COPR. So far it's not even in Koji, AFAICS. -- Petr? From pvoborni at redhat.com Wed Sep 24 10:17:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Sep 2014 12:17:42 +0200 Subject: [Freeipa-devel] [PATCH] 757 webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types Message-ID: <54229A46.9040409@redhat.com> webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types They are not supported by API. -- Petr Vobornik From pspacek at redhat.com Wed Sep 24 11:30:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 24 Sep 2014 13:30:06 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <54228825.4020900@redhat.com> References: <54228825.4020900@redhat.com> Message-ID: <5422AB3E.9080209@redhat.com> On 24.9.2014 11:00, Martin Kosek wrote: > Hello, > > I just rebuilt latest fixed pki-core&tomcat for our Copr > (http://copr.fedoraproject.org/coprs/mkosek/freeipa/builds/). We are now very > close to having a functional repo for RHEL/CentOS 7.0. > > With couple minor changes to the spec file, I was able to install FreeIPA 4.0.3 > and it's dependencies to 7.0, ipa-server-install *almost* finished (client > installation failed). > > I filed the remaining issues in > https://fedorahosted.org/freeipa/ticket/4562 > > 1. and 3, should be straightforward. However, I wonder about 2. Should FreeIPA > Copr be in a business of building system selinux-policy for supported platforms? > > I personally think it shouldn't as otherwise different Coprs enabled on a > system may clash with their system policies. I see 2 paths: > > 1) The better but very difficult one - for other platforms ship own SELinux > policy with rules and changes that are missing in the oldest supported version > SELinux policy and that cause AVCs with latest upstream FreeIPA. > > 2) The worse but easy: Change selinux-policy Requires so that it matches the > oldest selinux-policy version and recommend people to run the Copr FreeIPA > version with permissive SELinux. 3) The most complicated but most flexible way: - Build a new selinux policy package in separate COPR - Let people chose if they want to run SELinux in permissive mode or rather install IPA-supplied policy package -- Petr^2 Spacek From jhrozek at redhat.com Wed Sep 24 11:38:54 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 24 Sep 2014 13:38:54 +0200 Subject: [Freeipa-devel] [PATCH] 129 ipa-kdb: fix unit tests In-Reply-To: <20140722152451.GS2158@localhost.localdomain> References: <20140722152451.GS2158@localhost.localdomain> Message-ID: <20140924113854.GD31763@hendrix.brq.redhat.com> On Tue, Jul 22, 2014 at 05:24:51PM +0200, Sumit Bose wrote: > Hi, > > it looks like the ipa-kdb unit test is broken. This patch tries to fix > it. > > bye, > Sumit ACK Without the patch, I got: ipa_kdb_tests-ipa_kdb_common.o: In function `ipadb_ldap_attr_has_value': /home/remote/jhrozek/devel/freeipa/daemons/ipa-kdb/ipa_kdb_common.c:531: undefined reference to `ulc_casecmp' ipa_kdb_tests-ipa_kdb_principals.o: In function `ipadb_find_principal': /home/remote/jhrozek/devel/freeipa/daemons/ipa-kdb/ipa_kdb_principals.c:778: undefined reference to `ulc_casecmp' ipa_kdb_tests-ipa_kdb_mspac.o: In function `ipadb_sign_authdata': /home/remote/jhrozek/devel/freeipa/daemons/ipa-kdb/ipa_kdb_mspac.c:2067: undefined reference to `ulc_casecmp' clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [ipa_kdb_tests] Error 1 make[1]: Leaving directory `/home/remote/jhrozek/devel/freeipa/daemons/ipa-kdb' make: *** [check-am] Error 2 The tests passes now: Testsuite summary for ipa-server 4.0.0GIT2563ea2 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ Why don't the tests run at build time by default? From pviktori at redhat.com Wed Sep 24 11:47:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 13:47:04 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <54219904.1040004@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> Message-ID: <5422AF38.8030209@redhat.com> On 09/23/2014 06:00 PM, Petr Spacek wrote: > On 22.9.2014 14:09, Petr Viktorin wrote: >> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>> On 22.9.2014 10:38, Martin Kosek wrote: >>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>> >>>>>>> See ticket & commit message for details. >>>>>> >>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>> version just >>>>>> hammer DNS server with as many DNS queries as it can send? >>>>> >>>>> Oh yes, please add some time.sleep() call :-) >> >> Wow, no idea how that slipped out. Thanks for the catch. >> >>>>> Also I would like to see more detailed message: >>>>> + self.log.info('Waiting for hostname %s to be resolvable', >>>>> + self.replica_fqdn) >>>>> >>>>> => 'Waiting for hostname %s to be resolvable to A or AAAA record' >>>> >>>> >>>> >>>> Really? Shouldn't term "resolvable" already have that covered? A good >>>> software >>>> should work on all network types, whether it is IPv4, IPv6 or IPv8. >>>> So I >>>> personally do not think we need to be that specific and can stick to >>>> original >>>> proposal. >>> >>> I will agree with you if you post magic code which will work with DNS >>> records for IPv8 :-) The code is not going to work with IPv8 just >>> because we didn't mention 'A/AAAA' in the error message, A and AAAA >>> RRtypes are hardcoded in the code. >> >> +1; we're checking A and AAAA so that's what we should say we're doing. >> >> Is this wording OK? > Little NACK. (However, the wording is fine.) > > Tcpdump revealed this: > > IP vm-117.test.34067 > vm-133.test.domain: 38467+ A? vm-092.test. (51) > IP vm-133.test.domain > vm-117.test.34067: 38467 NXDomain* 0/1/0 (116) > IP vm-117.test.36006 > vm-133.test.domain: 20194+ A? > vm-092.test.ipa.example. (63) > IP vm-133.test.domain > vm-117.test.36006: 20194 NXDomain* 0/1/0 (143) > IP vm-117.test.51333 > vm-133.test.domain: 34027+ AAAA? vm-092.test. (51) > IP vm-133.test.domain > vm-117.test.51333: 34027 NXDomain* 0/1/0 (116) > IP vm-117.test.60373 > vm-133.test.domain: 45679+ AAAA? > vm-092.test.ipa.example. (63) > > You can see that the query for each A/AAAA type is repeated twice, the > second time with 'ipa.example.' suffix. > > This is caused by search list processing (search directive in > /etc/resolv.conf) and is highly undesirable. (Read this [1] e-mail if > you want to hear it from Paul Vixie.) > > The fix is simple: You have to be sure that self.replica_fqdn is > actually absolute FQDN - with the trailing period. > > Naive solution would be to use > dns_answer = resolver.query(self.replica_fqdn + '.', 'A', 'IN') > but I don't know if self.replica_fqdn variable can contain trailing > period or not. > > Mbasti can show you more advanced code snippets using 'dns.name'. > > [1] > https://lists.dns-oarc.net/pipermail/dns-operations/2014-September/012157.html Does this version look good? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0645.3-ipa-replica-prepare-Wait-for-the-DNS-entry-to-be-res.patch Type: text/x-patch Size: 4117 bytes Desc: not available URL: From dkupka at redhat.com Wed Sep 24 11:50:47 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Sep 2014 13:50:47 +0200 Subject: [Freeipa-devel] [PATCH] JSON client: Log pretty-printed request and response with -vv or above In-Reply-To: <54218083.5070402@redhat.com> References: <542171F8.90501@redhat.com> <54218083.5070402@redhat.com> Message-ID: <5422B017.8060104@redhat.com> On 09/23/2014 04:15 PM, Petr Viktorin wrote: > On 09/23/2014 03:13 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4233 > > After talking to Rob, I've changed what the -v means a bit more: > > A single -v just turns on INFO logging, as before: > > $ ipa -v ping > ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json > ipa: INFO: Forwarding 'ping' to json server > 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' > ----------------------------------------------------- > IPA server version 4.0.0GIT8543d4c. API version 2.102 > ----------------------------------------------------- > > Two -v's pretty-print the request & response: > > $ ipa -vv ping > ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json > ipa: INFO: Forwarding 'ping' to json server > 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' > ipa: INFO: Request: { > "id": 0, > "method": "ping", > "params": [ > [], > { > "version": "2.102" > } > ] > } > ipa: INFO: Response: { > "error": null, > "id": 0, > "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", > "result": { > "summary": "IPA server version 4.0.0GIT8543d4c. API version 2.102" > }, > "version": "4.0.0GIT8543d4c" > } > ----------------------------------------------------- > IPA server version 4.0.0GIT8543d4c. API version 2.102 > ----------------------------------------------------- > > And three -v's print everything -- the pretty-printed JSON and all of > the HTTP communication. > > Also, when using XML-RPC, a single -v will now also print all the HTTP > stuff. It could respond to two -v's as before I don't think it's worth > complicating the code (keep in mind this is client only, XML-RPC is not > used unless requested in the env). > > This patch also updates the man page. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, thanks, ACK. -- David Kupka From pspacek at redhat.com Wed Sep 24 11:54:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 24 Sep 2014 13:54:53 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <5422AF38.8030209@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> <5422AF38.8030209@redhat.com> Message-ID: <5422B10D.6010303@redhat.com> On 24.9.2014 13:47, Petr Viktorin wrote: > On 09/23/2014 06:00 PM, Petr Spacek wrote: >> On 22.9.2014 14:09, Petr Viktorin wrote: >>> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>>> On 22.9.2014 10:38, Martin Kosek wrote: >>>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>>> >>>>>>>> See ticket & commit message for details. >>>>>>> >>>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>>> version just >>>>>>> hammer DNS server with as many DNS queries as it can send? >>>>>> >>>>>> Oh yes, please add some time.sleep() call :-) >>> >>> Wow, no idea how that slipped out. Thanks for the catch. >>> >>>>>> Also I would like to see more detailed message: >>>>>> + self.log.info('Waiting for hostname %s to be resolvable', >>>>>> + self.replica_fqdn) >>>>>> >>>>>> => 'Waiting for hostname %s to be resolvable to A or AAAA record' >>>>> >>>>> >>>>> >>>>> Really? Shouldn't term "resolvable" already have that covered? A good >>>>> software >>>>> should work on all network types, whether it is IPv4, IPv6 or IPv8. >>>>> So I >>>>> personally do not think we need to be that specific and can stick to >>>>> original >>>>> proposal. >>>> >>>> I will agree with you if you post magic code which will work with DNS >>>> records for IPv8 :-) The code is not going to work with IPv8 just >>>> because we didn't mention 'A/AAAA' in the error message, A and AAAA >>>> RRtypes are hardcoded in the code. >>> >>> +1; we're checking A and AAAA so that's what we should say we're doing. >>> >>> Is this wording OK? >> Little NACK. (However, the wording is fine.) >> >> Tcpdump revealed this: >> >> IP vm-117.test.34067 > vm-133.test.domain: 38467+ A? vm-092.test. (51) >> IP vm-133.test.domain > vm-117.test.34067: 38467 NXDomain* 0/1/0 (116) >> IP vm-117.test.36006 > vm-133.test.domain: 20194+ A? >> vm-092.test.ipa.example. (63) >> IP vm-133.test.domain > vm-117.test.36006: 20194 NXDomain* 0/1/0 (143) >> IP vm-117.test.51333 > vm-133.test.domain: 34027+ AAAA? vm-092.test. (51) >> IP vm-133.test.domain > vm-117.test.51333: 34027 NXDomain* 0/1/0 (116) >> IP vm-117.test.60373 > vm-133.test.domain: 45679+ AAAA? >> vm-092.test.ipa.example. (63) >> >> You can see that the query for each A/AAAA type is repeated twice, the >> second time with 'ipa.example.' suffix. >> >> This is caused by search list processing (search directive in >> /etc/resolv.conf) and is highly undesirable. (Read this [1] e-mail if >> you want to hear it from Paul Vixie.) >> >> The fix is simple: You have to be sure that self.replica_fqdn is >> actually absolute FQDN - with the trailing period. >> >> Naive solution would be to use >> dns_answer = resolver.query(self.replica_fqdn + '.', 'A', 'IN') >> but I don't know if self.replica_fqdn variable can contain trailing >> period or not. >> >> Mbasti can show you more advanced code snippets using 'dns.name'. >> >> [1] >> https://lists.dns-oarc.net/pipermail/dns-operations/2014-September/012157.html > > Does this version look good? LGTM except one nitpick I didn't see before: > + if not options.wait_for_dns or self.check_dns(replica_fqdn): > + self.log.debug('%s A/AAAA record resolvable', replica_fqdn) > + return This will print message '%s A/AAAA record resolvable', replica_fqdn even if I use switch --no-wait-for-dns This is sooo minor detail that it can be deferred, please open a ticket if you don't plan to send new version of the patch. -- Petr^2 Spacek From pviktori at redhat.com Wed Sep 24 11:55:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 13:55:40 +0200 Subject: [Freeipa-devel] [PATCHES] 0631-0632 Integration tests for backup & restore In-Reply-To: <542148D2.1000603@redhat.com> References: <53E23D75.2040005@redhat.com> <53E2411B.2010301@redhat.com> <542148D2.1000603@redhat.com> Message-ID: <5422B13C.2090707@redhat.com> On 09/23/2014 12:17 PM, Tomas Babej wrote: > > On 08/06/2014 04:52 PM, Petr Viktorin wrote: >> 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 >> >> > > Thank you for these patches, the tests themselves seem all right to me. > > My only objection is that I don't think that the coverage for the basic > backup-restore test is exhaustive enough. Right now we only check the > presence of the admin entry in the LDAP via raw ldap calls and CLI, and > the output of the cert-find command. > > In the future, I'd like this to be extended with basic functionality > tests for each of the services, i.e. does DNS work after the restore? > Are all the services up and running? > > However, this does not block the patches, I think they can be pushed now > (this means a ACK from me) in their current form and extended later. If > you agree, I can file a ticket. Thanks for the review. Pushed to: master: ccb91f5970537df6362ec7f41cded369b668e91a ipa-4-1: 5fc92d621b73afba4bf240b2e35f9160bfac0c44 You're right, this does need more tests. I'll get to writing more tests. I think we can just keep the ticket open for now. -- Petr? From pviktori at redhat.com Wed Sep 24 11:58:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 13:58:40 +0200 Subject: [Freeipa-devel] [PATCH] JSON client: Log pretty-printed request and response with -vv or above In-Reply-To: <5422B017.8060104@redhat.com> References: <542171F8.90501@redhat.com> <54218083.5070402@redhat.com> <5422B017.8060104@redhat.com> Message-ID: <5422B1F0.9090408@redhat.com> On 09/24/2014 01:50 PM, David Kupka wrote: > On 09/23/2014 04:15 PM, Petr Viktorin wrote: >> On 09/23/2014 03:13 PM, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/4233 >> >> After talking to Rob, I've changed what the -v means a bit more: >> >> A single -v just turns on INFO logging, as before: >> >> $ ipa -v ping >> ipa: INFO: trying https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json >> ipa: INFO: Forwarding 'ping' to json server >> 'https://vm-073.idm.lab.eng.brq.redhat.com/ipa/json' >> ----------------------------------------------------- >> IPA server version 4.0.0GIT8543d4c. API version 2.102 >> ----------------------------------------------------- >> >> Two -v's pretty-print the request & response: >> [...] >> >> And three -v's print everything -- the pretty-printed JSON and all of >> the HTTP communication. >> >> Also, when using XML-RPC, a single -v will now also print all the HTTP >> stuff. It could respond to two -v's as before I don't think it's worth >> complicating the code (keep in mind this is client only, XML-RPC is not >> used unless requested in the env). >> >> This patch also updates the man page. > > Works for me, thanks, ACK. Thanks! Pushed to: master: b7a6d7937efae894dad0c28759d01042b663ba30 ipa-4-1: 16ffb82195512bfba43b15e8f482a0d010c37bc1 -- Petr? From pviktori at redhat.com Wed Sep 24 12:03:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 14:03:01 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response In-Reply-To: <534EA4C8.4060308@redhat.com> References: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> <534EA4C8.4060308@redhat.com> Message-ID: <5422B2F5.7060501@redhat.com> On 04/16/2014 05:42 PM, Rob Crittenden wrote: > Misnyovszki Adam wrote: >> Hi, >> this patch enables logging json dumps of request and response, using >> the --log-payload switch in ipa cli. RFC tag is to ensure that I >> handled the --log-payload switch correctly in ipa cli. Be careful, it >> only logs, so --log-payload without -v switch doesn't make the dump >> visible in command line, -v does! >> >> https://fedorahosted.org/freeipa/ticket/4233 > > Not a NACK but using -vvv makes this a much simpler operation as you can > then just compare verbose >= 3. This seems like a lot of work just to > pretty-print some output. > > rob This patch has been superseded by my 0648 (commit b7a6d79). -- Petr? From pviktori at redhat.com Wed Sep 24 12:07:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Sep 2014 14:07:59 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <5422B10D.6010303@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> <5422AF38.8030209@redhat.com> <5422B10D.6010303@redhat.com> Message-ID: <5422B41F.8090408@redhat.com> On 09/24/2014 01:54 PM, Petr Spacek wrote: > On 24.9.2014 13:47, Petr Viktorin wrote: >> On 09/23/2014 06:00 PM, Petr Spacek wrote: >>> On 22.9.2014 14:09, Petr Viktorin wrote: >>>> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>>>> On 22.9.2014 10:38, Martin Kosek wrote: >>>>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>>>> >>>>>>>>> See ticket & commit message for details. >>>>>>>> >>>>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>>>> version just >>>>>>>> hammer DNS server with as many DNS queries as it can send? >>>>>>> [...] > > LGTM except one nitpick I didn't see before: > >> + if not options.wait_for_dns or self.check_dns(replica_fqdn): >> + self.log.debug('%s A/AAAA record resolvable', replica_fqdn) >> + return > > This will print message > '%s A/AAAA record resolvable', replica_fqdn > even if I use switch --no-wait-for-dns > > This is sooo minor detail that it can be deferred, please open a ticket > if you don't plan to send new version of the patch. You're right. Let's do it correctly now; this isn't worth the overhead of a ticket. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0645.4-ipa-replica-prepare-Wait-for-the-DNS-entry-to-be-res.patch Type: text/x-patch Size: 4127 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 24 12:32:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 14:32:00 +0200 Subject: [Freeipa-devel] [PATCH] 482 Update contributors Message-ID: <5422B9C0.3030904@redhat.com> Add missing developers contributing to project git. Cancel "Past and Occcasional" section and merge the people in the right categories. Update .mailmap so that the Developer list can be easily re-generated. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-482-update-contributors.patch Type: text/x-patch Size: 4246 bytes Desc: not available URL: From simo at redhat.com Wed Sep 24 13:15:26 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 24 Sep 2014 09:15:26 -0400 Subject: [Freeipa-devel] [PATCH] 0015-16 Allow multiple krbprincipalnames + test In-Reply-To: <54227F45.8080606@redhat.com> References: <541A95AA.70902@redhat.com> <541AE1D7.3000903@redhat.com> <541AE6F8.5020309@redhat.com> <541AEC03.9080304@redhat.com> <541B2B29.6060005@redhat.com> <20140918151155.52e96806@willson.usersys.redhat.com> <541B35A9.7010404@redhat.com> <542025C1.1050708@redhat.com> <20140922101648.5abe7031@willson.usersys.redhat.com> <20140922150203.GA11503@redhat.com> <54227F45.8080606@redhat.com> Message-ID: <20140924091526.00cbd8f2@willson.usersys.redhat.com> On Wed, 24 Sep 2014 10:22:29 +0200 Martin Kosek wrote: > On 09/22/2014 05:02 PM, Alexander Bokovoy wrote: > > On Mon, 22 Sep 2014, Simo Sorce wrote: > >> On Mon, 22 Sep 2014 15:36:01 +0200 > >> David Kupka wrote: > >> > >>> On 09/18/2014 09:42 PM, Martin Kosek wrote: > >>> > On 09/18/2014 09:11 PM, Simo Sorce wrote: > >>> >> On Thu, 18 Sep 2014 14:57:45 -0400 > >>> >> Rob Crittenden wrote: > >>> >> > >>> >>> Martin Kosek wrote: > >>> >>>> On 09/18/2014 04:06 PM, David Kupka wrote: > >>> >>>>> On 09/18/2014 03:44 PM, Rob Crittenden wrote: > >>> >>>>>> David Kupka wrote: > >>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4421 > >>> >>>>>> > >>> >>>>>> You are removing an ACI in this patch. It is always > >>> >>>>>> possible it is no longer needed. Did you test all the > >>> >>>>>> client enrollment scenarios? > >>> >>>>>> > >>> >>>>>> rob > >>> >>>>>> > >>> >>>>> > >>> >>>>> As far as I'm aware I'm not removing any ACI. I'm modifying > >>> >>>>> ACI so it is possible to add krbPrincipalName to host even > >>> >>>>> when there is already one (or more). And adding one ACI to > >>> >>>>> allow writing krbCanonicalName to host. But I'm still not > >>> >>>>> really familiar with ACI so please correct me if I'm wrong. > >>> >>>>> > >>> >>>> > >>> >>>> What refers to is probably the update in ACI.txt - the ACI > >>> >>>> alternative to API.txt. David updated an ACI, not removed it. > >>> >>>> > >>> >>>> On that note, what is the reason for this permission change: > >>> >>>> > >>> >>>> - 'ipapermtargetfilter': [ > >>> >>>> - '(objectclass=ipahost)', > >>> >>>> - '(!(krbprincipalname=*))', > >>> >>>> - ], > >>> >>>> > >>> >>>> ? > >>> >>> > >>> >>> Yes, this is exactly the change I was referring to. Permission > >>> >>> changes within a plugin now translate automatically to ACI > >>> >>> changes. Sorry I wasn't clearer. > >>> >>> > >>> >>> This ACI gets replaced with a much simpler one and I'm not > >>> >>> 100% sure it will work with all enrollments: > >>> >>> > >>> >>> -aci: (targetattr = "krbprincipalname")(targetfilter = > >>> >>> "(&(!(krbprincipalname=*))(objectclass=ipahost))")(version > >>> >>> 3.0;acl "permission:System: Add krbPrincipalName to a > >>> >>> Host";allow (write) groupdn = "ldap:///cn=System: Add > >>> >>> krbPrincipalName to a > >>> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> >>> > >>> >>> +aci: (targetattr = "krbprincipalname")(targetfilter = > >>> >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: > >>> >>> Add krbPrincipalName to a Host";allow (write) groupdn = > >>> >>> "ldap:///cn=System: Add krbPrincipalName to a > >>> >>> Host,cn=permissions,cn=pbac,dc=ipa,dc=example";) > >>> >>> > >>> >>> The first one restricts writing the attribute only if it isn't > >>> >>> already set. The second lets it be changed unconditionally. > >>> >> > >>> >> Yeah this is wrong indeed, the point of the ACI is to allow > >>> >> setting the principal only when it is not already set, which is > >>> >> the OTP enrollment case. But if krbprincipal is set then this > >>> >> specific permission should not grant rights to change it. > >>> >> > >>> >> At least this was my understanding. > >>> >> > >>> >> Simo. > >>> > > >>> > Right. It seems to me we should add keep this permission intact > >>> > and add a new permission allowing adding krbPrincipalName > >>> > aliases. This would allow writing both krbPrincipalName and > >>> > krbCanonicalName. > >>> > > >>> > Martin > >>> > > >>> > >>> Thank you all for explanation and help. I rewrote the patch so it > >>> should work as requested now. Also I added tests to reassure the > >>> behavior is correct. > >> > >> > >> Sorry for not catching this earlier, but should we also add new IPA > >> MODRDN configuration ? > >> We currently change krbPrincipalName if the user uid changes. > >> > >> However perhaps what we should do is instead to allows aliases > >> only for service/host principals but not for ipa users, at least > >> for now. > > I think it is sensible approach to limit aliases for service/host > > principals only. > > Currently, David was only adding aliases for hosts - should we then > expand the logic also for services? I expect aliases will be used almost exclusively with services not hosts. > >> Should we also change permissions so that host/service entries > >> *cannot* be renamed ? Otherwise we'd need to add again IAP MODRDN > >> configuration so that if a service/host krbprincipalname is changed > >> then krbcanonicalname is too. > > Yes, host/service shouldn't be renamed. Additionally, this would > > make also their certificates "obsolete", in certain sense. > > Ok, this requirement will make it simpler. Here is the logic as I > would see it: > > 1) Whenever an alias is added to existing service with the single > krbPrincipalName, also krbCanonicalName is added targetting the > original value, object is renamed to the CanonicalName. 1.1) change the framework to start creating new services using krbCanonicalName as RDN. > 2) Framework would prohibit changing the canonical name as that would > always be the first name used when running host-add. (if someone does > that via ldapmodify, that's their problem). We should just prevent modrdn in cn=services and cn=accounts by removing the ability to do so in existing permissions I think. > >> Last but not least, and here I regret we may have a BIG issue, I > >> just realize we use krbprincipalname in the Services DN, if we add > >> additional values there does it mean we end up with a multivalued > >> RDN ? > > Unfortunately, this is what happens right now if you add more than > > one krbprincipalname already. Things seem to work fine except you > > cannot address such objects in Web UI and CLI. > > > >> That may be a problem, in such case should we rename services to > >> use krbcanonicalname as the rnd instead ? We can do this in a > >> compatible manner I think by renaming on the fly old entries if > >> the still use krbprincipalname and changing our code to start > >> always setting krbcanonicalname on new entries and set both > >> canmonical and principal name on every new entry. > > Sounds reasonable to me. > > BTW I now also hit > > https://fedorahosted.org/freeipa/ticket/3864 > > Simo, should we then do these changes in 4.1 given the schema may not > be OK yet? Yes, I think we should resolve 3864 at the same time. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Wed Sep 24 13:23:54 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 24 Sep 2014 15:23:54 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140923151101.GE2947@localhost.localdomain> References: <20140923151101.GE2947@localhost.localdomain> Message-ID: <20140924132354.GF31763@hendrix.brq.redhat.com> On Tue, Sep 23, 2014 at 05:11:01PM +0200, Sumit Bose wrote: > Hi, > > this patch should fix https://fedorahosted.org/freeipa/ticket/4031 and > with the corresponding SSSD part it would be possible to get the full > list of group memberships with the id command even for user who didn't > log in before. > > bye, > Sumit So far I only read the patch, no testing was done yet (I'm installing a separate VM where I'll keep this new plugin for easy comparison and backwards-compatibility testing) First, there are some Coverity warnings: Error: USE_AFTER_FREE (CWE-825): freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:242: alias: Assigning: "groups" = "new_groups". Now both point to the same storage. freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:246: freed_arg: "free(void *)" frees "groups". freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:252: use_after_free: Using freed pointer "groups". Error: CONSTANT_EXPRESSION_RESULT (CWE-398): freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:596: missing_parentheses: "!id_type != SSS_ID_TYPE_GID" is always true regardless of the values of its operands. Did you intend to either negate the entire comparison expression, in which case parentheses would be required around the entire comparison expression to force that interpretation, or negate the sense of the comparison (that is, use '==' rather than '!=')? This occurs as the logical second operand of '||'. Error: DEADCODE (CWE-561): freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_single: Condition "request_type == 1U", taking false branch. Now the value of "request_type" cannot be equal to 1. freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_set: Condition "request_type == 3U", taking false branch. Now the value of "request_type" cannot be equal to any of {1, 3}. freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: cannot_set: At condition "request_type == 1U", the value of "request_type" cannot be equal to any of {1, 3}. freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: dead_error_condition: The condition "request_type == 1U" cannot be true. freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:607: dead_error_line: Execution cannot reach this statement "ret = pack_ber_sid(sid_str,...". See some comments inline. > From 23ff38cdea85995b211e73f474bcb4b0d7fb8039 Mon Sep 17 00:00:00 2001 > From: Sumit Bose > Date: Tue, 23 Sep 2014 15:55:43 +0200 > Subject: [PATCH] extdom: add support for new version > > Currently the extdom plugin is basically used to translate SIDs of AD > users and groups to names and POSIX IDs. > > With this patch a new version is added which will return the full member > list for groups and the full list of group memberships for a user. > Additionally the gecos field, the home directory and the login shell of a > user are returned and an optional list of key-value pairs which > currently will contain the SID of the requested object if available. > > https://fedorahosted.org/freeipa/ticket/4031 > --- > .../ipa-extdom-extop/ipa_extdom.h | 29 +- > .../ipa-extdom-extop/ipa_extdom_common.c | 850 +++++++++++++++------ > .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- > 3 files changed, 640 insertions(+), 267 deletions(-) > > diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > index 5f834a047a579104cd2589ce417c580c1c5388d3..548ee74f561c474854c049726c4c3e71da5cbbea 100644 > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > @@ -64,6 +64,7 @@ > #include > > #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" > +#define EXOP_EXTDOM_V2_OID "2.16.840.1.113730.3.8.10.4.1" It's a bit odd that this control is called V1 in the SSSD tree and V2 in the IPA tree. It's not wrong, just strange maybe. > > #define IPA_EXTDOM_PLUGIN_NAME "ipa-extdom-extop" > #define IPA_EXTDOM_FEATURE_DESC "IPA trusted domain ID mapper" > @@ -71,6 +72,11 @@ > > #define IPA_PLUGIN_NAME IPA_EXTDOM_PLUGIN_NAME > > +enum extdom_version { > + EXTDOM_V1 = 1, > + EXTDOM_V2 > +}; > + > enum input_types { > INP_SID = 1, > INP_NAME, > @@ -80,14 +86,17 @@ enum input_types { > > enum request_types { > REQ_SIMPLE = 1, > - REQ_FULL > + REQ_FULL, > + REQ_FULL_WITH_GROUPS > }; > > enum response_types { > RESP_SID = 1, > RESP_NAME, > RESP_USER, > - RESP_GROUP > + RESP_GROUP, > + RESP_USER_GROUPLIST, > + RESP_GROUP_MEMBERS > }; > > struct extdom_req { > @@ -123,11 +132,18 @@ struct extdom_res { > char *user_name; > uid_t uid; > gid_t gid; > + char *gecos; > + char *home; > + char *shell; > + size_t ngroups; > + char **groups; > } user; > struct { > char *domain_name; > char *group_name; > gid_t gid; > + size_t nmembers; > + char **members; > } group; > } data; > }; > @@ -150,15 +166,14 @@ struct pwd_grp { > struct passwd pwd; > struct group grp; > } data; > + int ngroups; > + gid_t *groups; > }; > > int parse_request_data(struct berval *req_val, struct extdom_req **_req); > void free_req_data(struct extdom_req *req); > +int check_request(struct extdom_req *req, enum extdom_version version); > int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > - struct extdom_res **res); > -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > - const char *sid_str, enum sss_id_type id_type, > - const char *domain_name, struct extdom_res **_res); > -void free_resp_data(struct extdom_res *res); > + struct berval **berval); > int pack_response(struct extdom_res *res, struct berval **ret_val); > #endif /* _IPA_EXTDOM_H_ */ > diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c > index 025d37dc5eda05c8db43d4e8176fd7898ed32fe7..5c1ae79c818676c3660d5cd5b8ca5515a4f0f18d 100644 > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c > @@ -70,6 +70,7 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) > * requestType ENUMERATED { > * simple (1), > * full (2) > + * full_with_groups (3) > * }, > * data InputData > * } > @@ -179,23 +180,23 @@ void free_req_data(struct extdom_req *req) > free(req); > } > > -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > - struct extdom_res **res) > +int check_request(struct extdom_req *req, enum extdom_version version) > +{ > + if (version == EXTDOM_V1) { > + if (req->request_type == REQ_FULL_WITH_GROUPS) { > + return LDAP_PROTOCOL_ERROR; > + } > + } Any particular reason why these conditions are nested and not and-ed ? Did you expect more under the EXTDOM_V1 condition? > + > + return LDAP_SUCCESS; > +} > + > +static int get_buffer(size_t *_buf_len, char **_buf) > { > - int ret; > - char *domain_name = NULL; > - char *sid_str = NULL; > - size_t buf_len; > - char *buf = NULL; > long pw_max; > long gr_max; > - struct pwd_grp pg_data; > - struct passwd *pwd_result = NULL; > - struct group *grp_result = NULL; > - enum sss_id_type id_type; > - char *fq_name = NULL; > - char *sep; > - > + size_t buf_len; > + char *buf; > > pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); > gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); > @@ -211,302 +212,655 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > return LDAP_OPERATIONS_ERROR; > } > > - switch (req->input_type) { > - case INP_POSIX_UID: > - if (req->request_type == REQ_SIMPLE) { > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > - &id_type); > + *_buf_len = buf_len; > + *_buf = buf; > + > + return LDAP_SUCCESS; > +} > + > +static int get_user_grouplist(const char *name, gid_t gid, > + size_t *_ngroups, gid_t **_groups ) > +{ > + int ret; > + int ngroups; > + gid_t *groups; > + gid_t *new_groups; > + > + ngroups = 128; I was wondering whether to use _SC_NGROUPS_MAX or NGROUPS_MAX here, but I guess you're right it's very unlikely that a user will be a member of more than 128 groups so we'd just clinge to more memory than needed.. > + groups = malloc(ngroups * sizeof(gid_t)); > + if (groups == NULL) { > + return LDAP_OPERATIONS_ERROR; > + } > + > + ret = getgrouplist(name, gid, groups, &ngroups); > + if (ret == -1) { > + new_groups = realloc(groups, ngroups); > + if (new_groups == NULL) { > + free(groups); > + return LDAP_OPERATIONS_ERROR; > + } > + groups = new_groups; > + > + ret = getgrouplist(name, gid, groups, &ngroups); > + if (ret == -1) { > + free(groups); > + ret = LDAP_OPERATIONS_ERROR; > + } > + } > + > + *_ngroups = ngroups; > + *_groups = groups; > + > + return LDAP_SUCCESS; > +} > + > +static int pack_ber_sid(const char *sid, struct berval **berval) > +{ > + BerElement *ber = NULL; > + int ret; > + > + ber = ber_alloc_t( LBER_USE_DER ); > + if (ber == NULL) { > + return LDAP_OPERATIONS_ERROR; > + } > + > + ret = ber_printf(ber,"{es}", RESP_SID, sid); > + if (ret == -1) { > + ber_free(ber, 1); > + return LDAP_OPERATIONS_ERROR; > + } > + > + ret = ber_flatten(ber, berval); > + ber_free(ber, 1); > + if (ret == -1) { > + return LDAP_OPERATIONS_ERROR; > + } > + > + return LDAP_SUCCESS; > +} > + > +#define SSSD_SYSDB_SID_STR "objectSIDString" > + > +static int pack_ber_user(const char *domain_name, const char *user_name, > + uid_t uid, gid_t gid, > + const char *gecos, const char *homedir, > + const char *shell, const char *sid_str, > + struct berval **berval) > +{ > + BerElement *ber = NULL; > + int ret; > + enum response_types response_type; > + size_t ngroups; > + gid_t *groups = NULL; > + size_t buf_len; > + char *buf = NULL; > + struct group grp; > + struct group *grp_result; > + size_t c; > + char *locat; > + char *short_user_name = NULL; > + const char *single_value_string_array[] = {NULL, NULL}; > + > + if (gecos == NULL && homedir == NULL && shell == NULL) { > + response_type = RESP_USER; > + } else { > + response_type = RESP_USER_GROUPLIST; > + } > + > + short_user_name = strdup(user_name); > + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { Some functions in the code use strchr to fund the at-sign, some use strrch. Could we standardize on one or the other? Do you expect some usernames with an at-sign in them? > + if (strcasecmp(locat+1, domain_name) == 0 ) { > + locat[0] = '\0'; > } else { > - id_type = SSS_ID_TYPE_UID; > - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, > - buf_len, &pwd_result); > + ret = LDAP_NO_SUCH_OBJECT; > + goto done; > } > + } > > - domain_name = strdup(req->data.posix_uid.domain_name); > - break; > - case INP_POSIX_GID: > - if (req->request_type == REQ_SIMPLE) { > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > - &id_type); > + ber = ber_alloc_t( LBER_USE_DER ); > + if (ber == NULL) { > + return LDAP_OPERATIONS_ERROR; > + } > + > + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, > + uid, gid); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + if (response_type == RESP_USER_GROUPLIST) { > + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); > + if (ret != LDAP_SUCCESS) { > + goto done; > + } > + > + ret = get_buffer(&buf_len, &buf); > + if (ret != LDAP_SUCCESS) { > + goto done; > + } > + > + ret = ber_printf(ber,"sss", gecos, homedir, shell); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + ret = ber_printf(ber,"{"); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + for (c = 0; c < ngroups; c++) { > + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); > + if (ret != 0) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + if (grp_result == NULL) { > + ret = LDAP_NO_SUCH_OBJECT; > + goto done; I wanted to check if you think it's better to continue or fail here. Did you opt for failing because you were afraid of missing some deny access checks in case we couldn't resolv a group? > + } > + > + ret = ber_printf(ber, "s", grp.gr_name); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + } > + > + ret = ber_printf(ber,"}"); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + single_value_string_array[0] = sid_str; > + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, > + single_value_string_array); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + } > + > + ret = ber_printf(ber,"}}"); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + ret = ber_flatten(ber, berval); > + if (ret == -1) { > + ret = LDAP_OPERATIONS_ERROR; > + goto done; > + } > + > + ret = LDAP_SUCCESS; > +done: > + free(short_user_name); > + free(groups); > + free(buf); > + ber_free(ber, 1); > + return ret; > +} > + > +static int pack_ber_group(const char *domain_name, const char *group_name, > + gid_t gid, char **members, const char *sid_str, > + struct berval **berval) > +{ > + BerElement *ber = NULL; > + int ret; > + size_t c; > + char *locat; > + char *short_group_name = NULL; > + const char *single_value_string_array[] = {NULL, NULL}; > + > + short_group_name = strdup(group_name); > + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > + if (strcasecmp(locat+1, domain_name) == 0 ) { > + locat[0] = '\0'; > } else { > - id_type = SSS_ID_TYPE_GID; > - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, > - buf_len, &grp_result); > + ret = LDAP_NO_SUCH_OBJECT; > + goto done; > } > + } > > - domain_name = strdup(req->data.posix_gid.domain_name); > - break; > - case INP_SID: > - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); > - if (ret != 0) { > + ber = ber_alloc_t( LBER_USE_DER ); > + if (ber == NULL) { > + return LDAP_OPERATIONS_ERROR; > + } > + > + ret = ber_printf(ber,"{e{ssi", members == NULL ? RESP_GROUP > + : RESP_GROUP_MEMBERS, Each pack_ber_group is called like this: 718 if (request_type == REQ_FULL) { 719 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, 720 NULL, NULL, berval); 721 } else { 722 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, 723 grp.gr_mem, sid, berval); 724 } And then you guess the request_type again based on the parameter values. Isn't it safer to add the request type parameter avoid the if-else switch in the callers? Or were you trying to be on the safe side to avoid checking the validity members array in the pack_ber_group function and have the array set to NULL by the caller? The rest of the file looks to me, just the same "issue" with guessing the request type is repeated. From pvoborni at redhat.com Wed Sep 24 13:26:07 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Sep 2014 15:26:07 +0200 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <54222FC3.8080508@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> Message-ID: <5422C66F.3000109@redhat.com> On 24.9.2014 04:43, Endi Sukma Dewata wrote: > On 9/22/2014 9:49 AM, Petr Vobornik wrote: >> [PATCH] webui-ci: case-insensitive record check >> >> Indirect association are no longer lower cased, which caused a issue >> in CI. > > Is the use of "|=" operator intentional? I don't see the "has" variable > defined anywhere else in this method. > > has |= self.has_record(pkey.lower(), parent, table_name) > > If this has been tested to work, then ACK. > it's defined on the previous line: has = self.has_record(pkey, parent, table_name) has |= self.has_record(pkey.lower(), parent, table_name) -- Petr Vobornik From dkupka at redhat.com Wed Sep 24 13:44:47 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Sep 2014 15:44:47 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5421BB0B.9050500@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> Message-ID: <5422CACF.7020406@redhat.com> On 09/23/2014 08:25 PM, Martin Basti wrote: > On 23/09/14 13:23, David Kupka wrote: >> On 09/18/2014 06:34 PM, Martin Basti wrote: >>> ... >>> 1) >>> + if options.unattended: >>> + for ip in ip_addresses: >>> + if search_reverse_zones and find_reverse_zone(str(ip)): >>> + # reverse zone is already in LDAP >>> + continue >>> + for rz in ret_reverse_zones: >>> + if verify_reverse_zone(rz, ip): >>> + # reverse zone was entered by user >>> + break >>> + else: >>> + rz = get_reverse_zone_default(str(ip)) >>> + ret_reverse_zones.append(rz) >>> + elif options.reverse_zones or create_reverse(): >>> + for ip in ip_addresses: >>> + if search_reverse_zones and find_reverse_zone(str(ip)): >>> + # reverse zone is already in LDAP >>> + continue >>> + for rz in ret_reverse_zones: >>> + if verify_reverse_zone(rz, ip): >>> + # reverse zone was entered by user >>> + break >>> + else: >>> + rz = get_reverse_zone_default(str(ip)) >>> + rz = read_reverse_zone(rz, str(ip)) >>> + ret_reverse_zones.append(rz) >>> + else: >>> + options.no_reverse = True >>> + ret_reverse_zones = [] >>> >>> You can make it shorter without duplications: >>> >>> # this ifs can be in one line >>> if not options.unatended: >>> if not options.reverse_zones >>> if not create_reverse(): >>> options.no_reverse=True >>> return [] >>> >>> for ip in ip_addresses: >>> if search_reverse_zones and find_reverse_zone(str(ip)): >>> # reverse zone is already in LDAP >>> continue >>> for rz in ret_reverse_zones: >>> if verify_reverse_zone(rz, ip): >>> # reverse zone was entered by user >>> break >>> else: >>> rz = get_reverse_zone_default(str(ip)) >>> if not options.unattended: >>> rz = read_reverse_zone(rz, str(ip)) >>> ret_reverse_zones.append(rz) >>> >> >> Thanks, I modified it bit different way to alse address recommendation >> 3). >> >>> >>> 2) >>> Typo? There is no IP address matching reverze_zone %s." >>> ---------------------------------------------^^ >>> >> >> Thanks, fixed. >> >>> >>> 3) >>> Would be nice to ask user to create new zones only if new zones are >>> required. (If all required zones exist in LDAP, you ask user anyway) >>> >> >> I added one more variable and ask only once. >> >>> 4) >>> Ask framework gurus, if installutils module is better place for function >>> above >>> >>> >> >> Petr^3 said that it's ok to have it in bindinstance.py. >> >>> >> > NACK, most important point is 7 > > 1) > I'm not sure if this is bug, but interactively is allowed to add only > one ip address > > Unable to resolve IP address for host name > Please provide the IP address to be used for this host name: 2001:db8::2 > The kerberos protocol requires a Realm name to be defined. > For the sake of infinite usability and UX I rewrote it to ask for multiple addresses the same way as for DNS forwarders. Also I really simplified IP address checking code when I was in it. I tested it but please look at it carefully. Also I found that ipa-dns-install and ipa-adtrust-install also accept --ip-address param. So I modified ipa-dns-install in the same way as ipa-server-install and ipa-replica-install. After discussion with tbabej I decided to dont touch ipa-adtrust-install now as it do not use specified value at all. I will remove the processing code and mark the param as deprecated in separate patch. > 2) > I'm getting error message > > Invalid reverse zone 10.in-addr.arpa. for IP address 2001:db8::dead:beef > Invalid reverse zone 10.in-addr.arpa. for IP address > fed0:babe:baab:0:21a:4aff:fe10:4e18 > > - or - > > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name > [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: > Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP > address fed0:babe:baab:0:21a:4aff:fe10:4e18 > Please specify the reverse zone name > [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: > Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., > 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. > > This shouldn't be there Moved the message to function used when installation is attended by user. > > Could be better to ask user to specific zone for ip address a.b.c.d. Probably, but lets leave some work for future. > > 4) just nitpick > The IPA Master Server will be configured with: > ... > IP address(es): 2001:db8::dead:beef, fed0:babe:baab:0:21a:4aff:fe10:4e18 > ... > Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., > 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. > > You have label "IP address(es)", so you should use label "Reverse zone(s)" > Fixed. > 5) > ipa-server-install --ip-address=10.16.78.105 > --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. > --setup-dns > > Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not sure > if this is wrong, but we prevents user to add zone without address in > it, so we should prevents, to add empty zone. > It would be nice but not in this patch. > 6) > ipa-replica-prepare --ip-address 10.16.78.105 --ip-address > 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. vm-105.example.com > Directory Manager (existing master) password: > > Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 > Invalid reverse zone 1.0.0.2.ip6.arpa. > > IMO This should work, right? > > + sys.exit("There is no IP address matching reverse zone > %s." % rz) > I expected at least this error to be shown. Fixed, thanks. > > 7) > ipa-replica-prepare --ip-address 10.16.78.105 --ip-address > 2001:db8::dead:beef vm-105.example.com > Directory Manager (existing master) password: > > ....... > Adding DNS records for vm-105.example.com > Values instance has no attribute 'ip_address' > > Command returns the attribute error. > It fails with one --ip-address too. > Sorry, fixed. > > *) Not related with your patch > Problem with installation: > I'm getting message: > IPA server is already configured on this system. > Even if I validation wasn't successful and installation was aborted. > > IPA install detects previous installations by checking state file and > restore files. Function get_server_ip_address() stores some data and > hosts file and modify the host file, before user agreed installation. > This error was there before your patch. > https://fedorahosted.org/freeipa/ticket/4561 > > > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-9-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 44224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-9-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 44204 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 24 14:05:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 16:05:36 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <54219587.4020600@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> Message-ID: <5422CFB0.6000702@redhat.com> On 23/09/14 17:45, Petr Vobornik wrote: > On 25.8.2014 14:52, Martin Basti wrote: >> 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 >> >> > > Review of: > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html > > 1. Please follow pep8 for the new code. > # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 > Produces 25 erros. > > Only E124 and E128 could be ignored if they are part of old code. I left there some pep8 errors. They don't decrease readability > > Patch 120: > > 3. This patch uses term 'deprecated' in a different meaning than a > DeprecatedParam. It creates inconsistency -> future confusion. IMHO > this usage is correct since the usual understanding of deprecation is > that the param is still usable but user should be prepared that it > will be removed in a future. IMHO DeprecatedParam is badly designed > but that's not an issue of this patch. > > I think we can leave this as is and create a ticket to rename > DeprecatedParam e.g. to RemovedParam. What do you think? > https://fedorahosted.org/freeipa/ticket/4566 > 5. You've removed 'idnssoamname' and 'force' from Web UI but > dnszone-add precallback still uses these params. What is the intended > purpose? User should use modify dialog in webUI for zones. Precallback fills default value for idnsmname from LDAP. with --force there will be no validation of user specified soa mname Purpose is a user should let IPA to fill mname with safe value. > Patch 123: > > 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' shouldn't > it be normalized to contain '.' at the end? Or is it handled by > bind-dyndb-ldap? Zone manager (SOA RNAME) can eb relative name, BIND will append zone name. Currently we cant validate if email address is reachable, it doestn matter if it is filled with nonexistent absolute name, or nonexistent relative name. > Unrelated to this patch set: > > a. One is able to run: > # ipa dnszone-remove-permission $zone > multiple times and it always returns success > > Is it intentional? No, it isn't. I will inspect it and I will send additional patch > > b. Web UI doesn't have means to call dnszone-mod with --force option I'm not sure what you mean, it didn't do that before my patches. Updated patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114.4-Fix-DNS-plugin-to-allow-to-add-root-zone.patch Type: text/x-patch Size: 4993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0115.4-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4541 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120.4-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 17019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121.4-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0123.4-DNS-autofill-admin-email.patch Type: text/x-patch Size: 7904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0124.4-WebUI-DNS-Remove-ip-address-admin-email-options.patch Type: text/x-patch Size: 4444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0125.4-DNS-tests-tests-update-to-due-to-change-in-options.patch Type: text/x-patch Size: 62301 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 24 14:07:44 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 16:07:44 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <5421A587.3020502@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> <5421A154.4090304@redhat.com> <5421A587.3020502@redhat.com> Message-ID: <5422D030.4030708@redhat.com> On 23/09/14 18:53, Martin Basti wrote: > On 23/09/14 18:35, Petr Spacek wrote: >> On 22.9.2014 19:21, Martin Basti wrote: >>> On 22/09/14 13:17, Petr Vobornik wrote: >>>> On 19.9.2014 16:15, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >>>>> Patch attached. >>>>> >>>> >>>> Patch 126: >>>> >>>> 1. I think that just >>>> DeprecatedParam('dnsclass?'), >>>> >>>> should be enough. >>>> >>>> Also >>>> >>>> 2. You forgot to update API.txt and VERSION >>>> >>>> Patch 127: >>>> ACK >>>> >>> Updated patchset attached >> >> ACK, it works for me. >> > Please don't push, we discuss this and we will nit use the > DeprecatedParam. > Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0126.3-DNS-remove-class-option.patch Type: text/x-patch Size: 2239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0127.3-WebUI-DNS-remove-class-option.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From edewata at redhat.com Wed Sep 24 14:16:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Sep 2014 09:16:52 -0500 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <5422C66F.3000109@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> Message-ID: <5422D254.4040807@redhat.com> On 9/24/2014 8:26 AM, Petr Vobornik wrote: > On 24.9.2014 04:43, Endi Sukma Dewata wrote: >> On 9/22/2014 9:49 AM, Petr Vobornik wrote: >>> [PATCH] webui-ci: case-insensitive record check >>> >>> Indirect association are no longer lower cased, which caused a issue >>> in CI. >> >> Is the use of "|=" operator intentional? I don't see the "has" variable >> defined anywhere else in this method. >> >> has |= self.has_record(pkey.lower(), parent, table_name) >> >> If this has been tested to work, then ACK. >> > > it's defined on the previous line: > > has = self.has_record(pkey, parent, table_name) > has |= self.has_record(pkey.lower(), parent, table_name) Ah, I see. I thought the old line was being replaced. ACK. -- Endi S. Dewata From mbasti at redhat.com Wed Sep 24 14:24:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 16:24:52 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5422CFB0.6000702@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> Message-ID: <5422D434.4090800@redhat.com> On 24/09/14 16:05, Martin Basti wrote: > On 23/09/14 17:45, Petr Vobornik wrote: >> On 25.8.2014 14:52, Martin Basti wrote: >>> 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 >>> >>> >> >> Review of: >> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >> >> >> 1. Please follow pep8 for the new code. >> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >> Produces 25 erros. >> >> Only E124 and E128 could be ignored if they are part of old code. > > I left there some pep8 errors. They don't decrease readability > >> >> Patch 120: >> >> 3. This patch uses term 'deprecated' in a different meaning than a >> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >> this usage is correct since the usual understanding of deprecation is >> that the param is still usable but user should be prepared that it >> will be removed in a future. IMHO DeprecatedParam is badly designed >> but that's not an issue of this patch. >> >> I think we can leave this as is and create a ticket to rename >> DeprecatedParam e.g. to RemovedParam. What do you think? >> > https://fedorahosted.org/freeipa/ticket/4566 >> 5. You've removed 'idnssoamname' and 'force' from Web UI but >> dnszone-add precallback still uses these params. What is the intended >> purpose? > User should use modify dialog in webUI for zones. > Precallback fills default value for idnsmname from LDAP. > with --force there will be no validation of user specified soa mname > > Purpose is a user should let IPA to fill mname with safe value. >> Patch 123: >> >> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >> shouldn't it be normalized to contain '.' at the end? Or is it >> handled by bind-dyndb-ldap? > > Zone manager (SOA RNAME) can eb relative name, BIND will append zone > name. > Currently we cant validate if email address is reachable, it doestn > matter if it is filled with nonexistent absolute name, or nonexistent > relative name. > >> Unrelated to this patch set: >> >> a. One is able to run: >> # ipa dnszone-remove-permission $zone >> multiple times and it always returns success >> >> Is it intentional? > No, it isn't. I will inspect it and I will send additional patch > >> >> b. Web UI doesn't have means to call dnszone-mod with --force option > I'm not sure what you mean, it didn't do that before my patches. > > Updated patches attached > I accidentally removed one line in previous patchset. Updated patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114.4-Fix-DNS-plugin-to-allow-to-add-root-zone.patch Type: text/x-patch Size: 4993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0115.4-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4541 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120.4-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 17019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121.5-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0123.4-DNS-autofill-admin-email.patch Type: text/x-patch Size: 7904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0124.4-WebUI-DNS-Remove-ip-address-admin-email-options.patch Type: text/x-patch Size: 4444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0125.4-DNS-tests-tests-update-to-due-to-change-in-options.patch Type: text/x-patch Size: 62301 bytes Desc: not available URL: From edewata at redhat.com Wed Sep 24 14:30:41 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Sep 2014 09:30:41 -0500 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <541C2199.8010404@redhat.com> References: <541C2199.8010404@redhat.com> Message-ID: <5422D591.4070000@redhat.com> On 9/19/2014 7:29 AM, Petr Vobornik wrote: > Hello, > > attached patches implements Web UI part of ID Views. Backend is > currently on review as well - thread "[PATCHES 247-259] ID views - > management part". > > https://fedorahosted.org/freeipa/ticket/4535 > > I expect that backed can change and that the UI might influence it as > well. Therefore no UI integration tests nor static data files are > included in this patchset. They will follow when backend is stable. > > First 5 patches extends UI framework to support the main patch (#754). > > > == [PATCH] 749 webui: improve breadcrumb navigation == > > Fixes issue when: > - user navigates to a nested facet > - refreshes browser > - uses breadcrumb navigation to go to parent entity page which requires > a pkey. E.g. from automount keys to maps. > > The old code relies on the facet, that user visited the parent facet > before and therefore the facet has pkey stored. It fails after the > browser reload. > > Allows to specify a containing_facet. It allows breadcrumb navigation to > return to a different facet than the 'default'. ACK. > == [PATCH] 750 webui: treat value as pkey in link widget == > > Current default mechanism of a link widget assumes that pkeys of a > current facet are pkeys for the link. It works for the only usage - in > password policy. It's rather inflexible since it can't be used if the > keys are in other attribute. This behavior is also bad in nested > entities - creates a link to itself which is pointless. > > This patch changes the default behavior to assume that the supplied > value are the pkeys and that the last pkey is the value to display. > > It also keeps the old method of overriding `other_pkeys` method so if > the last and only pkey is the actual value to display then the method > can tranform it into the pkeys which keeps compatibility with descendant > widgets (`host_dnsrecord_entity_link_widget`, > `dnsrecord_host_link_widget`). ACK. > == [PATCH] 751 webui: do not show internal facet name to user == ACK. > == [PATCH] 752 webui: allow to skip link widget link validation == ACK. > == [PATCH] 753 webui: add simple link column suppor == > > Usual link columns are link with primary key of current entity. > > This patch allows to create a link to arbitrary non-nested entity. ACK. > == [PATCH] 754 webui: new ID views section == I'll test this separately. Does your patch #754-1 work with Tomas' latest patches (#247-2 - 270)? -- Endi S. Dewata From pvoborni at redhat.com Wed Sep 24 14:43:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Sep 2014 16:43:59 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <5422D591.4070000@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> Message-ID: <5422D8AF.6070300@redhat.com> On 24.9.2014 16:30, Endi Sukma Dewata wrote: > On 9/19/2014 7:29 AM, Petr Vobornik wrote: >> Hello, >> >> attached patches implements Web UI part of ID Views. Backend is >> currently on review as well - thread "[PATCHES 247-259] ID views - >> management part". >> >> https://fedorahosted.org/freeipa/ticket/4535 >> >> I expect that backed can change and that the UI might influence it as >> well. Therefore no UI integration tests nor static data files are >> included in this patchset. They will follow when backend is stable. >> snip > >> == [PATCH] 754 webui: new ID views section == > > I'll test this separately. Does your patch #754-1 work with Tomas' > latest patches (#247-2 - 270)? > It was tested with tomas' git branch which matched http://www.redhat.com/archives/freeipa-devel/2014-September/msg00336.html -- Petr Vobornik From mkosek at redhat.com Wed Sep 24 14:47:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 16:47:01 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <5422D030.4030708@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> <5421A154.4090304@redhat.com> <5421A587.3020502@redhat.com> <5422D030.4030708@redhat.com> Message-ID: <5422D965.30603@redhat.com> On 09/24/2014 04:07 PM, Martin Basti wrote: > On 23/09/14 18:53, Martin Basti wrote: >> On 23/09/14 18:35, Petr Spacek wrote: >>> On 22.9.2014 19:21, Martin Basti wrote: >>>> On 22/09/14 13:17, Petr Vobornik wrote: >>>>> On 19.9.2014 16:15, Martin Basti wrote: >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >>>>>> Patch attached. >>>>>> >>>>> >>>>> Patch 126: >>>>> >>>>> 1. I think that just >>>>> DeprecatedParam('dnsclass?'), >>>>> >>>>> should be enough. >>>>> >>>>> Also >>>>> >>>>> 2. You forgot to update API.txt and VERSION >>>>> >>>>> Patch 127: >>>>> ACK >>>>> >>>> Updated patchset attached >>> >>> ACK, it works for me. >>> >> Please don't push, we discuss this and we will nit use the DeprecatedParam. >> > Updated patch attached Just a nitpick - I think these 2 patches would also be squashed - I did not see a point in dividing the changes there... Not a blocker, just sayin'. Martin From mbasti at redhat.com Wed Sep 24 14:55:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 16:55:35 +0200 Subject: [Freeipa-devel] [PATCH 0128] dnszone-remove-permission should raise NotFound if permission doesn't exist Message-ID: <5422DB67.5070908@redhat.com> Patch attached This probably should go to 4.0.x, 4.1 and master -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0128-FIX-dnszone-remove-permission-should-raise-error.patch Type: text/x-patch Size: 975 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 24 15:30:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 17:30:52 +0200 Subject: [Freeipa-devel] [PATCH 0128] dnszone-remove-permission should raise NotFound if permission doesn't exist In-Reply-To: <5422DB67.5070908@redhat.com> References: <5422DB67.5070908@redhat.com> Message-ID: <5422E3AC.2000208@redhat.com> On 09/24/2014 04:55 PM, Martin Basti wrote: > Patch attached > > This probably should go to 4.0.x, 4.1 and master It is obvious that this interface was designed this way. So you should elaborate more on the "should" part, list use cases where current approach does not work, link to tickets, ... From tbordaz at redhat.com Wed Sep 24 16:02:24 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 24 Sep 2014 18:02:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <53EE7049.3050605@redhat.com> References: <53EE7049.3050605@redhat.com> Message-ID: <5422EB10.3030305@redhat.com> On 08/15/2014 10:40 PM, Petr Viktorin wrote: > 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. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The first patch looks good to me. Just a minor comment. The test and run of 'paths.SELINUXENABLED' is present several times in tasks.py and fedora. Does it worth to refactor it ? About the second patch, something I do not understand. restore_selinux_booleans resets the selinux boolean to the values that are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . Does that mean this dict has been updated with the original values (using 'backup_func' in set_selinux_booleans ?). thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Sep 24 16:13:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Sep 2014 18:13:21 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes Message-ID: <5422EDA1.4060004@redhat.com> Hi, the attached patches fix and . (Note that design page for this is TBD.) Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-336-Add-NSSDatabase.import_files-method-for-importing-fi.patch Type: text/x-patch Size: 8290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-337-External-CA-installer-options-usability-fixes.patch Type: text/x-patch Size: 23039 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-338-CA-less-installer-options-usability-fixes.patch Type: text/x-patch Size: 40256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-339-Allow-choosing-CA-less-server-certificates-by-name.patch Type: text/x-patch Size: 9511 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Sep 24 16:19:04 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 24 Sep 2014 18:19:04 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <54228825.4020900@redhat.com> References: <54228825.4020900@redhat.com> Message-ID: <20140924161904.GB16438@redhat.com> On Wed, Sep 24, 2014 at 11:00:21AM +0200, Martin Kosek wrote: > > I just rebuilt latest fixed pki-core&tomcat for our Copr > (http://copr.fedoraproject.org/coprs/mkosek/freeipa/builds/). We are now very > close to having a functional repo for RHEL/CentOS 7.0. > > With couple minor changes to the spec file, I was able to install FreeIPA 4.0.3 What will be the content of these yum repos going forward? Will they be fixated at 4.0.3, or will they always contain the latest greatest release? Would it make sense to create one copr repo per release, versioned, so that even when 4.0.4 or 4.1.0 is out, the 4.0.3 content is still available? I'd like to use these yum repos for Docker images and I wonder what naming I should use for the branches and tags -- centos-7-upstream, centos-7-4.0.3, or something else? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Wed Sep 24 16:22:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 18:22:07 +0200 Subject: [Freeipa-devel] [PATCH 0128] dnszone-remove-permission should raise NotFound if permission doesn't exist In-Reply-To: <5422E3AC.2000208@redhat.com> References: <5422DB67.5070908@redhat.com> <5422E3AC.2000208@redhat.com> Message-ID: <5422EFAF.9070905@redhat.com> On 24/09/14 17:30, Martin Kosek wrote: > On 09/24/2014 04:55 PM, Martin Basti wrote: >> Patch attached >> >> This probably should go to 4.0.x, 4.1 and master > It is obvious that this interface was designed this way. So you should > elaborate more on the "should" part, list use cases where current approach does > not work, link to tickets, ... > > Sorry for that, I though I broke it during refactoring. -- Martin Basti From jcholast at redhat.com Wed Sep 24 17:39:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Sep 2014 19:39:14 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5421BE54.8050802@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> Message-ID: <542301C2.5060200@redhat.com> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Hi, >> >> the attached patches fix various bugs and shortcomings in the CA >> management and renewal code. Related tickets: >> , >> . >> >> (Patch 319 was originally posted at >> .) > > Only two of the patches includes what ticket(s) they address. Most have > the tersest of commit messages. If got more and more difficult to see > why the changes were needed at all, as you'll see. Sorry, fixed (hopefully). Note that most of these patches fix stuff I didn't have time to fix before I posted the original CA management patches, hence the missing tickets. > > As a side note, it was rather difficult to review parts of this as > different patches modify exactly the same code in different ways. > > General: > > These patches don't replace /etc/pki/nssdb, they just add a new > location. Do we need to keep using the shared db because of p11-kit? It's for backward compatibility. > > 319: > > The post-install script tries to get a cert with nickname 'IPA CA'. It > should also look for '$REALM IPA CA'. I'd use > ipapythhon.certdb.py:CA_NICKNAME_FMT. Having a similar option for > External CA is probably not a bad idea. I included 'IPA CA' and 'External CA cert', because they are the only nicknames used for the CA certificate in /etc/pki/nssdb before 4.1 (I checked in git). I did not include '$REALM IPA CA', as it is used only in unreleased code. > > You don't need the password file to import a cert into an NSS database. Fixed. > > It may be too complex in a spec file but would it be better to try to > fetch things out of LDAP? This nearly screams for a separate script to > do the work. Sorry, you have to run ipa-certupdate manually for now to update the database. Automatic updates from LDAP will be included in 4.2. We definitely need a client update script, for other stuff as well. > > Are these operations important enough to be logged to > /var/log/ipaupgrade.log? I suspect it's the kind of thing that might > fail and never be noticed. It couldn't hurt. > > At some point we'll upgrade to sql NSS databases. Is this going to > complicate things? I don't think so. When do we want to do the upgrade? > > There are some places you do str(e[2]) that aren't necessary. Fixed. > > Might be worthwhile to clean up the comments regarding XML-RPC while > you're at it and just refer to RPC. Done. > > I'd rename ca_certs_nss to ca_certs_trust for clarity. OK. > > Is the separate helper create_ipa_nssdb() necessary? Should create_db() > be extended to do this extra work? It is easier to call from the spec file this way. > > 324: > > ACK > > 325: > > The exception from get_cert() is very rough so wouldn't cover the case > of file permissions, missing database, etc, but since the overall > behavior isn't changing, ACK. Might be worth a comment though indicating > a potential source of oddness for the uninitiated. Comment added. > > 326: > > ACK > > 327: > > @@ -133,6 +116,7 @@ class CertUpdate(admintool.AdminTool): > criteria = { > 'cert-database': dogtag_constants.ALIAS_DIR, > 'cert-nickname': nickname, > + 'ca-name': 'dogtag-ipa-ca-renew-agent', > } > request_id = certmonger.get_request_id(criteria) > if request_id is not None: > > Doesn't seem related to this change. Moved to patch 340, along with similar change in ipa-cacert-manage in patch 335. > > 328: > > ACK > > 329: > > ACK > > 330: > > I don't understand the reference to ipa.p11-kit (an unowned file, btw). Added the file to the spec file. > > Are you removing any cert that may be left over from some previous install? Yes. I believe it might what was causing the NSS failures you saw in . > > If the file were to exist it could cause update-ca-trust to be executed > twice. Is that needed? Where? > > I think more clarity in the commit message will clear things up. OK. > > 331: > > ACK Updated the patch with a simpler fix and a ticket number. > > 332: > > What is the reason for this refactoring? It makes it easier to make changes such as the one in patch 333. Also it makes dogtag-ipa-ca-renew-agent more pythonic and easy to read IMHO. > > 333: > > Seems reasonable but why would a CA profile change in the middle of a > request? > > 334: > > Same boat, why? > > 335: > > I kinda get the picture, along with previous patches, but need more info. Updated commit messages of the above 3 patches with more info. > > Some tips on testing would be helpful. Testing is basically the same as for the original CA management patches - do some server installs, upgrades and uninstalls and run ipa-certupdate and ipa-cacert-manage with different options. > > rob > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319.2-Introduce-NSS-database-etc-ipa-nssdb.patch Type: text/x-patch Size: 15996 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-324.1-Move-NSSDatabase-from-ipaserver.certs-to-ipapython.c.patch Type: text/x-patch Size: 20092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-325.1-Add-NSSDatabase.has_nickname-for-checking-nickname-p.patch Type: text/x-patch Size: 1030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-326.1-Use-NSSDatabase-instead-of-direct-certutil-calls-in-.patch Type: text/x-patch Size: 9167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-327.1-Use-etc-ipa-nssdb-to-get-nicknames-of-IPA-certs-inst.patch Type: text/x-patch Size: 8849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-328.1-Check-if-IPA-client-is-configured-in-ipa-certupdate.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-329.1-Get-server-hostname-from-jsonrpc_uri-in-ipa-certupda.patch Type: text/x-patch Size: 1164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-330.1-Remove-ipa-ca.crt-from-systemwide-CA-store-on-client.patch Type: text/x-patch Size: 4415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-331.1-Fix-certmonger.wait_for_request.patch Type: text/x-patch Size: 960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-332.1-Refactor-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 20633 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-333.1-Restart-request-in-dogtag-ipa-ca-renew-agent-if-prof.patch Type: text/x-patch Size: 2237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-334.1-Do-not-wait-for-new-CA-certificate-to-appear-in-LDAP.patch Type: text/x-patch Size: 5181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-335.1-Fail-if-certmonger-can-t-see-new-CA-certificate-in-L.patch Type: text/x-patch Size: 2606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-340-Fix-certmonger-search-for-the-CA-cert-in-ipa-certupd.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 24 18:54:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Sep 2014 20:54:12 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5422CACF.7020406@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> Message-ID: <54231354.7050102@redhat.com> On 24/09/14 15:44, David Kupka wrote: > On 09/23/2014 08:25 PM, Martin Basti wrote: >> On 23/09/14 13:23, David Kupka wrote: >>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>> ... >>>> 1) >>>> + if options.unattended: >>>> + for ip in ip_addresses: >>>> + if search_reverse_zones and >>>> find_reverse_zone(str(ip)): >>>> + # reverse zone is already in LDAP >>>> + continue >>>> + for rz in ret_reverse_zones: >>>> + if verify_reverse_zone(rz, ip): >>>> + # reverse zone was entered by user >>>> + break >>>> + else: >>>> + rz = get_reverse_zone_default(str(ip)) >>>> + ret_reverse_zones.append(rz) >>>> + elif options.reverse_zones or create_reverse(): >>>> + for ip in ip_addresses: >>>> + if search_reverse_zones and >>>> find_reverse_zone(str(ip)): >>>> + # reverse zone is already in LDAP >>>> + continue >>>> + for rz in ret_reverse_zones: >>>> + if verify_reverse_zone(rz, ip): >>>> + # reverse zone was entered by user >>>> + break >>>> + else: >>>> + rz = get_reverse_zone_default(str(ip)) >>>> + rz = read_reverse_zone(rz, str(ip)) >>>> + ret_reverse_zones.append(rz) >>>> + else: >>>> + options.no_reverse = True >>>> + ret_reverse_zones = [] >>>> >>>> You can make it shorter without duplications: >>>> >>>> # this ifs can be in one line >>>> if not options.unatended: >>>> if not options.reverse_zones >>>> if not create_reverse(): >>>> options.no_reverse=True >>>> return [] >>>> >>>> for ip in ip_addresses: >>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>> # reverse zone is already in LDAP >>>> continue >>>> for rz in ret_reverse_zones: >>>> if verify_reverse_zone(rz, ip): >>>> # reverse zone was entered by user >>>> break >>>> else: >>>> rz = get_reverse_zone_default(str(ip)) >>>> if not options.unattended: >>>> rz = read_reverse_zone(rz, str(ip)) >>>> ret_reverse_zones.append(rz) >>>> >>> >>> Thanks, I modified it bit different way to alse address recommendation >>> 3). >>> >>>> >>>> 2) >>>> Typo? There is no IP address matching reverze_zone %s." >>>> ---------------------------------------------^^ >>>> >>> >>> Thanks, fixed. >>> >>>> >>>> 3) >>>> Would be nice to ask user to create new zones only if new zones are >>>> required. (If all required zones exist in LDAP, you ask user anyway) >>>> >>> >>> I added one more variable and ask only once. >>> >>>> 4) >>>> Ask framework gurus, if installutils module is better place for >>>> function >>>> above >>>> >>>> >>> >>> Petr^3 said that it's ok to have it in bindinstance.py. >>> >>>> >>> >> NACK, most important point is 7 >> >> 1) >> I'm not sure if this is bug, but interactively is allowed to add only >> one ip address >> >> Unable to resolve IP address for host name >> Please provide the IP address to be used for this host name: 2001:db8::2 >> The kerberos protocol requires a Realm name to be defined. >> > > For the sake of infinite usability and UX I rewrote it to ask for > multiple addresses the same way as for DNS forwarders. Also I really > simplified IP address checking code when I was in it. I tested it but > please look at it carefully. > Also I found that ipa-dns-install and ipa-adtrust-install also accept > --ip-address param. So I modified ipa-dns-install in the same way as > ipa-server-install and ipa-replica-install. After discussion with > tbabej I decided to dont touch ipa-adtrust-install now as it do not > use specified value at all. I will remove the processing code and mark > the param as deprecated in separate patch. > >> 2) >> I'm getting error message >> >> Invalid reverse zone 10.in-addr.arpa. for IP address 2001:db8::dead:beef >> Invalid reverse zone 10.in-addr.arpa. for IP address >> fed0:babe:baab:0:21a:4aff:fe10:4e18 >> >> - or - >> >> Do you want to configure the reverse zone? [yes]: >> Please specify the reverse zone name >> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP >> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >> Please specify the reverse zone name >> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >> >> This shouldn't be there > > Moved the message to function used when installation is attended by user. > >> >> Could be better to ask user to specific zone for ip address a.b.c.d. > > Probably, but lets leave some work for future. > >> >> 4) just nitpick >> The IPA Master Server will be configured with: >> ... >> IP address(es): 2001:db8::dead:beef, fed0:babe:baab:0:21a:4aff:fe10:4e18 >> ... >> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >> >> You have label "IP address(es)", so you should use label "Reverse >> zone(s)" >> > > Fixed. > >> 5) >> ipa-server-install --ip-address=10.16.78.105 >> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >> --setup-dns >> >> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not sure >> if this is wrong, but we prevents user to add zone without address in >> it, so we should prevents, to add empty zone. >> > > It would be nice but not in this patch. > >> 6) >> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. vm-105.example.com >> Directory Manager (existing master) password: >> >> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >> Invalid reverse zone 1.0.0.2.ip6.arpa. >> >> IMO This should work, right? >> >> + sys.exit("There is no IP address matching reverse zone >> %s." % rz) >> I expected at least this error to be shown. > > Fixed, thanks. > >> >> 7) >> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >> 2001:db8::dead:beef vm-105.example.com >> Directory Manager (existing master) password: >> >> ....... >> Adding DNS records for vm-105.example.com >> Values instance has no attribute 'ip_address' >> >> Command returns the attribute error. >> It fails with one --ip-address too. >> > > Sorry, fixed. > >> >> *) Not related with your patch >> Problem with installation: >> I'm getting message: >> IPA server is already configured on this system. >> Even if I validation wasn't successful and installation was aborted. >> >> IPA install detects previous installations by checking state file and >> restore files. Function get_server_ip_address() stores some data and >> hosts file and modify the host file, before user agreed installation. >> This error was there before your patch. >> https://fedorahosted.org/freeipa/ticket/4561 >> >> >> > NACK 0) # ipa-dns-install --ip-address 2001:db8::feed 2014-09-24T06:02:13Z DEBUG stderr= 2014-09-24T06:02:13Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 645, in run_script return_value = main_function() File "/sbin/ipa-dns-install", line 135, in main ip_addresses = get_server_ip_address(api.env.host, fstore, options.unattended, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 473, in get_server_ip_address if options.setup_dns: 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, exception: AttributeError: Values instance has no attribute 'setup_dns' 1) # ipa-replica-prepare vm-073.example.com --ip-address 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 Directory Manager (existing master) password: Preparing replica for vm-073.example.com from vm-105.example.com Creating SSL certificate for the Directory Server Creating SSL certificate for the dogtag Directory Server Saving dogtag Directory Server port Creating SSL certificate for the Web Server Exporting RA certificate Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-vm-073.example.com.gpg Adding DNS records for vm-073.example.com Values instance has no attribute 'unattended' It should be unatended automatically, or we need add the --unattended option to ipa-replica-prepare 2) This is nto user friendly, could be IP address check before installation? [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns --no-forwarders Directory Manager (existing master) password: Run connection check to master ... ... Restarting the KDC There is no IP address matching reverse zone 10.in-addr.arpa.. LOG: return_value = main_function() File "/sbin/ipa-replica-install", line 721, in main install_bind(config, options) File "/sbin/ipa-replica-install", line 265, in install_bind reverse_zones = bindinstance.check_reverse_zones(config.ip_addresses, options.reverse_zones, options, True) File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 426, in check_reverse_zones sys.exit("There is no IP address matching reverse zone %s." % rz) 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, exception: SystemExit: There is no IP address matching reverse zone 10.in-addr.arpa.. 3) I'm not sure if sys.exit() is good, replica-install shoudl wrote something about partially configured system 4) I'm not sure if this is the best place to ask about reverse zones .... Done configuring the web interface (httpd). Configuring ipa-otpd [1/2]: starting ipa-otpd [2/2]: configuring ipa-otpd to start on boot Done configuring ipa-otpd. Applying LDAP updates Restarting the directory server Restarting the KDC Do you want to configure the reverse zone? [yes]: 5) And error # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx --setup-dns .... Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: AttributeError: 'str' object has no attribute 'version' LOG: 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket conn= 2014-09-24T06:50:45Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 645, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 721, in main install_bind(config, options) File "/sbin/ipa-replica-install", line 272, in install_bind ca_configured=options.setup_ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 550, in setup self.__setup_sub_dict() File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 651, in __setup_sub_dict if addr.version in (4, 6): 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, exception: AttributeError: 'str' object has no attribute 'version' *) I don't like this asking to specify zone without IP Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: Please specify the reverse zone name [78.16.10.in-addr.arpa.]: **) I'm not sure how often this case can happen: master and replica without DNS, you run --ipa-dns-install on master then on replica, then replica DNS installation will not try to find existent reverse zones in ldap, due configuration in ipa-dns-install. Maybe you should detect if DNS container exists and then set flag "search_reverse_zones=True" ipa-dns-install: + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, options.reverse_zones, options) -- Martin Basti From ftweedal at redhat.com Thu Sep 25 01:30:37 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 25 Sep 2014 11:30:37 +1000 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <5422D254.4040807@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> <5422D254.4040807@redhat.com> Message-ID: <20140925013037.GZ5346@dhcp-40-8.bne.redhat.com> On Wed, Sep 24, 2014 at 09:16:52AM -0500, Endi Sukma Dewata wrote: > On 9/24/2014 8:26 AM, Petr Vobornik wrote: > >On 24.9.2014 04:43, Endi Sukma Dewata wrote: > >>On 9/22/2014 9:49 AM, Petr Vobornik wrote: > >>>[PATCH] webui-ci: case-insensitive record check > >>> > >>>Indirect association are no longer lower cased, which caused a issue > >>>in CI. > >> > >>Is the use of "|=" operator intentional? I don't see the "has" variable > >>defined anywhere else in this method. > >> > >> has |= self.has_record(pkey.lower(), parent, table_name) > >> > >>If this has been tested to work, then ACK. > >> > > > >it's defined on the previous line: > > > > has = self.has_record(pkey, parent, table_name) > > has |= self.has_record(pkey.lower(), parent, table_name) > > Ah, I see. I thought the old line was being replaced. > ACK. IMO the following reads better:: has = self.has_record(pkey, parent, table_name) \ || self.has_record(pkey.lower(), parent, table_name) (Just a comment - no reason to block the patch.) > -- > Endi S. Dewata > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From redhatrises at gmail.com Thu Sep 25 02:34:26 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 24 Sep 2014 20:34:26 -0600 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants Message-ID: Hello, Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know if I missed any. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0033-Remove-trivial-path-constants-from-modules.patch Type: text/x-patch Size: 69831 bytes Desc: not available URL: From edewata at redhat.com Thu Sep 25 04:16:53 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Sep 2014 23:16:53 -0500 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <5422D8AF.6070300@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> Message-ID: <54239735.5040303@redhat.com> On 9/24/2014 9:43 AM, Petr Vobornik wrote: > On 24.9.2014 16:30, Endi Sukma Dewata wrote: >> On 9/19/2014 7:29 AM, Petr Vobornik wrote: >>> Hello, >>> >>> attached patches implements Web UI part of ID Views. Backend is >>> currently on review as well - thread "[PATCHES 247-259] ID views - >>> management part". >>> >>> https://fedorahosted.org/freeipa/ticket/4535 >>> >>> I expect that backed can change and that the UI might influence it as >>> well. Therefore no UI integration tests nor static data files are >>> included in this patchset. They will follow when backend is stable. >>> > > snip > >> >>> == [PATCH] 754 webui: new ID views section == >> >> I'll test this separately. Does your patch #754-1 work with Tomas' >> latest patches (#247-2 - 270)? >> > > It was tested with tomas' git branch which matched > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00336.html > OK, some comments/questions: 1. For consistency, the "ID view" should be capitalized into "ID View" in the navigation tab, page title, and dialog title. See "ID Ranges" as an example. 2. The tab titles in the ID view details page are quite long, and the "User ID overrides" and "Group ID overrides" labels aren't quite appropriate because the ID view can override other attributes too. How about using facet groups like in User Groups? For example: - applies to: - Hosts - overrides: - Users - Groups - Settings 3. Since the tab already says "Applied to hosts", the current button labels is kind of redundant. How about renaming and reorder the buttons like this? - Refresh - Remove - Add - Add hosts in host group - Remove hosts in host group 4. If I understand correctly the description field for the User ID Overrides and Group ID Overrides should be optional too because it's also used to optionally override the description attribute of the original entry. 5. Not sure if this is a problem. The search field in User/Group ID Overrides can be used to find the overriding attributes, but not the "User/Group to override". 6. Can multiple ID views be applied to the same host? Does the order matter? If so, how would the UI manage the order? 7. Related to #6, there probably should be a tab in the Host details page showing which ID views apply to it. 8. If we implement #7, are the "Un-apply from hosts/host groups" buttons in the ID views search page still necessary? Or can it be moved into that page (i.e. unapplying one host at a time)? 9. This probably requires server support. In the "Apply to hosts" association dialog, if a host is already added it will still appear in the dialog box. As a comparison, a User that has been added into a User Group will not appear in the association dialog anymore. 10. The use of association dialog for "Apply to host groups" and "Un-apply from host groups" is a bit unusual because it's used to select host groups, and once selected the host groups are not added to/removed from the main list because the main list contains hosts, not host groups. Would it be very common to select multiple host groups at once to apply ID view? If not, it might make more sense to just use a plain dialog to select one host group at a time. The dialog could probably show information about the host groups (i.e. host members) before applying/unapplying the ID view. I think the only major issue is #4. Once it's addressed, ACK. The others are minor issues, questions, and suggestions. -- Endi S. Dewata From mkosek at redhat.com Thu Sep 25 06:55:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 08:55:46 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <20140924161904.GB16438@redhat.com> References: <54228825.4020900@redhat.com> <20140924161904.GB16438@redhat.com> Message-ID: <5423BC72.9070701@redhat.com> On 09/24/2014 06:19 PM, Jan Pazdziora wrote: > On Wed, Sep 24, 2014 at 11:00:21AM +0200, Martin Kosek wrote: >> >> I just rebuilt latest fixed pki-core&tomcat for our Copr >> (http://copr.fedoraproject.org/coprs/mkosek/freeipa/builds/). We are now very >> close to having a functional repo for RHEL/CentOS 7.0. >> >> With couple minor changes to the spec file, I was able to install FreeIPA 4.0.3 > > What will be the content of these yum repos going forward? Will > they be fixated at 4.0.3, or will they always contain the latest > greatest release? My current vision for this Copr was for it to have the latest greatest stable (-ish) FreeIPA versino. I.e. as soon as we release 4.1, it would contain 4.1 and it's dependencies. > Would it make sense to create one copr repo per > release, versioned, so that even when 4.0.4 or 4.1.0 is out, the > 4.0.3 content is still available? It makes sense, yes - especially if there would be an interest in this from our users or your Docker use cases - given the maintenance burden. We can build some semi-automatism around it though to make the maintenance easier, I myself have some scripts ready to handle the builds. > I'd like to use these yum repos for Docker images and I wonder what > naming I should use for the branches and tags -- centos-7-upstream, > centos-7-4.0.3, or something else? centos-7-latest (with mkosek/freeipa copr) centos-7-4-0 (with potential future mkosek/freeipa-4-0 copr) centos-7-4-1 (with potential future mkosek/freeipa-4-1 copr) Makes sense? Martin From jhrozek at redhat.com Thu Sep 25 06:57:50 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 25 Sep 2014 08:57:50 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <5423BC72.9070701@redhat.com> References: <54228825.4020900@redhat.com> <20140924161904.GB16438@redhat.com> <5423BC72.9070701@redhat.com> Message-ID: <20140925065750.GT31763@hendrix.brq.redhat.com> On Thu, Sep 25, 2014 at 08:55:46AM +0200, Martin Kosek wrote: > On 09/24/2014 06:19 PM, Jan Pazdziora wrote: > > On Wed, Sep 24, 2014 at 11:00:21AM +0200, Martin Kosek wrote: > >> > >> I just rebuilt latest fixed pki-core&tomcat for our Copr > >> (http://copr.fedoraproject.org/coprs/mkosek/freeipa/builds/). We are now very > >> close to having a functional repo for RHEL/CentOS 7.0. > >> > >> With couple minor changes to the spec file, I was able to install FreeIPA 4.0.3 > > > > What will be the content of these yum repos going forward? Will > > they be fixated at 4.0.3, or will they always contain the latest > > greatest release? > > My current vision for this Copr was for it to have the latest greatest stable > (-ish) FreeIPA versino. I.e. as soon as we release 4.1, it would contain 4.1 > and it's dependencies. We do the same with SSSD 1.11.x and it's been quite a success, we've received several bug reports from people who run this repository. From abokovoy at redhat.com Thu Sep 25 07:25:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Sep 2014 10:25:49 +0300 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <54239735.5040303@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> Message-ID: <20140925072549.GF11503@redhat.com> On Wed, 24 Sep 2014, Endi Sukma Dewata wrote: >On 9/24/2014 9:43 AM, Petr Vobornik wrote: >>On 24.9.2014 16:30, Endi Sukma Dewata wrote: >>>On 9/19/2014 7:29 AM, Petr Vobornik wrote: >>>>Hello, >>>> >>>>attached patches implements Web UI part of ID Views. Backend is >>>>currently on review as well - thread "[PATCHES 247-259] ID views - >>>>management part". >>>> >>>>https://fedorahosted.org/freeipa/ticket/4535 >>>> >>>>I expect that backed can change and that the UI might influence it as >>>>well. Therefore no UI integration tests nor static data files are >>>>included in this patchset. They will follow when backend is stable. >>>> >> >>snip >> >>> >>>>== [PATCH] 754 webui: new ID views section == >>> >>>I'll test this separately. Does your patch #754-1 work with Tomas' >>>latest patches (#247-2 - 270)? >>> >> >>It was tested with tomas' git branch which matched >>http://www.redhat.com/archives/freeipa-devel/2014-September/msg00336.html >> > >OK, some comments/questions: > >1. For consistency, the "ID view" should be capitalized into "ID View" >in the navigation tab, page title, and dialog title. See "ID Ranges" >as an example. > >2. The tab titles in the ID view details page are quite long, and the >"User ID overrides" and "Group ID overrides" labels aren't quite >appropriate because the ID view can override other attributes too. How >about using facet groups like in User Groups? For example: > - applies to: > - Hosts > - overrides: > - Users > - Groups > - Settings > >3. Since the tab already says "Applied to hosts", the current button >labels is kind of redundant. How about renaming and reorder the >buttons like this? > - Refresh > - Remove > - Add > - Add hosts in host group > - Remove hosts in host group > >4. If I understand correctly the description field for the User ID >Overrides and Group ID Overrides should be optional too because it's >also used to optionally override the description attribute of the >original entry. No, this is description of the override itself. We don't want to override original description field, if any, we want to provide a way to document why this override was done. >5. Not sure if this is a problem. The search field in User/Group ID >Overrides can be used to find the overriding attributes, but not the >"User/Group to override". > >6. Can multiple ID views be applied to the same host? Does the order >matter? If so, how would the UI manage the order? No. Single ID view per host. The scheme is actually a bit more complex: - IPA users: data from main tree is overridden with a data from a host-specific ID view - AD users: data from AD is overridden by a data from a default trust view which is then overridden by a data from a host-specific ID view >7. Related to #6, there probably should be a tab in the Host details >page showing which ID views apply to it. There is only a single view and yes, it would be good to add a property there, linking it to the ID view tab, if possible. >8. If we implement #7, are the "Un-apply from hosts/host groups" >buttons in the ID views search page still necessary? Or can it be >moved into that page (i.e. unapplying one host at a time)? Mass-removal is needed to allow hostgroup management. >9. This probably requires server support. In the "Apply to hosts" >association dialog, if a host is already added it will still appear in >the dialog box. As a comparison, a User that has been added into a >User Group will not appear in the association dialog anymore. Could be trivially filtered out on Web UI side. >10. The use of association dialog for "Apply to host groups" and >"Un-apply from host groups" is a bit unusual because it's used to >select host groups, and once selected the host groups are not added >to/removed from the main list because the main list contains hosts, >not host groups. Would it be very common to select multiple host >groups at once to apply ID view? If not, it might make more sense to >just use a plain dialog to select one host group at a time. The dialog >could probably show information about the host groups (i.e. host >members) before applying/unapplying the ID view. I think it could be useful to select several hostgroups at the same time, given that 'apply to host groups' operation is one shot. -- / Alexander Bokovoy From pviktori at redhat.com Thu Sep 25 07:44:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 09:44:03 +0200 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <20140925013037.GZ5346@dhcp-40-8.bne.redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> <5422D254.4040807@redhat.com> <20140925013037.GZ5346@dhcp-40-8.bne.redhat.com> Message-ID: <5423C7C3.80305@redhat.com> On 09/25/2014 03:30 AM, Fraser Tweedale wrote: > On Wed, Sep 24, 2014 at 09:16:52AM -0500, Endi Sukma Dewata wrote: >> On 9/24/2014 8:26 AM, Petr Vobornik wrote: >>> On 24.9.2014 04:43, Endi Sukma Dewata wrote: >>>> On 9/22/2014 9:49 AM, Petr Vobornik wrote: >>>>> [PATCH] webui-ci: case-insensitive record check >>>>> >>>>> Indirect association are no longer lower cased, which caused a issue >>>>> in CI. >>>> >>>> Is the use of "|=" operator intentional? I don't see the "has" variable >>>> defined anywhere else in this method. >>>> >>>> has |= self.has_record(pkey.lower(), parent, table_name) >>>> >>>> If this has been tested to work, then ACK. >>>> >>> >>> it's defined on the previous line: >>> >>> has = self.has_record(pkey, parent, table_name) >>> has |= self.has_record(pkey.lower(), parent, table_name) >> >> Ah, I see. I thought the old line was being replaced. >> ACK. > > IMO the following reads better:: > > has = self.has_record(pkey, parent, table_name) \ > || self.has_record(pkey.lower(), parent, table_name) > > (Just a comment - no reason to block the patch.) Feel free to push the patch as it is, but since we're debating style... Write this: has_record = (self.has_record(pkey, parent, table_name) or self.has_record(pkey.lower(), parent, table_name)) For boolean values, you should prefer `or` and `and` over the bitwise operators, since "truthy"/"falsy" values might not be just booleans. It's better illustrated with `and`: `3 and 8` is true, but `3 & 8` is false. And from PEP8: - The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation. - The preferred place to break around a binary operator is after the operator, not before it. -- Petr? From mkosek at redhat.com Thu Sep 25 07:59:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 09:59:47 +0200 Subject: [Freeipa-devel] [PATCH 0128] dnszone-remove-permission should raise NotFound if permission doesn't exist In-Reply-To: <5422EFAF.9070905@redhat.com> References: <5422DB67.5070908@redhat.com> <5422E3AC.2000208@redhat.com> <5422EFAF.9070905@redhat.com> Message-ID: <5423CB73.9080200@redhat.com> On 09/24/2014 06:22 PM, Martin Basti wrote: > On 24/09/14 17:30, Martin Kosek wrote: >> On 09/24/2014 04:55 PM, Martin Basti wrote: >>> Patch attached >>> >>> This probably should go to 4.0.x, 4.1 and master >> It is obvious that this interface was designed this way. So you should >> elaborate more on the "should" part, list use cases where current approach does >> not work, link to tickets, ... >> >> > Sorry for that, I though I broke it during refactoring. Not so fast, pardner :-) I checked with 3.3.3 and this *was* indeed changed during your refactoring. My main point was that you should be clear about your intents and reasons for the patch, that a mere "should" is not clear to everybody. ACK to your patch though, works fine and restores the behavior - time to add tests?. I just adjusted the commit message a little before pushing. Pushed to: master: 2f1f1221701160ebeb4f23078adce3af59892162 ipa-4-1: 7a99f22ee0a4c5fd1d41722fa0101fee74e0c76e ipa-4-0: 32b6eb5110b2f851fbedb39ac0d853b46087465f Martin From mbasti at redhat.com Thu Sep 25 08:06:25 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 10:06:25 +0200 Subject: [Freeipa-devel] [PATCH 0128] dnszone-remove-permission should raise NotFound if permission doesn't exist In-Reply-To: <5423CB73.9080200@redhat.com> References: <5422DB67.5070908@redhat.com> <5422E3AC.2000208@redhat.com> <5422EFAF.9070905@redhat.com> <5423CB73.9080200@redhat.com> Message-ID: <5423CD01.4000909@redhat.com> On 25/09/14 09:59, Martin Kosek wrote: > On 09/24/2014 06:22 PM, Martin Basti wrote: >> On 24/09/14 17:30, Martin Kosek wrote: >>> On 09/24/2014 04:55 PM, Martin Basti wrote: >>>> Patch attached >>>> >>>> This probably should go to 4.0.x, 4.1 and master >>> It is obvious that this interface was designed this way. So you should >>> elaborate more on the "should" part, list use cases where current approach does >>> not work, link to tickets, ... >>> >>> >> Sorry for that, I though I broke it during refactoring. > Not so fast, pardner :-) I checked with 3.3.3 and this *was* indeed changed > during your refactoring. My main point was that you should be clear about your > intents and reasons for the patch, that a mere "should" is not clear to everybody. > > ACK to your patch though, works fine and restores the behavior - time to add > tests?. I just adjusted the commit message a little before pushing. > > Pushed to: > master: 2f1f1221701160ebeb4f23078adce3af59892162 > ipa-4-1: 7a99f22ee0a4c5fd1d41722fa0101fee74e0c76e > ipa-4-0: 32b6eb5110b2f851fbedb39ac0d853b46087465f > > Martin Thanks, I will add tests next week. -- Martin Basti From pvoborni at redhat.com Thu Sep 25 08:25:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 10:25:05 +0200 Subject: [Freeipa-devel] [PATCH] 756 webui: fix regression in association facet preop In-Reply-To: <54222FC6.9080508@redhat.com> References: <54203719.1040304@redhat.com> <54222FC6.9080508@redhat.com> Message-ID: <5423D161.8010800@redhat.com> On 24.9.2014 04:43, Endi Sukma Dewata wrote: > On 9/22/2014 9:50 AM, Petr Vobornik wrote: >> Association facet specs use 'add_method' instead of 'add_command' >> >> origin: https://fedorahosted.org/freeipa/ticket/4507 > > ACK. > Pushed to: master: a56c1e58696a2489bf5bf8dd5aca603977c76a1c ipa-4-1: 18cb8d7736e433db2f10e3d72f81a295571d3e88 -- Petr Vobornik From mbasti at redhat.com Thu Sep 25 08:31:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 10:31:16 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5422D434.4090800@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> Message-ID: <5423D2D4.6080709@redhat.com> On 24/09/14 16:24, Martin Basti wrote: > On 24/09/14 16:05, Martin Basti wrote: >> On 23/09/14 17:45, Petr Vobornik wrote: >>> On 25.8.2014 14:52, Martin Basti wrote: >>>> 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 >>>> >>>> >>> >>> Review of: >>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>> >>> >>> 1. Please follow pep8 for the new code. >>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>> Produces 25 erros. >>> >>> Only E124 and E128 could be ignored if they are part of old code. >> >> I left there some pep8 errors. They don't decrease readability >> >>> >>> Patch 120: >>> >>> 3. This patch uses term 'deprecated' in a different meaning than a >>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >>> this usage is correct since the usual understanding of deprecation >>> is that the param is still usable but user should be prepared that >>> it will be removed in a future. IMHO DeprecatedParam is badly >>> designed but that's not an issue of this patch. >>> >>> I think we can leave this as is and create a ticket to rename >>> DeprecatedParam e.g. to RemovedParam. What do you think? >>> >> https://fedorahosted.org/freeipa/ticket/4566 >>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>> dnszone-add precallback still uses these params. What is the >>> intended purpose? >> User should use modify dialog in webUI for zones. >> Precallback fills default value for idnsmname from LDAP. >> with --force there will be no validation of user specified soa mname >> >> Purpose is a user should let IPA to fill mname with safe value. >>> Patch 123: >>> >>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >>> shouldn't it be normalized to contain '.' at the end? Or is it >>> handled by bind-dyndb-ldap? >> >> Zone manager (SOA RNAME) can eb relative name, BIND will append zone >> name. >> Currently we cant validate if email address is reachable, it doestn >> matter if it is filled with nonexistent absolute name, or nonexistent >> relative name. >> >>> Unrelated to this patch set: >>> >>> a. One is able to run: >>> # ipa dnszone-remove-permission $zone >>> multiple times and it always returns success >>> >>> Is it intentional? >> No, it isn't. I will inspect it and I will send additional patch >> >>> >>> b. Web UI doesn't have means to call dnszone-mod with --force option >> I'm not sure what you mean, it didn't do that before my patches. >> >> Updated patches attached >> > I accidentally removed one line in previous patchset. > Updated patches attached > Sorry my IDE was too smart, and somehow added its configuration file to commit and I didn't notice it. Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0114.4-Fix-DNS-plugin-to-allow-to-add-root-zone.patch Type: text/x-patch Size: 4993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0115.4-DNS-test-allow-.-as-zone-name.patch Type: text/x-patch Size: 4541 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0120.5-Deprecation-of-name-server-and-ip-address-option-in-.patch Type: text/x-patch Size: 16370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0121.5-Add-correct-NS-records-during-installation.patch Type: text/x-patch Size: 9726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0123.4-DNS-autofill-admin-email.patch Type: text/x-patch Size: 7904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0124.4-WebUI-DNS-Remove-ip-address-admin-email-options.patch Type: text/x-patch Size: 4444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0125.4-DNS-tests-tests-update-to-due-to-change-in-options.patch Type: text/x-patch Size: 62301 bytes Desc: not available URL: From pvoborni at redhat.com Thu Sep 25 08:31:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 10:31:39 +0200 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <5422D254.4040807@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> <5422D254.4040807@redhat.com> Message-ID: <5423D2EB.1040205@redhat.com> On 24.9.2014 16:16, Endi Sukma Dewata wrote: > On 9/24/2014 8:26 AM, Petr Vobornik wrote: >> On 24.9.2014 04:43, Endi Sukma Dewata wrote: >>> On 9/22/2014 9:49 AM, Petr Vobornik wrote: >>>> [PATCH] webui-ci: case-insensitive record check >>>> >>>> Indirect association are no longer lower cased, which caused a issue >>>> in CI. >>> >>> Is the use of "|=" operator intentional? I don't see the "has" variable >>> defined anywhere else in this method. >>> >>> has |= self.has_record(pkey.lower(), parent, table_name) >>> >>> If this has been tested to work, then ACK. >>> >> >> it's defined on the previous line: >> >> has = self.has_record(pkey, parent, table_name) >> has |= self.has_record(pkey.lower(), parent, table_name) > > Ah, I see. I thought the old line was being replaced. > ACK. > Pushed to: master: dafdd68a6ed7030d7f7a153144b36443603e884f ipa-4-1: c66b1ec8c81dc65e2807ab54bdb13957eaf55534 -- Petr Vobornik From mbasti at redhat.com Thu Sep 25 08:51:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 10:51:58 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <541C21CB.8050202@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> Message-ID: <5423D7AE.2090306@redhat.com> On 19/09/14 14:30, Jan Cholasta wrote: > Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >> On 01/09/14 16:26, Martin Basti wrote: >>> On 28/08/14 14:01, Jan Cholasta wrote: >>>> 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 >>>> >>> 3) skipped as we discuss on IRC >>> >>> Updated patch attached >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Please review, this should be in 4.1 > > 1) The patch need a rebase on top of current ipa-4-1. I can apply it (Am I doing something wrong?) > > > 2) You can remove import pwd from service.py, it is no longer used there. > > > 3) Are named constants for the autobind argument the right thing to > do? It is a tri-state which can be expressed with None/True/False. > (I'm just asking, I don't have a strong opinion on this.) > As we discussed on IRC, using None/True/False, is not good approach. Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0116.3-Refactoring-of-autobind-object_exists.patch Type: text/x-patch Size: 9784 bytes Desc: not available URL: From pviktori at redhat.com Thu Sep 25 08:58:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 10:58:04 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <5422EB10.3030305@redhat.com> References: <53EE7049.3050605@redhat.com> <5422EB10.3030305@redhat.com> Message-ID: <5423D91C.6040503@redhat.com> On 09/24/2014 06:02 PM, thierry bordaz wrote: > On 08/15/2014 10:40 PM, Petr Viktorin wrote: >> 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. Filed easyfix: https://fedorahosted.org/freeipa/ticket/4571 > The first patch looks good to me. Just a minor comment. The test and run > of 'paths.SELINUXENABLED' is present several times in tasks.py and > fedora. Does it worth to refactor it ? > > About the second patch, something I do not understand. > restore_selinux_booleans resets the selinux boolean to the values that > are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . Does > that mean this dict has been updated with the original values (using > 'backup_func' in set_selinux_booleans ?). This is restoring an IPA installation, not restoring the system to a pre-IPA state. The settings need to be the same as if IPA was being installed. -- Petr? From mbasti at redhat.com Thu Sep 25 09:03:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 11:03:51 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <5422D030.4030708@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> <5421A154.4090304@redhat.com> <5421A587.3020502@redhat.com> <5422D030.4030708@redhat.com> Message-ID: <5423DA77.7080303@redhat.com> On 24/09/14 16:07, Martin Basti wrote: > On 23/09/14 18:53, Martin Basti wrote: >> On 23/09/14 18:35, Petr Spacek wrote: >>> On 22.9.2014 19:21, Martin Basti wrote: >>>> On 22/09/14 13:17, Petr Vobornik wrote: >>>>> On 19.9.2014 16:15, Martin Basti wrote: >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3414 >>>>>> Patch attached. >>>>>> >>>>> >>>>> Patch 126: >>>>> >>>>> 1. I think that just >>>>> DeprecatedParam('dnsclass?'), >>>>> >>>>> should be enough. >>>>> >>>>> Also >>>>> >>>>> 2. You forgot to update API.txt and VERSION >>>>> >>>>> Patch 127: >>>>> ACK >>>>> >>>> Updated patchset attached >>> >>> ACK, it works for me. >>> >> Please don't push, we discuss this and we will nit use the >> DeprecatedParam. >> > Updated patch attached > I didn't notice, but changes in VERSION is not required anymore. Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0126.4-DNS-remove-class-option.patch Type: text/x-patch Size: 1692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0127.4-WebUI-DNS-remove-class-option.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: From jpazdziora at redhat.com Thu Sep 25 09:09:54 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 25 Sep 2014 11:09:54 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <5423BC72.9070701@redhat.com> References: <54228825.4020900@redhat.com> <20140924161904.GB16438@redhat.com> <5423BC72.9070701@redhat.com> Message-ID: <20140925090954.GW8063@redhat.com> On Thu, Sep 25, 2014 at 08:55:46AM +0200, Martin Kosek wrote: > > > I'd like to use these yum repos for Docker images and I wonder what > > naming I should use for the branches and tags -- centos-7-upstream, > > centos-7-4.0.3, or something else? > > centos-7-latest (with mkosek/freeipa copr) > centos-7-4-0 (with potential future mkosek/freeipa-4-0 copr) > centos-7-4-1 (with potential future mkosek/freeipa-4-1 copr) > > Makes sense? Yes, thanks. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From tbordaz at redhat.com Thu Sep 25 09:34:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Sep 2014 11:34:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <5423D91C.6040503@redhat.com> References: <53EE7049.3050605@redhat.com> <5422EB10.3030305@redhat.com> <5423D91C.6040503@redhat.com> Message-ID: <5423E1C2.2080507@redhat.com> On 09/25/2014 10:58 AM, Petr Viktorin wrote: > On 09/24/2014 06:02 PM, thierry bordaz wrote: >> On 08/15/2014 10:40 PM, Petr Viktorin wrote: >>> 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. > > Filed easyfix: https://fedorahosted.org/freeipa/ticket/4571 > > >> The first patch looks good to me. Just a minor comment. The test and run >> of 'paths.SELINUXENABLED' is present several times in tasks.py and >> fedora. Does it worth to refactor it ? >> >> About the second patch, something I do not understand. >> restore_selinux_booleans resets the selinux boolean to the values that >> are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . Does >> that mean this dict has been updated with the original values (using >> 'backup_func' in set_selinux_booleans ?). > > This is restoring an IPA installation, not restoring the system to a > pre-IPA state. > The settings need to be the same as if IPA was being installed. > > OK thanks for the explanation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Sep 25 10:09:24 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 12:09:24 +0200 Subject: [Freeipa-devel] [PATCH 0126 - 0127] DNS: remove --class option In-Reply-To: <5423DA77.7080303@redhat.com> References: <541C3A95.9050504@redhat.com> <54200559.6060604@redhat.com> <54205A88.8050207@redhat.com> <5421A154.4090304@redhat.com> <5421A587.3020502@redhat.com> <5422D030.4030708@redhat.com> <5423DA77.7080303@redhat.com> Message-ID: <5423E9D4.7030602@redhat.com> On 25.9.2014 11:03, Martin Basti wrote: > On 24/09/14 16:07, Martin Basti wrote: >> > I didn't notice, but changes in VERSION is not required anymore. > Updated patch attached > ACK pushed to master: * 7325983a48c9cf9300d046260c98253b6dae2dbc DNS: remove --class option * 180414d64d992f80e03d0627deff7709f81520bd WebUI: DNS: remove --class option ipa-4-1: * 7d61444732d42aed12b0966068dce090c398aec5 DNS: remove --class option * 12c49d88942a45e7c053a6c005ce10f2b8cabe88 WebUI: DNS: remove --class option -- Petr Vobornik From pspacek at redhat.com Thu Sep 25 10:13:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Sep 2014 12:13:43 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <542297C0.5020108@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> <54201041.2050201@redhat.com> <54216CD9.80708@redhat.com> <542297C0.5020108@redhat.com> Message-ID: <5423EAD7.7030501@redhat.com> On 24.9.2014 12:06, Petr Viktorin wrote: > On 09/23/2014 02:51 PM, Martin Basti wrote: >> On 22/09/14 14:04, Petr Viktorin wrote: >>> On 09/01/2014 04:31 PM, Martin Basti wrote: >>>> On 24/07/14 09:06, Martin Basti wrote: >>>>> On 23/07/14 15:17, Martin Basti wrote: >>>>>> This patch fixes ordering problem of schema updates >>>>>> >>>>>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>>>>> (will be in Fedora 21) >>>>>> > [...] >> Thank you! >> updated patch attached. > > ACK > > We should wait with pushing until the rebased ldap-python *is* in Fedora, or > at least in a COPR. > So far it's not even in Koji, AFAICS. https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc20 https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc21 -- Petr^2 Spacek From mkosek at redhat.com Thu Sep 25 10:19:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 12:19:34 +0200 Subject: [Freeipa-devel] FreeIPA on RHEL/CentOS 7.0 In-Reply-To: <20140925090954.GW8063@redhat.com> References: <54228825.4020900@redhat.com> <20140924161904.GB16438@redhat.com> <5423BC72.9070701@redhat.com> <20140925090954.GW8063@redhat.com> Message-ID: <5423EC36.3030608@redhat.com> On 09/25/2014 11:09 AM, Jan Pazdziora wrote: > On Thu, Sep 25, 2014 at 08:55:46AM +0200, Martin Kosek wrote: >> >>> I'd like to use these yum repos for Docker images and I wonder what >>> naming I should use for the branches and tags -- centos-7-upstream, >>> centos-7-4.0.3, or something else? >> >> centos-7-latest (with mkosek/freeipa copr) >> centos-7-4-0 (with potential future mkosek/freeipa-4-0 copr) >> centos-7-4-1 (with potential future mkosek/freeipa-4-1 copr) >> >> Makes sense? > > Yes, thanks. > Although now looking at the branch names, people may confused CentOS/RHEL version with FreeIPA version (I am referring to 7-4-0 part). So centos-7-ipa-latest centos-7-ipa-4-1 centos-7-ipa-4-0 may be better + would also reflect the actual branch names. From mkosek at redhat.com Thu Sep 25 10:49:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 12:49:33 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <5423EAD7.7030501@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> <54201041.2050201@redhat.com> <54216CD9.80708@redhat.com> <542297C0.5020108@redhat.com> <5423EAD7.7030501@redhat.com> Message-ID: <5423F33D.809@redhat.com> On 09/25/2014 12:13 PM, Petr Spacek wrote: > On 24.9.2014 12:06, Petr Viktorin wrote: >> On 09/23/2014 02:51 PM, Martin Basti wrote: >>> On 22/09/14 14:04, Petr Viktorin wrote: >>>> On 09/01/2014 04:31 PM, Martin Basti wrote: >>>>> On 24/07/14 09:06, Martin Basti wrote: >>>>>> On 23/07/14 15:17, Martin Basti wrote: >>>>>>> This patch fixes ordering problem of schema updates >>>>>>> >>>>>>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>>>>>> (will be in Fedora 21) >>>>>>> >> [...] >>> Thank you! >>> updated patch attached. >> >> ACK >> >> We should wait with pushing until the rebased ldap-python *is* in Fedora, or >> at least in a COPR. >> So far it's not even in Koji, AFAICS. > > https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc20 > https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc21 It is now also being built in the Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/33650/ Martin From pviktori at redhat.com Thu Sep 25 10:58:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 12:58:08 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <5423EAD7.7030501@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53D0B05C.3060405@redhat.com> <54048358.9000604@redhat.com> <54201041.2050201@redhat.com> <54216CD9.80708@redhat.com> <542297C0.5020108@redhat.com> <5423EAD7.7030501@redhat.com> Message-ID: <5423F540.7020409@redhat.com> On 09/25/2014 12:13 PM, Petr Spacek wrote: > On 24.9.2014 12:06, Petr Viktorin wrote: >> On 09/23/2014 02:51 PM, Martin Basti wrote: >>> On 22/09/14 14:04, Petr Viktorin wrote: >>>> On 09/01/2014 04:31 PM, Martin Basti wrote: >>>>> On 24/07/14 09:06, Martin Basti wrote: >>>>>> On 23/07/14 15:17, Martin Basti wrote: >>>>>>> This patch fixes ordering problem of schema updates >>>>>>> >>>>>>> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python >>>>>>> (will be in Fedora 21) >>>>>>> >> [...] >>> Thank you! >>> updated patch attached. >> >> ACK >> >> We should wait with pushing until the rebased ldap-python *is* in >> Fedora, or >> at least in a COPR. >> So far it's not even in Koji, AFAICS. > > https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc20 > https://admin.fedoraproject.org/updates/python-ldap-2.4.16-1.fc21 Pushed to: master: c81acfff43042421b06873e66a04c1aebe89579b ipa-4-1: d8d5b2ea89a83b5b63b2650a421f16f341783126 -- Petr? From mkosek at redhat.com Thu Sep 25 11:23:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 13:23:18 +0200 Subject: [Freeipa-devel] [PATCH] 0647 test_permission_plugin: Check legacy permissions In-Reply-To: <541C7698.3000109@redhat.com> References: <541C7698.3000109@redhat.com> Message-ID: <5423FB26.1020500@redhat.com> On 09/19/2014 08:31 PM, Petr Viktorin wrote: > This has been wrong for some time, now I got around to fixing it properly. > It should go to all branches (4.0, 4.1, master). Thank you! This should make our unit tests more stable :-) Worked fine, ACK. Pushed to: master: f3b1471af946c7231447b36ea4196bb3278d6a1b ipa-4-1: 5cae98912de64c793f8589fba0a0521823648bdb ipa-4-0: 6f100c50f0c9d125ae09fd7a84ae2f801a3707fd Martin From mkosek at redhat.com Thu Sep 25 11:24:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 13:24:52 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure In-Reply-To: <5422841D.8080205@redhat.com> References: <53F76AB4.5000708@redhat.com> <5422841D.8080205@redhat.com> Message-ID: <5423FB84.8070105@redhat.com> On 09/24/2014 10:43 AM, Martin Kosek wrote: > On 08/22/2014 06:07 PM, Petr Viktorin wrote: >> 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? > > This works pretty nicely, I liked the service.py extension. > > My test output: > > # ipa-ldap-updater --upgrade > Upgrading IPA: > [1/10]: stopping directory server > [2/10]: saving configuration > [3/10]: disabling listeners > [4/10]: starting directory server > [5/10]: preparing server upgrade > PRE_SCHEMA_UPDATE > [6/10]: updating schema > ... > [7/10]: upgrading server > [error] ValueError: Ha! > [cleanup]: stopping directory server > [cleanup]: restoring configuration > > # ipactl start > # netstat -putna | grep 389 > ... > tcp6 0 0 10.16.78.147:389 10.16.78.147:37490 ESTABLISHED > 5956/ns-slapd > > So I am willing to ACK if there are no other objections. > > Martin I read the silence as "no objections", so ACK. Pushed to: master: 9a188607fcf68721fc8c38c3c73ee02cac76b58a ipa-4-1: b333e7adc98ff7c5335fbc7ce1bde5b9dfb3f5ef Martin From tbordaz at redhat.com Thu Sep 25 11:45:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Sep 2014 13:45:58 +0200 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth In-Reply-To: <1411148975.18665.5.camel@redhat.com> References: <1411148975.18665.5.camel@redhat.com> Message-ID: <54240076.80001@redhat.com> On 09/19/2014 07:49 PM, Nathaniel McCallum wrote: > This is an optimization from patch 0062 (rescinded) which I think is > worth keeping. There is no ticket for this. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, That is exact that slapi* are doing a intensive usage of the of alloc/free. Using a stack allocated mods would reduce the number of alloc/free but I afraid it will not have a significant impact. For example further slapi_modify_internal is doing tons of alloc/free. Also I think it is not possible to use stack allocated mods. In fact mods will be modified by internal_mod (for example to add 'modifytimestamp', 'modifiersname') and mods will be reallocated. This could also occurs from plugins. Finally if a modify retry occurs, the original mods are freeed. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Sep 25 11:46:00 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Sep 2014 13:46:00 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140924132354.GF31763@hendrix.brq.redhat.com> References: <20140923151101.GE2947@localhost.localdomain> <20140924132354.GF31763@hendrix.brq.redhat.com> Message-ID: <20140925114600.GD3987@localhost.localdomain> On Wed, Sep 24, 2014 at 03:23:54PM +0200, Jakub Hrozek wrote: > On Tue, Sep 23, 2014 at 05:11:01PM +0200, Sumit Bose wrote: > > Hi, > > > > this patch should fix https://fedorahosted.org/freeipa/ticket/4031 and > > with the corresponding SSSD part it would be possible to get the full > > list of group memberships with the id command even for user who didn't > > log in before. > > > > bye, > > Sumit > > So far I only read the patch, no testing was done yet (I'm installing a > separate VM where I'll keep this new plugin for easy comparison and > backwards-compatibility testing) Thank you for the review, please see comments below. > > First, there are some Coverity warnings: > > Error: USE_AFTER_FREE (CWE-825): > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:242: alias: Assigning: "groups" = "new_groups". Now both point to the same storage. > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:246: freed_arg: "free(void *)" frees "groups". > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:252: use_after_free: Using freed pointer "groups". fixed > > Error: CONSTANT_EXPRESSION_RESULT (CWE-398): > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:596: missing_parentheses: "!id_type != SSS_ID_TYPE_GID" is always true regardless of the values of its operands. Did you intend to either negate the entire comparison expression, in which case parentheses would be required around the entire comparison expression to force that interpretation, or negate the sense of the comparison (that is, use '==' rather than '!=')? This occurs as the logical second operand of '||'. fixed > > Error: DEADCODE (CWE-561): > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_single: Condition "request_type == 1U", taking false branch. Now the value of "request_type" cannot be equal to 1. > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_set: Condition "request_type == 3U", taking false branch. Now the value of "request_type" cannot be equal to any of {1, 3}. > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: cannot_set: At condition "request_type == 1U", the value of "request_type" cannot be equal to any of {1, 3}. > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: dead_error_condition: The condition "request_type == 1U" cannot be true. > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:607: dead_error_line: Execution cannot reach this statement "ret = pack_ber_sid(sid_str,...". I thik this is a result of the CONSTANT_EXPRESSION_RESULT issue, since I fixed it this warning should be gone as well. > > See some comments inline. > > > From 23ff38cdea85995b211e73f474bcb4b0d7fb8039 Mon Sep 17 00:00:00 2001 > > From: Sumit Bose > > Date: Tue, 23 Sep 2014 15:55:43 +0200 > > Subject: [PATCH] extdom: add support for new version > > > > Currently the extdom plugin is basically used to translate SIDs of AD > > users and groups to names and POSIX IDs. > > > > With this patch a new version is added which will return the full member > > list for groups and the full list of group memberships for a user. > > Additionally the gecos field, the home directory and the login shell of a > > user are returned and an optional list of key-value pairs which > > currently will contain the SID of the requested object if available. > > > > https://fedorahosted.org/freeipa/ticket/4031 > > --- > > .../ipa-extdom-extop/ipa_extdom.h | 29 +- > > .../ipa-extdom-extop/ipa_extdom_common.c | 850 +++++++++++++++------ > > .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- > > 3 files changed, 640 insertions(+), 267 deletions(-) > > > > diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > index 5f834a047a579104cd2589ce417c580c1c5388d3..548ee74f561c474854c049726c4c3e71da5cbbea 100644 > > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > @@ -64,6 +64,7 @@ > > #include > > > > #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" > > +#define EXOP_EXTDOM_V2_OID "2.16.840.1.113730.3.8.10.4.1" > > It's a bit odd that this control is called V1 in the SSSD tree and V2 in > the IPA tree. It's not wrong, just strange maybe. you are right, I renamed the versions here. > > > > > -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > - struct extdom_res **res) > > +int check_request(struct extdom_req *req, enum extdom_version version) > > +{ > > + if (version == EXTDOM_V1) { > > + if (req->request_type == REQ_FULL_WITH_GROUPS) { > > + return LDAP_PROTOCOL_ERROR; > > + } > > + } > > Any particular reason why these conditions are nested and not and-ed ? > Did you expect more under the EXTDOM_V1 condition? I'm not expecting them, but who knows :-) I think this way it is more clear that we are testing features of a specific version here. > > > + > > + return LDAP_SUCCESS; > > +} > > + > > +static int get_buffer(size_t *_buf_len, char **_buf) > > { > > - int ret; > > - char *domain_name = NULL; > > - char *sid_str = NULL; > > - size_t buf_len; > > - char *buf = NULL; > > long pw_max; > > long gr_max; > > - struct pwd_grp pg_data; > > - struct passwd *pwd_result = NULL; > > - struct group *grp_result = NULL; > > - enum sss_id_type id_type; > > - char *fq_name = NULL; > > - char *sep; > > - > > + size_t buf_len; > > + char *buf; > > > > pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); > > gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); > > @@ -211,302 +212,655 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > return LDAP_OPERATIONS_ERROR; > > } > > > > - switch (req->input_type) { > > - case INP_POSIX_UID: > > - if (req->request_type == REQ_SIMPLE) { > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > - &id_type); > > + *_buf_len = buf_len; > > + *_buf = buf; > > + > > + return LDAP_SUCCESS; > > +} > > + > > +static int get_user_grouplist(const char *name, gid_t gid, > > + size_t *_ngroups, gid_t **_groups ) > > +{ > > + int ret; > > + int ngroups; > > + gid_t *groups; > > + gid_t *new_groups; > > + > > + ngroups = 128; > > I was wondering whether to use _SC_NGROUPS_MAX or NGROUPS_MAX here, but > I guess you're right it's very unlikely that a user will be a member of > more than 128 groups so we'd just clinge to more memory than needed.. > > > + groups = malloc(ngroups * sizeof(gid_t)); > > + if (groups == NULL) { > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + ret = getgrouplist(name, gid, groups, &ngroups); > > + if (ret == -1) { > > + new_groups = realloc(groups, ngroups); > > + if (new_groups == NULL) { > > + free(groups); > > + return LDAP_OPERATIONS_ERROR; > > + } > > + groups = new_groups; > > + > > + ret = getgrouplist(name, gid, groups, &ngroups); > > + if (ret == -1) { > > + free(groups); > > + ret = LDAP_OPERATIONS_ERROR; > > + } > > + } > > + > > + *_ngroups = ngroups; > > + *_groups = groups; > > + > > + return LDAP_SUCCESS; > > +} > > + > > +static int pack_ber_sid(const char *sid, struct berval **berval) > > +{ > > + BerElement *ber = NULL; > > + int ret; > > + > > + ber = ber_alloc_t( LBER_USE_DER ); > > + if (ber == NULL) { > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + ret = ber_printf(ber,"{es}", RESP_SID, sid); > > + if (ret == -1) { > > + ber_free(ber, 1); > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + ret = ber_flatten(ber, berval); > > + ber_free(ber, 1); > > + if (ret == -1) { > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + return LDAP_SUCCESS; > > +} > > + > > +#define SSSD_SYSDB_SID_STR "objectSIDString" > > + > > +static int pack_ber_user(const char *domain_name, const char *user_name, > > + uid_t uid, gid_t gid, > > + const char *gecos, const char *homedir, > > + const char *shell, const char *sid_str, > > + struct berval **berval) > > +{ > > + BerElement *ber = NULL; > > + int ret; > > + enum response_types response_type; > > + size_t ngroups; > > + gid_t *groups = NULL; > > + size_t buf_len; > > + char *buf = NULL; > > + struct group grp; > > + struct group *grp_result; > > + size_t c; > > + char *locat; > > + char *short_user_name = NULL; > > + const char *single_value_string_array[] = {NULL, NULL}; > > + > > + if (gecos == NULL && homedir == NULL && shell == NULL) { > > + response_type = RESP_USER; > > + } else { > > + response_type = RESP_USER_GROUPLIST; > > + } > > + > > + short_user_name = strdup(user_name); > > + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > Some functions in the code use strchr to fund the at-sign, some use > strrch. Could we standardize on one or the other? Do you expect some > usernames with an at-sign in them? I think the 'rr' version was just a typo, I changed it to 'r'. > > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > + locat[0] = '\0'; > > } else { > > - id_type = SSS_ID_TYPE_UID; > > - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, > > - buf_len, &pwd_result); > > + ret = LDAP_NO_SUCH_OBJECT; > > + goto done; > > } > > + } > > > > - domain_name = strdup(req->data.posix_uid.domain_name); > > - break; > > - case INP_POSIX_GID: > > - if (req->request_type == REQ_SIMPLE) { > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > - &id_type); > > + ber = ber_alloc_t( LBER_USE_DER ); > > + if (ber == NULL) { > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, > > + uid, gid); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + if (response_type == RESP_USER_GROUPLIST) { > > + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); > > + if (ret != LDAP_SUCCESS) { > > + goto done; > > + } > > + > > + ret = get_buffer(&buf_len, &buf); > > + if (ret != LDAP_SUCCESS) { > > + goto done; > > + } > > + > > + ret = ber_printf(ber,"sss", gecos, homedir, shell); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + ret = ber_printf(ber,"{"); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + for (c = 0; c < ngroups; c++) { > > + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); > > + if (ret != 0) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + if (grp_result == NULL) { > > + ret = LDAP_NO_SUCH_OBJECT; > > + goto done; > > I wanted to check if you think it's better to continue or fail here. Did > you opt for failing because you were afraid of missing some deny access > checks in case we couldn't resolv a group? I think there is a disconnect if getgrouplist() returns a GID that cannot be resolved so I prefer an error in this case. > > > + } > > + > > + ret = ber_printf(ber, "s", grp.gr_name); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + } > > + > > + ret = ber_printf(ber,"}"); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + single_value_string_array[0] = sid_str; > > + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, > > + single_value_string_array); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + } > > + > > + ret = ber_printf(ber,"}}"); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + ret = ber_flatten(ber, berval); > > + if (ret == -1) { > > + ret = LDAP_OPERATIONS_ERROR; > > + goto done; > > + } > > + > > + ret = LDAP_SUCCESS; > > +done: > > + free(short_user_name); > > + free(groups); > > + free(buf); > > + ber_free(ber, 1); > > + return ret; > > +} > > + > > +static int pack_ber_group(const char *domain_name, const char *group_name, > > + gid_t gid, char **members, const char *sid_str, > > + struct berval **berval) > > +{ > > + BerElement *ber = NULL; > > + int ret; > > + size_t c; > > + char *locat; > > + char *short_group_name = NULL; > > + const char *single_value_string_array[] = {NULL, NULL}; > > + > > + short_group_name = strdup(group_name); > > + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > + locat[0] = '\0'; > > } else { > > - id_type = SSS_ID_TYPE_GID; > > - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, > > - buf_len, &grp_result); > > + ret = LDAP_NO_SUCH_OBJECT; > > + goto done; > > } > > + } > > > > - domain_name = strdup(req->data.posix_gid.domain_name); > > - break; > > - case INP_SID: > > - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); > > - if (ret != 0) { > > + ber = ber_alloc_t( LBER_USE_DER ); > > + if (ber == NULL) { > > + return LDAP_OPERATIONS_ERROR; > > + } > > + > > + ret = ber_printf(ber,"{e{ssi", members == NULL ? RESP_GROUP > > + : RESP_GROUP_MEMBERS, > > Each pack_ber_group is called like this: > 718 if (request_type == REQ_FULL) { > 719 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > 720 NULL, NULL, berval); > 721 } else { > 722 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > 723 grp.gr_mem, sid, berval); > 724 } > > And then you guess the request_type again based on the parameter > values. Isn't it safer to add the request type parameter avoid the if-else > switch in the callers? Or were you trying to be on the safe side to avoid > checking the validity members array in the pack_ber_group function and have > the array set to NULL by the caller? You are right, the if-block is odd. Instead of the request_type I added the response_type to the argument list of pack_ber_user() and pack_ber_group() which I think is more natural because it is the response that is packed. > > The rest of the file looks to me, just the same "issue" with guessing the > request type is repeated. > New version attached. bye, Sumit -------------- next part -------------- From f7de5e8330c3bdd6d9d21335df6c04e54ce19ed8 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 23 Sep 2014 15:55:43 +0200 Subject: [PATCH] extdom: add support for new version Currently the extdom plugin is basically used to translate SIDs of AD users and groups to names and POSIX IDs. With this patch a new version is added which will return the full member list for groups and the full list of group memberships for a user. Additionally the gecos field, the home directory and the login shell of a user are returned and an optional list of key-value pairs which currently will contain the SID of the requested object if available. https://fedorahosted.org/freeipa/ticket/4031 --- .../ipa-extdom-extop/ipa_extdom.h | 29 +- .../ipa-extdom-extop/ipa_extdom_common.c | 828 ++++++++++++++------- .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- 3 files changed, 617 insertions(+), 268 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 5f834a047a579104cd2589ce417c580c1c5388d3..90f8390d871a698dc00ef56c41be0749eaa13424 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -64,6 +64,7 @@ #include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" +#define EXOP_EXTDOM_V1_OID "2.16.840.1.113730.3.8.10.4.1" #define IPA_EXTDOM_PLUGIN_NAME "ipa-extdom-extop" #define IPA_EXTDOM_FEATURE_DESC "IPA trusted domain ID mapper" @@ -71,6 +72,11 @@ #define IPA_PLUGIN_NAME IPA_EXTDOM_PLUGIN_NAME +enum extdom_version { + EXTDOM_V0 = 0, + EXTDOM_V1 +}; + enum input_types { INP_SID = 1, INP_NAME, @@ -80,14 +86,17 @@ enum input_types { enum request_types { REQ_SIMPLE = 1, - REQ_FULL + REQ_FULL, + REQ_FULL_WITH_GROUPS }; enum response_types { RESP_SID = 1, RESP_NAME, RESP_USER, - RESP_GROUP + RESP_GROUP, + RESP_USER_GROUPLIST, + RESP_GROUP_MEMBERS }; struct extdom_req { @@ -123,11 +132,18 @@ struct extdom_res { char *user_name; uid_t uid; gid_t gid; + char *gecos; + char *home; + char *shell; + size_t ngroups; + char **groups; } user; struct { char *domain_name; char *group_name; gid_t gid; + size_t nmembers; + char **members; } group; } data; }; @@ -150,15 +166,14 @@ struct pwd_grp { struct passwd pwd; struct group grp; } data; + int ngroups; + gid_t *groups; }; int parse_request_data(struct berval *req_val, struct extdom_req **_req); void free_req_data(struct extdom_req *req); +int check_request(struct extdom_req *req, enum extdom_version version); int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res); -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res); -void free_resp_data(struct extdom_res *res); + struct berval **berval); int pack_response(struct extdom_res *res, struct berval **ret_val); #endif /* _IPA_EXTDOM_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 025d37dc5eda05c8db43d4e8176fd7898ed32fe7..57814c5220b6db4b23c56d0078d9719f69b30e55 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -70,6 +70,7 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) * requestType ENUMERATED { * simple (1), * full (2) + * full_with_groups (3) * }, * data InputData * } @@ -179,23 +180,23 @@ void free_req_data(struct extdom_req *req) free(req); } -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res) +int check_request(struct extdom_req *req, enum extdom_version version) +{ + if (version == EXTDOM_V0) { + if (req->request_type == REQ_FULL_WITH_GROUPS) { + return LDAP_PROTOCOL_ERROR; + } + } + + return LDAP_SUCCESS; +} + +static int get_buffer(size_t *_buf_len, char **_buf) { - int ret; - char *domain_name = NULL; - char *sid_str = NULL; - size_t buf_len; - char *buf = NULL; long pw_max; long gr_max; - struct pwd_grp pg_data; - struct passwd *pwd_result = NULL; - struct group *grp_result = NULL; - enum sss_id_type id_type; - char *fq_name = NULL; - char *sep; - + size_t buf_len; + char *buf; pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); @@ -211,302 +212,631 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, return LDAP_OPERATIONS_ERROR; } - switch (req->input_type) { - case INP_POSIX_UID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); - } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, - buf_len, &pwd_result); + *_buf_len = buf_len; + *_buf = buf; + + return LDAP_SUCCESS; +} + +static int get_user_grouplist(const char *name, gid_t gid, + size_t *_ngroups, gid_t **_groups ) +{ + int ret; + int ngroups; + gid_t *groups; + gid_t *new_groups; + + ngroups = 128; + groups = malloc(ngroups * sizeof(gid_t)); + if (groups == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + new_groups = realloc(groups, ngroups); + if (new_groups == NULL) { + free(groups); + return LDAP_OPERATIONS_ERROR; } + groups = new_groups; - domain_name = strdup(req->data.posix_uid.domain_name); - break; - case INP_POSIX_GID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + free(groups); + return LDAP_OPERATIONS_ERROR; + } + } + + *_ngroups = ngroups; + *_groups = groups; + + return LDAP_SUCCESS; +} + +static int pack_ber_sid(const char *sid, struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{es}", RESP_SID, sid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +#define SSSD_SYSDB_SID_STR "objectSIDString" + +static int pack_ber_user(enum response_types response_type, + const char *domain_name, const char *user_name, + uid_t uid, gid_t gid, + const char *gecos, const char *homedir, + const char *shell, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + size_t ngroups; + gid_t *groups = NULL; + size_t buf_len; + char *buf = NULL; + struct group grp; + struct group *grp_result; + size_t c; + char *locat; + char *short_user_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + short_user_name = strdup(user_name); + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_GID; - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, - buf_len, &grp_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; } + } - domain_name = strdup(req->data.posix_gid.domain_name); - break; - case INP_SID: - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, + uid, gid); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (response_type == RESP_USER_GROUPLIST) { + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { goto done; } - sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); - if (sep == NULL) { + ret = ber_printf(ber,"sss", gecos, homedir, shell); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - ret = asprintf(&domain_name, "%s", sep+1); + ret = ber_printf(ber,"{"); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; - domain_name = NULL; /* content is undefined according to - asprintf(3) */ - goto done; - } - - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - break; - case SSS_ID_TYPE_GID: - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); - break; - default: + goto done; + } + + for (c = 0; c < ngroups; c++) { + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = ber_printf(ber, "s", grp.gr_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - break; - case INP_NAME: - ret = asprintf(&fq_name, "%s%c%s", req->data.name.object_name, - SSSD_DOMAIN_SEPARATOR, - req->data.name.domain_name); + + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; - fq_name = NULL; /* content is undefined according to - asprintf(3) */ goto done; } + } + + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + ret = LDAP_SUCCESS; +done: + free(short_user_name); + free(groups); + free(buf); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_group(enum response_types response_type, + const char *domain_name, const char *group_name, + gid_t gid, char **members, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + size_t c; + char *locat; + char *short_group_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + short_group_name = strdup(group_name); + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - if (ret == 0 && pwd_result == NULL) { /* no user entry found */ - id_type = SSS_ID_TYPE_GID; - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + } + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssi", response_type, domain_name, short_group_name, + gid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + if (response_type == RESP_GROUP_MEMBERS) { + ret = ber_printf(ber,"{"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + for (c = 0; members[c] != NULL; c++) { + ret = ber_printf(ber, "s", members[c]); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; } } - domain_name = strdup(req->data.name.domain_name); + + ret = ber_printf(ber,"}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + } + + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; + +done: + free(short_group_name); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_name(const char *domain_name, const char *name, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ss}}", RESP_NAME, domain_name, name); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +static int handle_uid_request(enum request_types request_type, uid_t uid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(uid, &sid_str, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getpwuid_r(uid, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_gid_request(enum request_types request_type, gid_t gid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); + if (ret != 0 || id_type != SSS_ID_TYPE_GID) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_sid_request(enum request_types request_type, const char *sid, + struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *domain_name = NULL; + char *fq_name = NULL; + char *object_name = NULL; + char *sep; + size_t buf_len; + char *buf = NULL; + enum sss_id_type id_type; + + ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + + sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR); + if (sep == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + object_name = strndup(fq_name, (sep - fq_name)); + domain_name = strdup(sep + 1); + if (object_name == NULL || domain_name == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_name(domain_name, object_name, berval); + goto done; + } + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + switch(id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid, berval); + break; + case SSS_ID_TYPE_GID: + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid, berval); break; default: - ret = LDAP_PROTOCOL_ERROR; - goto done; - } - - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } else if (ret == 0 && pwd_result == NULL && grp_result == NULL && - sid_str == NULL) { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - - if (domain_name == NULL) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - - ret = create_response(req, &pg_data, sid_str, id_type, domain_name, res); - if (ret != 0) { ret = LDAP_OPERATIONS_ERROR; goto done; } - - ret = LDAP_SUCCESS; - done: - free(buf); free(fq_name); + free(object_name); free(domain_name); - free(sid_str); + free(buf); return ret; } -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res) +static int handle_name_request(enum request_types request_type, + const char *name, const char *domain_name, + struct berval **berval) { - int ret = EFAULT; - char *locat = NULL; - struct extdom_res *res; - - res = calloc(1, sizeof(struct extdom_res)); - if (res == NULL) { - return ENOMEM; + int ret; + char *fq_name = NULL; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, + domain_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + fq_name = NULL; /* content is undefined according to + asprintf(3) */ + goto done; } - switch (req->request_type) { - case REQ_SIMPLE: - switch (req->input_type) { - case INP_SID: - res->response_type = RESP_NAME; - res->data.name.domain_name = strdup(domain_name); - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0 ) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.pwd.pw_name); - break; - case SSS_ID_TYPE_GID: - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.grp.gr_name); - break; - default: - ret = EINVAL; - goto done; - } - - if (res->data.name.domain_name == NULL - || res->data.name.object_name == NULL) { - ret = ENOMEM; - goto done; - } - break; - case INP_NAME: - case INP_POSIX_UID: - case INP_POSIX_GID: - res->response_type = RESP_SID; - res->data.sid = strdup(sid_str); - if (res->data.sid == NULL) { - ret = ENOMEM; - goto done; - } - break; - default: - ret = EINVAL; - goto done; - } - break; - case REQ_FULL: - switch (id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - res->response_type = RESP_USER; - res->data.user.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.user.user_name = - strdup(pg_data->data.pwd.pw_name); - - if (res->data.user.domain_name == NULL - || res->data.user.user_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.user.uid = pg_data->data.pwd.pw_uid; - res->data.user.gid = pg_data->data.pwd.pw_gid; - break; - case SSS_ID_TYPE_GID: - res->response_type = RESP_GROUP; - res->data.group.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.group.group_name = - strdup(pg_data->data.grp.gr_name); - - if (res->data.group.domain_name == NULL - || res->data.group.group_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.group.gid = pg_data->data.grp.gr_gid; - break; - default: - ret = EINVAL; - goto done; + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; } - break; - default: - ret = EINVAL; - goto done; + goto done; + } } - ret = 0; - -done: - if (ret == 0) { - *_res = res; + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); } else { - free_resp_data(res); - } + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (pwd_result != NULL) { + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } else { /* no user entry found */ + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } - if (locat != NULL) { - locat[0] = SSSD_DOMAIN_SEPARATOR; + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } } +done: + free(fq_name); + free(sid_str); + free(buf); + return ret; } -void free_resp_data(struct extdom_res *res) +int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, + struct berval **berval) { - if (res == NULL) { - return; - } + int ret; + + switch (req->input_type) { + case INP_POSIX_UID: + ret = handle_uid_request(req->request_type, req->data.posix_uid.uid, + req->data.posix_uid.domain_name, berval); - switch (res->response_type) { - case RESP_SID: - free(res->data.sid); break; - case RESP_NAME: - free(res->data.name.domain_name); - free(res->data.name.object_name); + case INP_POSIX_GID: + ret = handle_gid_request(req->request_type, req->data.posix_gid.gid, + req->data.posix_uid.domain_name, berval); + break; - case RESP_USER: - free(res->data.user.domain_name); - free(res->data.user.user_name); + case INP_SID: + ret = handle_sid_request(req->request_type, req->data.sid, berval); break; - case RESP_GROUP: - free(res->data.group.domain_name); - free(res->data.group.group_name); + case INP_NAME: + ret = handle_name_request(req->request_type, req->data.name.object_name, + req->data.name.domain_name, berval); + break; + default: + ret = LDAP_PROTOCOL_ERROR; + goto done; } - free(res); + +done: + + return ret; } - int pack_response(struct extdom_res *res, struct berval **ret_val) { BerElement *ber = NULL; diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index 9315da260ee3de660ea8ff708950945110da37e3..aa66c145bc6cf2b77fdfe37be18da67588dc0439 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -49,6 +49,7 @@ Slapi_PluginDesc ipa_extdom_plugin_desc = { static char *ipa_extdom_oid_list[] = { EXOP_EXTDOM_OID, + EXOP_EXTDOM_V1_OID, NULL }; @@ -71,8 +72,8 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) struct berval *req_val = NULL; struct berval *ret_val = NULL; struct extdom_req *req = NULL; - struct extdom_res *res = NULL; struct ipa_extdom_ctx *ctx; + enum extdom_version version; ret = slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid); if (ret != 0) { @@ -82,7 +83,11 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) } LOG("Received extended operation request with OID %s\n", oid); - if (strcasecmp(oid, EXOP_EXTDOM_OID) != 0) { + if (strcasecmp(oid, EXOP_EXTDOM_OID) == 0) { + version = EXTDOM_V0; + } else if (strcasecmp(oid, EXOP_EXTDOM_V1_OID) == 0) { + version = EXTDOM_V1; + } else { return SLAPI_PLUGIN_EXTENDED_NOT_HANDLED; } @@ -107,21 +112,21 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) goto done; } - ret = handle_request(ctx, req, &res); + ret = check_request(req, version); + if (ret != LDAP_SUCCESS) { + rc = LDAP_UNWILLING_TO_PERFORM; + err_msg = "Error in request data.\n"; + goto done; + } + + ret = handle_request(ctx, req, &ret_val); if (ret != LDAP_SUCCESS) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to handle the request.\n"; goto done; } - ret = pack_response(res, &ret_val); - if (ret != LDAP_SUCCESS) { - rc = LDAP_OPERATIONS_ERROR; - err_msg = "Failed to pack the response.\n"; - goto done; - } - - ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, EXOP_EXTDOM_OID); + ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); if (ret != 0) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to set the OID for the response.\n"; @@ -139,7 +144,6 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) done: free_req_data(req); - free_resp_data(res); if (err_msg != NULL) { LOG("%s", err_msg); } -- 1.8.5.3 From jcholast at redhat.com Thu Sep 25 12:47:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Sep 2014 14:47:49 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <5423D7AE.2090306@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> <5423D7AE.2090306@redhat.com> Message-ID: <54240EF5.3060801@redhat.com> Dne 25.9.2014 v 10:51 Martin Basti napsal(a): > On 19/09/14 14:30, Jan Cholasta wrote: >> Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >>> On 01/09/14 16:26, Martin Basti wrote: >>>> On 28/08/14 14:01, Jan Cholasta wrote: >>>>> 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 >>>>> >>>> 3) skipped as we discuss on IRC >>>> >>>> Updated patch attached >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Please review, this should be in 4.1 >> >> 1) The patch need a rebase on top of current ipa-4-1. > I can apply it (Am I doing something wrong?) >> >> >> 2) You can remove import pwd from service.py, it is no longer used there. >> >> >> 3) Are named constants for the autobind argument the right thing to >> do? It is a tri-state which can be expressed with None/True/False. >> (I'm just asking, I don't have a strong opinion on this.) >> > As we discussed on IRC, using None/True/False, is not good approach. > Updated patch attached > ACK, but the patch still does not apply cleanly on ipa-4-1: $ git apply freeipa-mbasti-0116.3-Refactoring-of-autobind-object_exists.patch error: patch failed: ipaserver/install/service.py:20 error: ipaserver/install/service.py: patch does not apply -- Jan Cholasta From pviktori at redhat.com Thu Sep 25 12:56:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 14:56:38 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <5422B41F.8090408@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> <5422AF38.8030209@redhat.com> <5422B10D.6010303@redhat.com> <5422B41F.8090408@redhat.com> Message-ID: <54241106.3030709@redhat.com> On 09/24/2014 02:07 PM, Petr Viktorin wrote: > On 09/24/2014 01:54 PM, Petr Spacek wrote: >> On 24.9.2014 13:47, Petr Viktorin wrote: >>> On 09/23/2014 06:00 PM, Petr Spacek wrote: >>>> On 22.9.2014 14:09, Petr Viktorin wrote: >>>>> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>>>>> On 22.9.2014 10:38, Martin Kosek wrote: >>>>>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>>>>> >>>>>>>>>> See ticket & commit message for details. >>>>>>>>> >>>>>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>>>>> version just >>>>>>>>> hammer DNS server with as many DNS queries as it can send? >>>>>>>> > [...] >> >> LGTM except one nitpick I didn't see before: >> >>> + if not options.wait_for_dns or self.check_dns(replica_fqdn): >>> + self.log.debug('%s A/AAAA record resolvable', replica_fqdn) >>> + return >> >> This will print message >> '%s A/AAAA record resolvable', replica_fqdn >> even if I use switch --no-wait-for-dns >> >> This is sooo minor detail that it can be deferred, please open a ticket >> if you don't plan to send new version of the patch. > > You're right. > Let's do it correctly now; this isn't worth the overhead of a ticket. > Based on discussion more with Petr, I extended the list of handled exceptions. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0645.5-ipa-replica-prepare-Wait-for-the-DNS-entry-to-be-res.patch Type: text/x-patch Size: 4359 bytes Desc: not available URL: From pvoborni at redhat.com Thu Sep 25 12:56:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 14:56:55 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5422CFB0.6000702@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> Message-ID: <54241117.9090504@redhat.com> >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4149 >>> >> 5. You've removed 'idnssoamname' and 'force' from Web UI but >> dnszone-add precallback still uses these params. What is the intended >> purpose? > User should use modify dialog in webUI for zones. > Precallback fills default value for idnsmname from LDAP. > with --force there will be no validation of user specified soa mname Issue with web ui is that it can't call dnszone-mod with --force option. Should be fixed separately. > >> Unrelated to this patch set: >> b. Web UI doesn't have means to call dnszone-mod with --force option > I'm not sure what you mean, it didn't do that before my patches. See #5 > > Updated patches attached > Review of new version: All new issues are nitpicks. If somebody else thinks they are OK and if pspacek's functional tests pass then ACK. Patch: 114: ACK Patch: 115: ACK Patch: 120 1) Why is there: `default=None, # value will be added in precallback from ldap` ? Static 'default' is by default `None` 2) Wonder if RequirementError would be a better fit: + raise errors.ValidationError( + name='name_server', + error=_(u"is required")) Patch 121: 3) + if ns_hostname: + ns_hostname = normalize_zone(ns_hostname) + ns_hostname = unicode(ns_hostname) try: api.Command.dnszone_add(unicode(name), - idnssoamname=unicode(ns_main), + idnssoamname=ns_hostname, If `ns_hostname` is '' then it will not be converted to unicode. I'm not sure if it can cause an issue. Patch 123: ACK Patch 124: ACK Patch 125: ACK -- Petr Vobornik From mbasti at redhat.com Thu Sep 25 13:06:32 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 15:06:32 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <54240EF5.3060801@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> <5423D7AE.2090306@redhat.com> <54240EF5.3060801@redhat.com> Message-ID: <54241358.7080701@redhat.com> On 25/09/14 14:47, Jan Cholasta wrote: > Dne 25.9.2014 v 10:51 Martin Basti napsal(a): >> On 19/09/14 14:30, Jan Cholasta wrote: >>> Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >>>> On 01/09/14 16:26, Martin Basti wrote: >>>>> On 28/08/14 14:01, Jan Cholasta wrote: >>>>>> 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 >>>>>> >>>>> 3) skipped as we discuss on IRC >>>>> >>>>> Updated patch attached >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Please review, this should be in 4.1 >>> >>> 1) The patch need a rebase on top of current ipa-4-1. >> I can apply it (Am I doing something wrong?) >>> >>> >>> 2) You can remove import pwd from service.py, it is no longer used >>> there. >>> >>> >>> 3) Are named constants for the autobind argument the right thing to >>> do? It is a tri-state which can be expressed with None/True/False. >>> (I'm just asking, I don't have a strong opinion on this.) >>> >> As we discussed on IRC, using None/True/False, is not good approach. >> Updated patch attached >> > > ACK, but the patch still does not apply cleanly on ipa-4-1: > > $ git apply > freeipa-mbasti-0116.3-Refactoring-of-autobind-object_exists.patch > error: patch failed: ipaserver/install/service.py:20 > error: ipaserver/install/service.py: patch does not apply > Rebased patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0116.3-ipa-4-1-Refactoring-of-autobind-object_exists.patch Type: text/x-patch Size: 9800 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0116.3-Refactoring-of-autobind-object_exists.patch Type: text/x-patch Size: 9784 bytes Desc: not available URL: From tbordaz at redhat.com Thu Sep 25 13:15:20 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Sep 2014 15:15:20 +0200 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <1411149239.18665.7.camel@redhat.com> References: <1411149239.18665.7.camel@redhat.com> Message-ID: <54241568.4000107@redhat.com> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: > This prevents synchronization when an authentication collision occurs. > > https://fedorahosted.org/freeipa/ticket/4493 > > NOTE: this patch is related to the above ticket, but does not solve it. > For the solution, please see patch 0064. This behavior fix is from patch > 0062 (rescinded) and is worth keeping. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, . My understanding is that during a pre_bind, the plugins validates token codes (for example "HOTP") checking that step ranges [-25..+25]. As soon as the token is valid, the new HOTPcounter is written in the entry. But in case of negative steps,I believe the otp-decrement plugin will reject this update. If TOTPwatermark is updated and there is a second token code, then clockOffset is also updated. This update is done during a pre_bind, so if there are parallel binds on the server, there is a possibility that TOTPwatermark is updated from a bind and 'clockOffset' updated from an other bind. An option is to do a single internal modify to update both. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Sep 25 13:22:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 15:22:19 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <54241117.9090504@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <54241117.9090504@redhat.com> Message-ID: <5424170B.6060504@redhat.com> On 25/09/14 14:56, Petr Vobornik wrote: >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4149 >>>> > >>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>> dnszone-add precallback still uses these params. What is the intended >>> purpose? >> User should use modify dialog in webUI for zones. >> Precallback fills default value for idnsmname from LDAP. >> with --force there will be no validation of user specified soa mname > > Issue with web ui is that it can't call dnszone-mod with --force > option. Should be fixed separately. > >> >>> Unrelated to this patch set: >>> b. Web UI doesn't have means to call dnszone-mod with --force option >> I'm not sure what you mean, it didn't do that before my patches. > > See #5 > >> >> Updated patches attached >> > > Review of new version: > > All new issues are nitpicks. If somebody else thinks they are OK and > if pspacek's functional tests pass then ACK. > > Patch: 114: ACK > Patch: 115: ACK > > Patch: 120 > > 1) Why is there: > `default=None, # value will be added in precallback from ldap` ? > > Static 'default' is by default `None` You're right. I'll leave there only comment. > > 2) Wonder if RequirementError would be a better fit: > + raise errors.ValidationError( > + name='name_server', > + error=_(u"is required")) I tried it and ipa currently returns RequirementError, I will change it > > Patch 121: > 3) > + if ns_hostname: > + ns_hostname = normalize_zone(ns_hostname) > + ns_hostname = unicode(ns_hostname) > > try: > api.Command.dnszone_add(unicode(name), > - idnssoamname=unicode(ns_main), > + idnssoamname=ns_hostname, > > If `ns_hostname` is '' then it will not be converted to unicode. I'm > not sure if it can cause an issue. > ns_hostname values can be only None or DNSName instance, DNSName instance is always non_zero. > Patch 123: ACK > Patch 124: ACK > Patch 125: ACK -- Martin Basti From pspacek at redhat.com Thu Sep 25 13:23:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Sep 2014 15:23:05 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <54241106.3030709@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> <5422AF38.8030209@redhat.com> <5422B10D.6010303@redhat.com> <5422B41F.8090408@redhat.com> <54241106.3030709@redhat.com> Message-ID: <54241739.7040409@redhat.com> On 25.9.2014 14:56, Petr Viktorin wrote: > On 09/24/2014 02:07 PM, Petr Viktorin wrote: >> On 09/24/2014 01:54 PM, Petr Spacek wrote: >>> On 24.9.2014 13:47, Petr Viktorin wrote: >>>> On 09/23/2014 06:00 PM, Petr Spacek wrote: >>>>> On 22.9.2014 14:09, Petr Viktorin wrote: >>>>>> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>>>>>> On 22.9.2014 10:38, Martin Kosek wrote: >>>>>>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>>>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>>>>>> >>>>>>>>>>> See ticket & commit message for details. >>>>>>>>>> >>>>>>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>>>>>> version just >>>>>>>>>> hammer DNS server with as many DNS queries as it can send? >>>>>>>>> >> [...] >>> >>> LGTM except one nitpick I didn't see before: >>> >>>> + if not options.wait_for_dns or self.check_dns(replica_fqdn): >>>> + self.log.debug('%s A/AAAA record resolvable', replica_fqdn) >>>> + return >>> >>> This will print message >>> '%s A/AAAA record resolvable', replica_fqdn >>> even if I use switch --no-wait-for-dns >>> >>> This is sooo minor detail that it can be deferred, please open a ticket >>> if you don't plan to send new version of the patch. >> >> You're right. >> Let's do it correctly now; this isn't worth the overhead of a ticket. >> > > Based on discussion more with Petr, I extended the list of handled exceptions. ACK, it works even in corner cases like YXDOMAIN* answer and the like. * "Some name that ought not to exist, does exist." [RFC2136] -- Petr^2 Spacek From pviktori at redhat.com Thu Sep 25 13:32:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 15:32:00 +0200 Subject: [Freeipa-devel] [PATCH] 0645 ipa-replica-prepare: Wait for the DNS entry to be resolvable In-Reply-To: <54241739.7040409@redhat.com> References: <541C67F9.5060309@redhat.com> <541FDA68.9020402@redhat.com> <541FDE71.4090701@redhat.com> <541FE00C.7060405@redhat.com> <54200C73.1070407@redhat.com> <5420116B.7010303@redhat.com> <54219904.1040004@redhat.com> <5422AF38.8030209@redhat.com> <5422B10D.6010303@redhat.com> <5422B41F.8090408@redhat.com> <54241106.3030709@redhat.com> <54241739.7040409@redhat.com> Message-ID: <54241950.6060904@redhat.com> On 09/25/2014 03:23 PM, Petr Spacek wrote: > On 25.9.2014 14:56, Petr Viktorin wrote: >> On 09/24/2014 02:07 PM, Petr Viktorin wrote: >>> On 09/24/2014 01:54 PM, Petr Spacek wrote: >>>> On 24.9.2014 13:47, Petr Viktorin wrote: >>>>> On 09/23/2014 06:00 PM, Petr Spacek wrote: >>>>>> On 22.9.2014 14:09, Petr Viktorin wrote: >>>>>>> On 09/22/2014 01:48 PM, Petr Spacek wrote: >>>>>>>> On 22.9.2014 10:38, Martin Kosek wrote: >>>>>>>>> On 09/22/2014 10:31 AM, Petr Spacek wrote: >>>>>>>>>> On 22.9.2014 10:14, Martin Kosek wrote: >>>>>>>>>>> On 09/19/2014 07:29 PM, Petr Viktorin wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4551 >>>>>>>>>>>> >>>>>>>>>>>> See ticket & commit message for details. >>>>>>>>>>> >>>>>>>>>>> Shouldn't we add a 1 sec sleep between tries? Wouldn't current >>>>>>>>>>> version just >>>>>>>>>>> hammer DNS server with as many DNS queries as it can send? >>>>>>>>>> >>> [...] >>>> >>>> LGTM except one nitpick I didn't see before: >>>> >>>>> + if not options.wait_for_dns or self.check_dns(replica_fqdn): >>>>> + self.log.debug('%s A/AAAA record resolvable', >>>>> replica_fqdn) >>>>> + return >>>> >>>> This will print message >>>> '%s A/AAAA record resolvable', replica_fqdn >>>> even if I use switch --no-wait-for-dns >>>> >>>> This is sooo minor detail that it can be deferred, please open a ticket >>>> if you don't plan to send new version of the patch. >>> >>> You're right. >>> Let's do it correctly now; this isn't worth the overhead of a ticket. >>> >> >> Based on discussion more with Petr, I extended the list of handled >> exceptions. > > ACK, it works even in corner cases like YXDOMAIN* answer and the like. > > * "Some name that ought not to exist, does exist." [RFC2136] > Thanks for the review! Pushed to: master: ffe4417c630537b1fd51292c86877fbea66862fb ipa-4-1: ee4a023cf1d2cf5f3d10386979d00d96410e9e80 ipa-4-0: 179423761eb297dd62f0fa9bc33a4aa849d8bb34 -- Petr? From mbasti at redhat.com Thu Sep 25 14:15:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Sep 2014 16:15:52 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <54205CA9.8000708@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> <541C14A4.2010907@redhat.com> <541C25CB.8060801@redhat.com> <54205CA9.8000708@redhat.com> Message-ID: <54242398.4000507@redhat.com> On 22/09/14 19:30, Martin Basti wrote: > On 19/09/14 14:47, Jan Cholasta wrote: >> Dne 19.9.2014 v 13:33 Martin Basti napsal(a): >>> On 02/09/14 11:59, Martin Basti wrote: >>>> On 02/09/14 09:10, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>>>>> This patch allows to disable service in LDAP to prevents service >>>>>> to be >>>>>> started by "ipactl restart" >>>>>> >>>>>> Required by DNSSEC >>>>>> >>>>>> Patch attached >>>>> >>>>> I don't think the extra argument in ldap_enable is necessary. It >>>>> should enable the service no matter if the entry existed before or >>>>> not. >>>>> >>>>> Similarly, in ldap_disable you should not raise an error when the >>>>> entry is not found, because that already makes the service disabled. >>>>> >>>>> Honza >>>>> >>>> Updated patch attached >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Please review, this should be in 4.1 >>> >>> -- >>> Martin Basti >> >> 1) ipaConfigString is case-insensitive, so you need to look for the >> string "enabledService" in a case-insensitive way. >> >> >> 2) Don't say "failed to enable ..." when the service is already >> enabled. It is not a failure. Same for disabled. >> >> >> 3) Missing ipaConfigString is nothing to warn about. >> >> >> 4) You should log success in both ldap_enable/ldap_disable. >> >> >> 5) The except below update_entry should say "except >> errors.EmptyModlist". >> >> > Thank you, > > updated patch attached > Updated patch attached. I modified ldap_disable to use search function. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0118.4-LDAP-disable-service.patch Type: text/x-patch Size: 3849 bytes Desc: not available URL: From dkupka at redhat.com Thu Sep 25 14:17:13 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 25 Sep 2014 16:17:13 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54231354.7050102@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> Message-ID: <542423E9.4020203@redhat.com> On 09/24/2014 08:54 PM, Martin Basti wrote: > On 24/09/14 15:44, David Kupka wrote: >> On 09/23/2014 08:25 PM, Martin Basti wrote: >>> On 23/09/14 13:23, David Kupka wrote: >>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>> ... >>>>> 1) >>>>> + if options.unattended: >>>>> + for ip in ip_addresses: >>>>> + if search_reverse_zones and >>>>> find_reverse_zone(str(ip)): >>>>> + # reverse zone is already in LDAP >>>>> + continue >>>>> + for rz in ret_reverse_zones: >>>>> + if verify_reverse_zone(rz, ip): >>>>> + # reverse zone was entered by user >>>>> + break >>>>> + else: >>>>> + rz = get_reverse_zone_default(str(ip)) >>>>> + ret_reverse_zones.append(rz) >>>>> + elif options.reverse_zones or create_reverse(): >>>>> + for ip in ip_addresses: >>>>> + if search_reverse_zones and >>>>> find_reverse_zone(str(ip)): >>>>> + # reverse zone is already in LDAP >>>>> + continue >>>>> + for rz in ret_reverse_zones: >>>>> + if verify_reverse_zone(rz, ip): >>>>> + # reverse zone was entered by user >>>>> + break >>>>> + else: >>>>> + rz = get_reverse_zone_default(str(ip)) >>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>> + ret_reverse_zones.append(rz) >>>>> + else: >>>>> + options.no_reverse = True >>>>> + ret_reverse_zones = [] >>>>> >>>>> You can make it shorter without duplications: >>>>> >>>>> # this ifs can be in one line >>>>> if not options.unatended: >>>>> if not options.reverse_zones >>>>> if not create_reverse(): >>>>> options.no_reverse=True >>>>> return [] >>>>> >>>>> for ip in ip_addresses: >>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>> # reverse zone is already in LDAP >>>>> continue >>>>> for rz in ret_reverse_zones: >>>>> if verify_reverse_zone(rz, ip): >>>>> # reverse zone was entered by user >>>>> break >>>>> else: >>>>> rz = get_reverse_zone_default(str(ip)) >>>>> if not options.unattended: >>>>> rz = read_reverse_zone(rz, str(ip)) >>>>> ret_reverse_zones.append(rz) >>>>> >>>> >>>> Thanks, I modified it bit different way to alse address recommendation >>>> 3). >>>> >>>>> >>>>> 2) >>>>> Typo? There is no IP address matching reverze_zone %s." >>>>> ---------------------------------------------^^ >>>>> >>>> >>>> Thanks, fixed. >>>> >>>>> >>>>> 3) >>>>> Would be nice to ask user to create new zones only if new zones are >>>>> required. (If all required zones exist in LDAP, you ask user anyway) >>>>> >>>> >>>> I added one more variable and ask only once. >>>> >>>>> 4) >>>>> Ask framework gurus, if installutils module is better place for >>>>> function >>>>> above >>>>> >>>>> >>>> >>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>> >>>>> >>>> >>> NACK, most important point is 7 >>> >>> 1) >>> I'm not sure if this is bug, but interactively is allowed to add only >>> one ip address >>> >>> Unable to resolve IP address for host name >>> Please provide the IP address to be used for this host name: 2001:db8::2 >>> The kerberos protocol requires a Realm name to be defined. >>> >> >> For the sake of infinite usability and UX I rewrote it to ask for >> multiple addresses the same way as for DNS forwarders. Also I really >> simplified IP address checking code when I was in it. I tested it but >> please look at it carefully. >> Also I found that ipa-dns-install and ipa-adtrust-install also accept >> --ip-address param. So I modified ipa-dns-install in the same way as >> ipa-server-install and ipa-replica-install. After discussion with >> tbabej I decided to dont touch ipa-adtrust-install now as it do not >> use specified value at all. I will remove the processing code and mark >> the param as deprecated in separate patch. >> >>> 2) >>> I'm getting error message >>> >>> Invalid reverse zone 10.in-addr.arpa. for IP address 2001:db8::dead:beef >>> Invalid reverse zone 10.in-addr.arpa. for IP address >>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>> >>> - or - >>> >>> Do you want to configure the reverse zone? [yes]: >>> Please specify the reverse zone name >>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP >>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>> Please specify the reverse zone name >>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>> >>> This shouldn't be there >> >> Moved the message to function used when installation is attended by user. >> >>> >>> Could be better to ask user to specific zone for ip address a.b.c.d. >> >> Probably, but lets leave some work for future. >> >>> >>> 4) just nitpick >>> The IPA Master Server will be configured with: >>> ... >>> IP address(es): 2001:db8::dead:beef, fed0:babe:baab:0:21a:4aff:fe10:4e18 >>> ... >>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>> >>> You have label "IP address(es)", so you should use label "Reverse >>> zone(s)" >>> >> >> Fixed. >> >>> 5) >>> ipa-server-install --ip-address=10.16.78.105 >>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>> --setup-dns >>> >>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not sure >>> if this is wrong, but we prevents user to add zone without address in >>> it, so we should prevents, to add empty zone. >>> >> >> It would be nice but not in this patch. >> >>> 6) >>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. vm-105.example.com >>> Directory Manager (existing master) password: >>> >>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>> >>> IMO This should work, right? >>> >>> + sys.exit("There is no IP address matching reverse zone >>> %s." % rz) >>> I expected at least this error to be shown. >> >> Fixed, thanks. >> >>> >>> 7) >>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>> 2001:db8::dead:beef vm-105.example.com >>> Directory Manager (existing master) password: >>> >>> ....... >>> Adding DNS records for vm-105.example.com >>> Values instance has no attribute 'ip_address' >>> >>> Command returns the attribute error. >>> It fails with one --ip-address too. >>> >> >> Sorry, fixed. >> >>> >>> *) Not related with your patch >>> Problem with installation: >>> I'm getting message: >>> IPA server is already configured on this system. >>> Even if I validation wasn't successful and installation was aborted. >>> >>> IPA install detects previous installations by checking state file and >>> restore files. Function get_server_ip_address() stores some data and >>> hosts file and modify the host file, before user agreed installation. >>> This error was there before your patch. >>> https://fedorahosted.org/freeipa/ticket/4561 >>> >>> >>> >> > NACK > > 0) > # ipa-dns-install --ip-address 2001:db8::feed > > 2014-09-24T06:02:13Z DEBUG stderr= > 2014-09-24T06:02:13Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 645, in run_script > return_value = main_function() > > File "/sbin/ipa-dns-install", line 135, in main > ip_addresses = get_server_ip_address(api.env.host, fstore, > options.unattended, options) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 473, in get_server_ip_address > if options.setup_dns: > > 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, > exception: AttributeError: Values instance has no attribute 'setup_dns' Obviously there is no option --setup-dns in ipa-dns-install. Fixed, modified get_server_ip_address function. > > 1) > # ipa-replica-prepare vm-073.example.com --ip-address > 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 > Directory Manager (existing master) password: > > Preparing replica for vm-073.example.com from vm-105.example.com > Creating SSL certificate for the Directory Server > Creating SSL certificate for the dogtag Directory Server > Saving dogtag Directory Server port > Creating SSL certificate for the Web Server > Exporting RA certificate > Copying additional files > Finalizing configuration > Packaging replica information into > /var/lib/ipa/replica-info-vm-073.example.com.gpg > Adding DNS records for vm-073.example.com > Values instance has no attribute 'unattended' > > It should be unatended automatically, or we need add the --unattended > option to ipa-replica-prepare ipa-replica-install is missing --unattended option. I fixed it in my code for now but we should add it there. > > 2) This is nto user friendly, could be IP address check before > installation? > [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address > 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns > --no-forwarders > Directory Manager (existing master) password: > > Run connection check to master > ... > > ... > Restarting the KDC > There is no IP address matching reverse zone 10.in-addr.arpa.. > > LOG: > return_value = main_function() > > File "/sbin/ipa-replica-install", line 721, in main > install_bind(config, options) > > File "/sbin/ipa-replica-install", line 265, in install_bind > reverse_zones = > bindinstance.check_reverse_zones(config.ip_addresses, > options.reverse_zones, options, True) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > line 426, in check_reverse_zones > sys.exit("There is no IP address matching reverse zone %s." % rz) > > 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, > exception: SystemExit: There is no IP address matching reverse zone > 10.in-addr.arpa.. Fixed. Asking everything before actual installation. > > 3) > I'm not sure if sys.exit() is good, replica-install shoudl wrote > something about partially configured system This is quite common in installation scripts. I moved this parts before actual installation. > > 4) I'm not sure if this is the best place to ask about reverse zones > .... > Done configuring the web interface (httpd). > Configuring ipa-otpd > [1/2]: starting ipa-otpd > [2/2]: configuring ipa-otpd to start on boot > Done configuring ipa-otpd. > Applying LDAP updates > Restarting the directory server > Restarting the KDC > Do you want to configure the reverse zone? [yes]: Moved. > > 5) And error > # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx > --setup-dns > .... > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name > [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: > Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-install.log for details: > AttributeError: 'str' object has no attribute 'version' > > LOG: > 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket > conn= > 2014-09-24T06:50:45Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 645, in run_script > return_value = main_function() > > File "/sbin/ipa-replica-install", line 721, in main > install_bind(config, options) > > File "/sbin/ipa-replica-install", line 272, in install_bind > ca_configured=options.setup_ca) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > line 550, in setup > self.__setup_sub_dict() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > line 651, in __setup_sub_dict > if addr.version in (4, 6): > > 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, > exception: AttributeError: 'str' object has no attribute 'version' Fixed. We are using IP addresses as a strings and as a CheckedIPAddress. I swapped them here. > > > *) I don't like this asking to specify zone without IP > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name > [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: > Please specify the reverse zone name [78.16.10.in-addr.arpa.]: > Would be nice. Prefer to do it as a part of more powerfull reverse zone validation logic. > > > **) I'm not sure how often this case can happen: > master and replica without DNS, you run --ipa-dns-install on master then > on replica, then replica DNS installation will not try to find existent > reverse zones in ldap, due configuration in ipa-dns-install. > Maybe you should detect if DNS container exists and then set flag > "search_reverse_zones=True" > > ipa-dns-install: > + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, > options.reverse_zones, options) Same as above. > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-10-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 45576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-10-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 45418 bytes Desc: not available URL: From pspacek at redhat.com Thu Sep 25 14:32:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Sep 2014 16:32:22 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5423D2D4.6080709@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> <5423D2D4.6080709@redhat.com> Message-ID: <54242776.1070800@redhat.com> On 25.9.2014 10:31, Martin Basti wrote: > On 24/09/14 16:24, Martin Basti wrote: >> On 24/09/14 16:05, Martin Basti wrote: >>> On 23/09/14 17:45, Petr Vobornik wrote: >>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>> 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 >>>>> >>>>> >>>> >>>> Review of: >>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>>> >>>> 1. Please follow pep8 for the new code. >>>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>>> Produces 25 erros. >>>> >>>> Only E124 and E128 could be ignored if they are part of old code. >>> >>> I left there some pep8 errors. They don't decrease readability >>> >>>> >>>> Patch 120: >>>> >>>> 3. This patch uses term 'deprecated' in a different meaning than a >>>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO this >>>> usage is correct since the usual understanding of deprecation is that the >>>> param is still usable but user should be prepared that it will be removed >>>> in a future. IMHO DeprecatedParam is badly designed but that's not an >>>> issue of this patch. >>>> >>>> I think we can leave this as is and create a ticket to rename >>>> DeprecatedParam e.g. to RemovedParam. What do you think? >>>> >>> https://fedorahosted.org/freeipa/ticket/4566 >>>> 5. You've removed 'idnssoamname' and 'force' from Web UI but dnszone-add >>>> precallback still uses these params. What is the intended purpose? >>> User should use modify dialog in webUI for zones. >>> Precallback fills default value for idnsmname from LDAP. >>> with --force there will be no validation of user specified soa mname >>> >>> Purpose is a user should let IPA to fill mname with safe value. >>>> Patch 123: >>>> >>>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' shouldn't it >>>> be normalized to contain '.' at the end? Or is it handled by bind-dyndb-ldap? >>> >>> Zone manager (SOA RNAME) can eb relative name, BIND will append zone name. >>> Currently we cant validate if email address is reachable, it doestn matter >>> if it is filled with nonexistent absolute name, or nonexistent relative name. >>> >>>> Unrelated to this patch set: >>>> >>>> a. One is able to run: >>>> # ipa dnszone-remove-permission $zone >>>> multiple times and it always returns success >>>> >>>> Is it intentional? >>> No, it isn't. I will inspect it and I will send additional patch >>> >>>> >>>> b. Web UI doesn't have means to call dnszone-mod with --force option >>> I'm not sure what you mean, it didn't do that before my patches. >>> >>> Updated patches attached >>> >> I accidentally removed one line in previous patchset. >> Updated patches attached >> > Sorry my IDE was too smart, and somehow added its configuration file to commit > and I didn't notice it. > Patches attached. ACK, it works for me. Replica installation and deletion properly adds and deletes records as necessary. I would defer further improvements to https://fedorahosted.org/freeipa/ticket/3343 -- Petr^2 Spacek From pviktori at redhat.com Thu Sep 25 14:39:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Sep 2014 16:39:55 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <54242776.1070800@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> <5423D2D4.6080709@redhat.com> <54242776.1070800@redhat.com> Message-ID: <5424293B.3000502@redhat.com> On 09/25/2014 04:32 PM, Petr Spacek wrote: > On 25.9.2014 10:31, Martin Basti wrote: >> On 24/09/14 16:24, Martin Basti wrote: >>> On 24/09/14 16:05, Martin Basti wrote: >>>> On 23/09/14 17:45, Petr Vobornik wrote: >>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> Review of: >>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>>>> >>>>> >>>>> 1. Please follow pep8 for the new code. >>>>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>>>> Produces 25 erros. >>>>> >>>>> Only E124 and E128 could be ignored if they are part of old code. >>>> >>>> I left there some pep8 errors. They don't decrease readability >>>> >>>>> >>>>> Patch 120: >>>>> >>>>> 3. This patch uses term 'deprecated' in a different meaning than a >>>>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >>>>> this >>>>> usage is correct since the usual understanding of deprecation is >>>>> that the >>>>> param is still usable but user should be prepared that it will be >>>>> removed >>>>> in a future. IMHO DeprecatedParam is badly designed but that's not an >>>>> issue of this patch. >>>>> >>>>> I think we can leave this as is and create a ticket to rename >>>>> DeprecatedParam e.g. to RemovedParam. What do you think? >>>>> >>>> https://fedorahosted.org/freeipa/ticket/4566 >>>>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>>>> dnszone-add >>>>> precallback still uses these params. What is the intended purpose? >>>> User should use modify dialog in webUI for zones. >>>> Precallback fills default value for idnsmname from LDAP. >>>> with --force there will be no validation of user specified soa mname >>>> >>>> Purpose is a user should let IPA to fill mname with safe value. >>>>> Patch 123: >>>>> >>>>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >>>>> shouldn't it >>>>> be normalized to contain '.' at the end? Or is it handled by >>>>> bind-dyndb-ldap? >>>> >>>> Zone manager (SOA RNAME) can eb relative name, BIND will append zone >>>> name. >>>> Currently we cant validate if email address is reachable, it doestn >>>> matter >>>> if it is filled with nonexistent absolute name, or nonexistent >>>> relative name. >>>> >>>>> Unrelated to this patch set: >>>>> >>>>> a. One is able to run: >>>>> # ipa dnszone-remove-permission $zone >>>>> multiple times and it always returns success >>>>> >>>>> Is it intentional? >>>> No, it isn't. I will inspect it and I will send additional patch >>>> >>>>> >>>>> b. Web UI doesn't have means to call dnszone-mod with --force option >>>> I'm not sure what you mean, it didn't do that before my patches. >>>> >>>> Updated patches attached >>>> >>> I accidentally removed one line in previous patchset. >>> Updated patches attached >>> >> Sorry my IDE was too smart, and somehow added its configuration file >> to commit >> and I didn't notice it. >> Patches attached. > > ACK, it works for me. Replica installation and deletion properly adds > and deletes records as necessary. > > I would defer further improvements to > https://fedorahosted.org/freeipa/ticket/3343 > Pushed to: ipa-4-1: b7e3a990369d85dfd12165891cf9142d669a0259 master: bc2eaa145637e1947449ee53548243ab22059805 -- Petr? From edewata at redhat.com Thu Sep 25 14:40:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 25 Sep 2014 09:40:19 -0500 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <20140925072549.GF11503@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> Message-ID: <54242953.1010607@redhat.com> On 9/25/2014 2:25 AM, Alexander Bokovoy wrote: > On Wed, 24 Sep 2014, Endi Sukma Dewata wrote: >> 4. If I understand correctly the description field for the User ID >> Overrides and Group ID Overrides should be optional too because it's >> also used to optionally override the description attribute of the >> original entry. > No, this is description of the override itself. We don't want to > override original description field, if any, we want to provide a way to > document why this override was done. In that case the 'description' probably should have been a MUST. objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA v4' ) BTW, the LDAP schema in the wiki page is outdated: http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust >> 6. Can multiple ID views be applied to the same host? Does the order >> matter? If so, how would the UI manage the order? > No. Single ID view per host. The scheme is actually a bit more complex: > - IPA users: data from main tree is overridden with a data from a > host-specific ID view > - AD users: data from AD is overridden by a data from a default trust > view which is then overridden by a data from a host-specific ID view OK, right now if I apply an ID view to a host that already uses another ID view, the host will be removed silently from the other ID view. Should the operation fail/provide a warning if the host already uses another ID view? >> 7. Related to #6, there probably should be a tab in the Host details >> page showing which ID views apply to it. > There is only a single view and yes, it would be good to add a property > there, linking it to the ID view tab, if possible. I think that field should be editable as well so you can select the ID view from Host details page. >> 9. This probably requires server support. In the "Apply to hosts" >> association dialog, if a host is already added it will still appear in >> the dialog box. As a comparison, a User that has been added into a >> User Group will not appear in the association dialog anymore. > Could be trivially filtered out on Web UI side. It may not be possible if the list of hosts is paged. The UI will not get the full list of hosts, so it won't be able to filter out hosts that are already added but not currently displayed. I'm not sure how important is this, but we did this for some other pages. Since #4 is not a UI issue, patch #754 is ACKed. Other issues can be addressed later. -- Endi S. Dewata From jcholast at redhat.com Thu Sep 25 15:14:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Sep 2014 17:14:25 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <54242398.4000507@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> <541C14A4.2010907@redhat.com> <541C25CB.8060801@redhat.com> <54205CA9.8000708@redhat.com> <54242398.4000507@redhat.com> Message-ID: <54243151.20904@redhat.com> Dne 25.9.2014 v 16:15 Martin Basti napsal(a): > On 22/09/14 19:30, Martin Basti wrote: >> On 19/09/14 14:47, Jan Cholasta wrote: >>> Dne 19.9.2014 v 13:33 Martin Basti napsal(a): >>>> On 02/09/14 11:59, Martin Basti wrote: >>>>> On 02/09/14 09:10, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>>>>>> This patch allows to disable service in LDAP to prevents service >>>>>>> to be >>>>>>> started by "ipactl restart" >>>>>>> >>>>>>> Required by DNSSEC >>>>>>> >>>>>>> Patch attached >>>>>> >>>>>> I don't think the extra argument in ldap_enable is necessary. It >>>>>> should enable the service no matter if the entry existed before or >>>>>> not. >>>>>> >>>>>> Similarly, in ldap_disable you should not raise an error when the >>>>>> entry is not found, because that already makes the service disabled. >>>>>> >>>>>> Honza >>>>>> >>>>> Updated patch attached >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Please review, this should be in 4.1 >>>> >>>> -- >>>> Martin Basti >>> >>> 1) ipaConfigString is case-insensitive, so you need to look for the >>> string "enabledService" in a case-insensitive way. >>> >>> >>> 2) Don't say "failed to enable ..." when the service is already >>> enabled. It is not a failure. Same for disabled. >>> >>> >>> 3) Missing ipaConfigString is nothing to warn about. >>> >>> >>> 4) You should log success in both ldap_enable/ldap_disable. >>> >>> >>> 5) The except below update_entry should say "except >>> errors.EmptyModlist". >>> >>> >> Thank you, >> >> updated patch attached >> > Updated patch attached. I modified ldap_disable to use search function. > ACK. -- Jan Cholasta From mkosek at redhat.com Thu Sep 25 15:13:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 17:13:43 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <5424293B.3000502@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> <5423D2D4.6080709@redhat.com> <54242776.1070800@redhat.com> <5424293B.3000502@redhat.com> Message-ID: <54243127.1040000@redhat.com> On 09/25/2014 04:39 PM, Petr Viktorin wrote: > On 09/25/2014 04:32 PM, Petr Spacek wrote: >> On 25.9.2014 10:31, Martin Basti wrote: >>> On 24/09/14 16:24, Martin Basti wrote: >>>> On 24/09/14 16:05, Martin Basti wrote: >>>>> On 23/09/14 17:45, Petr Vobornik wrote: >>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> Review of: >>>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>>>>> >>>>>> >>>>>> 1. Please follow pep8 for the new code. >>>>>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>>>>> Produces 25 erros. >>>>>> >>>>>> Only E124 and E128 could be ignored if they are part of old code. >>>>> >>>>> I left there some pep8 errors. They don't decrease readability >>>>> >>>>>> >>>>>> Patch 120: >>>>>> >>>>>> 3. This patch uses term 'deprecated' in a different meaning than a >>>>>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >>>>>> this >>>>>> usage is correct since the usual understanding of deprecation is >>>>>> that the >>>>>> param is still usable but user should be prepared that it will be >>>>>> removed >>>>>> in a future. IMHO DeprecatedParam is badly designed but that's not an >>>>>> issue of this patch. >>>>>> >>>>>> I think we can leave this as is and create a ticket to rename >>>>>> DeprecatedParam e.g. to RemovedParam. What do you think? >>>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4566 >>>>>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>>>>> dnszone-add >>>>>> precallback still uses these params. What is the intended purpose? >>>>> User should use modify dialog in webUI for zones. >>>>> Precallback fills default value for idnsmname from LDAP. >>>>> with --force there will be no validation of user specified soa mname >>>>> >>>>> Purpose is a user should let IPA to fill mname with safe value. >>>>>> Patch 123: >>>>>> >>>>>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >>>>>> shouldn't it >>>>>> be normalized to contain '.' at the end? Or is it handled by >>>>>> bind-dyndb-ldap? >>>>> >>>>> Zone manager (SOA RNAME) can eb relative name, BIND will append zone >>>>> name. >>>>> Currently we cant validate if email address is reachable, it doestn >>>>> matter >>>>> if it is filled with nonexistent absolute name, or nonexistent >>>>> relative name. >>>>> >>>>>> Unrelated to this patch set: >>>>>> >>>>>> a. One is able to run: >>>>>> # ipa dnszone-remove-permission $zone >>>>>> multiple times and it always returns success >>>>>> >>>>>> Is it intentional? >>>>> No, it isn't. I will inspect it and I will send additional patch >>>>> >>>>>> >>>>>> b. Web UI doesn't have means to call dnszone-mod with --force option >>>>> I'm not sure what you mean, it didn't do that before my patches. >>>>> >>>>> Updated patches attached >>>>> >>>> I accidentally removed one line in previous patchset. >>>> Updated patches attached >>>> >>> Sorry my IDE was too smart, and somehow added its configuration file >>> to commit >>> and I didn't notice it. >>> Patches attached. >> >> ACK, it works for me. Replica installation and deletion properly adds >> and deletes records as necessary. >> >> I would defer further improvements to >> https://fedorahosted.org/freeipa/ticket/3343 >> > > Pushed to: > ipa-4-1: b7e3a990369d85dfd12165891cf9142d669a0259 > master: bc2eaa145637e1947449ee53548243ab22059805 > I reopened the ticket, we missed update to DNS help page (ipa help dns): https://fedorahosted.org/freeipa/ticket/4149#comment:18 Martin From pvoborni at redhat.com Thu Sep 25 15:23:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 17:23:36 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <54242953.1010607@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> <54242953.1010607@redhat.com> Message-ID: <54243378.2020604@redhat.com> Note: I'll send response also to previous mail. On 25.9.2014 16:40, Endi Sukma Dewata wrote: > On 9/25/2014 2:25 AM, Alexander Bokovoy wrote: >> On Wed, 24 Sep 2014, Endi Sukma Dewata wrote: >>> 4. If I understand correctly the description field for the User ID >>> Overrides and Group ID Overrides should be optional too because it's >>> also used to optionally override the description attribute of the >>> original entry. > >> No, this is description of the override itself. We don't want to >> override original description field, if any, we want to provide a way to >> document why this override was done. > > In that case the 'description' probably should have been a MUST. > > objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP > top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA > v4' ) > > BTW, the LDAP schema in the wiki page is outdated: > http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust New server version which is being developed by Tomas will not have description required. > >>> 6. Can multiple ID views be applied to the same host? Does the order >>> matter? If so, how would the UI manage the order? > >> No. Single ID view per host. The scheme is actually a bit more complex: >> - IPA users: data from main tree is overridden with a data from a >> host-specific ID view >> - AD users: data from AD is overridden by a data from a default trust >> view which is then overridden by a data from a host-specific ID view > > OK, right now if I apply an ID view to a host that already uses another > ID view, the host will be removed silently from the other ID view. > Should the operation fail/provide a warning if the host already uses > another ID view? If something then IMHO warning is better. > >>> 7. Related to #6, there probably should be a tab in the Host details >>> page showing which ID views apply to it. > >> There is only a single view and yes, it would be good to add a property >> there, linking it to the ID view tab, if possible. > > I think that field should be editable as well so you can select the ID > view from Host details page. I'll add readonly field yet. Editable is a bigger task which we don't have time for atm. But should done in later versions. > >>> 9. This probably requires server support. In the "Apply to hosts" >>> association dialog, if a host is already added it will still appear in >>> the dialog box. As a comparison, a User that has been added into a >>> User Group will not appear in the association dialog anymore. > >> Could be trivially filtered out on Web UI side. > > It may not be possible if the list of hosts is paged. The UI will not > get the full list of hosts, so it won't be able to filter out hosts that > are already added but not currently displayed. I'm not sure how > important is this, but we did this for some other pages. UI gets all hosts the view is applied on, so it can be filtered. > > Since #4 is not a UI issue, patch #754 is ACKed. Other issues can be > addressed later. > OK I will addressed(am addressing) other issues separately so this patch doesn't have to be reviewed multiple times. -- Petr Vobornik From edewata at redhat.com Thu Sep 25 16:43:12 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 25 Sep 2014 11:43:12 -0500 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <54243378.2020604@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> <54242953.1010607@redhat.com> <54243378.2020604@redhat.com> Message-ID: <54244620.3030400@redhat.com> On 9/25/2014 10:23 AM, Petr Vobornik wrote: > On 25.9.2014 16:40, Endi Sukma Dewata wrote: >>>> 4. If I understand correctly the description field for the User ID >>>> Overrides and Group ID Overrides should be optional too because it's >>>> also used to optionally override the description attribute of the >>>> original entry. >> >>> No, this is description of the override itself. We don't want to >>> override original description field, if any, we want to provide a way to >>> document why this override was done. >> >> In that case the 'description' probably should have been a MUST. >> >> objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP >> top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA >> v4' ) >> >> BTW, the LDAP schema in the wiki page is outdated: >> http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust > > New server version which is being developed by Tomas will not have > description required. The above schema is actually from Tomas' patch #247-2. So should the description be required or not? Regardless, I think the UI, CLI, and the schema should match. >>>> 6. Can multiple ID views be applied to the same host? Does the order >>>> matter? If so, how would the UI manage the order? >> >>> No. Single ID view per host. The scheme is actually a bit more complex: >>> - IPA users: data from main tree is overridden with a data from a >>> host-specific ID view >>> - AD users: data from AD is overridden by a data from a default trust >>> view which is then overridden by a data from a host-specific ID view >> >> OK, right now if I apply an ID view to a host that already uses another >> ID view, the host will be removed silently from the other ID view. >> Should the operation fail/provide a warning if the host already uses >> another ID view? > > If something then IMHO warning is better. If it's a warning, maybe we can just add a text in the dialog box saying that this will automatically un-apply the hosts from other ID views. Or alternatively, the UI probably can check first, if some of the hosts selected already have ID views it will prompt a confirmation dialog. -- Endi S. Dewata From pvoborni at redhat.com Thu Sep 25 17:07:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Sep 2014 19:07:59 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <20140925072549.GF11503@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> Message-ID: <54244BEF.40000@redhat.com> All issues will be done separately as already stated in other sub-thread. I've removed issues which are discussed in the other sub-thread. On 25.9.2014 09:25, Alexander Bokovoy wrote: > On Wed, 24 Sep 2014, Endi Sukma Dewata wrote: >> >> OK, some comments/questions: >> >> 1. For consistency, the "ID view" should be capitalized into "ID View" >> in the navigation tab, page title, and dialog title. See "ID Ranges" >> as an example. Will be fixed in a new iteration of the server plugin. UI will use it automatically. >> >> 2. The tab titles in the ID view details page are quite long, and the >> "User ID overrides" and "Group ID overrides" labels aren't quite >> appropriate because the ID view can override other attributes too. How >> about using facet groups like in User Groups? For example: >> - applies to: >> - Hosts >> - overrides: >> - Users >> - Groups >> - Settings Will add. >> 3. Since the tab already says "Applied to hosts", the current button >> labels is kind of redundant. How about renaming and reorder the >> buttons like this? >> - Refresh >> - Remove >> - Add >> - Add hosts in host group >> - Remove hosts in host group I agree that it's a little bit redundant. But I think that they describe the operation better. In other association facets the buttons have 'add' and 'remove' titles but they corresponds to 'add-*', 'remove-*' commands. I'm afraid that users would not associate these buttons with idview-(un)apply commands. >> >> 4. If I understand correctly the description field for the User ID... Discussed in other thread... In any way, UI reflects API. > >> 5. Not sure if this is a problem. The search field in User/Group ID >> Overrides can be used to find the overriding attributes, but not the >> "User/Group to override". I already reported it to Tomas. The issue is that the override is saved in LDAP in a UUID form (more or less) and so it doesn't contain related user login or group name. Might be fixed in other iteration of server part. > >> 7. Related to #6, there probably should be a tab in the Host details >> page showing which ID views apply to it. > There is only a single view and yes, it would be good to add a property > there, linking it to the ID view tab, if possible. Will add simple readonly field (link to view). It will be improved later (based on ipa-4-1 priorities) > >> 9. This probably requires server support. In the "Apply to hosts" >> association dialog, if a host is already added it will still appear in >> the dialog box. As a comparison, a User that has been added into a >> User Group will not appear in the association dialog anymore. > Could be trivially filtered out on Web UI side. Will be implemented. -- Petr Vobornik From ftweedal at redhat.com Thu Sep 25 23:47:37 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 26 Sep 2014 09:47:37 +1000 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <5423C7C3.80305@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> <5422D254.4040807@redhat.com> <20140925013037.GZ5346@dhcp-40-8.bne.redhat.com> <5423C7C3.80305@redhat.com> Message-ID: <20140925234737.GD5346@dhcp-40-8.bne.redhat.com> On Thu, Sep 25, 2014 at 09:44:03AM +0200, Petr Viktorin wrote: > On 09/25/2014 03:30 AM, Fraser Tweedale wrote: > >On Wed, Sep 24, 2014 at 09:16:52AM -0500, Endi Sukma Dewata wrote: > >>On 9/24/2014 8:26 AM, Petr Vobornik wrote: > >>>On 24.9.2014 04:43, Endi Sukma Dewata wrote: > >>>>On 9/22/2014 9:49 AM, Petr Vobornik wrote: > >>>>>[PATCH] webui-ci: case-insensitive record check > >>>>> > >>>>>Indirect association are no longer lower cased, which caused a issue > >>>>>in CI. > >>>> > >>>>Is the use of "|=" operator intentional? I don't see the "has" variable > >>>>defined anywhere else in this method. > >>>> > >>>> has |= self.has_record(pkey.lower(), parent, table_name) > >>>> > >>>>If this has been tested to work, then ACK. > >>>> > >>> > >>>it's defined on the previous line: > >>> > >>> has = self.has_record(pkey, parent, table_name) > >>> has |= self.has_record(pkey.lower(), parent, table_name) > >> > >>Ah, I see. I thought the old line was being replaced. > >>ACK. > > > >IMO the following reads better:: > > > > has = self.has_record(pkey, parent, table_name) \ > > || self.has_record(pkey.lower(), parent, table_name) > > > >(Just a comment - no reason to block the patch.) > > Feel free to push the patch as it is, but since we're debating style... > > Write this: > > has_record = (self.has_record(pkey, parent, table_name) or > self.has_record(pkey.lower(), parent, table_name)) > Hah, yes. What I wrote is not even Python! I have been writing too much Java it seems -_- > For boolean values, you should prefer `or` and `and` over the bitwise > operators, since "truthy"/"falsy" values might not be just booleans. > It's better illustrated with `and`: `3 and 8` is true, but `3 & 8` is false. > > > And from PEP8: > - The preferred way of wrapping long lines is by using Python's implied line > continuation inside parentheses, brackets and braces. Long lines can be > broken over multiple lines by wrapping expressions in parentheses. These > should be used in preference to using a backslash for line continuation. > > - The preferred place to break around a binary operator is after the > operator, not before it. > > -- > Petr? > From dkupka at redhat.com Fri Sep 26 06:28:32 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 08:28:32 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <542423E9.4020203@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> Message-ID: <54250790.1090105@redhat.com> On 09/25/2014 04:17 PM, David Kupka wrote: > On 09/24/2014 08:54 PM, Martin Basti wrote: >> On 24/09/14 15:44, David Kupka wrote: >>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>> On 23/09/14 13:23, David Kupka wrote: >>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>> ... >>>>>> 1) >>>>>> + if options.unattended: >>>>>> + for ip in ip_addresses: >>>>>> + if search_reverse_zones and >>>>>> find_reverse_zone(str(ip)): >>>>>> + # reverse zone is already in LDAP >>>>>> + continue >>>>>> + for rz in ret_reverse_zones: >>>>>> + if verify_reverse_zone(rz, ip): >>>>>> + # reverse zone was entered by user >>>>>> + break >>>>>> + else: >>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>> + ret_reverse_zones.append(rz) >>>>>> + elif options.reverse_zones or create_reverse(): >>>>>> + for ip in ip_addresses: >>>>>> + if search_reverse_zones and >>>>>> find_reverse_zone(str(ip)): >>>>>> + # reverse zone is already in LDAP >>>>>> + continue >>>>>> + for rz in ret_reverse_zones: >>>>>> + if verify_reverse_zone(rz, ip): >>>>>> + # reverse zone was entered by user >>>>>> + break >>>>>> + else: >>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>> + ret_reverse_zones.append(rz) >>>>>> + else: >>>>>> + options.no_reverse = True >>>>>> + ret_reverse_zones = [] >>>>>> >>>>>> You can make it shorter without duplications: >>>>>> >>>>>> # this ifs can be in one line >>>>>> if not options.unatended: >>>>>> if not options.reverse_zones >>>>>> if not create_reverse(): >>>>>> options.no_reverse=True >>>>>> return [] >>>>>> >>>>>> for ip in ip_addresses: >>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>> # reverse zone is already in LDAP >>>>>> continue >>>>>> for rz in ret_reverse_zones: >>>>>> if verify_reverse_zone(rz, ip): >>>>>> # reverse zone was entered by user >>>>>> break >>>>>> else: >>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>> if not options.unattended: >>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>> ret_reverse_zones.append(rz) >>>>>> >>>>> >>>>> Thanks, I modified it bit different way to alse address recommendation >>>>> 3). >>>>> >>>>>> >>>>>> 2) >>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>> ---------------------------------------------^^ >>>>>> >>>>> >>>>> Thanks, fixed. >>>>> >>>>>> >>>>>> 3) >>>>>> Would be nice to ask user to create new zones only if new zones are >>>>>> required. (If all required zones exist in LDAP, you ask user anyway) >>>>>> >>>>> >>>>> I added one more variable and ask only once. >>>>> >>>>>> 4) >>>>>> Ask framework gurus, if installutils module is better place for >>>>>> function >>>>>> above >>>>>> >>>>>> >>>>> >>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>> >>>>>> >>>>> >>>> NACK, most important point is 7 >>>> >>>> 1) >>>> I'm not sure if this is bug, but interactively is allowed to add only >>>> one ip address >>>> >>>> Unable to resolve IP address for host name >>>> Please provide the IP address to be used for this host name: >>>> 2001:db8::2 >>>> The kerberos protocol requires a Realm name to be defined. >>>> >>> >>> For the sake of infinite usability and UX I rewrote it to ask for >>> multiple addresses the same way as for DNS forwarders. Also I really >>> simplified IP address checking code when I was in it. I tested it but >>> please look at it carefully. >>> Also I found that ipa-dns-install and ipa-adtrust-install also accept >>> --ip-address param. So I modified ipa-dns-install in the same way as >>> ipa-server-install and ipa-replica-install. After discussion with >>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>> use specified value at all. I will remove the processing code and mark >>> the param as deprecated in separate patch. >>> >>>> 2) >>>> I'm getting error message >>>> >>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>> 2001:db8::dead:beef >>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>> >>>> - or - >>>> >>>> Do you want to configure the reverse zone? [yes]: >>>> Please specify the reverse zone name >>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP >>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>> Please specify the reverse zone name >>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>> >>>> This shouldn't be there >>> >>> Moved the message to function used when installation is attended by >>> user. >>> >>>> >>>> Could be better to ask user to specific zone for ip address a.b.c.d. >>> >>> Probably, but lets leave some work for future. >>> >>>> >>>> 4) just nitpick >>>> The IPA Master Server will be configured with: >>>> ... >>>> IP address(es): 2001:db8::dead:beef, >>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>> ... >>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>> >>>> You have label "IP address(es)", so you should use label "Reverse >>>> zone(s)" >>>> >>> >>> Fixed. >>> >>>> 5) >>>> ipa-server-install --ip-address=10.16.78.105 >>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>> --setup-dns >>>> >>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not sure >>>> if this is wrong, but we prevents user to add zone without address in >>>> it, so we should prevents, to add empty zone. >>>> >>> >>> It would be nice but not in this patch. >>> >>>> 6) >>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. vm-105.example.com >>>> Directory Manager (existing master) password: >>>> >>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>> >>>> IMO This should work, right? >>>> >>>> + sys.exit("There is no IP address matching reverse zone >>>> %s." % rz) >>>> I expected at least this error to be shown. >>> >>> Fixed, thanks. >>> >>>> >>>> 7) >>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>> 2001:db8::dead:beef vm-105.example.com >>>> Directory Manager (existing master) password: >>>> >>>> ....... >>>> Adding DNS records for vm-105.example.com >>>> Values instance has no attribute 'ip_address' >>>> >>>> Command returns the attribute error. >>>> It fails with one --ip-address too. >>>> >>> >>> Sorry, fixed. >>> >>>> >>>> *) Not related with your patch >>>> Problem with installation: >>>> I'm getting message: >>>> IPA server is already configured on this system. >>>> Even if I validation wasn't successful and installation was aborted. >>>> >>>> IPA install detects previous installations by checking state file and >>>> restore files. Function get_server_ip_address() stores some data and >>>> hosts file and modify the host file, before user agreed installation. >>>> This error was there before your patch. >>>> https://fedorahosted.org/freeipa/ticket/4561 >>>> >>>> >>>> >>> >> NACK >> >> 0) >> # ipa-dns-install --ip-address 2001:db8::feed >> >> 2014-09-24T06:02:13Z DEBUG stderr= >> 2014-09-24T06:02:13Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 645, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-dns-install", line 135, in main >> ip_addresses = get_server_ip_address(api.env.host, fstore, >> options.unattended, options) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 473, in get_server_ip_address >> if options.setup_dns: >> >> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >> exception: AttributeError: Values instance has no attribute 'setup_dns' > > Obviously there is no option --setup-dns in ipa-dns-install. > Fixed, modified get_server_ip_address function. > >> >> 1) >> # ipa-replica-prepare vm-073.example.com --ip-address >> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >> Directory Manager (existing master) password: >> >> Preparing replica for vm-073.example.com from vm-105.example.com >> Creating SSL certificate for the Directory Server >> Creating SSL certificate for the dogtag Directory Server >> Saving dogtag Directory Server port >> Creating SSL certificate for the Web Server >> Exporting RA certificate >> Copying additional files >> Finalizing configuration >> Packaging replica information into >> /var/lib/ipa/replica-info-vm-073.example.com.gpg >> Adding DNS records for vm-073.example.com >> Values instance has no attribute 'unattended' >> >> It should be unatended automatically, or we need add the --unattended >> option to ipa-replica-prepare > > ipa-replica-install is missing --unattended option. I fixed it in my > code for now but we should add it there. > >> >> 2) This is nto user friendly, could be IP address check before >> installation? >> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >> --no-forwarders >> Directory Manager (existing master) password: >> >> Run connection check to master >> ... >> >> ... >> Restarting the KDC >> There is no IP address matching reverse zone 10.in-addr.arpa.. >> >> LOG: >> return_value = main_function() >> >> File "/sbin/ipa-replica-install", line 721, in main >> install_bind(config, options) >> >> File "/sbin/ipa-replica-install", line 265, in install_bind >> reverse_zones = >> bindinstance.check_reverse_zones(config.ip_addresses, >> options.reverse_zones, options, True) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 426, in check_reverse_zones >> sys.exit("There is no IP address matching reverse zone %s." % rz) >> >> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >> exception: SystemExit: There is no IP address matching reverse zone >> 10.in-addr.arpa.. > > Fixed. Asking everything before actual installation. > >> >> 3) >> I'm not sure if sys.exit() is good, replica-install shoudl wrote >> something about partially configured system > > This is quite common in installation scripts. I moved this parts before > actual installation. > >> >> 4) I'm not sure if this is the best place to ask about reverse zones >> .... >> Done configuring the web interface (httpd). >> Configuring ipa-otpd >> [1/2]: starting ipa-otpd >> [2/2]: configuring ipa-otpd to start on boot >> Done configuring ipa-otpd. >> Applying LDAP updates >> Restarting the directory server >> Restarting the KDC >> Do you want to configure the reverse zone? [yes]: > > Moved. > >> >> 5) And error >> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >> --setup-dns >> .... >> Do you want to configure the reverse zone? [yes]: >> Please specify the reverse zone name >> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Unexpected error - see /var/log/ipareplica-install.log for details: >> AttributeError: 'str' object has no attribute 'version' >> >> LOG: >> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >> conn= >> 2014-09-24T06:50:45Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 645, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-replica-install", line 721, in main >> install_bind(config, options) >> >> File "/sbin/ipa-replica-install", line 272, in install_bind >> ca_configured=options.setup_ca) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 550, in setup >> self.__setup_sub_dict() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 651, in __setup_sub_dict >> if addr.version in (4, 6): >> >> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >> exception: AttributeError: 'str' object has no attribute 'version' > > Fixed. We are using IP addresses as a strings and as a CheckedIPAddress. > I swapped them here. >> >> >> *) I don't like this asking to specify zone without IP >> Do you want to configure the reverse zone? [yes]: >> Please specify the reverse zone name >> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >> > > Would be nice. Prefer to do it as a part of more powerfull reverse zone > validation logic. >> >> >> **) I'm not sure how often this case can happen: >> master and replica without DNS, you run --ipa-dns-install on master then >> on replica, then replica DNS installation will not try to find existent >> reverse zones in ldap, due configuration in ipa-dns-install. >> Maybe you should detect if DNS container exists and then set flag >> "search_reverse_zones=True" >> >> ipa-dns-install: >> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >> options.reverse_zones, options) > > Same as above. > >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Rebased to current master and ipa-4-1. Removed unintentional modification of ipa-adtrust-install. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-11-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-11-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43290 bytes Desc: not available URL: From jcholast at redhat.com Fri Sep 26 07:34:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Sep 2014 09:34:28 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54250790.1090105@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> Message-ID: <54251704.4080802@redhat.com> Dne 26.9.2014 v 08:28 David Kupka napsal(a): > On 09/25/2014 04:17 PM, David Kupka wrote: >> On 09/24/2014 08:54 PM, Martin Basti wrote: >>> On 24/09/14 15:44, David Kupka wrote: >>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>> ... >>>>>>> 1) >>>>>>> + if options.unattended: >>>>>>> + for ip in ip_addresses: >>>>>>> + if search_reverse_zones and >>>>>>> find_reverse_zone(str(ip)): >>>>>>> + # reverse zone is already in LDAP >>>>>>> + continue >>>>>>> + for rz in ret_reverse_zones: >>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>> + # reverse zone was entered by user >>>>>>> + break >>>>>>> + else: >>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>> + ret_reverse_zones.append(rz) >>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>> + for ip in ip_addresses: >>>>>>> + if search_reverse_zones and >>>>>>> find_reverse_zone(str(ip)): >>>>>>> + # reverse zone is already in LDAP >>>>>>> + continue >>>>>>> + for rz in ret_reverse_zones: >>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>> + # reverse zone was entered by user >>>>>>> + break >>>>>>> + else: >>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>> + ret_reverse_zones.append(rz) >>>>>>> + else: >>>>>>> + options.no_reverse = True >>>>>>> + ret_reverse_zones = [] >>>>>>> >>>>>>> You can make it shorter without duplications: >>>>>>> >>>>>>> # this ifs can be in one line >>>>>>> if not options.unatended: >>>>>>> if not options.reverse_zones >>>>>>> if not create_reverse(): >>>>>>> options.no_reverse=True >>>>>>> return [] >>>>>>> >>>>>>> for ip in ip_addresses: >>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>> # reverse zone is already in LDAP >>>>>>> continue >>>>>>> for rz in ret_reverse_zones: >>>>>>> if verify_reverse_zone(rz, ip): >>>>>>> # reverse zone was entered by user >>>>>>> break >>>>>>> else: >>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>> if not options.unattended: >>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>> ret_reverse_zones.append(rz) >>>>>>> >>>>>> >>>>>> Thanks, I modified it bit different way to alse address >>>>>> recommendation >>>>>> 3). >>>>>> >>>>>>> >>>>>>> 2) >>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>> ---------------------------------------------^^ >>>>>>> >>>>>> >>>>>> Thanks, fixed. >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> Would be nice to ask user to create new zones only if new zones are >>>>>>> required. (If all required zones exist in LDAP, you ask user anyway) >>>>>>> >>>>>> >>>>>> I added one more variable and ask only once. >>>>>> >>>>>>> 4) >>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>> function >>>>>>> above >>>>>>> >>>>>>> >>>>>> >>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>> >>>>>>> >>>>>> >>>>> NACK, most important point is 7 >>>>> >>>>> 1) >>>>> I'm not sure if this is bug, but interactively is allowed to add only >>>>> one ip address >>>>> >>>>> Unable to resolve IP address for host name >>>>> Please provide the IP address to be used for this host name: >>>>> 2001:db8::2 >>>>> The kerberos protocol requires a Realm name to be defined. >>>>> >>>> >>>> For the sake of infinite usability and UX I rewrote it to ask for >>>> multiple addresses the same way as for DNS forwarders. Also I really >>>> simplified IP address checking code when I was in it. I tested it but >>>> please look at it carefully. >>>> Also I found that ipa-dns-install and ipa-adtrust-install also accept >>>> --ip-address param. So I modified ipa-dns-install in the same way as >>>> ipa-server-install and ipa-replica-install. After discussion with >>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>> use specified value at all. I will remove the processing code and mark >>>> the param as deprecated in separate patch. >>>> >>>>> 2) >>>>> I'm getting error message >>>>> >>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>> 2001:db8::dead:beef >>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>> >>>>> - or - >>>>> >>>>> Do you want to configure the reverse zone? [yes]: >>>>> Please specify the reverse zone name >>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP >>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>> Please specify the reverse zone name >>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>> >>>>> This shouldn't be there >>>> >>>> Moved the message to function used when installation is attended by >>>> user. >>>> >>>>> >>>>> Could be better to ask user to specific zone for ip address a.b.c.d. >>>> >>>> Probably, but lets leave some work for future. >>>> >>>>> >>>>> 4) just nitpick >>>>> The IPA Master Server will be configured with: >>>>> ... >>>>> IP address(es): 2001:db8::dead:beef, >>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>> ... >>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>> >>>>> You have label "IP address(es)", so you should use label "Reverse >>>>> zone(s)" >>>>> >>>> >>>> Fixed. >>>> >>>>> 5) >>>>> ipa-server-install --ip-address=10.16.78.105 >>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>> --setup-dns >>>>> >>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>> sure >>>>> if this is wrong, but we prevents user to add zone without address in >>>>> it, so we should prevents, to add empty zone. >>>>> >>>> >>>> It would be nice but not in this patch. >>>> >>>>> 6) >>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>> vm-105.example.com >>>>> Directory Manager (existing master) password: >>>>> >>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>> >>>>> IMO This should work, right? >>>>> >>>>> + sys.exit("There is no IP address matching reverse >>>>> zone >>>>> %s." % rz) >>>>> I expected at least this error to be shown. >>>> >>>> Fixed, thanks. >>>> >>>>> >>>>> 7) >>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>> 2001:db8::dead:beef vm-105.example.com >>>>> Directory Manager (existing master) password: >>>>> >>>>> ....... >>>>> Adding DNS records for vm-105.example.com >>>>> Values instance has no attribute 'ip_address' >>>>> >>>>> Command returns the attribute error. >>>>> It fails with one --ip-address too. >>>>> >>>> >>>> Sorry, fixed. >>>> >>>>> >>>>> *) Not related with your patch >>>>> Problem with installation: >>>>> I'm getting message: >>>>> IPA server is already configured on this system. >>>>> Even if I validation wasn't successful and installation was aborted. >>>>> >>>>> IPA install detects previous installations by checking state file and >>>>> restore files. Function get_server_ip_address() stores some data and >>>>> hosts file and modify the host file, before user agreed installation. >>>>> This error was there before your patch. >>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>> >>>>> >>>>> >>>> >>> NACK >>> >>> 0) >>> # ipa-dns-install --ip-address 2001:db8::feed >>> >>> 2014-09-24T06:02:13Z DEBUG stderr= >>> 2014-09-24T06:02:13Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 645, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-dns-install", line 135, in main >>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>> options.unattended, options) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 473, in get_server_ip_address >>> if options.setup_dns: >>> >>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>> exception: AttributeError: Values instance has no attribute 'setup_dns' >> >> Obviously there is no option --setup-dns in ipa-dns-install. >> Fixed, modified get_server_ip_address function. >> >>> >>> 1) >>> # ipa-replica-prepare vm-073.example.com --ip-address >>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>> Directory Manager (existing master) password: >>> >>> Preparing replica for vm-073.example.com from vm-105.example.com >>> Creating SSL certificate for the Directory Server >>> Creating SSL certificate for the dogtag Directory Server >>> Saving dogtag Directory Server port >>> Creating SSL certificate for the Web Server >>> Exporting RA certificate >>> Copying additional files >>> Finalizing configuration >>> Packaging replica information into >>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>> Adding DNS records for vm-073.example.com >>> Values instance has no attribute 'unattended' >>> >>> It should be unatended automatically, or we need add the --unattended >>> option to ipa-replica-prepare >> >> ipa-replica-install is missing --unattended option. I fixed it in my >> code for now but we should add it there. >> >>> >>> 2) This is nto user friendly, could be IP address check before >>> installation? >>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>> --no-forwarders >>> Directory Manager (existing master) password: >>> >>> Run connection check to master >>> ... >>> >>> ... >>> Restarting the KDC >>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>> >>> LOG: >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 721, in main >>> install_bind(config, options) >>> >>> File "/sbin/ipa-replica-install", line 265, in install_bind >>> reverse_zones = >>> bindinstance.check_reverse_zones(config.ip_addresses, >>> options.reverse_zones, options, True) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>> line 426, in check_reverse_zones >>> sys.exit("There is no IP address matching reverse zone %s." % rz) >>> >>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>> exception: SystemExit: There is no IP address matching reverse zone >>> 10.in-addr.arpa.. >> >> Fixed. Asking everything before actual installation. >> >>> >>> 3) >>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>> something about partially configured system >> >> This is quite common in installation scripts. I moved this parts before >> actual installation. >> >>> >>> 4) I'm not sure if this is the best place to ask about reverse zones >>> .... >>> Done configuring the web interface (httpd). >>> Configuring ipa-otpd >>> [1/2]: starting ipa-otpd >>> [2/2]: configuring ipa-otpd to start on boot >>> Done configuring ipa-otpd. >>> Applying LDAP updates >>> Restarting the directory server >>> Restarting the KDC >>> Do you want to configure the reverse zone? [yes]: >> >> Moved. >> >>> >>> 5) And error >>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>> --setup-dns >>> .... >>> Do you want to configure the reverse zone? [yes]: >>> Please specify the reverse zone name >>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Unexpected error - see /var/log/ipareplica-install.log for details: >>> AttributeError: 'str' object has no attribute 'version' >>> >>> LOG: >>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>> conn= >>> 2014-09-24T06:50:45Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 645, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 721, in main >>> install_bind(config, options) >>> >>> File "/sbin/ipa-replica-install", line 272, in install_bind >>> ca_configured=options.setup_ca) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>> line 550, in setup >>> self.__setup_sub_dict() >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>> line 651, in __setup_sub_dict >>> if addr.version in (4, 6): >>> >>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>> exception: AttributeError: 'str' object has no attribute 'version' >> >> Fixed. We are using IP addresses as a strings and as a CheckedIPAddress. >> I swapped them here. >>> >>> >>> *) I don't like this asking to specify zone without IP >>> Do you want to configure the reverse zone? [yes]: >>> Please specify the reverse zone name >>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>> >> >> Would be nice. Prefer to do it as a part of more powerfull reverse zone >> validation logic. >>> >>> >>> **) I'm not sure how often this case can happen: >>> master and replica without DNS, you run --ipa-dns-install on master then >>> on replica, then replica DNS installation will not try to find existent >>> reverse zones in ldap, due configuration in ipa-dns-install. >>> Maybe you should detect if DNS container exists and then set flag >>> "search_reverse_zones=True" >>> >>> ipa-dns-install: >>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>> options.reverse_zones, options) >> >> Same as above. >> >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Rebased to current master and ipa-4-1. Removed unintentional > modification of ipa-adtrust-install. + for ip, ip_address in zip(config.ips, config.ip_addresses): + reverse_zone = bindinstance.find_reverse_zone(ip) Is it always 100% guaranteed that the values in config.ips and config.ip_addresses are the same length and otherwise match each other in a way that will not cause things to break? IMO it would be better to store a single list of 2-tuples somewhere from the start instead of zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, 'yes')].) -- Jan Cholasta From mkosek at redhat.com Fri Sep 26 07:56:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 09:56:28 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <54057D44.9040107@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> Message-ID: <54251C2C.2050101@redhat.com> On 09/02/2014 10:18 AM, Jan Cholasta wrote: > Dne 27.8.2014 v 16:49 David Kupka napsal(a): >> 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 >>>> >>> >> > > ACK as long as this works for Nalin. > I see Nalin is OK with the patch, I am not so OK. What should we do with the server option then? It is still being referred to as "Deprecated" in the man page. Should we then un-deprecate it as Honza suggested down the thread? Martin From mbasti at redhat.com Fri Sep 26 08:20:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Sep 2014 10:20:40 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <54243127.1040000@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> <5423D2D4.6080709@redhat.com> <54242776.1070800@redhat.com> <5424293B.3000502@redhat.com> <54243127.1040000@redhat.com> Message-ID: <542521D8.2090509@redhat.com> On 25/09/14 17:13, Martin Kosek wrote: > On 09/25/2014 04:39 PM, Petr Viktorin wrote: >> On 09/25/2014 04:32 PM, Petr Spacek wrote: >>> On 25.9.2014 10:31, Martin Basti wrote: >>>> On 24/09/14 16:24, Martin Basti wrote: >>>>> On 24/09/14 16:05, Martin Basti wrote: >>>>>> On 23/09/14 17:45, Petr Vobornik wrote: >>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> Review of: >>>>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>>>>>> >>>>>>> >>>>>>> 1. Please follow pep8 for the new code. >>>>>>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>>>>>> Produces 25 erros. >>>>>>> >>>>>>> Only E124 and E128 could be ignored if they are part of old code. >>>>>> I left there some pep8 errors. They don't decrease readability >>>>>> >>>>>>> Patch 120: >>>>>>> >>>>>>> 3. This patch uses term 'deprecated' in a different meaning than a >>>>>>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >>>>>>> this >>>>>>> usage is correct since the usual understanding of deprecation is >>>>>>> that the >>>>>>> param is still usable but user should be prepared that it will be >>>>>>> removed >>>>>>> in a future. IMHO DeprecatedParam is badly designed but that's not an >>>>>>> issue of this patch. >>>>>>> >>>>>>> I think we can leave this as is and create a ticket to rename >>>>>>> DeprecatedParam e.g. to RemovedParam. What do you think? >>>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4566 >>>>>>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>>>>>> dnszone-add >>>>>>> precallback still uses these params. What is the intended purpose? >>>>>> User should use modify dialog in webUI for zones. >>>>>> Precallback fills default value for idnsmname from LDAP. >>>>>> with --force there will be no validation of user specified soa mname >>>>>> >>>>>> Purpose is a user should let IPA to fill mname with safe value. >>>>>>> Patch 123: >>>>>>> >>>>>>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >>>>>>> shouldn't it >>>>>>> be normalized to contain '.' at the end? Or is it handled by >>>>>>> bind-dyndb-ldap? >>>>>> Zone manager (SOA RNAME) can eb relative name, BIND will append zone >>>>>> name. >>>>>> Currently we cant validate if email address is reachable, it doestn >>>>>> matter >>>>>> if it is filled with nonexistent absolute name, or nonexistent >>>>>> relative name. >>>>>> >>>>>>> Unrelated to this patch set: >>>>>>> >>>>>>> a. One is able to run: >>>>>>> # ipa dnszone-remove-permission $zone >>>>>>> multiple times and it always returns success >>>>>>> >>>>>>> Is it intentional? >>>>>> No, it isn't. I will inspect it and I will send additional patch >>>>>> >>>>>>> b. Web UI doesn't have means to call dnszone-mod with --force option >>>>>> I'm not sure what you mean, it didn't do that before my patches. >>>>>> >>>>>> Updated patches attached >>>>>> >>>>> I accidentally removed one line in previous patchset. >>>>> Updated patches attached >>>>> >>>> Sorry my IDE was too smart, and somehow added its configuration file >>>> to commit >>>> and I didn't notice it. >>>> Patches attached. >>> ACK, it works for me. Replica installation and deletion properly adds >>> and deletes records as necessary. >>> >>> I would defer further improvements to >>> https://fedorahosted.org/freeipa/ticket/3343 >>> >> Pushed to: >> ipa-4-1: b7e3a990369d85dfd12165891cf9142d669a0259 >> master: bc2eaa145637e1947449ee53548243ab22059805 >> > I reopened the ticket, we missed update to DNS help page (ipa help dns): > > https://fedorahosted.org/freeipa/ticket/4149#comment:18 > > Martin Thanks! Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0129-Remove-ip-address-name-server-otpions-from-DNS-help.patch Type: text/x-patch Size: 1519 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 26 08:28:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 10:28:43 +0200 Subject: [Freeipa-devel] [PATCHES 0114-0115] DNS: allow to add root zone '.' In-Reply-To: <542521D8.2090509@redhat.com> References: <53FB3191.7090102@redhat.com> <54219587.4020600@redhat.com> <5422CFB0.6000702@redhat.com> <5422D434.4090800@redhat.com> <5423D2D4.6080709@redhat.com> <54242776.1070800@redhat.com> <5424293B.3000502@redhat.com> <54243127.1040000@redhat.com> <542521D8.2090509@redhat.com> Message-ID: <542523BB.1040508@redhat.com> On 09/26/2014 10:20 AM, Martin Basti wrote: > On 25/09/14 17:13, Martin Kosek wrote: >> On 09/25/2014 04:39 PM, Petr Viktorin wrote: >>> On 09/25/2014 04:32 PM, Petr Spacek wrote: >>>> On 25.9.2014 10:31, Martin Basti wrote: >>>>> On 24/09/14 16:24, Martin Basti wrote: >>>>>> On 24/09/14 16:05, Martin Basti wrote: >>>>>>> On 23/09/14 17:45, Petr Vobornik wrote: >>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> Review of: >>>>>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00484.html >>>>>>>> >>>>>>>> >>>>>>>> 1. Please follow pep8 for the new code. >>>>>>>> # git diff HEAD~7 -U0 | pep8 --diff --ignore=E501 >>>>>>>> Produces 25 erros. >>>>>>>> >>>>>>>> Only E124 and E128 could be ignored if they are part of old code. >>>>>>> I left there some pep8 errors. They don't decrease readability >>>>>>> >>>>>>>> Patch 120: >>>>>>>> >>>>>>>> 3. This patch uses term 'deprecated' in a different meaning than a >>>>>>>> DeprecatedParam. It creates inconsistency -> future confusion. IMHO >>>>>>>> this >>>>>>>> usage is correct since the usual understanding of deprecation is >>>>>>>> that the >>>>>>>> param is still usable but user should be prepared that it will be >>>>>>>> removed >>>>>>>> in a future. IMHO DeprecatedParam is badly designed but that's not an >>>>>>>> issue of this patch. >>>>>>>> >>>>>>>> I think we can leave this as is and create a ticket to rename >>>>>>>> DeprecatedParam e.g. to RemovedParam. What do you think? >>>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4566 >>>>>>>> 5. You've removed 'idnssoamname' and 'force' from Web UI but >>>>>>>> dnszone-add >>>>>>>> precallback still uses these params. What is the intended purpose? >>>>>>> User should use modify dialog in webUI for zones. >>>>>>> Precallback fills default value for idnsmname from LDAP. >>>>>>> with --force there will be no validation of user specified soa mname >>>>>>> >>>>>>> Purpose is a user should let IPA to fill mname with safe value. >>>>>>>> Patch 123: >>>>>>>> >>>>>>>> 10. In `normalize_zonemgr(zonemgr)`, if zonemgr contains '@' >>>>>>>> shouldn't it >>>>>>>> be normalized to contain '.' at the end? Or is it handled by >>>>>>>> bind-dyndb-ldap? >>>>>>> Zone manager (SOA RNAME) can eb relative name, BIND will append zone >>>>>>> name. >>>>>>> Currently we cant validate if email address is reachable, it doestn >>>>>>> matter >>>>>>> if it is filled with nonexistent absolute name, or nonexistent >>>>>>> relative name. >>>>>>> >>>>>>>> Unrelated to this patch set: >>>>>>>> >>>>>>>> a. One is able to run: >>>>>>>> # ipa dnszone-remove-permission $zone >>>>>>>> multiple times and it always returns success >>>>>>>> >>>>>>>> Is it intentional? >>>>>>> No, it isn't. I will inspect it and I will send additional patch >>>>>>> >>>>>>>> b. Web UI doesn't have means to call dnszone-mod with --force option >>>>>>> I'm not sure what you mean, it didn't do that before my patches. >>>>>>> >>>>>>> Updated patches attached >>>>>>> >>>>>> I accidentally removed one line in previous patchset. >>>>>> Updated patches attached >>>>>> >>>>> Sorry my IDE was too smart, and somehow added its configuration file >>>>> to commit >>>>> and I didn't notice it. >>>>> Patches attached. >>>> ACK, it works for me. Replica installation and deletion properly adds >>>> and deletes records as necessary. >>>> >>>> I would defer further improvements to >>>> https://fedorahosted.org/freeipa/ticket/3343 >>>> >>> Pushed to: >>> ipa-4-1: b7e3a990369d85dfd12165891cf9142d669a0259 >>> master: bc2eaa145637e1947449ee53548243ab22059805 >>> >> I reopened the ticket, we missed update to DNS help page (ipa help dns): >> >> https://fedorahosted.org/freeipa/ticket/4149#comment:18 >> >> Martin > > Thanks! > Patch attached. ACK! Pushed to: master: 3f8cfdab269490e4935db7d296c3fc7f2fa552f5 ipa-4-1: 0f2eb65f008777ebdee9b35f5f69bada66066484 Martin From dkupka at redhat.com Fri Sep 26 08:30:01 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 10:30:01 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54251704.4080802@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> Message-ID: <54252409.7080002@redhat.com> On 09/26/2014 09:34 AM, Jan Cholasta wrote: > Dne 26.9.2014 v 08:28 David Kupka napsal(a): >> On 09/25/2014 04:17 PM, David Kupka wrote: >>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>> On 24/09/14 15:44, David Kupka wrote: >>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>> ... >>>>>>>> 1) >>>>>>>> + if options.unattended: >>>>>>>> + for ip in ip_addresses: >>>>>>>> + if search_reverse_zones and >>>>>>>> find_reverse_zone(str(ip)): >>>>>>>> + # reverse zone is already in LDAP >>>>>>>> + continue >>>>>>>> + for rz in ret_reverse_zones: >>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>> + # reverse zone was entered by user >>>>>>>> + break >>>>>>>> + else: >>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>> + for ip in ip_addresses: >>>>>>>> + if search_reverse_zones and >>>>>>>> find_reverse_zone(str(ip)): >>>>>>>> + # reverse zone is already in LDAP >>>>>>>> + continue >>>>>>>> + for rz in ret_reverse_zones: >>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>> + # reverse zone was entered by user >>>>>>>> + break >>>>>>>> + else: >>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>> + else: >>>>>>>> + options.no_reverse = True >>>>>>>> + ret_reverse_zones = [] >>>>>>>> >>>>>>>> You can make it shorter without duplications: >>>>>>>> >>>>>>>> # this ifs can be in one line >>>>>>>> if not options.unatended: >>>>>>>> if not options.reverse_zones >>>>>>>> if not create_reverse(): >>>>>>>> options.no_reverse=True >>>>>>>> return [] >>>>>>>> >>>>>>>> for ip in ip_addresses: >>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>> # reverse zone is already in LDAP >>>>>>>> continue >>>>>>>> for rz in ret_reverse_zones: >>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>> # reverse zone was entered by user >>>>>>>> break >>>>>>>> else: >>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>> if not options.unattended: >>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>> ret_reverse_zones.append(rz) >>>>>>>> >>>>>>> >>>>>>> Thanks, I modified it bit different way to alse address >>>>>>> recommendation >>>>>>> 3). >>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>> ---------------------------------------------^^ >>>>>>>> >>>>>>> >>>>>>> Thanks, fixed. >>>>>>> >>>>>>>> >>>>>>>> 3) >>>>>>>> Would be nice to ask user to create new zones only if new zones are >>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>> anyway) >>>>>>>> >>>>>>> >>>>>>> I added one more variable and ask only once. >>>>>>> >>>>>>>> 4) >>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>> function >>>>>>>> above >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>> >>>>>>>> >>>>>>> >>>>>> NACK, most important point is 7 >>>>>> >>>>>> 1) >>>>>> I'm not sure if this is bug, but interactively is allowed to add only >>>>>> one ip address >>>>>> >>>>>> Unable to resolve IP address for host name >>>>>> Please provide the IP address to be used for this host name: >>>>>> 2001:db8::2 >>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>> >>>>> >>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>> multiple addresses the same way as for DNS forwarders. Also I really >>>>> simplified IP address checking code when I was in it. I tested it but >>>>> please look at it carefully. >>>>> Also I found that ipa-dns-install and ipa-adtrust-install also accept >>>>> --ip-address param. So I modified ipa-dns-install in the same way as >>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>> use specified value at all. I will remove the processing code and mark >>>>> the param as deprecated in separate patch. >>>>> >>>>>> 2) >>>>>> I'm getting error message >>>>>> >>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>> 2001:db8::dead:beef >>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>> >>>>>> - or - >>>>>> >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> Please specify the reverse zone name >>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for IP >>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>> Please specify the reverse zone name >>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>> >>>>>> This shouldn't be there >>>>> >>>>> Moved the message to function used when installation is attended by >>>>> user. >>>>> >>>>>> >>>>>> Could be better to ask user to specific zone for ip address a.b.c.d. >>>>> >>>>> Probably, but lets leave some work for future. >>>>> >>>>>> >>>>>> 4) just nitpick >>>>>> The IPA Master Server will be configured with: >>>>>> ... >>>>>> IP address(es): 2001:db8::dead:beef, >>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>> ... >>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>> >>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>> zone(s)" >>>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 5) >>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>> --setup-dns >>>>>> >>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>> sure >>>>>> if this is wrong, but we prevents user to add zone without address in >>>>>> it, so we should prevents, to add empty zone. >>>>>> >>>>> >>>>> It would be nice but not in this patch. >>>>> >>>>>> 6) >>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>> vm-105.example.com >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>> >>>>>> IMO This should work, right? >>>>>> >>>>>> + sys.exit("There is no IP address matching reverse >>>>>> zone >>>>>> %s." % rz) >>>>>> I expected at least this error to be shown. >>>>> >>>>> Fixed, thanks. >>>>> >>>>>> >>>>>> 7) >>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> ....... >>>>>> Adding DNS records for vm-105.example.com >>>>>> Values instance has no attribute 'ip_address' >>>>>> >>>>>> Command returns the attribute error. >>>>>> It fails with one --ip-address too. >>>>>> >>>>> >>>>> Sorry, fixed. >>>>> >>>>>> >>>>>> *) Not related with your patch >>>>>> Problem with installation: >>>>>> I'm getting message: >>>>>> IPA server is already configured on this system. >>>>>> Even if I validation wasn't successful and installation was aborted. >>>>>> >>>>>> IPA install detects previous installations by checking state file and >>>>>> restore files. Function get_server_ip_address() stores some data and >>>>>> hosts file and modify the host file, before user agreed installation. >>>>>> This error was there before your patch. >>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>> >>>>>> >>>>>> >>>>> >>>> NACK >>>> >>>> 0) >>>> # ipa-dns-install --ip-address 2001:db8::feed >>>> >>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>> 2014-09-24T06:02:13Z DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 645, in run_script >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-dns-install", line 135, in main >>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>> options.unattended, options) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 473, in get_server_ip_address >>>> if options.setup_dns: >>>> >>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>> exception: AttributeError: Values instance has no attribute 'setup_dns' >>> >>> Obviously there is no option --setup-dns in ipa-dns-install. >>> Fixed, modified get_server_ip_address function. >>> >>>> >>>> 1) >>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>> Directory Manager (existing master) password: >>>> >>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>> Creating SSL certificate for the Directory Server >>>> Creating SSL certificate for the dogtag Directory Server >>>> Saving dogtag Directory Server port >>>> Creating SSL certificate for the Web Server >>>> Exporting RA certificate >>>> Copying additional files >>>> Finalizing configuration >>>> Packaging replica information into >>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>> Adding DNS records for vm-073.example.com >>>> Values instance has no attribute 'unattended' >>>> >>>> It should be unatended automatically, or we need add the --unattended >>>> option to ipa-replica-prepare >>> >>> ipa-replica-install is missing --unattended option. I fixed it in my >>> code for now but we should add it there. >>> >>>> >>>> 2) This is nto user friendly, could be IP address check before >>>> installation? >>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>> --no-forwarders >>>> Directory Manager (existing master) password: >>>> >>>> Run connection check to master >>>> ... >>>> >>>> ... >>>> Restarting the KDC >>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>> >>>> LOG: >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-replica-install", line 721, in main >>>> install_bind(config, options) >>>> >>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>> reverse_zones = >>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>> options.reverse_zones, options, True) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>> line 426, in check_reverse_zones >>>> sys.exit("There is no IP address matching reverse zone %s." % rz) >>>> >>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>> exception: SystemExit: There is no IP address matching reverse zone >>>> 10.in-addr.arpa.. >>> >>> Fixed. Asking everything before actual installation. >>> >>>> >>>> 3) >>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>> something about partially configured system >>> >>> This is quite common in installation scripts. I moved this parts before >>> actual installation. >>> >>>> >>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>> .... >>>> Done configuring the web interface (httpd). >>>> Configuring ipa-otpd >>>> [1/2]: starting ipa-otpd >>>> [2/2]: configuring ipa-otpd to start on boot >>>> Done configuring ipa-otpd. >>>> Applying LDAP updates >>>> Restarting the directory server >>>> Restarting the KDC >>>> Do you want to configure the reverse zone? [yes]: >>> >>> Moved. >>> >>>> >>>> 5) And error >>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>> --setup-dns >>>> .... >>>> Do you want to configure the reverse zone? [yes]: >>>> Please specify the reverse zone name >>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>> >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>> AttributeError: 'str' object has no attribute 'version' >>>> >>>> LOG: >>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>> conn= >>>> 2014-09-24T06:50:45Z DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 645, in run_script >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-replica-install", line 721, in main >>>> install_bind(config, options) >>>> >>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>> ca_configured=options.setup_ca) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>> line 550, in setup >>>> self.__setup_sub_dict() >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>> line 651, in __setup_sub_dict >>>> if addr.version in (4, 6): >>>> >>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>> exception: AttributeError: 'str' object has no attribute 'version' >>> >>> Fixed. We are using IP addresses as a strings and as a CheckedIPAddress. >>> I swapped them here. >>>> >>>> >>>> *) I don't like this asking to specify zone without IP >>>> Do you want to configure the reverse zone? [yes]: >>>> Please specify the reverse zone name >>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>> >>> >>> Would be nice. Prefer to do it as a part of more powerfull reverse zone >>> validation logic. >>>> >>>> >>>> **) I'm not sure how often this case can happen: >>>> master and replica without DNS, you run --ipa-dns-install on master >>>> then >>>> on replica, then replica DNS installation will not try to find existent >>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>> Maybe you should detect if DNS container exists and then set flag >>>> "search_reverse_zones=True" >>>> >>>> ipa-dns-install: >>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>> options.reverse_zones, options) >>> >>> Same as above. >>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Rebased to current master and ipa-4-1. Removed unintentional >> modification of ipa-adtrust-install. > > + for ip, ip_address in zip(config.ips, config.ip_addresses): > + reverse_zone = bindinstance.find_reverse_zone(ip) > > Is it always 100% guaranteed that the values in config.ips and > config.ip_addresses are the same length and otherwise match each other > in a way that will not cause things to break? IMO it would be better to > store a single list of 2-tuples somewhere from the start instead of > zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, > 'yes')].) > The chances that this will break are really small but I cannot guarantee that it won't eventually. One list (config.ip_addresses) is generated from the other (config.ips) and right now there is no need to modify them. But if someone in the future modify only one of them it will fail really badly. So I removed zip() and convert the ip address to string on demand. It will cost a few more cycles but also will be less error prone. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-12-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-12-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43234 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 26 09:23:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 11:23:55 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <5423E1C2.2080507@redhat.com> References: <53EE7049.3050605@redhat.com> <5422EB10.3030305@redhat.com> <5423D91C.6040503@redhat.com> <5423E1C2.2080507@redhat.com> Message-ID: <542530AB.7080707@redhat.com> On 09/25/2014 11:34 AM, thierry bordaz wrote: > On 09/25/2014 10:58 AM, Petr Viktorin wrote: >> On 09/24/2014 06:02 PM, thierry bordaz wrote: >>> On 08/15/2014 10:40 PM, Petr Viktorin wrote: >>>> 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. >> >> Filed easyfix: https://fedorahosted.org/freeipa/ticket/4571 >> >> >>> The first patch looks good to me. Just a minor comment. The test and run >>> of 'paths.SELINUXENABLED' is present several times in tasks.py and >>> fedora. Does it worth to refactor it ? >>> >>> About the second patch, something I do not understand. >>> restore_selinux_booleans resets the selinux boolean to the values that >>> are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . Does >>> that mean this dict has been updated with the original values (using >>> 'backup_func' in set_selinux_booleans ?). >> >> This is restoring an IPA installation, not restoring the system to a pre-IPA >> state. >> The settings need to be the same as if IPA was being installed. >> >> > OK thanks for the explanation. Is this an ACK? Martin From mkosek at redhat.com Fri Sep 26 09:29:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 11:29:05 +0200 Subject: [Freeipa-devel] [PATCH] 129 ipa-kdb: fix unit tests In-Reply-To: <20140924113854.GD31763@hendrix.brq.redhat.com> References: <20140722152451.GS2158@localhost.localdomain> <20140924113854.GD31763@hendrix.brq.redhat.com> Message-ID: <542531E1.6010108@redhat.com> On 09/24/2014 01:38 PM, Jakub Hrozek wrote: > On Tue, Jul 22, 2014 at 05:24:51PM +0200, Sumit Bose wrote: >> Hi, >> >> it looks like the ipa-kdb unit test is broken. This patch tries to fix >> it. >> >> bye, >> Sumit > > ACK > ... Pushed to: master: 757272a3f818e85e7f0b88060efbcd76d3a93f8b ipa-4-1: 5297cc9fa5f2b4890899247cc94057c19174f2e7 ipa-4-0: cfa2f2146d48f474bde9d11a516a51dddf4eeceb Martin From mkosek at redhat.com Fri Sep 26 09:46:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 11:46:15 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure In-Reply-To: <5423FB84.8070105@redhat.com> References: <53F76AB4.5000708@redhat.com> <5422841D.8080205@redhat.com> <5423FB84.8070105@redhat.com> Message-ID: <542535E7.7010900@redhat.com> On 09/25/2014 01:24 PM, Martin Kosek wrote: > On 09/24/2014 10:43 AM, Martin Kosek wrote: >> On 08/22/2014 06:07 PM, Petr Viktorin wrote: >>> 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? >> >> This works pretty nicely, I liked the service.py extension. >> >> My test output: >> >> # ipa-ldap-updater --upgrade >> Upgrading IPA: >> [1/10]: stopping directory server >> [2/10]: saving configuration >> [3/10]: disabling listeners >> [4/10]: starting directory server >> [5/10]: preparing server upgrade >> PRE_SCHEMA_UPDATE >> [6/10]: updating schema >> ... >> [7/10]: upgrading server >> [error] ValueError: Ha! >> [cleanup]: stopping directory server >> [cleanup]: restoring configuration >> >> # ipactl start >> # netstat -putna | grep 389 >> ... >> tcp6 0 0 10.16.78.147:389 10.16.78.147:37490 ESTABLISHED >> 5956/ns-slapd >> >> So I am willing to ACK if there are no other objections. >> >> Martin > > I read the silence as "no objections", so ACK. > > Pushed to: > master: 9a188607fcf68721fc8c38c3c73ee02cac76b58a > ipa-4-1: b333e7adc98ff7c5335fbc7ce1bde5b9dfb3f5ef > > Martin Just found (benign) display issue with this patch when --external-ca is used. See: https://fedorahosted.org/freeipa/ticket/4499#comment:4 Martin From tbordaz at redhat.com Fri Sep 26 09:57:11 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 26 Sep 2014 11:57:11 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <542530AB.7080707@redhat.com> References: <53EE7049.3050605@redhat.com> <5422EB10.3030305@redhat.com> <5423D91C.6040503@redhat.com> <5423E1C2.2080507@redhat.com> <542530AB.7080707@redhat.com> Message-ID: <54253877.6020407@redhat.com> On 09/26/2014 11:23 AM, Martin Kosek wrote: > On 09/25/2014 11:34 AM, thierry bordaz wrote: >> On 09/25/2014 10:58 AM, Petr Viktorin wrote: >>> On 09/24/2014 06:02 PM, thierry bordaz wrote: >>>> On 08/15/2014 10:40 PM, Petr Viktorin wrote: >>>>> 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. >>> >>> Filed easyfix: https://fedorahosted.org/freeipa/ticket/4571 >>> >>> >>>> The first patch looks good to me. Just a minor comment. The test >>>> and run >>>> of 'paths.SELINUXENABLED' is present several times in tasks.py and >>>> fedora. Does it worth to refactor it ? >>>> >>>> About the second patch, something I do not understand. >>>> restore_selinux_booleans resets the selinux boolean to the values that >>>> are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . >>>> Does >>>> that mean this dict has been updated with the original values (using >>>> 'backup_func' in set_selinux_booleans ?). >>> >>> This is restoring an IPA installation, not restoring the system to a >>> pre-IPA >>> state. >>> The settings need to be the same as if IPA was being installed. >>> >>> >> OK thanks for the explanation. > > Is this an ACK? > > Martin > Ho sorry, yes for me it is a ACK. thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Sep 26 10:02:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 12:02:32 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <54214161.4080900@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> Message-ID: <542539B8.6030701@redhat.com> On 09/23/2014 11:46 AM, Jan Cholasta wrote: > Dne 6.8.2014 v 18:17 Jan Cholasta napsal(a): >> 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. > > Turns out Dogtag does not like them, so I removed them. > >> >>> >>> Seeing the context makes me wonder if we should eventually add options >>> for CA key size and signing alg as well. >>> >>> rob >>> >> >> > > Updated patch attached. > I tested the patch (it works fine with Dogtag 10), but I got very confused. What CA option are we setting? Signing algorithm or Key Algorithm? I thought we are only setting Signing algorithm, but in that case: - --ca-key-algorithm option should rather read --ca-signing-key-algorithm - Dogtag9 update should only set --signing_algorithm and not --key_algorithm - man page should also be updated with proper explanation. Martin From mkosek at redhat.com Fri Sep 26 10:16:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 12:16:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0633-0634 Move setting SELinux booleans to platform code; Set SELinux booleans when restoring In-Reply-To: <54253877.6020407@redhat.com> References: <53EE7049.3050605@redhat.com> <5422EB10.3030305@redhat.com> <5423D91C.6040503@redhat.com> <5423E1C2.2080507@redhat.com> <542530AB.7080707@redhat.com> <54253877.6020407@redhat.com> Message-ID: <54253D05.8070802@redhat.com> On 09/26/2014 11:57 AM, thierry bordaz wrote: > On 09/26/2014 11:23 AM, Martin Kosek wrote: >> On 09/25/2014 11:34 AM, thierry bordaz wrote: >>> On 09/25/2014 10:58 AM, Petr Viktorin wrote: >>>> On 09/24/2014 06:02 PM, thierry bordaz wrote: >>>>> On 08/15/2014 10:40 PM, Petr Viktorin wrote: >>>>>> 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. >>>> >>>> Filed easyfix: https://fedorahosted.org/freeipa/ticket/4571 >>>> >>>> >>>>> The first patch looks good to me. Just a minor comment. The test and run >>>>> of 'paths.SELINUXENABLED' is present several times in tasks.py and >>>>> fedora. Does it worth to refactor it ? >>>>> >>>>> About the second patch, something I do not understand. >>>>> restore_selinux_booleans resets the selinux boolean to the values that >>>>> are taken from SELINUX_BOOLEAN_SETTINGS in the instance (http/ad) . Does >>>>> that mean this dict has been updated with the original values (using >>>>> 'backup_func' in set_selinux_booleans ?). >>>> >>>> This is restoring an IPA installation, not restoring the system to a pre-IPA >>>> state. >>>> The settings need to be the same as if IPA was being installed. >>>> >>>> >>> OK thanks for the explanation. >> >> Is this an ACK? >> >> Martin >> > Ho sorry, yes for me it is a ACK. > > thierry Ok, thanks. Pushed to: master: dea825fd9cdd36a6fa371b2a5e1d1f35c177c6ef ipa-4-1: 9b5436cbb9d0ab0c4b5a46885d108fda1cdf1b6d Martin From mkosek at redhat.com Fri Sep 26 11:31:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:31:06 +0200 Subject: [Freeipa-devel] [PATCH 0116] Refactoring of service autobind In-Reply-To: <54241358.7080701@redhat.com> References: <53FDDB9B.2070401@redhat.com> <53FF1A20.7010809@redhat.com> <54048203.4060708@redhat.com> <541C1463.6080502@redhat.com> <541C21CB.8050202@redhat.com> <5423D7AE.2090306@redhat.com> <54240EF5.3060801@redhat.com> <54241358.7080701@redhat.com> Message-ID: <54254E7A.8030702@redhat.com> On 09/25/2014 03:06 PM, Martin Basti wrote: > On 25/09/14 14:47, Jan Cholasta wrote: >> Dne 25.9.2014 v 10:51 Martin Basti napsal(a): >>> On 19/09/14 14:30, Jan Cholasta wrote: >>>> Dne 19.9.2014 v 13:32 Martin Basti napsal(a): >>>>> On 01/09/14 16:26, Martin Basti wrote: >>>>>> On 28/08/14 14:01, Jan Cholasta wrote: >>>>>>> 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 >>>>>>> >>>>>> 3) skipped as we discuss on IRC >>>>>> >>>>>> Updated patch attached >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> Please review, this should be in 4.1 >>>> >>>> 1) The patch need a rebase on top of current ipa-4-1. >>> I can apply it (Am I doing something wrong?) >>>> >>>> >>>> 2) You can remove import pwd from service.py, it is no longer used there. >>>> >>>> >>>> 3) Are named constants for the autobind argument the right thing to >>>> do? It is a tri-state which can be expressed with None/True/False. >>>> (I'm just asking, I don't have a strong opinion on this.) >>>> >>> As we discussed on IRC, using None/True/False, is not good approach. >>> Updated patch attached >>> >> >> ACK, but the patch still does not apply cleanly on ipa-4-1: >> >> $ git apply freeipa-mbasti-0116.3-Refactoring-of-autobind-object_exists.patch >> error: patch failed: ipaserver/install/service.py:20 >> error: ipaserver/install/service.py: patch does not apply >> > Rebased patches attached Pushed to: master: 29ba9d9d26b92498902d40d71adae193308b5c92 ipa-4-1: 8e0f8bc7ad8e91bcf9e30e3cc8159838977348e6 Martin From dkupka at redhat.com Fri Sep 26 11:37:22 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 13:37:22 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <54251C2C.2050101@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <54251C2C.2050101@redhat.com> Message-ID: <54254FF2.7020108@redhat.com> On 09/26/2014 09:56 AM, Martin Kosek wrote: > On 09/02/2014 10:18 AM, Jan Cholasta wrote: >> Dne 27.8.2014 v 16:49 David Kupka napsal(a): >>> 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 >>>>> >>>> >>> >> >> ACK as long as this works for Nalin. >> > > I see Nalin is OK with the patch, I am not so OK. What should we do with > the server option then? It is still being referred to as "Deprecated" in > the man page. Should we then un-deprecate it as Honza suggested down the > thread? > > Martin Ok, changed man page. It no longer refer "server" as deprecated. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0010-3-Add-host-setting-into-default.conf-configuration-fil.patch Type: text/x-patch Size: 3954 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 26 11:37:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:37:30 +0200 Subject: [Freeipa-devel] [PATCH 0118] Allow to disable service (in LDAP) In-Reply-To: <54243151.20904@redhat.com> References: <5404896C.4030907@redhat.com> <54056D55.7030102@redhat.com> <540594F3.2030001@redhat.com> <541C14A4.2010907@redhat.com> <541C25CB.8060801@redhat.com> <54205CA9.8000708@redhat.com> <54242398.4000507@redhat.com> <54243151.20904@redhat.com> Message-ID: <54254FFA.5090400@redhat.com> On 09/25/2014 05:14 PM, Jan Cholasta wrote: > Dne 25.9.2014 v 16:15 Martin Basti napsal(a): >> On 22/09/14 19:30, Martin Basti wrote: >>> On 19/09/14 14:47, Jan Cholasta wrote: >>>> Dne 19.9.2014 v 13:33 Martin Basti napsal(a): >>>>> On 02/09/14 11:59, Martin Basti wrote: >>>>>> On 02/09/14 09:10, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Dne 1.9.2014 v 16:57 Martin Basti napsal(a): >>>>>>>> This patch allows to disable service in LDAP to prevents service >>>>>>>> to be >>>>>>>> started by "ipactl restart" >>>>>>>> >>>>>>>> Required by DNSSEC >>>>>>>> >>>>>>>> Patch attached >>>>>>> >>>>>>> I don't think the extra argument in ldap_enable is necessary. It >>>>>>> should enable the service no matter if the entry existed before or >>>>>>> not. >>>>>>> >>>>>>> Similarly, in ldap_disable you should not raise an error when the >>>>>>> entry is not found, because that already makes the service disabled. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> Updated patch attached >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> Please review, this should be in 4.1 >>>>> >>>>> -- >>>>> Martin Basti >>>> >>>> 1) ipaConfigString is case-insensitive, so you need to look for the >>>> string "enabledService" in a case-insensitive way. >>>> >>>> >>>> 2) Don't say "failed to enable ..." when the service is already >>>> enabled. It is not a failure. Same for disabled. >>>> >>>> >>>> 3) Missing ipaConfigString is nothing to warn about. >>>> >>>> >>>> 4) You should log success in both ldap_enable/ldap_disable. >>>> >>>> >>>> 5) The except below update_entry should say "except >>>> errors.EmptyModlist". >>>> >>>> >>> Thank you, >>> >>> updated patch attached >>> >> Updated patch attached. I modified ldap_disable to use search function. >> > > ACK. > Pushed to: master: 66ce71f17a689bcad03022e3df6bbdf0fada2ab8 ipa-4-1: df9086c938963fdf59309cd8af69f4f5d8a7a34e Martin From jcholast at redhat.com Fri Sep 26 11:41:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Sep 2014 13:41:26 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <542539B8.6030701@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> Message-ID: <542550E6.6010806@redhat.com> Dne 26.9.2014 v 12:02 Martin Kosek napsal(a): > On 09/23/2014 11:46 AM, Jan Cholasta wrote: >> Dne 6.8.2014 v 18:17 Jan Cholasta napsal(a): >>> 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. >> >> Turns out Dogtag does not like them, so I removed them. >> >>> >>>> >>>> Seeing the context makes me wonder if we should eventually add options >>>> for CA key size and signing alg as well. >>>> >>>> rob >>>> >>> >>> >> >> Updated patch attached. >> > > I tested the patch (it works fine with Dogtag 10), but I got very confused. > > What CA option are we setting? Signing algorithm or Key Algorithm? I > thought we are only setting Signing algorithm, but in that case: We are setting key algorithm for the CA signing key. > > - --ca-key-algorithm option should rather read --ca-signing-key-algorithm If you want to emphasize that it is actually the algorithm used to sign the CA certificate, the option should read --ca-certificate-signature-algorithm, but I would rather stick to Dogtag terminology and keep the string "key algorithm" in the name. > - Dogtag9 update should only set --signing_algorithm and not > --key_algorithm It should not, because then *all* the certificates issued by the CA would use that algorithm, instead of just the CA certificate. > - man page should also be updated with proper explanation. And that would be? > > Martin -- Jan Cholasta From mkosek at redhat.com Fri Sep 26 11:40:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:40:01 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file In-Reply-To: <54254FF2.7020108@redhat.com> References: <53FC68F2.4040104@redhat.com> <53FC86DA.6010408@redhat.com> <53FC8BEE.5070206@redhat.com> <53FC91EB.5020603@redhat.com> <53FDA35D.8040407@redhat.com> <53FDF008.9040306@redhat.com> <54057D44.9040107@redhat.com> <54251C2C.2050101@redhat.com> <54254FF2.7020108@redhat.com> Message-ID: <54255091.7000001@redhat.com> On 09/26/2014 01:37 PM, David Kupka wrote: > On 09/26/2014 09:56 AM, Martin Kosek wrote: >> On 09/02/2014 10:18 AM, Jan Cholasta wrote: >>> Dne 27.8.2014 v 16:49 David Kupka napsal(a): >>>> 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 >>>>>> >>>>> >>>> >>> >>> ACK as long as this works for Nalin. >>> >> >> I see Nalin is OK with the patch, I am not so OK. What should we do with >> the server option then? It is still being referred to as "Deprecated" in >> the man page. Should we then un-deprecate it as Honza suggested down the >> thread? >> >> Martin > > Ok, changed man page. It no longer refer "server" as deprecated. > LGTM. Pushed to: master: 89c4f1242558d725a1771dce444df5737e49289e ipa-4-1: d82bc63960c22783d8fb56bcca5e21825d9a02cc Martin From jcholast at redhat.com Fri Sep 26 11:55:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Sep 2014 13:55:12 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <5422EDA1.4060004@redhat.com> References: <5422EDA1.4060004@redhat.com> Message-ID: <54255420.3060004@redhat.com> Dne 24.9.2014 v 18:13 Jan Cholasta napsal(a): > Hi, > > the attached patches fix > and . > > (Note that design page for this is TBD.) > > Honza Polished the code up a bit and rebased on top of current ipa-4-1. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-336.1-Add-NSSDatabase.import_files-method-for-importing-fi.patch Type: text/x-patch Size: 8305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-337.1-External-CA-installer-options-usability-fixes.patch Type: text/x-patch Size: 25639 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-338.1-CA-less-installer-options-usability-fixes.patch Type: text/x-patch Size: 44730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-339.1-Allow-choosing-CA-less-server-certificates-by-name.patch Type: text/x-patch Size: 9443 bytes Desc: not available URL: From mkosek at redhat.com Fri Sep 26 11:54:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:54:34 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <542550E6.6010806@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> Message-ID: <542553FA.4080400@redhat.com> On 09/26/2014 01:41 PM, Jan Cholasta wrote: > Dne 26.9.2014 v 12:02 Martin Kosek napsal(a): >> On 09/23/2014 11:46 AM, Jan Cholasta wrote: >>> Dne 6.8.2014 v 18:17 Jan Cholasta napsal(a): >>>> 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. >>> >>> Turns out Dogtag does not like them, so I removed them. >>> >>>> >>>>> >>>>> Seeing the context makes me wonder if we should eventually add options >>>>> for CA key size and signing alg as well. >>>>> >>>>> rob >>>>> >>>> >>>> >>> >>> Updated patch attached. >>> >> >> I tested the patch (it works fine with Dogtag 10), but I got very confused. >> >> What CA option are we setting? Signing algorithm or Key Algorithm? I >> thought we are only setting Signing algorithm, but in that case: > > We are setting key algorithm for the CA signing key. That did not made me any less confused... If I check for example fields from certificate details from my browser, I see 2 algorithms names: * Public Key Algorithm (RSA, ECC, ...) * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, something with ECC) In that world, "key algorithm" should really refer to the key PKI algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes come to play. >> - --ca-key-algorithm option should rather read --ca-signing-key-algorithm > > If you want to emphasize that it is actually the algorithm used to sign the CA > certificate, the option should read --ca-certificate-signature-algorithm, but I > would rather stick to Dogtag terminology and keep the string "key algorithm" in > the name. I still think for most people "key algorithm" refers to Public Key algorithm. Rob or Simo, what is your take on this? > >> - Dogtag9 update should only set --signing_algorithm and not >> --key_algorithm > > It should not, because then *all* the certificates issued by the CA would use > that algorithm, instead of just the CA certificate. Ok. > >> - man page should also be updated with proper explanation. > > And that would be? That would be something specifically referring to singing. You can also add a note when the option can be used. Whether with --external-ca only or with any CA option. From dkupka at redhat.com Fri Sep 26 12:47:42 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 14:47:42 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54252409.7080002@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> <54252409.7080002@redhat.com> Message-ID: <5425606E.5090703@redhat.com> On 09/26/2014 10:30 AM, David Kupka wrote: > On 09/26/2014 09:34 AM, Jan Cholasta wrote: >> Dne 26.9.2014 v 08:28 David Kupka napsal(a): >>> On 09/25/2014 04:17 PM, David Kupka wrote: >>>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>>> On 24/09/14 15:44, David Kupka wrote: >>>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>>> ... >>>>>>>>> 1) >>>>>>>>> + if options.unattended: >>>>>>>>> + for ip in ip_addresses: >>>>>>>>> + if search_reverse_zones and >>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>> + continue >>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>> + # reverse zone was entered by user >>>>>>>>> + break >>>>>>>>> + else: >>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>>> + for ip in ip_addresses: >>>>>>>>> + if search_reverse_zones and >>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>> + continue >>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>> + # reverse zone was entered by user >>>>>>>>> + break >>>>>>>>> + else: >>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>> + else: >>>>>>>>> + options.no_reverse = True >>>>>>>>> + ret_reverse_zones = [] >>>>>>>>> >>>>>>>>> You can make it shorter without duplications: >>>>>>>>> >>>>>>>>> # this ifs can be in one line >>>>>>>>> if not options.unatended: >>>>>>>>> if not options.reverse_zones >>>>>>>>> if not create_reverse(): >>>>>>>>> options.no_reverse=True >>>>>>>>> return [] >>>>>>>>> >>>>>>>>> for ip in ip_addresses: >>>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>>> # reverse zone is already in LDAP >>>>>>>>> continue >>>>>>>>> for rz in ret_reverse_zones: >>>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>>> # reverse zone was entered by user >>>>>>>>> break >>>>>>>>> else: >>>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>>> if not options.unattended: >>>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>>> ret_reverse_zones.append(rz) >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, I modified it bit different way to alse address >>>>>>>> recommendation >>>>>>>> 3). >>>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>>> ---------------------------------------------^^ >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> Would be nice to ask user to create new zones only if new zones >>>>>>>>> are >>>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>>> anyway) >>>>>>>>> >>>>>>>> >>>>>>>> I added one more variable and ask only once. >>>>>>>> >>>>>>>>> 4) >>>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>>> function >>>>>>>>> above >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> NACK, most important point is 7 >>>>>>> >>>>>>> 1) >>>>>>> I'm not sure if this is bug, but interactively is allowed to add >>>>>>> only >>>>>>> one ip address >>>>>>> >>>>>>> Unable to resolve IP address for host name >>>>>>> Please provide the IP address to be used for this host name: >>>>>>> 2001:db8::2 >>>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>>> >>>>>> >>>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>>> multiple addresses the same way as for DNS forwarders. Also I really >>>>>> simplified IP address checking code when I was in it. I tested it but >>>>>> please look at it carefully. >>>>>> Also I found that ipa-dns-install and ipa-adtrust-install also accept >>>>>> --ip-address param. So I modified ipa-dns-install in the same way as >>>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>>> use specified value at all. I will remove the processing code and >>>>>> mark >>>>>> the param as deprecated in separate patch. >>>>>> >>>>>>> 2) >>>>>>> I'm getting error message >>>>>>> >>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>> 2001:db8::dead:beef >>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>> >>>>>>> - or - >>>>>>> >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> Please specify the reverse zone name >>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. >>>>>>> for IP >>>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>> Please specify the reverse zone name >>>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>> >>>>>>> This shouldn't be there >>>>>> >>>>>> Moved the message to function used when installation is attended by >>>>>> user. >>>>>> >>>>>>> >>>>>>> Could be better to ask user to specific zone for ip address a.b.c.d. >>>>>> >>>>>> Probably, but lets leave some work for future. >>>>>> >>>>>>> >>>>>>> 4) just nitpick >>>>>>> The IPA Master Server will be configured with: >>>>>>> ... >>>>>>> IP address(es): 2001:db8::dead:beef, >>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>> ... >>>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>> >>>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>>> zone(s)" >>>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 5) >>>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>>> --setup-dns >>>>>>> >>>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>>> sure >>>>>>> if this is wrong, but we prevents user to add zone without >>>>>>> address in >>>>>>> it, so we should prevents, to add empty zone. >>>>>>> >>>>>> >>>>>> It would be nice but not in this patch. >>>>>> >>>>>>> 6) >>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>>> vm-105.example.com >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>>> >>>>>>> IMO This should work, right? >>>>>>> >>>>>>> + sys.exit("There is no IP address matching reverse >>>>>>> zone >>>>>>> %s." % rz) >>>>>>> I expected at least this error to be shown. >>>>>> >>>>>> Fixed, thanks. >>>>>> >>>>>>> >>>>>>> 7) >>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> ....... >>>>>>> Adding DNS records for vm-105.example.com >>>>>>> Values instance has no attribute 'ip_address' >>>>>>> >>>>>>> Command returns the attribute error. >>>>>>> It fails with one --ip-address too. >>>>>>> >>>>>> >>>>>> Sorry, fixed. >>>>>> >>>>>>> >>>>>>> *) Not related with your patch >>>>>>> Problem with installation: >>>>>>> I'm getting message: >>>>>>> IPA server is already configured on this system. >>>>>>> Even if I validation wasn't successful and installation was aborted. >>>>>>> >>>>>>> IPA install detects previous installations by checking state file >>>>>>> and >>>>>>> restore files. Function get_server_ip_address() stores some data and >>>>>>> hosts file and modify the host file, before user agreed >>>>>>> installation. >>>>>>> This error was there before your patch. >>>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> NACK >>>>> >>>>> 0) >>>>> # ipa-dns-install --ip-address 2001:db8::feed >>>>> >>>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>>> 2014-09-24T06:02:13Z DEBUG File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 645, in run_script >>>>> return_value = main_function() >>>>> >>>>> File "/sbin/ipa-dns-install", line 135, in main >>>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>>> options.unattended, options) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 473, in get_server_ip_address >>>>> if options.setup_dns: >>>>> >>>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>>> exception: AttributeError: Values instance has no attribute >>>>> 'setup_dns' >>>> >>>> Obviously there is no option --setup-dns in ipa-dns-install. >>>> Fixed, modified get_server_ip_address function. >>>> >>>>> >>>>> 1) >>>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>>> Directory Manager (existing master) password: >>>>> >>>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>>> Creating SSL certificate for the Directory Server >>>>> Creating SSL certificate for the dogtag Directory Server >>>>> Saving dogtag Directory Server port >>>>> Creating SSL certificate for the Web Server >>>>> Exporting RA certificate >>>>> Copying additional files >>>>> Finalizing configuration >>>>> Packaging replica information into >>>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>>> Adding DNS records for vm-073.example.com >>>>> Values instance has no attribute 'unattended' >>>>> >>>>> It should be unatended automatically, or we need add the --unattended >>>>> option to ipa-replica-prepare >>>> >>>> ipa-replica-install is missing --unattended option. I fixed it in my >>>> code for now but we should add it there. >>>> >>>>> >>>>> 2) This is nto user friendly, could be IP address check before >>>>> installation? >>>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>>> --no-forwarders >>>>> Directory Manager (existing master) password: >>>>> >>>>> Run connection check to master >>>>> ... >>>>> >>>>> ... >>>>> Restarting the KDC >>>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>>> >>>>> LOG: >>>>> return_value = main_function() >>>>> >>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>> install_bind(config, options) >>>>> >>>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>>> reverse_zones = >>>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>>> options.reverse_zones, options, True) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>> line 426, in check_reverse_zones >>>>> sys.exit("There is no IP address matching reverse zone %s." % rz) >>>>> >>>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>>> exception: SystemExit: There is no IP address matching reverse zone >>>>> 10.in-addr.arpa.. >>>> >>>> Fixed. Asking everything before actual installation. >>>> >>>>> >>>>> 3) >>>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>>> something about partially configured system >>>> >>>> This is quite common in installation scripts. I moved this parts before >>>> actual installation. >>>> >>>>> >>>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>>> .... >>>>> Done configuring the web interface (httpd). >>>>> Configuring ipa-otpd >>>>> [1/2]: starting ipa-otpd >>>>> [2/2]: configuring ipa-otpd to start on boot >>>>> Done configuring ipa-otpd. >>>>> Applying LDAP updates >>>>> Restarting the directory server >>>>> Restarting the KDC >>>>> Do you want to configure the reverse zone? [yes]: >>>> >>>> Moved. >>>> >>>>> >>>>> 5) And error >>>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>>> --setup-dns >>>>> .... >>>>> Do you want to configure the reverse zone? [yes]: >>>>> Please specify the reverse zone name >>>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>>> >>>>> Your system may be partly configured. >>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>> >>>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>>> AttributeError: 'str' object has no attribute 'version' >>>>> >>>>> LOG: >>>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>>> conn= >>>>> 2014-09-24T06:50:45Z DEBUG File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 645, in run_script >>>>> return_value = main_function() >>>>> >>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>> install_bind(config, options) >>>>> >>>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>>> ca_configured=options.setup_ca) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>> line 550, in setup >>>>> self.__setup_sub_dict() >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>> line 651, in __setup_sub_dict >>>>> if addr.version in (4, 6): >>>>> >>>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>>> exception: AttributeError: 'str' object has no attribute 'version' >>>> >>>> Fixed. We are using IP addresses as a strings and as a >>>> CheckedIPAddress. >>>> I swapped them here. >>>>> >>>>> >>>>> *) I don't like this asking to specify zone without IP >>>>> Do you want to configure the reverse zone? [yes]: >>>>> Please specify the reverse zone name >>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>>> >>>> >>>> Would be nice. Prefer to do it as a part of more powerfull reverse zone >>>> validation logic. >>>>> >>>>> >>>>> **) I'm not sure how often this case can happen: >>>>> master and replica without DNS, you run --ipa-dns-install on master >>>>> then >>>>> on replica, then replica DNS installation will not try to find >>>>> existent >>>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>>> Maybe you should detect if DNS container exists and then set flag >>>>> "search_reverse_zones=True" >>>>> >>>>> ipa-dns-install: >>>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>>> options.reverse_zones, options) >>>> >>>> Same as above. >>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> Rebased to current master and ipa-4-1. Removed unintentional >>> modification of ipa-adtrust-install. >> >> + for ip, ip_address in zip(config.ips, config.ip_addresses): >> + reverse_zone = bindinstance.find_reverse_zone(ip) >> >> Is it always 100% guaranteed that the values in config.ips and >> config.ip_addresses are the same length and otherwise match each other >> in a way that will not cause things to break? IMO it would be better to >> store a single list of 2-tuples somewhere from the start instead of >> zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, >> 'yes')].) >> > > The chances that this will break are really small but I cannot guarantee > that it won't eventually. > One list (config.ip_addresses) is generated from the other (config.ips) > and right now there is no need to modify them. But if someone in the > future modify only one of them it will fail really badly. So I removed > zip() and convert the ip address to string on demand. It will cost a few > more cycles but also will be less error prone. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Another few flaws eradicated. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-13-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-13-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43276 bytes Desc: not available URL: From redhatrises at gmail.com Fri Sep 26 13:08:06 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 26 Sep 2014 07:08:06 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile In-Reply-To: <534E65CE.8070504@redhat.com> References: <534E65CE.8070504@redhat.com> Message-ID: Hello, Just wondering if we have found a reviewer for this patch set? It would be nice to have this as a part of the docs. Thanks, Gabe On Wed, Apr 16, 2014 at 5:13 AM, Petr Spacek wrote: > On 16.4.2014 05:01, Gabe Alford wrote: > >> The following patches update the Solaris documentation and add a proxy >> agent/profile for Solaris. >> >> - Solaris documentation update >> https://fedorahosted.org/freeipa/ticket/3731 >> >> - Patch adds default Proxy Agent and default_secure profile through >> 20-nss_ldap.update when ipa-server-install is run. >> https://fedorahosted.org/freeipa/ticket/2561 >> > > Thank you Gabe! > > I think this chapter deserves review from a Solaris expert. Core IPA team > doesn't have one so we need to find some victim ... :-) > > Sigbjorn, would you mind reviewing this patch set? > > Instructions how to build docs are here: > http://www.freeipa.org/page/Contribute/Documentation > > Thank you very much! > > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Sep 26 13:16:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 15:16:12 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile In-Reply-To: References: <534E65CE.8070504@redhat.com> Message-ID: <5425671C.3090700@redhat.com> I saw a similar interest on freeipa-users list in "FreeIPA 3.3 and Solaris 10 Client Integration:" thread. Also note it is proposed to only have the guide maintained in the downstream guide in "[Freeipa-users] What should we do with upstream guide?" thread (I know you know about it). So it is likely the patch would only be applied either in downstream doc or would be even transferred in an article/howto on FreeIPA.org so that Solaris users can easily update it. Martin On 09/26/2014 03:08 PM, Gabe Alford wrote: > Hello, > > Just wondering if we have found a reviewer for this patch set? It would > be nice to have this as a part of the docs. > > Thanks, > > Gabe > > On Wed, Apr 16, 2014 at 5:13 AM, Petr Spacek > wrote: > > On 16.4.2014 05:01, Gabe Alford wrote: > > The following patches update the Solaris documentation and add a proxy > agent/profile for Solaris. > > - Solaris documentation update > https://fedorahosted.org/__freeipa/ticket/3731 > > > - Patch adds default Proxy Agent and default_secure profile through > 20-nss_ldap.update when ipa-server-install is run. > https://fedorahosted.org/__freeipa/ticket/2561 > > > > Thank you Gabe! > > I think this chapter deserves review from a Solaris expert. Core IPA team > doesn't have one so we need to find some victim ... :-) > > Sigbjorn, would you mind reviewing this patch set? > > Instructions how to build docs are here: > http://www.freeipa.org/page/__Contribute/Documentation > > > Thank you very much! > > -- > Petr^2 Spacek > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From fra.marella at gmx.com Fri Sep 26 13:35:43 2014 From: fra.marella at gmx.com (Francesco Marella) Date: Fri, 26 Sep 2014 15:35:43 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check Message-ID: <54256BAF.5090305@gmx.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fmarella-0001-Refactor-selinuxenabled-check.patch Type: text/x-patch Size: 3133 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 26 13:41:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Sep 2014 15:41:18 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <54256BAF.5090305@gmx.com> References: <54256BAF.5090305@gmx.com> Message-ID: <54256CFE.5030307@redhat.com> Hello! Thanks for the patch! The new function is not one of the platform-independent tasks, and doesn't even use `self`, so you can define it as a module-level helper function. But more importantly, this won't work: the blocks you are replacing return from their functions. You'd need to use something like: if not selinux_enabled(): return instead of: self.check_enabled_selinux() -- Petr? From tbordaz at redhat.com Fri Sep 26 13:41:52 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 26 Sep 2014 15:41:52 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <54256BAF.5090305@gmx.com> References: <54256BAF.5090305@gmx.com> Message-ID: <54256D20.7010109@redhat.com> On 09/26/2014 03:35 PM, Francesco Marella wrote: > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, I think that if we want to keep the same previous behaviour, then if 'self.check_enabled_selinux()' returns False, the caller should also return or return False. thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Fri Sep 26 13:55:15 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 26 Sep 2014 07:55:15 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile In-Reply-To: <5425671C.3090700@redhat.com> References: <534E65CE.8070504@redhat.com> <5425671C.3090700@redhat.com> Message-ID: If we can, let's try to push the doc patch 0014 downstream (except for patch 0015 as that patch is an ldif update). Gabe On Fri, Sep 26, 2014 at 7:16 AM, Martin Kosek wrote: > I saw a similar interest on freeipa-users list in "FreeIPA 3.3 and Solaris > 10 Client Integration:" thread. Also note it is proposed to only have the > guide maintained in the downstream guide in "[Freeipa-users] What should we > do with upstream guide?" thread (I know you know about it). > > So it is likely the patch would only be applied either in downstream doc > or would be even transferred in an article/howto on FreeIPA.org so that > Solaris users can easily update it. > > Martin > > On 09/26/2014 03:08 PM, Gabe Alford wrote: > >> Hello, >> >> Just wondering if we have found a reviewer for this patch set? It >> would >> be nice to have this as a part of the docs. >> >> Thanks, >> >> Gabe >> >> On Wed, Apr 16, 2014 at 5:13 AM, Petr Spacek > > wrote: >> >> On 16.4.2014 05:01, Gabe Alford wrote: >> >> The following patches update the Solaris documentation and add a >> proxy >> agent/profile for Solaris. >> >> - Solaris documentation update >> https://fedorahosted.org/__freeipa/ticket/3731 >> >> >> - Patch adds default Proxy Agent and default_secure profile >> through >> 20-nss_ldap.update when ipa-server-install is run. >> https://fedorahosted.org/__freeipa/ticket/2561 >> >> >> >> Thank you Gabe! >> >> I think this chapter deserves review from a Solaris expert. Core IPA >> team >> doesn't have one so we need to find some victim ... :-) >> >> Sigbjorn, would you mind reviewing this patch set? >> >> Instructions how to build docs are here: >> http://www.freeipa.org/page/__Contribute/Documentation >> >> >> Thank you very much! >> >> -- >> 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 Fri Sep 26 14:14:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Sep 2014 16:14:24 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure In-Reply-To: <542535E7.7010900@redhat.com> References: <53F76AB4.5000708@redhat.com> <5422841D.8080205@redhat.com> <5423FB84.8070105@redhat.com> <542535E7.7010900@redhat.com> Message-ID: <542574C0.3000304@redhat.com> On 09/26/2014 11:46 AM, Martin Kosek wrote: > On 09/25/2014 01:24 PM, Martin Kosek wrote: >> On 09/24/2014 10:43 AM, Martin Kosek wrote: >>> On 08/22/2014 06:07 PM, Petr Viktorin wrote: >>>> 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? >>> >>> This works pretty nicely, I liked the service.py extension. >>> >>> My test output: >>> >>> # ipa-ldap-updater --upgrade >>> Upgrading IPA: >>> [1/10]: stopping directory server >>> [2/10]: saving configuration >>> [3/10]: disabling listeners >>> [4/10]: starting directory server >>> [5/10]: preparing server upgrade >>> PRE_SCHEMA_UPDATE >>> [6/10]: updating schema >>> ... >>> [7/10]: upgrading server >>> [error] ValueError: Ha! >>> [cleanup]: stopping directory server >>> [cleanup]: restoring configuration >>> >>> # ipactl start >>> # netstat -putna | grep 389 >>> ... >>> tcp6 0 0 10.16.78.147:389 10.16.78.147:37490 >>> ESTABLISHED >>> 5956/ns-slapd >>> >>> So I am willing to ACK if there are no other objections. >>> >>> Martin >> >> I read the silence as "no objections", so ACK. >> >> Pushed to: >> master: 9a188607fcf68721fc8c38c3c73ee02cac76b58a >> ipa-4-1: b333e7adc98ff7c5335fbc7ce1bde5b9dfb3f5ef >> >> Martin > > Just found (benign) display issue with this patch when --external-ca is > used. See: > > https://fedorahosted.org/freeipa/ticket/4499#comment:4 > > Martin You're right. This patch should fix that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0649-ipaserver.install.service-Don-t-show-error-message-o.patch Type: text/x-patch Size: 1847 bytes Desc: not available URL: From fra.marella at gmx.com Fri Sep 26 14:30:43 2014 From: fra.marella at gmx.com (Francesco Marella) Date: Fri, 26 Sep 2014 16:30:43 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <54256CFE.5030307@redhat.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> Message-ID: <54257893.9010607@gmx.com> On 26/09/2014 15:41, Petr Viktorin wrote: > > Hello! Thanks for the patch! > > The new function is not one of the platform-independent tasks, and > doesn't even use `self`, so you can define it as a module-level helper > function. > > But more importantly, this won't work: the blocks you are replacing > return from their functions. You'd need to use something like: > if not selinux_enabled(): > return > instead of: > self.check_enabled_selinux() > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fmarella-0001-2-Refactor-selinuxenabled-check.patch Type: text/x-patch Size: 2931 bytes Desc: not available URL: From ssorce at redhat.com Fri Sep 26 14:44:16 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 26 Sep 2014 10:44:16 -0400 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <542553FA.4080400@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> Message-ID: <20140926104416.44548b7c@willson.usersys.redhat.com> On Fri, 26 Sep 2014 13:54:34 +0200 Martin Kosek wrote: > >> I tested the patch (it works fine with Dogtag 10), but I got very > >> confused. > >> > >> What CA option are we setting? Signing algorithm or Key Algorithm? > >> I thought we are only setting Signing algorithm, but in that > >> case: > > > > We are setting key algorithm for the CA signing key. > > That did not made me any less confused... If I check for example > fields from certificate details from my browser, I see 2 algorithms > names: > > * Public Key Algorithm (RSA, ECC, ...) > * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, > something with ECC) > > In that world, "key algorithm" should really refer to the key PKI > algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes > come to play. > > >> - --ca-key-algorithm option should rather read > >> --ca-signing-key-algorithm > > > > If you want to emphasize that it is actually the algorithm used to > > sign the CA certificate, the option should read > > --ca-certificate-signature-algorithm, but I would rather stick to > > Dogtag terminology and keep the string "key algorithm" in the > > name. > > I still think for most people "key algorithm" refers to Public Key > algorithm. Rob or Simo, what is your take on this? If we are defining the signing algorithm the "signing" string should be somewhere in the option. Having just --key-algorithm is indeed confusing. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Sep 26 14:58:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 16:58:00 +0200 Subject: [Freeipa-devel] [PATCH] 0637 upgradeinstance: Restore listeners on failure In-Reply-To: <542574C0.3000304@redhat.com> References: <53F76AB4.5000708@redhat.com> <5422841D.8080205@redhat.com> <5423FB84.8070105@redhat.com> <542535E7.7010900@redhat.com> <542574C0.3000304@redhat.com> Message-ID: <54257EF8.6030707@redhat.com> On 09/26/2014 04:14 PM, Petr Viktorin wrote: > On 09/26/2014 11:46 AM, Martin Kosek wrote: >> On 09/25/2014 01:24 PM, Martin Kosek wrote: >>> On 09/24/2014 10:43 AM, Martin Kosek wrote: >>>> On 08/22/2014 06:07 PM, Petr Viktorin wrote: >>>>> 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? >>>> >>>> This works pretty nicely, I liked the service.py extension. >>>> >>>> My test output: >>>> >>>> # ipa-ldap-updater --upgrade >>>> Upgrading IPA: >>>> [1/10]: stopping directory server >>>> [2/10]: saving configuration >>>> [3/10]: disabling listeners >>>> [4/10]: starting directory server >>>> [5/10]: preparing server upgrade >>>> PRE_SCHEMA_UPDATE >>>> [6/10]: updating schema >>>> ... >>>> [7/10]: upgrading server >>>> [error] ValueError: Ha! >>>> [cleanup]: stopping directory server >>>> [cleanup]: restoring configuration >>>> >>>> # ipactl start >>>> # netstat -putna | grep 389 >>>> ... >>>> tcp6 0 0 10.16.78.147:389 10.16.78.147:37490 >>>> ESTABLISHED >>>> 5956/ns-slapd >>>> >>>> So I am willing to ACK if there are no other objections. >>>> >>>> Martin >>> >>> I read the silence as "no objections", so ACK. >>> >>> Pushed to: >>> master: 9a188607fcf68721fc8c38c3c73ee02cac76b58a >>> ipa-4-1: b333e7adc98ff7c5335fbc7ce1bde5b9dfb3f5ef >>> >>> Martin >> >> Just found (benign) display issue with this patch when --external-ca is >> used. See: >> >> https://fedorahosted.org/freeipa/ticket/4499#comment:4 >> >> Martin > > You're right. This patch should fix that. It does! ACK. Pushed to: master: f86618623964f9a97244ce08117c575b200a34af ipa-4-1: 540f4166e45752ae74f652f66eec9b92413a5d1e Martin From dkupka at redhat.com Fri Sep 26 15:00:51 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 17:00:51 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5425606E.5090703@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> <54252409.7080002@redhat.com> <5425606E.5090703@redhat.com> Message-ID: <54257FA3.4070208@redhat.com> On 09/26/2014 02:47 PM, David Kupka wrote: > On 09/26/2014 10:30 AM, David Kupka wrote: >> On 09/26/2014 09:34 AM, Jan Cholasta wrote: >>> Dne 26.9.2014 v 08:28 David Kupka napsal(a): >>>> On 09/25/2014 04:17 PM, David Kupka wrote: >>>>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>>>> On 24/09/14 15:44, David Kupka wrote: >>>>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>>>> ... >>>>>>>>>> 1) >>>>>>>>>> + if options.unattended: >>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>> + if search_reverse_zones and >>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>> + continue >>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>> + break >>>>>>>>>> + else: >>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>> + if search_reverse_zones and >>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>> + continue >>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>> + break >>>>>>>>>> + else: >>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>> + else: >>>>>>>>>> + options.no_reverse = True >>>>>>>>>> + ret_reverse_zones = [] >>>>>>>>>> >>>>>>>>>> You can make it shorter without duplications: >>>>>>>>>> >>>>>>>>>> # this ifs can be in one line >>>>>>>>>> if not options.unatended: >>>>>>>>>> if not options.reverse_zones >>>>>>>>>> if not create_reverse(): >>>>>>>>>> options.no_reverse=True >>>>>>>>>> return [] >>>>>>>>>> >>>>>>>>>> for ip in ip_addresses: >>>>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>>>> # reverse zone is already in LDAP >>>>>>>>>> continue >>>>>>>>>> for rz in ret_reverse_zones: >>>>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>>>> # reverse zone was entered by user >>>>>>>>>> break >>>>>>>>>> else: >>>>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> if not options.unattended: >>>>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>> ret_reverse_zones.append(rz) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, I modified it bit different way to alse address >>>>>>>>> recommendation >>>>>>>>> 3). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>>>> ---------------------------------------------^^ >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> Would be nice to ask user to create new zones only if new zones >>>>>>>>>> are >>>>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>>>> anyway) >>>>>>>>>> >>>>>>>>> >>>>>>>>> I added one more variable and ask only once. >>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>>>> function >>>>>>>>>> above >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> NACK, most important point is 7 >>>>>>>> >>>>>>>> 1) >>>>>>>> I'm not sure if this is bug, but interactively is allowed to add >>>>>>>> only >>>>>>>> one ip address >>>>>>>> >>>>>>>> Unable to resolve IP address for host name >>>>>>>> Please provide the IP address to be used for this host name: >>>>>>>> 2001:db8::2 >>>>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>>>> >>>>>>> >>>>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>>>> multiple addresses the same way as for DNS forwarders. Also I really >>>>>>> simplified IP address checking code when I was in it. I tested it >>>>>>> but >>>>>>> please look at it carefully. >>>>>>> Also I found that ipa-dns-install and ipa-adtrust-install also >>>>>>> accept >>>>>>> --ip-address param. So I modified ipa-dns-install in the same way as >>>>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>>>> use specified value at all. I will remove the processing code and >>>>>>> mark >>>>>>> the param as deprecated in separate patch. >>>>>>> >>>>>>>> 2) >>>>>>>> I'm getting error message >>>>>>>> >>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>> 2001:db8::dead:beef >>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> >>>>>>>> - or - >>>>>>>> >>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>> Please specify the reverse zone name >>>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. >>>>>>>> for IP >>>>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> Please specify the reverse zone name >>>>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>> >>>>>>>> This shouldn't be there >>>>>>> >>>>>>> Moved the message to function used when installation is attended by >>>>>>> user. >>>>>>> >>>>>>>> >>>>>>>> Could be better to ask user to specific zone for ip address >>>>>>>> a.b.c.d. >>>>>>> >>>>>>> Probably, but lets leave some work for future. >>>>>>> >>>>>>>> >>>>>>>> 4) just nitpick >>>>>>>> The IPA Master Server will be configured with: >>>>>>>> ... >>>>>>>> IP address(es): 2001:db8::dead:beef, >>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> ... >>>>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>> >>>>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>>>> zone(s)" >>>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 5) >>>>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>>>> --setup-dns >>>>>>>> >>>>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>>>> sure >>>>>>>> if this is wrong, but we prevents user to add zone without >>>>>>>> address in >>>>>>>> it, so we should prevents, to add empty zone. >>>>>>>> >>>>>>> >>>>>>> It would be nice but not in this patch. >>>>>>> >>>>>>>> 6) >>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>>>> vm-105.example.com >>>>>>>> Directory Manager (existing master) password: >>>>>>>> >>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>>>> >>>>>>>> IMO This should work, right? >>>>>>>> >>>>>>>> + sys.exit("There is no IP address matching reverse >>>>>>>> zone >>>>>>>> %s." % rz) >>>>>>>> I expected at least this error to be shown. >>>>>>> >>>>>>> Fixed, thanks. >>>>>>> >>>>>>>> >>>>>>>> 7) >>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>>>> Directory Manager (existing master) password: >>>>>>>> >>>>>>>> ....... >>>>>>>> Adding DNS records for vm-105.example.com >>>>>>>> Values instance has no attribute 'ip_address' >>>>>>>> >>>>>>>> Command returns the attribute error. >>>>>>>> It fails with one --ip-address too. >>>>>>>> >>>>>>> >>>>>>> Sorry, fixed. >>>>>>> >>>>>>>> >>>>>>>> *) Not related with your patch >>>>>>>> Problem with installation: >>>>>>>> I'm getting message: >>>>>>>> IPA server is already configured on this system. >>>>>>>> Even if I validation wasn't successful and installation was >>>>>>>> aborted. >>>>>>>> >>>>>>>> IPA install detects previous installations by checking state file >>>>>>>> and >>>>>>>> restore files. Function get_server_ip_address() stores some data >>>>>>>> and >>>>>>>> hosts file and modify the host file, before user agreed >>>>>>>> installation. >>>>>>>> This error was there before your patch. >>>>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> NACK >>>>>> >>>>>> 0) >>>>>> # ipa-dns-install --ip-address 2001:db8::feed >>>>>> >>>>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>>>> 2014-09-24T06:02:13Z DEBUG File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> line 645, in run_script >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-dns-install", line 135, in main >>>>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>>>> options.unattended, options) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> line 473, in get_server_ip_address >>>>>> if options.setup_dns: >>>>>> >>>>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>>>> exception: AttributeError: Values instance has no attribute >>>>>> 'setup_dns' >>>>> >>>>> Obviously there is no option --setup-dns in ipa-dns-install. >>>>> Fixed, modified get_server_ip_address function. >>>>> >>>>>> >>>>>> 1) >>>>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>>>> Creating SSL certificate for the Directory Server >>>>>> Creating SSL certificate for the dogtag Directory Server >>>>>> Saving dogtag Directory Server port >>>>>> Creating SSL certificate for the Web Server >>>>>> Exporting RA certificate >>>>>> Copying additional files >>>>>> Finalizing configuration >>>>>> Packaging replica information into >>>>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>>>> Adding DNS records for vm-073.example.com >>>>>> Values instance has no attribute 'unattended' >>>>>> >>>>>> It should be unatended automatically, or we need add the --unattended >>>>>> option to ipa-replica-prepare >>>>> >>>>> ipa-replica-install is missing --unattended option. I fixed it in my >>>>> code for now but we should add it there. >>>>> >>>>>> >>>>>> 2) This is nto user friendly, could be IP address check before >>>>>> installation? >>>>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>>>> --no-forwarders >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> Run connection check to master >>>>>> ... >>>>>> >>>>>> ... >>>>>> Restarting the KDC >>>>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>>>> >>>>>> LOG: >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>> install_bind(config, options) >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>>>> reverse_zones = >>>>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>>>> options.reverse_zones, options, True) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> line 426, in check_reverse_zones >>>>>> sys.exit("There is no IP address matching reverse zone %s." % >>>>>> rz) >>>>>> >>>>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>>>> exception: SystemExit: There is no IP address matching reverse zone >>>>>> 10.in-addr.arpa.. >>>>> >>>>> Fixed. Asking everything before actual installation. >>>>> >>>>>> >>>>>> 3) >>>>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>>>> something about partially configured system >>>>> >>>>> This is quite common in installation scripts. I moved this parts >>>>> before >>>>> actual installation. >>>>> >>>>>> >>>>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>>>> .... >>>>>> Done configuring the web interface (httpd). >>>>>> Configuring ipa-otpd >>>>>> [1/2]: starting ipa-otpd >>>>>> [2/2]: configuring ipa-otpd to start on boot >>>>>> Done configuring ipa-otpd. >>>>>> Applying LDAP updates >>>>>> Restarting the directory server >>>>>> Restarting the KDC >>>>>> Do you want to configure the reverse zone? [yes]: >>>>> >>>>> Moved. >>>>> >>>>>> >>>>>> 5) And error >>>>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>>>> --setup-dns >>>>>> .... >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> Please specify the reverse zone name >>>>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>>>> >>>>>> Your system may be partly configured. >>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>> >>>>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>>>> AttributeError: 'str' object has no attribute 'version' >>>>>> >>>>>> LOG: >>>>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>>>> conn= >>>>>> 2014-09-24T06:50:45Z DEBUG File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> line 645, in run_script >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>> install_bind(config, options) >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>>>> ca_configured=options.setup_ca) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> line 550, in setup >>>>>> self.__setup_sub_dict() >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> line 651, in __setup_sub_dict >>>>>> if addr.version in (4, 6): >>>>>> >>>>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>>>> exception: AttributeError: 'str' object has no attribute 'version' >>>>> >>>>> Fixed. We are using IP addresses as a strings and as a >>>>> CheckedIPAddress. >>>>> I swapped them here. >>>>>> >>>>>> >>>>>> *) I don't like this asking to specify zone without IP >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> Please specify the reverse zone name >>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>>>> >>>>> >>>>> Would be nice. Prefer to do it as a part of more powerfull reverse >>>>> zone >>>>> validation logic. >>>>>> >>>>>> >>>>>> **) I'm not sure how often this case can happen: >>>>>> master and replica without DNS, you run --ipa-dns-install on master >>>>>> then >>>>>> on replica, then replica DNS installation will not try to find >>>>>> existent >>>>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>>>> Maybe you should detect if DNS container exists and then set flag >>>>>> "search_reverse_zones=True" >>>>>> >>>>>> ipa-dns-install: >>>>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>>>> options.reverse_zones, options) >>>>> >>>>> Same as above. >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Rebased to current master and ipa-4-1. Removed unintentional >>>> modification of ipa-adtrust-install. >>> >>> + for ip, ip_address in zip(config.ips, config.ip_addresses): >>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>> >>> Is it always 100% guaranteed that the values in config.ips and >>> config.ip_addresses are the same length and otherwise match each other >>> in a way that will not cause things to break? IMO it would be better to >>> store a single list of 2-tuples somewhere from the start instead of >>> zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, >>> 'yes')].) >>> >> >> The chances that this will break are really small but I cannot guarantee >> that it won't eventually. >> One list (config.ip_addresses) is generated from the other (config.ips) >> and right now there is no need to modify them. But if someone in the >> future modify only one of them it will fail really badly. So I removed >> zip() and convert the ip address to string on demand. It will cost a few >> more cycles but also will be less error prone. >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Another few flaws eradicated. > > > > _______________________________________________ > 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-16-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0009-16-ipa41-Detect-and-configure-all-usable-IP-addresses.patch Type: text/x-patch Size: 43238 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 26 15:13:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Sep 2014 11:13:17 -0400 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <542301C2.5060200@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> Message-ID: <5425828D.5020508@redhat.com> Jan Cholasta wrote: > Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix various bugs and shortcomings in the CA >>> management and renewal code. Related tickets: >>> , >>> . >>> >>> (Patch 319 was originally posted at >>> .) >>> >> >> Only two of the patches includes what ticket(s) they address. Most have >> the tersest of commit messages. If got more and more difficult to see >> why the changes were needed at all, as you'll see. > > Sorry, fixed (hopefully). > > Note that most of these patches fix stuff I didn't have time to fix > before I posted the original CA management patches, hence the missing > tickets. Well, the policy is that every commit should have a ticket. So I guess re-open the old tickets or open new ones. This will help someone in the future know the "why" of a patch. I've certainly been guilty Here is a new set of reviews as trying to intermingle was making my eyes cross: 319: I guess I still don't understand why you can't pull the certs out of LDAP when creating this database. When this code runs, we know that the client is configured, so we have access to authentication. Why can't create_ipa_nssdb pull the certs directly? It seems more robust to me, and the code is already written in ipa-client-install to do this. When adding the CA certificates to the temporary database it will report that a failure occurred, but not the exception: + except CalledProcessError, e: + root_logger.info("Failed to add CA to temporary NSS database.") + return CLIENT_INSTALL_ERROR Granted, NSS errors are often obtuse, but should it at least DEBUG log it? 324, 325, 326: ACK 327: So the idea is to just mirror the certs and us the new db to know what was added? What if someone has the same nickname, different cert in the two databases? Is that too much of a corner case? 328, 329, 330, 331: ACK As an aside, do you know why the global certs are seen by mod_nss? libnssckbi.so is symlinked into the directory (certutil -L -d /etc/httpd/alias -h all will show all the certs). 332-335 I think the naming and/or comments can be improved. For example, there are now 3 *retrieve_cert commands, all of which do slightly different things. All have external handlers (via the oddly named profile), but some are called internally as well. This is rather complex code: a command passes a call onto certmonger which then exuecutes the IPA CA helper... More documentation would definitely help a newcomer figure out how renewal, CA retrieval, etc. works. Not to be too pedantic but there is a lot of this in dogtag-ipa-ca-renew-agent-submit: if variable: OR if not variable: Where variable defaults to None. Shouldn't the test be: if variable is [not] None: 340: ACK Through some combination of ipa-certupdate and ipa-cacert-manage I seem to have hosed things up: ipa: DEBUG: certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 118, in run rc = self.renew() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 181, in renew return self.renew_self_signed(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 193, in renew_self_signed self.resubmit_request(ca, 'caCACert') File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 315, in resubmit_request "please check the request manually" % self.request_id) ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: ScriptError: Error resubmitting certmonger request '20140909142830', please check the request manually ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Error resubmitting certmonger request '20140909142830', please check the request manually Incidentally, IMHO it should include the command to execute to check the request manually. The CA is actually unreachable. Restarting it fixed things. I'll chalk this up to cosmic rays. Re-running ipa-cacert-manage renew was successful. I confirmed that the CA signing cert was updated in the dogtag database. I then ran ipa-certupdate to distribute this new CA cert around and none of the databases got the updated CA cert, nor did /etc/ipa/ca.crt. Still doing some functional testing. Unrelated to this: 9:freeipa-python-4.0.0GITf6875d4-0.################################# [100%] Update failed: Operations error: Seems to be related to this: 2014-09-25T19:28:22Z DEBUG --------------------------------------------- 2014-09-25T19:28:22Z DEBUG Final value after applying updates 2014-09-25T19:28:22Z DEBUG dn: cn=referential integrity postoperation,cn=plugins,cn=config 2014-09-25T19:28:22Z DEBUG cn: 2014-09-25T19:28:22Z DEBUG referential integrity postoperation 2014-09-25T19:28:22Z DEBUG objectClass: 2014-09-25T19:28:22Z DEBUG top 2014-09-25T19:28:22Z DEBUG nsSlapdPlugin 2014-09-25T19:28:22Z DEBUG extensibleObject 2014-09-25T19:28:22Z DEBUG nsslapd-pluginprecedence: 2014-09-25T19:28:22Z DEBUG 40 2014-09-25T19:28:22Z DEBUG nsslapd-pluginPath: 2014-09-25T19:28:22Z DEBUG libreferint-plugin 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVersion: 2014-09-25T19:28:22Z DEBUG 1.3.3.2 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg5: 2014-09-25T19:28:22Z DEBUG owner 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg4: 2014-09-25T19:28:22Z DEBUG uniquemember 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg7: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg6: 2014-09-25T19:28:22Z DEBUG seeAlso 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg1: 2014-09-25T19:28:22Z DEBUG /var/log/dirsrv/slapd-GREYOAK-COM/referint 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg0: 2014-09-25T19:28:22Z DEBUG 0 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg3: 2014-09-25T19:28:22Z DEBUG member 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg2: 2014-09-25T19:28:22Z DEBUG 0 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg9: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg8: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginInitfunc: 2014-09-25T19:28:22Z DEBUG referint_postop_init 2014-09-25T19:28:22Z DEBUG nsslapd-pluginexcludeentryscope: 2014-09-25T19:28:22Z DEBUG cn=provisioning,dc=greyoak,dc=com 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg11: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg10: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg13: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg12: 2014-09-25T19:28:22Z DEBUG nsslapd-plugin-depends-on-type: 2014-09-25T19:28:22Z DEBUG database 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVendor: 2014-09-25T19:28:22Z DEBUG 389 Project 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg17: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg16: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg18: 2014-09-25T19:28:22Z DEBUG nsslapd-pluginType: 2014-09-25T19:28:22Z DEBUG betxnpostoperation 2014-09-25T19:28:22Z DEBUG nsslapd-pluginDescription: 2014-09-25T19:28:22Z DEBUG referential integrity plugin 2014-09-25T19:28:22Z DEBUG nsslapd-pluginentryscope: 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com 2014-09-25T19:28:22Z DEBUG nsslapd-pluginEnabled: 2014-09-25T19:28:22Z DEBUG on 2014-09-25T19:28:22Z DEBUG nsslapd-pluginId: 2014-09-25T19:28:22Z DEBUG referint 2014-09-25T19:28:22Z DEBUG nsslapd-plugincontainerscope: 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg15: 2014-09-25T19:28:22Z DEBUG referint-membership-attr: 2014-09-25T19:28:22Z DEBUG manager 2014-09-25T19:28:22Z DEBUG secretary 2014-09-25T19:28:22Z DEBUG memberuser 2014-09-25T19:28:22Z DEBUG memberhost 2014-09-25T19:28:22Z DEBUG sourcehost 2014-09-25T19:28:22Z DEBUG memberservice 2014-09-25T19:28:22Z DEBUG managedby 2014-09-25T19:28:22Z DEBUG memberallowcmd 2014-09-25T19:28:22Z DEBUG memberdenycmd 2014-09-25T19:28:22Z DEBUG ipasudorunas 2014-09-25T19:28:22Z DEBUG ipasudorunasgroup 2014-09-25T19:28:22Z DEBUG ipatokenradiusconfiglink 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg14: 2014-09-25T19:28:22Z DEBUG [(1, u'nsslapd-pluginarg16', None), (1, u'nsslapd-pluginarg7', None), (1, u'nsslapd-pluginarg9', None), (1, u'nsslapd-pluginarg8', None), (1, u'nsslapd-pluginarg11', None), (1, u'nsslapd-pluginarg10', None), (1, u'nsslapd-pluginarg13', None), (1, u'nsslapd-pluginarg12', None), (1, u'nsslapd-pluginarg17', None), (1, u'nsslapd-pluginarg18', None), (1, u'nsslapd-pluginarg15', None), (2, u'referint-membership-attr', ['sourcehost', 'memberallowcmd', 'memberdenycmd', 'memberuser', 'managedby', 'manager', 'memberservice', 'ipasudorunas', 'ipasudorunasgroup', 'secretary', 'memberhost', 'ipatokenradiusconfiglink']), (1, u'nsslapd-pluginarg14', None)] 2014-09-25T19:28:22Z DEBUG Live 1, updated 1 2014-09-25T19:28:22Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2014-09-25T19:28:22Z ERROR Update failed: Operations error: From pviktori at redhat.com Fri Sep 26 15:15:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Sep 2014 17:15:00 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <5422EDA1.4060004@redhat.com> References: <5422EDA1.4060004@redhat.com> Message-ID: <542582F4.9080406@redhat.com> On 09/24/2014 06:13 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix > and . > > (Note that design page for this is TBD.) > > Honza > 336: Instead of len(data[:match.start() + 1].splitlines()) you can do data.count('\n', 0, match.start()) + 1 337: The --external_cert_file and --external_ca_file options for ipa-ca-install are removed, do we really want to do that? Shouldn't they be deprecated instead? Same for --external-ca-file in ipa-cacert-manage. 338: Looks OK 339: Looks OK Could you add some docstrings to the functions you add? Sometimes it's harder than necessary to decipher what they do and what the arguments/return values mean exactly. There is no user-visible documentation on what file types are expected/supported. It would be good to add this to the man pages, or the --help. In external CA, the error message when specifying a certificate but not the CA could be improved: $ ipa-server-install --external_cert_file ~/p/Certificate_Authority_8.cer ... CA certificate CN=Certificate Authority,O=IDM.LAB.ENG.BRQ.REDHAT.COM in /home/pviktori/p/Certificate_Authority_8.cer is not valid: (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized. For CA-less, I used a combination of files with which server installation went well, but replica-install failed halfway through: Console: ... [16/36]: creating indices [17/36]: enabling referential integrity plugin [18/36]: configuring ssl for ds instance [error] RuntimeError: incorrect password for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 Log tail: 2014-09-26T15:05:43Z DEBUG Starting external process 2014-09-26T15:05:43Z DEBUG args='/usr/bin/pk12util' '-d' '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/' '-i' '/tmp/tmp2vEWX_ipa/realm_info/dscert.p12' '-k' '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM//pwdfile.txt' '-v' '-w' '/dev/stdin' 2014-09-26T15:05:43Z DEBUG Process finished, return code=17 2014-09-26T15:05:43Z DEBUG stdout= 2014-09-26T15:05:43Z DEBUG stderr=pk12util: PKCS12 decode not verified: SEC_ERROR_BAD_PASSWORD: The security password entered is incorrect. 2014-09-26T15:05:43Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 370, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 360, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 600, in __enable_ssl trust_flags=trust_flags) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 1030, in create_from_pkcs12 self.import_pkcs12(pkcs12_fname, pkcs12_passwd) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 971, in import_pkcs12 pkcs12_passwd=pkcs12_passwd) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 191, in import_pkcs12 pkcs12_filename) RuntimeError: incorrect password for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 2014-09-26T15:05:43Z DEBUG [error] RuntimeError: incorrect password for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 2014-09-26T15:05:43Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 644, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 677, in main ds = install_replica_ds(config) File "/sbin/ipa-replica-install", line 190, in install_replica_ds ca_file=config.dir + "/ca.crt", File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 354, in create_replica self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 370, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 360, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 600, in __enable_ssl trust_flags=trust_flags) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 1030, in create_from_pkcs12 self.import_pkcs12(pkcs12_fname, pkcs12_passwd) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 971, in import_pkcs12 pkcs12_passwd=pkcs12_passwd) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 191, in import_pkcs12 pkcs12_filename) 2014-09-26T15:05:43Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: incorrect password for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 I'll attach the files for reference; the options for ipa-server-install and ipa-replica-prepare were: --http-cert-file=~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 --http-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-allcerts-x509.pem --http-pin 12345678 --dirsrv-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-cacerts-pkcs7.pem --dirsrv-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 --dirsrv-pin 12345678 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: STAR.idm.lab.eng.brq.redhat.com_3.p12-allcerts-x509.pem Type: application/x-x509-ca-cert Size: 1806 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: STAR.idm.lab.eng.brq.redhat.com_3.p12-cacerts-pkcs7.pem Type: application/x-x509-ca-cert Size: 827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 Type: application/x-pkcs12 Size: 1533 bytes Desc: not available URL: From pvoborni at redhat.com Fri Sep 26 15:25:51 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Sep 2014 17:25:51 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <54244BEF.40000@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> <54244BEF.40000@redhat.com> Message-ID: <5425857F.8020401@redhat.com> On 25.9.2014 19:07, Petr Vobornik wrote: > All issues will be done separately as already stated in other > sub-thread. I've removed issues which are discussed in the other > sub-thread. > >>> >>> 2. The tab titles in the ID view details page are quite long, and the >>> "User ID overrides" and "Group ID overrides" labels aren't quite >>> appropriate because the ID view can override other attributes too. How >>> about using facet groups like in User Groups? For example: >>> - applies to: >>> - Hosts >>> - overrides: >>> - Users >>> - Groups >>> - Settings > Attached patch 758 > > >> >>> 7. Related to #6, there probably should be a tab in the Host details >>> page showing which ID views apply to it. >> There is only a single view and yes, it would be good to add a property >> there, linking it to the ID view tab, if possible. > > Will add simple readonly field (link to view). It will be improved later > (based on ipa-4-1 priorities) Attached patch 760 > >> >>> 9. This probably requires server support. In the "Apply to hosts" >>> association dialog, if a host is already added it will still appear in >>> the dialog box. As a comparison, a User that has been added into a >>> User Group will not appear in the association dialog anymore. >> Could be trivially filtered out on Web UI side. > > Will be implemented. Attached patch 759 - quite ugly hack but does the job -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0760-webui-add-link-from-host-to-idview.patch Type: text/x-patch Size: 5175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0759-webui-list-only-not-applied-hosts-in-apply-to-host-d.patch Type: text/x-patch Size: 2417 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0758-webui-facet-group-labels-for-idview-s-facets.patch Type: text/x-patch Size: 3911 bytes Desc: not available URL: From fra.marella at gmx.com Fri Sep 26 15:26:42 2014 From: fra.marella at gmx.com (Francesco Marella) Date: Fri, 26 Sep 2014 17:26:42 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <54257893.9010607@gmx.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> <54257893.9010607@gmx.com> Message-ID: <542585B2.8020600@gmx.com> This should be the final one. fm On 26/09/2014 16:30, Francesco Marella wrote: > > On 26/09/2014 15:41, Petr Viktorin wrote: >> >> Hello! Thanks for the patch! >> >> The new function is not one of the platform-independent tasks, and >> doesn't even use `self`, so you can define it as a module-level >> helper function. >> >> But more importantly, this won't work: the blocks you are replacing >> return from their functions. You'd need to use something like: >> if not selinux_enabled(): >> return >> instead of: >> self.check_enabled_selinux() >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fmarella-0001-3-0001-Refactor-selinuxenabled-check.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 26 15:37:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Sep 2014 11:37:34 -0400 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <542582F4.9080406@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> Message-ID: <5425883E.6020000@redhat.com> Petr Viktorin wrote: > On 09/24/2014 06:13 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix >> and . >> >> (Note that design page for this is TBD.) Isn't this backwards then? > > 336: > > Instead of > len(data[:match.start() + 1].splitlines()) > you can do > data.count('\n', 0, match.start()) + 1 > > 337: > The --external_cert_file and --external_ca_file options for > ipa-ca-install are removed, do we really want to do that? Shouldn't they > be deprecated instead? +1 > > Same for --external-ca-file in ipa-cacert-manage. +1 I can't say I'm a fan of forcing users to concatenate cert files. > > 338: Looks OK > 339: Looks OK > > Could you add some docstrings to the functions you add? Sometimes it's > harder than necessary to decipher what they do and what the > arguments/return values mean exactly. > > There is no user-visible documentation on what file types are > expected/supported. It would be good to add this to the man pages, or > the --help. I also wonder if the detection code should be changed. It basically now tries a slew of different mechanisms one at a time rather than trying to identify the type of file and using that one. It may not be possible in all cases but you could at least start by looking for ^----- to know it is a text file and go from there, otherwise step through the binary formats. > > > > In external CA, the error message when specifying a certificate but not > the CA could be improved: > $ ipa-server-install --external_cert_file ~/p/Certificate_Authority_8.cer > ... > CA certificate CN=Certificate Authority,O=IDM.LAB.ENG.BRQ.REDHAT.COM in > /home/pviktori/p/Certificate_Authority_8.cer is not valid: > (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized. > > > > For CA-less, I used a combination of files with which server > installation went well, but replica-install failed halfway through: > > Console: > ... > [16/36]: creating indices > [17/36]: enabling referential integrity plugin > [18/36]: configuring ssl for ds instance > [error] RuntimeError: incorrect password for pkcs#12 file > /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 > > Log tail: > > 2014-09-26T15:05:43Z DEBUG Starting external process > 2014-09-26T15:05:43Z DEBUG args='/usr/bin/pk12util' '-d' > '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/' '-i' > '/tmp/tmp2vEWX_ipa/realm_info/dscert.p12' '-k' > '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM//pwdfile.txt' '-v' '-w' > '/dev/stdin' > 2014-09-26T15:05:43Z DEBUG Process finished, return code=17 > 2014-09-26T15:05:43Z DEBUG stdout= > 2014-09-26T15:05:43Z DEBUG stderr=pk12util: PKCS12 decode not verified: > SEC_ERROR_BAD_PASSWORD: The security password entered is incorrect. > > 2014-09-26T15:05:43Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 370, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 360, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 600, in __enable_ssl > trust_flags=trust_flags) > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 1030, in create_from_pkcs12 > self.import_pkcs12(pkcs12_fname, pkcs12_passwd) > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 971, in import_pkcs12 > pkcs12_passwd=pkcs12_passwd) > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 191, in import_pkcs12 > pkcs12_filename) > RuntimeError: incorrect password for pkcs#12 file > /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 > > 2014-09-26T15:05:43Z DEBUG [error] RuntimeError: incorrect password > for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 > 2014-09-26T15:05:43Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 644, in run_script > return_value = main_function() > > File "/sbin/ipa-replica-install", line 677, in main > ds = install_replica_ds(config) > > File "/sbin/ipa-replica-install", line 190, in install_replica_ds > ca_file=config.dir + "/ca.crt", > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 354, in create_replica > self.start_creation(runtime=60) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 370, in start_creation > run_step(full_msg, method) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 360, in run_step > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 600, in __enable_ssl > trust_flags=trust_flags) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 1030, in create_from_pkcs12 > self.import_pkcs12(pkcs12_fname, pkcs12_passwd) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 971, in import_pkcs12 > pkcs12_passwd=pkcs12_passwd) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 191, in import_pkcs12 > pkcs12_filename) > > 2014-09-26T15:05:43Z DEBUG The ipa-replica-install command failed, > exception: RuntimeError: incorrect password for pkcs#12 file > /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 > > > I'll attach the files for reference; the options for ipa-server-install > and ipa-replica-prepare were: > > --http-cert-file=~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 > --http-cert-file > ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-allcerts-x509.pem --http-pin > 12345678 --dirsrv-cert-file > ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-cacerts-pkcs7.pem > --dirsrv-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 > --dirsrv-pin 12345678 > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From tbordaz at redhat.com Fri Sep 26 15:43:51 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 26 Sep 2014 17:43:51 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <542585B2.8020600@gmx.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> <54257893.9010607@gmx.com> <542585B2.8020600@gmx.com> Message-ID: <542589B7.9060104@redhat.com> Hello, When called from set_selinux_booleans, if not selinux_enabled, you may want to 'return False' rather than 'return'. Now it looks like callers of set_selinux_booleans do not check the returned value :-) thanks thierry On 09/26/2014 05:26 PM, Francesco Marella wrote: > This should be the final one. > > fm > > On 26/09/2014 16:30, Francesco Marella wrote: >> >> On 26/09/2014 15:41, Petr Viktorin wrote: >>> >>> Hello! Thanks for the patch! >>> >>> The new function is not one of the platform-independent tasks, and >>> doesn't even use `self`, so you can define it as a module-level >>> helper function. >>> >>> But more importantly, this won't work: the blocks you are replacing >>> return from their functions. You'd need to use something like: >>> if not selinux_enabled(): >>> return >>> instead of: >>> self.check_enabled_selinux() >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 26 15:50:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 26 Sep 2014 17:50:30 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <5425606E.5090703@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> <54252409.7080002@redhat.com> <5425606E.5090703@redhat.com> Message-ID: <54258B46.9030906@redhat.com> On 26/09/14 14:47, David Kupka wrote: > On 09/26/2014 10:30 AM, David Kupka wrote: >> On 09/26/2014 09:34 AM, Jan Cholasta wrote: >>> Dne 26.9.2014 v 08:28 David Kupka napsal(a): >>>> On 09/25/2014 04:17 PM, David Kupka wrote: >>>>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>>>> On 24/09/14 15:44, David Kupka wrote: >>>>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>>>> ... >>>>>>>>>> 1) >>>>>>>>>> + if options.unattended: >>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>> + if search_reverse_zones and >>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>> + continue >>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>> + break >>>>>>>>>> + else: >>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>> + if search_reverse_zones and >>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>> + continue >>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>> + break >>>>>>>>>> + else: >>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>> + else: >>>>>>>>>> + options.no_reverse = True >>>>>>>>>> + ret_reverse_zones = [] >>>>>>>>>> >>>>>>>>>> You can make it shorter without duplications: >>>>>>>>>> >>>>>>>>>> # this ifs can be in one line >>>>>>>>>> if not options.unatended: >>>>>>>>>> if not options.reverse_zones >>>>>>>>>> if not create_reverse(): >>>>>>>>>> options.no_reverse=True >>>>>>>>>> return [] >>>>>>>>>> >>>>>>>>>> for ip in ip_addresses: >>>>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>>>> # reverse zone is already in LDAP >>>>>>>>>> continue >>>>>>>>>> for rz in ret_reverse_zones: >>>>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>>>> # reverse zone was entered by user >>>>>>>>>> break >>>>>>>>>> else: >>>>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>>>> if not options.unattended: >>>>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>> ret_reverse_zones.append(rz) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, I modified it bit different way to alse address >>>>>>>>> recommendation >>>>>>>>> 3). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>>>> ---------------------------------------------^^ >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> Would be nice to ask user to create new zones only if new zones >>>>>>>>>> are >>>>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>>>> anyway) >>>>>>>>>> >>>>>>>>> >>>>>>>>> I added one more variable and ask only once. >>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>>>> function >>>>>>>>>> above >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> NACK, most important point is 7 >>>>>>>> >>>>>>>> 1) >>>>>>>> I'm not sure if this is bug, but interactively is allowed to add >>>>>>>> only >>>>>>>> one ip address >>>>>>>> >>>>>>>> Unable to resolve IP address for host name >>>>>>>> Please provide the IP address to be used for this host name: >>>>>>>> 2001:db8::2 >>>>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>>>> >>>>>>> >>>>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>>>> multiple addresses the same way as for DNS forwarders. Also I >>>>>>> really >>>>>>> simplified IP address checking code when I was in it. I tested >>>>>>> it but >>>>>>> please look at it carefully. >>>>>>> Also I found that ipa-dns-install and ipa-adtrust-install also >>>>>>> accept >>>>>>> --ip-address param. So I modified ipa-dns-install in the same >>>>>>> way as >>>>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>>>> use specified value at all. I will remove the processing code and >>>>>>> mark >>>>>>> the param as deprecated in separate patch. >>>>>>> >>>>>>>> 2) >>>>>>>> I'm getting error message >>>>>>>> >>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>> 2001:db8::dead:beef >>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> >>>>>>>> - or - >>>>>>>> >>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>> Please specify the reverse zone name >>>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. >>>>>>>> for IP >>>>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> Please specify the reverse zone name >>>>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>> >>>>>>>> This shouldn't be there >>>>>>> >>>>>>> Moved the message to function used when installation is attended by >>>>>>> user. >>>>>>> >>>>>>>> >>>>>>>> Could be better to ask user to specific zone for ip address >>>>>>>> a.b.c.d. >>>>>>> >>>>>>> Probably, but lets leave some work for future. >>>>>>> >>>>>>>> >>>>>>>> 4) just nitpick >>>>>>>> The IPA Master Server will be configured with: >>>>>>>> ... >>>>>>>> IP address(es): 2001:db8::dead:beef, >>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>> ... >>>>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>> >>>>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>>>> zone(s)" >>>>>>>> >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> 5) >>>>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>>>> --setup-dns >>>>>>>> >>>>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>>>> sure >>>>>>>> if this is wrong, but we prevents user to add zone without >>>>>>>> address in >>>>>>>> it, so we should prevents, to add empty zone. >>>>>>>> >>>>>>> >>>>>>> It would be nice but not in this patch. >>>>>>> >>>>>>>> 6) >>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>>>> vm-105.example.com >>>>>>>> Directory Manager (existing master) password: >>>>>>>> >>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>>>> >>>>>>>> IMO This should work, right? >>>>>>>> >>>>>>>> + sys.exit("There is no IP address matching reverse >>>>>>>> zone >>>>>>>> %s." % rz) >>>>>>>> I expected at least this error to be shown. >>>>>>> >>>>>>> Fixed, thanks. >>>>>>> >>>>>>>> >>>>>>>> 7) >>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>>>> Directory Manager (existing master) password: >>>>>>>> >>>>>>>> ....... >>>>>>>> Adding DNS records for vm-105.example.com >>>>>>>> Values instance has no attribute 'ip_address' >>>>>>>> >>>>>>>> Command returns the attribute error. >>>>>>>> It fails with one --ip-address too. >>>>>>>> >>>>>>> >>>>>>> Sorry, fixed. >>>>>>> >>>>>>>> >>>>>>>> *) Not related with your patch >>>>>>>> Problem with installation: >>>>>>>> I'm getting message: >>>>>>>> IPA server is already configured on this system. >>>>>>>> Even if I validation wasn't successful and installation was >>>>>>>> aborted. >>>>>>>> >>>>>>>> IPA install detects previous installations by checking state file >>>>>>>> and >>>>>>>> restore files. Function get_server_ip_address() stores some >>>>>>>> data and >>>>>>>> hosts file and modify the host file, before user agreed >>>>>>>> installation. >>>>>>>> This error was there before your patch. >>>>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> NACK >>>>>> >>>>>> 0) >>>>>> # ipa-dns-install --ip-address 2001:db8::feed >>>>>> >>>>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>>>> 2014-09-24T06:02:13Z DEBUG File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> >>>>>> line 645, in run_script >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-dns-install", line 135, in main >>>>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>>>> options.unattended, options) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> >>>>>> line 473, in get_server_ip_address >>>>>> if options.setup_dns: >>>>>> >>>>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>>>> exception: AttributeError: Values instance has no attribute >>>>>> 'setup_dns' >>>>> >>>>> Obviously there is no option --setup-dns in ipa-dns-install. >>>>> Fixed, modified get_server_ip_address function. >>>>> >>>>>> >>>>>> 1) >>>>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>>>> Creating SSL certificate for the Directory Server >>>>>> Creating SSL certificate for the dogtag Directory Server >>>>>> Saving dogtag Directory Server port >>>>>> Creating SSL certificate for the Web Server >>>>>> Exporting RA certificate >>>>>> Copying additional files >>>>>> Finalizing configuration >>>>>> Packaging replica information into >>>>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>>>> Adding DNS records for vm-073.example.com >>>>>> Values instance has no attribute 'unattended' >>>>>> >>>>>> It should be unatended automatically, or we need add the >>>>>> --unattended >>>>>> option to ipa-replica-prepare >>>>> >>>>> ipa-replica-install is missing --unattended option. I fixed it in my >>>>> code for now but we should add it there. >>>>> >>>>>> >>>>>> 2) This is nto user friendly, could be IP address check before >>>>>> installation? >>>>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>>>> --no-forwarders >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> Run connection check to master >>>>>> ... >>>>>> >>>>>> ... >>>>>> Restarting the KDC >>>>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>>>> >>>>>> LOG: >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>> install_bind(config, options) >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>>>> reverse_zones = >>>>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>>>> options.reverse_zones, options, True) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> >>>>>> line 426, in check_reverse_zones >>>>>> sys.exit("There is no IP address matching reverse zone %s." >>>>>> % rz) >>>>>> >>>>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>>>> exception: SystemExit: There is no IP address matching reverse zone >>>>>> 10.in-addr.arpa.. >>>>> >>>>> Fixed. Asking everything before actual installation. >>>>> >>>>>> >>>>>> 3) >>>>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>>>> something about partially configured system >>>>> >>>>> This is quite common in installation scripts. I moved this parts >>>>> before >>>>> actual installation. >>>>> >>>>>> >>>>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>>>> .... >>>>>> Done configuring the web interface (httpd). >>>>>> Configuring ipa-otpd >>>>>> [1/2]: starting ipa-otpd >>>>>> [2/2]: configuring ipa-otpd to start on boot >>>>>> Done configuring ipa-otpd. >>>>>> Applying LDAP updates >>>>>> Restarting the directory server >>>>>> Restarting the KDC >>>>>> Do you want to configure the reverse zone? [yes]: >>>>> >>>>> Moved. >>>>> >>>>>> >>>>>> 5) And error >>>>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>>>> --setup-dns >>>>>> .... >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> Please specify the reverse zone name >>>>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>>>> >>>>>> Your system may be partly configured. >>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>> >>>>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>>>> AttributeError: 'str' object has no attribute 'version' >>>>>> >>>>>> LOG: >>>>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>>>> conn= >>>>>> 2014-09-24T06:50:45Z DEBUG File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>> >>>>>> line 645, in run_script >>>>>> return_value = main_function() >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>> install_bind(config, options) >>>>>> >>>>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>>>> ca_configured=options.setup_ca) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> >>>>>> line 550, in setup >>>>>> self.__setup_sub_dict() >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>> >>>>>> line 651, in __setup_sub_dict >>>>>> if addr.version in (4, 6): >>>>>> >>>>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>>>> exception: AttributeError: 'str' object has no attribute 'version' >>>>> >>>>> Fixed. We are using IP addresses as a strings and as a >>>>> CheckedIPAddress. >>>>> I swapped them here. >>>>>> >>>>>> >>>>>> *) I don't like this asking to specify zone without IP >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> Please specify the reverse zone name >>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>>>> >>>>> >>>>> Would be nice. Prefer to do it as a part of more powerfull reverse >>>>> zone >>>>> validation logic. >>>>>> >>>>>> >>>>>> **) I'm not sure how often this case can happen: >>>>>> master and replica without DNS, you run --ipa-dns-install on master >>>>>> then >>>>>> on replica, then replica DNS installation will not try to find >>>>>> existent >>>>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>>>> Maybe you should detect if DNS container exists and then set flag >>>>>> "search_reverse_zones=True" >>>>>> >>>>>> ipa-dns-install: >>>>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>>>> options.reverse_zones, options) >>>>> >>>>> Same as above. >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Rebased to current master and ipa-4-1. Removed unintentional >>>> modification of ipa-adtrust-install. >>> >>> + for ip, ip_address in zip(config.ips, >>> config.ip_addresses): >>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>> >>> Is it always 100% guaranteed that the values in config.ips and >>> config.ip_addresses are the same length and otherwise match each other >>> in a way that will not cause things to break? IMO it would be better to >>> store a single list of 2-tuples somewhere from the start instead of >>> zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, >>> 'yes')].) >>> >> >> The chances that this will break are really small but I cannot guarantee >> that it won't eventually. >> One list (config.ip_addresses) is generated from the other (config.ips) >> and right now there is no need to modify them. But if someone in the >> future modify only one of them it will fail really badly. So I removed >> zip() and convert the ip address to string on demand. It will cost a few >> more cycles but also will be less error prone. >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Another few flaws eradicated. > ACK There is one issue with info message in ipa-replica-install, where wrong zone is shown instead of zone where value will be added. (Values in DNS are correct). This doesn't work on IPA 4.0 too. (by source code, not tested) -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From fra.marella at gmx.com Fri Sep 26 15:53:20 2014 From: fra.marella at gmx.com (Francesco Marella) Date: Fri, 26 Sep 2014 17:53:20 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <542589B7.9060104@redhat.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> <54257893.9010607@gmx.com> <542585B2.8020600@gmx.com> <542589B7.9060104@redhat.com> Message-ID: <54258BF0.4020208@gmx.com> On 26/09/2014 17:43, thierry bordaz wrote: > Hello, > > When called from set_selinux_booleans, if not selinux_enabled, you > may want to 'return False' rather than 'return'. > Now it looks like callers of set_selinux_booleans do not check the > returned value :-) > > thanks > thierry > > On 09/26/2014 05:26 PM, Francesco Marella wrote: >> This should be the final one. >> >> fm >> >> On 26/09/2014 16:30, Francesco Marella wrote: >>> >>> On 26/09/2014 15:41, Petr Viktorin wrote: >>>> >>>> Hello! Thanks for the patch! >>>> >>>> The new function is not one of the platform-independent tasks, and >>>> doesn't even use `self`, so you can define it as a module-level >>>> helper function. >>>> >>>> But more importantly, this won't work: the blocks you are replacing >>>> return from their functions. You'd need to use something like: >>>> if not selinux_enabled(): >>>> return >>>> instead of: >>>> self.check_enabled_selinux() >>>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fmarella-0001-4-0001-Refactor-selinuxenabled-check.patch Type: text/x-patch Size: 2909 bytes Desc: not available URL: From dkupka at redhat.com Fri Sep 26 15:55:56 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Sep 2014 17:55:56 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54258B46.9030906@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> <54252409.7080002@redhat.com> <5425606E.5090703@redhat.com> <54258B46.9030906@redhat.com> Message-ID: <54258C8C.4040903@redhat.com> On 09/26/2014 05:50 PM, Martin Basti wrote: > On 26/09/14 14:47, David Kupka wrote: >> On 09/26/2014 10:30 AM, David Kupka wrote: >>> On 09/26/2014 09:34 AM, Jan Cholasta wrote: >>>> Dne 26.9.2014 v 08:28 David Kupka napsal(a): >>>>> On 09/25/2014 04:17 PM, David Kupka wrote: >>>>>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>>>>> On 24/09/14 15:44, David Kupka wrote: >>>>>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>>>>> ... >>>>>>>>>>> 1) >>>>>>>>>>> + if options.unattended: >>>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>>> + if search_reverse_zones and >>>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>>> + continue >>>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>>> + break >>>>>>>>>>> + else: >>>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>>> + if search_reverse_zones and >>>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>>> + continue >>>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>>> + break >>>>>>>>>>> + else: >>>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>>> + else: >>>>>>>>>>> + options.no_reverse = True >>>>>>>>>>> + ret_reverse_zones = [] >>>>>>>>>>> >>>>>>>>>>> You can make it shorter without duplications: >>>>>>>>>>> >>>>>>>>>>> # this ifs can be in one line >>>>>>>>>>> if not options.unatended: >>>>>>>>>>> if not options.reverse_zones >>>>>>>>>>> if not create_reverse(): >>>>>>>>>>> options.no_reverse=True >>>>>>>>>>> return [] >>>>>>>>>>> >>>>>>>>>>> for ip in ip_addresses: >>>>>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>>>>> # reverse zone is already in LDAP >>>>>>>>>>> continue >>>>>>>>>>> for rz in ret_reverse_zones: >>>>>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>>>>> # reverse zone was entered by user >>>>>>>>>>> break >>>>>>>>>>> else: >>>>>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> if not options.unattended: >>>>>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>>> ret_reverse_zones.append(rz) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, I modified it bit different way to alse address >>>>>>>>>> recommendation >>>>>>>>>> 3). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>>>>> ---------------------------------------------^^ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> Would be nice to ask user to create new zones only if new zones >>>>>>>>>>> are >>>>>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>>>>> anyway) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I added one more variable and ask only once. >>>>>>>>>> >>>>>>>>>>> 4) >>>>>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>>>>> function >>>>>>>>>>> above >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> NACK, most important point is 7 >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> I'm not sure if this is bug, but interactively is allowed to add >>>>>>>>> only >>>>>>>>> one ip address >>>>>>>>> >>>>>>>>> Unable to resolve IP address for host name >>>>>>>>> Please provide the IP address to be used for this host name: >>>>>>>>> 2001:db8::2 >>>>>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>>>>> >>>>>>>> >>>>>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>>>>> multiple addresses the same way as for DNS forwarders. Also I >>>>>>>> really >>>>>>>> simplified IP address checking code when I was in it. I tested >>>>>>>> it but >>>>>>>> please look at it carefully. >>>>>>>> Also I found that ipa-dns-install and ipa-adtrust-install also >>>>>>>> accept >>>>>>>> --ip-address param. So I modified ipa-dns-install in the same >>>>>>>> way as >>>>>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>>>>> use specified value at all. I will remove the processing code and >>>>>>>> mark >>>>>>>> the param as deprecated in separate patch. >>>>>>>> >>>>>>>>> 2) >>>>>>>>> I'm getting error message >>>>>>>>> >>>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>>> 2001:db8::dead:beef >>>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> >>>>>>>>> - or - >>>>>>>>> >>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>> Please specify the reverse zone name >>>>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. >>>>>>>>> for IP >>>>>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> Please specify the reverse zone name >>>>>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>>> >>>>>>>>> This shouldn't be there >>>>>>>> >>>>>>>> Moved the message to function used when installation is attended by >>>>>>>> user. >>>>>>>> >>>>>>>>> >>>>>>>>> Could be better to ask user to specific zone for ip address >>>>>>>>> a.b.c.d. >>>>>>>> >>>>>>>> Probably, but lets leave some work for future. >>>>>>>> >>>>>>>>> >>>>>>>>> 4) just nitpick >>>>>>>>> The IPA Master Server will be configured with: >>>>>>>>> ... >>>>>>>>> IP address(es): 2001:db8::dead:beef, >>>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> ... >>>>>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>>> >>>>>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>>>>> zone(s)" >>>>>>>>> >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> 5) >>>>>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>>>>> --setup-dns >>>>>>>>> >>>>>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>>>>> sure >>>>>>>>> if this is wrong, but we prevents user to add zone without >>>>>>>>> address in >>>>>>>>> it, so we should prevents, to add empty zone. >>>>>>>>> >>>>>>>> >>>>>>>> It would be nice but not in this patch. >>>>>>>> >>>>>>>>> 6) >>>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>>>>> vm-105.example.com >>>>>>>>> Directory Manager (existing master) password: >>>>>>>>> >>>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>>>>> >>>>>>>>> IMO This should work, right? >>>>>>>>> >>>>>>>>> + sys.exit("There is no IP address matching reverse >>>>>>>>> zone >>>>>>>>> %s." % rz) >>>>>>>>> I expected at least this error to be shown. >>>>>>>> >>>>>>>> Fixed, thanks. >>>>>>>> >>>>>>>>> >>>>>>>>> 7) >>>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>>>>> Directory Manager (existing master) password: >>>>>>>>> >>>>>>>>> ....... >>>>>>>>> Adding DNS records for vm-105.example.com >>>>>>>>> Values instance has no attribute 'ip_address' >>>>>>>>> >>>>>>>>> Command returns the attribute error. >>>>>>>>> It fails with one --ip-address too. >>>>>>>>> >>>>>>>> >>>>>>>> Sorry, fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> *) Not related with your patch >>>>>>>>> Problem with installation: >>>>>>>>> I'm getting message: >>>>>>>>> IPA server is already configured on this system. >>>>>>>>> Even if I validation wasn't successful and installation was >>>>>>>>> aborted. >>>>>>>>> >>>>>>>>> IPA install detects previous installations by checking state file >>>>>>>>> and >>>>>>>>> restore files. Function get_server_ip_address() stores some >>>>>>>>> data and >>>>>>>>> hosts file and modify the host file, before user agreed >>>>>>>>> installation. >>>>>>>>> This error was there before your patch. >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> NACK >>>>>>> >>>>>>> 0) >>>>>>> # ipa-dns-install --ip-address 2001:db8::feed >>>>>>> >>>>>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>>>>> 2014-09-24T06:02:13Z DEBUG File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> >>>>>>> line 645, in run_script >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-dns-install", line 135, in main >>>>>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>>>>> options.unattended, options) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> >>>>>>> line 473, in get_server_ip_address >>>>>>> if options.setup_dns: >>>>>>> >>>>>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>>>>> exception: AttributeError: Values instance has no attribute >>>>>>> 'setup_dns' >>>>>> >>>>>> Obviously there is no option --setup-dns in ipa-dns-install. >>>>>> Fixed, modified get_server_ip_address function. >>>>>> >>>>>>> >>>>>>> 1) >>>>>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>>>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>>>>> Creating SSL certificate for the Directory Server >>>>>>> Creating SSL certificate for the dogtag Directory Server >>>>>>> Saving dogtag Directory Server port >>>>>>> Creating SSL certificate for the Web Server >>>>>>> Exporting RA certificate >>>>>>> Copying additional files >>>>>>> Finalizing configuration >>>>>>> Packaging replica information into >>>>>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>>>>> Adding DNS records for vm-073.example.com >>>>>>> Values instance has no attribute 'unattended' >>>>>>> >>>>>>> It should be unatended automatically, or we need add the >>>>>>> --unattended >>>>>>> option to ipa-replica-prepare >>>>>> >>>>>> ipa-replica-install is missing --unattended option. I fixed it in my >>>>>> code for now but we should add it there. >>>>>> >>>>>>> >>>>>>> 2) This is nto user friendly, could be IP address check before >>>>>>> installation? >>>>>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>>>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>>>>> --no-forwarders >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> Run connection check to master >>>>>>> ... >>>>>>> >>>>>>> ... >>>>>>> Restarting the KDC >>>>>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>>>>> >>>>>>> LOG: >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>>> install_bind(config, options) >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>>>>> reverse_zones = >>>>>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>>>>> options.reverse_zones, options, True) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> >>>>>>> line 426, in check_reverse_zones >>>>>>> sys.exit("There is no IP address matching reverse zone %s." >>>>>>> % rz) >>>>>>> >>>>>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>>>>> exception: SystemExit: There is no IP address matching reverse zone >>>>>>> 10.in-addr.arpa.. >>>>>> >>>>>> Fixed. Asking everything before actual installation. >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>>>>> something about partially configured system >>>>>> >>>>>> This is quite common in installation scripts. I moved this parts >>>>>> before >>>>>> actual installation. >>>>>> >>>>>>> >>>>>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>>>>> .... >>>>>>> Done configuring the web interface (httpd). >>>>>>> Configuring ipa-otpd >>>>>>> [1/2]: starting ipa-otpd >>>>>>> [2/2]: configuring ipa-otpd to start on boot >>>>>>> Done configuring ipa-otpd. >>>>>>> Applying LDAP updates >>>>>>> Restarting the directory server >>>>>>> Restarting the KDC >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> >>>>>> Moved. >>>>>> >>>>>>> >>>>>>> 5) And error >>>>>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>>>>> --setup-dns >>>>>>> .... >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> Please specify the reverse zone name >>>>>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>>>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>>>>> >>>>>>> Your system may be partly configured. >>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>>> >>>>>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>>>>> AttributeError: 'str' object has no attribute 'version' >>>>>>> >>>>>>> LOG: >>>>>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>>>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>>>>> conn= >>>>>>> 2014-09-24T06:50:45Z DEBUG File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> >>>>>>> line 645, in run_script >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>>> install_bind(config, options) >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>>>>> ca_configured=options.setup_ca) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> >>>>>>> line 550, in setup >>>>>>> self.__setup_sub_dict() >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> >>>>>>> line 651, in __setup_sub_dict >>>>>>> if addr.version in (4, 6): >>>>>>> >>>>>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>>>>> exception: AttributeError: 'str' object has no attribute 'version' >>>>>> >>>>>> Fixed. We are using IP addresses as a strings and as a >>>>>> CheckedIPAddress. >>>>>> I swapped them here. >>>>>>> >>>>>>> >>>>>>> *) I don't like this asking to specify zone without IP >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> Please specify the reverse zone name >>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>>>>> >>>>>> >>>>>> Would be nice. Prefer to do it as a part of more powerfull reverse >>>>>> zone >>>>>> validation logic. >>>>>>> >>>>>>> >>>>>>> **) I'm not sure how often this case can happen: >>>>>>> master and replica without DNS, you run --ipa-dns-install on master >>>>>>> then >>>>>>> on replica, then replica DNS installation will not try to find >>>>>>> existent >>>>>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>>>>> Maybe you should detect if DNS container exists and then set flag >>>>>>> "search_reverse_zones=True" >>>>>>> >>>>>>> ipa-dns-install: >>>>>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>>>>> options.reverse_zones, options) >>>>>> >>>>>> Same as above. >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Rebased to current master and ipa-4-1. Removed unintentional >>>>> modification of ipa-adtrust-install. >>>> >>>> + for ip, ip_address in zip(config.ips, >>>> config.ip_addresses): >>>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>>> >>>> Is it always 100% guaranteed that the values in config.ips and >>>> config.ip_addresses are the same length and otherwise match each other >>>> in a way that will not cause things to break? IMO it would be better to >>>> store a single list of 2-tuples somewhere from the start instead of >>>> zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, >>>> 'yes')].) >>>> >>> >>> The chances that this will break are really small but I cannot guarantee >>> that it won't eventually. >>> One list (config.ip_addresses) is generated from the other (config.ips) >>> and right now there is no need to modify them. But if someone in the >>> future modify only one of them it will fail really badly. So I removed >>> zip() and convert the ip address to string on demand. It will cost a few >>> more cycles but also will be less error prone. >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Another few flaws eradicated. >> > ACK > > There is one issue with info message in ipa-replica-install, where wrong > zone is shown instead of zone where value will be added. (Values in DNS > are correct). This doesn't work on IPA 4.0 too. (by source code, not tested) > > -- > Martin Basti > Thanks to all gods on all heavens. This installers was crafted using powerful voodoo years ago. I was possessed by a couple of spirits of scarified chickens during work on this patch. Ticket for the issue with confusing message: https://fedorahosted.org/freeipa/ticket/4582 -- David Kupka From mkosek at redhat.com Fri Sep 26 15:57:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 17:57:35 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses. In-Reply-To: <54258B46.9030906@redhat.com> References: <53FB5082.9020703@redhat.com> <53FDCE0B.4070105@redhat.com> <54057FD2.1010001@redhat.com> <5405DA76.1020502@redhat.com> <540DD195.3070804@redhat.com> <5412C56C.7060404@redhat.com> <54132C35.6080004@redhat.com> <5418425A.4040509@redhat.com> <541860CF.20109@redhat.com> <54191B3D.6090205@redhat.com> <541AD906.4000006@redhat.com> <541B099C.9060606@redhat.com> <5421583A.8040303@redhat.com> <5421BB0B.9050500@redhat.com> <5422CACF.7020406@redhat.com> <54231354.7050102@redhat.com> <542423E9.4020203@redhat.com> <54250790.1090105@redhat.com> <54251704.4080802@redhat.com> <54252409.7080002@redhat.com> <5425606E.5090703@redhat.com> <54258B46.9030906@redhat.com> Message-ID: <54258CEF.1020206@redhat.com> On 09/26/2014 05:50 PM, Martin Basti wrote: > On 26/09/14 14:47, David Kupka wrote: >> On 09/26/2014 10:30 AM, David Kupka wrote: >>> On 09/26/2014 09:34 AM, Jan Cholasta wrote: >>>> Dne 26.9.2014 v 08:28 David Kupka napsal(a): >>>>> On 09/25/2014 04:17 PM, David Kupka wrote: >>>>>> On 09/24/2014 08:54 PM, Martin Basti wrote: >>>>>>> On 24/09/14 15:44, David Kupka wrote: >>>>>>>> On 09/23/2014 08:25 PM, Martin Basti wrote: >>>>>>>>> On 23/09/14 13:23, David Kupka wrote: >>>>>>>>>> On 09/18/2014 06:34 PM, Martin Basti wrote: >>>>>>>>>>> ... >>>>>>>>>>> 1) >>>>>>>>>>> + if options.unattended: >>>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>>> + if search_reverse_zones and >>>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>>> + continue >>>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>>> + break >>>>>>>>>>> + else: >>>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>>> + elif options.reverse_zones or create_reverse(): >>>>>>>>>>> + for ip in ip_addresses: >>>>>>>>>>> + if search_reverse_zones and >>>>>>>>>>> find_reverse_zone(str(ip)): >>>>>>>>>>> + # reverse zone is already in LDAP >>>>>>>>>>> + continue >>>>>>>>>>> + for rz in ret_reverse_zones: >>>>>>>>>>> + if verify_reverse_zone(rz, ip): >>>>>>>>>>> + # reverse zone was entered by user >>>>>>>>>>> + break >>>>>>>>>>> + else: >>>>>>>>>>> + rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> + rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>>> + ret_reverse_zones.append(rz) >>>>>>>>>>> + else: >>>>>>>>>>> + options.no_reverse = True >>>>>>>>>>> + ret_reverse_zones = [] >>>>>>>>>>> >>>>>>>>>>> You can make it shorter without duplications: >>>>>>>>>>> >>>>>>>>>>> # this ifs can be in one line >>>>>>>>>>> if not options.unatended: >>>>>>>>>>> if not options.reverse_zones >>>>>>>>>>> if not create_reverse(): >>>>>>>>>>> options.no_reverse=True >>>>>>>>>>> return [] >>>>>>>>>>> >>>>>>>>>>> for ip in ip_addresses: >>>>>>>>>>> if search_reverse_zones and find_reverse_zone(str(ip)): >>>>>>>>>>> # reverse zone is already in LDAP >>>>>>>>>>> continue >>>>>>>>>>> for rz in ret_reverse_zones: >>>>>>>>>>> if verify_reverse_zone(rz, ip): >>>>>>>>>>> # reverse zone was entered by user >>>>>>>>>>> break >>>>>>>>>>> else: >>>>>>>>>>> rz = get_reverse_zone_default(str(ip)) >>>>>>>>>>> if not options.unattended: >>>>>>>>>>> rz = read_reverse_zone(rz, str(ip)) >>>>>>>>>>> ret_reverse_zones.append(rz) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, I modified it bit different way to alse address >>>>>>>>>> recommendation >>>>>>>>>> 3). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> Typo? There is no IP address matching reverze_zone %s." >>>>>>>>>>> ---------------------------------------------^^ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> Would be nice to ask user to create new zones only if new zones >>>>>>>>>>> are >>>>>>>>>>> required. (If all required zones exist in LDAP, you ask user >>>>>>>>>>> anyway) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I added one more variable and ask only once. >>>>>>>>>> >>>>>>>>>>> 4) >>>>>>>>>>> Ask framework gurus, if installutils module is better place for >>>>>>>>>>> function >>>>>>>>>>> above >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Petr^3 said that it's ok to have it in bindinstance.py. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> NACK, most important point is 7 >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> I'm not sure if this is bug, but interactively is allowed to add >>>>>>>>> only >>>>>>>>> one ip address >>>>>>>>> >>>>>>>>> Unable to resolve IP address for host name >>>>>>>>> Please provide the IP address to be used for this host name: >>>>>>>>> 2001:db8::2 >>>>>>>>> The kerberos protocol requires a Realm name to be defined. >>>>>>>>> >>>>>>>> >>>>>>>> For the sake of infinite usability and UX I rewrote it to ask for >>>>>>>> multiple addresses the same way as for DNS forwarders. Also I really >>>>>>>> simplified IP address checking code when I was in it. I tested it but >>>>>>>> please look at it carefully. >>>>>>>> Also I found that ipa-dns-install and ipa-adtrust-install also accept >>>>>>>> --ip-address param. So I modified ipa-dns-install in the same way as >>>>>>>> ipa-server-install and ipa-replica-install. After discussion with >>>>>>>> tbabej I decided to dont touch ipa-adtrust-install now as it do not >>>>>>>> use specified value at all. I will remove the processing code and >>>>>>>> mark >>>>>>>> the param as deprecated in separate patch. >>>>>>>> >>>>>>>>> 2) >>>>>>>>> I'm getting error message >>>>>>>>> >>>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>>> 2001:db8::dead:beef >>>>>>>>> Invalid reverse zone 10.in-addr.arpa. for IP address >>>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> >>>>>>>>> - or - >>>>>>>>> >>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>> Please specify the reverse zone name >>>>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>>>> Invalid reverse zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. >>>>>>>>> for IP >>>>>>>>> address fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> Please specify the reverse zone name >>>>>>>>> [0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa.]: >>>>>>>>> Using reverse zone(s) 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>>> >>>>>>>>> This shouldn't be there >>>>>>>> >>>>>>>> Moved the message to function used when installation is attended by >>>>>>>> user. >>>>>>>> >>>>>>>>> >>>>>>>>> Could be better to ask user to specific zone for ip address a.b.c.d. >>>>>>>> >>>>>>>> Probably, but lets leave some work for future. >>>>>>>> >>>>>>>>> >>>>>>>>> 4) just nitpick >>>>>>>>> The IPA Master Server will be configured with: >>>>>>>>> ... >>>>>>>>> IP address(es): 2001:db8::dead:beef, >>>>>>>>> fed0:babe:baab:0:21a:4aff:fe10:4e18 >>>>>>>>> ... >>>>>>>>> Reverse zone: 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., >>>>>>>>> 0.0.0.0.b.a.a.b.e.b.a.b.0.d.e.f.ip6.arpa. >>>>>>>>> >>>>>>>>> You have label "IP address(es)", so you should use label "Reverse >>>>>>>>> zone(s)" >>>>>>>>> >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> 5) >>>>>>>>> ipa-server-install --ip-address=10.16.78.105 >>>>>>>>> --reverse-zone=10.in-addr.arpa. --reverse-zone=16.10.in-addr.arpa. >>>>>>>>> --setup-dns >>>>>>>>> >>>>>>>>> Creates both reverse zones, but 10.in-addr.arpa. is empty. I'm not >>>>>>>>> sure >>>>>>>>> if this is wrong, but we prevents user to add zone without >>>>>>>>> address in >>>>>>>>> it, so we should prevents, to add empty zone. >>>>>>>>> >>>>>>>> >>>>>>>> It would be nice but not in this patch. >>>>>>>> >>>>>>>>> 6) >>>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>>> 2001:db8::dead:beef --reverse-zone 1.0.0.2.ip6.arpa. >>>>>>>>> vm-105.example.com >>>>>>>>> Directory Manager (existing master) password: >>>>>>>>> >>>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. for IP address 10.16.78.105 >>>>>>>>> Invalid reverse zone 1.0.0.2.ip6.arpa. >>>>>>>>> >>>>>>>>> IMO This should work, right? >>>>>>>>> >>>>>>>>> + sys.exit("There is no IP address matching reverse >>>>>>>>> zone >>>>>>>>> %s." % rz) >>>>>>>>> I expected at least this error to be shown. >>>>>>>> >>>>>>>> Fixed, thanks. >>>>>>>> >>>>>>>>> >>>>>>>>> 7) >>>>>>>>> ipa-replica-prepare --ip-address 10.16.78.105 --ip-address >>>>>>>>> 2001:db8::dead:beef vm-105.example.com >>>>>>>>> Directory Manager (existing master) password: >>>>>>>>> >>>>>>>>> ....... >>>>>>>>> Adding DNS records for vm-105.example.com >>>>>>>>> Values instance has no attribute 'ip_address' >>>>>>>>> >>>>>>>>> Command returns the attribute error. >>>>>>>>> It fails with one --ip-address too. >>>>>>>>> >>>>>>>> >>>>>>>> Sorry, fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> *) Not related with your patch >>>>>>>>> Problem with installation: >>>>>>>>> I'm getting message: >>>>>>>>> IPA server is already configured on this system. >>>>>>>>> Even if I validation wasn't successful and installation was aborted. >>>>>>>>> >>>>>>>>> IPA install detects previous installations by checking state file >>>>>>>>> and >>>>>>>>> restore files. Function get_server_ip_address() stores some data and >>>>>>>>> hosts file and modify the host file, before user agreed >>>>>>>>> installation. >>>>>>>>> This error was there before your patch. >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4561 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> NACK >>>>>>> >>>>>>> 0) >>>>>>> # ipa-dns-install --ip-address 2001:db8::feed >>>>>>> >>>>>>> 2014-09-24T06:02:13Z DEBUG stderr= >>>>>>> 2014-09-24T06:02:13Z DEBUG File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> line 645, in run_script >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-dns-install", line 135, in main >>>>>>> ip_addresses = get_server_ip_address(api.env.host, fstore, >>>>>>> options.unattended, options) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> line 473, in get_server_ip_address >>>>>>> if options.setup_dns: >>>>>>> >>>>>>> 2014-09-24T06:02:13Z DEBUG The ipa-dns-install command failed, >>>>>>> exception: AttributeError: Values instance has no attribute >>>>>>> 'setup_dns' >>>>>> >>>>>> Obviously there is no option --setup-dns in ipa-dns-install. >>>>>> Fixed, modified get_server_ip_address function. >>>>>> >>>>>>> >>>>>>> 1) >>>>>>> # ipa-replica-prepare vm-073.example.com --ip-address >>>>>>> 2620:52:0::fe10:4e18 --ip-address 10.16.78.73 >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> Preparing replica for vm-073.example.com from vm-105.example.com >>>>>>> Creating SSL certificate for the Directory Server >>>>>>> Creating SSL certificate for the dogtag Directory Server >>>>>>> Saving dogtag Directory Server port >>>>>>> Creating SSL certificate for the Web Server >>>>>>> Exporting RA certificate >>>>>>> Copying additional files >>>>>>> Finalizing configuration >>>>>>> Packaging replica information into >>>>>>> /var/lib/ipa/replica-info-vm-073.example.com.gpg >>>>>>> Adding DNS records for vm-073.example.com >>>>>>> Values instance has no attribute 'unattended' >>>>>>> >>>>>>> It should be unatended automatically, or we need add the --unattended >>>>>>> option to ipa-replica-prepare >>>>>> >>>>>> ipa-replica-install is missing --unattended option. I fixed it in my >>>>>> code for now but we should add it there. >>>>>> >>>>>>> >>>>>>> 2) This is nto user friendly, could be IP address check before >>>>>>> installation? >>>>>>> [root at vm-073 ~]# ipa-replica-install replica.file.gpg --ip-address >>>>>>> 2620:52::fe10:4e18 --reverse-zone 10.in-addr.arpa. --setup-dns >>>>>>> --no-forwarders >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> Run connection check to master >>>>>>> ... >>>>>>> >>>>>>> ... >>>>>>> Restarting the KDC >>>>>>> There is no IP address matching reverse zone 10.in-addr.arpa.. >>>>>>> >>>>>>> LOG: >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>>> install_bind(config, options) >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 265, in install_bind >>>>>>> reverse_zones = >>>>>>> bindinstance.check_reverse_zones(config.ip_addresses, >>>>>>> options.reverse_zones, options, True) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> line 426, in check_reverse_zones >>>>>>> sys.exit("There is no IP address matching reverse zone %s." % rz) >>>>>>> >>>>>>> 2014-09-24T06:39:23Z DEBUG The ipa-replica-install command failed, >>>>>>> exception: SystemExit: There is no IP address matching reverse zone >>>>>>> 10.in-addr.arpa.. >>>>>> >>>>>> Fixed. Asking everything before actual installation. >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> I'm not sure if sys.exit() is good, replica-install shoudl wrote >>>>>>> something about partially configured system >>>>>> >>>>>> This is quite common in installation scripts. I moved this parts before >>>>>> actual installation. >>>>>> >>>>>>> >>>>>>> 4) I'm not sure if this is the best place to ask about reverse zones >>>>>>> .... >>>>>>> Done configuring the web interface (httpd). >>>>>>> Configuring ipa-otpd >>>>>>> [1/2]: starting ipa-otpd >>>>>>> [2/2]: configuring ipa-otpd to start on boot >>>>>>> Done configuring ipa-otpd. >>>>>>> Applying LDAP updates >>>>>>> Restarting the directory server >>>>>>> Restarting the KDC >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> >>>>>> Moved. >>>>>> >>>>>>> >>>>>>> 5) And error >>>>>>> # ipa-replica-install replica.file.gpg --ip-address 2620:52:xxxx >>>>>>> --setup-dns >>>>>>> .... >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> Please specify the reverse zone name >>>>>>> [c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa.]: >>>>>>> Using reverse zone(s) c.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa. >>>>>>> >>>>>>> Your system may be partly configured. >>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>>> >>>>>>> Unexpected error - see /var/log/ipareplica-install.log for details: >>>>>>> AttributeError: 'str' object has no attribute 'version' >>>>>>> >>>>>>> LOG: >>>>>>> 2014-09-24T06:50:44Z DEBUG retrieving schema for SchemaCache >>>>>>> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >>>>>>> conn= >>>>>>> 2014-09-24T06:50:45Z DEBUG File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>>>> line 645, in run_script >>>>>>> return_value = main_function() >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 721, in main >>>>>>> install_bind(config, options) >>>>>>> >>>>>>> File "/sbin/ipa-replica-install", line 272, in install_bind >>>>>>> ca_configured=options.setup_ca) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> line 550, in setup >>>>>>> self.__setup_sub_dict() >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>>>> line 651, in __setup_sub_dict >>>>>>> if addr.version in (4, 6): >>>>>>> >>>>>>> 2014-09-24T06:50:45Z DEBUG The ipa-replica-install command failed, >>>>>>> exception: AttributeError: 'str' object has no attribute 'version' >>>>>> >>>>>> Fixed. We are using IP addresses as a strings and as a >>>>>> CheckedIPAddress. >>>>>> I swapped them here. >>>>>>> >>>>>>> >>>>>>> *) I don't like this asking to specify zone without IP >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> Please specify the reverse zone name >>>>>>> [0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.]: >>>>>>> Please specify the reverse zone name [78.16.10.in-addr.arpa.]: >>>>>>> >>>>>> >>>>>> Would be nice. Prefer to do it as a part of more powerfull reverse zone >>>>>> validation logic. >>>>>>> >>>>>>> >>>>>>> **) I'm not sure how often this case can happen: >>>>>>> master and replica without DNS, you run --ipa-dns-install on master >>>>>>> then >>>>>>> on replica, then replica DNS installation will not try to find >>>>>>> existent >>>>>>> reverse zones in ldap, due configuration in ipa-dns-install. >>>>>>> Maybe you should detect if DNS container exists and then set flag >>>>>>> "search_reverse_zones=True" >>>>>>> >>>>>>> ipa-dns-install: >>>>>>> + reverse_zones = bindinstance.check_reverse_zones(ip_addresses, >>>>>>> options.reverse_zones, options) >>>>>> >>>>>> Same as above. >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Rebased to current master and ipa-4-1. Removed unintentional >>>>> modification of ipa-adtrust-install. >>>> >>>> + for ip, ip_address in zip(config.ips, config.ip_addresses): >>>> + reverse_zone = bindinstance.find_reverse_zone(ip) >>>> >>>> Is it always 100% guaranteed that the values in config.ips and >>>> config.ip_addresses are the same length and otherwise match each other >>>> in a way that will not cause things to break? IMO it would be better to >>>> store a single list of 2-tuples somewhere from the start instead of >>>> zipping things later. (Note that zip([1], ['yes', 'oh noes!']) == [(1, >>>> 'yes')].) >>>> >>> >>> The chances that this will break are really small but I cannot guarantee >>> that it won't eventually. >>> One list (config.ip_addresses) is generated from the other (config.ips) >>> and right now there is no need to modify them. But if someone in the >>> future modify only one of them it will fail really badly. So I removed >>> zip() and convert the ip address to string on demand. It will cost a few >>> more cycles but also will be less error prone. >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Another few flaws eradicated. >> > ACK > > There is one issue with info message in ipa-replica-install, where wrong zone > is shown instead of zone where value will be added. (Values in DNS are > correct). This doesn't work on IPA 4.0 too. (by source code, not tested) Great! Thanks for this heroic effort :-) Pushed to master, ipa-4-1. Martin From tbordaz at redhat.com Fri Sep 26 16:34:07 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 26 Sep 2014 18:34:07 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <54258BF0.4020208@gmx.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> <54257893.9010607@gmx.com> <542585B2.8020600@gmx.com> <542589B7.9060104@redhat.com> <54258BF0.4020208@gmx.com> Message-ID: <5425957F.90308@redhat.com> On 09/26/2014 05:53 PM, Francesco Marella wrote: > > On 26/09/2014 17:43, thierry bordaz wrote: >> Hello, >> >> When called from set_selinux_booleans, if not selinux_enabled, >> you may want to 'return False' rather than 'return'. >> Now it looks like callers of set_selinux_booleans do not check >> the returned value :-) >> >> thanks >> thierry >> >> On 09/26/2014 05:26 PM, Francesco Marella wrote: >>> This should be the final one. >>> >>> fm >>> >>> On 26/09/2014 16:30, Francesco Marella wrote: >>>> >>>> On 26/09/2014 15:41, Petr Viktorin wrote: >>>>> >>>>> Hello! Thanks for the patch! >>>>> >>>>> The new function is not one of the platform-independent tasks, and >>>>> doesn't even use `self`, so you can define it as a module-level >>>>> helper function. >>>>> >>>>> But more importantly, this won't work: the blocks you are >>>>> replacing return from their functions. You'd need to use something >>>>> like: >>>>> if not selinux_enabled(): >>>>> return >>>>> instead of: >>>>> self.check_enabled_selinux() >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Thanks Francesco ! For me it is a ACK. thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Sep 26 17:40:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Sep 2014 19:40:17 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <5425883E.6020000@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> Message-ID: <5425A501.4030909@redhat.com> Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): > Petr Viktorin wrote: >> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix >>> and . >>> >>> (Note that design page for this is TBD.) > > Isn't this backwards then? > >> >> 336: >> >> Instead of >> len(data[:match.start() + 1].splitlines()) >> you can do >> data.count('\n', 0, match.start()) + 1 Unfortunately '\n' is not good enough, we have to check for '\r\n' and '\r' as well, hence the use of splitlines. >> >> 337: >> The --external_cert_file and --external_ca_file options for >> ipa-ca-install are removed, do we really want to do that? Shouldn't they >> be deprecated instead? > > +1 > >> >> Same for --external-ca-file in ipa-cacert-manage. > > +1 IMO it's OK to just remove them, as they were added during 4.1 development and are not available in any released version of IPA. > > I can't say I'm a fan of forcing users to concatenate cert files. All the --*-cert-file options may be given multiple times. > >> >> 338: Looks OK >> 339: Looks OK >> >> Could you add some docstrings to the functions you add? Sometimes it's >> harder than necessary to decipher what they do and what the >> arguments/return values mean exactly. Sure. >> >> There is no user-visible documentation on what file types are >> expected/supported. It would be good to add this to the man pages, or >> the --help. Added. > > I also wonder if the detection code should be changed. It basically now > tries a slew of different mechanisms one at a time rather than trying to > identify the type of file and using that one. It may not be possible in > all cases but you could at least start by looking for ^----- to know it > is a text file and go from there, otherwise step through the binary formats. Rearranged the code so that text files are tried first. > >> >> >> >> In external CA, the error message when specifying a certificate but not >> the CA could be improved: >> $ ipa-server-install --external_cert_file ~/p/Certificate_Authority_8.cer >> ... >> CA certificate CN=Certificate Authority,O=IDM.LAB.ENG.BRQ.REDHAT.COM in >> /home/pviktori/p/Certificate_Authority_8.cer is not valid: >> (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized. Fixed. >> >> >> >> For CA-less, I used a combination of files with which server >> installation went well, but replica-install failed halfway through: >> >> Console: >> ... >> [16/36]: creating indices >> [17/36]: enabling referential integrity plugin >> [18/36]: configuring ssl for ds instance >> [error] RuntimeError: incorrect password for pkcs#12 file >> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >> >> Log tail: >> >> 2014-09-26T15:05:43Z DEBUG Starting external process >> 2014-09-26T15:05:43Z DEBUG args='/usr/bin/pk12util' '-d' >> '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/' '-i' >> '/tmp/tmp2vEWX_ipa/realm_info/dscert.p12' '-k' >> '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM//pwdfile.txt' '-v' '-w' >> '/dev/stdin' >> 2014-09-26T15:05:43Z DEBUG Process finished, return code=17 >> 2014-09-26T15:05:43Z DEBUG stdout= >> 2014-09-26T15:05:43Z DEBUG stderr=pk12util: PKCS12 decode not verified: >> SEC_ERROR_BAD_PASSWORD: The security password entered is incorrect. >> >> 2014-09-26T15:05:43Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 370, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 360, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 600, in __enable_ssl >> trust_flags=trust_flags) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 1030, in create_from_pkcs12 >> self.import_pkcs12(pkcs12_fname, pkcs12_passwd) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 971, in import_pkcs12 >> pkcs12_passwd=pkcs12_passwd) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 191, in import_pkcs12 >> pkcs12_filename) >> RuntimeError: incorrect password for pkcs#12 file >> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >> >> 2014-09-26T15:05:43Z DEBUG [error] RuntimeError: incorrect password >> for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >> 2014-09-26T15:05:43Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 644, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-replica-install", line 677, in main >> ds = install_replica_ds(config) >> >> File "/sbin/ipa-replica-install", line 190, in install_replica_ds >> ca_file=config.dir + "/ca.crt", >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 354, in create_replica >> self.start_creation(runtime=60) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 370, in start_creation >> run_step(full_msg, method) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 360, in run_step >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 600, in __enable_ssl >> trust_flags=trust_flags) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 1030, in create_from_pkcs12 >> self.import_pkcs12(pkcs12_fname, pkcs12_passwd) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 971, in import_pkcs12 >> pkcs12_passwd=pkcs12_passwd) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 191, in import_pkcs12 >> pkcs12_filename) >> >> 2014-09-26T15:05:43Z DEBUG The ipa-replica-install command failed, >> exception: RuntimeError: incorrect password for pkcs#12 file >> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >> >> >> I'll attach the files for reference; the options for ipa-server-install >> and ipa-replica-prepare were: >> >> --http-cert-file=~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 >> --http-cert-file >> ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-allcerts-x509.pem --http-pin >> 12345678 --dirsrv-cert-file >> ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-cacerts-pkcs7.pem >> --dirsrv-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 >> --dirsrv-pin 12345678 Fixed. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-336.2-Add-NSSDatabase.import_files-method-for-importing-fi.patch Type: text/x-patch Size: 9351 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-337.2-External-CA-installer-options-usability-fixes.patch Type: text/x-patch Size: 26469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-338.2-CA-less-installer-options-usability-fixes.patch Type: text/x-patch Size: 46851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-339.2-Allow-choosing-CA-less-server-certificates-by-name.patch Type: text/x-patch Size: 9601 bytes Desc: not available URL: From jcholast at redhat.com Fri Sep 26 17:54:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Sep 2014 19:54:11 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5425828D.5020508@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> Message-ID: <5425A843.1060007@redhat.com> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix various bugs and shortcomings in the CA >>>> management and renewal code. Related tickets: >>>> , >>>> . >>>> >>>> (Patch 319 was originally posted at >>>> .) >>>> >>> >>> Only two of the patches includes what ticket(s) they address. Most have >>> the tersest of commit messages. If got more and more difficult to see >>> why the changes were needed at all, as you'll see. >> >> Sorry, fixed (hopefully). >> >> Note that most of these patches fix stuff I didn't have time to fix >> before I posted the original CA management patches, hence the missing >> tickets. > > Well, the policy is that every commit should have a ticket. So I guess > re-open the old tickets or open new ones. This will help someone in the > future know the "why" of a patch. I've certainly been guilty OK, I will reopen the related tickets. > > Here is a new set of reviews as trying to intermingle was making my eyes > cross: > > 319: > > I guess I still don't understand why you can't pull the certs out of > LDAP when creating this database. When this code runs, we know that the > client is configured, so we have access to authentication. Why can't > create_ipa_nssdb pull the certs directly? It seems more robust to me, > and the code is already written in ipa-client-install to do this. Well, I don't understand why do you want them to be updated so much, as nothing will break if they are not. Also try to imagine what would happen if, say, 10k clients were updated at the same moment... > > When adding the CA certificates to the temporary database it will report > that a failure occurred, but not the exception: > > + except CalledProcessError, e: > + root_logger.info("Failed to add CA to temporary NSS database.") > + return CLIENT_INSTALL_ERROR > > Granted, NSS errors are often obtuse, but should it at least DEBUG log it? It is already logged in ipautil.run. The exception only says that the command failed, there's no point in logging it. > > 324, 325, 326: ACK > > 327: > > So the idea is to just mirror the certs and us the new db to know what > was added? Exactly. > What if someone has the same nickname, different cert in the > two databases? Is that too much of a corner case? IMO it is too much of a corner case, but I plan on adding a better diff/patch algorithm in the future if it turns out to be a problem. > > 328, 329, 330, 331: ACK > > As an aside, do you know why the global certs are seen by mod_nss? > libnssckbi.so is symlinked into the directory (certutil -L -d > /etc/httpd/alias -h all will show all the certs). I'm not sure why it is this way, but the module is linked to the NSS database: $ sudo modutil -list -dbdir /etc/httpd/alias Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. Root Certs library name: /etc/httpd/alias/libnssckbi.so slots: 2 slots attached status: loaded slot: /etc/pki/ca-trust/source token: System Trust slot: /usr/share/pki/ca-trust-source token: Default Trust ----------------------------------------------------------- > > 332-335 > > I think the naming and/or comments can be improved. For example, there > are now 3 *retrieve_cert commands, all of which do slightly different > things. All have external handlers (via the oddly named profile), but > some are called internally as well. I have spent quite some time trying to come up with good names for them, but I was not able to do so. Suggestions are welcome. > > This is rather complex code: a command passes a call onto certmonger > which then exuecutes the IPA CA helper... More documentation would > definitely help a newcomer figure out how renewal, CA retrieval, etc. works. OK, I'll try to add some. > > Not to be too pedantic but there is a lot of this in > dogtag-ipa-ca-renew-agent-submit: > > if variable: OR if not variable: > > Where variable defaults to None. Shouldn't the test be: > > if variable is [not] None: This doesn't catch empty strings, which may occur in some of these checks. > > 340: ACK > > Through some combination of ipa-certupdate and ipa-cacert-manage I seem > to have hosed things up: > > ipa: DEBUG: certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 118, in run > rc = self.renew() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 181, in renew > return self.renew_self_signed(ca) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 193, in renew_self_signed > self.resubmit_request(ca, 'caCACert') > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 315, in resubmit_request > "please check the request manually" % self.request_id) > > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The > ipa-cacert-manage command failed, exception: ScriptError: Error > resubmitting certmonger request '20140909142830', please check the > request manually > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Error > resubmitting certmonger request '20140909142830', please check the > request manually > > Incidentally, IMHO it should include the command to execute to check the > request manually. Will add. > > The CA is actually unreachable. Restarting it fixed things. I'll chalk > this up to cosmic rays. OK. > > Re-running ipa-cacert-manage renew was successful. Good. > > I confirmed that the CA signing cert was updated in the dogtag database. > > I then ran ipa-certupdate to distribute this new CA cert around and none > of the databases got the updated CA cert, nor did /etc/ipa/ca.crt. Can you see the new CA cert in cn=certificates,cn=ipa,cn=etc,$SUFFIX? > > Still doing some functional testing. > > Unrelated to this: > > 9:freeipa-python-4.0.0GITf6875d4-0.################################# > [100%] > Update failed: Operations error: > > Seems to be related to this: > > 2014-09-25T19:28:22Z DEBUG --------------------------------------------- > 2014-09-25T19:28:22Z DEBUG Final value after applying updates > 2014-09-25T19:28:22Z DEBUG dn: cn=referential integrity > postoperation,cn=plugins,cn=config > 2014-09-25T19:28:22Z DEBUG cn: > 2014-09-25T19:28:22Z DEBUG referential integrity postoperation > 2014-09-25T19:28:22Z DEBUG objectClass: > 2014-09-25T19:28:22Z DEBUG top > 2014-09-25T19:28:22Z DEBUG nsSlapdPlugin > 2014-09-25T19:28:22Z DEBUG extensibleObject > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginprecedence: > 2014-09-25T19:28:22Z DEBUG 40 > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginPath: > 2014-09-25T19:28:22Z DEBUG libreferint-plugin > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVersion: > 2014-09-25T19:28:22Z DEBUG 1.3.3.2 > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg5: > 2014-09-25T19:28:22Z DEBUG owner > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg4: > 2014-09-25T19:28:22Z DEBUG uniquemember > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg7: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg6: > 2014-09-25T19:28:22Z DEBUG seeAlso > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg1: > 2014-09-25T19:28:22Z DEBUG /var/log/dirsrv/slapd-GREYOAK-COM/referint > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg0: > 2014-09-25T19:28:22Z DEBUG 0 > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg3: > 2014-09-25T19:28:22Z DEBUG member > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg2: > 2014-09-25T19:28:22Z DEBUG 0 > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg9: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg8: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginInitfunc: > 2014-09-25T19:28:22Z DEBUG referint_postop_init > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginexcludeentryscope: > 2014-09-25T19:28:22Z DEBUG cn=provisioning,dc=greyoak,dc=com > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg11: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg10: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg13: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg12: > 2014-09-25T19:28:22Z DEBUG nsslapd-plugin-depends-on-type: > 2014-09-25T19:28:22Z DEBUG database > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVendor: > 2014-09-25T19:28:22Z DEBUG 389 Project > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg17: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg16: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg18: > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginType: > 2014-09-25T19:28:22Z DEBUG betxnpostoperation > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginDescription: > 2014-09-25T19:28:22Z DEBUG referential integrity plugin > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginentryscope: > 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginEnabled: > 2014-09-25T19:28:22Z DEBUG on > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginId: > 2014-09-25T19:28:22Z DEBUG referint > 2014-09-25T19:28:22Z DEBUG nsslapd-plugincontainerscope: > 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg15: > 2014-09-25T19:28:22Z DEBUG referint-membership-attr: > 2014-09-25T19:28:22Z DEBUG manager > 2014-09-25T19:28:22Z DEBUG secretary > 2014-09-25T19:28:22Z DEBUG memberuser > 2014-09-25T19:28:22Z DEBUG memberhost > 2014-09-25T19:28:22Z DEBUG sourcehost > 2014-09-25T19:28:22Z DEBUG memberservice > 2014-09-25T19:28:22Z DEBUG managedby > 2014-09-25T19:28:22Z DEBUG memberallowcmd > 2014-09-25T19:28:22Z DEBUG memberdenycmd > 2014-09-25T19:28:22Z DEBUG ipasudorunas > 2014-09-25T19:28:22Z DEBUG ipasudorunasgroup > 2014-09-25T19:28:22Z DEBUG ipatokenradiusconfiglink > 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg14: > 2014-09-25T19:28:22Z DEBUG [(1, u'nsslapd-pluginarg16', None), (1, > u'nsslapd-pluginarg7', None), (1, u'nsslapd-pluginarg9', None), (1, > u'nsslapd-pluginarg8', None), (1, u'nsslapd-pluginarg11', None), (1, > u'nsslapd-pluginarg10', None), (1, u'nsslapd-pluginarg13', None), (1, > u'nsslapd-pluginarg12', None), (1, u'nsslapd-pluginarg17', None), (1, > u'nsslapd-pluginarg18', None), (1, u'nsslapd-pluginarg15', None), (2, > u'referint-membership-attr', ['sourcehost', 'memberallowcmd', > 'memberdenycmd', 'memberuser', 'managedby', 'manager', 'memberservice', > 'ipasudorunas', 'ipasudorunasgroup', 'secretary', 'memberhost', > 'ipatokenradiusconfiglink']), (1, u'nsslapd-pluginarg14', None)] > 2014-09-25T19:28:22Z DEBUG Live 1, updated 1 > 2014-09-25T19:28:22Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: > {'desc': 'Operations error'} > 2014-09-25T19:28:22Z ERROR Update failed: Operations error: > > -- Jan Cholasta From ftweedal at redhat.com Mon Sep 29 03:16:07 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 29 Sep 2014 13:16:07 +1000 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <20140926104416.44548b7c@willson.usersys.redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> Message-ID: <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: > On Fri, 26 Sep 2014 13:54:34 +0200 > Martin Kosek wrote: > > > >> I tested the patch (it works fine with Dogtag 10), but I got very > > >> confused. > > >> > > >> What CA option are we setting? Signing algorithm or Key Algorithm? > > >> I thought we are only setting Signing algorithm, but in that > > >> case: > > > > > > We are setting key algorithm for the CA signing key. > > > > That did not made me any less confused... If I check for example > > fields from certificate details from my browser, I see 2 algorithms > > names: > > > > * Public Key Algorithm (RSA, ECC, ...) > > * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, > > something with ECC) > > > > In that world, "key algorithm" should really refer to the key PKI > > algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes > > come to play. > > > > >> - --ca-key-algorithm option should rather read > > >> --ca-signing-key-algorithm > > > > > > If you want to emphasize that it is actually the algorithm used to > > > sign the CA certificate, the option should read > > > --ca-certificate-signature-algorithm, but I would rather stick to > > > Dogtag terminology and keep the string "key algorithm" in the > > > name. > > > > I still think for most people "key algorithm" refers to Public Key > > algorithm. Rob or Simo, what is your take on this? > > If we are defining the signing algorithm the "signing" string should be > somewhere in the option. > Having just --key-algorithm is indeed confusing. > > Simo. > My take is that the terminology should be chosen in line with standards. The X.509 field is called `signatureAlgorithm' so `--ca-certificate-signature-algorithm' makes sense to me. Consistency with Dogtag terminology is a secondary consideration considering FreeIPA users are unlikely to interact directly with Dogtag much (especially during installation). Fraser > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From edewata at redhat.com Mon Sep 29 04:07:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 28 Sep 2014 23:07:19 -0500 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <5425857F.8020401@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> <54244BEF.40000@redhat.com> <5425857F.8020401@redhat.com> Message-ID: <5428DAF7.2080907@redhat.com> On 9/26/2014 10:25 AM, Petr Vobornik wrote: > On 25.9.2014 19:07, Petr Vobornik wrote: >> All issues will be done separately as already stated in other >> sub-thread. I've removed issues which are discussed in the other >> sub-thread. >> >>>> 2. The tab titles in the ID view details page are quite long, and the >>>> "User ID overrides" and "Group ID overrides" labels aren't quite >>>> appropriate because the ID view can override other attributes too. How >>>> about using facet groups like in User Groups? For example: >>>> - applies to: >>>> - Hosts >>>> - overrides: >>>> - Users >>>> - Groups >>>> - Settings > > Attached patch 758 ACK. >>>> 7. Related to #6, there probably should be a tab in the Host details >>>> page showing which ID views apply to it. >>> There is only a single view and yes, it would be good to add a property >>> there, linking it to the ID view tab, if possible. >> >> Will add simple readonly field (link to view). It will be improved later >> (based on ipa-4-1 priorities) > > Attached patch 760 ACK. >>>> 9. This probably requires server support. In the "Apply to hosts" >>>> association dialog, if a host is already added it will still appear in >>>> the dialog box. As a comparison, a User that has been added into a >>>> User Group will not appear in the association dialog anymore. >>> Could be trivially filtered out on Web UI side. >> >> Will be implemented. > > Attached patch 759 - quite ugly hack but does the job ACK. -- Endi S. Dewata From jpazdziora at redhat.com Mon Sep 29 06:31:07 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 29 Sep 2014 08:31:07 +0200 Subject: [Freeipa-devel] Continuous Integration & dependency tree testing In-Reply-To: <5422691D.50003@redhat.com> References: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> <5422691D.50003@redhat.com> Message-ID: <20140929063107.GF8063@redhat.com> On Wed, Sep 24, 2014 at 08:47:57AM +0200, Martin Kosek wrote: > > There is a good question though how the test should be triggered when our > dependency changes and the code does not (especially in stable branches). This > may be the part where the mechanism you propose would come in play. Can't you just run the tests once per day, no matter what? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Sep 29 07:17:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 09:17:32 +0200 Subject: [Freeipa-devel] Continuous Integration & dependency tree testing In-Reply-To: <20140929063107.GF8063@redhat.com> References: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> <5422691D.50003@redhat.com> <20140929063107.GF8063@redhat.com> Message-ID: <5429078C.8070702@redhat.com> On 09/29/2014 08:31 AM, Jan Pazdziora wrote: > On Wed, Sep 24, 2014 at 08:47:57AM +0200, Martin Kosek wrote: >> >> There is a good question though how the test should be triggered when our >> dependency changes and the code does not (especially in stable branches). This >> may be the part where the mechanism you propose would come in play. > > Can't you just run the tests once per day, no matter what? Sure, I hope Jenkins would make that easy. Martin From pvoborni at redhat.com Mon Sep 29 07:40:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 29 Sep 2014 09:40:17 +0200 Subject: [Freeipa-devel] [PATCH] 757 webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types In-Reply-To: <54229A46.9040409@redhat.com> References: <54229A46.9040409@redhat.com> Message-ID: <54290CE1.9040808@redhat.com> On 24.9.2014 12:17, Petr Vobornik wrote: > webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types > > They are not supported by API. Forgot to attach patch... -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0757-webui-do-not-offer-ipa-ad-winsync-and-ipa-ipa-trust-.patch Type: text/x-patch Size: 1182 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 29 07:50:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 29 Sep 2014 09:50:20 +0200 Subject: [Freeipa-devel] Continuous Integration & dependency tree testing In-Reply-To: <20140929063107.GF8063@redhat.com> References: <2119457106.28226194.1411497586577.JavaMail.zimbra@redhat.com> <5422691D.50003@redhat.com> <20140929063107.GF8063@redhat.com> Message-ID: <54290F3C.6040904@redhat.com> On 29.9.2014 08:31, Jan Pazdziora wrote: > On Wed, Sep 24, 2014 at 08:47:57AM +0200, Martin Kosek wrote: >> >> There is a good question though how the test should be triggered when our >> dependency changes and the code does not (especially in stable branches). This >> may be the part where the mechanism you propose would come in play. > > Can't you just run the tests once per day, no matter what? You can but then it would be harder to detect which particular update broke IPA. (Imagine that there was 10 different package updates in the same day. You would have to bisect the find the broken package.) -- Petr^2 Spacek From dkupka at redhat.com Mon Sep 29 08:09:58 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 29 Sep 2014 10:09:58 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. Message-ID: <542913D6.8020006@redhat.com> https://fedorahosted.org/freeipa/ticket/4387 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0017-Do-not-require-description-in-UI.patch Type: text/x-patch Size: 12274 bytes Desc: not available URL: From mkosek at redhat.com Mon Sep 29 08:22:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 10:22:33 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. In-Reply-To: <542913D6.8020006@redhat.com> References: <542913D6.8020006@redhat.com> Message-ID: <542916C9.9040409@redhat.com> On 09/29/2014 10:09 AM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4387 The changes look OK so far, except the test fix. The test_batch_plugin.py test is apparently testing that batch command behaves well in RequirementError for options. Thus, we should not remove it, we should just pick different option. Like filling uid+first options with user-add, but missing the --last option. Martin From dkupka at redhat.com Mon Sep 29 09:04:28 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 29 Sep 2014 11:04:28 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. In-Reply-To: <542916C9.9040409@redhat.com> References: <542913D6.8020006@redhat.com> <542916C9.9040409@redhat.com> Message-ID: <5429209C.6090005@redhat.com> On 09/29/2014 10:22 AM, Martin Kosek wrote: > On 09/29/2014 10:09 AM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4387 > > The changes look OK so far, except the test fix. > > The test_batch_plugin.py test is apparently testing that batch command behaves > well in RequirementError for options. Thus, we should not remove it, we should > just pick different option. Like filling uid+first options with user-add, but > missing the --last option. > > Martin > Ok, but the test is bit redundant as there is already test for missing givenname that should behave the same way. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0017-2-Do-not-require-description-in-UI.patch Type: text/x-patch Size: 12116 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 29 09:11:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 11:11:06 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> Message-ID: <5429222A.9030406@redhat.com> Dne 29.9.2014 v 05:16 Fraser Tweedale napsal(a): > On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: >> On Fri, 26 Sep 2014 13:54:34 +0200 >> Martin Kosek wrote: >> >>>>> I tested the patch (it works fine with Dogtag 10), but I got very >>>>> confused. >>>>> >>>>> What CA option are we setting? Signing algorithm or Key Algorithm? >>>>> I thought we are only setting Signing algorithm, but in that >>>>> case: >>>> >>>> We are setting key algorithm for the CA signing key. >>> >>> That did not made me any less confused... If I check for example >>> fields from certificate details from my browser, I see 2 algorithms >>> names: >>> >>> * Public Key Algorithm (RSA, ECC, ...) >>> * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, >>> something with ECC) >>> >>> In that world, "key algorithm" should really refer to the key PKI >>> algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes >>> come to play. >>> >>>>> - --ca-key-algorithm option should rather read >>>>> --ca-signing-key-algorithm >>>> >>>> If you want to emphasize that it is actually the algorithm used to >>>> sign the CA certificate, the option should read >>>> --ca-certificate-signature-algorithm, but I would rather stick to >>>> Dogtag terminology and keep the string "key algorithm" in the >>>> name. >>> >>> I still think for most people "key algorithm" refers to Public Key >>> algorithm. Rob or Simo, what is your take on this? >> >> If we are defining the signing algorithm the "signing" string should be >> somewhere in the option. >> Having just --key-algorithm is indeed confusing. >> >> Simo. >> > > My take is that the terminology should be chosen in line with > standards. The X.509 field is called `signatureAlgorithm' so > `--ca-certificate-signature-algorithm' makes sense to me. > Consistency with Dogtag terminology is a secondary consideration > considering FreeIPA users are unlikely to interact directly with > Dogtag much (especially during installation). > > Fraser > I think it actually sets both the key algorithm and the signature algorithm (you can't do a RSA signature with a EC key, etc.), that's probably why it is called "key algorithm" in Dogtag. -- Jan Cholasta From mkosek at redhat.com Mon Sep 29 10:20:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 12:20:04 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <5429222A.9030406@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> <5429222A.9030406@redhat.com> Message-ID: <54293254.6020406@redhat.com> On 09/29/2014 11:11 AM, Jan Cholasta wrote: > Dne 29.9.2014 v 05:16 Fraser Tweedale napsal(a): >> On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: >>> On Fri, 26 Sep 2014 13:54:34 +0200 >>> Martin Kosek wrote: >>> >>>>>> I tested the patch (it works fine with Dogtag 10), but I got very >>>>>> confused. >>>>>> >>>>>> What CA option are we setting? Signing algorithm or Key Algorithm? >>>>>> I thought we are only setting Signing algorithm, but in that >>>>>> case: >>>>> >>>>> We are setting key algorithm for the CA signing key. >>>> >>>> That did not made me any less confused... If I check for example >>>> fields from certificate details from my browser, I see 2 algorithms >>>> names: >>>> >>>> * Public Key Algorithm (RSA, ECC, ...) >>>> * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, >>>> something with ECC) >>>> >>>> In that world, "key algorithm" should really refer to the key PKI >>>> algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes >>>> come to play. >>>> >>>>>> - --ca-key-algorithm option should rather read >>>>>> --ca-signing-key-algorithm >>>>> >>>>> If you want to emphasize that it is actually the algorithm used to >>>>> sign the CA certificate, the option should read >>>>> --ca-certificate-signature-algorithm, but I would rather stick to >>>>> Dogtag terminology and keep the string "key algorithm" in the >>>>> name. >>>> >>>> I still think for most people "key algorithm" refers to Public Key >>>> algorithm. Rob or Simo, what is your take on this? >>> >>> If we are defining the signing algorithm the "signing" string should be >>> somewhere in the option. >>> Having just --key-algorithm is indeed confusing. >>> >>> Simo. >>> >> >> My take is that the terminology should be chosen in line with >> standards. The X.509 field is called `signatureAlgorithm' so >> `--ca-certificate-signature-algorithm' makes sense to me. >> Consistency with Dogtag terminology is a secondary consideration >> considering FreeIPA users are unlikely to interact directly with >> Dogtag much (especially during installation). >> >> Fraser >> > > I think it actually sets both the key algorithm and the signature algorithm > (you can't do a RSA signature with a EC key, etc.), that's probably why it is > called "key algorithm" in Dogtag. Hm, you are right that the key algorithm is implied during signature algorithm selection. But still, values SHA256withRSA and friends really denote just a signature algorithm and the option should be named accordingly. Martin From mkosek at redhat.com Mon Sep 29 10:57:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 12:57:10 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. In-Reply-To: <5429209C.6090005@redhat.com> References: <542913D6.8020006@redhat.com> <542916C9.9040409@redhat.com> <5429209C.6090005@redhat.com> Message-ID: <54293B06.5080902@redhat.com> On 09/29/2014 11:04 AM, David Kupka wrote: > On 09/29/2014 10:22 AM, Martin Kosek wrote: >> On 09/29/2014 10:09 AM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4387 >> >> The changes look OK so far, except the test fix. >> >> The test_batch_plugin.py test is apparently testing that batch command behaves >> well in RequirementError for options. Thus, we should not remove it, we should >> just pick different option. Like filling uid+first options with user-add, but >> missing the --last option. >> >> Martin >> > > Ok, but the test is bit redundant as there is already test for missing > givenname that should behave the same way. I think it is useful to keep the test here, in the previous one no option was added. Anyway, this should not stop this patch from going in. I checked the test results + Web UI and all looks OK. ACK. Pushed to: master: cd9a4cca1fe17998a342fde000ece5bf46d13d27 ipa-4-1: b69510b9bf8216d52707968bf520fd2dfa6e1ba7 Thanks, Martin From jcholast at redhat.com Mon Sep 29 11:13:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 13:13:53 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <54293254.6020406@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> <5429222A.9030406@redhat.com> <54293254.6020406@redhat.com> Message-ID: <54293EF1.3050903@redhat.com> Dne 29.9.2014 v 12:20 Martin Kosek napsal(a): > On 09/29/2014 11:11 AM, Jan Cholasta wrote: >> Dne 29.9.2014 v 05:16 Fraser Tweedale napsal(a): >>> On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: >>>> On Fri, 26 Sep 2014 13:54:34 +0200 >>>> Martin Kosek wrote: >>>> >>>>>>> I tested the patch (it works fine with Dogtag 10), but I got very >>>>>>> confused. >>>>>>> >>>>>>> What CA option are we setting? Signing algorithm or Key Algorithm? >>>>>>> I thought we are only setting Signing algorithm, but in that >>>>>>> case: >>>>>> >>>>>> We are setting key algorithm for the CA signing key. >>>>> >>>>> That did not made me any less confused... If I check for example >>>>> fields from certificate details from my browser, I see 2 algorithms >>>>> names: >>>>> >>>>> * Public Key Algorithm (RSA, ECC, ...) >>>>> * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, >>>>> something with ECC) >>>>> >>>>> In that world, "key algorithm" should really refer to the key PKI >>>>> algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes >>>>> come to play. >>>>> >>>>>>> - --ca-key-algorithm option should rather read >>>>>>> --ca-signing-key-algorithm >>>>>> >>>>>> If you want to emphasize that it is actually the algorithm used to >>>>>> sign the CA certificate, the option should read >>>>>> --ca-certificate-signature-algorithm, but I would rather stick to >>>>>> Dogtag terminology and keep the string "key algorithm" in the >>>>>> name. >>>>> >>>>> I still think for most people "key algorithm" refers to Public Key >>>>> algorithm. Rob or Simo, what is your take on this? >>>> >>>> If we are defining the signing algorithm the "signing" string should be >>>> somewhere in the option. >>>> Having just --key-algorithm is indeed confusing. >>>> >>>> Simo. >>>> >>> >>> My take is that the terminology should be chosen in line with >>> standards. The X.509 field is called `signatureAlgorithm' so >>> `--ca-certificate-signature-algorithm' makes sense to me. >>> Consistency with Dogtag terminology is a secondary consideration >>> considering FreeIPA users are unlikely to interact directly with >>> Dogtag much (especially during installation). >>> >>> Fraser >>> >> >> I think it actually sets both the key algorithm and the signature algorithm >> (you can't do a RSA signature with a EC key, etc.), that's probably why it is >> called "key algorithm" in Dogtag. > > Hm, you are right that the key algorithm is implied during signature algorithm > selection. But still, values SHA256withRSA and friends really denote just a > signature algorithm and the option should be named accordingly. > > Martin > Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-314.2-Allow-specifying-signing-algorithm-of-the-IPA-CA-cer.patch Type: text/x-patch Size: 5931 bytes Desc: not available URL: From mkosek at redhat.com Mon Sep 29 11:45:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 13:45:42 +0200 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <54293EF1.3050903@redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> <5429222A.9030406@redhat.com> <54293254.6020406@redhat.com> <54293EF1.3050903@redhat.com> Message-ID: <54294666.6020002@redhat.com> On 09/29/2014 01:13 PM, Jan Cholasta wrote: > Dne 29.9.2014 v 12:20 Martin Kosek napsal(a): >> On 09/29/2014 11:11 AM, Jan Cholasta wrote: >>> Dne 29.9.2014 v 05:16 Fraser Tweedale napsal(a): >>>> On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: >>>>> On Fri, 26 Sep 2014 13:54:34 +0200 >>>>> Martin Kosek wrote: >>>>> >>>>>>>> I tested the patch (it works fine with Dogtag 10), but I got very >>>>>>>> confused. >>>>>>>> >>>>>>>> What CA option are we setting? Signing algorithm or Key Algorithm? >>>>>>>> I thought we are only setting Signing algorithm, but in that >>>>>>>> case: >>>>>>> >>>>>>> We are setting key algorithm for the CA signing key. >>>>>> >>>>>> That did not made me any less confused... If I check for example >>>>>> fields from certificate details from my browser, I see 2 algorithms >>>>>> names: >>>>>> >>>>>> * Public Key Algorithm (RSA, ECC, ...) >>>>>> * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with RSA, >>>>>> something with ECC) >>>>>> >>>>>> In that world, "key algorithm" should really refer to the key PKI >>>>>> algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes >>>>>> come to play. >>>>>> >>>>>>>> - --ca-key-algorithm option should rather read >>>>>>>> --ca-signing-key-algorithm >>>>>>> >>>>>>> If you want to emphasize that it is actually the algorithm used to >>>>>>> sign the CA certificate, the option should read >>>>>>> --ca-certificate-signature-algorithm, but I would rather stick to >>>>>>> Dogtag terminology and keep the string "key algorithm" in the >>>>>>> name. >>>>>> >>>>>> I still think for most people "key algorithm" refers to Public Key >>>>>> algorithm. Rob or Simo, what is your take on this? >>>>> >>>>> If we are defining the signing algorithm the "signing" string should be >>>>> somewhere in the option. >>>>> Having just --key-algorithm is indeed confusing. >>>>> >>>>> Simo. >>>>> >>>> >>>> My take is that the terminology should be chosen in line with >>>> standards. The X.509 field is called `signatureAlgorithm' so >>>> `--ca-certificate-signature-algorithm' makes sense to me. >>>> Consistency with Dogtag terminology is a secondary consideration >>>> considering FreeIPA users are unlikely to interact directly with >>>> Dogtag much (especially during installation). >>>> >>>> Fraser >>>> >>> >>> I think it actually sets both the key algorithm and the signature algorithm >>> (you can't do a RSA signature with a EC key, etc.), that's probably why it is >>> called "key algorithm" in Dogtag. >> >> Hm, you are right that the key algorithm is implied during signature algorithm >> selection. But still, values SHA256withRSA and friends really denote just a >> signature algorithm and the option should be named accordingly. >> >> Martin >> > > Updated patch attached. > Looks good to me (and works good as well) - ACK. Pushed to master, ipa-4-1. (I just had to do a minor conflict resolution on master branch) Thanks, Martin From tbabej at redhat.com Mon Sep 29 11:52:47 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Sep 2014 13:52:47 +0200 Subject: [Freeipa-devel] [PATCH 0271] baseldap: Properly handle the case of renaming object to the In-Reply-To: <541A22E0.1040505@redhat.com> References: <5419A89F.9080105@redhat.com> <541A22E0.1040505@redhat.com> Message-ID: <5429480F.2090400@redhat.com> On 09/18/2014 02:10 AM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> When renaming a object to the same name, errors.EmptyModList is raised. >> This is not properly handled, and can cause other modifications in the >> LDAPUpdate command to be ignored. >> >> https://fedorahosted.org/freeipa/ticket/4548 > > Needs some tests... > > rob > Tests added. This patch is necessary for 4.1. -- 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-0271-2-baseldap-Properly-handle-the-case-of-renaming-object.patch Type: text/x-patch Size: 4245 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 29 12:21:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 14:21:42 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5425A843.1060007@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> Message-ID: <54294ED6.1000000@redhat.com> Dne 26.9.2014 v 19:54 Jan Cholasta napsal(a): > Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches fix various bugs and shortcomings in the CA >>>>> management and renewal code. Related tickets: >>>>> , >>>>> . >>>>> >>>>> (Patch 319 was originally posted at >>>>> .) >>>>> >>>>> >>>> >>>> Only two of the patches includes what ticket(s) they address. Most have >>>> the tersest of commit messages. If got more and more difficult to see >>>> why the changes were needed at all, as you'll see. >>> >>> Sorry, fixed (hopefully). >>> >>> Note that most of these patches fix stuff I didn't have time to fix >>> before I posted the original CA management patches, hence the missing >>> tickets. >> >> Well, the policy is that every commit should have a ticket. So I guess >> re-open the old tickets or open new ones. This will help someone in the >> future know the "why" of a patch. I've certainly been guilty > > OK, I will reopen the related tickets. > >> >> Here is a new set of reviews as trying to intermingle was making my eyes >> cross: >> >> 319: >> >> I guess I still don't understand why you can't pull the certs out of >> LDAP when creating this database. When this code runs, we know that the >> client is configured, so we have access to authentication. Why can't >> create_ipa_nssdb pull the certs directly? It seems more robust to me, >> and the code is already written in ipa-client-install to do this. > > Well, I don't understand why do you want them to be updated so much, as > nothing will break if they are not. Also try to imagine what would > happen if, say, 10k clients were updated at the same moment... > >> >> When adding the CA certificates to the temporary database it will report >> that a failure occurred, but not the exception: >> >> + except CalledProcessError, e: >> + root_logger.info("Failed to add CA to temporary NSS >> database.") >> + return CLIENT_INSTALL_ERROR >> >> Granted, NSS errors are often obtuse, but should it at least DEBUG log >> it? > > It is already logged in ipautil.run. The exception only says that the > command failed, there's no point in logging it. > >> >> 324, 325, 326: ACK >> >> 327: >> >> So the idea is to just mirror the certs and us the new db to know what >> was added? > > Exactly. > >> What if someone has the same nickname, different cert in the >> two databases? Is that too much of a corner case? > > IMO it is too much of a corner case, but I plan on adding a better > diff/patch algorithm in the future if it turns out to be a problem. > >> >> 328, 329, 330, 331: ACK >> >> As an aside, do you know why the global certs are seen by mod_nss? >> libnssckbi.so is symlinked into the directory (certutil -L -d >> /etc/httpd/alias -h all will show all the certs). > > I'm not sure why it is this way, but the module is linked to the NSS > database: > > $ sudo modutil -list -dbdir /etc/httpd/alias > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. Root Certs > library name: /etc/httpd/alias/libnssckbi.so > slots: 2 slots attached > status: loaded > > slot: /etc/pki/ca-trust/source > token: System Trust > > slot: /usr/share/pki/ca-trust-source > token: Default Trust > ----------------------------------------------------------- > >> >> 332-335 >> >> I think the naming and/or comments can be improved. For example, there >> are now 3 *retrieve_cert commands, all of which do slightly different >> things. All have external handlers (via the oddly named profile), but >> some are called internally as well. > > I have spent quite some time trying to come up with good names for them, > but I was not able to do so. Suggestions are welcome. > >> >> This is rather complex code: a command passes a call onto certmonger >> which then exuecutes the IPA CA helper... More documentation would >> definitely help a newcomer figure out how renewal, CA retrieval, etc. >> works. > > OK, I'll try to add some. > >> >> Not to be too pedantic but there is a lot of this in >> dogtag-ipa-ca-renew-agent-submit: >> >> if variable: OR if not variable: >> >> Where variable defaults to None. Shouldn't the test be: >> >> if variable is [not] None: > > This doesn't catch empty strings, which may occur in some of these checks. > >> >> 340: ACK >> >> Through some combination of ipa-certupdate and ipa-cacert-manage I seem >> to have hosed things up: >> >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >> execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 118, in run >> rc = self.renew() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 181, in renew >> return self.renew_self_signed(ca) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 193, in renew_self_signed >> self.resubmit_request(ca, 'caCACert') >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 315, in resubmit_request >> "please check the request manually" % self.request_id) >> >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >> ipa-cacert-manage command failed, exception: ScriptError: Error >> resubmitting certmonger request '20140909142830', please check the >> request manually >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Error >> resubmitting certmonger request '20140909142830', please check the >> request manually >> >> Incidentally, IMHO it should include the command to execute to check the >> request manually. > > Will add. > >> >> The CA is actually unreachable. Restarting it fixed things. I'll chalk >> this up to cosmic rays. > > OK. > >> >> Re-running ipa-cacert-manage renew was successful. > > Good. > >> >> I confirmed that the CA signing cert was updated in the dogtag database. >> >> I then ran ipa-certupdate to distribute this new CA cert around and none >> of the databases got the updated CA cert, nor did /etc/ipa/ca.crt. > > Can you see the new CA cert in cn=certificates,cn=ipa,cn=etc,$SUFFIX? > >> >> Still doing some functional testing. >> >> Unrelated to this: >> >> 9:freeipa-python-4.0.0GITf6875d4-0.################################# >> [100%] >> Update failed: Operations error: >> >> Seems to be related to this: >> >> 2014-09-25T19:28:22Z DEBUG --------------------------------------------- >> 2014-09-25T19:28:22Z DEBUG Final value after applying updates >> 2014-09-25T19:28:22Z DEBUG dn: cn=referential integrity >> postoperation,cn=plugins,cn=config >> 2014-09-25T19:28:22Z DEBUG cn: >> 2014-09-25T19:28:22Z DEBUG referential integrity postoperation >> 2014-09-25T19:28:22Z DEBUG objectClass: >> 2014-09-25T19:28:22Z DEBUG top >> 2014-09-25T19:28:22Z DEBUG nsSlapdPlugin >> 2014-09-25T19:28:22Z DEBUG extensibleObject >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginprecedence: >> 2014-09-25T19:28:22Z DEBUG 40 >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginPath: >> 2014-09-25T19:28:22Z DEBUG libreferint-plugin >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVersion: >> 2014-09-25T19:28:22Z DEBUG 1.3.3.2 >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg5: >> 2014-09-25T19:28:22Z DEBUG owner >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg4: >> 2014-09-25T19:28:22Z DEBUG uniquemember >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg7: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg6: >> 2014-09-25T19:28:22Z DEBUG seeAlso >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg1: >> 2014-09-25T19:28:22Z DEBUG >> /var/log/dirsrv/slapd-GREYOAK-COM/referint >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg0: >> 2014-09-25T19:28:22Z DEBUG 0 >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg3: >> 2014-09-25T19:28:22Z DEBUG member >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg2: >> 2014-09-25T19:28:22Z DEBUG 0 >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg9: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg8: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginInitfunc: >> 2014-09-25T19:28:22Z DEBUG referint_postop_init >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginexcludeentryscope: >> 2014-09-25T19:28:22Z DEBUG cn=provisioning,dc=greyoak,dc=com >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg11: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg10: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg13: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg12: >> 2014-09-25T19:28:22Z DEBUG nsslapd-plugin-depends-on-type: >> 2014-09-25T19:28:22Z DEBUG database >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginVendor: >> 2014-09-25T19:28:22Z DEBUG 389 Project >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg17: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg16: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg18: >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginType: >> 2014-09-25T19:28:22Z DEBUG betxnpostoperation >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginDescription: >> 2014-09-25T19:28:22Z DEBUG referential integrity plugin >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginentryscope: >> 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginEnabled: >> 2014-09-25T19:28:22Z DEBUG on >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginId: >> 2014-09-25T19:28:22Z DEBUG referint >> 2014-09-25T19:28:22Z DEBUG nsslapd-plugincontainerscope: >> 2014-09-25T19:28:22Z DEBUG dc=greyoak,dc=com >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg15: >> 2014-09-25T19:28:22Z DEBUG referint-membership-attr: >> 2014-09-25T19:28:22Z DEBUG manager >> 2014-09-25T19:28:22Z DEBUG secretary >> 2014-09-25T19:28:22Z DEBUG memberuser >> 2014-09-25T19:28:22Z DEBUG memberhost >> 2014-09-25T19:28:22Z DEBUG sourcehost >> 2014-09-25T19:28:22Z DEBUG memberservice >> 2014-09-25T19:28:22Z DEBUG managedby >> 2014-09-25T19:28:22Z DEBUG memberallowcmd >> 2014-09-25T19:28:22Z DEBUG memberdenycmd >> 2014-09-25T19:28:22Z DEBUG ipasudorunas >> 2014-09-25T19:28:22Z DEBUG ipasudorunasgroup >> 2014-09-25T19:28:22Z DEBUG ipatokenradiusconfiglink >> 2014-09-25T19:28:22Z DEBUG nsslapd-pluginarg14: >> 2014-09-25T19:28:22Z DEBUG [(1, u'nsslapd-pluginarg16', None), (1, >> u'nsslapd-pluginarg7', None), (1, u'nsslapd-pluginarg9', None), (1, >> u'nsslapd-pluginarg8', None), (1, u'nsslapd-pluginarg11', None), (1, >> u'nsslapd-pluginarg10', None), (1, u'nsslapd-pluginarg13', None), (1, >> u'nsslapd-pluginarg12', None), (1, u'nsslapd-pluginarg17', None), (1, >> u'nsslapd-pluginarg18', None), (1, u'nsslapd-pluginarg15', None), (2, >> u'referint-membership-attr', ['sourcehost', 'memberallowcmd', >> 'memberdenycmd', 'memberuser', 'managedby', 'manager', 'memberservice', >> 'ipasudorunas', 'ipasudorunasgroup', 'secretary', 'memberhost', >> 'ipatokenradiusconfiglink']), (1, u'nsslapd-pluginarg14', None)] >> 2014-09-25T19:28:22Z DEBUG Live 1, updated 1 >> 2014-09-25T19:28:22Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >> {'desc': 'Operations error'} >> 2014-09-25T19:28:22Z ERROR Update failed: Operations error: >> Updated rebased patches attached, now with ticket URLs. I have decided to drop 332-335 for now, since I won't be able to finish them before the release. We can continue with them later. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319.3-Introduce-NSS-database-etc-ipa-nssdb.patch Type: text/x-patch Size: 16042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-324.2-Move-NSSDatabase-from-ipaserver.certs-to-ipapython.c.patch Type: text/x-patch Size: 20092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-325.2-Add-NSSDatabase.has_nickname-for-checking-nickname-p.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-326.2-Use-NSSDatabase-instead-of-direct-certutil-calls-in-.patch Type: text/x-patch Size: 9212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-327.2-Use-etc-ipa-nssdb-to-get-nicknames-of-IPA-certs-inst.patch Type: text/x-patch Size: 8895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-328.2-Check-if-IPA-client-is-configured-in-ipa-certupdate.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-329.2-Get-server-hostname-from-jsonrpc_uri-in-ipa-certupda.patch Type: text/x-patch Size: 1209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-330.2-Remove-ipa-ca.crt-from-systemwide-CA-store-on-client.patch Type: text/x-patch Size: 4461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-331.2-Fix-certmonger.wait_for_request.patch Type: text/x-patch Size: 960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-340.1-Fix-certmonger-search-for-the-CA-cert-in-ipa-certupd.patch Type: text/x-patch Size: 1897 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 29 12:44:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 14:44:49 +0200 Subject: [Freeipa-devel] [PATCH 0271] baseldap: Properly handle the case of renaming object to the In-Reply-To: <5429480F.2090400@redhat.com> References: <5419A89F.9080105@redhat.com> <541A22E0.1040505@redhat.com> <5429480F.2090400@redhat.com> Message-ID: <54295441.9080603@redhat.com> Dne 29.9.2014 v 13:52 Tomas Babej napsal(a): > On 09/18/2014 02:10 AM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> When renaming a object to the same name, errors.EmptyModList is raised. >>> This is not properly handled, and can cause other modifications in the >>> LDAPUpdate command to be ignored. >>> >>> https://fedorahosted.org/freeipa/ticket/4548 >> >> Needs some tests... >> >> rob >> > > Tests added. This patch is necessary for 4.1. ACK. -- Jan Cholasta From ssorce at redhat.com Mon Sep 29 12:48:59 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 29 Sep 2014 08:48:59 -0400 Subject: [Freeipa-devel] [PATCH] 314 Allow specifying key algorithm of the IPA CA cert in ipa-server-install In-Reply-To: <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> References: <53E1DFD2.60307@redhat.com> <53E2230D.6090908@redhat.com> <53E25526.4080109@redhat.com> <54214161.4080900@redhat.com> <542539B8.6030701@redhat.com> <542550E6.6010806@redhat.com> <542553FA.4080400@redhat.com> <20140926104416.44548b7c@willson.usersys.redhat.com> <20140929031607.GG5346@dhcp-40-8.bne.redhat.com> Message-ID: <20140929084859.143b48cc@willson.usersys.redhat.com> On Mon, 29 Sep 2014 13:16:07 +1000 Fraser Tweedale wrote: > On Fri, Sep 26, 2014 at 10:44:16AM -0400, Simo Sorce wrote: > > On Fri, 26 Sep 2014 13:54:34 +0200 > > Martin Kosek wrote: > > > > > >> I tested the patch (it works fine with Dogtag 10), but I got > > > >> very confused. > > > >> > > > >> What CA option are we setting? Signing algorithm or Key > > > >> Algorithm? I thought we are only setting Signing algorithm, > > > >> but in that case: > > > > > > > > We are setting key algorithm for the CA signing key. > > > > > > That did not made me any less confused... If I check for example > > > fields from certificate details from my browser, I see 2 > > > algorithms names: > > > > > > * Public Key Algorithm (RSA, ECC, ...) > > > * Certificate Signature Algorithm (SHA-1 with RSA, SHA-256 with > > > RSA, something with ECC) > > > > > > In that world, "key algorithm" should really refer to the key PKI > > > algorithm, i.e. RSA, ECC, ... Signature algorithms is where hashes > > > come to play. > > > > > > >> - --ca-key-algorithm option should rather read > > > >> --ca-signing-key-algorithm > > > > > > > > If you want to emphasize that it is actually the algorithm used > > > > to sign the CA certificate, the option should read > > > > --ca-certificate-signature-algorithm, but I would rather stick > > > > to Dogtag terminology and keep the string "key algorithm" in the > > > > name. > > > > > > I still think for most people "key algorithm" refers to Public Key > > > algorithm. Rob or Simo, what is your take on this? > > > > If we are defining the signing algorithm the "signing" string > > should be somewhere in the option. > > Having just --key-algorithm is indeed confusing. > > > > Simo. > > > > My take is that the terminology should be chosen in line with > standards. The X.509 field is called `signatureAlgorithm' so > `--ca-certificate-signature-algorithm' makes sense to me. > Consistency with Dogtag terminology is a secondary consideration > considering FreeIPA users are unlikely to interact directly with > Dogtag much (especially during installation). +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Sep 29 13:05:31 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Sep 2014 09:05:31 -0400 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5425A843.1060007@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> Message-ID: <5429591B.5060700@redhat.com> Jan Cholasta wrote: > Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches fix various bugs and shortcomings in the CA >>>>> management and renewal code. Related tickets: >>>>> , >>>>> . >>>>> >>>>> (Patch 319 was originally posted at >>>>> .) >>>>> >>>>> >>>> >>>> Only two of the patches includes what ticket(s) they address. Most have >>>> the tersest of commit messages. If got more and more difficult to see >>>> why the changes were needed at all, as you'll see. >>> >>> Sorry, fixed (hopefully). >>> >>> Note that most of these patches fix stuff I didn't have time to fix >>> before I posted the original CA management patches, hence the missing >>> tickets. >> >> Well, the policy is that every commit should have a ticket. So I guess >> re-open the old tickets or open new ones. This will help someone in the >> future know the "why" of a patch. I've certainly been guilty > > OK, I will reopen the related tickets. > >> >> Here is a new set of reviews as trying to intermingle was making my eyes >> cross: >> >> 319: >> >> I guess I still don't understand why you can't pull the certs out of >> LDAP when creating this database. When this code runs, we know that the >> client is configured, so we have access to authentication. Why can't >> create_ipa_nssdb pull the certs directly? It seems more robust to me, >> and the code is already written in ipa-client-install to do this. > > Well, I don't understand why do you want them to be updated so much, as > nothing will break if they are not. Also try to imagine what would > happen if, say, 10k clients were updated at the same moment... What's the point of a database missing certificates? >> >> When adding the CA certificates to the temporary database it will report >> that a failure occurred, but not the exception: >> >> + except CalledProcessError, e: >> + root_logger.info("Failed to add CA to temporary NSS >> database.") >> + return CLIENT_INSTALL_ERROR >> >> Granted, NSS errors are often obtuse, but should it at least DEBUG log >> it? > > It is already logged in ipautil.run. The exception only says that the > command failed, there's no point in logging it. > >> >> 324, 325, 326: ACK >> >> 327: >> >> So the idea is to just mirror the certs and us the new db to know what >> was added? > > Exactly. > >> What if someone has the same nickname, different cert in the >> two databases? Is that too much of a corner case? > > IMO it is too much of a corner case, but I plan on adding a better > diff/patch algorithm in the future if it turns out to be a problem. The result could be a deleted cert, that was my concern. It does seem to be a rather slim case. >> >> 328, 329, 330, 331: ACK >> >> As an aside, do you know why the global certs are seen by mod_nss? >> libnssckbi.so is symlinked into the directory (certutil -L -d >> /etc/httpd/alias -h all will show all the certs). > > I'm not sure why it is this way, but the module is linked to the NSS > database: > > $ sudo modutil -list -dbdir /etc/httpd/alias > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. Root Certs > library name: /etc/httpd/alias/libnssckbi.so > slots: 2 slots attached > status: loaded > > slot: /etc/pki/ca-trust/source > token: System Trust > > slot: /usr/share/pki/ca-trust-source > token: Default Trust > ----------------------------------------------------------- Sorry, that was a rhetorical question. Presumably NSS hunts around for libnssckbi.so but it doesn't seem to look very hard, except that it does seem to find it if it exists in the same directory as the DB, so I symlink it in. I think mod_nss is probably the only thing that does this, but it can make things rather interesting (for good and bad) dealing with global certs. > >> >> 332-335 >> >> I think the naming and/or comments can be improved. For example, there >> are now 3 *retrieve_cert commands, all of which do slightly different >> things. All have external handlers (via the oddly named profile), but >> some are called internally as well. > > I have spent quite some time trying to come up with good names for them, > but I was not able to do so. Suggestions are welcome. > >> >> This is rather complex code: a command passes a call onto certmonger >> which then exuecutes the IPA CA helper... More documentation would >> definitely help a newcomer figure out how renewal, CA retrieval, etc. >> works. > > OK, I'll try to add some. > >> >> Not to be too pedantic but there is a lot of this in >> dogtag-ipa-ca-renew-agent-submit: >> >> if variable: OR if not variable: >> >> Where variable defaults to None. Shouldn't the test be: >> >> if variable is [not] None: > > This doesn't catch empty strings, which may occur in some of these checks. Gah, ok then, I'd definitely document that as it's a rather major minefield. > >> >> 340: ACK >> >> Through some combination of ipa-certupdate and ipa-cacert-manage I seem >> to have hosed things up: >> >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >> execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 118, in run >> rc = self.renew() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 181, in renew >> return self.renew_self_signed(ca) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 193, in renew_self_signed >> self.resubmit_request(ca, 'caCACert') >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 315, in resubmit_request >> "please check the request manually" % self.request_id) >> >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >> ipa-cacert-manage command failed, exception: ScriptError: Error >> resubmitting certmonger request '20140909142830', please check the >> request manually >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Error >> resubmitting certmonger request '20140909142830', please check the >> request manually >> >> Incidentally, IMHO it should include the command to execute to check the >> request manually. > > Will add. > >> >> The CA is actually unreachable. Restarting it fixed things. I'll chalk >> this up to cosmic rays. > > OK. > >> >> Re-running ipa-cacert-manage renew was successful. > > Good. > >> >> I confirmed that the CA signing cert was updated in the dogtag database. >> >> I then ran ipa-certupdate to distribute this new CA cert around and none >> of the databases got the updated CA cert, nor did /etc/ipa/ca.crt. > > Can you see the new CA cert in cn=certificates,cn=ipa,cn=etc,$SUFFIX? No, only the original CA cert is there which explains why the helpers didn't update things. rob From mkosek at redhat.com Mon Sep 29 13:26:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 15:26:58 +0200 Subject: [Freeipa-devel] [PATCH 0271] baseldap: Properly handle the case of renaming object to the In-Reply-To: <54295441.9080603@redhat.com> References: <5419A89F.9080105@redhat.com> <541A22E0.1040505@redhat.com> <5429480F.2090400@redhat.com> <54295441.9080603@redhat.com> Message-ID: <54295E22.9040005@redhat.com> On 09/29/2014 02:44 PM, Jan Cholasta wrote: > Dne 29.9.2014 v 13:52 Tomas Babej napsal(a): >> On 09/18/2014 02:10 AM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> Hi, >>>> >>>> When renaming a object to the same name, errors.EmptyModList is raised. >>>> This is not properly handled, and can cause other modifications in the >>>> LDAPUpdate command to be ignored. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4548 >>> >>> Needs some tests... >>> >>> rob >>> >> >> Tests added. This patch is necessary for 4.1. > > ACK. Pushed to: master: d83af7d38d65dfc50c70cb4ecf48f5c4c57d6979 ipa-4-1: 0cf2dbc44575e03cb630ac8d18ed59464abfd2b3 Martin From jcholast at redhat.com Mon Sep 29 13:35:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 15:35:12 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <5429591B.5060700@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> Message-ID: <54296010.1000705@redhat.com> Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>> management and renewal code. Related tickets: >>>>>> , >>>>>> . >>>>>> >>>>>> (Patch 319 was originally posted at >>>>>> .) >>>>>> >>>>>> >>>>> >>>>> Only two of the patches includes what ticket(s) they address. Most have >>>>> the tersest of commit messages. If got more and more difficult to see >>>>> why the changes were needed at all, as you'll see. >>>> >>>> Sorry, fixed (hopefully). >>>> >>>> Note that most of these patches fix stuff I didn't have time to fix >>>> before I posted the original CA management patches, hence the missing >>>> tickets. >>> >>> Well, the policy is that every commit should have a ticket. So I guess >>> re-open the old tickets or open new ones. This will help someone in the >>> future know the "why" of a patch. I've certainly been guilty >> >> OK, I will reopen the related tickets. >> >>> >>> Here is a new set of reviews as trying to intermingle was making my eyes >>> cross: >>> >>> 319: >>> >>> I guess I still don't understand why you can't pull the certs out of >>> LDAP when creating this database. When this code runs, we know that the >>> client is configured, so we have access to authentication. Why can't >>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>> and the code is already written in ipa-client-install to do this. >> >> Well, I don't understand why do you want them to be updated so much, as >> nothing will break if they are not. Also try to imagine what would >> happen if, say, 10k clients were updated at the same moment... > > What's the point of a database missing certificates? It won't be missing any certificates if /etc/pki/nssdb was not missing any certificates before the update. As I said, the update will not break anything. It will not fix anything either, but I don't think this kind of fixing should be done during client RPM upgrade. It is not consistent with anything else we do during client RPM upgrade, it does not scale well and it just does not feel right to me in overall. > >>> >>> When adding the CA certificates to the temporary database it will report >>> that a failure occurred, but not the exception: >>> >>> + except CalledProcessError, e: >>> + root_logger.info("Failed to add CA to temporary NSS >>> database.") >>> + return CLIENT_INSTALL_ERROR >>> >>> Granted, NSS errors are often obtuse, but should it at least DEBUG log >>> it? >> >> It is already logged in ipautil.run. The exception only says that the >> command failed, there's no point in logging it. >> >>> >>> 324, 325, 326: ACK >>> >>> 327: >>> >>> So the idea is to just mirror the certs and us the new db to know what >>> was added? >> >> Exactly. >> >>> What if someone has the same nickname, different cert in the >>> two databases? Is that too much of a corner case? >> >> IMO it is too much of a corner case, but I plan on adding a better >> diff/patch algorithm in the future if it turns out to be a problem. > > The result could be a deleted cert, that was my concern. It does seem to > be a rather slim case. > >>> >>> 328, 329, 330, 331: ACK >>> >>> As an aside, do you know why the global certs are seen by mod_nss? >>> libnssckbi.so is symlinked into the directory (certutil -L -d >>> /etc/httpd/alias -h all will show all the certs). >> >> I'm not sure why it is this way, but the module is linked to the NSS >> database: >> >> $ sudo modutil -list -dbdir /etc/httpd/alias >> >> Listing of PKCS #11 Modules >> ----------------------------------------------------------- >> 1. NSS Internal PKCS #11 Module >> slots: 2 slots attached >> status: loaded >> >> slot: NSS Internal Cryptographic Services >> token: NSS Generic Crypto Services >> >> slot: NSS User Private Key and Certificate Services >> token: NSS Certificate DB >> >> 2. Root Certs >> library name: /etc/httpd/alias/libnssckbi.so >> slots: 2 slots attached >> status: loaded >> >> slot: /etc/pki/ca-trust/source >> token: System Trust >> >> slot: /usr/share/pki/ca-trust-source >> token: Default Trust >> ----------------------------------------------------------- > > Sorry, that was a rhetorical question. Presumably NSS hunts around for > libnssckbi.so but it doesn't seem to look very hard, except that it does > seem to find it if it exists in the same directory as the DB, so I > symlink it in. I think mod_nss is probably the only thing that does > this, but it can make things rather interesting (for good and bad) > dealing with global certs. > >> >>> >>> 332-335 >>> >>> I think the naming and/or comments can be improved. For example, there >>> are now 3 *retrieve_cert commands, all of which do slightly different >>> things. All have external handlers (via the oddly named profile), but >>> some are called internally as well. >> >> I have spent quite some time trying to come up with good names for them, >> but I was not able to do so. Suggestions are welcome. >> >>> >>> This is rather complex code: a command passes a call onto certmonger >>> which then exuecutes the IPA CA helper... More documentation would >>> definitely help a newcomer figure out how renewal, CA retrieval, etc. >>> works. >> >> OK, I'll try to add some. >> >>> >>> Not to be too pedantic but there is a lot of this in >>> dogtag-ipa-ca-renew-agent-submit: >>> >>> if variable: OR if not variable: >>> >>> Where variable defaults to None. Shouldn't the test be: >>> >>> if variable is [not] None: >> >> This doesn't catch empty strings, which may occur in some of these checks. > > Gah, ok then, I'd definitely document that as it's a rather major minefield. OK. > >> >>> >>> 340: ACK >>> >>> Through some combination of ipa-certupdate and ipa-cacert-manage I seem >>> to have hosed things up: >>> >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'CA_UNREACHABLE', variant_level=1) >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >>> execute >>> return_value = self.run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>> >>> line 118, in run >>> rc = self.renew() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>> >>> line 181, in renew >>> return self.renew_self_signed(ca) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>> >>> line 193, in renew_self_signed >>> self.resubmit_request(ca, 'caCACert') >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>> >>> line 315, in resubmit_request >>> "please check the request manually" % self.request_id) >>> >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>> ipa-cacert-manage command failed, exception: ScriptError: Error >>> resubmitting certmonger request '20140909142830', please check the >>> request manually >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Error >>> resubmitting certmonger request '20140909142830', please check the >>> request manually >>> >>> Incidentally, IMHO it should include the command to execute to check the >>> request manually. >> >> Will add. >> >>> >>> The CA is actually unreachable. Restarting it fixed things. I'll chalk >>> this up to cosmic rays. >> >> OK. >> >>> >>> Re-running ipa-cacert-manage renew was successful. >> >> Good. >> >>> >>> I confirmed that the CA signing cert was updated in the dogtag database. >>> >>> I then ran ipa-certupdate to distribute this new CA cert around and none >>> of the databases got the updated CA cert, nor did /etc/ipa/ca.crt. >> >> Can you see the new CA cert in cn=certificates,cn=ipa,cn=etc,$SUFFIX? > > No, only the original CA cert is there which explains why the helpers > didn't update things. The LDAP update happens in renew_ca_cert. Are there any relevant errors in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the master entry of the master where you run ipa-cacert-manage renew? > > rob > -- Jan Cholasta From edewata at redhat.com Mon Sep 29 14:19:33 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 29 Sep 2014 09:19:33 -0500 Subject: [Freeipa-devel] [PATCH] 757 webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types In-Reply-To: <54290CE1.9040808@redhat.com> References: <54229A46.9040409@redhat.com> <54290CE1.9040808@redhat.com> Message-ID: <54296A75.3050205@redhat.com> On 9/29/2014 2:40 AM, Petr Vobornik wrote: > On 24.9.2014 12:17, Petr Vobornik wrote: >> webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types >> >> They are not supported by API. > > Forgot to attach patch... ACK. -- Endi S. Dewata From tbabej at redhat.com Mon Sep 29 14:30:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Sep 2014 16:30:04 +0200 Subject: [Freeipa-devel] [PATCHES 247-279] ID views - management part In-Reply-To: <54212A37.3050503@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> <54212A37.3050503@redhat.com> Message-ID: <54296CEC.40906@redhat.com> Thanks for the review. Sending updated patchset, responses are inline. On 09/23/2014 10:07 AM, Petr Viktorin wrote: > On 09/16/2014 01:21 PM, Tomas Babej wrote: >> Petr, >> >> thanks for the review, your input is, as always, much to the point. >> >> My responses are inline. Also, I'm attaching a new patchset, rebased on >> master, please, have a look at that. >> >> Most of the patches have at least minor changes, since I rebased another >> ~15 patches into this patchset, and there are additional 9 patches on >> top. Patch 254 was deprecated, as we decided to go with more explicit >> way of having two separate commands for user and group ID overrides. >> >> Also, the test suite (around 80 tests) for ID views is attached - patch >> 270. It depends on patch 269, sent in separate thread. >> >> Tomas >> >> On 09/10/2014 03:10 PM, Petr Viktorin wrote: >>> On 08/01/2014 12:30 PM, Tomas Babej wrote: >>>> 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. >>>> >>> >>> Not tested yet, but here are my comments on the patches: >>> > > 0247 looks good > > In 0248 you deleted a newline at EOF in 71-idviews.update > > 0249 looks good > >>> >>> 0250: >>> With so many names imported from one module, I find it more readable >>> to `from ipalib.plugins import baseldap`, and use qualified names >>> later. Same in the 2 other patches. >>> This is personal preference/tip, feel free to disagree :) >> >> I was just trying to be consistent here, rest of the IPA plugins seem to >> use non-qualified names for plugins. Even tough the main reason is >> probably that thay use evil star imports :) Let's keep it this way >> for now. > > Yes, the rest of the plugins are using star imports; no consistency to > be kept here. > I think that after these patches nobody will touch it again, so "for > now" is basically forever. > > 0521 looks good > >>> 0252: > >>> The pattern_errmsg in idoverride's uid should be expanded to fully >>> describe the pattern. >> >> If we want to expand it, then it should be corrected in user.py plugin >> too (I have taken it from there). Still, it's a tradeoff between >> conciseness and and exactness, do we really want to specify that user >> login may be at most 253 letters long or the $ character may only be >> used as terminal one? Or the fact that - can't be used at the beggining? >> This is probably the way it was since forever in user plugin. > > I think the message should at be free of false positives. Using e.e. > "-test-name-" and getting back "may only include letters, numbers, _, > -, . and $" would be extremely frustrating. > > Should I file a ticket? > > 0253 looks good > 0255-0256 looks good > >>> 0258: >>> idview_apply: typo in hostgroup doc, should be "hosts to apply the ID >>> view to" and "after running the idview-apply command". >>> Typos in output params, should be e.g. "this ID view" >> >> Fixed the second and third complaint ( IMHO this is clear from context, >> but I added "this" to be explicit), I'm not so sure about the first one >> though. Can we get a native speaker input on that? > > Actually both just need an article, doesn't matter much if it's "the" > or "this". > >>> >>> By subclassing idview_unapply from idview_apply you're violating >>> Liskov's substitution principle. Make a common base class for them. >> >> Done. > > In the wrong patch, it seems :) > >>> >>> 0259: >>> show_id_overrides: cn is a MUST attribute in ipa*Override; use >>> view.single_value['cn'] instead of get(). In enumerate_hosts, is None >>> okay if cn is missing? >> >> This was actually an error, fixed in updated version of patches. New >> code uses 'ipaanchoruuid' (which is a MUST) and converts it (with your >> objections addressed.) > > If it's MUST, use simply `single_value['ipaanchoruuid']` instead of > get(). > Yes, this is fixed in a later patch. > > 0260: > The get() method on dict-like objects returns None (or a given > default) if the item is missing. > If sAMAccountName is MUST, use regular dict item access. > If sAMAccountName is MAY, then you're not handling the None you might > get. It is a must, fixed in 260. > > Also look at the other uses of get() to see if you're doing the right > thing. Patch 276 makes sure this does not happen. > > I've looked at help(pysss_nss_idmap.getnamebysid). Shouldn't you use > pysss_nss_idmap.NAME_KEY and TYPE_KEY? Right. Also, there forgotten debubugging comment somehow lurked in, I got that fixed too. > > > 0261: > Again you're using get() on MUST attributes. Fixed. > > 0262: > ipalib/constants.py - No newline at end of file Fixed. > > Is IPA_ANCHOR_PREFIX and SID_ANCHOR_PREFIX to be used outside > idviews.py? Do we want it in constants? > >> + if anchor.startswith(IPA_ANCHOR_PREFIX): >> + uuid = anchor.split(IPA_ANCHOR_PREFIX)[1].strip() I thought of constants.py as a global store for all plugin constants. > > This is a dangerous idiom to use for removing a prefix, since it will > silently give wrong results if the string contains the prefix. Prefer: > anchor[len(IPA_ANCHOR_PREFIX):] > Same with SID_ANCHOR_PREFIX below. This cannot happen unless someone edits the raw LDAP directly, but still, you're correct here, better not get used to using/seeing this. Fixed in later patch, thanks. > > In get_dn, why do you resolve only the last key? You can only pass two arguments to these commands, where the first one is the name of the view, which you don't want to resolve. > > In set_anchoruuid_from_dn, an entry is a dict of lists, use either > single_value or put the dn[0].value in brackets. This actually needs to stay this way, since LDAPUpdate expects a single value, not a list. I added a comment. > > 0263: > > Note that permission_filter_objectclasses are ORed together; I don't > think you want ipaOverrideAnchor there. > Right, fixed. > You forgot to regenerate ACI.txt in this patch. > True, fixed. > 0264 looks OK > > 0265: > > Instead of: > >> + objectclass, name_attr = ( >> + ('posixaccount', 'uid') >> + if self.override_object == 'user' else >> + ('ipausergroup', 'cn') >> + ) > > prefer: > > objectclass, name_attr = { > 'user': ('posixaccount', 'uid'), > 'group': ('ipausergroup', 'cn'), > }[self.override_object] > > This generalizes better to more cases, and fails loudly on bad input. > Fixed. > You're misusing get() again. > Fixed. > 0266: > > To build strings, prefer formatting: > return '%s%s:%s' % (IPA_ANCHOR_PREFIX, domain, uuid) > rather than adding the separator to one of the strings and concatenating. > Fixed. > Instead of: > anchor.split(':')[-1] > prefer: > anchor.rpartition(':')[-1] > which does less work. > What is an ocean but a multitude of drops :) Fixed. > 0267: > resolve_object_to_anchor: For the error message, use > Object[...].handle_not_found() > Fixed. > 0268 looks good > > 0270: > get_idoverride_dn: Use re.escape() when inserting literal strings in > regexes. > Fixed, thanks. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0279-3-idviews-Catch-errors-on-unsuccessful-AD-object-looku.patch Type: text/x-patch Size: 2025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0278-3-idviews-Make-sure-the-dict.get-method-is-not-abused-.patch Type: text/x-patch Size: 2229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0277-3-idviews-Handle-Default-Trust-View-properly-in-the-fr.patch Type: text/x-patch Size: 3008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0276-3-idviews-Add-Default-Trust-View-as-part-of-adtrustins.patch Type: text/x-patch Size: 3434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0273-3-idviews-Update-the-referential-plugin-config-to-watc.patch Type: text/x-patch Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0275-3-idviews-Make-description-optional-for-the-ID-View-ob.patch Type: text/x-patch Size: 2826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0274-3-idviews-Fix-casing-of-ID-Views-to-be-consistent.patch Type: text/x-patch Size: 7220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0272-3-idviews-Add-ipaOriginalUid.patch Type: text/x-patch Size: 10765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0268-3-idviews-Resolve-anchors-to-object-names-in-idview-sh.patch Type: text/x-patch Size: 10987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0267-3-idviews-Raise-NotFound-errors-if-object-to-override-.patch Type: text/x-patch Size: 1541 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0266-3-idviews-Change-format-of-IPA-anchor-to-include-domai.patch Type: text/x-patch Size: 2479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0265-3-idviews-Alter-idoverride-methods-to-work-with-splitt.patch Type: text/x-patch Size: 5094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0264-3-idviews-Split-the-idoverride-commands-into-iduserove.patch Type: text/x-patch Size: 17663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0263-3-idviews-Split-the-idoverride-object-into-iduseroverr.patch Type: text/x-patch Size: 6901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0261-3-trusts-Add-conversion-from-SID-to-object-name.patch Type: text/x-patch Size: 3139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0262-3-idviews-Support-specifying-object-names-instead-of-r.patch Type: text/x-patch Size: 7782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0270-3-ipatests-Add-xmlrpc-tests-for-idviews-plugin.patch Type: text/x-patch Size: 49473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0259-3-idviews-Extend-idview-show-command-to-display-assign.patch Type: text/x-patch Size: 8412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0256-3-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-3-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-3-idviews-Add-ipa-idview-apply-and-idview-unapply-comm.patch Type: text/x-patch Size: 9584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0255-3-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-0253-3-idvies-Add-managed-permissions-for-idview-and-idover.patch Type: text/x-patch Size: 4094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0251-3-ipalib-PEP8-fixes-for-host-plugin.patch Type: text/x-patch Size: 6958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0252-3-idviews-Create-basic-idview-plugin-structure.patch Type: text/x-patch Size: 17680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0249-3-idviews-Add-ipaAssignedIDVIew-reference-to-the-host-.patch Type: text/x-patch Size: 9760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0250-3-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-0248-3-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-0247-3-idviews-Add-necessary-schema-for-the-ID-views.patch Type: text/x-patch Size: 4751 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 29 14:32:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Sep 2014 16:32:03 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <5425A501.4030909@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> <5425A501.4030909@redhat.com> Message-ID: <54296D63.8010505@redhat.com> Dne 26.9.2014 v 19:40 Jan Cholasta napsal(a): > Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): >> Petr Viktorin wrote: >>> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> and . >>>> >>>> (Note that design page for this is TBD.) >> >> Isn't this backwards then? >> >>> >>> 336: >>> >>> Instead of >>> len(data[:match.start() + 1].splitlines()) >>> you can do >>> data.count('\n', 0, match.start()) + 1 > > Unfortunately '\n' is not good enough, we have to check for '\r\n' and > '\r' as well, hence the use of splitlines. > >>> >>> 337: >>> The --external_cert_file and --external_ca_file options for >>> ipa-ca-install are removed, do we really want to do that? Shouldn't they >>> be deprecated instead? >> >> +1 >> >>> >>> Same for --external-ca-file in ipa-cacert-manage. >> >> +1 > > IMO it's OK to just remove them, as they were added during 4.1 > development and are not available in any released version of IPA. > > >> >> I can't say I'm a fan of forcing users to concatenate cert files. > > All the --*-cert-file options may be given multiple times. > >> >>> >>> 338: Looks OK >>> 339: Looks OK >>> >>> Could you add some docstrings to the functions you add? Sometimes it's >>> harder than necessary to decipher what they do and what the >>> arguments/return values mean exactly. > > Sure. > >>> >>> There is no user-visible documentation on what file types are >>> expected/supported. It would be good to add this to the man pages, or >>> the --help. > > Added. > >> >> I also wonder if the detection code should be changed. It basically now >> tries a slew of different mechanisms one at a time rather than trying to >> identify the type of file and using that one. It may not be possible in >> all cases but you could at least start by looking for ^----- to know it >> is a text file and go from there, otherwise step through the binary >> formats. > > Rearranged the code so that text files are tried first. > >> >>> >>> >>> >>> In external CA, the error message when specifying a certificate but not >>> the CA could be improved: >>> $ ipa-server-install --external_cert_file >>> ~/p/Certificate_Authority_8.cer >>> ... >>> CA certificate CN=Certificate Authority,O=IDM.LAB.ENG.BRQ.REDHAT.COM in >>> /home/pviktori/p/Certificate_Authority_8.cer is not valid: >>> (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized. > > Fixed. > >>> >>> >>> >>> For CA-less, I used a combination of files with which server >>> installation went well, but replica-install failed halfway through: >>> >>> Console: >>> ... >>> [16/36]: creating indices >>> [17/36]: enabling referential integrity plugin >>> [18/36]: configuring ssl for ds instance >>> [error] RuntimeError: incorrect password for pkcs#12 file >>> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >>> >>> Log tail: >>> >>> 2014-09-26T15:05:43Z DEBUG Starting external process >>> 2014-09-26T15:05:43Z DEBUG args='/usr/bin/pk12util' '-d' >>> '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/' '-i' >>> '/tmp/tmp2vEWX_ipa/realm_info/dscert.p12' '-k' >>> '/etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM//pwdfile.txt' '-v' '-w' >>> '/dev/stdin' >>> 2014-09-26T15:05:43Z DEBUG Process finished, return code=17 >>> 2014-09-26T15:05:43Z DEBUG stdout= >>> 2014-09-26T15:05:43Z DEBUG stderr=pk12util: PKCS12 decode not verified: >>> SEC_ERROR_BAD_PASSWORD: The security password entered is incorrect. >>> >>> 2014-09-26T15:05:43Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 370, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 360, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>> 600, in __enable_ssl >>> trust_flags=trust_flags) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 1030, in create_from_pkcs12 >>> self.import_pkcs12(pkcs12_fname, pkcs12_passwd) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 971, in import_pkcs12 >>> pkcs12_passwd=pkcs12_passwd) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 191, in import_pkcs12 >>> pkcs12_filename) >>> RuntimeError: incorrect password for pkcs#12 file >>> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >>> >>> 2014-09-26T15:05:43Z DEBUG [error] RuntimeError: incorrect password >>> for pkcs#12 file /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >>> 2014-09-26T15:05:43Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 644, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-replica-install", line 677, in main >>> ds = install_replica_ds(config) >>> >>> File "/sbin/ipa-replica-install", line 190, in install_replica_ds >>> ca_file=config.dir + "/ca.crt", >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>> 354, in create_replica >>> self.start_creation(runtime=60) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 370, in start_creation >>> run_step(full_msg, method) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 360, in run_step >>> method() >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>> 600, in __enable_ssl >>> trust_flags=trust_flags) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 1030, in create_from_pkcs12 >>> self.import_pkcs12(pkcs12_fname, pkcs12_passwd) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 971, in import_pkcs12 >>> pkcs12_passwd=pkcs12_passwd) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 191, in import_pkcs12 >>> pkcs12_filename) >>> >>> 2014-09-26T15:05:43Z DEBUG The ipa-replica-install command failed, >>> exception: RuntimeError: incorrect password for pkcs#12 file >>> /tmp/tmp2vEWX_ipa/realm_info/dscert.p12 >>> >>> >>> I'll attach the files for reference; the options for ipa-server-install >>> and ipa-replica-prepare were: >>> >>> --http-cert-file=~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 >>> --http-cert-file >>> ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-allcerts-x509.pem --http-pin >>> 12345678 --dirsrv-cert-file >>> ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-cacerts-pkcs7.pem >>> --dirsrv-cert-file ~/STAR.idm.lab.eng.brq.redhat.com_3.p12-nocacerts.p12 >>> --dirsrv-pin 12345678 > > Fixed. > > Updated patches attached. Added patch 341 for stricter CA certificate validation which fixes . Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-336.3-Add-NSSDatabase.import_files-method-for-importing-fi.patch Type: text/x-patch Size: 9442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-337.3-External-CA-installer-options-usability-fixes.patch Type: text/x-patch Size: 26492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-338.3-CA-less-installer-options-usability-fixes.patch Type: text/x-patch Size: 46897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-339.3-Allow-choosing-CA-less-server-certificates-by-name.patch Type: text/x-patch Size: 9601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-341-Do-stricter-validation-of-CA-certificates.patch Type: text/x-patch Size: 3013 bytes Desc: not available URL: From pvoborni at redhat.com Mon Sep 29 14:44:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 29 Sep 2014 16:44:30 +0200 Subject: [Freeipa-devel] [PATCH] 757 webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types In-Reply-To: <54296A75.3050205@redhat.com> References: <54229A46.9040409@redhat.com> <54290CE1.9040808@redhat.com> <54296A75.3050205@redhat.com> Message-ID: <5429704E.5010007@redhat.com> On 29.9.2014 16:19, Endi Sukma Dewata wrote: > On 9/29/2014 2:40 AM, Petr Vobornik wrote: >> On 24.9.2014 12:17, Petr Vobornik wrote: >>> webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types >>> >>> They are not supported by API. >> >> Forgot to attach patch... > > ACK. > Pushed to: ipa-4-1: d84b8fe8e3eb597d05201731faf1a0894f42aee0 master: fcce15d0bd0205c4fcd95a4057602da2e29b7bb8 -- Petr Vobornik From dkupka at redhat.com Mon Sep 29 14:48:03 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 29 Sep 2014 16:48:03 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Check that port 8443 is available when installing PKI. Message-ID: <54297123.4040901@redhat.com> https://fedorahosted.org/freeipa/ticket/4564 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0018-ipa41-Check-that-port-8443-is-available-when-installing-PK.patch Type: text/x-patch Size: 2994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0018-master-Check-that-port-8443-is-available-when-installing-PK.patch Type: text/x-patch Size: 2962 bytes Desc: not available URL: From npmccallum at redhat.com Mon Sep 29 15:26:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 29 Sep 2014 11:26:08 -0400 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth In-Reply-To: <54240076.80001@redhat.com> References: <1411148975.18665.5.camel@redhat.com> <54240076.80001@redhat.com> Message-ID: <1412004368.18502.1.camel@redhat.com> On Thu, 2014-09-25 at 13:45 +0200, thierry bordaz wrote: > On 09/19/2014 07:49 PM, Nathaniel McCallum wrote: > > > This is an optimization from patch 0062 (rescinded) which I think is > > worth keeping. There is no ticket for this. > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello, > > That is exact that slapi* are doing a intensive usage of the > of alloc/free. Using a stack allocated mods would reduce the > number of alloc/free but I afraid it will not have a > significant impact. For example further slapi_modify_internal > is doing tons of alloc/free. > > Also I think it is not possible to use stack allocated mods. > In fact mods will be modified by internal_mod (for example to > add 'modifytimestamp', 'modifiersname') and mods will be > reallocated. This could also occurs from plugins. > Finally if a modify retry occurs, the original mods are > freeed. So does slapi_modify_internal_set_pb() steal ownership of the LDAPMod array? I wish this were better documented. From npmccallum at redhat.com Mon Sep 29 15:45:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 29 Sep 2014 11:45:49 -0400 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth In-Reply-To: <54240076.80001@redhat.com> References: <1411148975.18665.5.camel@redhat.com> <54240076.80001@redhat.com> Message-ID: <1412005549.18502.2.camel@redhat.com> On Thu, 2014-09-25 at 13:45 +0200, thierry bordaz wrote: > On 09/19/2014 07:49 PM, Nathaniel McCallum wrote: > > > This is an optimization from patch 0062 (rescinded) which I think is > > worth keeping. There is no ticket for this. > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello, > > That is exact that slapi* are doing a intensive usage of the > of alloc/free. Using a stack allocated mods would reduce the > number of alloc/free but I afraid it will not have a > significant impact. For example further slapi_modify_internal > is doing tons of alloc/free. > > Also I think it is not possible to use stack allocated mods. > In fact mods will be modified by internal_mod (for example to > add 'modifytimestamp', 'modifiersname') and mods will be > reallocated. This could also occurs from plugins. > Finally if a modify retry occurs, the original mods are > freeed. See ldap/servers/slapd/task.c. In this file, everything is stack allocated except for the value itself. From tbordaz at redhat.com Mon Sep 29 16:01:48 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 29 Sep 2014 18:01:48 +0200 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth In-Reply-To: <1412005549.18502.2.camel@redhat.com> References: <1411148975.18665.5.camel@redhat.com> <54240076.80001@redhat.com> <1412005549.18502.2.camel@redhat.com> Message-ID: <5429826C.2070902@redhat.com> On 09/29/2014 05:45 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-25 at 13:45 +0200, thierry bordaz wrote: >> On 09/19/2014 07:49 PM, Nathaniel McCallum wrote: >> >>> This is an optimization from patch 0062 (rescinded) which I think is >>> worth keeping. There is no ticket for this. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello, >> >> That is exact that slapi* are doing a intensive usage of the >> of alloc/free. Using a stack allocated mods would reduce the >> number of alloc/free but I afraid it will not have a >> significant impact. For example further slapi_modify_internal >> is doing tons of alloc/free. >> >> Also I think it is not possible to use stack allocated mods. >> In fact mods will be modified by internal_mod (for example to >> add 'modifytimestamp', 'modifiersname') and mods will be >> reallocated. This could also occurs from plugins. >> Finally if a modify retry occurs, the original mods are >> freeed. > See ldap/servers/slapd/task.c. In this file, everything is stack > allocated except for the value itself. > Hi Nathaniel, Yes you are correct. This is even a common method :-[ In fact the mods are duplicated/replaced by normalized one at the begining of modify_internal_pb. This is that duplicated ones that can later be extended/freed. Sorry for the noise. The fix is valid. Ack. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Sep 29 16:09:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Sep 2014 12:09:57 -0400 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <54296010.1000705@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> <54296010.1000705@redhat.com> Message-ID: <54298455.7020601@redhat.com> Jan Cholasta wrote: > Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>>> management and renewal code. Related tickets: >>>>>>> , >>>>>>> . >>>>>>> >>>>>>> (Patch 319 was originally posted at >>>>>>> .) >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Only two of the patches includes what ticket(s) they address. Most >>>>>> have >>>>>> the tersest of commit messages. If got more and more difficult to see >>>>>> why the changes were needed at all, as you'll see. >>>>> >>>>> Sorry, fixed (hopefully). >>>>> >>>>> Note that most of these patches fix stuff I didn't have time to fix >>>>> before I posted the original CA management patches, hence the missing >>>>> tickets. >>>> >>>> Well, the policy is that every commit should have a ticket. So I guess >>>> re-open the old tickets or open new ones. This will help someone in the >>>> future know the "why" of a patch. I've certainly been guilty >>> >>> OK, I will reopen the related tickets. >>> >>>> >>>> Here is a new set of reviews as trying to intermingle was making my >>>> eyes >>>> cross: >>>> >>>> 319: >>>> >>>> I guess I still don't understand why you can't pull the certs out of >>>> LDAP when creating this database. When this code runs, we know that the >>>> client is configured, so we have access to authentication. Why can't >>>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>>> and the code is already written in ipa-client-install to do this. >>> >>> Well, I don't understand why do you want them to be updated so much, as >>> nothing will break if they are not. Also try to imagine what would >>> happen if, say, 10k clients were updated at the same moment... >> >> What's the point of a database missing certificates? > > It won't be missing any certificates if /etc/pki/nssdb was not missing > any certificates before the update. > > As I said, the update will not break anything. It will not fix anything > either, but I don't think this kind of fixing should be done during > client RPM upgrade. It is not consistent with anything else we do during > client RPM upgrade, it does not scale well and it just does not feel > right to me in overall. Ok, I'll concede the point that there is no difference post-update, but it doesn't do what ipa-certupdate does. You can potentially end up with a completely diffferent set of certificates. So why the difference? Post install of new client bits: # certutil -L -d /etc/ipa/nssdb/ IPA CA CT,C,C After running ipa-certupdate: # certutil -L -d /etc/ipa/nssdb/ CN=Primary CA,O=example.com,C=US ,, CN=Secondary CA,O=example.com,C=US ,, GREYOAK.COM IPA CA CT,C,C Quite the difference. I'll ACK for now since this doesn't materially change anything and shouldn't break any installs but it begs the question of why it is acceptable now but not acceptable to make ipa-certupdate do the same. So ACK for 319, 324-331, 340. > > The LDAP update happens in renew_ca_cert. Are there any relevant errors > in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the > master entry of the master where you run ipa-cacert-manage renew? Sep 25 16:06:44 grindle renew_ca_cert: Traceback (most recent call last): File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 214, in main() File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 79, in main ca = cainstance.CAInstance(host_name=api.env.host, ldapi=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 357, in __init__ self.ra_agent_pwd = self.ra_agent_db + "/pwdfile.txt" TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' Sep 25 16:06:44 grindle certmonger: Certificate named "caSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" issued by CA and saved. rob From sbose at redhat.com Mon Sep 29 16:15:21 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 29 Sep 2014 18:15:21 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140925114600.GD3987@localhost.localdomain> References: <20140923151101.GE2947@localhost.localdomain> <20140924132354.GF31763@hendrix.brq.redhat.com> <20140925114600.GD3987@localhost.localdomain> Message-ID: <20140929161521.GF3237@localhost.localdomain> On Thu, Sep 25, 2014 at 01:46:00PM +0200, Sumit Bose wrote: > On Wed, Sep 24, 2014 at 03:23:54PM +0200, Jakub Hrozek wrote: > > On Tue, Sep 23, 2014 at 05:11:01PM +0200, Sumit Bose wrote: > > > Hi, > > > > > > this patch should fix https://fedorahosted.org/freeipa/ticket/4031 and > > > with the corresponding SSSD part it would be possible to get the full > > > list of group memberships with the id command even for user who didn't > > > log in before. > > > > > > bye, > > > Sumit > > > > So far I only read the patch, no testing was done yet (I'm installing a > > separate VM where I'll keep this new plugin for easy comparison and > > backwards-compatibility testing) > > Thank you for the review, please see comments below. > > > > > First, there are some Coverity warnings: > > > > Error: USE_AFTER_FREE (CWE-825): > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:242: alias: Assigning: "groups" = "new_groups". Now both point to the same storage. > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:246: freed_arg: "free(void *)" frees "groups". > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:252: use_after_free: Using freed pointer "groups". > > fixed > > > > > Error: CONSTANT_EXPRESSION_RESULT (CWE-398): > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:596: missing_parentheses: "!id_type != SSS_ID_TYPE_GID" is always true regardless of the values of its operands. Did you intend to either negate the entire comparison expression, in which case parentheses would be required around the entire comparison expression to force that interpretation, or negate the sense of the comparison (that is, use '==' rather than '!=')? This occurs as the logical second operand of '||'. > > fixed > > > > > Error: DEADCODE (CWE-561): > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_single: Condition "request_type == 1U", taking false branch. Now the value of "request_type" cannot be equal to 1. > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_set: Condition "request_type == 3U", taking false branch. Now the value of "request_type" cannot be equal to any of {1, 3}. > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: cannot_set: At condition "request_type == 1U", the value of "request_type" cannot be equal to any of {1, 3}. > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: dead_error_condition: The condition "request_type == 1U" cannot be true. > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:607: dead_error_line: Execution cannot reach this statement "ret = pack_ber_sid(sid_str,...". > > I thik this is a result of the CONSTANT_EXPRESSION_RESULT issue, since I > fixed it this warning should be gone as well. > > > > > See some comments inline. > > > > > From 23ff38cdea85995b211e73f474bcb4b0d7fb8039 Mon Sep 17 00:00:00 2001 > > > From: Sumit Bose > > > Date: Tue, 23 Sep 2014 15:55:43 +0200 > > > Subject: [PATCH] extdom: add support for new version > > > > > > Currently the extdom plugin is basically used to translate SIDs of AD > > > users and groups to names and POSIX IDs. > > > > > > With this patch a new version is added which will return the full member > > > list for groups and the full list of group memberships for a user. > > > Additionally the gecos field, the home directory and the login shell of a > > > user are returned and an optional list of key-value pairs which > > > currently will contain the SID of the requested object if available. > > > > > > https://fedorahosted.org/freeipa/ticket/4031 > > > --- > > > .../ipa-extdom-extop/ipa_extdom.h | 29 +- > > > .../ipa-extdom-extop/ipa_extdom_common.c | 850 +++++++++++++++------ > > > .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- > > > 3 files changed, 640 insertions(+), 267 deletions(-) > > > > > > diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > index 5f834a047a579104cd2589ce417c580c1c5388d3..548ee74f561c474854c049726c4c3e71da5cbbea 100644 > > > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > @@ -64,6 +64,7 @@ > > > #include > > > > > > #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" > > > +#define EXOP_EXTDOM_V2_OID "2.16.840.1.113730.3.8.10.4.1" > > > > It's a bit odd that this control is called V1 in the SSSD tree and V2 in > > the IPA tree. It's not wrong, just strange maybe. > > you are right, I renamed the versions here. > > > > > > > > > -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > > - struct extdom_res **res) > > > +int check_request(struct extdom_req *req, enum extdom_version version) > > > +{ > > > + if (version == EXTDOM_V1) { > > > + if (req->request_type == REQ_FULL_WITH_GROUPS) { > > > + return LDAP_PROTOCOL_ERROR; > > > + } > > > + } > > > > Any particular reason why these conditions are nested and not and-ed ? > > Did you expect more under the EXTDOM_V1 condition? > > I'm not expecting them, but who knows :-) I think this way it is more > clear that we are testing features of a specific version here. > > > > > > + > > > + return LDAP_SUCCESS; > > > +} > > > + > > > +static int get_buffer(size_t *_buf_len, char **_buf) > > > { > > > - int ret; > > > - char *domain_name = NULL; > > > - char *sid_str = NULL; > > > - size_t buf_len; > > > - char *buf = NULL; > > > long pw_max; > > > long gr_max; > > > - struct pwd_grp pg_data; > > > - struct passwd *pwd_result = NULL; > > > - struct group *grp_result = NULL; > > > - enum sss_id_type id_type; > > > - char *fq_name = NULL; > > > - char *sep; > > > - > > > + size_t buf_len; > > > + char *buf; > > > > > > pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); > > > gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); > > > @@ -211,302 +212,655 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > > return LDAP_OPERATIONS_ERROR; > > > } > > > > > > - switch (req->input_type) { > > > - case INP_POSIX_UID: > > > - if (req->request_type == REQ_SIMPLE) { > > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > > - &id_type); > > > + *_buf_len = buf_len; > > > + *_buf = buf; > > > + > > > + return LDAP_SUCCESS; > > > +} > > > + > > > +static int get_user_grouplist(const char *name, gid_t gid, > > > + size_t *_ngroups, gid_t **_groups ) > > > +{ > > > + int ret; > > > + int ngroups; > > > + gid_t *groups; > > > + gid_t *new_groups; > > > + > > > + ngroups = 128; > > > > I was wondering whether to use _SC_NGROUPS_MAX or NGROUPS_MAX here, but > > I guess you're right it's very unlikely that a user will be a member of > > more than 128 groups so we'd just clinge to more memory than needed.. > > > > > + groups = malloc(ngroups * sizeof(gid_t)); > > > + if (groups == NULL) { > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + ret = getgrouplist(name, gid, groups, &ngroups); > > > + if (ret == -1) { > > > + new_groups = realloc(groups, ngroups); > > > + if (new_groups == NULL) { > > > + free(groups); > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + groups = new_groups; > > > + > > > + ret = getgrouplist(name, gid, groups, &ngroups); > > > + if (ret == -1) { > > > + free(groups); > > > + ret = LDAP_OPERATIONS_ERROR; > > > + } > > > + } > > > + > > > + *_ngroups = ngroups; > > > + *_groups = groups; > > > + > > > + return LDAP_SUCCESS; > > > +} > > > + > > > +static int pack_ber_sid(const char *sid, struct berval **berval) > > > +{ > > > + BerElement *ber = NULL; > > > + int ret; > > > + > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > + if (ber == NULL) { > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + ret = ber_printf(ber,"{es}", RESP_SID, sid); > > > + if (ret == -1) { > > > + ber_free(ber, 1); > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + ret = ber_flatten(ber, berval); > > > + ber_free(ber, 1); > > > + if (ret == -1) { > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + return LDAP_SUCCESS; > > > +} > > > + > > > +#define SSSD_SYSDB_SID_STR "objectSIDString" > > > + > > > +static int pack_ber_user(const char *domain_name, const char *user_name, > > > + uid_t uid, gid_t gid, > > > + const char *gecos, const char *homedir, > > > + const char *shell, const char *sid_str, > > > + struct berval **berval) > > > +{ > > > + BerElement *ber = NULL; > > > + int ret; > > > + enum response_types response_type; > > > + size_t ngroups; > > > + gid_t *groups = NULL; > > > + size_t buf_len; > > > + char *buf = NULL; > > > + struct group grp; > > > + struct group *grp_result; > > > + size_t c; > > > + char *locat; > > > + char *short_user_name = NULL; > > > + const char *single_value_string_array[] = {NULL, NULL}; > > > + > > > + if (gecos == NULL && homedir == NULL && shell == NULL) { > > > + response_type = RESP_USER; > > > + } else { > > > + response_type = RESP_USER_GROUPLIST; > > > + } > > > + > > > + short_user_name = strdup(user_name); > > > + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > > > Some functions in the code use strchr to fund the at-sign, some use > > strrch. Could we standardize on one or the other? Do you expect some > > usernames with an at-sign in them? > > I think the 'rr' version was just a typo, I changed it to 'r'. > > > > > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > > + locat[0] = '\0'; > > > } else { > > > - id_type = SSS_ID_TYPE_UID; > > > - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, > > > - buf_len, &pwd_result); > > > + ret = LDAP_NO_SUCH_OBJECT; > > > + goto done; > > > } > > > + } > > > > > > - domain_name = strdup(req->data.posix_uid.domain_name); > > > - break; > > > - case INP_POSIX_GID: > > > - if (req->request_type == REQ_SIMPLE) { > > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > > - &id_type); > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > + if (ber == NULL) { > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, > > > + uid, gid); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + if (response_type == RESP_USER_GROUPLIST) { > > > + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); > > > + if (ret != LDAP_SUCCESS) { > > > + goto done; > > > + } > > > + > > > + ret = get_buffer(&buf_len, &buf); > > > + if (ret != LDAP_SUCCESS) { > > > + goto done; > > > + } > > > + > > > + ret = ber_printf(ber,"sss", gecos, homedir, shell); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + ret = ber_printf(ber,"{"); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + for (c = 0; c < ngroups; c++) { > > > + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); > > > + if (ret != 0) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + if (grp_result == NULL) { > > > + ret = LDAP_NO_SUCH_OBJECT; > > > + goto done; > > > > I wanted to check if you think it's better to continue or fail here. Did > > you opt for failing because you were afraid of missing some deny access > > checks in case we couldn't resolv a group? > > I think there is a disconnect if getgrouplist() returns a GID that > cannot be resolved so I prefer an error in this case. > > > > > > + } > > > + > > > + ret = ber_printf(ber, "s", grp.gr_name); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + } > > > + > > > + ret = ber_printf(ber,"}"); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + single_value_string_array[0] = sid_str; > > > + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, > > > + single_value_string_array); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + } > > > + > > > + ret = ber_printf(ber,"}}"); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + ret = ber_flatten(ber, berval); > > > + if (ret == -1) { > > > + ret = LDAP_OPERATIONS_ERROR; > > > + goto done; > > > + } > > > + > > > + ret = LDAP_SUCCESS; > > > +done: > > > + free(short_user_name); > > > + free(groups); > > > + free(buf); > > > + ber_free(ber, 1); > > > + return ret; > > > +} > > > + > > > +static int pack_ber_group(const char *domain_name, const char *group_name, > > > + gid_t gid, char **members, const char *sid_str, > > > + struct berval **berval) > > > +{ > > > + BerElement *ber = NULL; > > > + int ret; > > > + size_t c; > > > + char *locat; > > > + char *short_group_name = NULL; > > > + const char *single_value_string_array[] = {NULL, NULL}; > > > + > > > + short_group_name = strdup(group_name); > > > + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > > + locat[0] = '\0'; > > > } else { > > > - id_type = SSS_ID_TYPE_GID; > > > - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, > > > - buf_len, &grp_result); > > > + ret = LDAP_NO_SUCH_OBJECT; > > > + goto done; > > > } > > > + } > > > > > > - domain_name = strdup(req->data.posix_gid.domain_name); > > > - break; > > > - case INP_SID: > > > - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); > > > - if (ret != 0) { > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > + if (ber == NULL) { > > > + return LDAP_OPERATIONS_ERROR; > > > + } > > > + > > > + ret = ber_printf(ber,"{e{ssi", members == NULL ? RESP_GROUP > > > + : RESP_GROUP_MEMBERS, > > > > Each pack_ber_group is called like this: > > 718 if (request_type == REQ_FULL) { > > 719 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > > 720 NULL, NULL, berval); > > 721 } else { > > 722 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > > 723 grp.gr_mem, sid, berval); > > 724 } > > > > And then you guess the request_type again based on the parameter > > values. Isn't it safer to add the request type parameter avoid the if-else > > switch in the callers? Or were you trying to be on the safe side to avoid > > checking the validity members array in the pack_ber_group function and have > > the array set to NULL by the caller? > > You are right, the if-block is odd. Instead of the request_type I added > the response_type to the argument list of pack_ber_user() and > pack_ber_group() which I think is more natural because it is the > response that is packed. > > > > > The rest of the file looks to me, just the same "issue" with guessing the > > request type is repeated. > > > > New version attached. > > bye, > Sumit Hi, Jakub found another issue which is fixed with this new version. bye, Sumit From sbose at redhat.com Mon Sep 29 16:16:30 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 29 Sep 2014 18:16:30 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140929161521.GF3237@localhost.localdomain> References: <20140923151101.GE2947@localhost.localdomain> <20140924132354.GF31763@hendrix.brq.redhat.com> <20140925114600.GD3987@localhost.localdomain> <20140929161521.GF3237@localhost.localdomain> Message-ID: <20140929161629.GG3237@localhost.localdomain> On Mon, Sep 29, 2014 at 06:15:21PM +0200, Sumit Bose wrote: > On Thu, Sep 25, 2014 at 01:46:00PM +0200, Sumit Bose wrote: > > On Wed, Sep 24, 2014 at 03:23:54PM +0200, Jakub Hrozek wrote: > > > On Tue, Sep 23, 2014 at 05:11:01PM +0200, Sumit Bose wrote: > > > > Hi, > > > > > > > > this patch should fix https://fedorahosted.org/freeipa/ticket/4031 and > > > > with the corresponding SSSD part it would be possible to get the full > > > > list of group memberships with the id command even for user who didn't > > > > log in before. > > > > > > > > bye, > > > > Sumit > > > > > > So far I only read the patch, no testing was done yet (I'm installing a > > > separate VM where I'll keep this new plugin for easy comparison and > > > backwards-compatibility testing) > > > > Thank you for the review, please see comments below. > > > > > > > > First, there are some Coverity warnings: > > > > > > Error: USE_AFTER_FREE (CWE-825): > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:242: alias: Assigning: "groups" = "new_groups". Now both point to the same storage. > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:246: freed_arg: "free(void *)" frees "groups". > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:252: use_after_free: Using freed pointer "groups". > > > > fixed > > > > > > > > Error: CONSTANT_EXPRESSION_RESULT (CWE-398): > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:596: missing_parentheses: "!id_type != SSS_ID_TYPE_GID" is always true regardless of the values of its operands. Did you intend to either negate the entire comparison expression, in which case parentheses would be required around the entire comparison expression to force that interpretation, or negate the sense of the comparison (that is, use '==' rather than '!=')? This occurs as the logical second operand of '||'. > > > > fixed > > > > > > > > Error: DEADCODE (CWE-561): > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_single: Condition "request_type == 1U", taking false branch. Now the value of "request_type" cannot be equal to 1. > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:594: cond_cannot_set: Condition "request_type == 3U", taking false branch. Now the value of "request_type" cannot be equal to any of {1, 3}. > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: cannot_set: At condition "request_type == 1U", the value of "request_type" cannot be equal to any of {1, 3}. > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:606: dead_error_condition: The condition "request_type == 1U" cannot be true. > > > freeipa-4.0.0GIT2563ea2/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c:607: dead_error_line: Execution cannot reach this statement "ret = pack_ber_sid(sid_str,...". > > > > I thik this is a result of the CONSTANT_EXPRESSION_RESULT issue, since I > > fixed it this warning should be gone as well. > > > > > > > > See some comments inline. > > > > > > > From 23ff38cdea85995b211e73f474bcb4b0d7fb8039 Mon Sep 17 00:00:00 2001 > > > > From: Sumit Bose > > > > Date: Tue, 23 Sep 2014 15:55:43 +0200 > > > > Subject: [PATCH] extdom: add support for new version > > > > > > > > Currently the extdom plugin is basically used to translate SIDs of AD > > > > users and groups to names and POSIX IDs. > > > > > > > > With this patch a new version is added which will return the full member > > > > list for groups and the full list of group memberships for a user. > > > > Additionally the gecos field, the home directory and the login shell of a > > > > user are returned and an optional list of key-value pairs which > > > > currently will contain the SID of the requested object if available. > > > > > > > > https://fedorahosted.org/freeipa/ticket/4031 > > > > --- > > > > .../ipa-extdom-extop/ipa_extdom.h | 29 +- > > > > .../ipa-extdom-extop/ipa_extdom_common.c | 850 +++++++++++++++------ > > > > .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- > > > > 3 files changed, 640 insertions(+), 267 deletions(-) > > > > > > > > diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > > index 5f834a047a579104cd2589ce417c580c1c5388d3..548ee74f561c474854c049726c4c3e71da5cbbea 100644 > > > > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h > > > > @@ -64,6 +64,7 @@ > > > > #include > > > > > > > > #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" > > > > +#define EXOP_EXTDOM_V2_OID "2.16.840.1.113730.3.8.10.4.1" > > > > > > It's a bit odd that this control is called V1 in the SSSD tree and V2 in > > > the IPA tree. It's not wrong, just strange maybe. > > > > you are right, I renamed the versions here. > > > > > > > > > > > > > -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > > > - struct extdom_res **res) > > > > +int check_request(struct extdom_req *req, enum extdom_version version) > > > > +{ > > > > + if (version == EXTDOM_V1) { > > > > + if (req->request_type == REQ_FULL_WITH_GROUPS) { > > > > + return LDAP_PROTOCOL_ERROR; > > > > + } > > > > + } > > > > > > Any particular reason why these conditions are nested and not and-ed ? > > > Did you expect more under the EXTDOM_V1 condition? > > > > I'm not expecting them, but who knows :-) I think this way it is more > > clear that we are testing features of a specific version here. > > > > > > > > > + > > > > + return LDAP_SUCCESS; > > > > +} > > > > + > > > > +static int get_buffer(size_t *_buf_len, char **_buf) > > > > { > > > > - int ret; > > > > - char *domain_name = NULL; > > > > - char *sid_str = NULL; > > > > - size_t buf_len; > > > > - char *buf = NULL; > > > > long pw_max; > > > > long gr_max; > > > > - struct pwd_grp pg_data; > > > > - struct passwd *pwd_result = NULL; > > > > - struct group *grp_result = NULL; > > > > - enum sss_id_type id_type; > > > > - char *fq_name = NULL; > > > > - char *sep; > > > > - > > > > + size_t buf_len; > > > > + char *buf; > > > > > > > > pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); > > > > gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); > > > > @@ -211,302 +212,655 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > > > return LDAP_OPERATIONS_ERROR; > > > > } > > > > > > > > - switch (req->input_type) { > > > > - case INP_POSIX_UID: > > > > - if (req->request_type == REQ_SIMPLE) { > > > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > > > - &id_type); > > > > + *_buf_len = buf_len; > > > > + *_buf = buf; > > > > + > > > > + return LDAP_SUCCESS; > > > > +} > > > > + > > > > +static int get_user_grouplist(const char *name, gid_t gid, > > > > + size_t *_ngroups, gid_t **_groups ) > > > > +{ > > > > + int ret; > > > > + int ngroups; > > > > + gid_t *groups; > > > > + gid_t *new_groups; > > > > + > > > > + ngroups = 128; > > > > > > I was wondering whether to use _SC_NGROUPS_MAX or NGROUPS_MAX here, but > > > I guess you're right it's very unlikely that a user will be a member of > > > more than 128 groups so we'd just clinge to more memory than needed.. > > > > > > > + groups = malloc(ngroups * sizeof(gid_t)); > > > > + if (groups == NULL) { > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + ret = getgrouplist(name, gid, groups, &ngroups); > > > > + if (ret == -1) { > > > > + new_groups = realloc(groups, ngroups); > > > > + if (new_groups == NULL) { > > > > + free(groups); > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + groups = new_groups; > > > > + > > > > + ret = getgrouplist(name, gid, groups, &ngroups); > > > > + if (ret == -1) { > > > > + free(groups); > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + } > > > > + } > > > > + > > > > + *_ngroups = ngroups; > > > > + *_groups = groups; > > > > + > > > > + return LDAP_SUCCESS; > > > > +} > > > > + > > > > +static int pack_ber_sid(const char *sid, struct berval **berval) > > > > +{ > > > > + BerElement *ber = NULL; > > > > + int ret; > > > > + > > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > > + if (ber == NULL) { > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + ret = ber_printf(ber,"{es}", RESP_SID, sid); > > > > + if (ret == -1) { > > > > + ber_free(ber, 1); > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + ret = ber_flatten(ber, berval); > > > > + ber_free(ber, 1); > > > > + if (ret == -1) { > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + return LDAP_SUCCESS; > > > > +} > > > > + > > > > +#define SSSD_SYSDB_SID_STR "objectSIDString" > > > > + > > > > +static int pack_ber_user(const char *domain_name, const char *user_name, > > > > + uid_t uid, gid_t gid, > > > > + const char *gecos, const char *homedir, > > > > + const char *shell, const char *sid_str, > > > > + struct berval **berval) > > > > +{ > > > > + BerElement *ber = NULL; > > > > + int ret; > > > > + enum response_types response_type; > > > > + size_t ngroups; > > > > + gid_t *groups = NULL; > > > > + size_t buf_len; > > > > + char *buf = NULL; > > > > + struct group grp; > > > > + struct group *grp_result; > > > > + size_t c; > > > > + char *locat; > > > > + char *short_user_name = NULL; > > > > + const char *single_value_string_array[] = {NULL, NULL}; > > > > + > > > > + if (gecos == NULL && homedir == NULL && shell == NULL) { > > > > + response_type = RESP_USER; > > > > + } else { > > > > + response_type = RESP_USER_GROUPLIST; > > > > + } > > > > + > > > > + short_user_name = strdup(user_name); > > > > + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > > > > > Some functions in the code use strchr to fund the at-sign, some use > > > strrch. Could we standardize on one or the other? Do you expect some > > > usernames with an at-sign in them? > > > > I think the 'rr' version was just a typo, I changed it to 'r'. > > > > > > > > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > > > + locat[0] = '\0'; > > > > } else { > > > > - id_type = SSS_ID_TYPE_UID; > > > > - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, > > > > - buf_len, &pwd_result); > > > > + ret = LDAP_NO_SUCH_OBJECT; > > > > + goto done; > > > > } > > > > + } > > > > > > > > - domain_name = strdup(req->data.posix_uid.domain_name); > > > > - break; > > > > - case INP_POSIX_GID: > > > > - if (req->request_type == REQ_SIMPLE) { > > > > - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, > > > > - &id_type); > > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > > + if (ber == NULL) { > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, > > > > + uid, gid); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + if (response_type == RESP_USER_GROUPLIST) { > > > > + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); > > > > + if (ret != LDAP_SUCCESS) { > > > > + goto done; > > > > + } > > > > + > > > > + ret = get_buffer(&buf_len, &buf); > > > > + if (ret != LDAP_SUCCESS) { > > > > + goto done; > > > > + } > > > > + > > > > + ret = ber_printf(ber,"sss", gecos, homedir, shell); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + ret = ber_printf(ber,"{"); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + for (c = 0; c < ngroups; c++) { > > > > + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); > > > > + if (ret != 0) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + if (grp_result == NULL) { > > > > + ret = LDAP_NO_SUCH_OBJECT; > > > > + goto done; > > > > > > I wanted to check if you think it's better to continue or fail here. Did > > > you opt for failing because you were afraid of missing some deny access > > > checks in case we couldn't resolv a group? > > > > I think there is a disconnect if getgrouplist() returns a GID that > > cannot be resolved so I prefer an error in this case. > > > > > > > > > + } > > > > + > > > > + ret = ber_printf(ber, "s", grp.gr_name); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + } > > > > + > > > > + ret = ber_printf(ber,"}"); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + single_value_string_array[0] = sid_str; > > > > + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, > > > > + single_value_string_array); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + } > > > > + > > > > + ret = ber_printf(ber,"}}"); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + ret = ber_flatten(ber, berval); > > > > + if (ret == -1) { > > > > + ret = LDAP_OPERATIONS_ERROR; > > > > + goto done; > > > > + } > > > > + > > > > + ret = LDAP_SUCCESS; > > > > +done: > > > > + free(short_user_name); > > > > + free(groups); > > > > + free(buf); > > > > + ber_free(ber, 1); > > > > + return ret; > > > > +} > > > > + > > > > +static int pack_ber_group(const char *domain_name, const char *group_name, > > > > + gid_t gid, char **members, const char *sid_str, > > > > + struct berval **berval) > > > > +{ > > > > + BerElement *ber = NULL; > > > > + int ret; > > > > + size_t c; > > > > + char *locat; > > > > + char *short_group_name = NULL; > > > > + const char *single_value_string_array[] = {NULL, NULL}; > > > > + > > > > + short_group_name = strdup(group_name); > > > > + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { > > > > + if (strcasecmp(locat+1, domain_name) == 0 ) { > > > > + locat[0] = '\0'; > > > > } else { > > > > - id_type = SSS_ID_TYPE_GID; > > > > - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, > > > > - buf_len, &grp_result); > > > > + ret = LDAP_NO_SUCH_OBJECT; > > > > + goto done; > > > > } > > > > + } > > > > > > > > - domain_name = strdup(req->data.posix_gid.domain_name); > > > > - break; > > > > - case INP_SID: > > > > - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); > > > > - if (ret != 0) { > > > > + ber = ber_alloc_t( LBER_USE_DER ); > > > > + if (ber == NULL) { > > > > + return LDAP_OPERATIONS_ERROR; > > > > + } > > > > + > > > > + ret = ber_printf(ber,"{e{ssi", members == NULL ? RESP_GROUP > > > > + : RESP_GROUP_MEMBERS, > > > > > > Each pack_ber_group is called like this: > > > 718 if (request_type == REQ_FULL) { > > > 719 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > > > 720 NULL, NULL, berval); > > > 721 } else { > > > 722 ret = pack_ber_group(domain_name, grp.gr_name, grp.gr_gid, > > > 723 grp.gr_mem, sid, berval); > > > 724 } > > > > > > And then you guess the request_type again based on the parameter > > > values. Isn't it safer to add the request type parameter avoid the if-else > > > switch in the callers? Or were you trying to be on the safe side to avoid > > > checking the validity members array in the pack_ber_group function and have > > > the array set to NULL by the caller? > > > > You are right, the if-block is odd. Instead of the request_type I added > > the response_type to the argument list of pack_ber_user() and > > pack_ber_group() which I think is more natural because it is the > > response that is packed. > > > > > > > > The rest of the file looks to me, just the same "issue" with guessing the > > > request type is repeated. > > > > > > > New version attached. > > > > bye, > > Sumit > > Hi, > > Jakub found another issue which is fixed with this new version. > > bye, > Sumit and now with patch ... -------------- next part -------------- From 1becbaf1c6120618a5dfe47150bf970578d1c8be Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 23 Sep 2014 15:55:43 +0200 Subject: [PATCH] extdom: add support for new version Currently the extdom plugin is basically used to translate SIDs of AD users and groups to names and POSIX IDs. With this patch a new version is added which will return the full member list for groups and the full list of group memberships for a user. Additionally the gecos field, the home directory and the login shell of a user are returned and an optional list of key-value pairs which currently will contain the SID of the requested object if available. https://fedorahosted.org/freeipa/ticket/4031 --- .../ipa-extdom-extop/ipa_extdom.h | 29 +- .../ipa-extdom-extop/ipa_extdom_common.c | 830 ++++++++++++++------- .../ipa-extdom-extop/ipa_extdom_extop.c | 28 +- 3 files changed, 619 insertions(+), 268 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 5f834a047a579104cd2589ce417c580c1c5388d3..90f8390d871a698dc00ef56c41be0749eaa13424 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -64,6 +64,7 @@ #include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" +#define EXOP_EXTDOM_V1_OID "2.16.840.1.113730.3.8.10.4.1" #define IPA_EXTDOM_PLUGIN_NAME "ipa-extdom-extop" #define IPA_EXTDOM_FEATURE_DESC "IPA trusted domain ID mapper" @@ -71,6 +72,11 @@ #define IPA_PLUGIN_NAME IPA_EXTDOM_PLUGIN_NAME +enum extdom_version { + EXTDOM_V0 = 0, + EXTDOM_V1 +}; + enum input_types { INP_SID = 1, INP_NAME, @@ -80,14 +86,17 @@ enum input_types { enum request_types { REQ_SIMPLE = 1, - REQ_FULL + REQ_FULL, + REQ_FULL_WITH_GROUPS }; enum response_types { RESP_SID = 1, RESP_NAME, RESP_USER, - RESP_GROUP + RESP_GROUP, + RESP_USER_GROUPLIST, + RESP_GROUP_MEMBERS }; struct extdom_req { @@ -123,11 +132,18 @@ struct extdom_res { char *user_name; uid_t uid; gid_t gid; + char *gecos; + char *home; + char *shell; + size_t ngroups; + char **groups; } user; struct { char *domain_name; char *group_name; gid_t gid; + size_t nmembers; + char **members; } group; } data; }; @@ -150,15 +166,14 @@ struct pwd_grp { struct passwd pwd; struct group grp; } data; + int ngroups; + gid_t *groups; }; int parse_request_data(struct berval *req_val, struct extdom_req **_req); void free_req_data(struct extdom_req *req); +int check_request(struct extdom_req *req, enum extdom_version version); int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res); -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res); -void free_resp_data(struct extdom_res *res); + struct berval **berval); int pack_response(struct extdom_res *res, struct berval **ret_val); #endif /* _IPA_EXTDOM_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 025d37dc5eda05c8db43d4e8176fd7898ed32fe7..d1d214ae769946a89ffe1702382e5db70035fdac 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -70,6 +70,7 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) * requestType ENUMERATED { * simple (1), * full (2) + * full_with_groups (3) * }, * data InputData * } @@ -179,23 +180,23 @@ void free_req_data(struct extdom_req *req) free(req); } -int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, - struct extdom_res **res) +int check_request(struct extdom_req *req, enum extdom_version version) +{ + if (version == EXTDOM_V0) { + if (req->request_type == REQ_FULL_WITH_GROUPS) { + return LDAP_PROTOCOL_ERROR; + } + } + + return LDAP_SUCCESS; +} + +static int get_buffer(size_t *_buf_len, char **_buf) { - int ret; - char *domain_name = NULL; - char *sid_str = NULL; - size_t buf_len; - char *buf = NULL; long pw_max; long gr_max; - struct pwd_grp pg_data; - struct passwd *pwd_result = NULL; - struct group *grp_result = NULL; - enum sss_id_type id_type; - char *fq_name = NULL; - char *sep; - + size_t buf_len; + char *buf; pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); @@ -211,302 +212,633 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, return LDAP_OPERATIONS_ERROR; } - switch (req->input_type) { - case INP_POSIX_UID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); - } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, - buf_len, &pwd_result); + *_buf_len = buf_len; + *_buf = buf; + + return LDAP_SUCCESS; +} + +static int get_user_grouplist(const char *name, gid_t gid, + size_t *_ngroups, gid_t **_groups ) +{ + int ret; + int ngroups; + gid_t *groups; + gid_t *new_groups; + + ngroups = 128; + groups = malloc(ngroups * sizeof(gid_t)); + if (groups == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + new_groups = realloc(groups, ngroups); + if (new_groups == NULL) { + free(groups); + return LDAP_OPERATIONS_ERROR; } + groups = new_groups; - domain_name = strdup(req->data.posix_uid.domain_name); - break; - case INP_POSIX_GID: - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, - &id_type); + ret = getgrouplist(name, gid, groups, &ngroups); + if (ret == -1) { + free(groups); + return LDAP_OPERATIONS_ERROR; + } + } + + *_ngroups = ngroups; + *_groups = groups; + + return LDAP_SUCCESS; +} + +static int pack_ber_sid(const char *sid, struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{es}", RESP_SID, sid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +#define SSSD_SYSDB_SID_STR "objectSIDString" + +static int pack_ber_user(enum response_types response_type, + const char *domain_name, const char *user_name, + uid_t uid, gid_t gid, + const char *gecos, const char *homedir, + const char *shell, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + size_t ngroups; + gid_t *groups = NULL; + size_t buf_len; + char *buf = NULL; + struct group grp; + struct group *grp_result; + size_t c; + char *locat; + char *short_user_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + short_user_name = strdup(user_name); + if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_GID; - ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, - buf_len, &grp_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; } + } - domain_name = strdup(req->data.posix_gid.domain_name); - break; - case INP_SID: - ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssii", response_type, domain_name, short_user_name, + uid, gid); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (response_type == RESP_USER_GROUPLIST) { + ret = get_user_grouplist(user_name, gid, &ngroups, &groups); + if (ret != LDAP_SUCCESS) { goto done; } - sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); - if (sep == NULL) { + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = ber_printf(ber,"sss", gecos, homedir, shell); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - ret = asprintf(&domain_name, "%s", sep+1); + ret = ber_printf(ber,"{"); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; - domain_name = NULL; /* content is undefined according to - asprintf(3) */ - goto done; - } - - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - break; - case SSS_ID_TYPE_GID: - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); - break; - default: + goto done; + } + + for (c = 0; c < ngroups; c++) { + ret = getgrgid_r(groups[c], &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = ber_printf(ber, "s", grp.gr_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; goto done; } - break; - case INP_NAME: - ret = asprintf(&fq_name, "%s%c%s", req->data.name.object_name, - SSSD_DOMAIN_SEPARATOR, - req->data.name.domain_name); + + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; - fq_name = NULL; /* content is undefined according to - asprintf(3) */ goto done; } + } - if (req->request_type == REQ_SIMPLE) { - ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; +done: + free(short_user_name); + free(groups); + free(buf); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_group(enum response_types response_type, + const char *domain_name, const char *group_name, + gid_t gid, char **members, const char *sid_str, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + size_t c; + char *locat; + char *short_group_name = NULL; + const char *single_value_string_array[] = {NULL, NULL}; + + short_group_name = strdup(group_name); + if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = '\0'; } else { - id_type = SSS_ID_TYPE_UID; - ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, - &pwd_result); - if (ret == 0 && pwd_result == NULL) { /* no user entry found */ - id_type = SSS_ID_TYPE_GID; - ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, - &grp_result); + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + } + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ssi", response_type, domain_name, short_group_name, + gid); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + if (response_type == RESP_GROUP_MEMBERS) { + ret = ber_printf(ber,"{"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + for (c = 0; members[c] != NULL; c++) { + ret = ber_printf(ber, "s", members[c]); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; } } - domain_name = strdup(req->data.name.domain_name); + + ret = ber_printf(ber,"}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + single_value_string_array[0] = sid_str; + ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, + single_value_string_array); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + } + + ret = ber_printf(ber,"}}"); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = ber_flatten(ber, berval); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; + +done: + free(short_group_name); + ber_free(ber, 1); + return ret; +} + +static int pack_ber_name(const char *domain_name, const char *name, + struct berval **berval) +{ + BerElement *ber = NULL; + int ret; + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_printf(ber,"{e{ss}}", RESP_NAME, domain_name, name); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, berval); + ber_free(ber, 1); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + +static int handle_uid_request(enum request_types request_type, uid_t uid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(uid, &sid_str, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getpwuid_r(uid, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_gid_request(enum request_types request_type, gid_t gid, + const char *domain_name, struct berval **berval) +{ + int ret; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); + if (ret != 0 || id_type != SSS_ID_TYPE_GID) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); + } else { + ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } + +done: + free(sid_str); + free(buf); + return ret; +} + +static int handle_sid_request(enum request_types request_type, const char *sid, + struct berval **berval) +{ + int ret; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *domain_name = NULL; + char *fq_name = NULL; + char *object_name = NULL; + char *sep; + size_t buf_len; + char *buf = NULL; + enum sss_id_type id_type; + + ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + + sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR); + if (sep == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + object_name = strndup(fq_name, (sep - fq_name)); + domain_name = strdup(sep + 1); + if (object_name == NULL || domain_name == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + if (request_type == REQ_SIMPLE) { + ret = pack_ber_name(domain_name, object_name, berval); + goto done; + } + + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + return ret; + } + + switch(id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (pwd_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid, berval); + break; + case SSS_ID_TYPE_GID: + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid, berval); break; default: - ret = LDAP_PROTOCOL_ERROR; - goto done; - } - - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } else if (ret == 0 && pwd_result == NULL && grp_result == NULL && - sid_str == NULL) { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - - if (domain_name == NULL) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - - ret = create_response(req, &pg_data, sid_str, id_type, domain_name, res); - if (ret != 0) { ret = LDAP_OPERATIONS_ERROR; goto done; } - - ret = LDAP_SUCCESS; - done: - free(buf); free(fq_name); + free(object_name); free(domain_name); - free(sid_str); + free(buf); return ret; } -int create_response(struct extdom_req *req, struct pwd_grp *pg_data, - const char *sid_str, enum sss_id_type id_type, - const char *domain_name, struct extdom_res **_res) +static int handle_name_request(enum request_types request_type, + const char *name, const char *domain_name, + struct berval **berval) { - int ret = EFAULT; - char *locat = NULL; - struct extdom_res *res; - - res = calloc(1, sizeof(struct extdom_res)); - if (res == NULL) { - return ENOMEM; + int ret; + char *fq_name = NULL; + struct passwd pwd; + struct passwd *pwd_result = NULL; + struct group grp; + struct group *grp_result = NULL; + char *sid_str = NULL; + enum sss_id_type id_type; + size_t buf_len; + char *buf = NULL; + + ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, + domain_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + fq_name = NULL; /* content is undefined according to + asprintf(3) */ + goto done; } - switch (req->request_type) { - case REQ_SIMPLE: - switch (req->input_type) { - case INP_SID: - res->response_type = RESP_NAME; - res->data.name.domain_name = strdup(domain_name); - switch(id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0 ) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.pwd.pw_name); - break; - case SSS_ID_TYPE_GID: - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.name.object_name = - strdup(pg_data->data.grp.gr_name); - break; - default: - ret = EINVAL; - goto done; - } - - if (res->data.name.domain_name == NULL - || res->data.name.object_name == NULL) { - ret = ENOMEM; - goto done; - } - break; - case INP_NAME: - case INP_POSIX_UID: - case INP_POSIX_GID: - res->response_type = RESP_SID; - res->data.sid = strdup(sid_str); - if (res->data.sid == NULL) { - ret = ENOMEM; - goto done; - } - break; - default: - ret = EINVAL; - goto done; - } - break; - case REQ_FULL: - switch (id_type) { - case SSS_ID_TYPE_UID: - case SSS_ID_TYPE_BOTH: - res->response_type = RESP_USER; - res->data.user.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.user.user_name = - strdup(pg_data->data.pwd.pw_name); - - if (res->data.user.domain_name == NULL - || res->data.user.user_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.user.uid = pg_data->data.pwd.pw_uid; - res->data.user.gid = pg_data->data.pwd.pw_gid; - break; - case SSS_ID_TYPE_GID: - res->response_type = RESP_GROUP; - res->data.group.domain_name = strdup(domain_name); - if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { - if (strcasecmp(locat+1, domain_name) == 0) { - locat[0] = 0; - } else { - ret = LDAP_NO_SUCH_OBJECT; - goto done; - } - } - res->data.group.group_name = - strdup(pg_data->data.grp.gr_name); - - if (res->data.group.domain_name == NULL - || res->data.group.group_name == NULL) { - ret = ENOMEM; - goto done; - } - - res->data.group.gid = pg_data->data.grp.gr_gid; - break; - default: - ret = EINVAL; - goto done; + if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + if (ret != 0) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; } - break; - default: - ret = EINVAL; - goto done; + goto done; + } } - ret = 0; - -done: - if (ret == 0) { - *_res = res; + if (request_type == REQ_SIMPLE) { + ret = pack_ber_sid(sid_str, berval); } else { - free_resp_data(res); - } + ret = get_buffer(&buf_len, &buf); + if (ret != LDAP_SUCCESS) { + goto done; + } + + ret = getpwnam_r(fq_name, &pwd, buf, buf_len, &pwd_result); + if (ret != 0) { + /* according to the man page there are a couple of error codes + * which can indicate that the user was not found. To be on the + * safe side we fail back to the group lookup on all errors. */ + pwd_result = NULL; + } + + if (pwd_result != NULL) { + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER + : RESP_USER_GROUPLIST), + domain_name, pwd.pw_name, pwd.pw_uid, + pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, + pwd.pw_shell, sid_str, berval); + } else { /* no user entry found */ + ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); + if (ret != 0) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } - if (locat != NULL) { - locat[0] = SSSD_DOMAIN_SEPARATOR; + if (grp_result == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP + : RESP_GROUP_MEMBERS), + domain_name, grp.gr_name, grp.gr_gid, + grp.gr_mem, sid_str, berval); + } } +done: + free(fq_name); + free(sid_str); + free(buf); + return ret; } -void free_resp_data(struct extdom_res *res) +int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, + struct berval **berval) { - if (res == NULL) { - return; - } + int ret; + + switch (req->input_type) { + case INP_POSIX_UID: + ret = handle_uid_request(req->request_type, req->data.posix_uid.uid, + req->data.posix_uid.domain_name, berval); - switch (res->response_type) { - case RESP_SID: - free(res->data.sid); break; - case RESP_NAME: - free(res->data.name.domain_name); - free(res->data.name.object_name); + case INP_POSIX_GID: + ret = handle_gid_request(req->request_type, req->data.posix_gid.gid, + req->data.posix_uid.domain_name, berval); + break; - case RESP_USER: - free(res->data.user.domain_name); - free(res->data.user.user_name); + case INP_SID: + ret = handle_sid_request(req->request_type, req->data.sid, berval); break; - case RESP_GROUP: - free(res->data.group.domain_name); - free(res->data.group.group_name); + case INP_NAME: + ret = handle_name_request(req->request_type, req->data.name.object_name, + req->data.name.domain_name, berval); + break; + default: + ret = LDAP_PROTOCOL_ERROR; + goto done; } - free(res); + +done: + + return ret; } - int pack_response(struct extdom_res *res, struct berval **ret_val) { BerElement *ber = NULL; diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index 9315da260ee3de660ea8ff708950945110da37e3..aa66c145bc6cf2b77fdfe37be18da67588dc0439 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -49,6 +49,7 @@ Slapi_PluginDesc ipa_extdom_plugin_desc = { static char *ipa_extdom_oid_list[] = { EXOP_EXTDOM_OID, + EXOP_EXTDOM_V1_OID, NULL }; @@ -71,8 +72,8 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) struct berval *req_val = NULL; struct berval *ret_val = NULL; struct extdom_req *req = NULL; - struct extdom_res *res = NULL; struct ipa_extdom_ctx *ctx; + enum extdom_version version; ret = slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid); if (ret != 0) { @@ -82,7 +83,11 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) } LOG("Received extended operation request with OID %s\n", oid); - if (strcasecmp(oid, EXOP_EXTDOM_OID) != 0) { + if (strcasecmp(oid, EXOP_EXTDOM_OID) == 0) { + version = EXTDOM_V0; + } else if (strcasecmp(oid, EXOP_EXTDOM_V1_OID) == 0) { + version = EXTDOM_V1; + } else { return SLAPI_PLUGIN_EXTENDED_NOT_HANDLED; } @@ -107,21 +112,21 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) goto done; } - ret = handle_request(ctx, req, &res); + ret = check_request(req, version); + if (ret != LDAP_SUCCESS) { + rc = LDAP_UNWILLING_TO_PERFORM; + err_msg = "Error in request data.\n"; + goto done; + } + + ret = handle_request(ctx, req, &ret_val); if (ret != LDAP_SUCCESS) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to handle the request.\n"; goto done; } - ret = pack_response(res, &ret_val); - if (ret != LDAP_SUCCESS) { - rc = LDAP_OPERATIONS_ERROR; - err_msg = "Failed to pack the response.\n"; - goto done; - } - - ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, EXOP_EXTDOM_OID); + ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); if (ret != 0) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to set the OID for the response.\n"; @@ -139,7 +144,6 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) done: free_req_data(req); - free_resp_data(res); if (err_msg != NULL) { LOG("%s", err_msg); } -- 1.8.5.3 From jhrozek at redhat.com Mon Sep 29 17:01:49 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 29 Sep 2014 19:01:49 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140929161629.GG3237@localhost.localdomain> References: <20140923151101.GE2947@localhost.localdomain> <20140924132354.GF31763@hendrix.brq.redhat.com> <20140925114600.GD3987@localhost.localdomain> <20140929161521.GF3237@localhost.localdomain> <20140929161629.GG3237@localhost.localdomain> Message-ID: <20140929170149.GH3165@hendrix.brq.redhat.com> On Mon, Sep 29, 2014 at 06:16:30PM +0200, Sumit Bose wrote: > > Hi, > > > > Jakub found another issue which is fixed with this new version. > > > > bye, > > Sumit > > and now with patch ... Thank you, ACK From npmccallum at redhat.com Mon Sep 29 18:30:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 29 Sep 2014 14:30:53 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <20140922093205.67d082c9@willson.usersys.redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> Message-ID: <1412015453.18502.7.camel@redhat.com> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: > On Sun, 21 Sep 2014 22:33:47 -0400 > Nathaniel McCallum wrote: > > Comments inline. > > > + > > +#define ch_malloc(type) \ > > + (type*) slapi_ch_malloc(sizeof(type)) > > +#define ch_calloc(count, type) \ > > + (type*) slapi_ch_calloc(count, sizeof(type)) > > +#define ch_free(p) \ > > + slapi_ch_free((void**) &(p)) > > please do not redefine slapi functions, it just makes it harder to know > what you used. > > > > +typedef struct { > > + bool exists; > > + long long value; > > +} counter; > > > please no typedefs of structures, use "struct counter { ... };" and > reference it as "struct counter" in the code. > > Btw, FWIW you could use a value of -1 to indicate non-existence of the > counter value, given counters can only be positive, this would avoid > the need for a struct. > > > +static int > > +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > > +{ > > + va_list ap; > > + int res; > > + > > + va_start(ap, template); > > + res = vsnprintf(NULL, 0, template, ap); > > + va_end(ap); > > + > > + if (res > 0) { > > + char str[res + 1]; > > + > > + va_start(ap, template); > > + res = vsnprintf(str, sizeof(str), template, ap); > > + va_end(ap); > > + > > + if (res > 0) > > + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > > + } > > + > > + if (res <= 0) > > + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > > + > > + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > > + return rc; > > +} > > This function seem not really useful, you use send_error() only at the > end of one single function where you could have the classic scheme of > using a done: label and just use directly slapi_ch_smprintf. This would > remove the need to use vsnprintf and all the va_ machinery which is > more than 50% of this function. > > > > +static long long > > +get_value(const LDAPMod *mod, long long def) > > +{ > > + const struct berval *bv; > > + long long val; > > + > > + if (mod == NULL) > > + return def; > > + > > + if (mod->mod_vals.modv_bvals == NULL) > > + return def; > > + > > + bv = mod->mod_vals.modv_bvals[0]; > > + if (bv == NULL) > > + return def; > > In general (here and elsewhere) I prefer to always use {} in if clauses. > I have been bitten enough time by people adding an instruction that > should be in the braces but forgot to add braces (defensive programming > style). But up to you. > > > + char buf[bv->bv_len + 1]; > > + memcpy(buf, bv->bv_val, bv->bv_len); > > + buf[sizeof(buf)-1] = '\0'; > > + > > + val = strtoll(buf, NULL, 10); > > + if (val == LLONG_MIN || val == LLONG_MAX) > > + return def; > > + > > + return val; > > +} > > + > > +static struct berval ** > > +make_berval_array(long long value) > > +{ > > + struct berval **bvs; > > + > > + bvs = ch_calloc(2, struct berval*); > > + bvs[0] = ch_malloc(struct berval); > > + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > > + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > > + > > + return bvs; > > +} > > + > > +static LDAPMod * > > +make_ldapmod(int op, const char *attr, long long value) > > +{ > > + LDAPMod *mod; > > + > > + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > > + mod->mod_op = op | LDAP_MOD_BVALUES; > > + mod->mod_type = slapi_ch_strdup(attr); > > + mod->mod_bvalues = make_berval_array(value); > > + > > + return mod; > > +} > > + > > +static void > > +convert_ldapmod_to_bval(LDAPMod *mod) > > +{ > > + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > > + return; > > + > > + mod->mod_op |= LDAP_MOD_BVALUES; > > + > > + if (mod->mod_values == NULL) { > > + mod->mod_bvalues = NULL; > > + return; > > + } > > + > > + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > > + struct berval *bv = ch_malloc(struct berval); > > + bv->bv_val = mod->mod_values[i]; > > + bv->bv_len = strlen(bv->bv_val); > > + mod->mod_bvalues[i] = bv; > > + } > > +} > > + > > +static counter > > +get_counter(Slapi_Entry *entry, const char *attr) > > +{ > > + Slapi_Attr *sattr = NULL; > > + > > + return (counter) { > > + slapi_entry_attr_find(entry, attr, &sattr) == 0, > > + slapi_entry_attr_get_longlong(entry, attr) > > + }; > > +} > > + > > +static void > > +berval_free_array(struct berval ***bvals) > > +{ > > + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > > + ch_free((*bvals)[i]->bv_val); > > + ch_free((*bvals)[i]); > > + } > > + > > + slapi_ch_free((void**) bvals); > > +} > > + > > +static bool > > +is_replication(Slapi_PBlock *pb) > > +{ > > + int repl = 0; > > + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > > + return repl != 0; > > +} > > + > > +static const char * > > +get_attribute(Slapi_Entry *entry) > > +{ > > + static struct { > > + const char *clss; > > + const char *attr; > > + } table[] = { > > + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > > + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > > + { NULL, NULL } > > + }; > > + > > + const char *attr = NULL; > > + char **clsses = NULL; > > + > > + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > > + if (clsses == NULL) > > + return NULL; > > + > > + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > > + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > > j++) { > > + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > > + attr = table[j].attr; > > + } > > + } > > + > > + slapi_ch_array_free(clsses); > > + return attr; > > +} > > Can you put a comment here that explains what you are going to do in > each cases in plain English ? This will help people in future figuring > out if/how to modify the code or why something happens a specific way. > It will also help the reviewer follow what is going on. > > > > +static int > > +preop_mod(Slapi_PBlock *pb) > > +{ > > + size_t count = 0, attrs = 0, extras = 0; > > + Slapi_Entry *entry = NULL; > > + const char *attr = NULL; > > + LDAPMod **inmods = NULL; > > + LDAPMod **mods = NULL; > > + counter ctr, orig; > > + > > + /* Get the input values. */ > > + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > > + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > > + if (entry == NULL || inmods == NULL) > > + return 0; > > + > > + /* Get the attribute name. */ > > + attr = get_attribute(entry); > > + if (attr == NULL) > > + return 0; /* Not a token. */ > > + > > + /* Count items. */ > > + while (inmods != NULL && inmods[count] != NULL) { > > ^^ this one would read much better as: > for (count = 0; inmods[count] != NULL; count++) { > > You do not need to check for insmods != NULL as you already check for > it and return 0 a few lines above. > > > + LDAPMod *mod = inmods[count++]; > > + > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > + continue; > > + > > + attrs++; > > + switch (mod->mod_op & LDAP_MOD_OP) { > > + case LDAP_MOD_REPLACE: > > + case LDAP_MOD_INCREMENT: > > + extras++; > > + break; > > + } > > + } > > + > > + /* Not operating on the counter/watermark. */ > > + if (attrs == 0) > > + return 0; > > + > > + /* Get the counter. */ > > + orig = ctr = get_counter(entry, attr); > > + > > + /* Filter the modify operations. */ > > + mods = ch_calloc(count + extras + 1, LDAPMod*); > > + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > > mods[j++] = inmods[i++]) { > > Please remove check for insmods != NULL, it is useless, and removing it > will bring back the line under 80columns > > > + LDAPMod *mod = inmods[i]; > > + > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > + continue; > > + > > + convert_ldapmod_to_bval(mod); > > + > > + switch (mod->mod_op & LDAP_MOD_OP) { > > + case LDAP_MOD_DELETE: > > + ctr.exists = false; > > + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > > NULL) > > + berval_free_array(&mod->mod_bvalues); > > + > > + if (is_replication(pb)) > > + berval_free_array(&mod->mod_bvalues); > > + > > + if (mod->mod_bvalues == NULL) > > + mod->mod_bvalues = make_berval_array(ctr.value); > > + break; > > I am not sure I understand this segment, why are you touching the > delete operation outside of a replication event ? > Doesn't this defeat and admin tool trying to correctly delete/add to > avoid races ? > > > + case LDAP_MOD_INCREMENT: > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > ctr.value); + > > + ctr.value += get_value(mod, 1); > > uhmmm if you had an ADD followed by INCREMENT operation, would this > cause the value to become value*2+1 instead of just value+1 ? > > > + berval_free_array(&mod->mod_bvalues); > > + mod->mod_op &= ~LDAP_MOD_OP; > > + mod->mod_op |= LDAP_MOD_ADD; > > + mod->mod_bvalues = make_berval_array(ctr.value); > > + break; > > uhmm why are you converting mod_increment in all cases ? (including > replication) > > > + case LDAP_MOD_REPLACE: > > + if (ctr.exists) > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > ctr.value); + > > + mod->mod_op &= ~LDAP_MOD_OP; > > + mod->mod_op |= LDAP_MOD_ADD; > > same question here, why are you converting a replace coming from > replication into a delete/add ? > > > + case LDAP_MOD_ADD: > > + ctr.value = get_value(mod, 0); > > + ctr.exists = true; > > + break; > > + } > > + } > > + > > + /* Set the modified operations. */ > > + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > > + ch_free(inmods); > > + > > + /* Ensure we aren't deleting the counter. */ > > + if (orig.exists && !ctr.exists) > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > + "Will not delete %s", attr); > > + > > + /* Ensure we aren't rolling back the counter. */ > > + if (orig.value > ctr.value) > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > + "Will not decrement %s", attr); > > + > > + return 0; > > +} > > > see above about send_error(). > > I think what is needed most is the comment that explains the process > at the to of the main function. > > Simo. All of the above are fixed. Also, I have addressed Thierry's concern about putting the plugin in betxnpreoperation by splitting the plugin into two phases: modification and validation. Now all modifications occur in bepreoperation and all validation occurs in betxnpreoperation. Additionally, I have new code to trigger a new replication in the case where a validation error occurs and we are in a replication transaction. Thus, when A attempts to push an old counter value to B, B will now replicate the latest value back to A. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.4-Create-ipa-otp-decrement-389DS-plugin.patch Type: text/x-patch Size: 35105 bytes Desc: not available URL: From npmccallum at redhat.com Mon Sep 29 18:38:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 29 Sep 2014 14:38:50 -0400 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <54241568.4000107@redhat.com> References: <1411149239.18665.7.camel@redhat.com> <54241568.4000107@redhat.com> Message-ID: <1412015930.18502.9.camel@redhat.com> On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote: > On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: > > > This prevents synchronization when an authentication collision occurs. > > > > https://fedorahosted.org/freeipa/ticket/4493 > > > > NOTE: this patch is related to the above ticket, but does not solve it. > > For the solution, please see patch 0064. This behavior fix is from patch > > 0062 (rescinded) and is worth keeping. > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello Nathaniel, > . > My understanding is that during a pre_bind, the plugins > validates token codes (for example "HOTP") checking that step > ranges [-25..+25]. > As soon as the token is valid, the new HOTPcounter is written > in the entry. > But in case of negative steps,I believe the otp-decrement > plugin will reject this update. HOTP never goes backwards. See line 188 in libotp.c. Even if this check weren't present, we would *want* the decrement plugin to reject the update. > If TOTPwatermark is updated and there is a second token code, > then clockOffset is also updated. > This update is done during a pre_bind, so if there are > parallel binds on the server, there is a possibility that > TOTPwatermark is updated from a bind and 'clockOffset' updated > from an other bind. > An option is to do a single internal modify to update both. We don't care about atomicity in this case. If two TOTP synchronizations occur at almost the same time, the value of clockOffset will be written twice with the same value. Since the values are the same, we don't care which value gets written first. Nathaniel From pviktori at redhat.com Mon Sep 29 21:02:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Sep 2014 23:02:16 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <54296D63.8010505@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> <5425A501.4030909@redhat.com> <54296D63.8010505@redhat.com> Message-ID: <5429C8D8.90904@redhat.com> On 09/29/2014 04:32 PM, Jan Cholasta wrote: > Dne 26.9.2014 v 19:40 Jan Cholasta napsal(a): >> Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): >>> Petr Viktorin wrote: >>>> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches fix >>>>> >>>>> and . >>>>> >>>>> (Note that design page for this is TBD.) >>> >> IMO it's OK to just remove them, as they were added during 4.1 >> development and are not available in any released version of IPA. >> Ah, OK > > Added patch 341 for stricter CA certificate validation which fixes > . > > Updated patches attached. > I didn't find any more issues, except of course the missing design page and tests. Any ETA on those? -- Petr? From redhatrises at gmail.com Tue Sep 30 03:13:19 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 29 Sep 2014 21:13:19 -0600 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: References: Message-ID: Updated patch to fix merge conflicts from recent changes. On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford wrote: > Hello, > > Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know if I > missed any. > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0033-2-Remove-trivial-path-constants-from-modules.patch Type: text/x-patch Size: 69690 bytes Desc: not available URL: From mkosek at redhat.com Tue Sep 30 06:28:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 08:28:40 +0200 Subject: [Freeipa-devel] [PATCH 0067] Use stack allocation when writing values during otp auth In-Reply-To: <5429826C.2070902@redhat.com> References: <1411148975.18665.5.camel@redhat.com> <54240076.80001@redhat.com> <1412005549.18502.2.camel@redhat.com> <5429826C.2070902@redhat.com> Message-ID: <542A4D98.2070206@redhat.com> On 09/29/2014 06:01 PM, thierry bordaz wrote: > On 09/29/2014 05:45 PM, Nathaniel McCallum wrote: >> On Thu, 2014-09-25 at 13:45 +0200, thierry bordaz wrote: >>> On 09/19/2014 07:49 PM, Nathaniel McCallum wrote: >>> >>>> This is an optimization from patch 0062 (rescinded) which I think is >>>> worth keeping. There is no ticket for this. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Hello, >>> >>> That is exact that slapi* are doing a intensive usage of the >>> of alloc/free. Using a stack allocated mods would reduce the >>> number of alloc/free but I afraid it will not have a >>> significant impact. For example further slapi_modify_internal >>> is doing tons of alloc/free. >>> Also I think it is not possible to use stack allocated mods. >>> In fact mods will be modified by internal_mod (for example to >>> add 'modifytimestamp', 'modifiersname') and mods will be >>> reallocated. This could also occurs from plugins. >>> Finally if a modify retry occurs, the original mods are >>> freeed. >> See ldap/servers/slapd/task.c. In this file, everything is stack >> allocated except for the value itself. >> > Hi Nathaniel, > > Yes you are correct. This is even a common method :-[ > In fact the mods are duplicated/replaced by normalized one at the > begining of modify_internal_pb. > This is that duplicated ones that can later be extended/freed. > > Sorry for the noise. The fix is valid. Ack. > > thanks > thierry Pushed to: master: 35ec0f7e3d9832c9b687bb01561a10e0304dfa74 ipa-4-1: ada187f66f3e51467aaf9bd21f74198b73805c3e Martin From mkosek at redhat.com Tue Sep 30 06:35:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 08:35:48 +0200 Subject: [Freeipa-devel] [PATCH 130] extdom: add support for new version In-Reply-To: <20140929170149.GH3165@hendrix.brq.redhat.com> References: <20140923151101.GE2947@localhost.localdomain> <20140924132354.GF31763@hendrix.brq.redhat.com> <20140925114600.GD3987@localhost.localdomain> <20140929161521.GF3237@localhost.localdomain> <20140929161629.GG3237@localhost.localdomain> <20140929170149.GH3165@hendrix.brq.redhat.com> Message-ID: <542A4F44.3060102@redhat.com> On 09/29/2014 07:01 PM, Jakub Hrozek wrote: > On Mon, Sep 29, 2014 at 06:16:30PM +0200, Sumit Bose wrote: >>> Hi, >>> >>> Jakub found another issue which is fixed with this new version. >>> >>> bye, >>> Sumit >> >> and now with patch ... > > Thank you, > > ACK Pushed to: master: 3c75b9171e5721097f6ba2855e41f0e4129b907b ipa-4-1: 2006d8759b767364031052480a3fc8947dea0998 Martin From mkosek at redhat.com Tue Sep 30 07:00:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 09:00:05 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <5429C8D8.90904@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> <5425A501.4030909@redhat.com> <54296D63.8010505@redhat.com> <5429C8D8.90904@redhat.com> Message-ID: <542A54F5.5060408@redhat.com> On 09/29/2014 11:02 PM, Petr Viktorin wrote: > On 09/29/2014 04:32 PM, Jan Cholasta wrote: >> Dne 26.9.2014 v 19:40 Jan Cholasta napsal(a): >>> Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): >>>> Petr Viktorin wrote: >>>>> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix >>>>>> >>>>>> and . >>>>>> >>>>>> (Note that design page for this is TBD.) >>>> > >>> IMO it's OK to just remove them, as they were added during 4.1 >>> development and are not available in any released version of IPA. >>> > > Ah, OK > >> >> Added patch 341 for stricter CA certificate validation which fixes >> . >> >> Updated patches attached. >> > > > I didn't find any more issues I understood that as an ACK, so I pushed to master, ipa-4-1 (to expedite preparations for 4.1 Alpha). I just had to do a minor conflict resolution for master branch. > except of course the missing design page and > tests. Any ETA on those? Right, this is still a work to do. I saw Honza created http://www.freeipa.org/page/V4/Installer_CA_options_usability_improvements but it still misses the content. If there are missing tests, please file a ticket so that we have the deficiency tracked. Martin From mkosek at redhat.com Tue Sep 30 07:01:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 09:01:59 +0200 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: References: Message-ID: <542A5567.4050807@redhat.com> Hello Gabe, Thanks for the patch! And thank you for being patient, most people are focusing on wrapping up FreeIPA 4.1 release, so the review forces are limited. Martin On 09/30/2014 05:13 AM, Gabe Alford wrote: > Updated patch to fix merge conflicts from recent changes. > > On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford wrote: > >> Hello, >> >> Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know if I >> missed any. >> >> Thanks, >> >> Gabe > From mkosek at redhat.com Tue Sep 30 07:51:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 09:51:49 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <542A54F5.5060408@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> <5425A501.4030909@redhat.com> <54296D63.8010505@redhat.com> <5429C8D8.90904@redhat.com> <542A54F5.5060408@redhat.com> Message-ID: <542A6115.7020402@redhat.com> On 09/30/2014 09:00 AM, Martin Kosek wrote: > On 09/29/2014 11:02 PM, Petr Viktorin wrote: >> On 09/29/2014 04:32 PM, Jan Cholasta wrote: >>> Dne 26.9.2014 v 19:40 Jan Cholasta napsal(a): >>>> Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): >>>>> Petr Viktorin wrote: >>>>>> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patches fix >>>>>>> >>>>>>> and . >>>>>>> >>>>>>> (Note that design page for this is TBD.) >>>>> >> >>>> IMO it's OK to just remove them, as they were added during 4.1 >>>> development and are not available in any released version of IPA. >>>> >> >> Ah, OK >> >>> >>> Added patch 341 for stricter CA certificate validation which fixes >>> . >>> >>> Updated patches attached. >>> >> >> >> I didn't find any more issues > > I understood that as an ACK, so I pushed to master, ipa-4-1 (to expedite > preparations for 4.1 Alpha). I just had to do a minor conflict resolution for > master branch. Umh, and also had to fix a subsequent error caused by the merge - pushed as a one liner (attached). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-ImportError-in-ipa-ca-install.patch Type: text/x-patch Size: 1239 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 30 07:56:15 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 30 Sep 2014 09:56:15 +0200 Subject: [Freeipa-devel] [PATCHES 247-281] ID views - management part In-Reply-To: <54296CEC.40906@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> <54212A37.3050503@redhat.com> <54296CEC.40906@redhat.com> Message-ID: <542A621F.7010407@redhat.com> Attaching updated patchset with resolved objections from Petr^1 and Petr^3. (three more patches attached) On 09/29/2014 04:30 PM, Tomas Babej wrote: > Thanks for the review. > > Sending updated patchset, responses are inline. > > On 09/23/2014 10:07 AM, Petr Viktorin wrote: >> On 09/16/2014 01:21 PM, Tomas Babej wrote: >>> Petr, >>> >>> thanks for the review, your input is, as always, much to the point. >>> >>> My responses are inline. Also, I'm attaching a new patchset, rebased on >>> master, please, have a look at that. >>> >>> Most of the patches have at least minor changes, since I rebased >>> another >>> ~15 patches into this patchset, and there are additional 9 patches on >>> top. Patch 254 was deprecated, as we decided to go with more explicit >>> way of having two separate commands for user and group ID overrides. >>> >>> Also, the test suite (around 80 tests) for ID views is attached - patch >>> 270. It depends on patch 269, sent in separate thread. >>> >>> Tomas >>> >>> On 09/10/2014 03:10 PM, Petr Viktorin wrote: >>>> On 08/01/2014 12:30 PM, Tomas Babej wrote: >>>>> 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. >>>>> >>>> >>>> Not tested yet, but here are my comments on the patches: >>>> >> >> 0247 looks good >> >> In 0248 you deleted a newline at EOF in 71-idviews.update >> >> 0249 looks good >> >>>> >>>> 0250: >>>> With so many names imported from one module, I find it more readable >>>> to `from ipalib.plugins import baseldap`, and use qualified names >>>> later. Same in the 2 other patches. >>>> This is personal preference/tip, feel free to disagree :) >>> >>> I was just trying to be consistent here, rest of the IPA plugins >>> seem to >>> use non-qualified names for plugins. Even tough the main reason is >>> probably that thay use evil star imports :) Let's keep it this way >>> for now. >> >> Yes, the rest of the plugins are using star imports; no consistency >> to be kept here. >> I think that after these patches nobody will touch it again, so "for >> now" is basically forever. >> >> 0521 looks good >> >>>> 0252: >> >>>> The pattern_errmsg in idoverride's uid should be expanded to fully >>>> describe the pattern. >>> >>> If we want to expand it, then it should be corrected in user.py plugin >>> too (I have taken it from there). Still, it's a tradeoff between >>> conciseness and and exactness, do we really want to specify that user >>> login may be at most 253 letters long or the $ character may only be >>> used as terminal one? Or the fact that - can't be used at the >>> beggining? >>> This is probably the way it was since forever in user plugin. >> >> I think the message should at be free of false positives. Using e.e. >> "-test-name-" and getting back "may only include letters, numbers, _, >> -, . and $" would be extremely frustrating. >> >> Should I file a ticket? >> >> 0253 looks good >> 0255-0256 looks good >> >>>> 0258: >>>> idview_apply: typo in hostgroup doc, should be "hosts to apply the ID >>>> view to" and "after running the idview-apply command". >>>> Typos in output params, should be e.g. "this ID view" >>> >>> Fixed the second and third complaint ( IMHO this is clear from context, >>> but I added "this" to be explicit), I'm not so sure about the first one >>> though. Can we get a native speaker input on that? >> >> Actually both just need an article, doesn't matter much if it's "the" >> or "this". >> >>>> >>>> By subclassing idview_unapply from idview_apply you're violating >>>> Liskov's substitution principle. Make a common base class for them. >>> >>> Done. >> >> In the wrong patch, it seems :) >> >>>> >>>> 0259: >>>> show_id_overrides: cn is a MUST attribute in ipa*Override; use >>>> view.single_value['cn'] instead of get(). In enumerate_hosts, is None >>>> okay if cn is missing? >>> >>> This was actually an error, fixed in updated version of patches. New >>> code uses 'ipaanchoruuid' (which is a MUST) and converts it (with your >>> objections addressed.) >> >> If it's MUST, use simply `single_value['ipaanchoruuid']` instead of >> get(). >> > Yes, this is fixed in a later patch. > > > >> >> 0260: >> The get() method on dict-like objects returns None (or a given >> default) if the item is missing. >> If sAMAccountName is MUST, use regular dict item access. >> If sAMAccountName is MAY, then you're not handling the None you might >> get. > > It is a must, fixed in 260. > > > >> >> Also look at the other uses of get() to see if you're doing the right >> thing. > > Patch 276 makes sure this does not happen. > > > >> >> I've looked at help(pysss_nss_idmap.getnamebysid). Shouldn't you use >> pysss_nss_idmap.NAME_KEY and TYPE_KEY? > > Right. Also, there forgotten debubugging comment somehow lurked in, I > got that fixed too. > > >> >> >> 0261: >> Again you're using get() on MUST attributes. > > Fixed. > >> >> 0262: >> ipalib/constants.py - No newline at end of file > > Fixed. > > >> >> Is IPA_ANCHOR_PREFIX and SID_ANCHOR_PREFIX to be used outside >> idviews.py? Do we want it in constants? >> >>> + if anchor.startswith(IPA_ANCHOR_PREFIX): >>> + uuid = anchor.split(IPA_ANCHOR_PREFIX)[1].strip() > > I thought of constants.py as a global store for all plugin constants. > > >> >> This is a dangerous idiom to use for removing a prefix, since it will >> silently give wrong results if the string contains the prefix. Prefer: >> anchor[len(IPA_ANCHOR_PREFIX):] >> Same with SID_ANCHOR_PREFIX below. > > This cannot happen unless someone edits the raw LDAP directly, but > still, you're correct here, better not get used to using/seeing this. > Fixed in later patch, thanks. > > > >> >> In get_dn, why do you resolve only the last key? > > You can only pass two arguments to these commands, where the first one > is the name of the view, which you don't want to resolve. > > >> >> In set_anchoruuid_from_dn, an entry is a dict of lists, use either >> single_value or put the dn[0].value in brackets. > > This actually needs to stay this way, since LDAPUpdate expects a > single value, not a list. I added a comment. > > > >> >> 0263: >> >> Note that permission_filter_objectclasses are ORed together; I don't >> think you want ipaOverrideAnchor there. >> > Right, fixed. > >> You forgot to regenerate ACI.txt in this patch. >> > > True, fixed. > >> 0264 looks OK >> >> 0265: >> >> Instead of: >> >>> + objectclass, name_attr = ( >>> + ('posixaccount', 'uid') >>> + if self.override_object == 'user' else >>> + ('ipausergroup', 'cn') >>> + ) >> >> prefer: >> >> objectclass, name_attr = { >> 'user': ('posixaccount', 'uid'), >> 'group': ('ipausergroup', 'cn'), >> }[self.override_object] >> >> This generalizes better to more cases, and fails loudly on bad input. >> > Fixed. > >> You're misusing get() again. >> > Fixed. > >> 0266: >> >> To build strings, prefer formatting: >> return '%s%s:%s' % (IPA_ANCHOR_PREFIX, domain, uuid) >> rather than adding the separator to one of the strings and >> concatenating. >> > Fixed. > >> Instead of: >> anchor.split(':')[-1] >> prefer: >> anchor.rpartition(':')[-1] >> which does less work. >> > What is an ocean but a multitude of drops :) Fixed. > >> 0267: >> resolve_object_to_anchor: For the error message, use >> Object[...].handle_not_found() >> > Fixed. > >> 0268 looks good >> >> 0270: >> get_idoverride_dn: Use re.escape() when inserting literal strings in >> regexes. >> > Fixed, thanks. > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0279-4-idviews-Catch-errors-on-unsuccessful-AD-object-looku.patch Type: text/x-patch Size: 2025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0278-4-idviews-Make-sure-the-dict.get-method-is-not-abused-.patch Type: text/x-patch Size: 2229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0277-4-idviews-Handle-Default-Trust-View-properly-in-the-fr.patch Type: text/x-patch Size: 3530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0276-4-idviews-Add-Default-Trust-View-as-part-of-adtrustins.patch Type: text/x-patch Size: 3434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0275-4-idviews-Make-description-optional-for-the-ID-View-ob.patch Type: text/x-patch Size: 2826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0274-4-idviews-Fix-casing-of-ID-Views-to-be-consistent.patch Type: text/x-patch Size: 7220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0273-4-idviews-Update-the-referential-plugin-config-to-watc.patch Type: text/x-patch Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0272-4-idviews-Add-ipaOriginalUid.patch Type: text/x-patch Size: 10765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0270-4-ipatests-Add-xmlrpc-tests-for-idviews-plugin.patch Type: text/x-patch Size: 49473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0268-4-idviews-Resolve-anchors-to-object-names-in-idview-sh.patch Type: text/x-patch Size: 10987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0267-4-idviews-Raise-NotFound-errors-if-object-to-override-.patch Type: text/x-patch Size: 1541 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0266-4-idviews-Change-format-of-IPA-anchor-to-include-domai.patch Type: text/x-patch Size: 2479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0265-4-idviews-Alter-idoverride-methods-to-work-with-splitt.patch Type: text/x-patch Size: 5094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0264-4-idviews-Split-the-idoverride-commands-into-iduserove.patch Type: text/x-patch Size: 17663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0263-4-idviews-Split-the-idoverride-object-into-iduseroverr.patch Type: text/x-patch Size: 6901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0262-4-idviews-Support-specifying-object-names-instead-of-r.patch Type: text/x-patch Size: 7782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0261-4-trusts-Add-conversion-from-SID-to-object-name.patch Type: text/x-patch Size: 3139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0259-4-idviews-Extend-idview-show-command-to-display-assign.patch Type: text/x-patch Size: 8412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0258-4-idviews-Add-ipa-idview-apply-and-idview-unapply-comm.patch Type: text/x-patch Size: 9584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0257-4-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-0256-4-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-0255-4-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-0253-4-idvies-Add-managed-permissions-for-idview-and-idover.patch Type: text/x-patch Size: 4094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0252-4-idviews-Create-basic-idview-plugin-structure.patch Type: text/x-patch Size: 17680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0251-4-ipalib-PEP8-fixes-for-host-plugin.patch Type: text/x-patch Size: 6958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0250-4-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-0249-4-idviews-Add-ipaAssignedIDVIew-reference-to-the-host-.patch Type: text/x-patch Size: 9760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0248-4-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-0247-4-idviews-Add-necessary-schema-for-the-ID-views.patch Type: text/x-patch Size: 4751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0280-4-idviews-Display-the-list-of-hosts-when-using-all.patch Type: text/x-patch Size: 1603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0282-4-idviews-Create-Default-Trust-View-for-upgraded-serve.patch Type: text/x-patch Size: 2542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0281-4-idviews-Make-sure-only-regular-IPA-objects-are-allow.patch Type: text/x-patch Size: 1614 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 30 07:59:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Sep 2014 09:59:19 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <54298455.7020601@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> <54296010.1000705@redhat.com> <54298455.7020601@redhat.com> Message-ID: <542A62D7.2040204@redhat.com> Dne 29.9.2014 v 18:09 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>>>> management and renewal code. Related tickets: >>>>>>>> , >>>>>>>> . >>>>>>>> >>>>>>>> (Patch 319 was originally posted at >>>>>>>> .) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Only two of the patches includes what ticket(s) they address. Most >>>>>>> have >>>>>>> the tersest of commit messages. If got more and more difficult to see >>>>>>> why the changes were needed at all, as you'll see. >>>>>> >>>>>> Sorry, fixed (hopefully). >>>>>> >>>>>> Note that most of these patches fix stuff I didn't have time to fix >>>>>> before I posted the original CA management patches, hence the missing >>>>>> tickets. >>>>> >>>>> Well, the policy is that every commit should have a ticket. So I guess >>>>> re-open the old tickets or open new ones. This will help someone in the >>>>> future know the "why" of a patch. I've certainly been guilty >>>> >>>> OK, I will reopen the related tickets. >>>> >>>>> >>>>> Here is a new set of reviews as trying to intermingle was making my >>>>> eyes >>>>> cross: >>>>> >>>>> 319: >>>>> >>>>> I guess I still don't understand why you can't pull the certs out of >>>>> LDAP when creating this database. When this code runs, we know that the >>>>> client is configured, so we have access to authentication. Why can't >>>>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>>>> and the code is already written in ipa-client-install to do this. >>>> >>>> Well, I don't understand why do you want them to be updated so much, as >>>> nothing will break if they are not. Also try to imagine what would >>>> happen if, say, 10k clients were updated at the same moment... >>> >>> What's the point of a database missing certificates? >> >> It won't be missing any certificates if /etc/pki/nssdb was not missing >> any certificates before the update. >> >> As I said, the update will not break anything. It will not fix anything >> either, but I don't think this kind of fixing should be done during >> client RPM upgrade. It is not consistent with anything else we do during >> client RPM upgrade, it does not scale well and it just does not feel >> right to me in overall. > > Ok, I'll concede the point that there is no difference post-update, but > it doesn't do what ipa-certupdate does. You can potentially end up with > a completely diffferent set of certificates. So why the difference? If you end up with a *completely* different set of certificates, it's because the admins screwed up, so it's theirs responsibility to fix it, not ours IMHO. > > Post install of new client bits: > > # certutil -L -d /etc/ipa/nssdb/ > > IPA CA CT,C,C > > After running ipa-certupdate: > > # certutil -L -d /etc/ipa/nssdb/ > > CN=Primary CA,O=example.com,C=US ,, > CN=Secondary CA,O=example.com,C=US ,, > GREYOAK.COM IPA CA CT,C,C > > Quite the difference. Not much of a difference when you realize that "IPA CA" and "GREYOAK.COM IPA CA" are the same certificate and the rest are there just for completeness. > > I'll ACK for now since this doesn't materially change anything and > shouldn't break any installs but it begs the question of why it is > acceptable now but not acceptable to make ipa-certupdate do the same. I have changed the NSS database used by the RPC code from /etc/pki/nssdb to /etc/ipa/nssdb. What the RPM update does is a necessary configuration update to keep RPC working. ipa-certupdate on the other hand fetches new policy from the server, which is quite a different thing IMO. > > So ACK for 319, 324-331, 340. Thanks! > >> >> The LDAP update happens in renew_ca_cert. Are there any relevant errors >> in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the >> master entry of the master where you run ipa-cacert-manage renew? > > Sep 25 16:06:44 grindle renew_ca_cert: Traceback (most recent call last): > File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 214, in > main() > File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 79, in main > ca = cainstance.CAInstance(host_name=api.env.host, ldapi=False) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 357, in __init__ > self.ra_agent_pwd = self.ra_agent_db + "/pwdfile.txt" > TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' > Sep 25 16:06:44 grindle certmonger: Certificate named "caSigningCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/etc/pki/pki-tomcat/alias" issued by CA and saved. One of the KRA patches broke this. I assumed you'd be testing on top of ipa-4-1, so I didn't fix it, sorry. See the attached patch 342 for a fix. Martin, can you please review it? > > rob > The patches needed a rebase, attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-319.4-Introduce-NSS-database-etc-ipa-nssdb.patch Type: text/x-patch Size: 16042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-324.3-Move-NSSDatabase-from-ipaserver.certs-to-ipapython.c.patch Type: text/x-patch Size: 37116 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-325.3-Add-NSSDatabase.has_nickname-for-checking-nickname-p.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-326.3-Use-NSSDatabase-instead-of-direct-certutil-calls-in-.patch Type: text/x-patch Size: 9212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-327.3-Use-etc-ipa-nssdb-to-get-nicknames-of-IPA-certs-inst.patch Type: text/x-patch Size: 8895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-328.3-Check-if-IPA-client-is-configured-in-ipa-certupdate.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-329.3-Get-server-hostname-from-jsonrpc_uri-in-ipa-certupda.patch Type: text/x-patch Size: 1209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-330.3-Remove-ipa-ca.crt-from-systemwide-CA-store-on-client.patch Type: text/x-patch Size: 4461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-331.3-Fix-certmonger.wait_for_request.patch Type: text/x-patch Size: 960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-340.2-Fix-certmonger-search-for-the-CA-cert-in-ipa-certupd.patch Type: text/x-patch Size: 1897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-342-Do-not-crash-in-CAInstance.__init__-when-default-arg.patch Type: text/x-patch Size: 1293 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 30 07:59:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 09:59:16 +0200 Subject: [Freeipa-devel] [PATCHES] 336-339 Installer certificate options usability fixes In-Reply-To: <542A54F5.5060408@redhat.com> References: <5422EDA1.4060004@redhat.com> <542582F4.9080406@redhat.com> <5425883E.6020000@redhat.com> <5425A501.4030909@redhat.com> <54296D63.8010505@redhat.com> <5429C8D8.90904@redhat.com> <542A54F5.5060408@redhat.com> Message-ID: <542A62D4.3060409@redhat.com> On 09/30/2014 09:00 AM, Martin Kosek wrote: > On 09/29/2014 11:02 PM, Petr Viktorin wrote: >> On 09/29/2014 04:32 PM, Jan Cholasta wrote: >>> Dne 26.9.2014 v 19:40 Jan Cholasta napsal(a): >>>> Dne 26.9.2014 v 17:37 Rob Crittenden napsal(a): >>>>> Petr Viktorin wrote: >>>>>> On 09/24/2014 06:13 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patches fix >>>>>>> >>>>>>> and . >>>>>>> >>>>>>> (Note that design page for this is TBD.) >>>>> >> >>>> IMO it's OK to just remove them, as they were added during 4.1 >>>> development and are not available in any released version of IPA. >>>> >> >> Ah, OK >> >>> >>> Added patch 341 for stricter CA certificate validation which fixes >>> . >>> >>> Updated patches attached. >>> >> >> >> I didn't find any more issues > > I understood that as an ACK, so I pushed to master, ipa-4-1 (to expedite > preparations for 4.1 Alpha). I just had to do a minor conflict resolution for > master branch. > >> except of course the missing design page and >> tests. Any ETA on those? > > Right, this is still a work to do. I saw Honza created > http://www.freeipa.org/page/V4/Installer_CA_options_usability_improvements > but it still misses the content. > > If there are missing tests, please file a ticket so that we have the deficiency > tracked. https://fedorahosted.org/freeipa/ticket/4588 -- Petr? From mkosek at redhat.com Tue Sep 30 08:09:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 10:09:08 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <542A62D7.2040204@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> <54296010.1000705@redhat.com> <54298455.7020601@redhat.com> <542A62D7.2040204@redhat.com> Message-ID: <542A6524.1050405@redhat.com> On 09/30/2014 09:59 AM, Jan Cholasta wrote: > Dne 29.9.2014 v 18:09 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>>>>> management and renewal code. Related tickets: >>>>>>>>> , >>>>>>>>> . >>>>>>>>> >>>>>>>>> (Patch 319 was originally posted at >>>>>>>>> .) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Only two of the patches includes what ticket(s) they address. Most >>>>>>>> have >>>>>>>> the tersest of commit messages. If got more and more difficult to see >>>>>>>> why the changes were needed at all, as you'll see. >>>>>>> >>>>>>> Sorry, fixed (hopefully). >>>>>>> >>>>>>> Note that most of these patches fix stuff I didn't have time to fix >>>>>>> before I posted the original CA management patches, hence the missing >>>>>>> tickets. >>>>>> >>>>>> Well, the policy is that every commit should have a ticket. So I guess >>>>>> re-open the old tickets or open new ones. This will help someone in the >>>>>> future know the "why" of a patch. I've certainly been guilty >>>>> >>>>> OK, I will reopen the related tickets. >>>>> >>>>>> >>>>>> Here is a new set of reviews as trying to intermingle was making my >>>>>> eyes >>>>>> cross: >>>>>> >>>>>> 319: >>>>>> >>>>>> I guess I still don't understand why you can't pull the certs out of >>>>>> LDAP when creating this database. When this code runs, we know that the >>>>>> client is configured, so we have access to authentication. Why can't >>>>>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>>>>> and the code is already written in ipa-client-install to do this. >>>>> >>>>> Well, I don't understand why do you want them to be updated so much, as >>>>> nothing will break if they are not. Also try to imagine what would >>>>> happen if, say, 10k clients were updated at the same moment... >>>> >>>> What's the point of a database missing certificates? >>> >>> It won't be missing any certificates if /etc/pki/nssdb was not missing >>> any certificates before the update. >>> >>> As I said, the update will not break anything. It will not fix anything >>> either, but I don't think this kind of fixing should be done during >>> client RPM upgrade. It is not consistent with anything else we do during >>> client RPM upgrade, it does not scale well and it just does not feel >>> right to me in overall. >> >> Ok, I'll concede the point that there is no difference post-update, but >> it doesn't do what ipa-certupdate does. You can potentially end up with >> a completely diffferent set of certificates. So why the difference? > > If you end up with a *completely* different set of certificates, it's because > the admins screwed up, so it's theirs responsibility to fix it, not ours IMHO. > >> >> Post install of new client bits: >> >> # certutil -L -d /etc/ipa/nssdb/ >> >> IPA CA CT,C,C >> >> After running ipa-certupdate: >> >> # certutil -L -d /etc/ipa/nssdb/ >> >> CN=Primary CA,O=example.com,C=US ,, >> CN=Secondary CA,O=example.com,C=US ,, >> GREYOAK.COM IPA CA CT,C,C >> >> Quite the difference. > > Not much of a difference when you realize that "IPA CA" and "GREYOAK.COM IPA > CA" are the same certificate and the rest are there just for completeness. > >> >> I'll ACK for now since this doesn't materially change anything and >> shouldn't break any installs but it begs the question of why it is >> acceptable now but not acceptable to make ipa-certupdate do the same. > > I have changed the NSS database used by the RPC code from /etc/pki/nssdb to > /etc/ipa/nssdb. What the RPM update does is a necessary configuration update to > keep RPC working. ipa-certupdate on the other hand fetches new policy from the > server, which is quite a different thing IMO. > >> >> So ACK for 319, 324-331, 340. > > Thanks! > >> >>> >>> The LDAP update happens in renew_ca_cert. Are there any relevant errors >>> in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the >>> master entry of the master where you run ipa-cacert-manage renew? >> >> Sep 25 16:06:44 grindle renew_ca_cert: Traceback (most recent call last): >> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 214, in >> main() >> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 79, in main >> ca = cainstance.CAInstance(host_name=api.env.host, ldapi=False) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 357, in __init__ >> self.ra_agent_pwd = self.ra_agent_db + "/pwdfile.txt" >> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >> Sep 25 16:06:44 grindle certmonger: Certificate named "caSigningCert >> cert-pki-ca" in token "NSS Certificate DB" in database >> "/etc/pki/pki-tomcat/alias" issued by CA and saved. > > One of the KRA patches broke this. I assumed you'd be testing on top of > ipa-4-1, so I didn't fix it, sorry. See the attached patch 342 for a fix. > Martin, can you please review it? > >> >> rob >> > > The patches needed a rebase, attached. > Thanks to both for this work! I pushed all patches that Rob reviewer to master and ipa-4-1. I also checked Jan's fix up patch 342 and it looks good to me as well. ACK for that and pushed to master. Martin From jcholast at redhat.com Tue Sep 30 08:19:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Sep 2014 10:19:06 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <542A6524.1050405@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> <54296010.1000705@redhat.com> <54298455.7020601@redhat.com> <542A62D7.2040204@redhat.com> <542A6524.1050405@redhat.com> Message-ID: <542A677A.9060006@redhat.com> Dne 30.9.2014 v 10:09 Martin Kosek napsal(a): > On 09/30/2014 09:59 AM, Jan Cholasta wrote: >> Dne 29.9.2014 v 18:09 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>>>>>> management and renewal code. Related tickets: >>>>>>>>>> , >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> (Patch 319 was originally posted at >>>>>>>>>> .) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Only two of the patches includes what ticket(s) they address. Most >>>>>>>>> have >>>>>>>>> the tersest of commit messages. If got more and more difficult to see >>>>>>>>> why the changes were needed at all, as you'll see. >>>>>>>> >>>>>>>> Sorry, fixed (hopefully). >>>>>>>> >>>>>>>> Note that most of these patches fix stuff I didn't have time to fix >>>>>>>> before I posted the original CA management patches, hence the missing >>>>>>>> tickets. >>>>>>> >>>>>>> Well, the policy is that every commit should have a ticket. So I guess >>>>>>> re-open the old tickets or open new ones. This will help someone in the >>>>>>> future know the "why" of a patch. I've certainly been guilty >>>>>> >>>>>> OK, I will reopen the related tickets. >>>>>> >>>>>>> >>>>>>> Here is a new set of reviews as trying to intermingle was making my >>>>>>> eyes >>>>>>> cross: >>>>>>> >>>>>>> 319: >>>>>>> >>>>>>> I guess I still don't understand why you can't pull the certs out of >>>>>>> LDAP when creating this database. When this code runs, we know that the >>>>>>> client is configured, so we have access to authentication. Why can't >>>>>>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>>>>>> and the code is already written in ipa-client-install to do this. >>>>>> >>>>>> Well, I don't understand why do you want them to be updated so much, as >>>>>> nothing will break if they are not. Also try to imagine what would >>>>>> happen if, say, 10k clients were updated at the same moment... >>>>> >>>>> What's the point of a database missing certificates? >>>> >>>> It won't be missing any certificates if /etc/pki/nssdb was not missing >>>> any certificates before the update. >>>> >>>> As I said, the update will not break anything. It will not fix anything >>>> either, but I don't think this kind of fixing should be done during >>>> client RPM upgrade. It is not consistent with anything else we do during >>>> client RPM upgrade, it does not scale well and it just does not feel >>>> right to me in overall. >>> >>> Ok, I'll concede the point that there is no difference post-update, but >>> it doesn't do what ipa-certupdate does. You can potentially end up with >>> a completely diffferent set of certificates. So why the difference? >> >> If you end up with a *completely* different set of certificates, it's because >> the admins screwed up, so it's theirs responsibility to fix it, not ours IMHO. >> >>> >>> Post install of new client bits: >>> >>> # certutil -L -d /etc/ipa/nssdb/ >>> >>> IPA CA CT,C,C >>> >>> After running ipa-certupdate: >>> >>> # certutil -L -d /etc/ipa/nssdb/ >>> >>> CN=Primary CA,O=example.com,C=US ,, >>> CN=Secondary CA,O=example.com,C=US ,, >>> GREYOAK.COM IPA CA CT,C,C >>> >>> Quite the difference. >> >> Not much of a difference when you realize that "IPA CA" and "GREYOAK.COM IPA >> CA" are the same certificate and the rest are there just for completeness. >> >>> >>> I'll ACK for now since this doesn't materially change anything and >>> shouldn't break any installs but it begs the question of why it is >>> acceptable now but not acceptable to make ipa-certupdate do the same. >> >> I have changed the NSS database used by the RPC code from /etc/pki/nssdb to >> /etc/ipa/nssdb. What the RPM update does is a necessary configuration update to >> keep RPC working. ipa-certupdate on the other hand fetches new policy from the >> server, which is quite a different thing IMO. >> >>> >>> So ACK for 319, 324-331, 340. >> >> Thanks! >> >>> >>>> >>>> The LDAP update happens in renew_ca_cert. Are there any relevant errors >>>> in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the >>>> master entry of the master where you run ipa-cacert-manage renew? >>> >>> Sep 25 16:06:44 grindle renew_ca_cert: Traceback (most recent call last): >>> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 214, in >>> main() >>> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 79, in main >>> ca = cainstance.CAInstance(host_name=api.env.host, ldapi=False) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>> 357, in __init__ >>> self.ra_agent_pwd = self.ra_agent_db + "/pwdfile.txt" >>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> Sep 25 16:06:44 grindle certmonger: Certificate named "caSigningCert >>> cert-pki-ca" in token "NSS Certificate DB" in database >>> "/etc/pki/pki-tomcat/alias" issued by CA and saved. >> >> One of the KRA patches broke this. I assumed you'd be testing on top of >> ipa-4-1, so I didn't fix it, sorry. See the attached patch 342 for a fix. >> Martin, can you please review it? >> >>> >>> rob >>> >> >> The patches needed a rebase, attached. >> > > Thanks to both for this work! I pushed all patches that Rob reviewer to master > and ipa-4-1. > > I also checked Jan's fix up patch 342 and it looks good to me as well. > > ACK for that and pushed to master. > > Martin > I did a lousy job at rebasing the patches, sorry. The attached patch fixes it. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-343-Add-missing-imports-to-ipapython.certdb.patch Type: text/x-patch Size: 791 bytes Desc: not available URL: From mkosek at redhat.com Tue Sep 30 08:20:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 10:20:42 +0200 Subject: [Freeipa-devel] [PATCHES] 319, 324-335 CA management and renewal fixes In-Reply-To: <542A677A.9060006@redhat.com> References: <5420121C.3050907@redhat.com> <5421BE54.8050802@redhat.com> <542301C2.5060200@redhat.com> <5425828D.5020508@redhat.com> <5425A843.1060007@redhat.com> <5429591B.5060700@redhat.com> <54296010.1000705@redhat.com> <54298455.7020601@redhat.com> <542A62D7.2040204@redhat.com> <542A6524.1050405@redhat.com> <542A677A.9060006@redhat.com> Message-ID: <542A67DA.6090502@redhat.com> On 09/30/2014 10:19 AM, Jan Cholasta wrote: > Dne 30.9.2014 v 10:09 Martin Kosek napsal(a): >> On 09/30/2014 09:59 AM, Jan Cholasta wrote: >>> Dne 29.9.2014 v 18:09 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 29.9.2014 v 15:05 Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 26.9.2014 v 17:13 Rob Crittenden napsal(a): >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 23.9.2014 v 20:39 Rob Crittenden napsal(a): >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> the attached patches fix various bugs and shortcomings in the CA >>>>>>>>>>> management and renewal code. Related tickets: >>>>>>>>>>> , >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> (Patch 319 was originally posted at >>>>>>>>>>> .) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Only two of the patches includes what ticket(s) they address. Most >>>>>>>>>> have >>>>>>>>>> the tersest of commit messages. If got more and more difficult to see >>>>>>>>>> why the changes were needed at all, as you'll see. >>>>>>>>> >>>>>>>>> Sorry, fixed (hopefully). >>>>>>>>> >>>>>>>>> Note that most of these patches fix stuff I didn't have time to fix >>>>>>>>> before I posted the original CA management patches, hence the missing >>>>>>>>> tickets. >>>>>>>> >>>>>>>> Well, the policy is that every commit should have a ticket. So I guess >>>>>>>> re-open the old tickets or open new ones. This will help someone in the >>>>>>>> future know the "why" of a patch. I've certainly been guilty >>>>>>> >>>>>>> OK, I will reopen the related tickets. >>>>>>> >>>>>>>> >>>>>>>> Here is a new set of reviews as trying to intermingle was making my >>>>>>>> eyes >>>>>>>> cross: >>>>>>>> >>>>>>>> 319: >>>>>>>> >>>>>>>> I guess I still don't understand why you can't pull the certs out of >>>>>>>> LDAP when creating this database. When this code runs, we know that the >>>>>>>> client is configured, so we have access to authentication. Why can't >>>>>>>> create_ipa_nssdb pull the certs directly? It seems more robust to me, >>>>>>>> and the code is already written in ipa-client-install to do this. >>>>>>> >>>>>>> Well, I don't understand why do you want them to be updated so much, as >>>>>>> nothing will break if they are not. Also try to imagine what would >>>>>>> happen if, say, 10k clients were updated at the same moment... >>>>>> >>>>>> What's the point of a database missing certificates? >>>>> >>>>> It won't be missing any certificates if /etc/pki/nssdb was not missing >>>>> any certificates before the update. >>>>> >>>>> As I said, the update will not break anything. It will not fix anything >>>>> either, but I don't think this kind of fixing should be done during >>>>> client RPM upgrade. It is not consistent with anything else we do during >>>>> client RPM upgrade, it does not scale well and it just does not feel >>>>> right to me in overall. >>>> >>>> Ok, I'll concede the point that there is no difference post-update, but >>>> it doesn't do what ipa-certupdate does. You can potentially end up with >>>> a completely diffferent set of certificates. So why the difference? >>> >>> If you end up with a *completely* different set of certificates, it's because >>> the admins screwed up, so it's theirs responsibility to fix it, not ours IMHO. >>> >>>> >>>> Post install of new client bits: >>>> >>>> # certutil -L -d /etc/ipa/nssdb/ >>>> >>>> IPA CA CT,C,C >>>> >>>> After running ipa-certupdate: >>>> >>>> # certutil -L -d /etc/ipa/nssdb/ >>>> >>>> CN=Primary CA,O=example.com,C=US ,, >>>> CN=Secondary CA,O=example.com,C=US ,, >>>> GREYOAK.COM IPA CA CT,C,C >>>> >>>> Quite the difference. >>> >>> Not much of a difference when you realize that "IPA CA" and "GREYOAK.COM IPA >>> CA" are the same certificate and the rest are there just for completeness. >>> >>>> >>>> I'll ACK for now since this doesn't materially change anything and >>>> shouldn't break any installs but it begs the question of why it is >>>> acceptable now but not acceptable to make ipa-certupdate do the same. >>> >>> I have changed the NSS database used by the RPC code from /etc/pki/nssdb to >>> /etc/ipa/nssdb. What the RPM update does is a necessary configuration update to >>> keep RPC working. ipa-certupdate on the other hand fetches new policy from the >>> server, which is quite a different thing IMO. >>> >>>> >>>> So ACK for 319, 324-331, 340. >>> >>> Thanks! >>> >>>> >>>>> >>>>> The LDAP update happens in renew_ca_cert. Are there any relevant errors >>>>> in /var/log/messages? Is there caRenewalMaster in ipaConfigString of the >>>>> master entry of the master where you run ipa-cacert-manage renew? >>>> >>>> Sep 25 16:06:44 grindle renew_ca_cert: Traceback (most recent call last): >>>> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 214, in >>>> main() >>>> File "/usr/lib64/ipa/certmonger/renew_ca_cert", line 79, in main >>>> ca = cainstance.CAInstance(host_name=api.env.host, ldapi=False) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>>> 357, in __init__ >>>> self.ra_agent_pwd = self.ra_agent_db + "/pwdfile.txt" >>>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>>> Sep 25 16:06:44 grindle certmonger: Certificate named "caSigningCert >>>> cert-pki-ca" in token "NSS Certificate DB" in database >>>> "/etc/pki/pki-tomcat/alias" issued by CA and saved. >>> >>> One of the KRA patches broke this. I assumed you'd be testing on top of >>> ipa-4-1, so I didn't fix it, sorry. See the attached patch 342 for a fix. >>> Martin, can you please review it? >>> >>>> >>>> rob >>>> >>> >>> The patches needed a rebase, attached. >>> >> >> Thanks to both for this work! I pushed all patches that Rob reviewer to master >> and ipa-4-1. >> >> I also checked Jan's fix up patch 342 and it looks good to me as well. >> >> ACK for that and pushed to master. >> >> Martin >> > > I did a lousy job at rebasing the patches, sorry. The attached patch fixes it. Ah, thanks, it fixes the issue, lint passes (/me wishes he did lint before pushing). ACK. Pushed to master, ipa-4-1. Martin From pviktori at redhat.com Tue Sep 30 08:22:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 10:22:22 +0200 Subject: [Freeipa-devel] [PATCHES 247-281] ID views - management part In-Reply-To: <542A621F.7010407@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> <54212A37.3050503@redhat.com> <54296CEC.40906@redhat.com> <542A621F.7010407@redhat.com> Message-ID: <542A683E.90609@redhat.com> On 09/30/2014 09:56 AM, Tomas Babej wrote: > Attaching updated patchset with resolved objections from Petr^1 and Petr^3. > > (three more patches attached) LGTM. (I never did functional testing for this though.) -- Petr? From pvoborni at redhat.com Tue Sep 30 08:37:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 30 Sep 2014 10:37:29 +0200 Subject: [Freeipa-devel] [PATCHES 247-281] ID views - management part In-Reply-To: <542A683E.90609@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> <54212A37.3050503@redhat.com> <54296CEC.40906@redhat.com> <542A621F.7010407@redhat.com> <542A683E.90609@redhat.com> Message-ID: <542A6BC9.5050905@redhat.com> On 30.9.2014 10:22, Petr Viktorin wrote: > On 09/30/2014 09:56 AM, Tomas Babej wrote: >> Attaching updated patchset with resolved objections from Petr^1 and >> Petr^3. >> >> (three more patches attached) > > LGTM. (I never did functional testing for this though.) > ACK 280-4, 281-4 LGTM 282-4 (not tested) -- Petr Vobornik From mkosek at redhat.com Tue Sep 30 08:43:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 10:43:23 +0200 Subject: [Freeipa-devel] [PATCHES 247-281] ID views - management part In-Reply-To: <542A6BC9.5050905@redhat.com> References: <53DB6C2E.1050501@redhat.com> <54104DE3.2050309@redhat.com> <54181D3D.9070400@redhat.com> <54212A37.3050503@redhat.com> <54296CEC.40906@redhat.com> <542A621F.7010407@redhat.com> <542A683E.90609@redhat.com> <542A6BC9.5050905@redhat.com> Message-ID: <542A6D2B.5060701@redhat.com> On 09/30/2014 10:37 AM, Petr Vobornik wrote: > On 30.9.2014 10:22, Petr Viktorin wrote: >> On 09/30/2014 09:56 AM, Tomas Babej wrote: >>> Attaching updated patchset with resolved objections from Petr^1 and >>> Petr^3. >>> >>> (three more patches attached) >> >> LGTM. (I never did functional testing for this though.) >> > > ACK 280-4, 281-4 > > LGTM 282-4 (not tested) Thanks for all for this heroic effort! :-) Pushed to: master: 2a230b6cc16037fbf56d79bfde2fb4d1ab386ef6 ipa-4-1: f0b6254106f98875e2c94af81bcb836d3ad46681 Martin From pvoborni at redhat.com Tue Sep 30 08:49:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 30 Sep 2014 10:49:40 +0200 Subject: [Freeipa-devel] [PATCH] 749-754 webui: new ID views section In-Reply-To: <5428DAF7.2080907@redhat.com> References: <541C2199.8010404@redhat.com> <5422D591.4070000@redhat.com> <5422D8AF.6070300@redhat.com> <54239735.5040303@redhat.com> <20140925072549.GF11503@redhat.com> <54244BEF.40000@redhat.com> <5425857F.8020401@redhat.com> <5428DAF7.2080907@redhat.com> Message-ID: <542A6EA4.2090706@redhat.com> All pushed. master: * 15b6ed67056ce918e11f7ea5c2d193534b5ce6b5 webui: improve breadcrumb navigation * 26bd309c96446b9eda26a08e6924d6e1b4c621fc webui: treat value as pkey in link widget * 27196b92c60917d8488dad8721d2087e9fee716c webui: do not show internal facet name to user * 8b0e2ed991e9a1a49ef92e314d3d4855beb93b46 webui: allow to skip link widget link validation * 749101db74219681735226664c1f83ebb4dc4aa7 webui: add simple link column support * ae5a34cbbc0cd3841647a2ad166bdfc65399da19 webui: new ID views section * 2cc78acf9b45b5f8a2d12e232d53267a31732df6 webui: facet group labels for idview's facets * 0e76bc1cb65b3eb81b37b4b45ccb71bf91fe5fbc webui: list only not-applied hosts in "apply to host" dialog * 00d598bab043e277d3f57eab5092c04cf5d6f5f8 webui: add link from host to idview ipa-4-1: * f3c8c4c00f42692f4484dd7875a991a8a0443208 webui: improve breadcrumb navigation * 1050ec887782d1ebf906d239e6aab98aecfc9db4 webui: treat value as pkey in link widget * 86fc8ec0c8d22bd32abe157a047148f0fabf0ff9 webui: do not show internal facet name to user * e0c33446799a2f199b181660dd2b03a4ca6636da webui: allow to skip link widget link validation * cd4c337002fa5c67d0dcad271790fc7130af47d1 webui: add simple link column support * 8a4730ce3c971a23d3d3e2ce55d9bb5a0c46124a webui: new ID views section * bdf1e6c2262b09e6d515d09a37e8a33c4a4e85df webui: facet group labels for idview's facets * 7b7b98db185efba17225c2029d5728bd794e4650 webui: list only not-applied hosts in "apply to host" dialog * 6388aaad80fe5ab18ad4100fb28e3257f55dbca5 webui: add link from host to idview -- Petr Vobornik From tbabej at redhat.com Tue Sep 30 09:40:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 30 Sep 2014 11:40:39 +0200 Subject: [Freeipa-devel] [PATCH 0283] idviews: Fix typo in upgrade handling of the Default Trust Message-ID: <542A7A97.8090705@redhat.com> Hi, Fixed missing comma. Also removes leading spaces from the ldif, since this is not stripped by the updater. Part of: https://fedorahosted.org/freeipa/ticket/3979 -- 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-0283-idviews-Fix-typo-in-upgrade-handling-of-the-Default-.patch Type: text/x-patch Size: 1460 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 30 09:48:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Sep 2014 11:48:18 +0200 Subject: [Freeipa-devel] [PATCH 0283] idviews: Fix typo in upgrade handling of the Default Trust In-Reply-To: <542A7A97.8090705@redhat.com> References: <542A7A97.8090705@redhat.com> Message-ID: <542A7C62.6080608@redhat.com> Dne 30.9.2014 v 11:40 Tomas Babej napsal(a): > Hi, > > Fixed missing comma. Also removes leading spaces from the ldif, > since this is not stripped by the updater. > > Part of: https://fedorahosted.org/freeipa/ticket/3979 ACK. -- Jan Cholasta From mkosek at redhat.com Tue Sep 30 09:54:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 11:54:28 +0200 Subject: [Freeipa-devel] [PATCH 0283] idviews: Fix typo in upgrade handling of the Default Trust In-Reply-To: <542A7C62.6080608@redhat.com> References: <542A7A97.8090705@redhat.com> <542A7C62.6080608@redhat.com> Message-ID: <542A7DD4.4070704@redhat.com> On 09/30/2014 11:48 AM, Jan Cholasta wrote: > Dne 30.9.2014 v 11:40 Tomas Babej napsal(a): >> Hi, >> >> Fixed missing comma. Also removes leading spaces from the ldif, >> since this is not stripped by the updater. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3979 > > ACK. Pushed to: master: 00457a9c109c1df0788a979f07c7fb5c0cc3bc8b ipa-4-1: 7ddebb613d1d14ebe11491651eb7bbfe21c64f5b Martin From pviktori at redhat.com Tue Sep 30 10:55:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 12:55:43 +0200 Subject: [Freeipa-devel] Use "alpha" instead of "pre" for alpha releases Message-ID: <542A8C2F.4060109@redhat.com> Last time (2.1) we used "Preview/Testing" for the pre-beta release, but the Git tags were still named alpha_*. I think alpha is a better name, let's use that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0650-VERSION-Makefile-Rename-pre-to-alpha.patch Type: text/x-patch Size: 3210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0651-Become-IPA-4.1.0-Alpha.patch Type: text/x-patch Size: 1101 bytes Desc: not available URL: From mkosek at redhat.com Tue Sep 30 10:59:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 12:59:23 +0200 Subject: [Freeipa-devel] Use "alpha" instead of "pre" for alpha releases In-Reply-To: <542A8C2F.4060109@redhat.com> References: <542A8C2F.4060109@redhat.com> Message-ID: <542A8D0B.4050402@redhat.com> On 09/30/2014 12:55 PM, Petr Viktorin wrote: > Last time (2.1) we used "Preview/Testing" for the pre-beta release, > but the Git tags were still named alpha_*. > > I think alpha is a better name, let's use that. > +1, I would also prefer to use Alpha, I this it is more understandable than "pre-release". Actually all Alpha and Beta versions are "pre-releases"... Martin From abokovoy at redhat.com Tue Sep 30 11:15:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Sep 2014 14:15:50 +0300 Subject: [Freeipa-devel] Use "alpha" instead of "pre" for alpha releases In-Reply-To: <542A8D0B.4050402@redhat.com> References: <542A8C2F.4060109@redhat.com> <542A8D0B.4050402@redhat.com> Message-ID: <20140930111550.GB4909@redhat.com> On Tue, 30 Sep 2014, Martin Kosek wrote: >On 09/30/2014 12:55 PM, Petr Viktorin wrote: >> Last time (2.1) we used "Preview/Testing" for the pre-beta release, >> but the Git tags were still named alpha_*. >> >> I think alpha is a better name, let's use that. >> > >+1, I would also prefer to use Alpha, I this it is more understandable than >"pre-release". Actually all Alpha and Beta versions are "pre-releases"... I'm fine with that. -- / Alexander Bokovoy From pvoborni at redhat.com Tue Sep 30 11:19:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 30 Sep 2014 13:19:59 +0200 Subject: [Freeipa-devel] Use "alpha" instead of "pre" for alpha releases In-Reply-To: <542A8C2F.4060109@redhat.com> References: <542A8C2F.4060109@redhat.com> Message-ID: <542A91DF.8040803@redhat.com> On 30.9.2014 12:55, Petr Viktorin wrote: > Last time (2.1) we used "Preview/Testing" for the pre-beta release, > but the Git tags were still named alpha_*. > > I think alpha is a better name, let's use that. > +1 -- Petr Vobornik From tbordaz at redhat.com Tue Sep 30 11:42:55 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 30 Sep 2014 13:42:55 +0200 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <1412015930.18502.9.camel@redhat.com> References: <1411149239.18665.7.camel@redhat.com> <54241568.4000107@redhat.com> <1412015930.18502.9.camel@redhat.com> Message-ID: <542A973F.5030600@redhat.com> On 09/29/2014 08:38 PM, Nathaniel McCallum wrote: > On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote: >> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: >> >>> This prevents synchronization when an authentication collision occurs. >>> >>> https://fedorahosted.org/freeipa/ticket/4493 >>> >>> NOTE: this patch is related to the above ticket, but does not solve it. >>> For the solution, please see patch 0064. This behavior fix is from patch >>> 0062 (rescinded) and is worth keeping. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello Nathaniel, >> . >> My understanding is that during a pre_bind, the plugins >> validates token codes (for example "HOTP") checking that step >> ranges [-25..+25]. >> As soon as the token is valid, the new HOTPcounter is written >> in the entry. >> But in case of negative steps,I believe the otp-decrement >> plugin will reject this update. > HOTP never goes backwards. See line 188 in libotp.c. Even if this check > weren't present, we would *want* the decrement plugin to reject the > update. Ok. > >> If TOTPwatermark is updated and there is a second token code, >> then clockOffset is also updated. >> This update is done during a pre_bind, so if there are >> parallel binds on the server, there is a possibility that >> TOTPwatermark is updated from a bind and 'clockOffset' updated >> from an other bind. >> An option is to do a single internal modify to update both. > We don't care about atomicity in this case. If two TOTP synchronizations > occur at almost the same time, the value of clockOffset will be written > twice with the same value. Since the values are the same, we don't care > which value gets written first. I was just wondering if parallel binds with different 'step' values could occur. Because different 'step' values can lead to different 'clockOffset'. thanks thierry > > Nathaniel > From mkosek at redhat.com Tue Sep 30 12:15:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 30 Sep 2014 14:15:25 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 Alpha 1 Message-ID: <542A9EDD.4090501@redhat.com> Hello, It is time to produce an Alpha 1 release of FreeIPA 4.1, as a technology preview for other developers or testers. The main reason is that the Views feature is slowly getting complete and we want other people take a look. The FreeIPA framework and UI part are done, SSSD and slapi-nis are in progress. Given the nature of the build, I would only announce it on freeipa-devel and wait with a more baked release for freeipa-users and freeipa-interest. I prepared a first version of the release notes here: http://www.freeipa.org/page/Releases/4.1.0.alpha1 Please feel free to fix or extend, we can then use it as a base for our next 4.1 release notes. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Tue Sep 30 12:37:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 14:37:20 +0200 Subject: [Freeipa-devel] Use "alpha" instead of "pre" for alpha releases In-Reply-To: <20140930111550.GB4909@redhat.com> References: <542A8C2F.4060109@redhat.com> <542A8D0B.4050402@redhat.com> <20140930111550.GB4909@redhat.com> Message-ID: <542AA400.4070904@redhat.com> On 09/30/2014 01:15 PM, Alexander Bokovoy wrote: > On Tue, 30 Sep 2014, Martin Kosek wrote: >> On 09/30/2014 12:55 PM, Petr Viktorin wrote: >>> Last time (2.1) we used "Preview/Testing" for the pre-beta release, >>> but the Git tags were still named alpha_*. >>> >>> I think alpha is a better name, let's use that. >>> >> >> +1, I would also prefer to use Alpha, I this it is more understandable >> than >> "pre-release". Actually all Alpha and Beta versions are "pre-releases"... > I'm fine with that. Pushed & tagged ipa-4-1: 946291c0db2b2445e5519553d5f707d8b10a09f1 [new tag] alpha_1-4-1-0 And I the first patch went to master as well: master: 9ba33971fad5ec3b6fb5445669228b0ea9a89ec5 -- Petr? From npmccallum at redhat.com Tue Sep 30 12:41:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 30 Sep 2014 08:41:22 -0400 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <542A973F.5030600@redhat.com> References: <1411149239.18665.7.camel@redhat.com> <54241568.4000107@redhat.com> <1412015930.18502.9.camel@redhat.com> <542A973F.5030600@redhat.com> Message-ID: <1412080882.3732.1.camel@redhat.com> On Tue, 2014-09-30 at 13:42 +0200, thierry bordaz wrote: > On 09/29/2014 08:38 PM, Nathaniel McCallum wrote: > > On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote: > >> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: > >> > >>> This prevents synchronization when an authentication collision occurs. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4493 > >>> > >>> NOTE: this patch is related to the above ticket, but does not solve it. > >>> For the solution, please see patch 0064. This behavior fix is from patch > >>> 0062 (rescinded) and is worth keeping. > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> Hello Nathaniel, > >> . > >> My understanding is that during a pre_bind, the plugins > >> validates token codes (for example "HOTP") checking that step > >> ranges [-25..+25]. > >> As soon as the token is valid, the new HOTPcounter is written > >> in the entry. > >> But in case of negative steps,I believe the otp-decrement > >> plugin will reject this update. > > HOTP never goes backwards. See line 188 in libotp.c. Even if this check > > weren't present, we would *want* the decrement plugin to reject the > > update. > Ok. > > > >> If TOTPwatermark is updated and there is a second token code, > >> then clockOffset is also updated. > >> This update is done during a pre_bind, so if there are > >> parallel binds on the server, there is a possibility that > >> TOTPwatermark is updated from a bind and 'clockOffset' updated > >> from an other bind. > >> An option is to do a single internal modify to update both. > > We don't care about atomicity in this case. If two TOTP synchronizations > > occur at almost the same time, the value of clockOffset will be written > > twice with the same value. Since the values are the same, we don't care > > which value gets written first. > I was just wondering if parallel binds with different 'step' values > could occur. > Because different 'step' values can lead to different 'clockOffset'. It is possible, but this isn't a concern. This code path is reached only when synchronization is being performed (not regular binds). This means that the clockOffset value is currently wildly incorrect. We are trying to move this value to something roughly correct. For various reasons, we can't get this value exactly. So if parallel authentication has succeeded, either of the resulting step values is correct. From tbordaz at redhat.com Tue Sep 30 12:53:03 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 30 Sep 2014 14:53:03 +0200 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <1412080882.3732.1.camel@redhat.com> References: <1411149239.18665.7.camel@redhat.com> <54241568.4000107@redhat.com> <1412015930.18502.9.camel@redhat.com> <542A973F.5030600@redhat.com> <1412080882.3732.1.camel@redhat.com> Message-ID: <542AA7AF.6020306@redhat.com> On 09/30/2014 02:41 PM, Nathaniel McCallum wrote: > On Tue, 2014-09-30 at 13:42 +0200, thierry bordaz wrote: >> On 09/29/2014 08:38 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote: >>>> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: >>>> >>>>> This prevents synchronization when an authentication collision occurs. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4493 >>>>> >>>>> NOTE: this patch is related to the above ticket, but does not solve it. >>>>> For the solution, please see patch 0064. This behavior fix is from patch >>>>> 0062 (rescinded) and is worth keeping. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Hello Nathaniel, >>>> . >>>> My understanding is that during a pre_bind, the plugins >>>> validates token codes (for example "HOTP") checking that step >>>> ranges [-25..+25]. >>>> As soon as the token is valid, the new HOTPcounter is written >>>> in the entry. >>>> But in case of negative steps,I believe the otp-decrement >>>> plugin will reject this update. >>> HOTP never goes backwards. See line 188 in libotp.c. Even if this check >>> weren't present, we would *want* the decrement plugin to reject the >>> update. >> Ok. >>>> If TOTPwatermark is updated and there is a second token code, >>>> then clockOffset is also updated. >>>> This update is done during a pre_bind, so if there are >>>> parallel binds on the server, there is a possibility that >>>> TOTPwatermark is updated from a bind and 'clockOffset' updated >>>> from an other bind. >>>> An option is to do a single internal modify to update both. >>> We don't care about atomicity in this case. If two TOTP synchronizations >>> occur at almost the same time, the value of clockOffset will be written >>> twice with the same value. Since the values are the same, we don't care >>> which value gets written first. >> I was just wondering if parallel binds with different 'step' values >> could occur. >> Because different 'step' values can lead to different 'clockOffset'. > It is possible, but this isn't a concern. This code path is reached only > when synchronization is being performed (not regular binds). This means > that the clockOffset value is currently wildly incorrect. We are trying > to move this value to something roughly correct. For various reasons, we > can't get this value exactly. So if parallel authentication has > succeeded, either of the resulting step values is correct. > Thanks Nathaniel for the explanations. The fix is fine for me and for me it is a ACK. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Sep 30 14:20:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 16:20:24 +0200 Subject: [Freeipa-devel] [PATCH 0068] Move OTP synchronization step to after counter writeback In-Reply-To: <542AA7AF.6020306@redhat.com> References: <1411149239.18665.7.camel@redhat.com> <54241568.4000107@redhat.com> <1412015930.18502.9.camel@redhat.com> <542A973F.5030600@redhat.com> <1412080882.3732.1.camel@redhat.com> <542AA7AF.6020306@redhat.com> Message-ID: <542ABC28.3080103@redhat.com> On 09/30/2014 02:53 PM, thierry bordaz wrote: > On 09/30/2014 02:41 PM, Nathaniel McCallum wrote: >> On Tue, 2014-09-30 at 13:42 +0200, thierry bordaz wrote: >>> On 09/29/2014 08:38 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote: >>>>> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote: >>>>> >>>>>> This prevents synchronization when an authentication collision occurs. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4493 >>>>>> >>>>>> NOTE: this patch is related to the above ticket, but does not solve it. >>>>>> For the solution, please see patch 0064. This behavior fix is from patch >>>>>> 0062 (rescinded) and is worth keeping. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> Hello Nathaniel, >>>>> . >>>>> My understanding is that during a pre_bind, the plugins >>>>> validates token codes (for example "HOTP") checking that step >>>>> ranges [-25..+25]. >>>>> As soon as the token is valid, the new HOTPcounter is written >>>>> in the entry. >>>>> But in case of negative steps,I believe the otp-decrement >>>>> plugin will reject this update. >>>> HOTP never goes backwards. See line 188 in libotp.c. Even if this check >>>> weren't present, we would *want* the decrement plugin to reject the >>>> update. >>> Ok. >>>>> If TOTPwatermark is updated and there is a second token code, >>>>> then clockOffset is also updated. >>>>> This update is done during a pre_bind, so if there are >>>>> parallel binds on the server, there is a possibility that >>>>> TOTPwatermark is updated from a bind and 'clockOffset' updated >>>>> from an other bind. >>>>> An option is to do a single internal modify to update both. >>>> We don't care about atomicity in this case. If two TOTP synchronizations >>>> occur at almost the same time, the value of clockOffset will be written >>>> twice with the same value. Since the values are the same, we don't care >>>> which value gets written first. >>> I was just wondering if parallel binds with different 'step' values >>> could occur. >>> Because different 'step' values can lead to different 'clockOffset'. >> It is possible, but this isn't a concern. This code path is reached only >> when synchronization is being performed (not regular binds). This means >> that the clockOffset value is currently wildly incorrect. We are trying >> to move this value to something roughly correct. For various reasons, we >> can't get this value exactly. So if parallel authentication has >> succeeded, either of the resulting step values is correct. >> > Thanks Nathaniel for the explanations. > The fix is fine for me and for me it is a ACK. > > thanks > thierry > Pushed to: master: 915837c14af5f0839d1d08683ea8332334e284ba ipa-4-1: 98debb7fb1b1e998d48806702ad4d950b6dd9f23 -- Petr? From tbordaz at redhat.com Tue Sep 30 16:30:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 30 Sep 2014 18:30:05 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412015453.18502.7.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> Message-ID: <542ADA8D.10807@redhat.com> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >> On Sun, 21 Sep 2014 22:33:47 -0400 >> Nathaniel McCallum wrote: >> >> Comments inline. >> >>> + >>> +#define ch_malloc(type) \ >>> + (type*) slapi_ch_malloc(sizeof(type)) >>> +#define ch_calloc(count, type) \ >>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>> +#define ch_free(p) \ >>> + slapi_ch_free((void**) &(p)) >> please do not redefine slapi functions, it just makes it harder to know >> what you used. >> >> >>> +typedef struct { >>> + bool exists; >>> + long long value; >>> +} counter; >> >> please no typedefs of structures, use "struct counter { ... };" and >> reference it as "struct counter" in the code. >> >> Btw, FWIW you could use a value of -1 to indicate non-existence of the >> counter value, given counters can only be positive, this would avoid >> the need for a struct. >> >>> +static int >>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>> +{ >>> + va_list ap; >>> + int res; >>> + >>> + va_start(ap, template); >>> + res = vsnprintf(NULL, 0, template, ap); >>> + va_end(ap); >>> + >>> + if (res > 0) { >>> + char str[res + 1]; >>> + >>> + va_start(ap, template); >>> + res = vsnprintf(str, sizeof(str), template, ap); >>> + va_end(ap); >>> + >>> + if (res > 0) >>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>> + } >>> + >>> + if (res <= 0) >>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>> + >>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>> + return rc; >>> +} >> This function seem not really useful, you use send_error() only at the >> end of one single function where you could have the classic scheme of >> using a done: label and just use directly slapi_ch_smprintf. This would >> remove the need to use vsnprintf and all the va_ machinery which is >> more than 50% of this function. >> >> >>> +static long long >>> +get_value(const LDAPMod *mod, long long def) >>> +{ >>> + const struct berval *bv; >>> + long long val; >>> + >>> + if (mod == NULL) >>> + return def; >>> + >>> + if (mod->mod_vals.modv_bvals == NULL) >>> + return def; >>> + >>> + bv = mod->mod_vals.modv_bvals[0]; >>> + if (bv == NULL) >>> + return def; >> In general (here and elsewhere) I prefer to always use {} in if clauses. >> I have been bitten enough time by people adding an instruction that >> should be in the braces but forgot to add braces (defensive programming >> style). But up to you. >> >>> + char buf[bv->bv_len + 1]; >>> + memcpy(buf, bv->bv_val, bv->bv_len); >>> + buf[sizeof(buf)-1] = '\0'; >>> + >>> + val = strtoll(buf, NULL, 10); >>> + if (val == LLONG_MIN || val == LLONG_MAX) >>> + return def; >>> + >>> + return val; >>> +} >>> + >>> +static struct berval ** >>> +make_berval_array(long long value) >>> +{ >>> + struct berval **bvs; >>> + >>> + bvs = ch_calloc(2, struct berval*); >>> + bvs[0] = ch_malloc(struct berval); >>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>> + >>> + return bvs; >>> +} >>> + >>> +static LDAPMod * >>> +make_ldapmod(int op, const char *attr, long long value) >>> +{ >>> + LDAPMod *mod; >>> + >>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>> + mod->mod_type = slapi_ch_strdup(attr); >>> + mod->mod_bvalues = make_berval_array(value); >>> + >>> + return mod; >>> +} >>> + >>> +static void >>> +convert_ldapmod_to_bval(LDAPMod *mod) >>> +{ >>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>> + return; >>> + >>> + mod->mod_op |= LDAP_MOD_BVALUES; >>> + >>> + if (mod->mod_values == NULL) { >>> + mod->mod_bvalues = NULL; >>> + return; >>> + } >>> + >>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>> + struct berval *bv = ch_malloc(struct berval); >>> + bv->bv_val = mod->mod_values[i]; >>> + bv->bv_len = strlen(bv->bv_val); >>> + mod->mod_bvalues[i] = bv; >>> + } >>> +} >>> + >>> +static counter >>> +get_counter(Slapi_Entry *entry, const char *attr) >>> +{ >>> + Slapi_Attr *sattr = NULL; >>> + >>> + return (counter) { >>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>> + slapi_entry_attr_get_longlong(entry, attr) >>> + }; >>> +} >>> + >>> +static void >>> +berval_free_array(struct berval ***bvals) >>> +{ >>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>> + ch_free((*bvals)[i]->bv_val); >>> + ch_free((*bvals)[i]); >>> + } >>> + >>> + slapi_ch_free((void**) bvals); >>> +} >>> + >>> +static bool >>> +is_replication(Slapi_PBlock *pb) >>> +{ >>> + int repl = 0; >>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>> + return repl != 0; >>> +} >>> + >>> +static const char * >>> +get_attribute(Slapi_Entry *entry) >>> +{ >>> + static struct { >>> + const char *clss; >>> + const char *attr; >>> + } table[] = { >>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>> + { NULL, NULL } >>> + }; >>> + >>> + const char *attr = NULL; >>> + char **clsses = NULL; >>> + >>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>> + if (clsses == NULL) >>> + return NULL; >>> + >>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>> j++) { >>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>> + attr = table[j].attr; >>> + } >>> + } >>> + >>> + slapi_ch_array_free(clsses); >>> + return attr; >>> +} >> Can you put a comment here that explains what you are going to do in >> each cases in plain English ? This will help people in future figuring >> out if/how to modify the code or why something happens a specific way. >> It will also help the reviewer follow what is going on. >> >> >>> +static int >>> +preop_mod(Slapi_PBlock *pb) >>> +{ >>> + size_t count = 0, attrs = 0, extras = 0; >>> + Slapi_Entry *entry = NULL; >>> + const char *attr = NULL; >>> + LDAPMod **inmods = NULL; >>> + LDAPMod **mods = NULL; >>> + counter ctr, orig; >>> + >>> + /* Get the input values. */ >>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>> + if (entry == NULL || inmods == NULL) >>> + return 0; >>> + >>> + /* Get the attribute name. */ >>> + attr = get_attribute(entry); >>> + if (attr == NULL) >>> + return 0; /* Not a token. */ >>> + >>> + /* Count items. */ >>> + while (inmods != NULL && inmods[count] != NULL) { >> ^^ this one would read much better as: >> for (count = 0; inmods[count] != NULL; count++) { >> >> You do not need to check for insmods != NULL as you already check for >> it and return 0 a few lines above. >> >>> + LDAPMod *mod = inmods[count++]; >>> + >>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>> + continue; >>> + >>> + attrs++; >>> + switch (mod->mod_op & LDAP_MOD_OP) { >>> + case LDAP_MOD_REPLACE: >>> + case LDAP_MOD_INCREMENT: >>> + extras++; >>> + break; >>> + } >>> + } >>> + >>> + /* Not operating on the counter/watermark. */ >>> + if (attrs == 0) >>> + return 0; >>> + >>> + /* Get the counter. */ >>> + orig = ctr = get_counter(entry, attr); >>> + >>> + /* Filter the modify operations. */ >>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>> mods[j++] = inmods[i++]) { >> Please remove check for insmods != NULL, it is useless, and removing it >> will bring back the line under 80columns >> >>> + LDAPMod *mod = inmods[i]; >>> + >>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>> + continue; >>> + >>> + convert_ldapmod_to_bval(mod); >>> + >>> + switch (mod->mod_op & LDAP_MOD_OP) { >>> + case LDAP_MOD_DELETE: >>> + ctr.exists = false; >>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>> NULL) >>> + berval_free_array(&mod->mod_bvalues); >>> + >>> + if (is_replication(pb)) >>> + berval_free_array(&mod->mod_bvalues); >>> + >>> + if (mod->mod_bvalues == NULL) >>> + mod->mod_bvalues = make_berval_array(ctr.value); >>> + break; >> I am not sure I understand this segment, why are you touching the >> delete operation outside of a replication event ? >> Doesn't this defeat and admin tool trying to correctly delete/add to >> avoid races ? >> >>> + case LDAP_MOD_INCREMENT: >>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>> ctr.value); + >>> + ctr.value += get_value(mod, 1); >> uhmmm if you had an ADD followed by INCREMENT operation, would this >> cause the value to become value*2+1 instead of just value+1 ? >> >>> + berval_free_array(&mod->mod_bvalues); >>> + mod->mod_op &= ~LDAP_MOD_OP; >>> + mod->mod_op |= LDAP_MOD_ADD; >>> + mod->mod_bvalues = make_berval_array(ctr.value); >>> + break; >> uhmm why are you converting mod_increment in all cases ? (including >> replication) >> >>> + case LDAP_MOD_REPLACE: >>> + if (ctr.exists) >>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>> ctr.value); + >>> + mod->mod_op &= ~LDAP_MOD_OP; >>> + mod->mod_op |= LDAP_MOD_ADD; >> same question here, why are you converting a replace coming from >> replication into a delete/add ? >> >>> + case LDAP_MOD_ADD: >>> + ctr.value = get_value(mod, 0); >>> + ctr.exists = true; >>> + break; >>> + } >>> + } >>> + >>> + /* Set the modified operations. */ >>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>> + ch_free(inmods); >>> + >>> + /* Ensure we aren't deleting the counter. */ >>> + if (orig.exists && !ctr.exists) >>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>> + "Will not delete %s", attr); >>> + >>> + /* Ensure we aren't rolling back the counter. */ >>> + if (orig.value > ctr.value) >>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>> + "Will not decrement %s", attr); >>> + >>> + return 0; >>> +} >> >> see above about send_error(). >> >> I think what is needed most is the comment that explains the process >> at the to of the main function. >> >> Simo. > All of the above are fixed. > > Also, I have addressed Thierry's concern about putting the plugin in > betxnpreoperation by splitting the plugin into two phases: modification > and validation. Now all modifications occur in bepreoperation and all > validation occurs in betxnpreoperation. > > Additionally, I have new code to trigger a new replication in the case > where a validation error occurs and we are in a replication transaction. > Thus, when A attempts to push an old counter value to B, B will now > replicate the latest value back to A. > > Nathaniel > Hello, The plugin looks very good I have very few comments: trigger_replication, prepare the pblock for internal op but does not call slapi_modify_internal_pb. At the end of txnpreop_mod, you may prefer to use PR_snprintf(msg, sizeof(msg), "%s %s", err, attr) rather than strcpy/strcat. Reading the fix, I still have problems to understand how replicated updates will behave. Let me give an example of my concern: The initial value of the counter is 10. On server A, the counter is updated MOD/REPL to the value 11/csnA On server B, the counter is updated MOD/REPL to the value 12/csnB For some reason csnBcsnB. When server B receives the operation value 11/csnA. preop_mod translates it into (DEL 12/ADD 11)/csn A. txnpreop_mod reject the operation, updates (DEL 12/ADD 12)/csnB' and returns unwilling_to_perform. Later the update csnB' will be sent to A but server A will still be in problem to send csnA update. You mentioned that synchronize replication was needed. Do you mean we need 'synchronous replication' to address the example above ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Sep 30 16:59:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 18:59:37 +0200 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: References: Message-ID: <542AE179.6050303@redhat.com> On 09/30/2014 05:13 AM, Gabe Alford wrote: > Updated patch to fix merge conflicts from recent changes. > > On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford > wrote: > > Hello, > > Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know > if I missed any. > > Thanks, > > Gabe Thanks for the patch, and sorry for the delay! ipaserver/tools/ipa-upgradeconfig: The `filename` and `ca_file` aren't module-level constants; I think in this case they improve readability. The ticket calls for removing module-level lines like: NSSWITCH_CONF = paths.NSSWITCH_CONF which are just silly, but assigning a name locally to a global constant is a valid thing to do -- even if the local name just says "the file we're working on now". > - ca_file = paths.ALIAS_CACERT_ASC > - if os.path.exists(ca_file): > + if os.path.exists(paths.SYSCONFIG_HTTPD): Whoops! install/wsgi/plugins.py: > -PLUGINS_DIR = paths.IPA_JS_PLUGINS_DIR > - [...] > - if not os.path.isdir(PLUGINS_DIR): > + if not os.path.isdir(paths.IPA_CA_CSR): Whoops too! ipaplatform/fedora/tasks.py: ipa-client/ipa-install/ipa-client-install: ipaserver/install/dsinstance.py: ipaserver/install/httpinstance.py: Again, I'd not change the target_fname, filepath. ipapython/sysrestore.py: Again, `SYSRESTORE_PATH` describes better what we do with `paths.TMP`, so I'd prefer keeping it. ipaserver/install/adtrustinstance.py: I don't think we want to convert the self.* to constants. ipaserver/install/certs.py: I'd leave NSS_DIR as it is, rather than lose the comment. ipapython/ipautil.py: ipaserver/install/ldapupdate.py: ipalib/session.py: ipaserver/install/bindinstance.py: SHARE_DIR, UPDATES_DIR, and krbccache_dir, NAMED_CONF (respectively) need to stay, unless you also replace them in everything that uses them. Be sure to run make-lint after doing these changes. I've rebased, and I made some of the changes as I went along the review. You can base another revision on the attached patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-33+pviktori-Remove-trivial-path-constants-from-modules.patch Type: text/x-patch Size: 51354 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 30 17:04:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Sep 2014 19:04:19 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Refactor selinuxenabled check In-Reply-To: <5425957F.90308@redhat.com> References: <54256BAF.5090305@gmx.com> <54256CFE.5030307@redhat.com> <54257893.9010607@gmx.com> <542585B2.8020600@gmx.com> <542589B7.9060104@redhat.com> <54258BF0.4020208@gmx.com> <5425957F.90308@redhat.com> Message-ID: <542AE293.2050600@redhat.com> On 09/26/2014 06:34 PM, thierry bordaz wrote: > On 09/26/2014 05:53 PM, Francesco Marella wrote: >> >> On 26/09/2014 17:43, thierry bordaz wrote: >>> Hello, >>> >>> When called from set_selinux_booleans, if not selinux_enabled, >>> you may want to 'return False' rather than 'return'. >>> Now it looks like callers of set_selinux_booleans do not check >>> the returned value :-) >>> >>> thanks >>> thierry >>> >>> On 09/26/2014 05:26 PM, Francesco Marella wrote: >>>> This should be the final one. >>>> >>>> fm >>>> >>>> On 26/09/2014 16:30, Francesco Marella wrote: >>>>> >>>>> On 26/09/2014 15:41, Petr Viktorin wrote: >>>>>> >>>>>> Hello! Thanks for the patch! >>>>>> >>>>>> The new function is not one of the platform-independent tasks, and >>>>>> doesn't even use `self`, so you can define it as a module-level >>>>>> helper function. >>>>>> >>>>>> But more importantly, this won't work: the blocks you are >>>>>> replacing return from their functions. You'd need to use something >>>>>> like: >>>>>> if not selinux_enabled(): >>>>>> return >>>>>> instead of: >>>>>> self.check_enabled_selinux() >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> > Thanks Francesco ! > > For me it is a ACK. Thanks indeed! Pushed to master: f5b302be47eb94fb064af6b9a1855da4d318898e -- Petr? From npmccallum at redhat.com Tue Sep 30 20:49:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 30 Sep 2014 16:49:04 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <542ADA8D.10807@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542ADA8D.10807@redhat.com> Message-ID: <1412110144.3732.23.camel@redhat.com> On Tue, 2014-09-30 at 18:30 +0200, thierry bordaz wrote: > On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > > > On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: > > > On Sun, 21 Sep 2014 22:33:47 -0400 > > > Nathaniel McCallum wrote: > > > > > > Comments inline. > > > > > > > + > > > > +#define ch_malloc(type) \ > > > > + (type*) slapi_ch_malloc(sizeof(type)) > > > > +#define ch_calloc(count, type) \ > > > > + (type*) slapi_ch_calloc(count, sizeof(type)) > > > > +#define ch_free(p) \ > > > > + slapi_ch_free((void**) &(p)) > > > please do not redefine slapi functions, it just makes it harder to know > > > what you used. > > > > > > > > > > +typedef struct { > > > > + bool exists; > > > > + long long value; > > > > +} counter; > > > > > > please no typedefs of structures, use "struct counter { ... };" and > > > reference it as "struct counter" in the code. > > > > > > Btw, FWIW you could use a value of -1 to indicate non-existence of the > > > counter value, given counters can only be positive, this would avoid > > > the need for a struct. > > > > > > > +static int > > > > +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > > > > +{ > > > > + va_list ap; > > > > + int res; > > > > + > > > > + va_start(ap, template); > > > > + res = vsnprintf(NULL, 0, template, ap); > > > > + va_end(ap); > > > > + > > > > + if (res > 0) { > > > > + char str[res + 1]; > > > > + > > > > + va_start(ap, template); > > > > + res = vsnprintf(str, sizeof(str), template, ap); > > > > + va_end(ap); > > > > + > > > > + if (res > 0) > > > > + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > > > > + } > > > > + > > > > + if (res <= 0) > > > > + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > > > > + > > > > + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > > > > + return rc; > > > > +} > > > This function seem not really useful, you use send_error() only at the > > > end of one single function where you could have the classic scheme of > > > using a done: label and just use directly slapi_ch_smprintf. This would > > > remove the need to use vsnprintf and all the va_ machinery which is > > > more than 50% of this function. > > > > > > > > > > +static long long > > > > +get_value(const LDAPMod *mod, long long def) > > > > +{ > > > > + const struct berval *bv; > > > > + long long val; > > > > + > > > > + if (mod == NULL) > > > > + return def; > > > > + > > > > + if (mod->mod_vals.modv_bvals == NULL) > > > > + return def; > > > > + > > > > + bv = mod->mod_vals.modv_bvals[0]; > > > > + if (bv == NULL) > > > > + return def; > > > In general (here and elsewhere) I prefer to always use {} in if clauses. > > > I have been bitten enough time by people adding an instruction that > > > should be in the braces but forgot to add braces (defensive programming > > > style). But up to you. > > > > > > > + char buf[bv->bv_len + 1]; > > > > + memcpy(buf, bv->bv_val, bv->bv_len); > > > > + buf[sizeof(buf)-1] = '\0'; > > > > + > > > > + val = strtoll(buf, NULL, 10); > > > > + if (val == LLONG_MIN || val == LLONG_MAX) > > > > + return def; > > > > + > > > > + return val; > > > > +} > > > > + > > > > +static struct berval ** > > > > +make_berval_array(long long value) > > > > +{ > > > > + struct berval **bvs; > > > > + > > > > + bvs = ch_calloc(2, struct berval*); > > > > + bvs[0] = ch_malloc(struct berval); > > > > + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > > > > + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > > > > + > > > > + return bvs; > > > > +} > > > > + > > > > +static LDAPMod * > > > > +make_ldapmod(int op, const char *attr, long long value) > > > > +{ > > > > + LDAPMod *mod; > > > > + > > > > + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > > > > + mod->mod_op = op | LDAP_MOD_BVALUES; > > > > + mod->mod_type = slapi_ch_strdup(attr); > > > > + mod->mod_bvalues = make_berval_array(value); > > > > + > > > > + return mod; > > > > +} > > > > + > > > > +static void > > > > +convert_ldapmod_to_bval(LDAPMod *mod) > > > > +{ > > > > + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > > > > + return; > > > > + > > > > + mod->mod_op |= LDAP_MOD_BVALUES; > > > > + > > > > + if (mod->mod_values == NULL) { > > > > + mod->mod_bvalues = NULL; > > > > + return; > > > > + } > > > > + > > > > + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > > > > + struct berval *bv = ch_malloc(struct berval); > > > > + bv->bv_val = mod->mod_values[i]; > > > > + bv->bv_len = strlen(bv->bv_val); > > > > + mod->mod_bvalues[i] = bv; > > > > + } > > > > +} > > > > + > > > > +static counter > > > > +get_counter(Slapi_Entry *entry, const char *attr) > > > > +{ > > > > + Slapi_Attr *sattr = NULL; > > > > + > > > > + return (counter) { > > > > + slapi_entry_attr_find(entry, attr, &sattr) == 0, > > > > + slapi_entry_attr_get_longlong(entry, attr) > > > > + }; > > > > +} > > > > + > > > > +static void > > > > +berval_free_array(struct berval ***bvals) > > > > +{ > > > > + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > > > > + ch_free((*bvals)[i]->bv_val); > > > > + ch_free((*bvals)[i]); > > > > + } > > > > + > > > > + slapi_ch_free((void**) bvals); > > > > +} > > > > + > > > > +static bool > > > > +is_replication(Slapi_PBlock *pb) > > > > +{ > > > > + int repl = 0; > > > > + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > > > > + return repl != 0; > > > > +} > > > > + > > > > +static const char * > > > > +get_attribute(Slapi_Entry *entry) > > > > +{ > > > > + static struct { > > > > + const char *clss; > > > > + const char *attr; > > > > + } table[] = { > > > > + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > > > > + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > > > > + { NULL, NULL } > > > > + }; > > > > + > > > > + const char *attr = NULL; > > > > + char **clsses = NULL; > > > > + > > > > + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > > > > + if (clsses == NULL) > > > > + return NULL; > > > > + > > > > + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > > > > + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > > > > j++) { > > > > + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > > > > + attr = table[j].attr; > > > > + } > > > > + } > > > > + > > > > + slapi_ch_array_free(clsses); > > > > + return attr; > > > > +} > > > Can you put a comment here that explains what you are going to do in > > > each cases in plain English ? This will help people in future figuring > > > out if/how to modify the code or why something happens a specific way. > > > It will also help the reviewer follow what is going on. > > > > > > > > > > +static int > > > > +preop_mod(Slapi_PBlock *pb) > > > > +{ > > > > + size_t count = 0, attrs = 0, extras = 0; > > > > + Slapi_Entry *entry = NULL; > > > > + const char *attr = NULL; > > > > + LDAPMod **inmods = NULL; > > > > + LDAPMod **mods = NULL; > > > > + counter ctr, orig; > > > > + > > > > + /* Get the input values. */ > > > > + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > > > > + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > > > > + if (entry == NULL || inmods == NULL) > > > > + return 0; > > > > + > > > > + /* Get the attribute name. */ > > > > + attr = get_attribute(entry); > > > > + if (attr == NULL) > > > > + return 0; /* Not a token. */ > > > > + > > > > + /* Count items. */ > > > > + while (inmods != NULL && inmods[count] != NULL) { > > > ^^ this one would read much better as: > > > for (count = 0; inmods[count] != NULL; count++) { > > > > > > You do not need to check for insmods != NULL as you already check for > > > it and return 0 a few lines above. > > > > > > > + LDAPMod *mod = inmods[count++]; > > > > + > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > + continue; > > > > + > > > > + attrs++; > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > + case LDAP_MOD_REPLACE: > > > > + case LDAP_MOD_INCREMENT: > > > > + extras++; > > > > + break; > > > > + } > > > > + } > > > > + > > > > + /* Not operating on the counter/watermark. */ > > > > + if (attrs == 0) > > > > + return 0; > > > > + > > > > + /* Get the counter. */ > > > > + orig = ctr = get_counter(entry, attr); > > > > + > > > > + /* Filter the modify operations. */ > > > > + mods = ch_calloc(count + extras + 1, LDAPMod*); > > > > + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > > > > mods[j++] = inmods[i++]) { > > > Please remove check for insmods != NULL, it is useless, and removing it > > > will bring back the line under 80columns > > > > > > > + LDAPMod *mod = inmods[i]; > > > > + > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > + continue; > > > > + > > > > + convert_ldapmod_to_bval(mod); > > > > + > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > + case LDAP_MOD_DELETE: > > > > + ctr.exists = false; > > > > + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > > > > NULL) > > > > + berval_free_array(&mod->mod_bvalues); > > > > + > > > > + if (is_replication(pb)) > > > > + berval_free_array(&mod->mod_bvalues); > > > > + > > > > + if (mod->mod_bvalues == NULL) > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > + break; > > > I am not sure I understand this segment, why are you touching the > > > delete operation outside of a replication event ? > > > Doesn't this defeat and admin tool trying to correctly delete/add to > > > avoid races ? > > > > > > > + case LDAP_MOD_INCREMENT: > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > ctr.value); + > > > > + ctr.value += get_value(mod, 1); > > > uhmmm if you had an ADD followed by INCREMENT operation, would this > > > cause the value to become value*2+1 instead of just value+1 ? > > > > > > > + berval_free_array(&mod->mod_bvalues); > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > + break; > > > uhmm why are you converting mod_increment in all cases ? (including > > > replication) > > > > > > > + case LDAP_MOD_REPLACE: > > > > + if (ctr.exists) > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > ctr.value); + > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > same question here, why are you converting a replace coming from > > > replication into a delete/add ? > > > > > > > + case LDAP_MOD_ADD: > > > > + ctr.value = get_value(mod, 0); > > > > + ctr.exists = true; > > > > + break; > > > > + } > > > > + } > > > > + > > > > + /* Set the modified operations. */ > > > > + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > > > > + ch_free(inmods); > > > > + > > > > + /* Ensure we aren't deleting the counter. */ > > > > + if (orig.exists && !ctr.exists) > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > + "Will not delete %s", attr); > > > > + > > > > + /* Ensure we aren't rolling back the counter. */ > > > > + if (orig.value > ctr.value) > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > + "Will not decrement %s", attr); > > > > + > > > > + return 0; > > > > +} > > > > > > see above about send_error(). > > > > > > I think what is needed most is the comment that explains the process > > > at the to of the main function. > > > > > > Simo. > > All of the above are fixed. > > > > Also, I have addressed Thierry's concern about putting the plugin in > > betxnpreoperation by splitting the plugin into two phases: modification > > and validation. Now all modifications occur in bepreoperation and all > > validation occurs in betxnpreoperation. > > > > Additionally, I have new code to trigger a new replication in the case > > where a validation error occurs and we are in a replication transaction. > > Thus, when A attempts to push an old counter value to B, B will now > > replicate the latest value back to A. > > > > Nathaniel > > > Hello, > > The plugin looks very good I have very few comments: > trigger_replication, prepare the pblock for internal op but > does not call slapi_modify_internal_pb. > > At the end of txnpreop_mod, you may prefer to use > PR_snprintf(msg, sizeof(msg), "%s %s", err, attr) rather than > strcpy/strcat. > > Reading the fix, I still have problems to understand how > replicated updates will behave. > Let me give an example of my concern: > The initial value of the counter is 10. > On server A, the counter is updated MOD/REPL to the value > 11/csnA > On server B, the counter is updated MOD/REPL to the value > 12/csnB > For some reason csnB On server A, MOD/REPL is translated into (DEL 10+ADD 11)/csnA. > current value is then 11/csnA > On server B, MOD/REPL is translated into (DEL 10+ADD 12)/csnB. > current value is then 12/csnB > > When server A receives the operation value 12/csnB. preop_mod > translates it into (DEL 11/ADD 12)/csnB. txnpreop_mod accepts > the operation because orig.value (11) < ctr.value (12). > Unfortunately when the operation will be applied the final > value kept for the counter will be 11 because csnA>csnB. > > When server B receives the operation value 11/csnA. preop_mod > translates it into (DEL 12/ADD 11)/csn A. txnpreop_mod reject > the operation, updates (DEL 12/ADD 12)/csnB' and returns > unwilling_to_perform. Later the update csnB' will be sent to A > but server A will still be in problem to send csnA update. I see only two ways to solve this problem: 1. We modify the CSN upon receipt. 2. We compare the received replication request's CSN with the current value and perform the writes ourselves. I don't think #2 is workable because it will cause a replication storm. I'm not sure about #1. Suggestions? > You mentioned that synchronize replication was needed. Do you > mean we need 'synchronous replication' to address the example > above ? I think I was referring to this: http://www.freeipa.org/page/V4/OTPReplayPrevention#Synchronous_Synchronization Nathaniel