From gh.mdgh at gmail.com Sun Feb 2 05:29:06 2014 From: gh.mdgh at gmail.com (Mahmoud) Date: Sun, 2 Feb 2014 08:59:06 +0330 Subject: [Freeipa-devel] Configuring Networking Services Message-ID: Hello, The following commands are recommended to install FreeIPA. I would like to know that could I install freeipa without following command? chkconfig NetworkManager off; service NetworkManager stop chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop chkconfig network on; service network start Could you help me, what problems NetworkManager can cause with FreeIPA and the KDC? Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Feb 2 12:16:41 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 2 Feb 2014 14:16:41 +0200 Subject: [Freeipa-devel] Configuring Networking Services In-Reply-To: References: Message-ID: <20140202121641.GB4447@redhat.com> On Sun, 02 Feb 2014, Mahmoud wrote: >Hello, > >The following commands are recommended to install FreeIPA. I would like to >know that could I install freeipa without following command? > >chkconfig NetworkManager off; service NetworkManager stop >chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher >stop >chkconfig network on; service network start > >Could you help me, what problems NetworkManager can cause with FreeIPA and >the KDC? Where this recommendation comes from? Fedora 16+ has no known issues with Network Manager and FreeIPA at all. -- / Alexander Bokovoy From gh.mdgh at gmail.com Sun Feb 2 13:56:23 2014 From: gh.mdgh at gmail.com (Mahmoud) Date: Sun, 2 Feb 2014 17:26:23 +0330 Subject: [Freeipa-devel] Configuring Networking Services In-Reply-To: <20140202121641.GB4447@redhat.com> References: <20140202121641.GB4447@redhat.com> Message-ID: Thank you for your attention. It was mentioned under the following link: http://www.freeipa.org/docs/2.0.0/Installation_Deployment_Guide/en-US/html/#sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Configuring_Networking Best regards. On Sun, Feb 2, 2014 at 3:46 PM, Alexander Bokovoy wrote: > On Sun, 02 Feb 2014, Mahmoud wrote: > >> Hello, >> >> The following commands are recommended to install FreeIPA. I would like to >> know that could I install freeipa without following command? >> >> chkconfig NetworkManager off; service NetworkManager stop >> chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher >> stop >> chkconfig network on; service network start >> >> Could you help me, what problems NetworkManager can cause with FreeIPA and >> the KDC? >> > Where this recommendation comes from? > > Fedora 16+ has no known issues with Network Manager and FreeIPA at all. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Feb 2 15:19:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 2 Feb 2014 17:19:11 +0200 Subject: [Freeipa-devel] Configuring Networking Services In-Reply-To: References: <20140202121641.GB4447@redhat.com> Message-ID: <20140202151911.GA6106@redhat.com> On Sun, 02 Feb 2014, Mahmoud wrote: >Thank you for your attention. > >It was mentioned under the following link: >http://www.freeipa.org/docs/2.0.0/Installation_Deployment_Guide/en-US/html/#sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Configuring_Networking These are outdated docs -- we are at version 3.3 nowadays. However, the same paragraph is there too. Could you please file a bug at bugzilla.redhat.com against 'freeipa' component in Fedora? I think we need this fixed also for RHEL 7 documentation since that is using Network Manager by default too. -- / Alexander Bokovoy From gh.mdgh at gmail.com Sun Feb 2 16:27:57 2014 From: gh.mdgh at gmail.com (Mahmoud) Date: Sun, 2 Feb 2014 19:57:57 +0330 Subject: [Freeipa-devel] Configuring Networking Services In-Reply-To: <20140202151911.GA6106@redhat.com> References: <20140202121641.GB4447@redhat.com> <20140202151911.GA6106@redhat.com> Message-ID: Hello, Thank you for your time and attention. Yes I do, I would report it. Best regards. On Sun, Feb 2, 2014 at 6:49 PM, Alexander Bokovoy wrote: > On Sun, 02 Feb 2014, Mahmoud wrote: > >> Thank you for your attention. >> >> It was mentioned under the following link: >> http://www.freeipa.org/docs/2.0.0/Installation_Deployment_ >> Guide/en-US/html/#sect-Installation_and_Deployment_ >> Guide-Preparing_for_an_IPA_Installation-Configuring_Networking >> > These are outdated docs -- we are at version 3.3 nowadays. > > However, the same paragraph is there too. Could you please file a bug > at bugzilla.redhat.com against 'freeipa' component in Fedora? I think we > need this fixed also for RHEL 7 documentation since that is using > Network Manager by default too. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 3 08:16:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Feb 2014 09:16:36 +0100 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52EBC399.4030109@redhat.com> References: <52EA771A.3080708@redhat.com> <52EA97CC.8030203@redhat.com> <52EB5ECE.2010500@redhat.com> <52EBC399.4030109@redhat.com> Message-ID: <52EF5064.7000304@redhat.com> On 01/31/2014 04:39 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/30/2014 07:19 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> krbPwdPolicyReference is no longer filled default users. Instead, plugins >>>> fallback to hardcoded global policy reference. >>>> >>>> Fix ipa-lockout plugin to fallback to it instead of failing to apply >>>> the policy. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4085 >>> >>> NACK. >>> >>> I think you should include the value of krberr in error messages (we aren't >>> exactly consistent in this elsewhere in the code but we need to start >>> somewhere). >>> >>> You check the wrong value after the krb5_get_default_realm() call. >>> >>> It is probably better to use slapi_ch_free_string() than free(). >>> >>> At some point we'll need a common library where this sort of operation can be >>> done. >>> >>> rob >> >> Good catch, sending updated patch. >> >> Martin >> > > ACK Pushed to master, ipa-3-3. Martin From ilgrosso at apache.org Mon Feb 3 10:41:56 2014 From: ilgrosso at apache.org (=?ISO-8859-1?Q?Francesco_Chicchiricc=F2?=) Date: Mon, 03 Feb 2014 11:41:56 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EBE3FD.3030709@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> Message-ID: <52EF7274.7010503@apache.org> On 31/01/2014 18:57, Dmitri Pal wrote: > On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >> Are you saying that we should split our development in two: >> >> (1) smart proxy, exposing the RESTful interface, developed on the >> basis of [8] >> >> (2) actual ConnId connector, dealing with the proxy above for >> implementing its own logic > Correct > >> If so, could you please point to the source code of [8]? >> Will then this eventually become part of FreeIPA? > Quite soon. I would leave it to the team to suggest whether user and > host provisioning smart proxies should be a same smart proxy or > different so that they can be installed independently from each other > but use the same approach. IMO haveing them separately but share the > same code and approach will be more valuable to the project. But I am > open to other ideas here. > >> I am actually not sure if it is "lightweight" connector could actually >> be better than a "loaded" connector (e.g. without proxy), from a >> deployment point of view, unless you are saying either that (a) a >> smart proxy is already available that can be reused > The idea can be reused as a starting point. IMO the easiest would be to > look at the patches and use same machinery but implement different commands. > >> or that (b) incorporating the smart proxy that we are going to develop >> into FreeIPA will easily happen. > If done right: i.e. following process and style then yes. > > Please become familiar with the coding style [9] page on the wiki and > other contributer guidelines [10]. > Also having a design page created as a result of the preliminary > investigation would go a long way towards acceptance and quality of the > feature. > > We will gladly guide you on the way if you have specific questions > > [...] Ok then, we'll do it as follows. We are currently experimenting with FreeIPA, to get familiar with technology and options; once we will be confident enough to start the actual work on the connector, we will check the status of the smart proxy patches from [11]. If the implementation status will be close to be ready and about to be included in the official distribution, we will follow the suggestions above and develop a REST-based connector. Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Thanks for your support. Regards. >>>>>> [2] http://tirasa.github.io/ConnId/ >>>>>> [3] http://java.net/projects/identityconnectors/ >>>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>>> [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>> [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>> >>>> [7] http://www.freeipa.org/page/Documentation >>>> [8] http://www.freeipa.org/page/V3/Smart_Proxy >> [1] http://syncope.apache.org/ > [9] http://www.freeipa.org/page/Coding_Style > [10] http://www.freeipa.org/page/Contribute/Code [11] https://fedorahosted.org/freeipa/ticket/4128 [12] https://github.com/Tirasa/ConnIdCMDBundle [13] https://connid.atlassian.net/wiki/display/BASE/Connector+Servers -- Francesco Chicchiricc? Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ From ayoung at redhat.com Mon Feb 3 17:16:56 2014 From: ayoung at redhat.com (Adam Young) Date: Mon, 03 Feb 2014 12:16:56 -0500 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EB74F5.1010002@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> Message-ID: <52EFCF08.6070706@redhat.com> On 01/31/2014 05:03 AM, Martin Kosek wrote: > On 01/31/2014 10:45 AM, Francesco Chicchiricc? wrote: >> On 30/01/2014 19:25, Dmitri Pal wrote: >>> On 01/30/2014 11:35 AM, Francesco Chicchiricc? wrote: > ... >>> To call into IPA you can use "ipa ..." command line or use out API from >>> python client. Since you are using Java calling into "ipa" command is >>> probably the best option. >> Actually, a RESTful interface (HTTP/JSON) would better suit our development >> model and deployment scenarios. > FreeIPA does not have (currently) not RESTful interface (though it is being > partially designed in [8]). However it has a Kerberos-protected > JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the > server. For examples of working with it: http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ I found the Batch command especially helpful: it allows you to send multiple single commands in one remote call. Here are some sample data batch commands. They are old, and have not been tested in a few years, but they should give you a sense of how to do a few bascia things via the JSON-RPC interface. http://admiyo.fedorapeople.org/ipa/long_userlist.json http://admiyo.fedorapeople.org/ipa/sampledata-summit.json > > We do not, however, have a good (read "none") documentation of the interface, > see related discussion in freeipa-users list [6]. > >>> In future we plan to allow insertion of the users via an ldap command >>> https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for >>> this spring. >>> >>> What are other use cases and workflows you have? >>> Do you have a password reset self service? >>> If you do it might be nice external addition to FreeIPA if it integrates >>> into the UI seamlessly. >> The idea is to deploy the latest FreeIPA version in our lab, start playing with >> it and come to this list for asking for more information we are not able to >> find in the wiki (just to avoid some graceful RTFMs...). >> Then, every time we get something working, we will also check here whether we >> are heading into the right direction, if we are missing some important points, >> etc. >> >> Does it sound? > Sounds good to me, you should be able to find all documentation links in [7]. > >> Regards. >> >>> [1] http://syncope.apache.org/ >>> [2] http://tirasa.github.io/ConnId/ >>> [3] http://java.net/projects/identityconnectors/ >>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >> [5] >> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html > [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html > [7] http://www.freeipa.org/page/Documentation > [8] http://www.freeipa.org/page/V3/Smart_Proxy > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From JR.Aquino at citrix.com Tue Feb 4 05:37:03 2014 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 4 Feb 2014 05:37:03 +0000 Subject: [Freeipa-devel] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past Message-ID: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> If you are seeing clock skew errors in /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you will need to verify the time/date of the server to make sure NTP isn't freaked out. If the system date is correct, it is possible that the change number generator has skewed. [01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 repl="dc=example,dc=com": Excessive clock skew from supplier RUV [01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit exceeded; value - 1448518, limit - 86400 [01/Feb/2014:14:42:06 -0800] - CSN generator's state: [01/Feb/2014:14:42:06 -0800] - replica id: 115 [01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526 [01/Feb/2014:14:42:06 -0800] - local offset: 0 [01/Feb/2014:14:42:06 -0800] - remote offset: 0 [01/Feb/2014:14:42:06 -0800] - sequence number: 55067 The following NsState_Script should be used to determine whether the change number generator has jumped significantly from the real time/date. https://github.com/richm/scripts/blob/master/readNsState.py The usage for the script works like this: [root at ipaserver.ops jaquino]# ./readNsState.py /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif nsState is cwAAAAAAAABGPfBSAAAAAAAAAAAAAAAAAQAAAAAAAAACAAAAAAAAAA== Little Endian For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 115 Sampled Time : 1391476038 Gen as csn : 52f03d46000201150000 Time as str : Mon Feb 3 17:07:18 2014 Local Offset : 0 Remote Offset : 1 Seq. num : 2 System time : Mon Feb 3 17:09:11 2014 Diff in sec. : 113 Day:sec diff : 0:113 If the output from the above command is over a day or more out of sync, then the reason is because the CSN generator has become grossly skewed. It will be necessary to perform the following steps to recover. -------------------------------------------- How to resolve this issue ? 1: Select an ipa server to be authoritative and write the contents of its database to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -a /tmp/master-389.ldif Note that without the -r option it is deliberately ommiting the tainted replication data which contains the bad CSNs ? 2: On the ipa server, shutdown its dirsrv daemon down so that you can reset the attribute responsible for the serial generation, and so that you can re-initialize its db from the known good ldif On the master supplier: ipactl stop ? 3: Sanitize the dse.ldif Configuration File On the master supplier: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== Delete the entire line ? 3.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif backup the old dse.ldif and replace it with the new one: # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif ? 4: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the master supplier: chmod 644 /tmp/master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/master-389.ldif ? 5: Restart the ipa daemons on the master supplier #ipactl start ? 6: When the daemon starts, it will see that it does not have an nsState and will write new CSN's to -all- of the newly imported good data with today's timetamp, we need to take that data and write -it- out to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif ^ the -r tells it to include all replica data which includes the newly blessed CSN data transfer the file to all of the ipa servers in the fleet ? 7: Now we must re-initialize _every other_ ipa consumer server in the fleet with the new good data. Steps 7-10 need to be done 1 at a time on each ipa consumer server ipactl stop ? 8: Sanitize the dse.ldif Configuration File On the ipa server: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== Delete the entire line ? 8.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif backup the old dse.ldif and replace it with the new one # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif ? 9: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the auth server: chmod 644 /tmp/replication-master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/replication-master-389.ldif ? 10: Restart the ipa daemons on the ipa server On the ipa server: ipactl start -------------------------------- From Rich Megginson: Further reading for those interested in the particulars of CSN tracking or the MultiMaster Replication algorithm, you can read up about it here: It all starts with the Leslie Lamport paper: http://www.stanford.edu/class/cs240/readings/lamport.pdf "Time, Clocks, and the Ordering of Events in a Distributed System" The next big impact on MMR protocols was the work done at Xerox PARC on the Bayou project. These and other sources formed the basis of the IETF LDUP working group. Much of the MMR protocol is based on the LDUP work. The tl;dr version is this: The MMR protocol is based on ordering operations by time so that when you have two updates to the same attribute, the "last one wins" So how do you guarantee some sort of consistent ordering throughout many systems that do not have clocks in sync down to the millisecond? If you say "ntp" then you lose... The protocol itself has to have some notion of time differences among servers The ordering is done by CSN (Change Sequence Number) The first part of the CSN is the timestamp of the operation in unix time_t (number of seconds since the epoch). In order to guarantee ordering, the MMR protocol has a major constraint You must never, never, issue a CSN that is the same or less than another CSN In order to guarantee that, the MMR protocol keeps track of the time differences among _all_ of the servers that it knows about. When it generates CSNs, it uses the largest time difference among all servers that it knows about. So how does the time skew grow at all? Due to timing differences, network latency, etc. the directory server cannot always generate the absolute exact system time. There will always be 1 or 2 second differences in some replication sessions. These 1 to 2 second differences accumulate over time. However, there are things which can introduce really large differences 1) buggy ntp implementations 2) bad sysadmin screws up the system clock 3) vms which are notorious for having laggy system clocks, etc. How can you monitor for this in the future? The readnsState.py script supplied in this email can be used to output the effective skew of the system date vs the CSN generator. You can set a crontab to run this script and monitor its output to catch any future severe drifts. Ticket information for some of the fixes that have been implimented because of this work so far: https://fedorahosted.org/389/ticket/47516 "You cannot hope to secure that which you do not first understand" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JR Aquino Senior Information Security Specialist, Technical Operations T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 GIAC Certified Exploit Researcher and Advanced Penetration Tester | GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler JR.Aquino at citrix.com Powering mobile workstyles and cloud services -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 15835 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pviktori at redhat.com Tue Feb 4 09:27:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Feb 2014 10:27:47 +0100 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52EF5064.7000304@redhat.com> References: <52EA771A.3080708@redhat.com> <52EA97CC.8030203@redhat.com> <52EB5ECE.2010500@redhat.com> <52EBC399.4030109@redhat.com> <52EF5064.7000304@redhat.com> Message-ID: <52F0B293.3010404@redhat.com> On 02/03/2014 09:16 AM, Martin Kosek wrote: > On 01/31/2014 04:39 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/30/2014 07:19 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> krbPwdPolicyReference is no longer filled default users. Instead, plugins >>>>> fallback to hardcoded global policy reference. >>>>> >>>>> Fix ipa-lockout plugin to fallback to it instead of failing to apply >>>>> the policy. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4085 >>>> >>>> NACK. >>>> >>>> I think you should include the value of krberr in error messages (we aren't >>>> exactly consistent in this elsewhere in the code but we need to start >>>> somewhere). >>>> >>>> You check the wrong value after the krb5_get_default_realm() call. >>>> >>>> It is probably better to use slapi_ch_free_string() than free(). >>>> >>>> At some point we'll need a common library where this sort of operation can be >>>> done. >>>> >>>> rob >>> >>> Good catch, sending updated patch. >>> >>> Martin >>> >> >> ACK > > Pushed to master, ipa-3-3. > > Martin I'm unable to install IPA on f20 with this patch. Does it work for you? -- Petr? From mkosek at redhat.com Tue Feb 4 10:08:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Feb 2014 11:08:13 +0100 Subject: [Freeipa-devel] [PATCH] 456 ipa-lockout: do not fail when default realm cannot be read Message-ID: <52F0BC0D.1020401@redhat.com> When ipa-lockout plugin is started during FreeIPA server installation, the default realm may not be available and plugin should then not end with failure. Similarly to other plugins, start in degraded mode in this situation. Operation is fully restored during the final services restart. https://fedorahosted.org/freeipa/ticket/4085 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-456-ipa-lockout-do-not-fail-when-default-realm-cannot-be.patch Type: text/x-patch Size: 2496 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 4 10:33:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Feb 2014 11:33:13 +0100 Subject: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin In-Reply-To: <52F0B293.3010404@redhat.com> References: <52EA771A.3080708@redhat.com> <52EA97CC.8030203@redhat.com> <52EB5ECE.2010500@redhat.com> <52EBC399.4030109@redhat.com> <52EF5064.7000304@redhat.com> <52F0B293.3010404@redhat.com> Message-ID: <52F0C1E9.9050108@redhat.com> On 02/04/2014 10:27 AM, Petr Viktorin wrote: > On 02/03/2014 09:16 AM, Martin Kosek wrote: >> On 01/31/2014 04:39 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 01/30/2014 07:19 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> krbPwdPolicyReference is no longer filled default users. Instead, plugins >>>>>> fallback to hardcoded global policy reference. >>>>>> >>>>>> Fix ipa-lockout plugin to fallback to it instead of failing to apply >>>>>> the policy. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4085 >>>>> >>>>> NACK. >>>>> >>>>> I think you should include the value of krberr in error messages (we aren't >>>>> exactly consistent in this elsewhere in the code but we need to start >>>>> somewhere). >>>>> >>>>> You check the wrong value after the krb5_get_default_realm() call. >>>>> >>>>> It is probably better to use slapi_ch_free_string() than free(). >>>>> >>>>> At some point we'll need a common library where this sort of operation can be >>>>> done. >>>>> >>>>> rob >>>> >>>> Good catch, sending updated patch. >>>> >>>> Martin >>>> >>> >>> ACK >> >> Pushed to master, ipa-3-3. >> >> Martin > > I'm unable to install IPA on f20 with this patch. Does it work for you? > Same here. I unfortunately tested this only on running IPA. See my patch 456, it fixes it. Martin From rcritten at redhat.com Tue Feb 4 11:42:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Feb 2014 12:42:10 +0100 Subject: [Freeipa-devel] [PATCH] 456 ipa-lockout: do not fail when default realm cannot be read In-Reply-To: <52F0BC0D.1020401@redhat.com> References: <52F0BC0D.1020401@redhat.com> Message-ID: <52F0D212.50305@redhat.com> Martin Kosek wrote: > When ipa-lockout plugin is started during FreeIPA server installation, > the default realm may not be available and plugin should then not end > with failure. > > Similarly to other plugins, start in degraded mode in this situation. > Operation is fully restored during the final services restart. > > https://fedorahosted.org/freeipa/ticket/4085 Sorry, I tested upgrading a server, not a new install. New patch works fine. ACK rob From mkosek at redhat.com Tue Feb 4 12:21:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Feb 2014 13:21:51 +0100 Subject: [Freeipa-devel] [PATCH] 456 ipa-lockout: do not fail when default realm cannot be read In-Reply-To: <52F0D212.50305@redhat.com> References: <52F0BC0D.1020401@redhat.com> <52F0D212.50305@redhat.com> Message-ID: <52F0DB5F.4080506@redhat.com> On 02/04/2014 12:42 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> When ipa-lockout plugin is started during FreeIPA server installation, >> the default realm may not be available and plugin should then not end >> with failure. >> >> Similarly to other plugins, start in degraded mode in this situation. >> Operation is fully restored during the final services restart. >> >> https://fedorahosted.org/freeipa/ticket/4085 > > Sorry, I tested upgrading a server, not a new install. New patch works fine. > > ACK > > rob > Pushed to master, ipa-3-3. Martin From jcholast at redhat.com Tue Feb 4 14:01:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 04 Feb 2014 15:01:46 +0100 Subject: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods Message-ID: <52F0F2CA.9070701@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-238-Fix-modlist-generation-code-not-to-generate-empty-re.patch Type: text/x-patch Size: 1121 bytes Desc: not available URL: From npmccallum at redhat.com Tue Feb 4 16:53:31 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 04 Feb 2014 11:53:31 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52DEA438.50904@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> Message-ID: <1391532811.20303.49.camel@localhost.localdomain> On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: > > Hi, > > > > these patches implements the OTP Web UI. > > > > Last 5 patches is the OTP UI. > > > > First 6 patches is a little refactoring/bug fixes needed for them. > > General password dialog is introduced to avoid another implementation. > > > > Self-service UI is implemented to be very simple. Atm user can choose > > only token name. Admin interface allows to enter all values. > > > > It's based on the RCUE work -> we need to push RCUE first. Thanks > > Nathaniel for review of the last font package. It will speed things up. > > > > Know bugs: > > - there is clash in id's of checkboxes preventing editation of > > subsequently displayed ones with the same name. Will be fixed in > > separate patch. > > - bugs caused by bugs in API (adding/removal of own tokens in > > self-service, inability to enter key on token creation - > > https://fedorahosted.org/freeipa/ticket/4099) > > - datetime format (widget+validator) will be implemented in separate patch > > - no support of not reviewed CLI patches (HOTP..) > > > > Cgit: > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > > > https://fedorahosted.org/freeipa/ticket/3369 > > > > Patches were rebased because of minor conflict with trusted domains patch. Patch 531 seems to have a spacing issue (tabs instead of spaces?) at the end of the first file. Nathaniel From pvoborni at redhat.com Tue Feb 4 17:44:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Feb 2014 18:44:19 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1391532811.20303.49.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391532811.20303.49.camel@localhost.localdomain> Message-ID: <52F126F3.1020306@redhat.com> On 4.2.2014 17:53, Nathaniel McCallum wrote: > On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >> On 13.1.2014 17:09, Petr Vobornik wrote: >>> Hi, >>> >>> these patches implements the OTP Web UI. >>> >>> Last 5 patches is the OTP UI. >>> >>> First 6 patches is a little refactoring/bug fixes needed for them. >>> General password dialog is introduced to avoid another implementation. >>> >>> Self-service UI is implemented to be very simple. Atm user can choose >>> only token name. Admin interface allows to enter all values. >>> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>> Nathaniel for review of the last font package. It will speed things up. >>> >>> Know bugs: >>> - there is clash in id's of checkboxes preventing editation of >>> subsequently displayed ones with the same name. Will be fixed in >>> separate patch. >>> - bugs caused by bugs in API (adding/removal of own tokens in >>> self-service, inability to enter key on token creation - >>> https://fedorahosted.org/freeipa/ticket/4099) >>> - datetime format (widget+validator) will be implemented in separate patch >>> - no support of not reviewed CLI patches (HOTP..) >>> >>> Cgit: >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>> >>> https://fedorahosted.org/freeipa/ticket/3369 >>> >> >> Patches were rebased because of minor conflict with trusted domains patch. > > Patch 531 seems to have a spacing issue (tabs instead of spaces?) at the > end of the first file. > > Nathaniel > Are you using the rebased patches 531-1 .. 541-1? (sent on 2014-01-21) They apply on master without any warning. -- Petr Vobornik From npmccallum at redhat.com Tue Feb 4 18:00:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 04 Feb 2014 13:00:03 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F126F3.1020306@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391532811.20303.49.camel@localhost.localdomain> <52F126F3.1020306@redhat.com> Message-ID: <1391536803.20303.52.camel@localhost.localdomain> On Tue, 2014-02-04 at 18:44 +0100, Petr Vobornik wrote: > On 4.2.2014 17:53, Nathaniel McCallum wrote: > > On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: > >> On 13.1.2014 17:09, Petr Vobornik wrote: > >>> Hi, > >>> > >>> these patches implements the OTP Web UI. > >>> > >>> Last 5 patches is the OTP UI. > >>> > >>> First 6 patches is a little refactoring/bug fixes needed for them. > >>> General password dialog is introduced to avoid another implementation. > >>> > >>> Self-service UI is implemented to be very simple. Atm user can choose > >>> only token name. Admin interface allows to enter all values. > >>> > >>> It's based on the RCUE work -> we need to push RCUE first. Thanks > >>> Nathaniel for review of the last font package. It will speed things up. > >>> > >>> Know bugs: > >>> - there is clash in id's of checkboxes preventing editation of > >>> subsequently displayed ones with the same name. Will be fixed in > >>> separate patch. > >>> - bugs caused by bugs in API (adding/removal of own tokens in > >>> self-service, inability to enter key on token creation - > >>> https://fedorahosted.org/freeipa/ticket/4099) > >>> - datetime format (widget+validator) will be implemented in separate patch > >>> - no support of not reviewed CLI patches (HOTP..) > >>> > >>> Cgit: > >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >>> > >>> https://fedorahosted.org/freeipa/ticket/3369 > >>> > >> > >> Patches were rebased because of minor conflict with trusted domains patch. > > > > Patch 531 seems to have a spacing issue (tabs instead of spaces?) at the > > end of the first file. > > > > Nathaniel > > > > Are you using the rebased patches 531-1 .. 541-1? (sent on 2014-01-21) Yes. > They apply on master without any warning. I found it with my eyes. :) Just look at the bottom of the details.js section of the patch. The line after "that.parser ..." is indented too far. Nathaniel From tbabej at redhat.com Wed Feb 5 05:49:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Feb 2014 06:49:19 +0100 Subject: [Freeipa-devel] [PATCH] 0451 integration tests OpenSSHTransport: Expand tilde to home in, root_ssh_key_filename In-Reply-To: <1389722627.26102.421.camel@willson.li.ssimo.org> References: <52D56DBC.9080207@redhat.com> <1389722627.26102.421.camel@willson.li.ssimo.org> Message-ID: <52F1D0DF.2060509@redhat.com> On 01/14/2014 07:03 PM, Simo Sorce wrote: > On Tue, 2014-01-14 at 18:02 +0100, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4115 >> >> The tilde was not expanded in the $IPA_ROOT_SSH_KEY configuration >> variable, so the default (~/.ssh/id_rsa) did not work. >> Here's a fix. > Looks good. > Simo. > ACK Tomas From pviktori at redhat.com Wed Feb 5 07:36:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 08:36:04 +0100 Subject: [Freeipa-devel] [PATCH] 0451 integration tests OpenSSHTransport: Expand tilde to home in, root_ssh_key_filename In-Reply-To: <52F1D0DF.2060509@redhat.com> References: <52D56DBC.9080207@redhat.com> <1389722627.26102.421.camel@willson.li.ssimo.org> <52F1D0DF.2060509@redhat.com> Message-ID: <52F1E9E4.3020405@redhat.com> On 02/05/2014 06:49 AM, Tomas Babej wrote: > > On 01/14/2014 07:03 PM, Simo Sorce wrote: >> On Tue, 2014-01-14 at 18:02 +0100, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/4115 >>> >>> The tilde was not expanded in the $IPA_ROOT_SSH_KEY configuration >>> variable, so the default (~/.ssh/id_rsa) did not work. >>> Here's a fix. >> Looks good. >> Simo. >> > > ACK > > Tomas Thank you! Pushed to master: 7b5124416b193ce026ff30f1968e00d8c800d881 ipa-3-3: 5741927de57be15c1907f7482f3a3f1178902395 -- Petr? From pvoborni at redhat.com Wed Feb 5 09:11:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 05 Feb 2014 10:11:56 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1391536803.20303.52.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391532811.20303.49.camel@localhost.localdomain> <52F126F3.1020306@redhat.com> <1391536803.20303.52.camel@localhost.localdomain> Message-ID: <52F2005C.6010907@redhat.com> On 4.2.2014 19:00, Nathaniel McCallum wrote: > On Tue, 2014-02-04 at 18:44 +0100, Petr Vobornik wrote: >> On 4.2.2014 17:53, Nathaniel McCallum wrote: >>> On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >>>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>>> Hi, >>>>> >>>>> these patches implements the OTP Web UI. >>>>> >>>>> Last 5 patches is the OTP UI. >>>>> >>>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>>> General password dialog is introduced to avoid another implementation. >>>>> >>>>> Self-service UI is implemented to be very simple. Atm user can choose >>>>> only token name. Admin interface allows to enter all values. >>>>> >>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>>> Nathaniel for review of the last font package. It will speed things up. >>>>> >>>>> Know bugs: >>>>> - there is clash in id's of checkboxes preventing editation of >>>>> subsequently displayed ones with the same name. Will be fixed in >>>>> separate patch. >>>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>>> self-service, inability to enter key on token creation - >>>>> https://fedorahosted.org/freeipa/ticket/4099) >>>>> - datetime format (widget+validator) will be implemented in separate patch >>>>> - no support of not reviewed CLI patches (HOTP..) >>>>> >>>>> Cgit: >>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3369 >>>>> >>>> >>>> Patches were rebased because of minor conflict with trusted domains patch. >>> >>> Patch 531 seems to have a spacing issue (tabs instead of spaces?) at the >>> end of the first file. >>> >>> Nathaniel >>> >> >> Are you using the rebased patches 531-1 .. 541-1? (sent on 2014-01-21) > > Yes. > >> They apply on master without any warning. > > I found it with my eyes. :) Yeah, sorry, I was under impression that you are talking about trailing whitespaces. > > Just look at the bottom of the details.js section of the patch. The line > after "that.parser ..." is indented too far. > > Nathaniel > You are right, there is incorrect indentation, but it's just spaces, no tabs. Fixed, patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-2-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: From pviktori at redhat.com Wed Feb 5 09:14:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 10:14:55 +0100 Subject: [Freeipa-devel] [PATCH] 0455 - ipa tool: Print the name of the server we are connecting to with -v Message-ID: <52F2010F.2020806@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/4135 in ipa-3-3. I'll send a patch form master soon. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa3.3-pviktori-0455-ipa-tool-Print-the-name-of-the-server-we-are-connect.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From tbabej at redhat.com Wed Feb 5 09:29:15 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Feb 2014 10:29:15 +0100 Subject: [Freeipa-devel] First batch of ipatests fixes Message-ID: <52F2046B.6080104@redhat.com> Hello, the attached patches fix the following tickets: https://fedorahosted.org/freeipa/ticket/4131 https://fedorahosted.org/freeipa/ticket/4130 https://fedorahosted.org/freeipa/ticket/4133 Details in the commit messages. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0143-ipatests-test_legacy_clients-Change-test-group-to-te.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0144-ipatests-Add-records-for-all-hosts-in-master-s-domai.patch Type: text/x-patch Size: 5171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0145-ipatests-Run-restoring-backup-files-and-restoring-th.patch Type: text/x-patch Size: 2486 bytes Desc: not available URL: From pviktori at redhat.com Wed Feb 5 09:49:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 10:49:36 +0100 Subject: [Freeipa-devel] [PATCH] 0455 - ipa tool: Print the name of the server we are connecting to with -v In-Reply-To: <52F2010F.2020806@redhat.com> References: <52F2010F.2020806@redhat.com> Message-ID: <52F20930.9070306@redhat.com> On 02/05/2014 10:14 AM, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/4135 in ipa-3-3. I'll > send a patch for master soon. Version for master is here. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0455-ipa-tool-Print-the-name-of-the-server-we-are-connect.patch Type: text/x-patch Size: 2712 bytes Desc: not available URL: From pviktori at redhat.com Wed Feb 5 10:23:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 11:23:35 +0100 Subject: [Freeipa-devel] First batch of ipatests fixes In-Reply-To: <52F2046B.6080104@redhat.com> References: <52F2046B.6080104@redhat.com> Message-ID: <52F21127.8040505@redhat.com> On 02/05/2014 10:29 AM, Tomas Babej wrote: > Hello, > > the attached patches fix the following tickets: > > https://fedorahosted.org/freeipa/ticket/4131 > https://fedorahosted.org/freeipa/ticket/4130 > https://fedorahosted.org/freeipa/ticket/4133 > > Details in the commit messages. > > Tomas > These look good, just a few nitpicks: Use a lowercase "A" in option and method names in 0144 to keep consistent with our naming convention. Add an article to the add_a_record docstring & man page: Adds an A record for the host to the IPA master and the help text for the host argument could be better: Host whose record should be added (or, Host for which the record should be added) -- Petr? From pviktori at redhat.com Wed Feb 5 11:47:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 12:47:40 +0100 Subject: [Freeipa-devel] First batch of ipatests fixes In-Reply-To: <52F21127.8040505@redhat.com> References: <52F2046B.6080104@redhat.com> <52F21127.8040505@redhat.com> Message-ID: <52F224DC.9020204@redhat.com> On 02/05/2014 11:23 AM, Petr Viktorin wrote: > On 02/05/2014 10:29 AM, Tomas Babej wrote: >> Hello, >> >> the attached patches fix the following tickets: >> >> https://fedorahosted.org/freeipa/ticket/4131 >> https://fedorahosted.org/freeipa/ticket/4130 >> https://fedorahosted.org/freeipa/ticket/4133 >> >> Details in the commit messages. >> >> Tomas >> > > These look good, just a few nitpicks: > > Use a lowercase "A" in option and method names in 0144 to keep > consistent with our naming convention. > > Add an article to the add_a_record docstring & man page: > Adds an A record for the host to the IPA master > > and the help text for the host argument could be better: > Host whose record should be added > (or, Host for which the record should be added) > Another issue, in 0145 the copyfiles_command should be run with raiseonerr=False, so we don't fail in cease the directory doesn't exist. -- Petr? From tbabej at redhat.com Wed Feb 5 11:56:48 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Feb 2014 12:56:48 +0100 Subject: [Freeipa-devel] [PATCH] 0455 - ipa tool: Print the name of the server we are connecting to with -v In-Reply-To: <52F20930.9070306@redhat.com> References: <52F2010F.2020806@redhat.com> <52F20930.9070306@redhat.com> Message-ID: <52F22700.9040301@redhat.com> ACK for both versions Tomas On 02/05/2014 10:49 AM, Petr Viktorin wrote: > On 02/05/2014 10:14 AM, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/4135 in ipa-3-3. I'll >> send a patch for master soon. > > Version for master is here. > > > > > _______________________________________________ > 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 tbabej at redhat.com Wed Feb 5 12:06:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Feb 2014 13:06:19 +0100 Subject: [Freeipa-devel] First batch of ipatests fixes In-Reply-To: <52F224DC.9020204@redhat.com> References: <52F2046B.6080104@redhat.com> <52F21127.8040505@redhat.com> <52F224DC.9020204@redhat.com> Message-ID: <52F2293B.9030009@redhat.com> On 02/05/2014 12:47 PM, Petr Viktorin wrote: > On 02/05/2014 11:23 AM, Petr Viktorin wrote: >> On 02/05/2014 10:29 AM, Tomas Babej wrote: >>> Hello, >>> >>> the attached patches fix the following tickets: >>> >>> https://fedorahosted.org/freeipa/ticket/4131 >>> https://fedorahosted.org/freeipa/ticket/4130 >>> https://fedorahosted.org/freeipa/ticket/4133 >>> >>> Details in the commit messages. >>> >>> Tomas >>> >> >> These look good, just a few nitpicks: >> >> Use a lowercase "A" in option and method names in 0144 to keep >> consistent with our naming convention. >> >> Add an article to the add_a_record docstring & man page: >> Adds an A record for the host to the IPA master >> >> and the help text for the host argument could be better: >> Host whose record should be added >> (or, Host for which the record should be added) >> > > Another issue, in 0145 the copyfiles_command should be run with > raiseonerr=False, so we don't fail in cease the directory doesn't exist. > Thank you for the review, updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0144-2-ipatests-Add-records-for-all-hosts-in-master-s-domai.patch Type: text/x-patch Size: 5174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0145-2-ipatests-Run-restoring-backup-files-and-restoring-th.patch Type: text/x-patch Size: 2492 bytes Desc: not available URL: From pviktori at redhat.com Wed Feb 5 14:25:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 15:25:17 +0100 Subject: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group In-Reply-To: <52EB6B72.4060602@redhat.com> References: <52E643CF.30906@redhat.com> <52E7AE1E.8090508@redhat.com> <52EB6B72.4060602@redhat.com> Message-ID: <52F249CD.1060706@redhat.com> On 01/31/2014 10:22 AM, Martin Kosek wrote: > On 01/28/2014 02:18 PM, Petr Viktorin wrote: >> On 01/27/2014 12:32 PM, Martin Kosek wrote: >>> When users with missing default group were searched, IPA suffix was >>> not passed so these users were searched in a wrong base DN. Thus, >>> no user was detected and added to default group. >>> >>> https://fedorahosted.org/freeipa/ticket/4141 >> >> This needs a rebase for the new LDAP API. > > I tested primarily on ipa-3-3 branch, I will rebase when acked. > >> I don't see the need for the second change, caching of len(new_members). On >> lists, len() is extremely fast. >> If you want to optimize, convert the list of existing members to a set before >> the for loop, instead of getting it from the entry and using the `in` operator >> (which is O(N) on lists) every time. > > Makes sense, done. > >> >> >> Nitpicks: >> >> Instead of "if len(container) > 0:" you should just use "if container:" (see >> PEP8). > > Fixed. > >> >> Instead of: >> members = group_entry_attrs.get('member', []) >> ... >> group_entry_attrs['member'] = members >> you can use: >> members = group_entry_attrs.setdefault('member', []) >> ... > > Fixed. > > New patch attached (tested). > > Martin Works fine, ACK. You can rebase to master now. -- Petr? From pviktori at redhat.com Wed Feb 5 14:40:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 15:40:42 +0100 Subject: [Freeipa-devel] First batch of ipatests fixes In-Reply-To: <52F2293B.9030009@redhat.com> References: <52F2046B.6080104@redhat.com> <52F21127.8040505@redhat.com> <52F224DC.9020204@redhat.com> <52F2293B.9030009@redhat.com> Message-ID: <52F24D6A.8060606@redhat.com> On 02/05/2014 01:06 PM, Tomas Babej wrote: > > On 02/05/2014 12:47 PM, Petr Viktorin wrote: >> On 02/05/2014 11:23 AM, Petr Viktorin wrote: >>> On 02/05/2014 10:29 AM, Tomas Babej wrote: >>>> Hello, >>>> >>>> the attached patches fix the following tickets: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4131 >>>> https://fedorahosted.org/freeipa/ticket/4130 >>>> https://fedorahosted.org/freeipa/ticket/4133 >>>> >>>> Details in the commit messages. >>>> >>>> Tomas >>>> >>> >>> These look good, just a few nitpicks: >>> >>> Use a lowercase "A" in option and method names in 0144 to keep >>> consistent with our naming convention. >>> >>> Add an article to the add_a_record docstring & man page: >>> Adds an A record for the host to the IPA master >>> >>> and the help text for the host argument could be better: >>> Host whose record should be added >>> (or, Host for which the record should be added) >>> >> >> Another issue, in 0145 the copyfiles_command should be run with >> raiseonerr=False, so we don't fail in cease the directory doesn't exist. >> > > Thank you for the review, updated patches attached. Thank you! ACK, pushed to master: 1601860023193ec295458a71f1f097edbb57d787 ipa-3-3: 57e6b5bdc540551312fd674c56ded7dbb7322677 -- Petr? From pviktori at redhat.com Wed Feb 5 14:41:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Feb 2014 15:41:29 +0100 Subject: [Freeipa-devel] [PATCH] 0455 - ipa tool: Print the name of the server we are connecting to with -v In-Reply-To: <52F22700.9040301@redhat.com> References: <52F2010F.2020806@redhat.com> <52F20930.9070306@redhat.com> <52F22700.9040301@redhat.com> Message-ID: <52F24D99.6080801@redhat.com> On 02/05/2014 12:56 PM, Tomas Babej wrote: > ACK for both versions Thanks, pushed to: master: 894b70a164f06a865504e49cd4763670e4e1f8f6 ipa-3-3: 6347340eb468a1483e189e4cd8b22590b928f688 > Tomas > > On 02/05/2014 10:49 AM, Petr Viktorin wrote: >> On 02/05/2014 10:14 AM, Petr Viktorin wrote: >>> Hello, >>> This fixes https://fedorahosted.org/freeipa/ticket/4135 in ipa-3-3. I'll >>> send a patch for master soon. >> >> Version for master is here. -- Petr? From mkosek at redhat.com Wed Feb 5 15:54:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Feb 2014 16:54:22 +0100 Subject: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group In-Reply-To: <52F249CD.1060706@redhat.com> References: <52E643CF.30906@redhat.com> <52E7AE1E.8090508@redhat.com> <52EB6B72.4060602@redhat.com> <52F249CD.1060706@redhat.com> Message-ID: <52F25EAE.1090104@redhat.com> On 02/05/2014 03:25 PM, Petr Viktorin wrote: > On 01/31/2014 10:22 AM, Martin Kosek wrote: >> On 01/28/2014 02:18 PM, Petr Viktorin wrote: >>> On 01/27/2014 12:32 PM, Martin Kosek wrote: >>>> When users with missing default group were searched, IPA suffix was >>>> not passed so these users were searched in a wrong base DN. Thus, >>>> no user was detected and added to default group. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4141 >>> >>> This needs a rebase for the new LDAP API. >> >> I tested primarily on ipa-3-3 branch, I will rebase when acked. >> >>> I don't see the need for the second change, caching of len(new_members). On >>> lists, len() is extremely fast. >>> If you want to optimize, convert the list of existing members to a set before >>> the for loop, instead of getting it from the entry and using the `in` operator >>> (which is O(N) on lists) every time. >> >> Makes sense, done. >> >>> >>> >>> Nitpicks: >>> >>> Instead of "if len(container) > 0:" you should just use "if container:" (see >>> PEP8). >> >> Fixed. >> >>> >>> Instead of: >>> members = group_entry_attrs.get('member', []) >>> ... >>> group_entry_attrs['member'] = members >>> you can use: >>> members = group_entry_attrs.setdefault('member', []) >>> ... >> >> Fixed. >> >> New patch attached (tested). >> >> Martin > > Works fine, ACK. You can rebase to master now. Rebased the patch to master and pushed to master, ipa-3-3. Martin From npmccallum at redhat.com Wed Feb 5 17:38:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 05 Feb 2014 12:38:49 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52DEA438.50904@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> Message-ID: <1391621929.20303.64.camel@localhost.localdomain> On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: > from ipaserver.dcerpc import DomainValidator Patch 541 is NACK because ipaserver.dcerpc only exists in freeipa-server-trust-ad. Nathaniel From abokovoy at redhat.com Wed Feb 5 17:54:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Feb 2014 19:54:09 +0200 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1391621929.20303.64.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391621929.20303.64.camel@localhost.localdomain> Message-ID: <20140205175409.GK7586@redhat.com> On Wed, 05 Feb 2014, Nathaniel McCallum wrote: >On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >> from ipaserver.dcerpc import DomainValidator > >Patch 541 is NACK because ipaserver.dcerpc only exists in >freeipa-server-trust-ad. I agree. Instead of modifying a highly specialized code in ipaserver.dcerpc, you can extend a general purpose kinit code in ipapython/ipautil.py or add a separate one there to handle FAST part. -- / Alexander Bokovoy From npmccallum at redhat.com Wed Feb 5 19:59:55 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 05 Feb 2014 14:59:55 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52DEA438.50904@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> Message-ID: <1391630395.20303.66.camel@localhost.localdomain> The Add Token dialog asks the user to specify a unique id. This unique id should be generated instead. See how I did this in the CLI. It should work in this case too. Nathaniel On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: > > Hi, > > > > these patches implements the OTP Web UI. > > > > Last 5 patches is the OTP UI. > > > > First 6 patches is a little refactoring/bug fixes needed for them. > > General password dialog is introduced to avoid another implementation. > > > > Self-service UI is implemented to be very simple. Atm user can choose > > only token name. Admin interface allows to enter all values. > > > > It's based on the RCUE work -> we need to push RCUE first. Thanks > > Nathaniel for review of the last font package. It will speed things up. > > > > Know bugs: > > - there is clash in id's of checkboxes preventing editation of > > subsequently displayed ones with the same name. Will be fixed in > > separate patch. > > - bugs caused by bugs in API (adding/removal of own tokens in > > self-service, inability to enter key on token creation - > > https://fedorahosted.org/freeipa/ticket/4099) > > - datetime format (widget+validator) will be implemented in separate patch > > - no support of not reviewed CLI patches (HOTP..) > > > > Cgit: > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > > > https://fedorahosted.org/freeipa/ticket/3369 > > > > Patches were rebased because of minor conflict with trusted domains patch. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tbabej at redhat.com Thu Feb 6 06:06:42 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Feb 2014 07:06:42 +0100 Subject: [Freeipa-devel] Second batch of ipatests fixes and improvements Message-ID: <52F32672.1020808@redhat.com> Hi, the attached patches fix the following tickets https://fedorahosted.org/freeipa/ticket/4134 https://fedorahosted.org/freeipa/ticket/4132 and some additional errors as well. Comments in the commit messages. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0146-ipatests-legacy_clients-Test-legacy-clients-with-non.patch Type: text/x-patch Size: 6654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0147-ipatests-Perform-a-connection-test-before-preparing-.patch Type: text/x-patch Size: 1397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0149-ipatests-Make-sure-we-re-kinit-as-admin-before-addin.patch Type: text/x-patch Size: 1174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0150-2-ipatests-Stop-sssd-service-before-deleting-the-cache.patch Type: text/x-patch Size: 1246 bytes Desc: not available URL: From jcholast at redhat.com Thu Feb 6 09:59:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Feb 2014 10:59:08 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> Message-ID: <52F35CEC.4050603@redhat.com> Hi, On 31.1.2014 16:06, Martin Basti wrote: > Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > allowed. > > Ticket: https://fedorahosted.org/freeipa/ticket/4143 > Patches attached. I think the validation should be more strict. IPv4 reverse zones should allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash at all. +def _cname_hostname_validator(ugettext, value): Can you name this _bind_cname_hostname_validator, so that it is clear it is related to _bind_hostname_validator? + #classless reverse zones can contain slash '/' + if not zone_is_reverse(normalized_zone) and (normalized_zone.count('/') > 0): + raise errors.ValidationError(name='name', + error=_("Only reverse zones can contain '/' in labels")) This should be handled in _domain_name_validator. Validation in pre_callback should be done only when the validation depends on values of multiple parameters, which is not this case. + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, **options): Rename this to _idnsname_pre_callback and you won't have to call it explicitly in run_precallback_validators. + if addr.count('/') > 0: I think "if '/' in addr:" would be better. -def validate_dns_label(dns_label, allow_underscore=False): +def validate_dns_label(dns_label, allow_underscore=False, allow_slash=False): IMO instead of adding a new boolean argument, it would be nicer to replace allow_underscore with an argument (e.g. allowed_chars) which takes a string of extra allowed characters. Honza -- Jan Cholasta From jcholast at redhat.com Thu Feb 6 12:16:02 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Feb 2014 13:16:02 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule Message-ID: <52F37D02.1040905@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-239-Remove-sourcehostcategory-from-the-default-HBAC-rule.patch Type: text/x-patch Size: 3292 bytes Desc: not available URL: From pvoborni at redhat.com Thu Feb 6 12:36:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Feb 2014 13:36:59 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1391630395.20303.66.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391630395.20303.66.camel@localhost.localdomain> Message-ID: <52F381EB.6000203@redhat.com> On 5.2.2014 20:59, Nathaniel McCallum wrote: > The Add Token dialog asks the user to specify a unique id. This unique > id should be generated instead. See how I did this in the CLI. It should > work in this case too. > > Nathaniel Fixed. I have not added proper handling of `optional_create` flag in Web UI, because it might affect details pages in unwanted manner. Because of that, otptoken dialog's `ipatokenuniqueid` field now use `required=false` override. > > On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >> On 13.1.2014 17:09, Petr Vobornik wrote: >>> Hi, >>> >>> these patches implements the OTP Web UI. >>> >>> Last 5 patches is the OTP UI. >>> >>> First 6 patches is a little refactoring/bug fixes needed for them. >>> General password dialog is introduced to avoid another implementation. >>> >>> Self-service UI is implemented to be very simple. Atm user can choose >>> only token name. Admin interface allows to enter all values. >>> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>> Nathaniel for review of the last font package. It will speed things up. >>> >>> Know bugs: >>> - there is clash in id's of checkboxes preventing editation of >>> subsequently displayed ones with the same name. Will be fixed in >>> separate patch. >>> - bugs caused by bugs in API (adding/removal of own tokens in >>> self-service, inability to enter key on token creation - >>> https://fedorahosted.org/freeipa/ticket/4099) >>> - datetime format (widget+validator) will be implemented in separate patch >>> - no support of not reviewed CLI patches (HOTP..) >>> >>> Cgit: >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>> >>> https://fedorahosted.org/freeipa/ticket/3369 >>> >> >> Patches were rebased because of minor conflict with trusted domains patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-2-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15662 bytes Desc: not available URL: From pvoborni at redhat.com Thu Feb 6 12:46:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Feb 2014 13:46:41 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F381EB.6000203@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391630395.20303.66.camel@localhost.localdomain> <52F381EB.6000203@redhat.com> Message-ID: <52F38431.8090002@redhat.com> The sent patch was exactly the same as 537-1. Correct patch attached. On 6.2.2014 13:36, Petr Vobornik wrote: > On 5.2.2014 20:59, Nathaniel McCallum wrote: >> The Add Token dialog asks the user to specify a unique id. This unique >> id should be generated instead. See how I did this in the CLI. It should >> work in this case too. >> >> Nathaniel > > Fixed. > > I have not added proper handling of `optional_create` flag in Web UI, > because it might affect details pages in unwanted manner. > > Because of that, otptoken dialog's `ipatokenuniqueid` field now use > `required=false` override. > >> >> On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>> Hi, >>>> >>>> these patches implements the OTP Web UI. >>>> >>>> Last 5 patches is the OTP UI. >>>> >>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>> General password dialog is introduced to avoid another implementation. >>>> >>>> Self-service UI is implemented to be very simple. Atm user can choose >>>> only token name. Admin interface allows to enter all values. >>>> >>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>> Nathaniel for review of the last font package. It will speed things up. >>>> >>>> Know bugs: >>>> - there is clash in id's of checkboxes preventing editation of >>>> subsequently displayed ones with the same name. Will be fixed in >>>> separate patch. >>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>> self-service, inability to enter key on token creation - >>>> https://fedorahosted.org/freeipa/ticket/4099) >>>> - datetime format (widget+validator) will be implemented in separate >>>> patch >>>> - no support of not reviewed CLI patches (HOTP..) >>>> >>>> Cgit: >>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>> >>>> https://fedorahosted.org/freeipa/ticket/3369 >>>> >>> >>> Patches were rebased because of minor conflict with trusted domains >>> patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-3-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15810 bytes Desc: not available URL: From pvoborni at redhat.com Thu Feb 6 13:11:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Feb 2014 14:11:30 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <20140205175409.GK7586@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391621929.20303.64.camel@localhost.localdomain> <20140205175409.GK7586@redhat.com> Message-ID: <52F38A02.2060906@redhat.com> On 5.2.2014 18:54, Alexander Bokovoy wrote: > On Wed, 05 Feb 2014, Nathaniel McCallum wrote: >> On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >>> from ipaserver.dcerpc import DomainValidator >> >> Patch 541 is NACK because ipaserver.dcerpc only exists in >> freeipa-server-trust-ad. > I agree. Instead of modifying a highly specialized code in > ipaserver.dcerpc, you can extend a general purpose kinit code in > ipapython/ipautil.py or add a separate one there to handle FAST part. > I've implemented new version of patch 541 which doesn't use dcerpc module (attached). This new version might be incorrect as well. The new form based login works as follows: - calls kinit with HTTP keytab to get armor ccache - calls kinit with user credantials and armor_ccache - calls kdestroy to cleanup the armor_ccache It was inspired by existing code in dcerpc.py and rpcserver.py. The question is whether we should avoid calling sub-processes and rather use krbV lib as in ipapython.ipautil.kinit_hostprincipal. Rob mentioned that subprocess calls within Apache are quite expensive. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-2-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 6 13:30:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Feb 2014 15:30:34 +0200 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F38A02.2060906@redhat.com> References: <52D40FD7.5090301@redhat.com> <52DEA438.50904@redhat.com> <1391621929.20303.64.camel@localhost.localdomain> <20140205175409.GK7586@redhat.com> <52F38A02.2060906@redhat.com> Message-ID: <20140206133034.GM7586@redhat.com> On Thu, 06 Feb 2014, Petr Vobornik wrote: >On 5.2.2014 18:54, Alexander Bokovoy wrote: >>On Wed, 05 Feb 2014, Nathaniel McCallum wrote: >>>On Tue, 2014-01-21 at 17:45 +0100, Petr Vobornik wrote: >>>>from ipaserver.dcerpc import DomainValidator >>> >>>Patch 541 is NACK because ipaserver.dcerpc only exists in >>>freeipa-server-trust-ad. >>I agree. Instead of modifying a highly specialized code in >>ipaserver.dcerpc, you can extend a general purpose kinit code in >>ipapython/ipautil.py or add a separate one there to handle FAST part. >> > >I've implemented new version of patch 541 which doesn't use dcerpc >module (attached). > >This new version might be incorrect as well. The new form based login >works as follows: >- calls kinit with HTTP keytab to get armor ccache >- calls kinit with user credantials and armor_ccache >- calls kdestroy to cleanup the armor_ccache > >It was inspired by existing code in dcerpc.py and rpcserver.py. > >The question is whether we should avoid calling sub-processes and >rather use krbV lib as in ipapython.ipautil.kinit_hostprincipal. Rob >mentioned that subprocess calls within Apache are quite expensive. Yes, they are. Given that it only needs to happen once per session setup, it might be affordable in most cases. The main issue, however, is whether krbV supports using armor ccache or not. Looking at the code, it seems it is possible to do double rotation, by passing an existing ccache object and using a different principal but the code fails: # python Python 2.7.5 (default, Nov 12 2013, 16:45:54) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import krbV >>> cc=krbV.CCache(primary_principal=krbV.Principal('host/masteripa.ipa.weald.vda.li')) >>> cc1=krbV.CCache(ccache=cc,primary_principal=krbV.Principal('admin')) Segmentation fault # -- / Alexander Bokovoy From asantos at uc.pt Thu Feb 6 14:22:04 2014 From: asantos at uc.pt (Alexandre Santos) Date: Thu, 6 Feb 2014 14:22:04 +0000 Subject: [Freeipa-devel] Web services in freeIPA Message-ID: Hi, I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. I would like to know if there is any information about that. Thanks Alexandre Santos -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Feb 6 14:33:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Feb 2014 15:33:43 +0100 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: References: Message-ID: <52F39D47.4050902@redhat.com> On 6.2.2014 15:22, Alexandre Santos wrote: > Hi, > > I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. > > I would like to know if there is any information about that. > > Thanks > > Alexandre Santos > The url you saw is most-likely for XML RPC API. You can check: https://hostname/ipa/xml - XML RPC API https://hostname/ipa/json - JSON RPC API https://hostname/ipa/session/xml XML RPC API with session support https://hostname/ipa/session/json JSON RPC API with session support https://hostname/ipa/ui - Web UI https://hostname/ipa/config/unauthorized.html - some config and error pages We don't have docs for the APIs yet. -- Petr Vobornik From asantos at uc.pt Thu Feb 6 14:52:17 2014 From: asantos at uc.pt (Alexandre Santos) Date: Thu, 6 Feb 2014 14:52:17 +0000 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <52F39D47.4050902@redhat.com> References: <52F39D47.4050902@redhat.com> Message-ID: <76403A7F-B761-4170-A73D-01C6E7CD37CD@uc.pt> Thanks, I think I have what i need. Best regards On 06 Feb 2014, at 14:33, Petr Vobornik wrote: > On 6.2.2014 15:22, Alexandre Santos wrote: >> Hi, >> >> I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. >> >> I would like to know if there is any information about that. >> >> Thanks >> >> Alexandre Santos >> > > The url you saw is most-likely for XML RPC API. > > You can check: > > https://hostname/ipa/xml - XML RPC API > https://hostname/ipa/json - JSON RPC API > https://hostname/ipa/session/xml XML RPC API with session support > https://hostname/ipa/session/json JSON RPC API with session support > https://hostname/ipa/ui - Web UI > https://hostname/ipa/config/unauthorized.html - some config and error pages > > We don't have docs for the APIs yet. > -- > Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 6 14:57:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 06 Feb 2014 15:57:51 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52F35CEC.4050603@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> Message-ID: <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > Hi, > > On 31.1.2014 16:06, Martin Basti wrote: > > Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > > allowed. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/4143 > > Patches attached. > I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > I think the validation should be more strict. IPv4 reverse zones should > allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is > valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash > at all. > I havent found anything about IPv6, RFCs don't forbids it. 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to CNAME records The slashes in domain names are referenced as the best practise in RFC, there are not strict rules. > > +def _cname_hostname_validator(ugettext, value): > > Can you name this _bind_cname_hostname_validator, so that it is clear it > is related to _bind_hostname_validator? > I will rename it > > + #classless reverse zones can contain slash '/' > + if not zone_is_reverse(normalized_zone) and > (normalized_zone.count('/') > 0): > + raise errors.ValidationError(name='name', > + error=_("Only reverse zones can contain '/' in > labels")) > > This should be handled in _domain_name_validator. Validation in > pre_callback should be done only when the validation depends on values > of multiple parameters, which is not this case. > I will move it > > + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, > **options): > > Rename this to _idnsname_pre_callback and you won't have to call it > explicitly in run_precallback_validators. > I will rename it > > + if addr.count('/') > 0: > > I think "if '/' in addr:" would be better. > I will change it > > -def validate_dns_label(dns_label, allow_underscore=False): > +def validate_dns_label(dns_label, allow_underscore=False, > allow_slash=False): > > IMO instead of adding a new boolean argument, it would be nicer to > replace allow_underscore with an argument (e.g. allowed_chars) which > takes a string of extra allowed characters. > But I have to handle not only allowed chars, but position of the chars in the label string too. > > Honza > -- Martin^2 Basti From mkosek at redhat.com Thu Feb 6 15:04:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 16:04:25 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule In-Reply-To: <52F37D02.1040905@redhat.com> References: <52F37D02.1040905@redhat.com> Message-ID: <52F3A479.7060500@redhat.com> On 02/06/2014 01:16 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Adding a whole new update plugin for this little change seems as a overengineering for me. Why does a simple "remove: sourcehostcategory: all" not work? Also, I would be OK with even just not adding it in new installation only. It is a benign attribute which also may not be deprecated in older version (and replicated) replicas. Martin From asantos at uc.pt Thu Feb 6 15:04:32 2014 From: asantos at uc.pt (Alexandre Santos) Date: Thu, 6 Feb 2014 15:04:32 +0000 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <52F39D47.4050902@redhat.com> References: <52F39D47.4050902@redhat.com> Message-ID: <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> Is there any examples that can guide me. Thanks Alexandre Santos On 06 Feb 2014, at 14:33, Petr Vobornik wrote: > On 6.2.2014 15:22, Alexandre Santos wrote: >> Hi, >> >> I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. >> >> I would like to know if there is any information about that. >> >> Thanks >> >> Alexandre Santos >> > > The url you saw is most-likely for XML RPC API. > > You can check: > > https://hostname/ipa/xml - XML RPC API > https://hostname/ipa/json - JSON RPC API > https://hostname/ipa/session/xml XML RPC API with session support > https://hostname/ipa/session/json JSON RPC API with session support > https://hostname/ipa/ui - Web UI > https://hostname/ipa/config/unauthorized.html - some config and error pages > > We don't have docs for the APIs yet. > -- > Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 6 15:12:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 16:12:53 +0100 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> Message-ID: <52F3A675.3030602@redhat.com> As Petr said, we do not have a proper documentation for using RPC for controlling IPA. But I think you can start with looking at [1] to see the template and try running our commands with "-vv" which will show you how we call the API: $ ipa -vv user-show admin Martin [1] http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ On 02/06/2014 04:04 PM, Alexandre Santos wrote: > > Is there any examples that can guide me. > > Thanks > Alexandre Santos > > On 06 Feb 2014, at 14:33, Petr Vobornik wrote: > >> On 6.2.2014 15:22, Alexandre Santos wrote: >>> Hi, >>> >>> I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. >>> >>> I would like to know if there is any information about that. >>> >>> Thanks >>> >>> Alexandre Santos >>> >> >> The url you saw is most-likely for XML RPC API. >> >> You can check: >> >> https://hostname/ipa/xml - XML RPC API >> https://hostname/ipa/json - JSON RPC API >> https://hostname/ipa/session/xml XML RPC API with session support >> https://hostname/ipa/session/json JSON RPC API with session support >> https://hostname/ipa/ui - Web UI >> https://hostname/ipa/config/unauthorized.html - some config and error pages >> >> We don't have docs for the APIs yet. >> -- >> Petr Vobornik > From jcholast at redhat.com Thu Feb 6 15:21:15 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Feb 2014 16:21:15 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule In-Reply-To: <52F3A479.7060500@redhat.com> References: <52F37D02.1040905@redhat.com> <52F3A479.7060500@redhat.com> Message-ID: <52F3A86B.9040809@redhat.com> On 6.2.2014 16:04, Martin Kosek wrote: > On 02/06/2014 01:16 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Adding a whole new update plugin for this little change seems as a > overengineering for me. Why does a simple "remove: sourcehostcategory: all" not > work? Because there is no simple "dn: ..." to put above it, since it uses auto-generated ipaUniqueId. > > Also, I would be OK with even just not adding it in new installation only. It > is a benign attribute which also may not be deprecated in older version (and > replicated) replicas. If it is not removed, it will still be shown in hbacrule commands' output. Is it OK to remove sourcehostcategory from hbacrule.default_attributes? I'm not sure why it was left there when source hosts were deprecated. > > Martin > -- Jan Cholasta From mkosek at redhat.com Thu Feb 6 15:20:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 16:20:35 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule In-Reply-To: <52F3A86B.9040809@redhat.com> References: <52F37D02.1040905@redhat.com> <52F3A479.7060500@redhat.com> <52F3A86B.9040809@redhat.com> Message-ID: <52F3A843.7090103@redhat.com> On 02/06/2014 04:21 PM, Jan Cholasta wrote: > On 6.2.2014 16:04, Martin Kosek wrote: >> On 02/06/2014 01:16 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Adding a whole new update plugin for this little change seems as a >> overengineering for me. Why does a simple "remove: sourcehostcategory: all" not >> work? > > Because there is no simple "dn: ..." to put above it, since it uses > auto-generated ipaUniqueId. Ah, I see. > >> >> Also, I would be OK with even just not adding it in new installation only. It >> is a benign attribute which also may not be deprecated in older version (and >> replicated) replicas. > > If it is not removed, it will still be shown in hbacrule commands' output. Is > it OK to remove sourcehostcategory from hbacrule.default_attributes? I'm not > sure why it was left there when source hosts were deprecated. Makes sense. I think removing it from default LDIF + from default_attributes will do the trick. Martin From dpal at redhat.com Thu Feb 6 15:29:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 Feb 2014 10:29:07 -0500 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <52F3A675.3030602@redhat.com> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> Message-ID: <52F3AA43.6040107@redhat.com> On 02/06/2014 10:12 AM, Martin Kosek wrote: > As Petr said, we do not have a proper documentation for using RPC for > controlling IPA. But I think you can start with looking at [1] to see the > template and try running our commands with "-vv" which will show you how we > call the API: > > $ ipa -vv user-show admin Are we still suggesting using XML interface? I though we were planning to prefer JSON rather than XML, something changed here? > > Martin > > [1] http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > > On 02/06/2014 04:04 PM, Alexandre Santos wrote: >> Is there any examples that can guide me. >> >> Thanks >> Alexandre Santos >> >> On 06 Feb 2014, at 14:33, Petr Vobornik wrote: >> >>> On 6.2.2014 15:22, Alexandre Santos wrote: >>>> Hi, >>>> >>>> I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. >>>> >>>> I would like to know if there is any information about that. >>>> >>>> Thanks >>>> >>>> Alexandre Santos >>>> >>> The url you saw is most-likely for XML RPC API. >>> >>> You can check: >>> >>> https://hostname/ipa/xml - XML RPC API >>> https://hostname/ipa/json - JSON RPC API >>> https://hostname/ipa/session/xml XML RPC API with session support >>> https://hostname/ipa/session/json JSON RPC API with session support >>> https://hostname/ipa/ui - Web UI >>> https://hostname/ipa/config/unauthorized.html - some config and error pages >>> >>> We don't have docs for the APIs yet. >>> -- >>> Petr Vobornik > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Thu Feb 6 15:37:55 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Feb 2014 16:37:55 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> Message-ID: <52F3AC53.7040505@redhat.com> On 6.2.2014 15:57, Martin Basti wrote: > On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >> Hi, >> >> On 31.1.2014 16:06, Martin Basti wrote: >>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>> allowed. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>> Patches attached. >> > I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > >> I think the validation should be more strict. IPv4 reverse zones should >> allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is >> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash >> at all. >> > I havent found anything about IPv6, RFCs don't forbids it. AFAIK the RFCs do not forbid anything, but we do validation anyway, so we might as well do it right, otherwise there is no point in doing it. > 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to CNAME > records Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned about. > The slashes in domain names are referenced as the best practise in RFC, > there are not strict rules. >> >> +def _cname_hostname_validator(ugettext, value): >> >> Can you name this _bind_cname_hostname_validator, so that it is clear it >> is related to _bind_hostname_validator? >> > I will rename it > >> >> + #classless reverse zones can contain slash '/' >> + if not zone_is_reverse(normalized_zone) and >> (normalized_zone.count('/') > 0): >> + raise errors.ValidationError(name='name', >> + error=_("Only reverse zones can contain '/' in >> labels")) >> >> This should be handled in _domain_name_validator. Validation in >> pre_callback should be done only when the validation depends on values >> of multiple parameters, which is not this case. >> > I will move it >> >> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, >> **options): >> >> Rename this to _idnsname_pre_callback and you won't have to call it >> explicitly in run_precallback_validators. >> > I will rename it >> >> + if addr.count('/') > 0: >> >> I think "if '/' in addr:" would be better. >> > I will change it > >> >> -def validate_dns_label(dns_label, allow_underscore=False): >> +def validate_dns_label(dns_label, allow_underscore=False, >> allow_slash=False): >> >> IMO instead of adding a new boolean argument, it would be nicer to >> replace allow_underscore with an argument (e.g. allowed_chars) which >> takes a string of extra allowed characters. >> > But I have to handle not only allowed chars, but position of the chars > in the label string too. Why? Is there a RFC that forbids it? My point is, adding a new argument for each extra character is bad, there should be a better way of doing that. -- Jan Cholasta From jcholast at redhat.com Thu Feb 6 15:46:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Feb 2014 16:46:10 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule In-Reply-To: <52F3A843.7090103@redhat.com> References: <52F37D02.1040905@redhat.com> <52F3A479.7060500@redhat.com> <52F3A86B.9040809@redhat.com> <52F3A843.7090103@redhat.com> Message-ID: <52F3AE42.6060808@redhat.com> On 6.2.2014 16:20, Martin Kosek wrote: > On 02/06/2014 04:21 PM, Jan Cholasta wrote: >> On 6.2.2014 16:04, Martin Kosek wrote: >>> On 02/06/2014 01:16 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes . >>>> >>>> Honza >>> >>> Adding a whole new update plugin for this little change seems as a >>> overengineering for me. Why does a simple "remove: sourcehostcategory: all" not >>> work? >> >> Because there is no simple "dn: ..." to put above it, since it uses >> auto-generated ipaUniqueId. > > Ah, I see. > >> >>> >>> Also, I would be OK with even just not adding it in new installation only. It >>> is a benign attribute which also may not be deprecated in older version (and >>> replicated) replicas. >> >> If it is not removed, it will still be shown in hbacrule commands' output. Is >> it OK to remove sourcehostcategory from hbacrule.default_attributes? I'm not >> sure why it was left there when source hosts were deprecated. > > Makes sense. I think removing it from default LDIF + from default_attributes > will do the trick. > > Martin > Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-239.1-Remove-sourcehostcategory-from-the-default-HBAC-rule.patch Type: text/x-patch Size: 1384 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 6 15:52:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 16:52:49 +0100 Subject: [Freeipa-devel] [PATCH] 239 Remove sourcehostcategory from the default HBAC rule In-Reply-To: <52F3AE42.6060808@redhat.com> References: <52F37D02.1040905@redhat.com> <52F3A479.7060500@redhat.com> <52F3A86B.9040809@redhat.com> <52F3A843.7090103@redhat.com> <52F3AE42.6060808@redhat.com> Message-ID: <52F3AFD1.2080009@redhat.com> On 02/06/2014 04:46 PM, Jan Cholasta wrote: > On 6.2.2014 16:20, Martin Kosek wrote: >> On 02/06/2014 04:21 PM, Jan Cholasta wrote: >>> On 6.2.2014 16:04, Martin Kosek wrote: >>>> On 02/06/2014 01:16 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes . >>>>> >>>>> Honza >>>> >>>> Adding a whole new update plugin for this little change seems as a >>>> overengineering for me. Why does a simple "remove: sourcehostcategory: all" >>>> not >>>> work? >>> >>> Because there is no simple "dn: ..." to put above it, since it uses >>> auto-generated ipaUniqueId. >> >> Ah, I see. >> >>> >>>> >>>> Also, I would be OK with even just not adding it in new installation only. It >>>> is a benign attribute which also may not be deprecated in older version (and >>>> replicated) replicas. >>> >>> If it is not removed, it will still be shown in hbacrule commands' output. Is >>> it OK to remove sourcehostcategory from hbacrule.default_attributes? I'm not >>> sure why it was left there when source hosts were deprecated. >> >> Makes sense. I think removing it from default LDIF + from default_attributes >> will do the trick. >> >> Martin >> > > Updated patch attached. > ACK. Pushed to master, ipa-3-3. Martin From npmccallum at redhat.com Thu Feb 6 16:02:20 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Feb 2014 11:02:20 -0500 Subject: [Freeipa-devel] [PATCH 0035] ipa-kdb: validate that an OTP user has tokens Message-ID: <1391702540.20303.68.camel@localhost.localdomain> This patch is independent of any of my other patches and can be merged out of order. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0035-ipa-kdb-validate-that-an-OTP-user-has-tokens.patch Type: text/x-patch Size: 10152 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 6 16:04:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 06 Feb 2014 17:04:01 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52F3AC53.7040505@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> Message-ID: <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: > On 6.2.2014 15:57, Martin Basti wrote: > > On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > >> Hi, > >> > >> On 31.1.2014 16:06, Martin Basti wrote: > >>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > >>> allowed. > >>> > >>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 > >>> Patches attached. > >> > > I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > > > >> I think the validation should be more strict. IPv4 reverse zones should > >> allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is > >> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash > >> at all. > >> > > I havent found anything about IPv6, RFCs don't forbids it. > > AFAIK the RFCs do not forbid anything, but we do validation anyway, so > we might as well do it right, otherwise there is no point in doing it. > OK, I leave there only IPv4 > > 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to CNAME > > records > > Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned about. > http://tools.ietf.org/html/rfc6672#section-6.2 This can give a very strange positions of / in FQDN Optionally, I could permit only 1 slash in domain name, but I have to inspect first if user can do something useful with subnet of subnet in DNS, like 1.0/25.128/25.168.192.in-addr.arpa > > The slashes in domain names are referenced as the best practise in RFC, > > there are not strict rules. > >> > >> +def _cname_hostname_validator(ugettext, value): > >> > >> Can you name this _bind_cname_hostname_validator, so that it is clear it > >> is related to _bind_hostname_validator? > >> > > I will rename it > > > >> > >> + #classless reverse zones can contain slash '/' > >> + if not zone_is_reverse(normalized_zone) and > >> (normalized_zone.count('/') > 0): > >> + raise errors.ValidationError(name='name', > >> + error=_("Only reverse zones can contain '/' in > >> labels")) > >> > >> This should be handled in _domain_name_validator. Validation in > >> pre_callback should be done only when the validation depends on values > >> of multiple parameters, which is not this case. > >> > > I will move it > >> > >> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, > >> **options): > >> > >> Rename this to _idnsname_pre_callback and you won't have to call it > >> explicitly in run_precallback_validators. > >> > > I will rename it > >> > >> + if addr.count('/') > 0: > >> > >> I think "if '/' in addr:" would be better. > >> > > I will change it > > > >> > >> -def validate_dns_label(dns_label, allow_underscore=False): > >> +def validate_dns_label(dns_label, allow_underscore=False, > >> allow_slash=False): > >> > >> IMO instead of adding a new boolean argument, it would be nicer to > >> replace allow_underscore with an argument (e.g. allowed_chars) which > >> takes a string of extra allowed characters. > >> > > But I have to handle not only allowed chars, but position of the chars > > in the label string too. > > Why? Is there a RFC that forbids it? > > My point is, adding a new argument for each extra character is bad, > there should be a better way of doing that. > I agree, but for example: "_" should be at start (it is not required be at the start in IPA), "/" and "-" in the middle. -- Martin^2 Basti From mkosek at redhat.com Thu Feb 6 16:43:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 17:43:21 +0100 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <52F3AA43.6040107@redhat.com> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <52F3AA43.6040107@redhat.com> Message-ID: <52F3BBA9.7050009@redhat.com> On 02/06/2014 04:29 PM, Dmitri Pal wrote: > On 02/06/2014 10:12 AM, Martin Kosek wrote: >> As Petr said, we do not have a proper documentation for using RPC for >> controlling IPA. But I think you can start with looking at [1] to see the >> template and try running our commands with "-vv" which will show you how we >> call the API: >> >> $ ipa -vv user-show admin > > Are we still suggesting using XML interface? > I though we were planning to prefer JSON rather than XML, something > changed here? No, we prefer JSON. In currently developed FreeIPA version (3.4) we already switched to it by default [1]. So if the command above is run in this version, it will show the actual JSON-RPC query asked on the server. If run in older FreeIPA client, it will still use the XML-RPC. Martin [1] https://fedorahosted.org/freeipa/ticket/3299 From npmccallum at redhat.com Thu Feb 6 18:25:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Feb 2014 13:25:54 -0500 Subject: [Freeipa-devel] Second batch of ipatests fixes and improvements In-Reply-To: <52F32672.1020808@redhat.com> References: <52F32672.1020808@redhat.com> Message-ID: <1391711154.1830.19.camel@localhost.localdomain> On Thu, 2014-02-06 at 07:06 +0100, Tomas Babej wrote: > Hi, > > the attached patches fix the following tickets > > https://fedorahosted.org/freeipa/ticket/4134 > https://fedorahosted.org/freeipa/ticket/4132 > > and some additional errors as well. Comments in the commit messages. 0146: ACK 0147: ACK 0148: ACK 0149: ACK 0150: ACK Nathaniel From npmccallum at redhat.com Thu Feb 6 18:41:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Feb 2014 13:41:15 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1389303173.1962.11.camel@localhost.localdomain> References: <1389303173.1962.11.camel@localhost.localdomain> Message-ID: <1391712075.1830.28.camel@localhost.localdomain> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > This patch is independent from my patches 0028-0031 and can be merged in > any order. > > This patch has a bug, but I can't figure it out. We need to set > nsslapd-access-userattr-strict on cn=config to "off". However, during > the rpm installation, I get this error: > > DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting > attributes is not allowed', 'desc': 'Server is unwilling to perform'} > ERROR Update failed: Server is unwilling to perform: Deleting attributes > is not allowed > > I'm not sure what is causing this. Does anyone have any suggestions? Attached is a new revision of this patch. It uses the new SELFDN support present in 389-ds-base 1.3.2.11 that was a result of the previous review of this patch. It currently depends on the HOTP patch (0033-2). However, if we wish to merge this first, this could be easily rebased. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0032-1-Update-ACIs-to-permit-users-to-add-delete-their-own-.patch Type: text/x-patch Size: 4556 bytes Desc: not available URL: From tbabej at redhat.com Fri Feb 7 05:01:25 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 07 Feb 2014 06:01:25 +0100 Subject: [Freeipa-devel] Third batch of ipatests fixes Message-ID: <52F468A5.2070309@redhat.com> Hello, this is the third and final batch. Please note that patch 148 has been already ACKed by Nathaniel :) (by mistake, so please look it over again) Details in the commit messages. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0148--ipatests-Add-test-cases-for-subdomain-users-on-legac.patch Type: text/x-patch Size: 8697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0151-ipatests-Change-expected-home-directories-returned-b.patch Type: text/x-patch Size: 4640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0152-ipatests-Do-not-require-group-name-resolution-for-th.patch Type: text/x-patch Size: 3129 bytes Desc: not available URL: From asantos at uc.pt Fri Feb 7 09:33:57 2014 From: asantos at uc.pt (Alexandre Santos) Date: Fri, 7 Feb 2014 09:33:57 +0000 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <52F3A675.3030602@redhat.com> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> Message-ID: <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> Hi Martin, I?ve tried your example and i get this error: curl -v \ -H "Content-Type:application/json" \ -H "Accept:applicaton/json"\ --negotiate -u : \ --delegation always \ --cacert /etc/ipa/ca.crt \ -d '{"method":"user_find","params":[[""],{}],"id":0}' \ -X POST https://ipa/ipa/json ... > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: pi > Content-Type:application/json > Accept:applicaton/json > Content-Length: 48 > < HTTP/1.1 200 Success < Date: Thu, 06 Feb 2014 16:42:26 GMT < Server: Apache/2.2.15 (CentOS) < Connection: close < Transfer-Encoding: chunked < Content-Type: application/json; charset=utf-8 < { "error": { "code": 911, "message": "Missing or invalid HTTP Referer, missing", "name": { "__base64__": "UmVmZXJlckVycm9y" } }, "id": null, "principal": ?admin at ipa", "result": null, "version": "3.0.0" * Closing connection #0 Any suggestion? Alexandre Santos On 06 Feb 2014, at 15:12, Martin Kosek wrote: > As Petr said, we do not have a proper documentation for using RPC for > controlling IPA. But I think you can start with looking at [1] to see the > template and try running our commands with "-vv" which will show you how we > call the API: > > $ ipa -vv user-show admin > > Martin > > [1] http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > > On 02/06/2014 04:04 PM, Alexandre Santos wrote: >> >> Is there any examples that can guide me. >> >> Thanks >> Alexandre Santos >> >> On 06 Feb 2014, at 14:33, Petr Vobornik wrote: >> >>> On 6.2.2014 15:22, Alexandre Santos wrote: >>>> Hi, >>>> >>>> I?m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I?ve seen that when i use the command "ipa -vv user-add? a url for the app if given. >>>> >>>> I would like to know if there is any information about that. >>>> >>>> Thanks >>>> >>>> Alexandre Santos >>>> >>> >>> The url you saw is most-likely for XML RPC API. >>> >>> You can check: >>> >>> https://hostname/ipa/xml - XML RPC API >>> https://hostname/ipa/json - JSON RPC API >>> https://hostname/ipa/session/xml XML RPC API with session support >>> https://hostname/ipa/session/json JSON RPC API with session support >>> https://hostname/ipa/ui - Web UI >>> https://hostname/ipa/config/unauthorized.html - some config and error pages >>> >>> We don't have docs for the APIs yet. >>> -- >>> Petr Vobornik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Feb 7 09:42:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Feb 2014 10:42:10 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> Message-ID: <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: > On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: > > On 6.2.2014 15:57, Martin Basti wrote: > > > On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > > >> Hi, > > >> > > >> On 31.1.2014 16:06, Martin Basti wrote: > > >>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > > >>> allowed. > > >>> > > >>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 > > >>> Patches attached. > > >> > > > I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > > > > > >> I think the validation should be more strict. IPv4 reverse zones should > > >> allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is > > >> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash > > >> at all. > > >> > > > I havent found anything about IPv6, RFCs don't forbids it. > > > > AFAIK the RFCs do not forbid anything, but we do validation anyway, so > > we might as well do it right, otherwise there is no point in doing it. > > > OK, I leave there only IPv4 > > > > 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to CNAME > > > records > > > > Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned about. > > > > http://tools.ietf.org/html/rfc6672#section-6.2 > This can give a very strange positions of / in FQDN > > Optionally, I could permit only 1 slash in domain name, but I have to > inspect first if user can do something useful with subnet of subnet in > DNS, like 1.0/25.128/25.168.192.in-addr.arpa > > > The slashes in domain names are referenced as the best practise in RFC, > > > there are not strict rules. > > >> > > >> +def _cname_hostname_validator(ugettext, value): > > >> > > >> Can you name this _bind_cname_hostname_validator, so that it is clear it > > >> is related to _bind_hostname_validator? > > >> > > > I will rename it > > > > > >> > > >> + #classless reverse zones can contain slash '/' > > >> + if not zone_is_reverse(normalized_zone) and > > >> (normalized_zone.count('/') > 0): > > >> + raise errors.ValidationError(name='name', > > >> + error=_("Only reverse zones can contain '/' in > > >> labels")) > > >> > > >> This should be handled in _domain_name_validator. Validation in > > >> pre_callback should be done only when the validation depends on values > > >> of multiple parameters, which is not this case. > > >> > > > I will move it > > >> > > >> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, > > >> **options): > > >> > > >> Rename this to _idnsname_pre_callback and you won't have to call it > > >> explicitly in run_precallback_validators. > > >> > > > I will rename it > > >> > > >> + if addr.count('/') > 0: > > >> > > >> I think "if '/' in addr:" would be better. > > >> > > > I will change it > > > > > >> > > >> -def validate_dns_label(dns_label, allow_underscore=False): > > >> +def validate_dns_label(dns_label, allow_underscore=False, > > >> allow_slash=False): > > >> > > >> IMO instead of adding a new boolean argument, it would be nicer to > > >> replace allow_underscore with an argument (e.g. allowed_chars) which > > >> takes a string of extra allowed characters. > > >> > > > But I have to handle not only allowed chars, but position of the chars > > > in the label string too. > > > > Why? Is there a RFC that forbids it? > > > > My point is, adding a new argument for each extra character is bad, > > there should be a better way of doing that. > > > I agree, but for example: "_" should be at start (it is not required be > at the start in IPA), "/" and "-" in the middle. > Updated patch attached. Patch for tests is the same as previos. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0024-2-DNS-classless-support-for-reverse-domains.patch Type: text/x-patch Size: 9118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0025-DNS-tests-for-classless-reverse-domains.patch Type: text/x-patch Size: 14149 bytes Desc: not available URL: From abokovoy at redhat.com Fri Feb 7 09:45:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Feb 2014 11:45:36 +0200 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> Message-ID: <20140207094536.GQ7586@redhat.com> On Fri, 07 Feb 2014, Alexandre Santos wrote: >Hi Martin, > >I?ve tried your example and i get this error: > >curl -v \ > -H "Content-Type:application/json" \ > -H "Accept:applicaton/json"\ > --negotiate -u : \ > --delegation always \ > --cacert /etc/ipa/ca.crt \ > -d '{"method":"user_find","params":[[""],{}],"id":0}' \ > -X POST https://ipa/ipa/json > >... > >> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 >> Host: pi >> Content-Type:application/json >> Accept:applicaton/json >> Content-Length: 48 >> >< HTTP/1.1 200 Success >< Date: Thu, 06 Feb 2014 16:42:26 GMT >< Server: Apache/2.2.15 (CentOS) >< Connection: close >< Transfer-Encoding: chunked >< Content-Type: application/json; charset=utf-8 >< >{ > "error": { > "code": 911, > "message": "Missing or invalid HTTP Referer, missing", > "name": { > "__base64__": "UmVmZXJlckVycm9y" > } > }, > "id": null, > "principal": ?admin at ipa", > "result": null, > "version": "3.0.0" >* Closing connection #0 > > >Any suggestion? You need to set the referrer. -H referer:https://ipa.mybox/ipa/ui/index.html -- / Alexander Bokovoy From npmccallum at redhat.com Fri Feb 7 17:09:56 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 07 Feb 2014 12:09:56 -0500 Subject: [Freeipa-devel] [PATCH 0036] Move ipa-otpd socket directory Message-ID: <1391792996.17145.8.camel@localhost.localdomain> NOTE: Special care is required with this patch. Specifically, it needs to be synchronized with this patch: https://github.com/krb5/krb5/pull/45 The background here is the desire of SELinux folks to move the sockets into /run. MIT has agreed to use the new runstatedir in autoconf git master (soon to be 2.70). This change has been applied upstream and will be part of the 1.13 release. The major downside is that this patch is backwards incompatible. In the interest of making backwards incompatible changes as quickly as possible before increased adoption, Nalin and I have agreed to backport this patch to rawhide. We are also strongly considering a backport to F20. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0036-Move-ipa-otpd-socket-directory.patch Type: text/x-patch Size: 2717 bytes Desc: not available URL: From pvoborni at redhat.com Sat Feb 8 17:16:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Sat, 08 Feb 2014 18:16:33 +0100 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> Message-ID: <52F66671.3070408@redhat.com> On 7.2.2014 10:33, Alexandre Santos wrote: > Hi Martin, > > I?ve tried your example and i get this error: > > curl -v \ > -H "Content-Type:application/json" \ > -H "Accept:applicaton/json"\ > --negotiate -u : \ > --delegation always \ > --cacert /etc/ipa/ca.crt \ > -d '{"method":"user_find","params":[[""],{}],"id":0}' \ > -X POST https://ipa/ipa/json Just add -H "Referer: https://ipa/ipa/json" \ FreeIPA server checks the referer to prevent CSRF. > > ... > > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: pi > > Content-Type:application/json > > Accept:applicaton/json > > Content-Length: 48 > > > < HTTP/1.1 200 Success > < Date: Thu, 06 Feb 2014 16:42:26 GMT > < Server: Apache/2.2.15 (CentOS) > < Connection: close > < Transfer-Encoding: chunked > < Content-Type: application/json; charset=utf-8 > < > { > "error": { > "code": 911, > "message": "Missing or invalid HTTP Referer, missing", > "name": { > "__base64__": "UmVmZXJlckVycm9y" > } > }, > "id": null, > "principal": ?admin at ipa", > "result": null, > "version": "3.0.0" > * Closing connection #0 > > > Any suggestion? > > Alexandre Santos > > On 06 Feb 2014, at 15:12, Martin Kosek > wrote: > >> As Petr said, we do not have a proper documentation for using RPC for >> controlling IPA. But I think you can start with looking at [1] to see the >> template and try running our commands with "-vv" which will show you >> how we >> call the API: >> >> $ ipa -vv user-show admin >> >> Martin >> >> [1] >> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >> >> On 02/06/2014 04:04 PM, Alexandre Santos wrote: >>> >>> Is there any examples that can guide me. >>> >>> Thanks >>> Alexandre Santos >>> >>> On 06 Feb 2014, at 14:33, Petr Vobornik >> > wrote: >>> >>>> On 6.2.2014 15:22, Alexandre Santos wrote: >>>>> Hi, >>>>> >>>>> I?m starting in freeIPA and I would like to know what web apps are >>>>> available for use, like create user, delete user and so on. I?ve >>>>> seen that when i use the command "ipa -vv user-add? a url for the >>>>> app if given. >>>>> >>>>> I would like to know if there is any information about that. >>>>> >>>>> Thanks >>>>> >>>>> Alexandre Santos >>>>> >>>> >>>> The url you saw is most-likely for XML RPC API. >>>> >>>> You can check: >>>> >>>> https://hostname/ipa/xml - XML RPC API >>>> https://hostname/ipa/json - JSON RPC API >>>> https://hostname/ipa/session/xml XML RPC API with session support >>>> https://hostname/ipa/session/json JSON RPC API with session support >>>> https://hostname/ipa/ui - Web UI >>>> https://hostname/ipa/config/unauthorized.html - some config and >>>> error pages >>>> >>>> We don't have docs for the APIs yet. >>>> -- >>>> Petr Vobornik >>> >> > -- Petr Vobornik From pspacek at redhat.com Mon Feb 10 07:50:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 10 Feb 2014 08:50:13 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> Message-ID: <52F884B5.8090501@redhat.com> On 7.2.2014 10:42, Martin Basti wrote: > On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>> On 6.2.2014 15:57, Martin Basti wrote: >>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>> allowed. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>> Patches attached. >>>>> >>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>> >>>>> I think the validation should be more strict. IPv4 reverse zones should >>>>> allow slash only in the label for the last octet (i.e. 0/25.1.168.192 is >>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow slash >>>>> at all. >>>>> >>>> I havent found anything about IPv6, RFCs don't forbids it. >>> >>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>> we might as well do it right, otherwise there is no point in doing it. >>> >> OK, I leave there only IPv4 >> >>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to CNAME >>>> records >>> >>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned about. >>> >> >> http://tools.ietf.org/html/rfc6672#section-6.2 >> This can give a very strange positions of / in FQDN >> >> Optionally, I could permit only 1 slash in domain name, but I have to >> inspect first if user can do something useful with subnet of subnet in >> DNS, like 1.0/25.128/25.168.192.in-addr.arpa Multiple slashes has to be allowed, without limitation to last octet. Imagine situation when split subnet is later split to even smaller pieces. Guys, do not over-engineer it. IMHO this validator should produce a warning is something is not as we expect but it should not block user from adding a record. We have had enough problems with too strict validators in the past and IMHO warning is the way to go. Petr^2 Spacek >>>> The slashes in domain names are referenced as the best practise in RFC, >>>> there are not strict rules. >>>>> >>>>> +def _cname_hostname_validator(ugettext, value): >>>>> >>>>> Can you name this _bind_cname_hostname_validator, so that it is clear it >>>>> is related to _bind_hostname_validator? >>>>> >>>> I will rename it >>>> >>>>> >>>>> + #classless reverse zones can contain slash '/' >>>>> + if not zone_is_reverse(normalized_zone) and >>>>> (normalized_zone.count('/') > 0): >>>>> + raise errors.ValidationError(name='name', >>>>> + error=_("Only reverse zones can contain '/' in >>>>> labels")) >>>>> >>>>> This should be handled in _domain_name_validator. Validation in >>>>> pre_callback should be done only when the validation depends on values >>>>> of multiple parameters, which is not this case. >>>>> >>>> I will move it >>>>> >>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, >>>>> **options): >>>>> >>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>> explicitly in run_precallback_validators. >>>>> >>>> I will rename it >>>>> >>>>> + if addr.count('/') > 0: >>>>> >>>>> I think "if '/' in addr:" would be better. >>>>> >>>> I will change it >>>> >>>>> >>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>> allow_slash=False): >>>>> >>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>> takes a string of extra allowed characters. >>>>> >>>> But I have to handle not only allowed chars, but position of the chars >>>> in the label string too. >>> >>> Why? Is there a RFC that forbids it? >>> >>> My point is, adding a new argument for each extra character is bad, >>> there should be a better way of doing that. >>> >> I agree, but for example: "_" should be at start (it is not required be >> at the start in IPA), "/" and "-" in the middle. >> > > Updated patch attached. > Patch for tests is the same as previos. -- Petr^2 Spacek From asantos at uc.pt Mon Feb 10 09:13:01 2014 From: asantos at uc.pt (Alexandre Santos) Date: Mon, 10 Feb 2014 09:13:01 +0000 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <9B77D11D-B662-4F97-A676-E16192FAF95C@uc.pt> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> <20140207094536.GQ7586@redhat.com> <9B77D11D-B662-4F97-A676-E16192FAF95C@uc.pt> Message-ID: I have to install the new version, I have the 3.2 installed. I have to integrate the web apps to my web administration site, so i can add, remove, update and find users. Thanks Alexandre Santos On 07 Feb 2014, at 15:15, Alexandre Santos wrote: > Thanks, i?m new to this json. How can i find the methods available and there options? > > Thanks > > Alexandre Santos > > > On 07 Feb 2014, at 09:45, Alexander Bokovoy wrote: > >> On Fri, 07 Feb 2014, Alexandre Santos wrote: >>> Hi Martin, >>> >>> I?ve tried your example and i get this error: >>> >>> curl -v \ >>> -H "Content-Type:application/json" \ >>> -H "Accept:applicaton/json"\ >>> --negotiate -u : \ >>> --delegation always \ >>> --cacert /etc/ipa/ca.crt \ >>> -d '{"method":"user_find","params":[[""],{}],"id":0}' \ >>> -X POST https://ipa/ipa/json >>> >>> ... >>> >>>> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 >>>> Host: pi >>>> Content-Type:application/json >>>> Accept:applicaton/json >>>> Content-Length: 48 >>>> >>> < HTTP/1.1 200 Success >>> < Date: Thu, 06 Feb 2014 16:42:26 GMT >>> < Server: Apache/2.2.15 (CentOS) >>> < Connection: close >>> < Transfer-Encoding: chunked >>> < Content-Type: application/json; charset=utf-8 >>> < >>> { >>> "error": { >>> "code": 911, >>> "message": "Missing or invalid HTTP Referer, missing", >>> "name": { >>> "__base64__": "UmVmZXJlckVycm9y" >>> } >>> }, >>> "id": null, >>> "principal": ?admin at ipa", >>> "result": null, >>> "version": "3.0.0" >>> * Closing connection #0 >>> >>> >>> Any suggestion? >> You need to set the referrer. >> >> -H referer:https://ipa.mybox/ipa/ui/index.html >> -- >> / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 10 09:22:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 10:22:35 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52E81498.7040204@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> Message-ID: <52F89A5B.2090707@redhat.com> On 01/28/2014 09:35 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... >> The URL endpoint /ipa/rest suggests that if we implement a complete REST >> API for IPA it would live here. Is the API supposed to be >> future-compatible? (The API itself seems to be a good subset of a >> complete REST API, but can we easily add an frontend with >> authentication, i18n, etc. here later, and keep the limitations for >> unauthenticated access?) >> Perhaps /ipa/smartproxy would be a better choice? > > It was future-proofing. I'm fine with changing the URI, it is probably a good > thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin From mkosek at redhat.com Mon Feb 10 09:31:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 10:31:58 +0100 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> <20140207094536.GQ7586@redhat.com> <9B77D11D-B662-4F97-A676-E16192FAF95C@uc.pt> Message-ID: <52F89C8E.10208@redhat.com> As this is not documented, I am thinking the easiest approach will be to open Web UI and see what JSON requests it sends to IPA for desired actions. I tested that for example with Chrome developer tools and I could easily see that for showing a particular user it uses following JSON: {"method":"user_show","params":[["fbar"],{"all":true,"rights":true}]} or for user-del: {"method":"user_del","params":[["fbar"],{}]} Martin On 02/10/2014 10:13 AM, Alexandre Santos wrote: > I have to install the new version, I have the 3.2 installed. > > I have to integrate the web apps to my web administration site, so i can add, remove, update and find users. > > Thanks > > Alexandre Santos > > On 07 Feb 2014, at 15:15, Alexandre Santos wrote: > >> Thanks, i?m new to this json. How can i find the methods available and there options? >> >> Thanks >> >> Alexandre Santos >> >> >> On 07 Feb 2014, at 09:45, Alexander Bokovoy wrote: >> >>> On Fri, 07 Feb 2014, Alexandre Santos wrote: >>>> Hi Martin, >>>> >>>> I?ve tried your example and i get this error: >>>> >>>> curl -v \ >>>> -H "Content-Type:application/json" \ >>>> -H "Accept:applicaton/json"\ >>>> --negotiate -u : \ >>>> --delegation always \ >>>> --cacert /etc/ipa/ca.crt \ >>>> -d '{"method":"user_find","params":[[""],{}],"id":0}' \ >>>> -X POST https://ipa/ipa/json >>>> >>>> ... >>>> >>>>> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 >>>>> Host: pi >>>>> Content-Type:application/json >>>>> Accept:applicaton/json >>>>> Content-Length: 48 >>>>> >>>> < HTTP/1.1 200 Success >>>> < Date: Thu, 06 Feb 2014 16:42:26 GMT >>>> < Server: Apache/2.2.15 (CentOS) >>>> < Connection: close >>>> < Transfer-Encoding: chunked >>>> < Content-Type: application/json; charset=utf-8 >>>> < >>>> { >>>> "error": { >>>> "code": 911, >>>> "message": "Missing or invalid HTTP Referer, missing", >>>> "name": { >>>> "__base64__": "UmVmZXJlckVycm9y" >>>> } >>>> }, >>>> "id": null, >>>> "principal": ?admin at ipa", >>>> "result": null, >>>> "version": "3.0.0" >>>> * Closing connection #0 >>>> >>>> >>>> Any suggestion? >>> You need to set the referrer. >>> >>> -H referer:https://ipa.mybox/ipa/ui/index.html >>> -- >>> / Alexander Bokovoy >> > > From pviktori at redhat.com Mon Feb 10 09:39:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Feb 2014 10:39:59 +0100 Subject: [Freeipa-devel] Second batch of ipatests fixes and improvements In-Reply-To: <1391711154.1830.19.camel@localhost.localdomain> References: <52F32672.1020808@redhat.com> <1391711154.1830.19.camel@localhost.localdomain> Message-ID: <52F89E6F.4090809@redhat.com> On 02/06/2014 07:25 PM, Nathaniel McCallum wrote: > On Thu, 2014-02-06 at 07:06 +0100, Tomas Babej wrote: >> Hi, >> >> the attached patches fix the following tickets >> >> https://fedorahosted.org/freeipa/ticket/4134 >> https://fedorahosted.org/freeipa/ticket/4132 >> >> and some additional errors as well. Comments in the commit messages. > > 0146: ACK > 0147: ACK > 0148: ACK > 0149: ACK > 0150: ACK > > Nathaniel Pushed to: master: daf2d64f83c4bd4d0fe60323f51d63e8355652b7 ipa-3-3: b99de765f942d4c4bcdf164d666aa997f593343e -- Petr? From mkosek at redhat.com Mon Feb 10 10:03:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 11:03:43 +0100 Subject: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones Message-ID: <52F8A3FF.10200@redhat.com> Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) "Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) "Pilsner" -> "Future releases" (with appropriate milestone description to set the expectations right) b) "Beer Exchange" -> "Backlog" (with better description) c) "Deferred" - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From jcholast at redhat.com Mon Feb 10 11:22:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Feb 2014 12:22:45 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52F884B5.8090501@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> Message-ID: <52F8B685.3020603@redhat.com> On 10.2.2014 08:50, Petr Spacek wrote: > On 7.2.2014 10:42, Martin Basti wrote: >> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>>> On 6.2.2014 15:57, Martin Basti wrote: >>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>>> allowed. >>>>>>> >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>>> Patches attached. >>>>>> >>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>>> >>>>>> I think the validation should be more strict. IPv4 reverse zones >>>>>> should >>>>>> allow slash only in the label for the last octet (i.e. >>>>>> 0/25.1.168.192 is >>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow >>>>>> slash >>>>>> at all. >>>>>> >>>>> I havent found anything about IPv6, RFCs don't forbids it. >>>> >>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>>> we might as well do it right, otherwise there is no point in doing it. >>>> >>> OK, I leave there only IPv4 For the record, we discussed this off-line with Martin and Petr and figured out it would be best to allow slashes in IPv6 reverse zones after all. >>> >>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to >>>>> CNAME >>>>> records >>>> >>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned >>>> about. >>>> >>> >>> http://tools.ietf.org/html/rfc6672#section-6.2 >>> This can give a very strange positions of / in FQDN Point taken. >>> >>> Optionally, I could permit only 1 slash in domain name, but I have to >>> inspect first if user can do something useful with subnet of subnet in >>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa > Multiple slashes has to be allowed, without limitation to last octet. > Imagine situation when split subnet is later split to even smaller pieces. > > Guys, do not over-engineer it. IMHO this validator should produce a > warning is something is not as we expect but it should not block user > from adding a record. > > We have had enough problems with too strict validators in the past and > IMHO warning is the way to go. I agree, but it's too late to get such change into 3.3.x. > > Petr^2 Spacek > >>>>> The slashes in domain names are referenced as the best practise in >>>>> RFC, >>>>> there are not strict rules. >>>>>> >>>>>> +def _cname_hostname_validator(ugettext, value): >>>>>> >>>>>> Can you name this _bind_cname_hostname_validator, so that it is >>>>>> clear it >>>>>> is related to _bind_hostname_validator? >>>>>> >>>>> I will rename it >>>>> >>>>>> >>>>>> + #classless reverse zones can contain slash '/' >>>>>> + if not zone_is_reverse(normalized_zone) and >>>>>> (normalized_zone.count('/') > 0): >>>>>> + raise errors.ValidationError(name='name', >>>>>> + error=_("Only reverse zones can contain >>>>>> '/' in >>>>>> labels")) >>>>>> >>>>>> This should be handled in _domain_name_validator. Validation in >>>>>> pre_callback should be done only when the validation depends on >>>>>> values >>>>>> of multiple parameters, which is not this case. >>>>>> >>>>> I will move it >>>>>> >>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, >>>>>> *keys, >>>>>> **options): >>>>>> >>>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>>> explicitly in run_precallback_validators. >>>>>> >>>>> I will rename it >>>>>> >>>>>> + if addr.count('/') > 0: >>>>>> >>>>>> I think "if '/' in addr:" would be better. >>>>>> >>>>> I will change it >>>>> >>>>>> >>>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>>> allow_slash=False): >>>>>> >>>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>>> takes a string of extra allowed characters. >>>>>> >>>>> But I have to handle not only allowed chars, but position of the chars >>>>> in the label string too. >>>> >>>> Why? Is there a RFC that forbids it? >>>> >>>> My point is, adding a new argument for each extra character is bad, >>>> there should be a better way of doing that. >>>> >>> I agree, but for example: "_" should be at start (it is not required be >>> at the start in IPA), "/" and "-" in the middle. OK then. (But I still don't like it.) >>> >> >> Updated patch attached. >> Patch for tests is the same as previos. + validate_domain_name(value, allow_slash=True) + + #classless reverse zones can contain slash '/' + normalized_zone = normalize_zone(value) + if not zone_is_reverse(normalized_zone) and ('/' in normalized_zone): + return u"Only reverse zones can contain '/' in labels" You don't need to enclose "x in y" in parentheses. Also I don't think there is any value in pointing out that slash can be used for reverse zones when giving an error for non-reverse zones. I would prefer something like this instead: normalized_zone = normalize_zone(value) validate_domain_mame(value, allow_slash=zone_is_reverse(normalized_zone)) + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + #in reverse zone can a record name contains /, (and -) + + if self.is_pkey_zone_record(*keys): + addr = u'' + else: + addr = keys[-1] + + zone = keys[-2] + zone = normalize_zone(zone) + if (not zone_is_reverse(zone)) and ('/' in addr): + raise errors.ValidationError(name='name', + error=unicode(_('Only domain names in reverse zones can contain \'/\'')) ) I think you can do better (from the top of my head and untested): if not self.is_pkey_zone_record(*keys): zone, addr = normalize_zone(keys[-2]), keys[-1] try: validate_domain_name(addr + zone, allow_slash=zone_is_reverse(zone)) except ValueError, e: raise errors.ValidationError(name='idnsname', error=str(e)) + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check + #zone has to be checked without reverse domain suffix (in-addr.arpa.) + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: + pass + else: + ip_addr_comp_count = addr_len + len(zone.split('.')) + if ip_addr_comp_count != zone_len: + raise errors.ValidationError(name='ptrrecord', + error=unicode(_('Reverse zone %(name)s requires exactly %(count)d IP address components, %(user_count)d given') + % dict(name=zone_name, count=zone_len, user_count=ip_addr_comp_count))) Is there anything preventing us from dropping this whole check? I don't think it makes sense anymore. IMHO validate_dns_label is very ugly. I would prefer if it looked something like this instead (again, from the top of my head and untested): def validate_dns_label(dns_label, allow_underscore=False, allow_slash=False): base_chars = 'a-z0-9' extra_chars = '' middle_chars = '' if allow_underscore: extra_chars += "_" if allow_slash: middle_chars += '/' middle_chars += '-' label_regex = r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' % dict(base=base_chars, extra=extra_chars, middle=middle_chars) regex = re.compile(label_regex, re.IGNORECASE) if not dns_label: raise ValueError(_('empty DNS label')) if len(dns_label) > 63: raise ValueError(_('DNS label cannot be longer that 63 characters')) if not regex.match(dns_label): chars = ', '.join('"%s"' % c for c in base_chars + extra_chars + middle_chars) chars2 = ', '.join('"%s"' % c for c in middle_chars) raise ValueError(_('only letters, numbers, %(chars)s are allowed. ' \ 'DNS label may not start or end with %(chars2)s') \ % dict(chars=chars, chars2=chars2)) -- Jan Cholasta From mbasti at redhat.com Mon Feb 10 12:14:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Feb 2014 13:14:19 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52F8B685.3020603@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> Message-ID: <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: > On 10.2.2014 08:50, Petr Spacek wrote: > > On 7.2.2014 10:42, Martin Basti wrote: > >> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: > >>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: > >>>> On 6.2.2014 15:57, Martin Basti wrote: > >>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > >>>>>> Hi, > >>>>>> > >>>>>> On 31.1.2014 16:06, Martin Basti wrote: > >>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > >>>>>>> allowed. > >>>>>>> > >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 > >>>>>>> Patches attached. > >>>>>> > >>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > >>>>> > >>>>>> I think the validation should be more strict. IPv4 reverse zones > >>>>>> should > >>>>>> allow slash only in the label for the last octet (i.e. > >>>>>> 0/25.1.168.192 is > >>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow > >>>>>> slash > >>>>>> at all. > >>>>>> > >>>>> I havent found anything about IPv6, RFCs don't forbids it. > >>>> > >>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so > >>>> we might as well do it right, otherwise there is no point in doing it. > >>>> > >>> OK, I leave there only IPv4 > > For the record, we discussed this off-line with Martin and Petr and > figured out it would be best to allow slashes in IPv6 reverse zones > after all. > > >>> > >>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to > >>>>> CNAME > >>>>> records > >>>> > >>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned > >>>> about. > >>>> > >>> > >>> http://tools.ietf.org/html/rfc6672#section-6.2 > >>> This can give a very strange positions of / in FQDN > > Point taken. > > >>> > >>> Optionally, I could permit only 1 slash in domain name, but I have to > >>> inspect first if user can do something useful with subnet of subnet in > >>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa > > Multiple slashes has to be allowed, without limitation to last octet. > > Imagine situation when split subnet is later split to even smaller pieces. > > > > Guys, do not over-engineer it. IMHO this validator should produce a > > warning is something is not as we expect but it should not block user > > from adding a record. > > > > We have had enough problems with too strict validators in the past and > > IMHO warning is the way to go. > > I agree, but it's too late to get such change into 3.3.x. > > > > > Petr^2 Spacek > > > >>>>> The slashes in domain names are referenced as the best practise in > >>>>> RFC, > >>>>> there are not strict rules. > >>>>>> > >>>>>> +def _cname_hostname_validator(ugettext, value): > >>>>>> > >>>>>> Can you name this _bind_cname_hostname_validator, so that it is > >>>>>> clear it > >>>>>> is related to _bind_hostname_validator? > >>>>>> > >>>>> I will rename it > >>>>> > >>>>>> > >>>>>> + #classless reverse zones can contain slash '/' > >>>>>> + if not zone_is_reverse(normalized_zone) and > >>>>>> (normalized_zone.count('/') > 0): > >>>>>> + raise errors.ValidationError(name='name', > >>>>>> + error=_("Only reverse zones can contain > >>>>>> '/' in > >>>>>> labels")) > >>>>>> > >>>>>> This should be handled in _domain_name_validator. Validation in > >>>>>> pre_callback should be done only when the validation depends on > >>>>>> values > >>>>>> of multiple parameters, which is not this case. > >>>>>> > >>>>> I will move it > >>>>>> > >>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, > >>>>>> *keys, > >>>>>> **options): > >>>>>> > >>>>>> Rename this to _idnsname_pre_callback and you won't have to call it > >>>>>> explicitly in run_precallback_validators. > >>>>>> > >>>>> I will rename it > >>>>>> > >>>>>> + if addr.count('/') > 0: > >>>>>> > >>>>>> I think "if '/' in addr:" would be better. > >>>>>> > >>>>> I will change it > >>>>> > >>>>>> > >>>>>> -def validate_dns_label(dns_label, allow_underscore=False): > >>>>>> +def validate_dns_label(dns_label, allow_underscore=False, > >>>>>> allow_slash=False): > >>>>>> > >>>>>> IMO instead of adding a new boolean argument, it would be nicer to > >>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which > >>>>>> takes a string of extra allowed characters. > >>>>>> > >>>>> But I have to handle not only allowed chars, but position of the chars > >>>>> in the label string too. > >>>> > >>>> Why? Is there a RFC that forbids it? > >>>> > >>>> My point is, adding a new argument for each extra character is bad, > >>>> there should be a better way of doing that. > >>>> > >>> I agree, but for example: "_" should be at start (it is not required be > >>> at the start in IPA), "/" and "-" in the middle. > > OK then. (But I still don't like it.) > > >>> > >> > >> Updated patch attached. > >> Patch for tests is the same as previos. > > + validate_domain_name(value, allow_slash=True) > + > + #classless reverse zones can contain slash '/' > + normalized_zone = normalize_zone(value) > + if not zone_is_reverse(normalized_zone) and ('/' in > normalized_zone): > + return u"Only reverse zones can contain '/' in labels" > > You don't need to enclose "x in y" in parentheses. Also I don't think > there is any value in pointing out that slash can be used for reverse > zones when giving an error for non-reverse zones. I would prefer > something like this instead: > > normalized_zone = normalize_zone(value) > validate_domain_mame(value, > allow_slash=zone_is_reverse(normalized_zone)) > > > + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, > **options): > + #in reverse zone can a record name contains /, (and -) > + > + if self.is_pkey_zone_record(*keys): > + addr = u'' > + else: > + addr = keys[-1] > + > + zone = keys[-2] > + zone = normalize_zone(zone) > + if (not zone_is_reverse(zone)) and ('/' in addr): > + raise errors.ValidationError(name='name', > + error=unicode(_('Only domain names in reverse zones > can contain \'/\'')) ) > > I think you can do better (from the top of my head and untested): > > if not self.is_pkey_zone_record(*keys): > zone, addr = normalize_zone(keys[-2]), keys[-1] > try: > validate_domain_name(addr + zone, > allow_slash=zone_is_reverse(zone)) > except ValueError, e: > raise errors.ValidationError(name='idnsname', > error=str(e)) > > > + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check > + #zone has to be checked without reverse domain suffix > (in-addr.arpa.) > + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: > + pass > + else: > + ip_addr_comp_count = addr_len + len(zone.split('.')) > + if ip_addr_comp_count != zone_len: > + raise errors.ValidationError(name='ptrrecord', > + error=unicode(_('Reverse zone %(name)s requires > exactly %(count)d IP address components, %(user_count)d given') > + % dict(name=zone_name, count=zone_len, > user_count=ip_addr_comp_count))) > > Is there anything preventing us from dropping this whole check? I don't > think it makes sense anymore. > IMO it doesnt have sense with classless reverse domains, but it is useful with classfull reverse domains, which are used more, to prevent users making mistakes. > > IMHO validate_dns_label is very ugly. I would prefer if it looked > something like this instead (again, from the top of my head and untested): > > def validate_dns_label(dns_label, allow_underscore=False, > allow_slash=False): > base_chars = 'a-z0-9' > extra_chars = '' > middle_chars = '' > > if allow_underscore: > extra_chars += "_" > if allow_slash: > middle_chars += '/' > > middle_chars += '-' > > label_regex = > r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' > % dict(base=base_chars, extra=extra_chars, middle=middle_chars) > regex = re.compile(label_regex, re.IGNORECASE) > > if not dns_label: > raise ValueError(_('empty DNS label')) > > if len(dns_label) > 63: > raise ValueError(_('DNS label cannot be longer that 63 > characters')) > > if not regex.match(dns_label): > chars = ', '.join('"%s"' % c for c in base_chars + extra_chars > + middle_chars) > chars2 = ', '.join('"%s"' % c for c in middle_chars) > raise ValueError(_('only letters, numbers, %(chars)s are > allowed. ' \ > 'DNS label may not start or end with > %(chars2)s') \ > % dict(chars=chars, chars2=chars2)) > > Thank you for the review, I will fix it. -- Martin^2 Basti From mkosek at redhat.com Mon Feb 10 12:22:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 13:22:04 +0100 Subject: [Freeipa-devel] Organizing upstream development in Trac Message-ID: <52F8C46C.6060308@redhat.com> Hello, FreeIPA core devel team had a discussion about how to organize our development milestones better. Currently, all next release development tickets are put into monthly milestones and then worked in based on priorities. However, this does does not fly well with the non-critical tickets as when the development gets behind schedule, there is a lot of moving tickets around, moving them to $month+1 milestone, causing confusing churn in the ticket history. As agreed on the meeting, we need to improve the situation, this is the proposal: 1) Monthly release milestones will only contain a limited set of scheduled core critical feature that will be a priority for the developer to work on. 2) We will create a new "next feature backlog" which will contain the less important features and bug fixes, i.e. "FreeIPA 3.4 Backlog". When developer has done all his this-month tickets, he can start with the backlog ones, according to priority. 3) Besides these 2 next-release milestone types, there will be a second train for bug fixing current release (we currently have "2014 Month 2 - February (3.3.x bug fixing)"). I am thinking this does not need be divided to months as these tickets need to be done asap anyway. So I would name it simply "FreeIPA 3.3.5". Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing that it is more difficult to see the exact version where the patch landed. This means that each month, a developer should watch following 3 milestones (in this order): * current release bug fixing milestone: FreeIPA 3.3.5 * next-release monthly milestone: FreeIPA 3.4 - 2014/2 * next-release backlog milestone: FreeIPA 3.4 Backlog If there are no strong objections, I will create new milestones, rename existing ones and sanitize current distribution of 3.4 tickets. IMO this would make the milestone clear, but I am open to other suggestions. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Mon Feb 10 12:28:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Feb 2014 13:28:22 +0100 Subject: [Freeipa-devel] Organizing upstream development in Trac In-Reply-To: <52F8C46C.6060308@redhat.com> References: <52F8C46C.6060308@redhat.com> Message-ID: <52F8C5E6.6030503@redhat.com> On 02/10/2014 01:22 PM, Martin Kosek wrote: > Hello, > > FreeIPA core devel team had a discussion about how to organize our development > milestones better. Currently, all next release development tickets are put into > monthly milestones and then worked in based on priorities. > > However, this does does not fly well with the non-critical tickets as when the > development gets behind schedule, there is a lot of moving tickets around, > moving them to $month+1 milestone, causing confusing churn in the ticket history. > > As agreed on the meeting, we need to improve the situation, this is the proposal: > > 1) Monthly release milestones will only contain a limited set of scheduled core > critical feature that will be a priority for the developer to work on. > > 2) We will create a new "next feature backlog" which will contain the less > important features and bug fixes, i.e. "FreeIPA 3.4 Backlog". When developer > has done all his this-month tickets, he can start with the backlog ones, > according to priority. > > 3) Besides these 2 next-release milestone types, there will be a second train > for bug fixing current release (we currently have "2014 Month 2 - February > (3.3.x bug fixing)"). I am thinking this does not need be divided to months as > these tickets need to be done asap anyway. So I would name it simply "FreeIPA > 3.3.5". Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing > that it is more difficult to see the exact version where the patch landed. Please name it e.g. "FreeIPA 3.3.5 (bug fixing)" or "FreeIPA 3.3.5 (maintenance)" for clarity. Numbers have a tendency to get mixed up. > This means that each month, a developer should watch following 3 milestones (in > this order): > * current release bug fixing milestone: FreeIPA 3.3.5 > * next-release monthly milestone: FreeIPA 3.4 - 2014/2 > * next-release backlog milestone: FreeIPA 3.4 Backlog > > If there are no strong objections, I will create new milestones, rename > existing ones and sanitize current distribution of 3.4 tickets. IMO this would > make the milestone clear, but I am open to other suggestions. -- Petr? From mkosek at redhat.com Mon Feb 10 12:32:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 13:32:12 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag Message-ID: <52F8C6CC.1030809@redhat.com> Hello, I would like to follow up on a core devel team discussion we had last week. We found out, that it would be beneficial to see a reviewer of the patches that land in our git. This will serve both as a nice way to both generate statistics who is devoted to both writing new code, but also to reviewing other people's code (and win prizes ;-), but it will also offer the git history archaeologist 2 names of developers which should be the most knowledgeable about the patch. We will use the current de-facto standard "Reviewed-By" tag. Example: commit da70c6d9353cd29531c8e2c135db81a97f22293c Author: Martin Kosek Date: Mon Jan 27 12:28:12 2014 +0100 Migration does not add users to default group When users with missing default group were searched, IPA suffix was not passed so these users were searched in a wrong base DN. Thus, no user was detected and added to default group. https://fedorahosted.org/freeipa/ticket/4141 Reviewed-By: Petr Viktorin Currently, I used to add the tag via "git commit --amend". Does anybody have a nice helper scripts or snippets to semi-automate it? Note that we will be able to fully automate it when we start with an CI merging system. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Mon Feb 10 12:55:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Feb 2014 13:55:02 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag In-Reply-To: <52F8C6CC.1030809@redhat.com> References: <52F8C6CC.1030809@redhat.com> Message-ID: <52F8CC26.7060708@redhat.com> On 02/10/2014 01:32 PM, Martin Kosek wrote: > Hello, > > I would like to follow up on a core devel team discussion we had last week. We > found out, that it would be beneficial to see a reviewer of the patches that > land in our git. > > This will serve both as a nice way to both generate statistics who is devoted > to both writing new code, but also to reviewing other people's code (and win > prizes ;-), but it will also offer the git history archaeologist 2 names of > developers which should be the most knowledgeable about the patch. > > We will use the current de-facto standard "Reviewed-By" tag. Example: > > commit da70c6d9353cd29531c8e2c135db81a97f22293c > Author: Martin Kosek > Date: Mon Jan 27 12:28:12 2014 +0100 > > Migration does not add users to default group > > When users with missing default group were searched, IPA suffix was > not passed so these users were searched in a wrong base DN. Thus, > no user was detected and added to default group. > > https://fedorahosted.org/freeipa/ticket/4141 > > Reviewed-By: Petr Viktorin > > > Currently, I used to add the tag via "git commit --amend". Does anybody have a > nice helper scripts or snippets to semi-automate it? Note that we will be able > to fully automate it when we start with an CI merging system. > I usually hack tasks like these with a special "editor" for git. I've attached one for Reviewed-By. Usage: REVIEWER='I Myself ' GIT_EDITOR=add-reviewed-by.py git commit --amend -e I'll use some time this week to write a better patch-pushing helper that'll incorporate this. (For the record, now we usually use https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: add-reviewed-by.py Type: text/x-python Size: 385 bytes Desc: not available URL: From mkosek at redhat.com Mon Feb 10 12:59:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 13:59:27 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag In-Reply-To: <52F8CC26.7060708@redhat.com> References: <52F8C6CC.1030809@redhat.com> <52F8CC26.7060708@redhat.com> Message-ID: <52F8CD2F.7000603@redhat.com> On 02/10/2014 01:55 PM, Petr Viktorin wrote: > On 02/10/2014 01:32 PM, Martin Kosek wrote: >> Hello, >> >> I would like to follow up on a core devel team discussion we had last week. We >> found out, that it would be beneficial to see a reviewer of the patches that >> land in our git. >> >> This will serve both as a nice way to both generate statistics who is devoted >> to both writing new code, but also to reviewing other people's code (and win >> prizes ;-), but it will also offer the git history archaeologist 2 names of >> developers which should be the most knowledgeable about the patch. >> >> We will use the current de-facto standard "Reviewed-By" tag. Example: >> >> commit da70c6d9353cd29531c8e2c135db81a97f22293c >> Author: Martin Kosek >> Date: Mon Jan 27 12:28:12 2014 +0100 >> >> Migration does not add users to default group >> >> When users with missing default group were searched, IPA suffix was >> not passed so these users were searched in a wrong base DN. Thus, >> no user was detected and added to default group. >> >> https://fedorahosted.org/freeipa/ticket/4141 >> >> Reviewed-By: Petr Viktorin >> >> >> Currently, I used to add the tag via "git commit --amend". Does anybody have a >> nice helper scripts or snippets to semi-automate it? Note that we will be able >> to fully automate it when we start with an CI merging system. >> > > I usually hack tasks like these with a special "editor" for git. I've attached > one for Reviewed-By. > > Usage: > REVIEWER='I Myself ' GIT_EDITOR=add-reviewed-by.py git commit > --amend -e > Thanks. > > I'll use some time this week to write a better patch-pushing helper that'll > incorporate this. > (For the record, now we usually use > https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) That may be the best option for the short term. I would envision something like: $ pushpatch.py freeipa-somebody-1-great.patch ... Reviewed by: 0) Me 1) Petr Vobornik 2) Martin Kosek 3) Petr Viktorin 4) ... 99) Others: Reviewed-By choice [0]: _ Martin From abokovoy at redhat.com Mon Feb 10 13:11:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Feb 2014 15:11:07 +0200 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <1391712075.1830.28.camel@localhost.localdomain> References: <1389303173.1962.11.camel@localhost.localdomain> <1391712075.1830.28.camel@localhost.localdomain> Message-ID: <20140210131107.GC8040@redhat.com> On Thu, 06 Feb 2014, Nathaniel McCallum wrote: >On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: >> This patch is independent from my patches 0028-0031 and can be merged in >> any order. >> >> This patch has a bug, but I can't figure it out. We need to set >> nsslapd-access-userattr-strict on cn=config to "off". However, during >> the rpm installation, I get this error: >> >> DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting >> attributes is not allowed', 'desc': 'Server is unwilling to perform'} >> ERROR Update failed: Server is unwilling to perform: Deleting attributes >> is not allowed >> >> I'm not sure what is causing this. Does anyone have any suggestions? > >Attached is a new revision of this patch. It uses the new SELFDN support >present in 389-ds-base 1.3.2.11 that was a result of the previous review >of this patch. > >It currently depends on the HOTP patch (0033-2). However, if we wish to >merge this first, this could be easily rebased. Could you please rebase it? It would be good to merge it first because 0033-2 depends on otp infrastructure patches. -- / Alexander Bokovoy From pvoborni at redhat.com Mon Feb 10 13:12:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 10 Feb 2014 14:12:20 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52D40FD7.5090301@redhat.com> References: <52D40FD7.5090301@redhat.com> Message-ID: <52F8D034.2040009@redhat.com> On 13.1.2014 17:09, Petr Vobornik wrote: > Hi, > > these patches implements the OTP Web UI. > > Last 5 patches is the OTP UI. > > First 6 patches is a little refactoring/bug fixes needed for them. > General password dialog is introduced to avoid another implementation. > > Self-service UI is implemented to be very simple. Atm user can choose > only token name. Admin interface allows to enter all values. > > It's based on the RCUE work -> we need to push RCUE first. Thanks > Nathaniel for review of the last font package. It will speed things up. > > Know bugs: > - there is clash in id's of checkboxes preventing editation of > subsequently displayed ones with the same name. Will be fixed in > separate patch. > - bugs caused by bugs in API (adding/removal of own tokens in > self-service, inability to enter key on token creation - > https://fedorahosted.org/freeipa/ticket/4099) > - datetime format (widget+validator) will be implemented in separate patch > - no support of not reviewed CLI patches (HOTP..) > > Cgit: > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > https://fedorahosted.org/freeipa/ticket/3369 > patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0540-2-Added-QRcode-generation-to-Web-UI.patch Type: text/x-patch Size: 33181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-3-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-2-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-2-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0536-1-Fix-handling-of-action-visibility-change-in-action-p.patch Type: text/x-patch Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0535-1-Use-general-password-dialog-for-host-OTP.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0534-1-Password-Dialog.patch Type: text/x-patch Size: 11249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0533-1-Fixed-doc-examples-in-Spec_mod.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0532-1-Declarative-replacement-of-array-item-in-specificati.patch Type: text/x-patch Size: 3642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0538-1-UI-for-radius-proxy.patch Type: text/x-patch Size: 7703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0539-1-UI-for-managing-user-auth-types.patch Type: text/x-patch Size: 2008 bytes Desc: not available URL: From jhrozek at redhat.com Mon Feb 10 13:22:00 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Feb 2014 14:22:00 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag In-Reply-To: <52F8CD2F.7000603@redhat.com> References: <52F8C6CC.1030809@redhat.com> <52F8CC26.7060708@redhat.com> <52F8CD2F.7000603@redhat.com> Message-ID: <20140210132200.GH11705@hendrix.brq.redhat.com> On Mon, Feb 10, 2014 at 01:59:27PM +0100, Martin Kosek wrote: > On 02/10/2014 01:55 PM, Petr Viktorin wrote: > > On 02/10/2014 01:32 PM, Martin Kosek wrote: > >> Hello, > >> > >> I would like to follow up on a core devel team discussion we had last week. We > >> found out, that it would be beneficial to see a reviewer of the patches that > >> land in our git. > >> > >> This will serve both as a nice way to both generate statistics who is devoted > >> to both writing new code, but also to reviewing other people's code (and win > >> prizes ;-), but it will also offer the git history archaeologist 2 names of > >> developers which should be the most knowledgeable about the patch. > >> > >> We will use the current de-facto standard "Reviewed-By" tag. Example: > >> > >> commit da70c6d9353cd29531c8e2c135db81a97f22293c > >> Author: Martin Kosek > >> Date: Mon Jan 27 12:28:12 2014 +0100 > >> > >> Migration does not add users to default group > >> > >> When users with missing default group were searched, IPA suffix was > >> not passed so these users were searched in a wrong base DN. Thus, > >> no user was detected and added to default group. > >> > >> https://fedorahosted.org/freeipa/ticket/4141 > >> > >> Reviewed-By: Petr Viktorin > >> > >> > >> Currently, I used to add the tag via "git commit --amend". Does anybody have a > >> nice helper scripts or snippets to semi-automate it? Note that we will be able > >> to fully automate it when we start with an CI merging system. > >> > > > > I usually hack tasks like these with a special "editor" for git. I've attached > > one for Reviewed-By. > > > > Usage: > > REVIEWER='I Myself ' GIT_EDITOR=add-reviewed-by.py git commit > > --amend -e > > > > Thanks. > > > > > I'll use some time this week to write a better patch-pushing helper that'll > > incorporate this. > > (For the record, now we usually use > > https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) > > That may be the best option for the short term. I would envision something like: > > $ pushpatch.py freeipa-somebody-1-great.patch > ... > Reviewed by: > 0) Me > 1) Petr Vobornik > 2) Martin Kosek > 3) Petr Viktorin > 4) ... > 99) Others: > > Reviewed-By choice [0]: _ > > Martin For SSSD I simply added a ~/.vimrc snippet based on: https://wiki.samba.org/index.php/CodeReview It currently includes: function! CommitMessages() nmap R iReviewed-by: Jakub Hrozek iab #R Reviewed-by: iab JH JakubHrozek (and similar entries for other developers) endf autocmd BufWinEnter COMMIT_EDITMSG,*.diff,*.patch,*.patches.txt call CommitMessages() Of course, this wouldn't work if you're using an inferior editor :-] From jcholast at redhat.com Mon Feb 10 13:28:02 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Feb 2014 14:28:02 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> Message-ID: <52F8D3E2.2000004@redhat.com> On 10.2.2014 13:14, Martin Basti wrote: > On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: >> On 10.2.2014 08:50, Petr Spacek wrote: >>> On 7.2.2014 10:42, Martin Basti wrote: >>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>>>>> On 6.2.2014 15:57, Martin Basti wrote: >>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>>>>> allowed. >>>>>>>>> >>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>>>>> Patches attached. >>>>>>>> >>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>>>>> >>>>>>>> I think the validation should be more strict. IPv4 reverse zones >>>>>>>> should >>>>>>>> allow slash only in the label for the last octet (i.e. >>>>>>>> 0/25.1.168.192 is >>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow >>>>>>>> slash >>>>>>>> at all. >>>>>>>> >>>>>>> I havent found anything about IPv6, RFCs don't forbids it. >>>>>> >>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>>>>> we might as well do it right, otherwise there is no point in doing it. >>>>>> >>>>> OK, I leave there only IPv4 >> >> For the record, we discussed this off-line with Martin and Petr and >> figured out it would be best to allow slashes in IPv6 reverse zones >> after all. >> >>>>> >>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to >>>>>>> CNAME >>>>>>> records >>>>>> >>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned >>>>>> about. >>>>>> >>>>> >>>>> http://tools.ietf.org/html/rfc6672#section-6.2 >>>>> This can give a very strange positions of / in FQDN >> >> Point taken. >> >>>>> >>>>> Optionally, I could permit only 1 slash in domain name, but I have to >>>>> inspect first if user can do something useful with subnet of subnet in >>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa >>> Multiple slashes has to be allowed, without limitation to last octet. >>> Imagine situation when split subnet is later split to even smaller pieces. >>> >>> Guys, do not over-engineer it. IMHO this validator should produce a >>> warning is something is not as we expect but it should not block user >>> from adding a record. >>> >>> We have had enough problems with too strict validators in the past and >>> IMHO warning is the way to go. >> >> I agree, but it's too late to get such change into 3.3.x. >> >>> >>> Petr^2 Spacek >>> >>>>>>> The slashes in domain names are referenced as the best practise in >>>>>>> RFC, >>>>>>> there are not strict rules. >>>>>>>> >>>>>>>> +def _cname_hostname_validator(ugettext, value): >>>>>>>> >>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is >>>>>>>> clear it >>>>>>>> is related to _bind_hostname_validator? >>>>>>>> >>>>>>> I will rename it >>>>>>> >>>>>>>> >>>>>>>> + #classless reverse zones can contain slash '/' >>>>>>>> + if not zone_is_reverse(normalized_zone) and >>>>>>>> (normalized_zone.count('/') > 0): >>>>>>>> + raise errors.ValidationError(name='name', >>>>>>>> + error=_("Only reverse zones can contain >>>>>>>> '/' in >>>>>>>> labels")) >>>>>>>> >>>>>>>> This should be handled in _domain_name_validator. Validation in >>>>>>>> pre_callback should be done only when the validation depends on >>>>>>>> values >>>>>>>> of multiple parameters, which is not this case. >>>>>>>> >>>>>>> I will move it >>>>>>>> >>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, >>>>>>>> *keys, >>>>>>>> **options): >>>>>>>> >>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>>>>> explicitly in run_precallback_validators. >>>>>>>> >>>>>>> I will rename it >>>>>>>> >>>>>>>> + if addr.count('/') > 0: >>>>>>>> >>>>>>>> I think "if '/' in addr:" would be better. >>>>>>>> >>>>>>> I will change it >>>>>>> >>>>>>>> >>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>>>>> allow_slash=False): >>>>>>>> >>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>>>>> takes a string of extra allowed characters. >>>>>>>> >>>>>>> But I have to handle not only allowed chars, but position of the chars >>>>>>> in the label string too. >>>>>> >>>>>> Why? Is there a RFC that forbids it? >>>>>> >>>>>> My point is, adding a new argument for each extra character is bad, >>>>>> there should be a better way of doing that. >>>>>> >>>>> I agree, but for example: "_" should be at start (it is not required be >>>>> at the start in IPA), "/" and "-" in the middle. >> >> OK then. (But I still don't like it.) >> >>>>> >>>> >>>> Updated patch attached. >>>> Patch for tests is the same as previos. >> >> + validate_domain_name(value, allow_slash=True) >> + >> + #classless reverse zones can contain slash '/' >> + normalized_zone = normalize_zone(value) >> + if not zone_is_reverse(normalized_zone) and ('/' in >> normalized_zone): >> + return u"Only reverse zones can contain '/' in labels" >> >> You don't need to enclose "x in y" in parentheses. Also I don't think >> there is any value in pointing out that slash can be used for reverse >> zones when giving an error for non-reverse zones. I would prefer >> something like this instead: >> >> normalized_zone = normalize_zone(value) >> validate_domain_mame(value, >> allow_slash=zone_is_reverse(normalized_zone)) >> >> >> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, >> **options): >> + #in reverse zone can a record name contains /, (and -) >> + >> + if self.is_pkey_zone_record(*keys): >> + addr = u'' >> + else: >> + addr = keys[-1] >> + >> + zone = keys[-2] >> + zone = normalize_zone(zone) >> + if (not zone_is_reverse(zone)) and ('/' in addr): >> + raise errors.ValidationError(name='name', >> + error=unicode(_('Only domain names in reverse zones >> can contain \'/\'')) ) >> >> I think you can do better (from the top of my head and untested): >> >> if not self.is_pkey_zone_record(*keys): >> zone, addr = normalize_zone(keys[-2]), keys[-1] >> try: >> validate_domain_name(addr + zone, >> allow_slash=zone_is_reverse(zone)) >> except ValueError, e: >> raise errors.ValidationError(name='idnsname', >> error=str(e)) >> >> >> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check >> + #zone has to be checked without reverse domain suffix >> (in-addr.arpa.) >> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: >> + pass >> + else: >> + ip_addr_comp_count = addr_len + len(zone.split('.')) >> + if ip_addr_comp_count != zone_len: >> + raise errors.ValidationError(name='ptrrecord', >> + error=unicode(_('Reverse zone %(name)s requires >> exactly %(count)d IP address components, %(user_count)d given') >> + % dict(name=zone_name, count=zone_len, >> user_count=ip_addr_comp_count))) >> >> Is there anything preventing us from dropping this whole check? I don't >> think it makes sense anymore. >> > IMO it doesnt have sense with classless reverse domains, but it is > useful with classfull reverse domains, which are used more, to prevent > users making mistakes. OK, but please use a simple if instead of if/pass/else. > >> >> IMHO validate_dns_label is very ugly. I would prefer if it looked >> something like this instead (again, from the top of my head and untested): >> >> def validate_dns_label(dns_label, allow_underscore=False, >> allow_slash=False): >> base_chars = 'a-z0-9' >> extra_chars = '' >> middle_chars = '' >> >> if allow_underscore: >> extra_chars += "_" >> if allow_slash: >> middle_chars += '/' >> >> middle_chars += '-' >> >> label_regex = >> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' >> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) >> regex = re.compile(label_regex, re.IGNORECASE) >> >> if not dns_label: >> raise ValueError(_('empty DNS label')) >> >> if len(dns_label) > 63: >> raise ValueError(_('DNS label cannot be longer that 63 >> characters')) >> >> if not regex.match(dns_label): >> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars >> + middle_chars) >> chars2 = ', '.join('"%s"' % c for c in middle_chars) >> raise ValueError(_('only letters, numbers, %(chars)s are >> allowed. ' \ >> 'DNS label may not start or end with >> %(chars2)s') \ >> % dict(chars=chars, chars2=chars2)) >> >> > > Thank you for the review, I will fix it. > -- Jan Cholasta From mkosek at redhat.com Mon Feb 10 15:52:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 16:52:56 +0100 Subject: [Freeipa-devel] Organizing upstream development in Trac In-Reply-To: <52F8C5E6.6030503@redhat.com> References: <52F8C46C.6060308@redhat.com> <52F8C5E6.6030503@redhat.com> Message-ID: <52F8F5D8.9060908@redhat.com> On 02/10/2014 01:28 PM, Petr Viktorin wrote: > On 02/10/2014 01:22 PM, Martin Kosek wrote: >> Hello, >> >> FreeIPA core devel team had a discussion about how to organize our development >> milestones better. Currently, all next release development tickets are put into >> monthly milestones and then worked in based on priorities. >> >> However, this does does not fly well with the non-critical tickets as when the >> development gets behind schedule, there is a lot of moving tickets around, >> moving them to $month+1 milestone, causing confusing churn in the ticket >> history. >> >> As agreed on the meeting, we need to improve the situation, this is the >> proposal: >> >> 1) Monthly release milestones will only contain a limited set of scheduled core >> critical feature that will be a priority for the developer to work on. >> >> 2) We will create a new "next feature backlog" which will contain the less >> important features and bug fixes, i.e. "FreeIPA 3.4 Backlog". When developer >> has done all his this-month tickets, he can start with the backlog ones, >> according to priority. >> >> 3) Besides these 2 next-release milestone types, there will be a second train >> for bug fixing current release (we currently have "2014 Month 2 - February >> (3.3.x bug fixing)"). I am thinking this does not need be divided to months as >> these tickets need to be done asap anyway. So I would name it simply "FreeIPA >> 3.3.5". Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing >> that it is more difficult to see the exact version where the patch landed. > > Please name it e.g. "FreeIPA 3.3.5 (bug fixing)" or "FreeIPA 3.3.5 > (maintenance)" for clarity. Numbers have a tendency to get mixed up. Makes sense. >> This means that each month, a developer should watch following 3 milestones (in >> this order): >> * current release bug fixing milestone: FreeIPA 3.3.5 >> * next-release monthly milestone: FreeIPA 3.4 - 2014/2 >> * next-release backlog milestone: FreeIPA 3.4 Backlog >> >> If there are no strong objections, I will create new milestones, rename >> existing ones and sanitize current distribution of 3.4 tickets. IMO this would >> make the milestone clear, but I am open to other suggestions. By the way, few examples why I consider also changing names of the already closed milestones. "0.7 iteration - December FC" actually means "FreeIPA 2.0.0 - 2012/1" "2013 Month 01 - January" actually means "FreeIPA 3.2.0 - 2013/1" In these 2 examples, the FreeIPA version is unclear. I would also like to use just one format of version milestones instead of several others we used in the past: 2.1 - Sprint 1. May 3.0 Y11 06 Iteration June 3.0 Trust Effort Iteration 02 August Y11 2014 Month 1 - January (3.4) ... When fixed, ordering of milestones in Trac should be much clearer and one should be also able to quickly see where the fix landed (and not have to investigate git). Current (updated) proposed examples are: FreeIPA 3.4 - 2014/2 FreeIPA 3.4 - Backlog FreeIPA 3.3.5 (maintenance) Martin From pviktori at redhat.com Mon Feb 10 15:53:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Feb 2014 16:53:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52EB9A83.1040705@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <52EB9A83.1040705@redhat.com> Message-ID: <52F8F608.3070400@redhat.com> On 01/31/2014 01:43 PM, Martin Kosek wrote: > On 01/24/2014 04:48 PM, Petr Viktorin wrote: >> On 01/23/2014 02:42 PM, Simo Sorce wrote: >>> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >>>> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>>>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> This adds "managed" permissions, the framework that will make our >>>>>>> default permissions merge IPA updates and user changes sanely. >>>>>>> >>>>>>> There is no updater yet, nor does this add any actual managed >>>>>>> permissions, so there's no user-visible change (beyond help text and a >>>>>>> disabled option). To test the patch you might need to touch LDAP directly. >>>>>>> >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>>>> Design (no updater & plugin changes yet): >>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>> >>>>>>> 0447 - Minor fixes. >>>>>>> 0448 - Since you can't create managed permissions through the API, I >>>>>>> needed to get creative with the declarative tests. The tests will need a >>>>>>> custom function that adds a managed perm. >>>>>>> 0449 - The change itself. >>>>>> >>>>>> ping; any thoughts on this one? >>>>>> >>>>>> >>>>> >>>>> 1) 449, the comment: >>>>> >>>>> +Deleting or renaming a managed permission, as well as changing its target, >>>>> +is not supported. >>>>> +""") + _(""" >>>>> >>>>> I am not sure that the phrase "not supported" is the right one. It sounds >>>>> to me >>>>> like this is something we want to allow, just not implemented yet. IMO "is not >>>>> allowed" would be better. >>>> >>>> Makes sense. >>>> >>>>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>>>> >>>>> + flags={'no_create', 'allow_mod_for_managed'}, >>>>> >>>>> So far we try to add all flag descriptions there. >>>> >>>> OK >>>> >>>>> 3) When I updated the test to not delete the testperm, I tried to show the >>>>> managed permission and it is not entirely clear, see: >>>>> >>>>> # ipa permission-show testperm >>>>> Permission name: testperm >>>>> Permissions: write >>>>> * Attributes: cn, o, sn >>>>> * Excluded attributes: cn, sn >>>>> Bind rule type: all >>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>> Type: user >>>>> * Default attributes: l, o, cn >>>>> * Effective attributes: l, o >>>> >>>> Well, this is a tradeoff between presenting what's stored in LDAP and >>>> what's in the ACI. >>>> >>>>> The "Attributes" mean actually attributes explicitly allowed by user, but >>>>> it is >>>>> not obvious from the output. >>>>> >>>>> Maybe it would be better to return only "Effective attributes" by default and >>>>> return the 3 source lists only when --all is passed. But this would require us >>>>> to let Command override LDAPObject's default_attributes, which framework >>>>> cannot do. >>>> >>>> Modifying default_attributes would not work because the 3 lists need to >>>> be loaded from LDAP to determine the effective attributes. >>>> It's possible to remove the extra attributes in the post_callback, >>>> postprocess_result already does similar output manipulation. >>>> >>>>> Alternatively, we may choose to use the attributes differently with managed >>>>> permissions: >>>>> - we add the new attributeType "ipaPermIncludedAttr". It would be used for the >>>>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>>>> - we do not use the ipaPermAllowedAttr with managed attributes at all or >>>>> use it >>>>> for the "Effective attributes" list >>>>> >>>>> My point is that the semantics of ipaPermAllowedAttr is different for managed >>>>> and non-managed permission, so it may confuse people. >>>> >>>> Well, the semantics are always the same (effective = (default | allowed) >>>> - excluded). I agree that it can be confusing; perhaps I'm in too deep >>>> to judge how it looks from the outside. >>>> >>>>> For example, you may want >>>>> to search for all permissions that allow attribute "sn": >>>>> >>>>> # ipa permission-find --attrs sn >>>>> --------------------- >>>>> 4 permissions matched >>>>> --------------------- >>>>> Permission name: anon >>>>> Permissions: read >>>>> Attributes: sn >>>>> Bind rule type: anonymous >>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>> Type: user >>>>> ... >>>>> Permission name: testperm >>>>> Permissions: write >>>>> Attributes: cn, o, sn >>>>> Excluded attributes: cn, sn >>>>> Bind rule type: anonymous >>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>> Type: user >>>>> Default attributes: l, o, cn >>>>> Effective attributes: l, o >>>>> ... >>>>> >>>>> As you see, it matched both testperm and anon even though testperm does not >>>>> really allow sn as it excluded. >>>>> >>>>> Thoughts? >>>> >>>> Well, we could have default, included, excluded attributes stored in >>>> LDAP as now (using the name "included" instead of "allowed"), and make >>>> effective attributes (--attrs) into an updatable virtual attribute: when >>>> setting it, IPA would consult the "default" attributes and update >>>> "included"/"excluded" accordingly. (With non-managed permissions >>>> "default" is empty, so only "included" would be updated.) And searching >>>> on --attrs would construct an appropriate filter. >>>> >>>> I thought about this approach earlier but thought that it obscured >>>> what's actually stored in LDAP. Given recent discussions I'm now >>>> thinking I shouldn't have rejected it. >>> >>> >>> I would take a consistent approach indeed. >>> I do not much care for the virtual attribute part in LDAP, as long as >>> our tool show prominently the effective list. >>> And also as long as all permissions behave the same way in the general >>> mechanism in LDAP. >>> >>> Simo. >>> >> >> All right. Here are patches; I'll start updating the design page. >> >> **NOTE** >> This renames the 'ipaPermAllowedAttr' attribute to 'ipaPermIncludedAttr'. >> Upgrades from master will fail, so please install a new server. Of course no >> released versions of FreeIPA are affected. >> I assume there's no clean way to rename an attribute without changing the OID? >> Is it OK to break master this way? >> >> As before three source lists are stored in LDAP: >> - ipaPermDefaultAttr >> - ipaPermIncludedAttr (--includedattrs) >> - ipaPermExcludedAttr (--excludedattrs) >> >> Setting --attrs ("Effective Attributes") will set the included/excluded >> attributes based on the default set. >> For normal permissions, default & excluded will be empty, and in this case only >> effective attributes will be displayed on output (unless --all or --raw is given). >> >> >> >> I've added some preparatory patches for #4074 to this batch, mostly to prevent >> rebase conflicts with that work. Re-numbering for a sane order. >> >> Apply on top of my patch 0452 >> >> 0455 - minor fixes, unchanged from 0447 >> >> 0456 - converting options on the server it will allow us to consult the entry's >> existing state. Arguably it's also cleaner to use execute than >> args_options_2_params for this. >> >> 0457 - generate ACIs in the plugin. This is the next step in obsoleting the ACI >> class, which in the end should only be necessary for updating old-style ACIs. >> The one-way function should be easier to maintain and extend. >> >> 0458 - allow callables in declarative tests, unchanged from 0448 >> >> 0459 - managed permissions >> >> >> Or: git pull https://github.com/encukou/freeipa 3566-managed-perms >> commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 >> > > 1) (cosmetic) Wouldn't it better to move ipapermdefaultattr to takes_params > with ['no_create', 'no_update'] flags to: > > a) Have better ordering of output params. Now it looks like: > > # ipa permission-show testperm > Permission name: testperm > Permissions: write > Effective attributes: cn, l, o, sn > Included attributes: sn > Bind rule type: all > Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > ACI target DN: > uid=*,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > Type: user > Default attributes: l, o, cn > > > I think it would be better if all the "* attributes" parameters are together.: > > Effective attributes: bla, bla > Included attributes: bla, bla > Excluded attributes: bla, bla > Default attributes: bla, bla > > so that it is easier to read the output. > > b) If ipapermdefaultattr is in takes_params, one would be able to do > permission-search for default attributes. Even if we don't allow user to change > them, we should allow him to search them. > > 2) (also cosmetic) Given we have ipapermincludedattr described as > doc=_('User-specified attributes to which the permission applies'), > shouldn't we also describe ipapermexcludedattr as > doc=_('User-specified attributes to which the permission explicitly ' > 'does not apply'), > ? I think it would be more consistent. > > > Besides these 2 cosmetic issues, I think the new patchset works pretty nice - > good job! Thanks for the review, fixed. I've also fixed the search filter for --attrs, and added more tests for that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0455.2-Permission-plugin-fixes.patch Type: text/x-patch Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0456.2-permission-plugin-Convert-options-in-execute-not-arg.patch Type: text/x-patch Size: 3198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0457.2-permission-plugin-Generate-ACIs-in-the-plugin.patch Type: text/x-patch Size: 3125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0458.2-Make-it-possible-to-call-custom-functions-in-Declara.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0459.2-Add-support-for-managed-permissions.patch Type: text/x-patch Size: 78150 bytes Desc: not available URL: From npmccallum at redhat.com Mon Feb 10 16:03:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:03:11 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8D034.2040009@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> Message-ID: <1392048191.17145.12.camel@localhost.localdomain> On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: > > Hi, > > > > these patches implements the OTP Web UI. > > > > Last 5 patches is the OTP UI. > > > > First 6 patches is a little refactoring/bug fixes needed for them. > > General password dialog is introduced to avoid another implementation. > > > > Self-service UI is implemented to be very simple. Atm user can choose > > only token name. Admin interface allows to enter all values. > > > > It's based on the RCUE work -> we need to push RCUE first. Thanks > > Nathaniel for review of the last font package. It will speed things up. > > > > Know bugs: > > - there is clash in id's of checkboxes preventing editation of > > subsequently displayed ones with the same name. Will be fixed in > > separate patch. > > - bugs caused by bugs in API (adding/removal of own tokens in > > self-service, inability to enter key on token creation - > > https://fedorahosted.org/freeipa/ticket/4099) > > - datetime format (widget+validator) will be implemented in separate patch > > - no support of not reviewed CLI patches (HOTP..) > > > > Cgit: > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > > > https://fedorahosted.org/freeipa/ticket/3369 > > > > patch 540-1 has been updated > - QR code is centered > - QR code correction level was lowered from H to M > > All other current patches from sub-threads are attached as well (it was > getting hard to keep track of them). Another nit-pick: in the top menu bar we have the item "OTP tokens". However, other two-word menu items are capitalized. Shouldn't this be "OTP Tokens"? Nathaniel From npmccallum at redhat.com Mon Feb 10 16:09:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:09:51 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8D034.2040009@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> Message-ID: <1392048591.17145.14.camel@localhost.localdomain> On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: > > Hi, > > > > these patches implements the OTP Web UI. > > > > Last 5 patches is the OTP UI. > > > > First 6 patches is a little refactoring/bug fixes needed for them. > > General password dialog is introduced to avoid another implementation. > > > > Self-service UI is implemented to be very simple. Atm user can choose > > only token name. Admin interface allows to enter all values. > > > > It's based on the RCUE work -> we need to push RCUE first. Thanks > > Nathaniel for review of the last font package. It will speed things up. > > > > Know bugs: > > - there is clash in id's of checkboxes preventing editation of > > subsequently displayed ones with the same name. Will be fixed in > > separate patch. > > - bugs caused by bugs in API (adding/removal of own tokens in > > self-service, inability to enter key on token creation - > > https://fedorahosted.org/freeipa/ticket/4099) > > - datetime format (widget+validator) will be implemented in separate patch > > - no support of not reviewed CLI patches (HOTP..) > > > > Cgit: > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > > > https://fedorahosted.org/freeipa/ticket/3369 > > > > patch 540-1 has been updated > - QR code is centered > - QR code correction level was lowered from H to M > > All other current patches from sub-threads are attached as well (it was > getting hard to keep track of them). When specifying a token using the admin user, the token URI generated is invalid. From pvoborni at redhat.com Mon Feb 10 16:16:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 10 Feb 2014 17:16:04 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1392048591.17145.14.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048591.17145.14.camel@localhost.localdomain> Message-ID: <52F8FB44.50005@redhat.com> On 10.2.2014 17:09, Nathaniel McCallum wrote: > On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: >> On 13.1.2014 17:09, Petr Vobornik wrote: >>> Hi, >>> >>> these patches implements the OTP Web UI. >>> >>> Last 5 patches is the OTP UI. >>> >>> First 6 patches is a little refactoring/bug fixes needed for them. >>> General password dialog is introduced to avoid another implementation. >>> >>> Self-service UI is implemented to be very simple. Atm user can choose >>> only token name. Admin interface allows to enter all values. >>> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>> Nathaniel for review of the last font package. It will speed things up. >>> >>> Know bugs: >>> - there is clash in id's of checkboxes preventing editation of >>> subsequently displayed ones with the same name. Will be fixed in >>> separate patch. >>> - bugs caused by bugs in API (adding/removal of own tokens in >>> self-service, inability to enter key on token creation - >>> https://fedorahosted.org/freeipa/ticket/4099) >>> - datetime format (widget+validator) will be implemented in separate patch >>> - no support of not reviewed CLI patches (HOTP..) >>> >>> Cgit: >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>> >>> https://fedorahosted.org/freeipa/ticket/3369 >>> >> >> patch 540-1 has been updated >> - QR code is centered >> - QR code correction level was lowered from H to M >> >> All other current patches from sub-threads are attached as well (it was >> getting hard to keep track of them). > > When specifying a token using the admin user, the token URI generated is > invalid. > Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 -- Petr Vobornik From pvoborni at redhat.com Mon Feb 10 16:17:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 10 Feb 2014 17:17:00 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1392048191.17145.12.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048191.17145.12.camel@localhost.localdomain> Message-ID: <52F8FB7C.4030004@redhat.com> On 10.2.2014 17:03, Nathaniel McCallum wrote: > On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: >> On 13.1.2014 17:09, Petr Vobornik wrote: >>> Hi, >>> >>> these patches implements the OTP Web UI. >>> >>> Last 5 patches is the OTP UI. >>> >>> First 6 patches is a little refactoring/bug fixes needed for them. >>> General password dialog is introduced to avoid another implementation. >>> >>> Self-service UI is implemented to be very simple. Atm user can choose >>> only token name. Admin interface allows to enter all values. >>> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>> Nathaniel for review of the last font package. It will speed things up. >>> >>> Know bugs: >>> - there is clash in id's of checkboxes preventing editation of >>> subsequently displayed ones with the same name. Will be fixed in >>> separate patch. >>> - bugs caused by bugs in API (adding/removal of own tokens in >>> self-service, inability to enter key on token creation - >>> https://fedorahosted.org/freeipa/ticket/4099) >>> - datetime format (widget+validator) will be implemented in separate patch >>> - no support of not reviewed CLI patches (HOTP..) >>> >>> Cgit: >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>> >>> https://fedorahosted.org/freeipa/ticket/3369 >>> >> >> patch 540-1 has been updated >> - QR code is centered >> - QR code correction level was lowered from H to M >> >> All other current patches from sub-threads are attached as well (it was >> getting hard to keep track of them). > > Another nit-pick: in the top menu bar we have the item "OTP tokens". > However, other two-word menu items are capitalized. Shouldn't this be > "OTP Tokens"? ipalib issues as well: otptoken.py: object_name = _('OTP tokens') object_name_plural = _('OTP tokens') -- Petr Vobornik From npmccallum at redhat.com Mon Feb 10 16:36:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:36:28 -0500 Subject: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens In-Reply-To: <20140210131107.GC8040@redhat.com> References: <1389303173.1962.11.camel@localhost.localdomain> <1391712075.1830.28.camel@localhost.localdomain> <20140210131107.GC8040@redhat.com> Message-ID: <1392050188.17145.21.camel@localhost.localdomain> On Mon, 2014-02-10 at 15:11 +0200, Alexander Bokovoy wrote: > On Thu, 06 Feb 2014, Nathaniel McCallum wrote: > >On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > >> This patch is independent from my patches 0028-0031 and can be merged in > >> any order. > >> > >> This patch has a bug, but I can't figure it out. We need to set > >> nsslapd-access-userattr-strict on cn=config to "off". However, during > >> the rpm installation, I get this error: > >> > >> DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting > >> attributes is not allowed', 'desc': 'Server is unwilling to perform'} > >> ERROR Update failed: Server is unwilling to perform: Deleting attributes > >> is not allowed > >> > >> I'm not sure what is causing this. Does anyone have any suggestions? > > > >Attached is a new revision of this patch. It uses the new SELFDN support > >present in 389-ds-base 1.3.2.11 that was a result of the previous review > >of this patch. > > > >It currently depends on the HOTP patch (0033-2). However, if we wish to > >merge this first, this could be easily rebased. > Could you please rebase it? It would be good to merge it first because > 0033-2 depends on otp infrastructure patches. Done. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0032-2-Update-ACIs-to-permit-users-to-add-delete-their-own-.patch Type: text/x-patch Size: 4571 bytes Desc: not available URL: From npmccallum at redhat.com Mon Feb 10 16:42:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:42:03 -0500 Subject: [Freeipa-devel] [PATCH 0037] Fix OTP token names/labels Message-ID: <1392050523.17145.23.camel@localhost.localdomain> This is a typo patch and is therefore an easy review for an aspiring reviewer. :) Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0037-Fix-OTP-token-names-labels.patch Type: text/x-patch Size: 1201 bytes Desc: not available URL: From npmccallum at redhat.com Mon Feb 10 16:44:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:44:46 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8FB7C.4030004@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048191.17145.12.camel@localhost.localdomain> <52F8FB7C.4030004@redhat.com> Message-ID: <1392050686.17145.24.camel@localhost.localdomain> On Mon, 2014-02-10 at 17:17 +0100, Petr Vobornik wrote: > On 10.2.2014 17:03, Nathaniel McCallum wrote: > > On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > >> On 13.1.2014 17:09, Petr Vobornik wrote: > >>> Hi, > >>> > >>> these patches implements the OTP Web UI. > >>> > >>> Last 5 patches is the OTP UI. > >>> > >>> First 6 patches is a little refactoring/bug fixes needed for them. > >>> General password dialog is introduced to avoid another implementation. > >>> > >>> Self-service UI is implemented to be very simple. Atm user can choose > >>> only token name. Admin interface allows to enter all values. > >>> > >>> It's based on the RCUE work -> we need to push RCUE first. Thanks > >>> Nathaniel for review of the last font package. It will speed things up. > >>> > >>> Know bugs: > >>> - there is clash in id's of checkboxes preventing editation of > >>> subsequently displayed ones with the same name. Will be fixed in > >>> separate patch. > >>> - bugs caused by bugs in API (adding/removal of own tokens in > >>> self-service, inability to enter key on token creation - > >>> https://fedorahosted.org/freeipa/ticket/4099) > >>> - datetime format (widget+validator) will be implemented in separate patch > >>> - no support of not reviewed CLI patches (HOTP..) > >>> > >>> Cgit: > >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >>> > >>> https://fedorahosted.org/freeipa/ticket/3369 > >>> > >> > >> patch 540-1 has been updated > >> - QR code is centered > >> - QR code correction level was lowered from H to M > >> > >> All other current patches from sub-threads are attached as well (it was > >> getting hard to keep track of them). > > > > Another nit-pick: in the top menu bar we have the item "OTP tokens". > > However, other two-word menu items are capitalized. Shouldn't this be > > "OTP Tokens"? > > ipalib issues as well: > > otptoken.py: > object_name = _('OTP tokens') > object_name_plural = _('OTP tokens') Fixed here: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00090.html Nathaniel From npmccallum at redhat.com Mon Feb 10 16:49:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 11:49:49 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8FB44.50005@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048591.17145.14.camel@localhost.localdomain> <52F8FB44.50005@redhat.com> Message-ID: <1392050989.17145.27.camel@localhost.localdomain> On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote: > On 10.2.2014 17:09, Nathaniel McCallum wrote: > > On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > >> On 13.1.2014 17:09, Petr Vobornik wrote: > >>> Hi, > >>> > >>> these patches implements the OTP Web UI. > >>> > >>> Last 5 patches is the OTP UI. > >>> > >>> First 6 patches is a little refactoring/bug fixes needed for them. > >>> General password dialog is introduced to avoid another implementation. > >>> > >>> Self-service UI is implemented to be very simple. Atm user can choose > >>> only token name. Admin interface allows to enter all values. > >>> > >>> It's based on the RCUE work -> we need to push RCUE first. Thanks > >>> Nathaniel for review of the last font package. It will speed things up. > >>> > >>> Know bugs: > >>> - there is clash in id's of checkboxes preventing editation of > >>> subsequently displayed ones with the same name. Will be fixed in > >>> separate patch. > >>> - bugs caused by bugs in API (adding/removal of own tokens in > >>> self-service, inability to enter key on token creation - > >>> https://fedorahosted.org/freeipa/ticket/4099) > >>> - datetime format (widget+validator) will be implemented in separate patch > >>> - no support of not reviewed CLI patches (HOTP..) > >>> > >>> Cgit: > >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >>> > >>> https://fedorahosted.org/freeipa/ticket/3369 > >>> > >> > >> patch 540-1 has been updated > >> - QR code is centered > >> - QR code correction level was lowered from H to M > >> > >> All other current patches from sub-threads are attached as well (it was > >> getting hard to keep track of them). > > > > When specifying a token using the admin user, the token URI generated is > > invalid. > > > Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 I agree there is an API issue part of this. However, I think the UI would be cleaner without the "default" radio button. Putting on my admin hat, when I look at that page I immediately think "What is the default!?" I think it would be better to leave out the "default" option and just have the actual default value selected by default. Nathaniel From npmccallum at redhat.com Mon Feb 10 17:09:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 12:09:10 -0500 Subject: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs Message-ID: <1392052150.17145.28.camel@localhost.localdomain> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0038-Fix-generation-of-invalid-OTP-URIs.patch Type: text/x-patch Size: 1362 bytes Desc: not available URL: From npmccallum at redhat.com Mon Feb 10 17:10:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 12:10:42 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1392050989.17145.27.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048591.17145.14.camel@localhost.localdomain> <52F8FB44.50005@redhat.com> <1392050989.17145.27.camel@localhost.localdomain> Message-ID: <1392052242.17145.30.camel@localhost.localdomain> On Mon, 2014-02-10 at 11:49 -0500, Nathaniel McCallum wrote: > On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote: > > On 10.2.2014 17:09, Nathaniel McCallum wrote: > > > On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > > >> On 13.1.2014 17:09, Petr Vobornik wrote: > > >>> Hi, > > >>> > > >>> these patches implements the OTP Web UI. > > >>> > > >>> Last 5 patches is the OTP UI. > > >>> > > >>> First 6 patches is a little refactoring/bug fixes needed for them. > > >>> General password dialog is introduced to avoid another implementation. > > >>> > > >>> Self-service UI is implemented to be very simple. Atm user can choose > > >>> only token name. Admin interface allows to enter all values. > > >>> > > >>> It's based on the RCUE work -> we need to push RCUE first. Thanks > > >>> Nathaniel for review of the last font package. It will speed things up. > > >>> > > >>> Know bugs: > > >>> - there is clash in id's of checkboxes preventing editation of > > >>> subsequently displayed ones with the same name. Will be fixed in > > >>> separate patch. > > >>> - bugs caused by bugs in API (adding/removal of own tokens in > > >>> self-service, inability to enter key on token creation - > > >>> https://fedorahosted.org/freeipa/ticket/4099) > > >>> - datetime format (widget+validator) will be implemented in separate patch > > >>> - no support of not reviewed CLI patches (HOTP..) > > >>> > > >>> Cgit: > > >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > >>> > > >>> https://fedorahosted.org/freeipa/ticket/3369 > > >>> > > >> > > >> patch 540-1 has been updated > > >> - QR code is centered > > >> - QR code correction level was lowered from H to M > > >> > > >> All other current patches from sub-threads are attached as well (it was > > >> getting hard to keep track of them). > > > > > > When specifying a token using the admin user, the token URI generated is > > > invalid. > > > > > Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 > > I agree there is an API issue part of this. However, I think the UI > would be cleaner without the "default" radio button. Putting on my admin > hat, when I look at that page I immediately think "What is the > default!?" I think it would be better to leave out the "default" option > and just have the actual default value selected by default. API-side of this problem is fixed here: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00093.html Nathaniel From pvoborni at redhat.com Mon Feb 10 17:28:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 10 Feb 2014 18:28:48 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1392050989.17145.27.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <1392048591.17145.14.camel@localhost.localdomain> <52F8FB44.50005@redhat.com> <1392050989.17145.27.camel@localhost.localdomain> Message-ID: <52F90C50.7030702@redhat.com> On 10.2.2014 17:49, Nathaniel McCallum wrote: > On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote: >> On 10.2.2014 17:09, Nathaniel McCallum wrote: >>> On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: >>>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>>> Hi, >>>>> >>>>> these patches implements the OTP Web UI. >>>>> >>>>> Last 5 patches is the OTP UI. >>>>> >>>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>>> General password dialog is introduced to avoid another implementation. >>>>> >>>>> Self-service UI is implemented to be very simple. Atm user can choose >>>>> only token name. Admin interface allows to enter all values. >>>>> >>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>>> Nathaniel for review of the last font package. It will speed things up. >>>>> >>>>> Know bugs: >>>>> - there is clash in id's of checkboxes preventing editation of >>>>> subsequently displayed ones with the same name. Will be fixed in >>>>> separate patch. >>>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>>> self-service, inability to enter key on token creation - >>>>> https://fedorahosted.org/freeipa/ticket/4099) >>>>> - datetime format (widget+validator) will be implemented in separate patch >>>>> - no support of not reviewed CLI patches (HOTP..) >>>>> >>>>> Cgit: >>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3369 >>>>> >>>> >>>> patch 540-1 has been updated >>>> - QR code is centered >>>> - QR code correction level was lowered from H to M >>>> >>>> All other current patches from sub-threads are attached as well (it was >>>> getting hard to keep track of them). >>> >>> When specifying a token using the admin user, the token URI generated is >>> invalid. >>> >> Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 > > I agree there is an API issue part of this. However, I think the UI > would be cleaner without the "default" radio button. Putting on my admin > hat, when I look at that page I immediately think "What is the > default!?" I think it would be better to leave out the "default" option > and just have the actual default value selected by default. > > Nathaniel > I agree with the "What's the default?" part. However The Web UI should be consistent with CLI. In this case the default is not clearly defined and both options are defined as optional, i.e. I would change the UI to your proposal if the ipalib definition was: IntEnum('ipatokenotpdigits', cli_name='digits', label=_('Display length'), values=(6, 8), default=6, flags=('no_update'), ), Btw, why are these two options optional? In one otptoken.py comment you proposed to introduce global configuration in near future. With it, every global configuration change might break existing tokens. So in any case the value should be written to LDAP (which is not happening atm). -- Petr Vobornik From dpal at redhat.com Mon Feb 10 20:21:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:21:41 -0500 Subject: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones In-Reply-To: <52F8A3FF.10200@redhat.com> References: <52F8A3FF.10200@redhat.com> Message-ID: <52F934D5.6060200@redhat.com> On 02/10/2014 05:03 AM, Martin Kosek wrote: > Hello, > > I would to follow up on a core devel team discussion we had last week. Part of > it were changes to milestones as we currently use it. > > 1) "Pilsner/Beer Exchange/Deferred > Currently, we have 3 levels of deferring feature request and bug fix tickets to > later releases: > > a) Pilsner barrel: when planning next release, most of the tickets will come > from this release, based on priority or topic of the next release > > b) Beer Exchange: tickets we do not plan to complete any time soon as we do not > consider it critical enough to devote our limited development resources to it. > However, it does not mean we do not welcome our community to contact us and > provide patches! More details in [1]. It may still happen though, that we will > pick a ticket from this milestone to next release, but it is much less likely > than with Pilsner > > c) Deferred: we surely do not plan to complete those and we do not recommend > community to look at those either (unless strongly justified). > > More information about Roadmap in [2]. > > As discussed, this naming is not very transparent and obvious for people > outside of core development team. Thus, to narrow the expectations, we would > like to rename it to become more obvious. Here are my proposals: > > a) "Pilsner" -> "Future releases" (with appropriate milestone description to > set the expectations right) "Next release backlog" > > b) "Beer Exchange" -> "Backlog" (with better description) "General ticket pool" > > c) "Deferred" - can stay as is. > > If there are any objections or better suggestions, please let me know. > > [1] http://www.freeipa.org/page/Contribute/Code > [2] http://www.freeipa.org/page/Roadmap > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Feb 10 20:24:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:24:53 -0500 Subject: [Freeipa-devel] Organizing upstream development in Trac In-Reply-To: <52F8C5E6.6030503@redhat.com> References: <52F8C46C.6060308@redhat.com> <52F8C5E6.6030503@redhat.com> Message-ID: <52F93595.8060600@redhat.com> On 02/10/2014 07:28 AM, Petr Viktorin wrote: > On 02/10/2014 01:22 PM, Martin Kosek wrote: >> Hello, >> >> FreeIPA core devel team had a discussion about how to organize our >> development >> milestones better. Currently, all next release development tickets >> are put into >> monthly milestones and then worked in based on priorities. >> >> However, this does does not fly well with the non-critical tickets as >> when the >> development gets behind schedule, there is a lot of moving tickets >> around, >> moving them to $month+1 milestone, causing confusing churn in the >> ticket history. >> >> As agreed on the meeting, we need to improve the situation, this is >> the proposal: >> >> 1) Monthly release milestones will only contain a limited set of >> scheduled core >> critical feature that will be a priority for the developer to work on. >> >> 2) We will create a new "next feature backlog" which will contain the >> less >> important features and bug fixes, i.e. "FreeIPA 3.4 Backlog". When >> developer >> has done all his this-month tickets, he can start with the backlog ones, >> according to priority. >> >> 3) Besides these 2 next-release milestone types, there will be a >> second train >> for bug fixing current release (we currently have "2014 Month 2 - >> February >> (3.3.x bug fixing)"). I am thinking this does not need be divided to >> months as >> these tickets need to be done asap anyway. So I would name it simply >> "FreeIPA >> 3.3.5". Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is >> confusing >> that it is more difficult to see the exact version where the patch >> landed. > > Please name it e.g. "FreeIPA 3.3.5 (bug fixing)" or "FreeIPA 3.3.5 > (maintenance)" for clarity. Numbers have a tendency to get mixed up. +1 > >> This means that each month, a developer should watch following 3 >> milestones (in >> this order): >> * current release bug fixing milestone: FreeIPA 3.3.5 >> * next-release monthly milestone: FreeIPA 3.4 - 2014/2 >> * next-release backlog milestone: FreeIPA 3.4 Backlog >> >> If there are no strong objections, I will create new milestones, rename >> existing ones and sanitize current distribution of 3.4 tickets. IMO >> this would >> make the milestone clear, but I am open to other suggestions. > +1 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Feb 10 20:31:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 15:31:14 -0500 (EST) Subject: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones In-Reply-To: <52F934D5.6060200@redhat.com> References: <52F8A3FF.10200@redhat.com> <52F934D5.6060200@redhat.com> Message-ID: <35475490.2150440.1392064274344.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Dmitri Pal" > To: freeipa-devel at redhat.com > Sent: Monday, February 10, 2014 9:21:41 PM > Subject: Re: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones ... > > a) "Pilsner" -> "Future releases" (with appropriate milestone description > > to > > set the expectations right) > "Next release backlog" > > > > b) "Beer Exchange" -> "Backlog" (with better description) > "General ticket pool" Yeah, that would work too. I vouched for backlog as it is shorter to spell (e.g. during triage meeting), has the same meaning (at least for me) and is already used in other projects like bind-dyndb-ldap. But if people want "General ticket pool", I can live with that. Martin From dpal at redhat.com Mon Feb 10 20:55:56 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:55:56 -0500 Subject: [Freeipa-devel] Samba FS ticket Message-ID: <52F93CDC.9070107@redhat.com> Hi, We have a ticket [1] about Samba FS documentation. Alexander added a comment recently but I know Sumit is working on this effort now. Should we pull ticket in and/or merge it with some other ticket wit have? [1] https://fedorahosted.org/freeipa/ticket/3999 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Mon Feb 10 21:06:37 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Feb 2014 16:06:37 -0500 Subject: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default Message-ID: <1392066397.17145.37.camel@localhost.localdomain> https://fedorahosted.org/freeipa/ticket/4173 I do have one question. Do we ever try to "upgrade" the SSSD config? If so, should we try to "upgrade" the SSSD config to enable FAST by default? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0039-Enable-FAST-support-in-SSSD-by-default.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: From ayoung at redhat.com Mon Feb 10 21:18:09 2014 From: ayoung at redhat.com (Adam Young) Date: Mon, 10 Feb 2014 16:18:09 -0500 Subject: [Freeipa-devel] Web services in freeIPA In-Reply-To: <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> References: <52F39D47.4050902@redhat.com> <09DC09DA-7298-477D-8D0D-7FD91899A511@uc.pt> <52F3A675.3030602@redhat.com> <23C77966-58D0-4173-B14B-3130A66B2D3E@uc.pt> Message-ID: <52F94211.5050109@redhat.com> On 02/07/2014 04:33 AM, Alexandre Santos wrote: > Hi Martin, > > I?ve tried your example and i get this error: > > curl -v \ > -H "Content-Type:application/json" \ > -H "Accept:applicaton/json"\ > --negotiate -u : \ > --delegation always \ > --cacert /etc/ipa/ca.crt \ > -d '{"method":"user_find","params":[[""],{}],"id":0}' \ > -X POST https://ipa/ipa/json > > ... > > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: pi > > Content-Type:application/json > > Accept:applicaton/json > > Content-Length: 48 > > > < HTTP/1.1 200 Success > < Date: Thu, 06 Feb 2014 16:42:26 GMT > < Server: Apache/2.2.15 (CentOS) > < Connection: close > < Transfer-Encoding: chunked > < Content-Type: application/json; charset=utf-8 > < > { > "error": { > "code": 911, > "message": "Missing or invalid HTTP Referer, missing", > "name": { > "__base64__": "UmVmZXJlckVycm9y" > } > }, > "id": null, > "principal": "admin at ipa", > "result": null, > "version": "3.0.0" > * Closing connection #0 > > > Any suggestion? That is the CSRF check. Explicitly set the referrer header to the same URL as the web server and you should be OK > > Alexandre Santos > > On 06 Feb 2014, at 15:12, Martin Kosek > wrote: > >> As Petr said, we do not have a proper documentation for using RPC for >> controlling IPA. But I think you can start with looking at [1] to see the >> template and try running our commands with "-vv" which will show you >> how we >> call the API: >> >> $ ipa -vv user-show admin >> >> Martin >> >> [1] >> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >> >> On 02/06/2014 04:04 PM, Alexandre Santos wrote: >>> >>> Is there any examples that can guide me. >>> >>> Thanks >>> Alexandre Santos >>> >>> On 06 Feb 2014, at 14:33, Petr Vobornik >> > wrote: >>> >>>> On 6.2.2014 15:22, Alexandre Santos wrote: >>>>> Hi, >>>>> >>>>> I?m starting in freeIPA and I would like to know what web apps are >>>>> available for use, like create user, delete user and so on. I?ve >>>>> seen that when i use the command "ipa -vv user-add" a url for the >>>>> app if given. >>>>> >>>>> I would like to know if there is any information about that. >>>>> >>>>> Thanks >>>>> >>>>> Alexandre Santos >>>>> >>>> >>>> The url you saw is most-likely for XML RPC API. >>>> >>>> You can check: >>>> >>>> https://hostname/ipa/xml - XML RPC API >>>> https://hostname/ipa/json - JSON RPC API >>>> https://hostname/ipa/session/xml XML RPC API with session support >>>> https://hostname/ipa/session/json JSON RPC API with session support >>>> https://hostname/ipa/ui - Web UI >>>> https://hostname/ipa/config/unauthorized.html - some config and >>>> error pages >>>> >>>> We don't have docs for the APIs yet. >>>> -- >>>> Petr Vobornik >>> >> > > > > _______________________________________________ > 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 jhrozek at redhat.com Mon Feb 10 21:53:49 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Feb 2014 22:53:49 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default In-Reply-To: <1392066397.17145.37.camel@localhost.localdomain> References: <1392066397.17145.37.camel@localhost.localdomain> Message-ID: <20140210215349.GA6125@hendrix.redhat.com> On Mon, Feb 10, 2014 at 04:06:37PM -0500, Nathaniel McCallum wrote: > https://fedorahosted.org/freeipa/ticket/4173 > > I do have one question. Do we ever try to "upgrade" the SSSD config? If > so, should we try to "upgrade" the SSSD config to enable FAST by > default? > > Nathaniel What if we changed the SSSD defaults instead? Would enabling FAST by default break backwards compatibility in any way if we set it to "try" ? I would prefer to keep the config as clean as possible and only rely on sane defaults. From redhatrises at gmail.com Tue Feb 11 04:49:45 2014 From: redhatrises at gmail.com (Darth Vader) Date: Mon, 10 Feb 2014 21:49:45 -0700 Subject: [Freeipa-devel] Contribute to Freeipa Message-ID: Hi all, I would like to help contribute some to the FreeIPA project. I am an Infrastructure engineer and not a developer by trade, and I am familiar with the IPA product. I can do some basic things (which may not be that much help) such as documentation, some simple code (trivial and some minor tickets), grammar consistency in ipa help commands, etc. I was looking at some of the documentation tickets and have created a couple of patches that I can attach for review. Let me know what you guys think. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 11 07:50:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 08:50:54 +0100 Subject: [Freeipa-devel] Contribute to Freeipa In-Reply-To: References: Message-ID: <52F9D65E.8080008@redhat.com> On 02/11/2014 05:49 AM, Darth Vader wrote: > Hi all, > > I would like to help contribute some to the FreeIPA project. I am an > Infrastructure engineer and not a developer by trade, and I am familiar > with the IPA product. I can do some basic things (which may not be that > much help) such as documentation, some simple code (trivial and some minor > tickets), grammar consistency in ipa help commands, etc. > > I was looking at some of the documentation tickets and have created a > couple of patches that I can attach for review. > > Let me know what you guys think. > > Thanks, > > Gabe Hi Gabe, I think that it's a great idea. By contributing you will not only learn more about FreeIPA and this technology, but also help us move this project forward. See [1] and especially [2] and [3] for help and guide how to contribute code or documentation. To see what are the current milestones and most wanted tasks to be completed, check [4]. If you want to start with easier tickets, you can search for "easyfix" in ticket keywords, but we do not always set it for the easy ones. If you questions, feel free to ask on this list. May the Force be with you, Martin [1] http://www.freeipa.org/page/Contribute [2] http://www.freeipa.org/page/Contribute/Documentation [3] http://www.freeipa.org/page/Contribute/Code [4] http://www.freeipa.org/page/Roadmap From sbose at redhat.com Tue Feb 11 08:08:55 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Feb 2014 09:08:55 +0100 Subject: [Freeipa-devel] Samba FS ticket In-Reply-To: <52F93CDC.9070107@redhat.com> References: <52F93CDC.9070107@redhat.com> Message-ID: <20140211080855.GC2635@localhost.localdomain> On Mon, Feb 10, 2014 at 03:55:56PM -0500, Dmitri Pal wrote: > Hi, > > We have a ticket [1] about Samba FS documentation. Alexander added a > comment recently but I know Sumit is working on this effort now. > Should we pull ticket in and/or merge it with some other ticket wit have? Since there are two different use cases (SSSD AD provider and SSSD IPA provider) I would prefer to not merge this with another ticket. My plan is to work on the AD provider case first, because I see this as a requirement for the IPA case, and then to add what is needed for IPA. Currently I would say the 3.4 is a reachable target. bye, Sumit > > [1] https://fedorahosted.org/freeipa/ticket/3999 > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > From mkosek at redhat.com Tue Feb 11 08:50:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 09:50:50 +0100 Subject: [Freeipa-devel] [PATCH 0036] Move ipa-otpd socket directory In-Reply-To: <1391792996.17145.8.camel@localhost.localdomain> References: <1391792996.17145.8.camel@localhost.localdomain> Message-ID: <52F9E46A.7050809@redhat.com> On 02/07/2014 06:09 PM, Nathaniel McCallum wrote: > NOTE: Special care is required with this patch. Specifically, it needs > to be synchronized with this patch: https://github.com/krb5/krb5/pull/45 > > The background here is the desire of SELinux folks to move the sockets > into /run. MIT has agreed to use the new runstatedir in autoconf git > master (soon to be 2.70). This change has been applied upstream and will > be part of the 1.13 release. The major downside is that this patch is > backwards incompatible. > > In the interest of making backwards incompatible changes as quickly as > possible before increased adoption, Nalin and I have agreed to backport > this patch to rawhide. We are also strongly considering a backport to > F20. > > Nathaniel This worked for me in a F20 downstream scratch build, socket was on the assumed place. 1) I think you should also update the upstream reference spec file so that the updated KDC is required: @@ -118,7 +119,7 @@ Requires: nss >= 3.14.3-12.0 Requires: nss-tools >= 3.14.3-12.0 %endif %if 0%{?krb5_dal_version} >= 4 -Requires: krb5-server >= 1.11.2-1 +Requires: krb5-server >= 1.11.5-3 %else %if 0%{krb5_dal_version} == 3 # krb5 1.11 bumped DAL interface major version, a rebuild is needed 2) What do you mean by "backwards incompatible"? That updated KDC won't work with non-patched FreeIPA? Just checking - upgrades should work fine, right? I.e. when both FreeIPA and KRB5KDC is updated, OTP will keep working? No re-install needed? Martin From mkosek at redhat.com Tue Feb 11 09:09:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 10:09:56 +0100 Subject: [Freeipa-devel] Contribute to Freeipa In-Reply-To: <52F9D65E.8080008@redhat.com> References: <52F9D65E.8080008@redhat.com> Message-ID: <52F9E8E4.4030006@redhat.com> On 02/11/2014 08:50 AM, Martin Kosek wrote: > On 02/11/2014 05:49 AM, Darth Vader wrote: >> Hi all, >> >> I would like to help contribute some to the FreeIPA project. I am an >> Infrastructure engineer and not a developer by trade, and I am familiar >> with the IPA product. I can do some basic things (which may not be that >> much help) such as documentation, some simple code (trivial and some minor >> tickets), grammar consistency in ipa help commands, etc. >> >> I was looking at some of the documentation tickets and have created a >> couple of patches that I can attach for review. >> >> Let me know what you guys think. >> >> Thanks, >> >> Gabe > > Hi Gabe, > > I think that it's a great idea. By contributing you will not only learn more > about FreeIPA and this technology, but also help us move this project forward. > > See [1] and especially [2] and [3] for help and guide how to contribute code or > documentation. To see what are the current milestones and most wanted tasks to > be completed, check [4]. If you want to start with easier tickets, you can > search for "easyfix" in ticket keywords, but we do not always set it for the > easy ones. > > If you questions, feel free to ask on this list. > > May the Force be with you, > Martin Petr Spacek advised that we should have a special Trac report for the easyfix tickets. This is it: [5]. Martin > > > [1] http://www.freeipa.org/page/Contribute > [2] http://www.freeipa.org/page/Contribute/Documentation > [3] http://www.freeipa.org/page/Contribute/Code > [4] http://www.freeipa.org/page/Roadmap [5] https://fedorahosted.org/freeipa/report/43 From jcholast at redhat.com Tue Feb 11 09:13:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Feb 2014 10:13:43 +0100 Subject: [Freeipa-devel] [PATCH 0037] Fix OTP token names/labels In-Reply-To: <1392050523.17145.23.camel@localhost.localdomain> References: <1392050523.17145.23.camel@localhost.localdomain> Message-ID: <52F9E9C7.3000606@redhat.com> Hi, On 10.2.2014 17:42, Nathaniel McCallum wrote: > This is a typo patch and is therefore an easy review for an aspiring > reviewer. :) > > Nathaniel NACK, object_name and object_name_plural should use lower case "t" in "token" for consistency with other plugins. Honza -- Jan Cholasta From abokovoy at redhat.com Tue Feb 11 10:34:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Feb 2014 12:34:07 +0200 Subject: [Freeipa-devel] Third batch of ipatests fixes In-Reply-To: <52F468A5.2070309@redhat.com> References: <52F468A5.2070309@redhat.com> Message-ID: <20140211103407.GE8040@redhat.com> On Fri, 07 Feb 2014, Tomas Babej wrote: >Hello, > >this is the third and final batch. > >Please note that patch 148 has been already ACKed by Nathaniel :) (by >mistake, so please look it over again) > >Details in the commit messages. 0148 - ACK 0151 - ACK 0152 - ACK -- / Alexander Bokovoy From pvoborni at redhat.com Tue Feb 11 11:21:49 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Feb 2014 12:21:49 +0100 Subject: [Freeipa-devel] [PATCH 0037] Fix OTP token names/labels In-Reply-To: <52F9E9C7.3000606@redhat.com> References: <1392050523.17145.23.camel@localhost.localdomain> <52F9E9C7.3000606@redhat.com> Message-ID: <52FA07CD.5040800@redhat.com> On 11.2.2014 10:13, Jan Cholasta wrote: > Hi, > > On 10.2.2014 17:42, Nathaniel McCallum wrote: >> This is a typo patch and is therefore an easy review for an aspiring >> reviewer. :) >> >> Nathaniel > > NACK, object_name and object_name_plural should use lower case "t" in > "token" for consistency with other plugins. > > Honza > I have to apologize Nathaniel for wrongly pointing out the incorrect format of these object names attributes in different mail; I meant label attributes, which are correctly fixed here. I did a simple search and it seems that we are not much consistent in other plugins. Some examples: object_name = 'Automember rule' object_name = _('automount location') object_name = _('DNS zone') object_name = _('host group') object_name = ('range') ------------------^ shouldn't it be idrange? What is the main purpose of object_name/s? I can see that it's sometimes used in error messages, IMO not very correct usage - label might be better. -- Petr Vobornik From abokovoy at redhat.com Tue Feb 11 12:57:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Feb 2014 14:57:40 +0200 Subject: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default In-Reply-To: <20140210215349.GA6125@hendrix.redhat.com> References: <1392066397.17145.37.camel@localhost.localdomain> <20140210215349.GA6125@hendrix.redhat.com> Message-ID: <20140211125740.GF8040@redhat.com> On Mon, 10 Feb 2014, Jakub Hrozek wrote: >On Mon, Feb 10, 2014 at 04:06:37PM -0500, Nathaniel McCallum wrote: >> https://fedorahosted.org/freeipa/ticket/4173 >> >> I do have one question. Do we ever try to "upgrade" the SSSD config? If >> so, should we try to "upgrade" the SSSD config to enable FAST by >> default? >> >> Nathaniel > >What if we changed the SSSD defaults instead? Would enabling FAST by >default break backwards compatibility in any way if we set it to "try" ? 'try' shouldn't break anything now that I fixed SSSD side to properly process OTP token responses. >I would prefer to keep the config as clean as possible and only rely on >sane defaults. I agree but this means we would depend on specific SSSD version to provide full OTP experience. It may be good to be clear with that in documentation instead of explicitly setting the option, though. -- / Alexander Bokovoy From jhrozek at redhat.com Tue Feb 11 13:27:44 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Feb 2014 14:27:44 +0100 Subject: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default In-Reply-To: <20140211125740.GF8040@redhat.com> References: <1392066397.17145.37.camel@localhost.localdomain> <20140210215349.GA6125@hendrix.redhat.com> <20140211125740.GF8040@redhat.com> Message-ID: <20140211132744.GH6125@hendrix.redhat.com> On Tue, Feb 11, 2014 at 02:57:40PM +0200, Alexander Bokovoy wrote: > On Mon, 10 Feb 2014, Jakub Hrozek wrote: > >On Mon, Feb 10, 2014 at 04:06:37PM -0500, Nathaniel McCallum wrote: > >>https://fedorahosted.org/freeipa/ticket/4173 > >> > >>I do have one question. Do we ever try to "upgrade" the SSSD config? If > >>so, should we try to "upgrade" the SSSD config to enable FAST by > >>default? > >> > >>Nathaniel > > > >What if we changed the SSSD defaults instead? Would enabling FAST by > >default break backwards compatibility in any way if we set it to "try" ? > 'try' shouldn't break anything now that I fixed SSSD side to properly > process OTP token responses. > > >I would prefer to keep the config as clean as possible and only rely on > >sane defaults. > I agree but this means we would depend on specific SSSD version to > provide full OTP experience. It may be good to be clear with that in > documentation instead of explicitly setting the option, though. Wouldn't you prefer to Require a specific version anyway to make sure the OTP fix is in? From mbasti at redhat.com Tue Feb 11 13:29:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Feb 2014 14:29:49 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52F8D3E2.2000004@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> Message-ID: <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> On Mon, 2014-02-10 at 14:28 +0100, Jan Cholasta wrote: > On 10.2.2014 13:14, Martin Basti wrote: > > On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: > >> On 10.2.2014 08:50, Petr Spacek wrote: > >>> On 7.2.2014 10:42, Martin Basti wrote: > >>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: > >>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: > >>>>>> On 6.2.2014 15:57, Martin Basti wrote: > >>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: > >>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > >>>>>>>>> allowed. > >>>>>>>>> > >>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 > >>>>>>>>> Patches attached. > >>>>>>>> > >>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > >>>>>>> > >>>>>>>> I think the validation should be more strict. IPv4 reverse zones > >>>>>>>> should > >>>>>>>> allow slash only in the label for the last octet (i.e. > >>>>>>>> 0/25.1.168.192 is > >>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow > >>>>>>>> slash > >>>>>>>> at all. > >>>>>>>> > >>>>>>> I havent found anything about IPv6, RFCs don't forbids it. > >>>>>> > >>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so > >>>>>> we might as well do it right, otherwise there is no point in doing it. > >>>>>> > >>>>> OK, I leave there only IPv4 > >> > >> For the record, we discussed this off-line with Martin and Petr and > >> figured out it would be best to allow slashes in IPv6 reverse zones > >> after all. > >> > >>>>> > >>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to > >>>>>>> CNAME > >>>>>>> records > >>>>>> > >>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned > >>>>>> about. > >>>>>> > >>>>> > >>>>> http://tools.ietf.org/html/rfc6672#section-6.2 > >>>>> This can give a very strange positions of / in FQDN > >> > >> Point taken. > >> > >>>>> > >>>>> Optionally, I could permit only 1 slash in domain name, but I have to > >>>>> inspect first if user can do something useful with subnet of subnet in > >>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa > >>> Multiple slashes has to be allowed, without limitation to last octet. > >>> Imagine situation when split subnet is later split to even smaller pieces. > >>> > >>> Guys, do not over-engineer it. IMHO this validator should produce a > >>> warning is something is not as we expect but it should not block user > >>> from adding a record. > >>> > >>> We have had enough problems with too strict validators in the past and > >>> IMHO warning is the way to go. > >> > >> I agree, but it's too late to get such change into 3.3.x. > >> > >>> > >>> Petr^2 Spacek > >>> > >>>>>>> The slashes in domain names are referenced as the best practise in > >>>>>>> RFC, > >>>>>>> there are not strict rules. > >>>>>>>> > >>>>>>>> +def _cname_hostname_validator(ugettext, value): > >>>>>>>> > >>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is > >>>>>>>> clear it > >>>>>>>> is related to _bind_hostname_validator? > >>>>>>>> > >>>>>>> I will rename it > >>>>>>> > >>>>>>>> > >>>>>>>> + #classless reverse zones can contain slash '/' > >>>>>>>> + if not zone_is_reverse(normalized_zone) and > >>>>>>>> (normalized_zone.count('/') > 0): > >>>>>>>> + raise errors.ValidationError(name='name', > >>>>>>>> + error=_("Only reverse zones can contain > >>>>>>>> '/' in > >>>>>>>> labels")) > >>>>>>>> > >>>>>>>> This should be handled in _domain_name_validator. Validation in > >>>>>>>> pre_callback should be done only when the validation depends on > >>>>>>>> values > >>>>>>>> of multiple parameters, which is not this case. > >>>>>>>> > >>>>>>> I will move it > >>>>>>>> > >>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, > >>>>>>>> *keys, > >>>>>>>> **options): > >>>>>>>> > >>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it > >>>>>>>> explicitly in run_precallback_validators. > >>>>>>>> > >>>>>>> I will rename it > >>>>>>>> > >>>>>>>> + if addr.count('/') > 0: > >>>>>>>> > >>>>>>>> I think "if '/' in addr:" would be better. > >>>>>>>> > >>>>>>> I will change it > >>>>>>> > >>>>>>>> > >>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): > >>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, > >>>>>>>> allow_slash=False): > >>>>>>>> > >>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to > >>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which > >>>>>>>> takes a string of extra allowed characters. > >>>>>>>> > >>>>>>> But I have to handle not only allowed chars, but position of the chars > >>>>>>> in the label string too. > >>>>>> > >>>>>> Why? Is there a RFC that forbids it? > >>>>>> > >>>>>> My point is, adding a new argument for each extra character is bad, > >>>>>> there should be a better way of doing that. > >>>>>> > >>>>> I agree, but for example: "_" should be at start (it is not required be > >>>>> at the start in IPA), "/" and "-" in the middle. > >> > >> OK then. (But I still don't like it.) > >> > >>>>> > >>>> > >>>> Updated patch attached. > >>>> Patch for tests is the same as previos. > >> > >> + validate_domain_name(value, allow_slash=True) > >> + > >> + #classless reverse zones can contain slash '/' > >> + normalized_zone = normalize_zone(value) > >> + if not zone_is_reverse(normalized_zone) and ('/' in > >> normalized_zone): > >> + return u"Only reverse zones can contain '/' in labels" > >> > >> You don't need to enclose "x in y" in parentheses. Also I don't think > >> there is any value in pointing out that slash can be used for reverse > >> zones when giving an error for non-reverse zones. I would prefer > >> something like this instead: > >> > >> normalized_zone = normalize_zone(value) > >> validate_domain_mame(value, > >> allow_slash=zone_is_reverse(normalized_zone)) > >> > >> > >> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, > >> **options): > >> + #in reverse zone can a record name contains /, (and -) > >> + > >> + if self.is_pkey_zone_record(*keys): > >> + addr = u'' > >> + else: > >> + addr = keys[-1] > >> + > >> + zone = keys[-2] > >> + zone = normalize_zone(zone) > >> + if (not zone_is_reverse(zone)) and ('/' in addr): > >> + raise errors.ValidationError(name='name', > >> + error=unicode(_('Only domain names in reverse zones > >> can contain \'/\'')) ) > >> > >> I think you can do better (from the top of my head and untested): > >> > >> if not self.is_pkey_zone_record(*keys): > >> zone, addr = normalize_zone(keys[-2]), keys[-1] > >> try: > >> validate_domain_name(addr + zone, > >> allow_slash=zone_is_reverse(zone)) > >> except ValueError, e: > >> raise errors.ValidationError(name='idnsname', > >> error=str(e)) > >> > >> > >> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check > >> + #zone has to be checked without reverse domain suffix > >> (in-addr.arpa.) > >> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: > >> + pass > >> + else: > >> + ip_addr_comp_count = addr_len + len(zone.split('.')) > >> + if ip_addr_comp_count != zone_len: > >> + raise errors.ValidationError(name='ptrrecord', > >> + error=unicode(_('Reverse zone %(name)s requires > >> exactly %(count)d IP address components, %(user_count)d given') > >> + % dict(name=zone_name, count=zone_len, > >> user_count=ip_addr_comp_count))) > >> > >> Is there anything preventing us from dropping this whole check? I don't > >> think it makes sense anymore. > >> > > IMO it doesnt have sense with classless reverse domains, but it is > > useful with classfull reverse domains, which are used more, to prevent > > users making mistakes. > > OK, but please use a simple if instead of if/pass/else. > > > > >> > >> IMHO validate_dns_label is very ugly. I would prefer if it looked > >> something like this instead (again, from the top of my head and untested): > >> > >> def validate_dns_label(dns_label, allow_underscore=False, > >> allow_slash=False): > >> base_chars = 'a-z0-9' > >> extra_chars = '' > >> middle_chars = '' > >> > >> if allow_underscore: > >> extra_chars += "_" > >> if allow_slash: > >> middle_chars += '/' > >> > >> middle_chars += '-' > >> > >> label_regex = > >> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' > >> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) > >> regex = re.compile(label_regex, re.IGNORECASE) > >> > >> if not dns_label: > >> raise ValueError(_('empty DNS label')) > >> > >> if len(dns_label) > 63: > >> raise ValueError(_('DNS label cannot be longer that 63 > >> characters')) > >> > >> if not regex.match(dns_label): > >> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars > >> + middle_chars) > >> chars2 = ', '.join('"%s"' % c for c in middle_chars) > >> raise ValueError(_('only letters, numbers, %(chars)s are > >> allowed. ' \ > >> 'DNS label may not start or end with > >> %(chars2)s') \ > >> % dict(chars=chars, chars2=chars2)) > >> > >> > > > > Thank you for the review, I will fix it. > > > > All fixed. Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0024-3-DNS-classless-support-for-reverse-domains.patch Type: text/x-patch Size: 9404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0025-2-DNS-tests-for-classless-reverse-domains.patch Type: text/x-patch Size: 14910 bytes Desc: not available URL: From npmccallum at redhat.com Tue Feb 11 14:10:58 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 11 Feb 2014 09:10:58 -0500 Subject: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default In-Reply-To: <20140211132744.GH6125@hendrix.redhat.com> References: <1392066397.17145.37.camel@localhost.localdomain> <20140210215349.GA6125@hendrix.redhat.com> <20140211125740.GF8040@redhat.com> <20140211132744.GH6125@hendrix.redhat.com> Message-ID: <1392127858.17145.42.camel@localhost.localdomain> On Tue, 2014-02-11 at 14:27 +0100, Jakub Hrozek wrote: > On Tue, Feb 11, 2014 at 02:57:40PM +0200, Alexander Bokovoy wrote: > > On Mon, 10 Feb 2014, Jakub Hrozek wrote: > > >On Mon, Feb 10, 2014 at 04:06:37PM -0500, Nathaniel McCallum wrote: > > >>https://fedorahosted.org/freeipa/ticket/4173 > > >> > > >>I do have one question. Do we ever try to "upgrade" the SSSD config? If > > >>so, should we try to "upgrade" the SSSD config to enable FAST by > > >>default? > > >> > > >>Nathaniel > > > > > >What if we changed the SSSD defaults instead? Would enabling FAST by > > >default break backwards compatibility in any way if we set it to "try" ? > > 'try' shouldn't break anything now that I fixed SSSD side to properly > > process OTP token responses. > > > > >I would prefer to keep the config as clean as possible and only rely on > > >sane defaults. > > I agree but this means we would depend on specific SSSD version to > > provide full OTP experience. It may be good to be clear with that in > > documentation instead of explicitly setting the option, though. > > Wouldn't you prefer to Require a specific version anyway to make sure > the OTP fix is in? Agreed. In a private conversation, Jakub is going to work up a patch. Nathaniel From jcholast at redhat.com Tue Feb 11 14:31:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Feb 2014 15:31:05 +0100 Subject: [Freeipa-devel] [PATCH 0026] PTR records can be added without specify FQDN zone name In-Reply-To: <1391182912.2394.6.camel@unused-4-145.brq.redhat.com> References: <1391182912.2394.6.camel@unused-4-145.brq.redhat.com> Message-ID: <52FA3429.1090106@redhat.com> Hi, On 31.1.2014 16:41, Martin Basti wrote: > One liner. > > Ticket: https://fedorahosted.org/freeipa/ticket/4151 > Patch attached. Works for me, ACK. Honza -- Jan Cholasta From jcholast at redhat.com Tue Feb 11 14:42:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Feb 2014 15:42:20 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> Message-ID: <52FA36CC.5060103@redhat.com> On 11.2.2014 14:29, Martin Basti wrote: > On Mon, 2014-02-10 at 14:28 +0100, Jan Cholasta wrote: >> On 10.2.2014 13:14, Martin Basti wrote: >>> On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: >>>> On 10.2.2014 08:50, Petr Spacek wrote: >>>>> On 7.2.2014 10:42, Martin Basti wrote: >>>>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >>>>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>>>>>>> On 6.2.2014 15:57, Martin Basti wrote: >>>>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>>>>>>> allowed. >>>>>>>>>>> >>>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>>>>>>> Patches attached. >>>>>>>>>> >>>>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>>>>>>> >>>>>>>>>> I think the validation should be more strict. IPv4 reverse zones >>>>>>>>>> should >>>>>>>>>> allow slash only in the label for the last octet (i.e. >>>>>>>>>> 0/25.1.168.192 is >>>>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow >>>>>>>>>> slash >>>>>>>>>> at all. >>>>>>>>>> >>>>>>>>> I havent found anything about IPv6, RFCs don't forbids it. >>>>>>>> >>>>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>>>>>>> we might as well do it right, otherwise there is no point in doing it. >>>>>>>> >>>>>>> OK, I leave there only IPv4 >>>> >>>> For the record, we discussed this off-line with Martin and Petr and >>>> figured out it would be best to allow slashes in IPv6 reverse zones >>>> after all. >>>> >>>>>>> >>>>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to >>>>>>>>> CNAME >>>>>>>>> records >>>>>>>> >>>>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned >>>>>>>> about. >>>>>>>> >>>>>>> >>>>>>> http://tools.ietf.org/html/rfc6672#section-6.2 >>>>>>> This can give a very strange positions of / in FQDN >>>> >>>> Point taken. >>>> >>>>>>> >>>>>>> Optionally, I could permit only 1 slash in domain name, but I have to >>>>>>> inspect first if user can do something useful with subnet of subnet in >>>>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa >>>>> Multiple slashes has to be allowed, without limitation to last octet. >>>>> Imagine situation when split subnet is later split to even smaller pieces. >>>>> >>>>> Guys, do not over-engineer it. IMHO this validator should produce a >>>>> warning is something is not as we expect but it should not block user >>>>> from adding a record. >>>>> >>>>> We have had enough problems with too strict validators in the past and >>>>> IMHO warning is the way to go. >>>> >>>> I agree, but it's too late to get such change into 3.3.x. >>>> >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>>>>> The slashes in domain names are referenced as the best practise in >>>>>>>>> RFC, >>>>>>>>> there are not strict rules. >>>>>>>>>> >>>>>>>>>> +def _cname_hostname_validator(ugettext, value): >>>>>>>>>> >>>>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is >>>>>>>>>> clear it >>>>>>>>>> is related to _bind_hostname_validator? >>>>>>>>>> >>>>>>>>> I will rename it >>>>>>>>> >>>>>>>>>> >>>>>>>>>> + #classless reverse zones can contain slash '/' >>>>>>>>>> + if not zone_is_reverse(normalized_zone) and >>>>>>>>>> (normalized_zone.count('/') > 0): >>>>>>>>>> + raise errors.ValidationError(name='name', >>>>>>>>>> + error=_("Only reverse zones can contain >>>>>>>>>> '/' in >>>>>>>>>> labels")) >>>>>>>>>> >>>>>>>>>> This should be handled in _domain_name_validator. Validation in >>>>>>>>>> pre_callback should be done only when the validation depends on >>>>>>>>>> values >>>>>>>>>> of multiple parameters, which is not this case. >>>>>>>>>> >>>>>>>>> I will move it >>>>>>>>>> >>>>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, >>>>>>>>>> *keys, >>>>>>>>>> **options): >>>>>>>>>> >>>>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>>>>>>> explicitly in run_precallback_validators. >>>>>>>>>> >>>>>>>>> I will rename it >>>>>>>>>> >>>>>>>>>> + if addr.count('/') > 0: >>>>>>>>>> >>>>>>>>>> I think "if '/' in addr:" would be better. >>>>>>>>>> >>>>>>>>> I will change it >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>>>>>>> allow_slash=False): >>>>>>>>>> >>>>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>>>>>>> takes a string of extra allowed characters. >>>>>>>>>> >>>>>>>>> But I have to handle not only allowed chars, but position of the chars >>>>>>>>> in the label string too. >>>>>>>> >>>>>>>> Why? Is there a RFC that forbids it? >>>>>>>> >>>>>>>> My point is, adding a new argument for each extra character is bad, >>>>>>>> there should be a better way of doing that. >>>>>>>> >>>>>>> I agree, but for example: "_" should be at start (it is not required be >>>>>>> at the start in IPA), "/" and "-" in the middle. >>>> >>>> OK then. (But I still don't like it.) >>>> >>>>>>> >>>>>> >>>>>> Updated patch attached. >>>>>> Patch for tests is the same as previos. >>>> >>>> + validate_domain_name(value, allow_slash=True) >>>> + >>>> + #classless reverse zones can contain slash '/' >>>> + normalized_zone = normalize_zone(value) >>>> + if not zone_is_reverse(normalized_zone) and ('/' in >>>> normalized_zone): >>>> + return u"Only reverse zones can contain '/' in labels" >>>> >>>> You don't need to enclose "x in y" in parentheses. Also I don't think >>>> there is any value in pointing out that slash can be used for reverse >>>> zones when giving an error for non-reverse zones. I would prefer >>>> something like this instead: >>>> >>>> normalized_zone = normalize_zone(value) >>>> validate_domain_mame(value, >>>> allow_slash=zone_is_reverse(normalized_zone)) >>>> >>>> >>>> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, >>>> **options): >>>> + #in reverse zone can a record name contains /, (and -) >>>> + >>>> + if self.is_pkey_zone_record(*keys): >>>> + addr = u'' >>>> + else: >>>> + addr = keys[-1] >>>> + >>>> + zone = keys[-2] >>>> + zone = normalize_zone(zone) >>>> + if (not zone_is_reverse(zone)) and ('/' in addr): >>>> + raise errors.ValidationError(name='name', >>>> + error=unicode(_('Only domain names in reverse zones >>>> can contain \'/\'')) ) >>>> >>>> I think you can do better (from the top of my head and untested): >>>> >>>> if not self.is_pkey_zone_record(*keys): >>>> zone, addr = normalize_zone(keys[-2]), keys[-1] >>>> try: >>>> validate_domain_name(addr + zone, >>>> allow_slash=zone_is_reverse(zone)) >>>> except ValueError, e: >>>> raise errors.ValidationError(name='idnsname', >>>> error=str(e)) >>>> >>>> >>>> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check >>>> + #zone has to be checked without reverse domain suffix >>>> (in-addr.arpa.) >>>> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: >>>> + pass >>>> + else: >>>> + ip_addr_comp_count = addr_len + len(zone.split('.')) >>>> + if ip_addr_comp_count != zone_len: >>>> + raise errors.ValidationError(name='ptrrecord', >>>> + error=unicode(_('Reverse zone %(name)s requires >>>> exactly %(count)d IP address components, %(user_count)d given') >>>> + % dict(name=zone_name, count=zone_len, >>>> user_count=ip_addr_comp_count))) >>>> >>>> Is there anything preventing us from dropping this whole check? I don't >>>> think it makes sense anymore. >>>> >>> IMO it doesnt have sense with classless reverse domains, but it is >>> useful with classfull reverse domains, which are used more, to prevent >>> users making mistakes. >> >> OK, but please use a simple if instead of if/pass/else. >> >>> >>>> >>>> IMHO validate_dns_label is very ugly. I would prefer if it looked >>>> something like this instead (again, from the top of my head and untested): >>>> >>>> def validate_dns_label(dns_label, allow_underscore=False, >>>> allow_slash=False): >>>> base_chars = 'a-z0-9' >>>> extra_chars = '' >>>> middle_chars = '' >>>> >>>> if allow_underscore: >>>> extra_chars += "_" >>>> if allow_slash: >>>> middle_chars += '/' >>>> >>>> middle_chars += '-' >>>> >>>> label_regex = >>>> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' >>>> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) >>>> regex = re.compile(label_regex, re.IGNORECASE) >>>> >>>> if not dns_label: >>>> raise ValueError(_('empty DNS label')) >>>> >>>> if len(dns_label) > 63: >>>> raise ValueError(_('DNS label cannot be longer that 63 >>>> characters')) >>>> >>>> if not regex.match(dns_label): >>>> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars >>>> + middle_chars) >>>> chars2 = ', '.join('"%s"' % c for c in middle_chars) >>>> raise ValueError(_('only letters, numbers, %(chars)s are >>>> allowed. ' \ >>>> 'DNS label may not start or end with >>>> %(chars2)s') \ >>>> % dict(chars=chars, chars2=chars2)) >>>> >>>> >>> >>> Thank you for the review, I will fix it. >>> >> >> > > All fixed. Patches attached. > Thanks! I see some new test failures caused by the error message change: ====================================================================== FAIL: test_netgroup[17]: netgroup_add_member: Add invalid host u'+invalid&host' to netgroup u'netgroup1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 284, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 298, in check self.check_exception(nice, cmd, args, options, expected) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 324, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'host': only letters, numbers, _, and - are allowed. DNS label may not start or end with -" got = u"invalid 'host': only letters, numbers, '_', '-' are allowed. DNS label may not start or end with '-'" path = () ====================================================================== FAIL: test_netgroup[32]: netgroup_mod: Add invalid host u'+invalid&host' to netgroup u'netgroup1' using setattr ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 284, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 298, in check self.check_exception(nice, cmd, args, options, expected) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 324, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'externalhost': only letters, numbers, _, and - are allowed. DNS label may not start or end with -" got = u"invalid 'externalhost': only letters, numbers, '_', '-' are allowed. DNS label may not start or end with '-'" path = () ====================================================================== FAIL: test_raduisproxy[21]: radiusproxy_mod: Set server string of testradius to testradius.test:1:2:3 (invalid) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 284, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 298, in check self.check_exception(nice, cmd, args, options, expected) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 324, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'ipatokenradiusserver': only letters, numbers, _, and - are allowed. DNS label may not start or end with -" got = u"invalid 'ipatokenradiusserver': only letters, numbers, '_', '-' are allowed. DNS label may not start or end with '-'" path = () ====================================================================== FAIL: Test adding an invalid external host to Sudo rule using ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_sudorule_plugin.py", line 500, in test_a_sudorule_mod_externalhost_invalid_addattr "DNS label may not start or end with -") AssertionError And one nitpick: please don't add the extra newlines around _domain_name_validator. Honza -- Jan Cholasta From mbasti at redhat.com Tue Feb 11 15:23:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Feb 2014 16:23:34 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52FA36CC.5060103@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> Message-ID: <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> On Tue, 2014-02-11 at 15:42 +0100, Jan Cholasta wrote: > On 11.2.2014 14:29, Martin Basti wrote: > > On Mon, 2014-02-10 at 14:28 +0100, Jan Cholasta wrote: > >> On 10.2.2014 13:14, Martin Basti wrote: > >>> On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: > >>>> On 10.2.2014 08:50, Petr Spacek wrote: > >>>>> On 7.2.2014 10:42, Martin Basti wrote: > >>>>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: > >>>>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: > >>>>>>>> On 6.2.2014 15:57, Martin Basti wrote: > >>>>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: > >>>>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now > >>>>>>>>>>> allowed. > >>>>>>>>>>> > >>>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 > >>>>>>>>>>> Patches attached. > >>>>>>>>>> > >>>>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 > >>>>>>>>> > >>>>>>>>>> I think the validation should be more strict. IPv4 reverse zones > >>>>>>>>>> should > >>>>>>>>>> allow slash only in the label for the last octet (i.e. > >>>>>>>>>> 0/25.1.168.192 is > >>>>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow > >>>>>>>>>> slash > >>>>>>>>>> at all. > >>>>>>>>>> > >>>>>>>>> I havent found anything about IPv6, RFCs don't forbids it. > >>>>>>>> > >>>>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so > >>>>>>>> we might as well do it right, otherwise there is no point in doing it. > >>>>>>>> > >>>>>>> OK, I leave there only IPv4 > >>>> > >>>> For the record, we discussed this off-line with Martin and Petr and > >>>> figured out it would be best to allow slashes in IPv6 reverse zones > >>>> after all. > >>>> > >>>>>>> > >>>>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to > >>>>>>>>> CNAME > >>>>>>>>> records > >>>>>>>> > >>>>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned > >>>>>>>> about. > >>>>>>>> > >>>>>>> > >>>>>>> http://tools.ietf.org/html/rfc6672#section-6.2 > >>>>>>> This can give a very strange positions of / in FQDN > >>>> > >>>> Point taken. > >>>> > >>>>>>> > >>>>>>> Optionally, I could permit only 1 slash in domain name, but I have to > >>>>>>> inspect first if user can do something useful with subnet of subnet in > >>>>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa > >>>>> Multiple slashes has to be allowed, without limitation to last octet. > >>>>> Imagine situation when split subnet is later split to even smaller pieces. > >>>>> > >>>>> Guys, do not over-engineer it. IMHO this validator should produce a > >>>>> warning is something is not as we expect but it should not block user > >>>>> from adding a record. > >>>>> > >>>>> We have had enough problems with too strict validators in the past and > >>>>> IMHO warning is the way to go. > >>>> > >>>> I agree, but it's too late to get such change into 3.3.x. > >>>> > >>>>> > >>>>> Petr^2 Spacek > >>>>> > >>>>>>>>> The slashes in domain names are referenced as the best practise in > >>>>>>>>> RFC, > >>>>>>>>> there are not strict rules. > >>>>>>>>>> > >>>>>>>>>> +def _cname_hostname_validator(ugettext, value): > >>>>>>>>>> > >>>>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is > >>>>>>>>>> clear it > >>>>>>>>>> is related to _bind_hostname_validator? > >>>>>>>>>> > >>>>>>>>> I will rename it > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> + #classless reverse zones can contain slash '/' > >>>>>>>>>> + if not zone_is_reverse(normalized_zone) and > >>>>>>>>>> (normalized_zone.count('/') > 0): > >>>>>>>>>> + raise errors.ValidationError(name='name', > >>>>>>>>>> + error=_("Only reverse zones can contain > >>>>>>>>>> '/' in > >>>>>>>>>> labels")) > >>>>>>>>>> > >>>>>>>>>> This should be handled in _domain_name_validator. Validation in > >>>>>>>>>> pre_callback should be done only when the validation depends on > >>>>>>>>>> values > >>>>>>>>>> of multiple parameters, which is not this case. > >>>>>>>>>> > >>>>>>>>> I will move it > >>>>>>>>>> > >>>>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, > >>>>>>>>>> *keys, > >>>>>>>>>> **options): > >>>>>>>>>> > >>>>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it > >>>>>>>>>> explicitly in run_precallback_validators. > >>>>>>>>>> > >>>>>>>>> I will rename it > >>>>>>>>>> > >>>>>>>>>> + if addr.count('/') > 0: > >>>>>>>>>> > >>>>>>>>>> I think "if '/' in addr:" would be better. > >>>>>>>>>> > >>>>>>>>> I will change it > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): > >>>>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, > >>>>>>>>>> allow_slash=False): > >>>>>>>>>> > >>>>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to > >>>>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which > >>>>>>>>>> takes a string of extra allowed characters. > >>>>>>>>>> > >>>>>>>>> But I have to handle not only allowed chars, but position of the chars > >>>>>>>>> in the label string too. > >>>>>>>> > >>>>>>>> Why? Is there a RFC that forbids it? > >>>>>>>> > >>>>>>>> My point is, adding a new argument for each extra character is bad, > >>>>>>>> there should be a better way of doing that. > >>>>>>>> > >>>>>>> I agree, but for example: "_" should be at start (it is not required be > >>>>>>> at the start in IPA), "/" and "-" in the middle. > >>>> > >>>> OK then. (But I still don't like it.) > >>>> > >>>>>>> > >>>>>> > >>>>>> Updated patch attached. > >>>>>> Patch for tests is the same as previos. > >>>> > >>>> + validate_domain_name(value, allow_slash=True) > >>>> + > >>>> + #classless reverse zones can contain slash '/' > >>>> + normalized_zone = normalize_zone(value) > >>>> + if not zone_is_reverse(normalized_zone) and ('/' in > >>>> normalized_zone): > >>>> + return u"Only reverse zones can contain '/' in labels" > >>>> > >>>> You don't need to enclose "x in y" in parentheses. Also I don't think > >>>> there is any value in pointing out that slash can be used for reverse > >>>> zones when giving an error for non-reverse zones. I would prefer > >>>> something like this instead: > >>>> > >>>> normalized_zone = normalize_zone(value) > >>>> validate_domain_mame(value, > >>>> allow_slash=zone_is_reverse(normalized_zone)) > >>>> > >>>> > >>>> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, > >>>> **options): > >>>> + #in reverse zone can a record name contains /, (and -) > >>>> + > >>>> + if self.is_pkey_zone_record(*keys): > >>>> + addr = u'' > >>>> + else: > >>>> + addr = keys[-1] > >>>> + > >>>> + zone = keys[-2] > >>>> + zone = normalize_zone(zone) > >>>> + if (not zone_is_reverse(zone)) and ('/' in addr): > >>>> + raise errors.ValidationError(name='name', > >>>> + error=unicode(_('Only domain names in reverse zones > >>>> can contain \'/\'')) ) > >>>> > >>>> I think you can do better (from the top of my head and untested): > >>>> > >>>> if not self.is_pkey_zone_record(*keys): > >>>> zone, addr = normalize_zone(keys[-2]), keys[-1] > >>>> try: > >>>> validate_domain_name(addr + zone, > >>>> allow_slash=zone_is_reverse(zone)) > >>>> except ValueError, e: > >>>> raise errors.ValidationError(name='idnsname', > >>>> error=str(e)) > >>>> > >>>> > >>>> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check > >>>> + #zone has to be checked without reverse domain suffix > >>>> (in-addr.arpa.) > >>>> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: > >>>> + pass > >>>> + else: > >>>> + ip_addr_comp_count = addr_len + len(zone.split('.')) > >>>> + if ip_addr_comp_count != zone_len: > >>>> + raise errors.ValidationError(name='ptrrecord', > >>>> + error=unicode(_('Reverse zone %(name)s requires > >>>> exactly %(count)d IP address components, %(user_count)d given') > >>>> + % dict(name=zone_name, count=zone_len, > >>>> user_count=ip_addr_comp_count))) > >>>> > >>>> Is there anything preventing us from dropping this whole check? I don't > >>>> think it makes sense anymore. > >>>> > >>> IMO it doesnt have sense with classless reverse domains, but it is > >>> useful with classfull reverse domains, which are used more, to prevent > >>> users making mistakes. > >> > >> OK, but please use a simple if instead of if/pass/else. > >> > >>> > >>>> > >>>> IMHO validate_dns_label is very ugly. I would prefer if it looked > >>>> something like this instead (again, from the top of my head and untested): > >>>> > >>>> def validate_dns_label(dns_label, allow_underscore=False, > >>>> allow_slash=False): > >>>> base_chars = 'a-z0-9' > >>>> extra_chars = '' > >>>> middle_chars = '' > >>>> > >>>> if allow_underscore: > >>>> extra_chars += "_" > >>>> if allow_slash: > >>>> middle_chars += '/' > >>>> > >>>> middle_chars += '-' > >>>> > >>>> label_regex = > >>>> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' > >>>> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) > >>>> regex = re.compile(label_regex, re.IGNORECASE) > >>>> > >>>> if not dns_label: > >>>> raise ValueError(_('empty DNS label')) > >>>> > >>>> if len(dns_label) > 63: > >>>> raise ValueError(_('DNS label cannot be longer that 63 > >>>> characters')) > >>>> > >>>> if not regex.match(dns_label): > >>>> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars > >>>> + middle_chars) > >>>> chars2 = ', '.join('"%s"' % c for c in middle_chars) > >>>> raise ValueError(_('only letters, numbers, %(chars)s are > >>>> allowed. ' \ > >>>> 'DNS label may not start or end with > >>>> %(chars2)s') \ > >>>> % dict(chars=chars, chars2=chars2)) > >>>> > >>>> > >>> > >>> Thank you for the review, I will fix it. > >>> > >> > >> > > > > All fixed. Patches attached. > > > > Thanks! > > > I see some new test failures caused by the error message change: > > ====================================================================== > FAIL: test_netgroup[17]: netgroup_add_member: Add invalid host > u'+invalid&host' to netgroup u'netgroup1' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 284, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 298, in check > self.check_exception(nice, cmd, args, options, expected) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 324, in check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, > in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'host': only letters, numbers, _, and - are > allowed. DNS label may not start or end with -" > got = u"invalid 'host': only letters, numbers, '_', '-' are allowed. > DNS label may not start or end with '-'" > path = () > > ====================================================================== > FAIL: test_netgroup[32]: netgroup_mod: Add invalid host u'+invalid&host' > to netgroup u'netgroup1' using setattr > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 284, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 298, in check > self.check_exception(nice, cmd, args, options, expected) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 324, in check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, > in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'externalhost': only letters, numbers, _, and - > are allowed. DNS label may not start or end with -" > got = u"invalid 'externalhost': only letters, numbers, '_', '-' are > allowed. DNS label may not start or end with '-'" > path = () > > ====================================================================== > FAIL: test_raduisproxy[21]: radiusproxy_mod: Set server string of > testradius to testradius.test:1:2:3 (invalid) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 284, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 298, in check > self.check_exception(nice, cmd, args, options, expected) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", > line 324, in check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, > in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'ipatokenradiusserver': only letters, numbers, > _, and - are allowed. DNS label may not start or end with -" > got = u"invalid 'ipatokenradiusserver': only letters, numbers, '_', > '-' are allowed. DNS label may not start or end with '-'" > path = () > > ====================================================================== > FAIL: Test adding an invalid external host to Sudo rule using > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_sudorule_plugin.py", > line 500, in test_a_sudorule_mod_externalhost_invalid_addattr > "DNS label may not start or end with -") > AssertionError > > > And one nitpick: please don't add the extra newlines around > _domain_name_validator. > > > Honza > Thank you for review. Patches attached. Extra blank lines removed. The others test are fixed now. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0024-4-DNS-classless-support-for-reverse-domains.patch Type: text/x-patch Size: 9291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0025-3-DNS-tests-for-classless-reverse-domains.patch Type: text/x-patch Size: 18030 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 11 15:34:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 16:34:33 +0100 Subject: [Freeipa-devel] [PATCH 0026] PTR records can be added without specify FQDN zone name In-Reply-To: <52FA3429.1090106@redhat.com> References: <1391182912.2394.6.camel@unused-4-145.brq.redhat.com> <52FA3429.1090106@redhat.com> Message-ID: <52FA4309.9080309@redhat.com> On 02/11/2014 03:31 PM, Jan Cholasta wrote: > Hi, > > On 31.1.2014 16:41, Martin Basti wrote: >> One liner. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4151 >> Patch attached. > > Works for me, ACK. > > Honza > Pushed to master. Martin From mkosek at redhat.com Tue Feb 11 15:39:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 16:39:28 +0100 Subject: [Freeipa-devel] Third batch of ipatests fixes In-Reply-To: <20140211103407.GE8040@redhat.com> References: <52F468A5.2070309@redhat.com> <20140211103407.GE8040@redhat.com> Message-ID: <52FA4430.2070704@redhat.com> On 02/11/2014 11:34 AM, Alexander Bokovoy wrote: > On Fri, 07 Feb 2014, Tomas Babej wrote: >> Hello, >> >> this is the third and final batch. >> >> Please note that patch 148 has been already ACKed by Nathaniel :) (by >> mistake, so please look it over again) >> >> Details in the commit messages. > > 0148 - ACK > 0151 - ACK > 0152 - ACK Pushed all 3 to master, ipa-3-3. Martin From abokovoy at redhat.com Tue Feb 11 15:56:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Feb 2014 17:56:49 +0200 Subject: [Freeipa-devel] wrong branch testotp Message-ID: <20140211155649.GI8040@redhat.com> Hi! I did push wrong branch to the upstream git repo. Simo is going to delete it. Sorry for inconvenience, I wanted to push to my fedorapeople tree instead. -- / Alexander Bokovoy From npmccallum at redhat.com Tue Feb 11 16:06:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 11 Feb 2014 11:06:53 -0500 Subject: [Freeipa-devel] [PATCH 0036] Move ipa-otpd socket directory In-Reply-To: <52F9E46A.7050809@redhat.com> References: <1391792996.17145.8.camel@localhost.localdomain> <52F9E46A.7050809@redhat.com> Message-ID: <1392134813.17145.46.camel@localhost.localdomain> On Tue, 2014-02-11 at 09:50 +0100, Martin Kosek wrote: > On 02/07/2014 06:09 PM, Nathaniel McCallum wrote: > > NOTE: Special care is required with this patch. Specifically, it needs > > to be synchronized with this patch: https://github.com/krb5/krb5/pull/45 > > > > The background here is the desire of SELinux folks to move the sockets > > into /run. MIT has agreed to use the new runstatedir in autoconf git > > master (soon to be 2.70). This change has been applied upstream and will > > be part of the 1.13 release. The major downside is that this patch is > > backwards incompatible. > > > > In the interest of making backwards incompatible changes as quickly as > > possible before increased adoption, Nalin and I have agreed to backport > > this patch to rawhide. We are also strongly considering a backport to > > F20. > > > > Nathaniel > > > This worked for me in a F20 downstream scratch build, socket was on the assumed > place. > > 1) I think you should also update the upstream reference spec file so that the > updated KDC is required: > > @@ -118,7 +119,7 @@ Requires: nss >= 3.14.3-12.0 > Requires: nss-tools >= 3.14.3-12.0 > %endif > %if 0%{?krb5_dal_version} >= 4 > -Requires: krb5-server >= 1.11.2-1 > +Requires: krb5-server >= 1.11.5-3 > %else > %if 0%{krb5_dal_version} == 3 > # krb5 1.11 bumped DAL interface major version, a rebuild is needed Fix attached. > 2) What do you mean by "backwards incompatible"? That updated KDC won't work > with non-patched FreeIPA? Updated KDC will continue to work for all manually configured OTP servers. However, the KDC also supports "implicit configuration" which looks in a specific directory for sockets. This directory is what is changing. If you update the KDC without FreeIPA, the KDC won't be able to find the FreeIPA socket because we depend on implicit configuration. The FreeIPA patch just makes systemd create the socket in the right place. Either a reboot or "systemctl daemon-reload; systemctl restart ipa-otpd.socket" are required to make the changes take effect. > Just checking - upgrades should work fine, right? I.e. when both FreeIPA and > KRB5KDC is updated, OTP will keep working? No re-install needed? Correct. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0036-2-Move-ipa-otpd-socket-directory.patch Type: text/x-patch Size: 3250 bytes Desc: not available URL: From jcholast at redhat.com Tue Feb 11 16:11:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Feb 2014 17:11:03 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> Message-ID: <52FA4B97.6060805@redhat.com> On 11.2.2014 16:23, Martin Basti wrote: > On Tue, 2014-02-11 at 15:42 +0100, Jan Cholasta wrote: >> On 11.2.2014 14:29, Martin Basti wrote: >>> On Mon, 2014-02-10 at 14:28 +0100, Jan Cholasta wrote: >>>> On 10.2.2014 13:14, Martin Basti wrote: >>>>> On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: >>>>>> On 10.2.2014 08:50, Petr Spacek wrote: >>>>>>> On 7.2.2014 10:42, Martin Basti wrote: >>>>>>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >>>>>>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>>>>>>>>> On 6.2.2014 15:57, Martin Basti wrote: >>>>>>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>>>>>>>>> allowed. >>>>>>>>>>>>> >>>>>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>>>>>>>>> Patches attached. >>>>>>>>>>>> >>>>>>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>>>>>>>>> >>>>>>>>>>>> I think the validation should be more strict. IPv4 reverse zones >>>>>>>>>>>> should >>>>>>>>>>>> allow slash only in the label for the last octet (i.e. >>>>>>>>>>>> 0/25.1.168.192 is >>>>>>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow >>>>>>>>>>>> slash >>>>>>>>>>>> at all. >>>>>>>>>>>> >>>>>>>>>>> I havent found anything about IPv6, RFCs don't forbids it. >>>>>>>>>> >>>>>>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>>>>>>>>> we might as well do it right, otherwise there is no point in doing it. >>>>>>>>>> >>>>>>>>> OK, I leave there only IPv4 >>>>>> >>>>>> For the record, we discussed this off-line with Martin and Petr and >>>>>> figured out it would be best to allow slashes in IPv6 reverse zones >>>>>> after all. >>>>>> >>>>>>>>> >>>>>>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to >>>>>>>>>>> CNAME >>>>>>>>>>> records >>>>>>>>>> >>>>>>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned >>>>>>>>>> about. >>>>>>>>>> >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/rfc6672#section-6.2 >>>>>>>>> This can give a very strange positions of / in FQDN >>>>>> >>>>>> Point taken. >>>>>> >>>>>>>>> >>>>>>>>> Optionally, I could permit only 1 slash in domain name, but I have to >>>>>>>>> inspect first if user can do something useful with subnet of subnet in >>>>>>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa >>>>>>> Multiple slashes has to be allowed, without limitation to last octet. >>>>>>> Imagine situation when split subnet is later split to even smaller pieces. >>>>>>> >>>>>>> Guys, do not over-engineer it. IMHO this validator should produce a >>>>>>> warning is something is not as we expect but it should not block user >>>>>>> from adding a record. >>>>>>> >>>>>>> We have had enough problems with too strict validators in the past and >>>>>>> IMHO warning is the way to go. >>>>>> >>>>>> I agree, but it's too late to get such change into 3.3.x. >>>>>> >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>>>>>> The slashes in domain names are referenced as the best practise in >>>>>>>>>>> RFC, >>>>>>>>>>> there are not strict rules. >>>>>>>>>>>> >>>>>>>>>>>> +def _cname_hostname_validator(ugettext, value): >>>>>>>>>>>> >>>>>>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is >>>>>>>>>>>> clear it >>>>>>>>>>>> is related to _bind_hostname_validator? >>>>>>>>>>>> >>>>>>>>>>> I will rename it >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> + #classless reverse zones can contain slash '/' >>>>>>>>>>>> + if not zone_is_reverse(normalized_zone) and >>>>>>>>>>>> (normalized_zone.count('/') > 0): >>>>>>>>>>>> + raise errors.ValidationError(name='name', >>>>>>>>>>>> + error=_("Only reverse zones can contain >>>>>>>>>>>> '/' in >>>>>>>>>>>> labels")) >>>>>>>>>>>> >>>>>>>>>>>> This should be handled in _domain_name_validator. Validation in >>>>>>>>>>>> pre_callback should be done only when the validation depends on >>>>>>>>>>>> values >>>>>>>>>>>> of multiple parameters, which is not this case. >>>>>>>>>>>> >>>>>>>>>>> I will move it >>>>>>>>>>>> >>>>>>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, >>>>>>>>>>>> *keys, >>>>>>>>>>>> **options): >>>>>>>>>>>> >>>>>>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>>>>>>>>> explicitly in run_precallback_validators. >>>>>>>>>>>> >>>>>>>>>>> I will rename it >>>>>>>>>>>> >>>>>>>>>>>> + if addr.count('/') > 0: >>>>>>>>>>>> >>>>>>>>>>>> I think "if '/' in addr:" would be better. >>>>>>>>>>>> >>>>>>>>>>> I will change it >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>>>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>>>>>>>>> allow_slash=False): >>>>>>>>>>>> >>>>>>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>>>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>>>>>>>>> takes a string of extra allowed characters. >>>>>>>>>>>> >>>>>>>>>>> But I have to handle not only allowed chars, but position of the chars >>>>>>>>>>> in the label string too. >>>>>>>>>> >>>>>>>>>> Why? Is there a RFC that forbids it? >>>>>>>>>> >>>>>>>>>> My point is, adding a new argument for each extra character is bad, >>>>>>>>>> there should be a better way of doing that. >>>>>>>>>> >>>>>>>>> I agree, but for example: "_" should be at start (it is not required be >>>>>>>>> at the start in IPA), "/" and "-" in the middle. >>>>>> >>>>>> OK then. (But I still don't like it.) >>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> Patch for tests is the same as previos. >>>>>> >>>>>> + validate_domain_name(value, allow_slash=True) >>>>>> + >>>>>> + #classless reverse zones can contain slash '/' >>>>>> + normalized_zone = normalize_zone(value) >>>>>> + if not zone_is_reverse(normalized_zone) and ('/' in >>>>>> normalized_zone): >>>>>> + return u"Only reverse zones can contain '/' in labels" >>>>>> >>>>>> You don't need to enclose "x in y" in parentheses. Also I don't think >>>>>> there is any value in pointing out that slash can be used for reverse >>>>>> zones when giving an error for non-reverse zones. I would prefer >>>>>> something like this instead: >>>>>> >>>>>> normalized_zone = normalize_zone(value) >>>>>> validate_domain_mame(value, >>>>>> allow_slash=zone_is_reverse(normalized_zone)) >>>>>> >>>>>> >>>>>> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, >>>>>> **options): >>>>>> + #in reverse zone can a record name contains /, (and -) >>>>>> + >>>>>> + if self.is_pkey_zone_record(*keys): >>>>>> + addr = u'' >>>>>> + else: >>>>>> + addr = keys[-1] >>>>>> + >>>>>> + zone = keys[-2] >>>>>> + zone = normalize_zone(zone) >>>>>> + if (not zone_is_reverse(zone)) and ('/' in addr): >>>>>> + raise errors.ValidationError(name='name', >>>>>> + error=unicode(_('Only domain names in reverse zones >>>>>> can contain \'/\'')) ) >>>>>> >>>>>> I think you can do better (from the top of my head and untested): >>>>>> >>>>>> if not self.is_pkey_zone_record(*keys): >>>>>> zone, addr = normalize_zone(keys[-2]), keys[-1] >>>>>> try: >>>>>> validate_domain_name(addr + zone, >>>>>> allow_slash=zone_is_reverse(zone)) >>>>>> except ValueError, e: >>>>>> raise errors.ValidationError(name='idnsname', >>>>>> error=str(e)) >>>>>> >>>>>> >>>>>> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check >>>>>> + #zone has to be checked without reverse domain suffix >>>>>> (in-addr.arpa.) >>>>>> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: >>>>>> + pass >>>>>> + else: >>>>>> + ip_addr_comp_count = addr_len + len(zone.split('.')) >>>>>> + if ip_addr_comp_count != zone_len: >>>>>> + raise errors.ValidationError(name='ptrrecord', >>>>>> + error=unicode(_('Reverse zone %(name)s requires >>>>>> exactly %(count)d IP address components, %(user_count)d given') >>>>>> + % dict(name=zone_name, count=zone_len, >>>>>> user_count=ip_addr_comp_count))) >>>>>> >>>>>> Is there anything preventing us from dropping this whole check? I don't >>>>>> think it makes sense anymore. >>>>>> >>>>> IMO it doesnt have sense with classless reverse domains, but it is >>>>> useful with classfull reverse domains, which are used more, to prevent >>>>> users making mistakes. >>>> >>>> OK, but please use a simple if instead of if/pass/else. >>>> >>>>> >>>>>> >>>>>> IMHO validate_dns_label is very ugly. I would prefer if it looked >>>>>> something like this instead (again, from the top of my head and untested): >>>>>> >>>>>> def validate_dns_label(dns_label, allow_underscore=False, >>>>>> allow_slash=False): >>>>>> base_chars = 'a-z0-9' >>>>>> extra_chars = '' >>>>>> middle_chars = '' >>>>>> >>>>>> if allow_underscore: >>>>>> extra_chars += "_" >>>>>> if allow_slash: >>>>>> middle_chars += '/' >>>>>> >>>>>> middle_chars += '-' >>>>>> >>>>>> label_regex = >>>>>> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' >>>>>> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) >>>>>> regex = re.compile(label_regex, re.IGNORECASE) >>>>>> >>>>>> if not dns_label: >>>>>> raise ValueError(_('empty DNS label')) >>>>>> >>>>>> if len(dns_label) > 63: >>>>>> raise ValueError(_('DNS label cannot be longer that 63 >>>>>> characters')) >>>>>> >>>>>> if not regex.match(dns_label): >>>>>> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars >>>>>> + middle_chars) >>>>>> chars2 = ', '.join('"%s"' % c for c in middle_chars) >>>>>> raise ValueError(_('only letters, numbers, %(chars)s are >>>>>> allowed. ' \ >>>>>> 'DNS label may not start or end with >>>>>> %(chars2)s') \ >>>>>> % dict(chars=chars, chars2=chars2)) >>>>>> >>>>>> >>>>> >>>>> Thank you for the review, I will fix it. >>>>> >>>> >>>> >>> >>> All fixed. Patches attached. >>> >> >> Thanks! >> >> >> I see some new test failures caused by the error message change: >> >> ====================================================================== >> FAIL: test_netgroup[17]: netgroup_add_member: Add invalid host >> u'+invalid&host' to netgroup u'netgroup1' >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 284, in >> func = lambda: self.check(nice, **test) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 298, in check >> self.check_exception(nice, cmd, args, options, expected) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 324, in check_exception >> assert_deepequal(expected.strerror, e.strerror) >> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >> in assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> >> expected = u"invalid 'host': only letters, numbers, _, and - are >> allowed. DNS label may not start or end with -" >> got = u"invalid 'host': only letters, numbers, '_', '-' are allowed. >> DNS label may not start or end with '-'" >> path = () >> >> ====================================================================== >> FAIL: test_netgroup[32]: netgroup_mod: Add invalid host u'+invalid&host' >> to netgroup u'netgroup1' using setattr >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 284, in >> func = lambda: self.check(nice, **test) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 298, in check >> self.check_exception(nice, cmd, args, options, expected) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 324, in check_exception >> assert_deepequal(expected.strerror, e.strerror) >> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >> in assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> >> expected = u"invalid 'externalhost': only letters, numbers, _, and - >> are allowed. DNS label may not start or end with -" >> got = u"invalid 'externalhost': only letters, numbers, '_', '-' are >> allowed. DNS label may not start or end with '-'" >> path = () >> >> ====================================================================== >> FAIL: test_raduisproxy[21]: radiusproxy_mod: Set server string of >> testradius to testradius.test:1:2:3 (invalid) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 284, in >> func = lambda: self.check(nice, **test) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 298, in check >> self.check_exception(nice, cmd, args, options, expected) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >> line 324, in check_exception >> assert_deepequal(expected.strerror, e.strerror) >> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >> in assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> >> expected = u"invalid 'ipatokenradiusserver': only letters, numbers, >> _, and - are allowed. DNS label may not start or end with -" >> got = u"invalid 'ipatokenradiusserver': only letters, numbers, '_', >> '-' are allowed. DNS label may not start or end with '-'" >> path = () >> >> ====================================================================== >> FAIL: Test adding an invalid external host to Sudo rule using >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_sudorule_plugin.py", >> line 500, in test_a_sudorule_mod_externalhost_invalid_addattr >> "DNS label may not start or end with -") >> AssertionError >> >> >> And one nitpick: please don't add the extra newlines around >> _domain_name_validator. >> >> >> Honza >> > > Thank you for review. > > Patches attached. > Extra blank lines removed. > The others test are fixed now. > ACK. -- Jan Cholasta From pviktori at redhat.com Tue Feb 11 16:18:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Feb 2014 17:18:05 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files Message-ID: <52FA4D3D.2000903@redhat.com> Hello, I have a cold and a headache today, so I could't concentrate on anything complicated today :( Instead I did some small changes to our project files. 0460: .mailmap This fixes and deduplicates the output of `git shortlog -se`. It also puts proper diacritics in people's names if they don't use those in commits. The changes only appear in the shortlog. It might be a bit controversial, I'm not insisting it needs to go in, but I'll be using it so I'm sharing. 0461: Contributors.txt Jenny changed her last name. 0462: README & BUILD.txt Update README with current info from http://www.freeipa.org/page/Leaflet, fix broken links, refresh build instructions. 0463: Remove TODO This file was just ancient cruft. We have trac for this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0460-Add-a-.mailmap-file.patch Type: text/x-patch Size: 3598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0461-Correct-Jenny-Severance-s-last-name.patch Type: text/x-patch Size: 694 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0462-Update-README-and-BUILD.patch Type: text/x-patch Size: 8029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0463-Remove-the-TODO-file.patch Type: text/x-patch Size: 3863 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 11 16:49:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 17:49:30 +0100 Subject: [Freeipa-devel] [PATCH 0036] Move ipa-otpd socket directory In-Reply-To: <1392134813.17145.46.camel@localhost.localdomain> References: <1391792996.17145.8.camel@localhost.localdomain> <52F9E46A.7050809@redhat.com> <1392134813.17145.46.camel@localhost.localdomain> Message-ID: <52FA549A.7080804@redhat.com> On 02/11/2014 05:06 PM, Nathaniel McCallum wrote: > On Tue, 2014-02-11 at 09:50 +0100, Martin Kosek wrote: >> On 02/07/2014 06:09 PM, Nathaniel McCallum wrote: >>> NOTE: Special care is required with this patch. Specifically, it needs >>> to be synchronized with this patch: https://github.com/krb5/krb5/pull/45 >>> >>> The background here is the desire of SELinux folks to move the sockets >>> into /run. MIT has agreed to use the new runstatedir in autoconf git >>> master (soon to be 2.70). This change has been applied upstream and will >>> be part of the 1.13 release. The major downside is that this patch is >>> backwards incompatible. >>> >>> In the interest of making backwards incompatible changes as quickly as >>> possible before increased adoption, Nalin and I have agreed to backport >>> this patch to rawhide. We are also strongly considering a backport to >>> F20. >>> >>> Nathaniel >> >> >> This worked for me in a F20 downstream scratch build, socket was on the assumed >> place. >> >> 1) I think you should also update the upstream reference spec file so that the >> updated KDC is required: >> >> @@ -118,7 +119,7 @@ Requires: nss >= 3.14.3-12.0 >> Requires: nss-tools >= 3.14.3-12.0 >> %endif >> %if 0%{?krb5_dal_version} >= 4 >> -Requires: krb5-server >= 1.11.2-1 >> +Requires: krb5-server >= 1.11.5-3 >> %else >> %if 0%{krb5_dal_version} == 3 >> # krb5 1.11 bumped DAL interface major version, a rebuild is needed > > Fix attached. > >> 2) What do you mean by "backwards incompatible"? That updated KDC won't work >> with non-patched FreeIPA? > > Updated KDC will continue to work for all manually configured OTP > servers. However, the KDC also supports "implicit configuration" which > looks in a specific directory for sockets. This directory is what is > changing. If you update the KDC without FreeIPA, the KDC won't be able > to find the FreeIPA socket because we depend on implicit configuration. > The FreeIPA patch just makes systemd create the socket in the right > place. Either a reboot or "systemctl daemon-reload; systemctl restart > ipa-otpd.socket" are required to make the changes take effect. > >> Just checking - upgrades should work fine, right? I.e. when both FreeIPA and >> KRB5KDC is updated, OTP will keep working? No re-install needed? > > Correct. > ACK, pushed to master. freeipa-3.3.4-3.fc20 is now in build. Martin From mkosek at redhat.com Tue Feb 11 16:51:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 17:51:17 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains In-Reply-To: <52FA4B97.6060805@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> <52FA4B97.6060805@redhat.com> Message-ID: <52FA5505.3040108@redhat.com> On 02/11/2014 05:11 PM, Jan Cholasta wrote: > On 11.2.2014 16:23, Martin Basti wrote: >> On Tue, 2014-02-11 at 15:42 +0100, Jan Cholasta wrote: >>> On 11.2.2014 14:29, Martin Basti wrote: >>>> On Mon, 2014-02-10 at 14:28 +0100, Jan Cholasta wrote: >>>>> On 10.2.2014 13:14, Martin Basti wrote: >>>>>> On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote: >>>>>>> On 10.2.2014 08:50, Petr Spacek wrote: >>>>>>>> On 7.2.2014 10:42, Martin Basti wrote: >>>>>>>>> On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote: >>>>>>>>>> On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote: >>>>>>>>>>> On 6.2.2014 15:57, Martin Basti wrote: >>>>>>>>>>>> On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 31.1.2014 16:06, Martin Basti wrote: >>>>>>>>>>>>>> Reverse domain names in form "0/28.0.10.10.in-addr.arpa." are now >>>>>>>>>>>>>> allowed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4143 >>>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>> >>>>>>>>>>>> I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6 >>>>>>>>>>>> >>>>>>>>>>>>> I think the validation should be more strict. IPv4 reverse zones >>>>>>>>>>>>> should >>>>>>>>>>>>> allow slash only in the label for the last octet (i.e. >>>>>>>>>>>>> 0/25.1.168.192 is >>>>>>>>>>>>> valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow >>>>>>>>>>>>> slash >>>>>>>>>>>>> at all. >>>>>>>>>>>>> >>>>>>>>>>>> I havent found anything about IPv6, RFCs don't forbids it. >>>>>>>>>>> >>>>>>>>>>> AFAIK the RFCs do not forbid anything, but we do validation anyway, so >>>>>>>>>>> we might as well do it right, otherwise there is no point in doing it. >>>>>>>>>>> >>>>>>>>>> OK, I leave there only IPv4 >>>>>>> >>>>>>> For the record, we discussed this off-line with Martin and Petr and >>>>>>> figured out it would be best to allow slashes in IPv6 reverse zones >>>>>>> after all. >>>>>>> >>>>>>>>>> >>>>>>>>>>>> 1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to >>>>>>>>>>>> CNAME >>>>>>>>>>>> records >>>>>>>>>>> >>>>>>>>>>> Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned >>>>>>>>>>> about. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://tools.ietf.org/html/rfc6672#section-6.2 >>>>>>>>>> This can give a very strange positions of / in FQDN >>>>>>> >>>>>>> Point taken. >>>>>>> >>>>>>>>>> >>>>>>>>>> Optionally, I could permit only 1 slash in domain name, but I have to >>>>>>>>>> inspect first if user can do something useful with subnet of subnet in >>>>>>>>>> DNS, like 1.0/25.128/25.168.192.in-addr.arpa >>>>>>>> Multiple slashes has to be allowed, without limitation to last octet. >>>>>>>> Imagine situation when split subnet is later split to even smaller pieces. >>>>>>>> >>>>>>>> Guys, do not over-engineer it. IMHO this validator should produce a >>>>>>>> warning is something is not as we expect but it should not block user >>>>>>>> from adding a record. >>>>>>>> >>>>>>>> We have had enough problems with too strict validators in the past and >>>>>>>> IMHO warning is the way to go. >>>>>>> >>>>>>> I agree, but it's too late to get such change into 3.3.x. >>>>>>> >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>>>>>> The slashes in domain names are referenced as the best practise in >>>>>>>>>>>> RFC, >>>>>>>>>>>> there are not strict rules. >>>>>>>>>>>>> >>>>>>>>>>>>> +def _cname_hostname_validator(ugettext, value): >>>>>>>>>>>>> >>>>>>>>>>>>> Can you name this _bind_cname_hostname_validator, so that it is >>>>>>>>>>>>> clear it >>>>>>>>>>>>> is related to _bind_hostname_validator? >>>>>>>>>>>>> >>>>>>>>>>>> I will rename it >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> + #classless reverse zones can contain slash '/' >>>>>>>>>>>>> + if not zone_is_reverse(normalized_zone) and >>>>>>>>>>>>> (normalized_zone.count('/') > 0): >>>>>>>>>>>>> + raise errors.ValidationError(name='name', >>>>>>>>>>>>> + error=_("Only reverse zones can contain >>>>>>>>>>>>> '/' in >>>>>>>>>>>>> labels")) >>>>>>>>>>>>> >>>>>>>>>>>>> This should be handled in _domain_name_validator. Validation in >>>>>>>>>>>>> pre_callback should be done only when the validation depends on >>>>>>>>>>>>> values >>>>>>>>>>>>> of multiple parameters, which is not this case. >>>>>>>>>>>>> >>>>>>>>>>>> I will move it >>>>>>>>>>>>> >>>>>>>>>>>>> + def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, >>>>>>>>>>>>> *keys, >>>>>>>>>>>>> **options): >>>>>>>>>>>>> >>>>>>>>>>>>> Rename this to _idnsname_pre_callback and you won't have to call it >>>>>>>>>>>>> explicitly in run_precallback_validators. >>>>>>>>>>>>> >>>>>>>>>>>> I will rename it >>>>>>>>>>>>> >>>>>>>>>>>>> + if addr.count('/') > 0: >>>>>>>>>>>>> >>>>>>>>>>>>> I think "if '/' in addr:" would be better. >>>>>>>>>>>>> >>>>>>>>>>>> I will change it >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -def validate_dns_label(dns_label, allow_underscore=False): >>>>>>>>>>>>> +def validate_dns_label(dns_label, allow_underscore=False, >>>>>>>>>>>>> allow_slash=False): >>>>>>>>>>>>> >>>>>>>>>>>>> IMO instead of adding a new boolean argument, it would be nicer to >>>>>>>>>>>>> replace allow_underscore with an argument (e.g. allowed_chars) which >>>>>>>>>>>>> takes a string of extra allowed characters. >>>>>>>>>>>>> >>>>>>>>>>>> But I have to handle not only allowed chars, but position of the chars >>>>>>>>>>>> in the label string too. >>>>>>>>>>> >>>>>>>>>>> Why? Is there a RFC that forbids it? >>>>>>>>>>> >>>>>>>>>>> My point is, adding a new argument for each extra character is bad, >>>>>>>>>>> there should be a better way of doing that. >>>>>>>>>>> >>>>>>>>>> I agree, but for example: "_" should be at start (it is not required be >>>>>>>>>> at the start in IPA), "/" and "-" in the middle. >>>>>>> >>>>>>> OK then. (But I still don't like it.) >>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Updated patch attached. >>>>>>>>> Patch for tests is the same as previos. >>>>>>> >>>>>>> + validate_domain_name(value, allow_slash=True) >>>>>>> + >>>>>>> + #classless reverse zones can contain slash '/' >>>>>>> + normalized_zone = normalize_zone(value) >>>>>>> + if not zone_is_reverse(normalized_zone) and ('/' in >>>>>>> normalized_zone): >>>>>>> + return u"Only reverse zones can contain '/' in labels" >>>>>>> >>>>>>> You don't need to enclose "x in y" in parentheses. Also I don't think >>>>>>> there is any value in pointing out that slash can be used for reverse >>>>>>> zones when giving an error for non-reverse zones. I would prefer >>>>>>> something like this instead: >>>>>>> >>>>>>> normalized_zone = normalize_zone(value) >>>>>>> validate_domain_mame(value, >>>>>>> allow_slash=zone_is_reverse(normalized_zone)) >>>>>>> >>>>>>> >>>>>>> + def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys, >>>>>>> **options): >>>>>>> + #in reverse zone can a record name contains /, (and -) >>>>>>> + >>>>>>> + if self.is_pkey_zone_record(*keys): >>>>>>> + addr = u'' >>>>>>> + else: >>>>>>> + addr = keys[-1] >>>>>>> + >>>>>>> + zone = keys[-2] >>>>>>> + zone = normalize_zone(zone) >>>>>>> + if (not zone_is_reverse(zone)) and ('/' in addr): >>>>>>> + raise errors.ValidationError(name='name', >>>>>>> + error=unicode(_('Only domain names in reverse zones >>>>>>> can contain \'/\'')) ) >>>>>>> >>>>>>> I think you can do better (from the top of my head and untested): >>>>>>> >>>>>>> if not self.is_pkey_zone_record(*keys): >>>>>>> zone, addr = normalize_zone(keys[-2]), keys[-1] >>>>>>> try: >>>>>>> validate_domain_name(addr + zone, >>>>>>> allow_slash=zone_is_reverse(zone)) >>>>>>> except ValueError, e: >>>>>>> raise errors.ValidationError(name='idnsname', >>>>>>> error=str(e)) >>>>>>> >>>>>>> >>>>>>> + #Classless zones (0/25.0.0.10.in-addr.arpa.) -> skip check >>>>>>> + #zone has to be checked without reverse domain suffix >>>>>>> (in-addr.arpa.) >>>>>>> + if '/' in addr or '/' in zone or '-' in addr or '-' in zone: >>>>>>> + pass >>>>>>> + else: >>>>>>> + ip_addr_comp_count = addr_len + len(zone.split('.')) >>>>>>> + if ip_addr_comp_count != zone_len: >>>>>>> + raise errors.ValidationError(name='ptrrecord', >>>>>>> + error=unicode(_('Reverse zone %(name)s requires >>>>>>> exactly %(count)d IP address components, %(user_count)d given') >>>>>>> + % dict(name=zone_name, count=zone_len, >>>>>>> user_count=ip_addr_comp_count))) >>>>>>> >>>>>>> Is there anything preventing us from dropping this whole check? I don't >>>>>>> think it makes sense anymore. >>>>>>> >>>>>> IMO it doesnt have sense with classless reverse domains, but it is >>>>>> useful with classfull reverse domains, which are used more, to prevent >>>>>> users making mistakes. >>>>> >>>>> OK, but please use a simple if instead of if/pass/else. >>>>> >>>>>> >>>>>>> >>>>>>> IMHO validate_dns_label is very ugly. I would prefer if it looked >>>>>>> something like this instead (again, from the top of my head and untested): >>>>>>> >>>>>>> def validate_dns_label(dns_label, allow_underscore=False, >>>>>>> allow_slash=False): >>>>>>> base_chars = 'a-z0-9' >>>>>>> extra_chars = '' >>>>>>> middle_chars = '' >>>>>>> >>>>>>> if allow_underscore: >>>>>>> extra_chars += "_" >>>>>>> if allow_slash: >>>>>>> middle_chars += '/' >>>>>>> >>>>>>> middle_chars += '-' >>>>>>> >>>>>>> label_regex = >>>>>>> r'^[%(base)s%(extra)s]([%(base)s%(extra)%(middle)s]?[%(base)s%(extra)s])*$' >>>>>>> % dict(base=base_chars, extra=extra_chars, middle=middle_chars) >>>>>>> regex = re.compile(label_regex, re.IGNORECASE) >>>>>>> >>>>>>> if not dns_label: >>>>>>> raise ValueError(_('empty DNS label')) >>>>>>> >>>>>>> if len(dns_label) > 63: >>>>>>> raise ValueError(_('DNS label cannot be longer that 63 >>>>>>> characters')) >>>>>>> >>>>>>> if not regex.match(dns_label): >>>>>>> chars = ', '.join('"%s"' % c for c in base_chars + extra_chars >>>>>>> + middle_chars) >>>>>>> chars2 = ', '.join('"%s"' % c for c in middle_chars) >>>>>>> raise ValueError(_('only letters, numbers, %(chars)s are >>>>>>> allowed. ' \ >>>>>>> 'DNS label may not start or end with >>>>>>> %(chars2)s') \ >>>>>>> % dict(chars=chars, chars2=chars2)) >>>>>>> >>>>>>> >>>>>> >>>>>> Thank you for the review, I will fix it. >>>>>> >>>>> >>>>> >>>> >>>> All fixed. Patches attached. >>>> >>> >>> Thanks! >>> >>> >>> I see some new test failures caused by the error message change: >>> >>> ====================================================================== >>> FAIL: test_netgroup[17]: netgroup_add_member: Add invalid host >>> u'+invalid&host' to netgroup u'netgroup1' >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 284, in >>> func = lambda: self.check(nice, **test) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 298, in check >>> self.check_exception(nice, cmd, args, options, expected) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 324, in check_exception >>> assert_deepequal(expected.strerror, e.strerror) >>> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >>> in assert_deepequal >>> VALUE % (doc, expected, got, stack) >>> AssertionError: assert_deepequal: expected != got. >>> >>> expected = u"invalid 'host': only letters, numbers, _, and - are >>> allowed. DNS label may not start or end with -" >>> got = u"invalid 'host': only letters, numbers, '_', '-' are allowed. >>> DNS label may not start or end with '-'" >>> path = () >>> >>> ====================================================================== >>> FAIL: test_netgroup[32]: netgroup_mod: Add invalid host u'+invalid&host' >>> to netgroup u'netgroup1' using setattr >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 284, in >>> func = lambda: self.check(nice, **test) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 298, in check >>> self.check_exception(nice, cmd, args, options, expected) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 324, in check_exception >>> assert_deepequal(expected.strerror, e.strerror) >>> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >>> in assert_deepequal >>> VALUE % (doc, expected, got, stack) >>> AssertionError: assert_deepequal: expected != got. >>> >>> expected = u"invalid 'externalhost': only letters, numbers, _, and - >>> are allowed. DNS label may not start or end with -" >>> got = u"invalid 'externalhost': only letters, numbers, '_', '-' are >>> allowed. DNS label may not start or end with '-'" >>> path = () >>> >>> ====================================================================== >>> FAIL: test_raduisproxy[21]: radiusproxy_mod: Set server string of >>> testradius to testradius.test:1:2:3 (invalid) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 284, in >>> func = lambda: self.check(nice, **test) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 298, in check >>> self.check_exception(nice, cmd, args, options, expected) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", >>> line 324, in check_exception >>> assert_deepequal(expected.strerror, e.strerror) >>> File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 352, >>> in assert_deepequal >>> VALUE % (doc, expected, got, stack) >>> AssertionError: assert_deepequal: expected != got. >>> >>> expected = u"invalid 'ipatokenradiusserver': only letters, numbers, >>> _, and - are allowed. DNS label may not start or end with -" >>> got = u"invalid 'ipatokenradiusserver': only letters, numbers, '_', >>> '-' are allowed. DNS label may not start or end with '-'" >>> path = () >>> >>> ====================================================================== >>> FAIL: Test adding an invalid external host to Sudo rule using >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_sudorule_plugin.py", >>> >>> line 500, in test_a_sudorule_mod_externalhost_invalid_addattr >>> "DNS label may not start or end with -") >>> AssertionError >>> >>> >>> And one nitpick: please don't add the extra newlines around >>> _domain_name_validator. >>> >>> >>> Honza >>> >> >> Thank you for review. >> >> Patches attached. >> Extra blank lines removed. >> The others test are fixed now. >> > > ACK. > Pushed both patches to master, but just the first to ipa-3-3 as the test updating patch did not apply (a lot). Martin, you will need to check if DNS tests pass in ipa-3-3, I assume there are changes required. Martin From mbasti at redhat.com Wed Feb 12 10:05:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Feb 2014 11:05:16 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025, 0027] Classless support for reverse domains In-Reply-To: <52FA5505.3040108@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> <52FA4B97.6060805@redhat.com> <52FA5505.3040108@redhat.com> Message-ID: <1392199516.2368.6.camel@unused-4-145.brq.redhat.com> > > Pushed both patches to master, but just the first to ipa-3-3 as the test > updating patch did not apply (a lot). > > Martin, you will need to check if DNS tests pass in ipa-3-3, I assume there are > changes required. > > Martin Patch for ipa-3-3 tests attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0027-1-DNS-tests-classless-domains-3-3-backport.patch Type: text/x-patch Size: 18738 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 12 10:11:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 11:11:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files In-Reply-To: <52FA4D3D.2000903@redhat.com> References: <52FA4D3D.2000903@redhat.com> Message-ID: <52FB48BC.1080506@redhat.com> On 02/11/2014 05:18 PM, Petr Viktorin wrote: > Hello, > I have a cold and a headache today, so I could't concentrate on anything > complicated today :( > Instead I did some small changes to our project files. > > 0460: .mailmap > This fixes and deduplicates the output of `git shortlog -se`. > It also puts proper diacritics in people's names if they don't use those in > commits. The changes only appear in the shortlog. > It might be a bit controversial, I'm not insisting it needs to go in, but I'll > be using it so I'm sharing. Makes sense to me, some fixes would be needed though: 1) I see both "Endi S. Dewata" and "Endi Sukma Dewata" 2) If we want to do proper diacritics, then: s/Basti/Ba?ti/ s/Zuna/Z?na/ s/Slebodnik/Slebodn?k/ > > 0461: Contributors.txt > Jenny changed her last name. OK. > > 0462: README & BUILD.txt > Update README with current info from http://www.freeipa.org/page/Leaflet, fix > broken links, refresh build instructions. I miss some note about the AD integration, we can build it on this sentence in the leaflet: Seamless integration into Active Directory Environment via cross-realm Kerberos trust or user synchronization > > 0463: Remove TODO > This file was just ancient cruft. We have trac for this. OK. I am surprised this file lasted that long :) Martin From pvoborni at redhat.com Wed Feb 12 10:24:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Feb 2014 11:24:04 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files In-Reply-To: <52FA4D3D.2000903@redhat.com> References: <52FA4D3D.2000903@redhat.com> Message-ID: <52FB4BC4.5030601@redhat.com> On 11.2.2014 17:18, Petr Viktorin wrote: > Hello, > I have a cold and a headache today, so I could't concentrate on anything > complicated today :( > Instead I did some small changes to our project files. > > 0460: .mailmap > This fixes and deduplicates the output of `git shortlog -se`. > It also puts proper diacritics in people's names if they don't use those > in commits. The changes only appear in the shortlog. > It might be a bit controversial, I'm not insisting it needs to go in, > but I'll be using it so I'm sharing. Kyle's mail is kybaker at redhat, not kbaker at redhat. kbaker is a different person. > > 0461: Contributors.txt > Jenny changed her last name. > > 0462: README & BUILD.txt > Update README with current info from > http://www.freeipa.org/page/Leaflet, fix broken links, refresh build > instructions. > > 0463: Remove TODO > This file was just ancient cruft. We have trac for this. > -- Petr Vobornik From mkosek at redhat.com Wed Feb 12 12:12:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 13:12:52 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025, 0027] Classless support for reverse domains In-Reply-To: <1392199516.2368.6.camel@unused-4-145.brq.redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> <52FA4B97.6060805@redhat.com> <52FA5505.3040108@redhat.com> <1392199516.2368.6.camel@unused-4-145.brq.redhat.com> Message-ID: <52FB6544.60103@redhat.com> On 02/12/2014 11:05 AM, Martin Basti wrote: > >> >> Pushed both patches to master, but just the first to ipa-3-3 as the test >> updating patch did not apply (a lot). >> >> Martin, you will need to check if DNS tests pass in ipa-3-3, I assume there are >> changes required. >> >> Martin > > Patch for ipa-3-3 tests attached. > NACK. I see one more failure: ====================================================================== FAIL: test_host[38]: host_add: Test that validation is enabled on adds ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in func = lambda: self.check(nice, **test) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 297, in check self.check_exception(nice, cmd, args, options, expected) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 323, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'hostname': invalid domain-name: only letters, numbers, and - are allowed. DNS label may not start or end with -" got = u"invalid 'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS label may not start or end with '-'" path = () Martin From pviktori at redhat.com Wed Feb 12 12:34:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 13:34:29 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files In-Reply-To: <52FB48BC.1080506@redhat.com> References: <52FA4D3D.2000903@redhat.com> <52FB48BC.1080506@redhat.com> Message-ID: <52FB6A55.30709@redhat.com> On 02/12/2014 11:11 AM, Martin Kosek wrote: > On 02/11/2014 05:18 PM, Petr Viktorin wrote: >> Hello, >> I have a cold and a headache today, so I could't concentrate on anything >> complicated today :( >> Instead I did some small changes to our project files. >> >> 0460: .mailmap >> This fixes and deduplicates the output of `git shortlog -se`. >> It also puts proper diacritics in people's names if they don't use those in >> commits. The changes only appear in the shortlog. >> It might be a bit controversial, I'm not insisting it needs to go in, but I'll >> be using it so I'm sharing. > > Makes sense to me, some fixes would be needed though: > > 1) I see both "Endi S. Dewata" and "Endi Sukma Dewata" > > 2) If we want to do proper diacritics, then: > s/Basti/Ba?ti/ > s/Zuna/Z?na/ > s/Slebodnik/Slebodn?k/ Z?na? I never knew. The rest is sloppiness on my part, apologies. Fixed, along with the issue Petr noticed (s/kbaker/kybaker/) > >> >> 0461: Contributors.txt >> Jenny changed her last name. > > OK. > >> >> 0462: README & BUILD.txt >> Update README with current info from http://www.freeipa.org/page/Leaflet, fix >> broken links, refresh build instructions. > > I miss some note about the AD integration, we can build it on this sentence in > the leaflet: > > Seamless integration into Active Directory Environment via cross-realm Kerberos > trust or user synchronization Added. >> 0463: Remove TODO >> This file was just ancient cruft. We have trac for this. > > OK. I am surprised this file lasted that long :) > > Martin Thanks for the review! Please leave pushing to me if this is ACKed, I want to test a new patch-pushing tool. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0460-Add-a-.mailmap-file.patch Type: text/x-patch Size: 3723 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0461-Correct-Jenny-Severance-s-last-name.patch Type: text/x-patch Size: 694 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0462-Update-README-and-BUILD.patch Type: text/x-patch Size: 8212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0463-Remove-the-TODO-file.patch Type: text/x-patch Size: 3863 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 12 12:44:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 13:44:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files In-Reply-To: <52FB6A55.30709@redhat.com> References: <52FA4D3D.2000903@redhat.com> <52FB48BC.1080506@redhat.com> <52FB6A55.30709@redhat.com> Message-ID: <52FB6CAE.7010901@redhat.com> On 02/12/2014 01:34 PM, Petr Viktorin wrote: > On 02/12/2014 11:11 AM, Martin Kosek wrote: >> On 02/11/2014 05:18 PM, Petr Viktorin wrote: >>> Hello, >>> I have a cold and a headache today, so I could't concentrate on anything >>> complicated today :( >>> Instead I did some small changes to our project files. >>> >>> 0460: .mailmap >>> This fixes and deduplicates the output of `git shortlog -se`. >>> It also puts proper diacritics in people's names if they don't use those in >>> commits. The changes only appear in the shortlog. >>> It might be a bit controversial, I'm not insisting it needs to go in, but I'll >>> be using it so I'm sharing. >> >> Makes sense to me, some fixes would be needed though: >> >> 1) I see both "Endi S. Dewata" and "Endi Sukma Dewata" >> >> 2) If we want to do proper diacritics, then: >> s/Basti/Ba?ti/ >> s/Zuna/Z?na/ >> s/Slebodnik/Slebodn?k/ > > Z?na? I never knew. > The rest is sloppiness on my part, apologies. > > Fixed, along with the issue Petr noticed (s/kbaker/kybaker/) > >> >>> >>> 0461: Contributors.txt >>> Jenny changed her last name. >> >> OK. >> >>> >>> 0462: README & BUILD.txt >>> Update README with current info from http://www.freeipa.org/page/Leaflet, fix >>> broken links, refresh build instructions. >> >> I miss some note about the AD integration, we can build it on this sentence in >> the leaflet: >> >> Seamless integration into Active Directory Environment via cross-realm Kerberos >> trust or user synchronization > > Added. > >>> 0463: Remove TODO >>> This file was just ancient cruft. We have trac for this. >> >> OK. I am surprised this file lasted that long :) >> >> Martin > > Thanks for the review! > > Please leave pushing to me if this is ACKed, I want to test a new patch-pushing > tool. > Looks good to me, ACK to all! Make sure the new patch-pushing tool properly fills Reviewed-By tag ;-) Martin From mbasti at redhat.com Wed Feb 12 12:47:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Feb 2014 13:47:31 +0100 Subject: [Freeipa-devel] [PATCHES 0024, 0025, 0027, 0028] Classless support for reverse domains In-Reply-To: <52FB6544.60103@redhat.com> References: <1391180764.2394.3.camel@unused-4-145.brq.redhat.com> <52F35CEC.4050603@redhat.com> <1391698671.20096.10.camel@unused-4-145.brq.redhat.com> <52F3AC53.7040505@redhat.com> <1391702641.20096.19.camel@unused-4-145.brq.redhat.com> <1391766130.24998.2.camel@unused-4-145.brq.redhat.com> <52F884B5.8090501@redhat.com> <52F8B685.3020603@redhat.com> <1392034459.2384.5.camel@unused-4-145.brq.redhat.com> <52F8D3E2.2000004@redhat.com> <1392125389.2386.0.camel@unused-4-145.brq.redhat.com> <52FA36CC.5060103@redhat.com> <1392132214.11060.1.camel@unused-4-145.brq.redhat.com> <52FA4B97.6060805@redhat.com> <52FA5505.3040108@redhat.com> <1392199516.2368.6.camel@unused-4-145.brq.redhat.com> <52FB6544.60103@redhat.com> Message-ID: <1392209251.2368.9.camel@unused-4-145.brq.redhat.com> On Wed, 2014-02-12 at 13:12 +0100, Martin Kosek wrote: > On 02/12/2014 11:05 AM, Martin Basti wrote: > > > >> > >> Pushed both patches to master, but just the first to ipa-3-3 as the test > >> updating patch did not apply (a lot). > >> > >> Martin, you will need to check if DNS tests pass in ipa-3-3, I assume there are > >> changes required. > >> > >> Martin > > > > Patch for ipa-3-3 tests attached. > > > > NACK. > > I see one more failure: > > ====================================================================== > FAIL: test_host[38]: host_add: Test that validation is enabled on adds > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 297, in > check > self.check_exception(nice, cmd, args, options, expected) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 323, in > check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'hostname': invalid domain-name: only letters, numbers, > and - are allowed. DNS label may not start or end with -" > got = u"invalid 'hostname': invalid domain-name: only letters, numbers, '-' > are allowed. DNS label may not start or end with '-'" > path = () > > Martin Sorry for that, patch 0028 fix it. Patch 0028 should be applied after 0027 to ipa-3-3 branch. Patch 0028 should be applied to master branch too. Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0028-1-FIX-test_host_plugin-for-DNS-Classless-Reverse-zones.patch Type: text/x-patch Size: 1231 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0027-1-DNS-tests-classless-domains-3-3-backport.patch Type: text/x-patch Size: 18738 bytes Desc: not available URL: From pviktori at redhat.com Wed Feb 12 13:07:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 14:07:46 +0100 Subject: [Freeipa-devel] [PATCHES] 0460-0463 - Fixes in project files In-Reply-To: <52FB6CAE.7010901@redhat.com> References: <52FA4D3D.2000903@redhat.com> <52FB48BC.1080506@redhat.com> <52FB6A55.30709@redhat.com> <52FB6CAE.7010901@redhat.com> Message-ID: <52FB7222.3000800@redhat.com> On 02/12/2014 01:44 PM, Martin Kosek wrote: > On 02/12/2014 01:34 PM, Petr Viktorin wrote: >> On 02/12/2014 11:11 AM, Martin Kosek wrote: >>> On 02/11/2014 05:18 PM, Petr Viktorin wrote: >>>> Hello, >>>> I have a cold and a headache today, so I could't concentrate on anything >>>> complicated today :( >>>> Instead I did some small changes to our project files. >>>> >>>> 0460: .mailmap >>>> This fixes and deduplicates the output of `git shortlog -se`. >>>> It also puts proper diacritics in people's names if they don't use those in >>>> commits. The changes only appear in the shortlog. >>>> It might be a bit controversial, I'm not insisting it needs to go in, but I'll >>>> be using it so I'm sharing. >>> >>> Makes sense to me, some fixes would be needed though: >>> >>> 1) I see both "Endi S. Dewata" and "Endi Sukma Dewata" >>> >>> 2) If we want to do proper diacritics, then: >>> s/Basti/Ba?ti/ >>> s/Zuna/Z?na/ >>> s/Slebodnik/Slebodn?k/ >> >> Z?na? I never knew. >> The rest is sloppiness on my part, apologies. >> >> Fixed, along with the issue Petr noticed (s/kbaker/kybaker/) >> >>> >>>> >>>> 0461: Contributors.txt >>>> Jenny changed her last name. >>> >>> OK. >>> >>>> >>>> 0462: README & BUILD.txt >>>> Update README with current info from http://www.freeipa.org/page/Leaflet, fix >>>> broken links, refresh build instructions. >>> >>> I miss some note about the AD integration, we can build it on this sentence in >>> the leaflet: >>> >>> Seamless integration into Active Directory Environment via cross-realm Kerberos >>> trust or user synchronization >> >> Added. >> >>>> 0463: Remove TODO >>>> This file was just ancient cruft. We have trac for this. >>> >>> OK. I am surprised this file lasted that long :) >>> >>> Martin >> >> Thanks for the review! >> >> Please leave pushing to me if this is ACKed, I want to test a new patch-pushing >> tool. >> > > Looks good to me, ACK to all! Make sure the new patch-pushing tool properly > fills Reviewed-By tag ;-) > > Martin > Thank you! Pushed to master: 9ae2696a858e9b928436ea68180e1234ffd44ff0 -- Petr? From pviktori at redhat.com Wed Feb 12 13:36:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 14:36:26 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag In-Reply-To: <52F8CD2F.7000603@redhat.com> References: <52F8C6CC.1030809@redhat.com> <52F8CC26.7060708@redhat.com> <52F8CD2F.7000603@redhat.com> Message-ID: <52FB78DA.5020800@redhat.com> On 02/10/2014 01:59 PM, Martin Kosek wrote: > On 02/10/2014 01:55 PM, Petr Viktorin wrote: [...] >> I'll use some time this week to write a better patch-pushing helper that'll >> incorporate this. >> (For the record, now we usually use >> https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) > > That may be the best option for the short term. I would envision something like: > > $ pushpatch.py freeipa-somebody-1-great.patch > ... > Reviewed by: > 0) Me > 1) Petr Vobornik > 2) Martin Kosek > 3) Petr Viktorin > 4) ... > 99) Others: > > Reviewed-By choice [0]: _ Since the time I tried using `certutil -R` from a script, I like to provide command line options instead, and limit interactivity to a [y/n] question at the end. > Martin The tool is available for beta-testing at: git clone https://github.com/encukou/ipa-tools.git (pushpatches.py) or: https://raw.github.com/encukou/ipa-tools/master/pushpatches.py Please check the output before answering "yes" :) It has a few futuristic dependencies: sudo yum install python3-docopt python3-PyYAML python3-blessings You need a config file in ~/.ipa/pushpatch.yaml; `pushpatches.py --help` has an example one. My workflow is to add patches to a designated "to-apply" directory (mentioned in the config file), and then run something like: dev/ipa-tools/pushpatches.py --reviewer mkosek --branch={master,ipa-3-3} You can of course specify patches on the command line instead. If you leave --branches out, it'll try to get the branches from ticket milestones. Please double-check if you use this. It will also divine Bugzilla URLs from Trac tickets. It doesn't auto-open the tickets in a browser, but hopefully nowadays most terminal emulators make URLs clickable. -- Petr? From pviktori at redhat.com Wed Feb 12 13:49:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 14:49:01 +0100 Subject: [Freeipa-devel] Using the Reviewed-by git tag In-Reply-To: <52FB78DA.5020800@redhat.com> References: <52F8C6CC.1030809@redhat.com> <52F8CC26.7060708@redhat.com> <52F8CD2F.7000603@redhat.com> <52FB78DA.5020800@redhat.com> Message-ID: <52FB7BCD.6030206@redhat.com> On 02/12/2014 02:36 PM, Petr Viktorin wrote: > On 02/10/2014 01:59 PM, Martin Kosek wrote: >> On 02/10/2014 01:55 PM, Petr Viktorin wrote: > [...] >>> I'll use some time this week to write a better patch-pushing helper >>> that'll >>> incorporate this. >>> (For the record, now we usually use >>> https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) >> >> That may be the best option for the short term. I would envision >> something like: >> >> $ pushpatch.py freeipa-somebody-1-great.patch >> ... >> Reviewed by: >> 0) Me >> 1) Petr Vobornik >> 2) Martin Kosek >> 3) Petr Viktorin >> 4) ... >> 99) Others: >> >> Reviewed-By choice [0]: _ > > Since the time I tried using `certutil -R` from a script, I like to > provide command line options instead, and limit interactivity to a [y/n] > question at the end. > >> Martin > > > The tool is available for beta-testing at: > git clone https://github.com/encukou/ipa-tools.git (pushpatches.py) > or: https://raw.github.com/encukou/ipa-tools/master/pushpatches.py > Please check the output before answering "yes" :) > > It has a few futuristic dependencies: > sudo yum install python3-docopt python3-PyYAML python3-blessings Note: python3-docopt is only in updates-testing ATM. Update: The tool now approximates reviewer names in ASCII (basically, it removes any diacritics). This adds a new dependency: python3-unidecode. > You need a config file in ~/.ipa/pushpatch.yaml; `pushpatches.py > --help` has an example one. > > My workflow is to add patches to a designated "to-apply" directory > (mentioned in the config file), and then run something like: > dev/ipa-tools/pushpatches.py --reviewer mkosek --branch={master,ipa-3-3} > You can of course specify patches on the command line instead. > > If you leave --branches out, it'll try to get the branches from ticket > milestones. Please double-check if you use this. > It will also divine Bugzilla URLs from Trac tickets. > It doesn't auto-open the tickets in a browser, but hopefully nowadays > most terminal emulators make URLs clickable. > -- Petr? From mkosek at redhat.com Wed Feb 12 15:57:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 16:57:51 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52F8F608.3070400@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <52EB9A83.1040705@redhat.com> <52F8F608.3070400@redhat.com> Message-ID: <52FB99FF.6010801@redhat.com> On 02/10/2014 04:53 PM, Petr Viktorin wrote: > On 01/31/2014 01:43 PM, Martin Kosek wrote: >> On 01/24/2014 04:48 PM, Petr Viktorin wrote: >>> On 01/23/2014 02:42 PM, Simo Sorce wrote: >>>> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >>>>> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>>>>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>>>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> This adds "managed" permissions, the framework that will make our >>>>>>>> default permissions merge IPA updates and user changes sanely. >>>>>>>> >>>>>>>> There is no updater yet, nor does this add any actual managed >>>>>>>> permissions, so there's no user-visible change (beyond help text and a >>>>>>>> disabled option). To test the patch you might need to touch LDAP directly. >>>>>>>> >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>>>>> Design (no updater & plugin changes yet): >>>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>>> >>>>>>>> 0447 - Minor fixes. >>>>>>>> 0448 - Since you can't create managed permissions through the API, I >>>>>>>> needed to get creative with the declarative tests. The tests will need a >>>>>>>> custom function that adds a managed perm. >>>>>>>> 0449 - The change itself. >>>>>>> >>>>>>> ping; any thoughts on this one? >>>>>>> >>>>>>> >>>>>> >>>>>> 1) 449, the comment: >>>>>> >>>>>> +Deleting or renaming a managed permission, as well as changing its target, >>>>>> +is not supported. >>>>>> +""") + _(""" >>>>>> >>>>>> I am not sure that the phrase "not supported" is the right one. It sounds >>>>>> to me >>>>>> like this is something we want to allow, just not implemented yet. IMO >>>>>> "is not >>>>>> allowed" would be better. >>>>> >>>>> Makes sense. >>>>> >>>>>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>>>>> >>>>>> + flags={'no_create', 'allow_mod_for_managed'}, >>>>>> >>>>>> So far we try to add all flag descriptions there. >>>>> >>>>> OK >>>>> >>>>>> 3) When I updated the test to not delete the testperm, I tried to show the >>>>>> managed permission and it is not entirely clear, see: >>>>>> >>>>>> # ipa permission-show testperm >>>>>> Permission name: testperm >>>>>> Permissions: write >>>>>> * Attributes: cn, o, sn >>>>>> * Excluded attributes: cn, sn >>>>>> Bind rule type: all >>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>> Type: user >>>>>> * Default attributes: l, o, cn >>>>>> * Effective attributes: l, o >>>>> >>>>> Well, this is a tradeoff between presenting what's stored in LDAP and >>>>> what's in the ACI. >>>>> >>>>>> The "Attributes" mean actually attributes explicitly allowed by user, but >>>>>> it is >>>>>> not obvious from the output. >>>>>> >>>>>> Maybe it would be better to return only "Effective attributes" by default >>>>>> and >>>>>> return the 3 source lists only when --all is passed. But this would >>>>>> require us >>>>>> to let Command override LDAPObject's default_attributes, which framework >>>>>> cannot do. >>>>> >>>>> Modifying default_attributes would not work because the 3 lists need to >>>>> be loaded from LDAP to determine the effective attributes. >>>>> It's possible to remove the extra attributes in the post_callback, >>>>> postprocess_result already does similar output manipulation. >>>>> >>>>>> Alternatively, we may choose to use the attributes differently with managed >>>>>> permissions: >>>>>> - we add the new attributeType "ipaPermIncludedAttr". It would be used >>>>>> for the >>>>>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>>>>> - we do not use the ipaPermAllowedAttr with managed attributes at all or >>>>>> use it >>>>>> for the "Effective attributes" list >>>>>> >>>>>> My point is that the semantics of ipaPermAllowedAttr is different for >>>>>> managed >>>>>> and non-managed permission, so it may confuse people. >>>>> >>>>> Well, the semantics are always the same (effective = (default | allowed) >>>>> - excluded). I agree that it can be confusing; perhaps I'm in too deep >>>>> to judge how it looks from the outside. >>>>> >>>>>> For example, you may want >>>>>> to search for all permissions that allow attribute "sn": >>>>>> >>>>>> # ipa permission-find --attrs sn >>>>>> --------------------- >>>>>> 4 permissions matched >>>>>> --------------------- >>>>>> Permission name: anon >>>>>> Permissions: read >>>>>> Attributes: sn >>>>>> Bind rule type: anonymous >>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>> Type: user >>>>>> ... >>>>>> Permission name: testperm >>>>>> Permissions: write >>>>>> Attributes: cn, o, sn >>>>>> Excluded attributes: cn, sn >>>>>> Bind rule type: anonymous >>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>> Type: user >>>>>> Default attributes: l, o, cn >>>>>> Effective attributes: l, o >>>>>> ... >>>>>> >>>>>> As you see, it matched both testperm and anon even though testperm does not >>>>>> really allow sn as it excluded. >>>>>> >>>>>> Thoughts? >>>>> >>>>> Well, we could have default, included, excluded attributes stored in >>>>> LDAP as now (using the name "included" instead of "allowed"), and make >>>>> effective attributes (--attrs) into an updatable virtual attribute: when >>>>> setting it, IPA would consult the "default" attributes and update >>>>> "included"/"excluded" accordingly. (With non-managed permissions >>>>> "default" is empty, so only "included" would be updated.) And searching >>>>> on --attrs would construct an appropriate filter. >>>>> >>>>> I thought about this approach earlier but thought that it obscured >>>>> what's actually stored in LDAP. Given recent discussions I'm now >>>>> thinking I shouldn't have rejected it. >>>> >>>> >>>> I would take a consistent approach indeed. >>>> I do not much care for the virtual attribute part in LDAP, as long as >>>> our tool show prominently the effective list. >>>> And also as long as all permissions behave the same way in the general >>>> mechanism in LDAP. >>>> >>>> Simo. >>>> >>> >>> All right. Here are patches; I'll start updating the design page. >>> >>> **NOTE** >>> This renames the 'ipaPermAllowedAttr' attribute to 'ipaPermIncludedAttr'. >>> Upgrades from master will fail, so please install a new server. Of course no >>> released versions of FreeIPA are affected. >>> I assume there's no clean way to rename an attribute without changing the OID? >>> Is it OK to break master this way? >>> >>> As before three source lists are stored in LDAP: >>> - ipaPermDefaultAttr >>> - ipaPermIncludedAttr (--includedattrs) >>> - ipaPermExcludedAttr (--excludedattrs) >>> >>> Setting --attrs ("Effective Attributes") will set the included/excluded >>> attributes based on the default set. >>> For normal permissions, default & excluded will be empty, and in this case only >>> effective attributes will be displayed on output (unless --all or --raw is >>> given). >>> >>> >>> >>> I've added some preparatory patches for #4074 to this batch, mostly to prevent >>> rebase conflicts with that work. Re-numbering for a sane order. >>> >>> Apply on top of my patch 0452 >>> >>> 0455 - minor fixes, unchanged from 0447 >>> >>> 0456 - converting options on the server it will allow us to consult the entry's >>> existing state. Arguably it's also cleaner to use execute than >>> args_options_2_params for this. >>> >>> 0457 - generate ACIs in the plugin. This is the next step in obsoleting the ACI >>> class, which in the end should only be necessary for updating old-style ACIs. >>> The one-way function should be easier to maintain and extend. >>> >>> 0458 - allow callables in declarative tests, unchanged from 0448 >>> >>> 0459 - managed permissions >>> >>> >>> Or: git pull https://github.com/encukou/freeipa 3566-managed-perms >>> commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 >>> >> >> 1) (cosmetic) Wouldn't it better to move ipapermdefaultattr to takes_params >> with ['no_create', 'no_update'] flags to: >> >> a) Have better ordering of output params. Now it looks like: >> >> # ipa permission-show testperm >> Permission name: testperm >> Permissions: write >> Effective attributes: cn, l, o, sn >> Included attributes: sn >> Bind rule type: all >> Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> ACI target DN: >> uid=*,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> Type: user >> Default attributes: l, o, cn >> >> >> I think it would be better if all the "* attributes" parameters are together.: >> >> Effective attributes: bla, bla >> Included attributes: bla, bla >> Excluded attributes: bla, bla >> Default attributes: bla, bla >> >> so that it is easier to read the output. >> >> b) If ipapermdefaultattr is in takes_params, one would be able to do >> permission-search for default attributes. Even if we don't allow user to change >> them, we should allow him to search them. >> >> 2) (also cosmetic) Given we have ipapermincludedattr described as >> doc=_('User-specified attributes to which the permission applies'), >> shouldn't we also describe ipapermexcludedattr as >> doc=_('User-specified attributes to which the permission explicitly ' >> 'does not apply'), >> ? I think it would be more consistent. >> >> >> Besides these 2 cosmetic issues, I think the new patchset works pretty nice - >> good job! > > Thanks for the review, fixed. > I've also fixed the search filter for --attrs, and added more tests for that. > Looks good to me: # ipa permission-show testperm Permission name: testperm Permissions: write Effective attributes: cn, o, sn Included attributes: sn Excluded attributes: l Default attributes: l, o, cn Bind rule type: all Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com Type: user ACK to all 5 patches (the last patch had 2-fuzz chunk). Martin From pviktori at redhat.com Wed Feb 12 16:13:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 17:13:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions In-Reply-To: <52FB99FF.6010801@redhat.com> References: <52CD738A.40105@redhat.com> <52DF8F0E.9020705@redhat.com> <52E0FBEC.2020303@redhat.com> <52E109CA.2020605@redhat.com> <1390484550.15404.79.camel@willson.li.ssimo.org> <52E28B64.9010403@redhat.com> <52EB9A83.1040705@redhat.com> <52F8F608.3070400@redhat.com> <52FB99FF.6010801@redhat.com> Message-ID: <52FB9D94.5020802@redhat.com> On 02/12/2014 04:57 PM, Martin Kosek wrote: > On 02/10/2014 04:53 PM, Petr Viktorin wrote: >> On 01/31/2014 01:43 PM, Martin Kosek wrote: >>> On 01/24/2014 04:48 PM, Petr Viktorin wrote: >>>> On 01/23/2014 02:42 PM, Simo Sorce wrote: >>>>> On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote: >>>>>> On 01/23/2014 12:24 PM, Martin Kosek wrote: >>>>>>> On 01/22/2014 10:27 AM, Petr Viktorin wrote: >>>>>>>> On 01/08/2014 04:49 PM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> This adds "managed" permissions, the framework that will make our >>>>>>>>> default permissions merge IPA updates and user changes sanely. >>>>>>>>> >>>>>>>>> There is no updater yet, nor does this add any actual managed >>>>>>>>> permissions, so there's no user-visible change (beyond help text and a >>>>>>>>> disabled option). To test the patch you might need to touch LDAP directly. >>>>>>>>> >>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4033 >>>>>>>>> Design (no updater & plugin changes yet): >>>>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>>>> >>>>>>>>> 0447 - Minor fixes. >>>>>>>>> 0448 - Since you can't create managed permissions through the API, I >>>>>>>>> needed to get creative with the declarative tests. The tests will need a >>>>>>>>> custom function that adds a managed perm. >>>>>>>>> 0449 - The change itself. >>>>>>>> >>>>>>>> ping; any thoughts on this one? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> 1) 449, the comment: >>>>>>> >>>>>>> +Deleting or renaming a managed permission, as well as changing its target, >>>>>>> +is not supported. >>>>>>> +""") + _(""" >>>>>>> >>>>>>> I am not sure that the phrase "not supported" is the right one. It sounds >>>>>>> to me >>>>>>> like this is something we want to allow, just not implemented yet. IMO >>>>>>> "is not >>>>>>> allowed" would be better. >>>>>> >>>>>> Makes sense. >>>>>> >>>>>>> 2) Can you add allow_mod_for_managed flag description to parameters.py? >>>>>>> >>>>>>> + flags={'no_create', 'allow_mod_for_managed'}, >>>>>>> >>>>>>> So far we try to add all flag descriptions there. >>>>>> >>>>>> OK >>>>>> >>>>>>> 3) When I updated the test to not delete the testperm, I tried to show the >>>>>>> managed permission and it is not entirely clear, see: >>>>>>> >>>>>>> # ipa permission-show testperm >>>>>>> Permission name: testperm >>>>>>> Permissions: write >>>>>>> * Attributes: cn, o, sn >>>>>>> * Excluded attributes: cn, sn >>>>>>> Bind rule type: all >>>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>>> Type: user >>>>>>> * Default attributes: l, o, cn >>>>>>> * Effective attributes: l, o >>>>>> >>>>>> Well, this is a tradeoff between presenting what's stored in LDAP and >>>>>> what's in the ACI. >>>>>> >>>>>>> The "Attributes" mean actually attributes explicitly allowed by user, but >>>>>>> it is >>>>>>> not obvious from the output. >>>>>>> >>>>>>> Maybe it would be better to return only "Effective attributes" by default >>>>>>> and >>>>>>> return the 3 source lists only when --all is passed. But this would >>>>>>> require us >>>>>>> to let Command override LDAPObject's default_attributes, which framework >>>>>>> cannot do. >>>>>> >>>>>> Modifying default_attributes would not work because the 3 lists need to >>>>>> be loaded from LDAP to determine the effective attributes. >>>>>> It's possible to remove the extra attributes in the post_callback, >>>>>> postprocess_result already does similar output manipulation. >>>>>> >>>>>>> Alternatively, we may choose to use the attributes differently with managed >>>>>>> permissions: >>>>>>> - we add the new attributeType "ipaPermIncludedAttr". It would be used >>>>>>> for the >>>>>>> user-specified whitelist of attributes instead of ipaPermAllowedAttr >>>>>>> - we do not use the ipaPermAllowedAttr with managed attributes at all or >>>>>>> use it >>>>>>> for the "Effective attributes" list >>>>>>> >>>>>>> My point is that the semantics of ipaPermAllowedAttr is different for >>>>>>> managed >>>>>>> and non-managed permission, so it may confuse people. >>>>>> >>>>>> Well, the semantics are always the same (effective = (default | allowed) >>>>>> - excluded). I agree that it can be confusing; perhaps I'm in too deep >>>>>> to judge how it looks from the outside. >>>>>> >>>>>>> For example, you may want >>>>>>> to search for all permissions that allow attribute "sn": >>>>>>> >>>>>>> # ipa permission-find --attrs sn >>>>>>> --------------------- >>>>>>> 4 permissions matched >>>>>>> --------------------- >>>>>>> Permission name: anon >>>>>>> Permissions: read >>>>>>> Attributes: sn >>>>>>> Bind rule type: anonymous >>>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>>> Type: user >>>>>>> ... >>>>>>> Permission name: testperm >>>>>>> Permissions: write >>>>>>> Attributes: cn, o, sn >>>>>>> Excluded attributes: cn, sn >>>>>>> Bind rule type: anonymous >>>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>>> ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com >>>>>>> Type: user >>>>>>> Default attributes: l, o, cn >>>>>>> Effective attributes: l, o >>>>>>> ... >>>>>>> >>>>>>> As you see, it matched both testperm and anon even though testperm does not >>>>>>> really allow sn as it excluded. >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> Well, we could have default, included, excluded attributes stored in >>>>>> LDAP as now (using the name "included" instead of "allowed"), and make >>>>>> effective attributes (--attrs) into an updatable virtual attribute: when >>>>>> setting it, IPA would consult the "default" attributes and update >>>>>> "included"/"excluded" accordingly. (With non-managed permissions >>>>>> "default" is empty, so only "included" would be updated.) And searching >>>>>> on --attrs would construct an appropriate filter. >>>>>> >>>>>> I thought about this approach earlier but thought that it obscured >>>>>> what's actually stored in LDAP. Given recent discussions I'm now >>>>>> thinking I shouldn't have rejected it. >>>>> >>>>> >>>>> I would take a consistent approach indeed. >>>>> I do not much care for the virtual attribute part in LDAP, as long as >>>>> our tool show prominently the effective list. >>>>> And also as long as all permissions behave the same way in the general >>>>> mechanism in LDAP. >>>>> >>>>> Simo. >>>>> >>>> >>>> All right. Here are patches; I'll start updating the design page. >>>> >>>> **NOTE** >>>> This renames the 'ipaPermAllowedAttr' attribute to 'ipaPermIncludedAttr'. >>>> Upgrades from master will fail, so please install a new server. Of course no >>>> released versions of FreeIPA are affected. >>>> I assume there's no clean way to rename an attribute without changing the OID? >>>> Is it OK to break master this way? >>>> >>>> As before three source lists are stored in LDAP: >>>> - ipaPermDefaultAttr >>>> - ipaPermIncludedAttr (--includedattrs) >>>> - ipaPermExcludedAttr (--excludedattrs) >>>> >>>> Setting --attrs ("Effective Attributes") will set the included/excluded >>>> attributes based on the default set. >>>> For normal permissions, default & excluded will be empty, and in this case only >>>> effective attributes will be displayed on output (unless --all or --raw is >>>> given). >>>> >>>> >>>> >>>> I've added some preparatory patches for #4074 to this batch, mostly to prevent >>>> rebase conflicts with that work. Re-numbering for a sane order. >>>> >>>> Apply on top of my patch 0452 >>>> >>>> 0455 - minor fixes, unchanged from 0447 >>>> >>>> 0456 - converting options on the server it will allow us to consult the entry's >>>> existing state. Arguably it's also cleaner to use execute than >>>> args_options_2_params for this. >>>> >>>> 0457 - generate ACIs in the plugin. This is the next step in obsoleting the ACI >>>> class, which in the end should only be necessary for updating old-style ACIs. >>>> The one-way function should be easier to maintain and extend. >>>> >>>> 0458 - allow callables in declarative tests, unchanged from 0448 >>>> >>>> 0459 - managed permissions >>>> >>>> >>>> Or: git pull https://github.com/encukou/freeipa 3566-managed-perms >>>> commit 51bb7f27516202a062ffa25fedae18d0e9f302b6 >>>> >>> >>> 1) (cosmetic) Wouldn't it better to move ipapermdefaultattr to takes_params >>> with ['no_create', 'no_update'] flags to: >>> >>> a) Have better ordering of output params. Now it looks like: >>> >>> # ipa permission-show testperm >>> Permission name: testperm >>> Permissions: write >>> Effective attributes: cn, l, o, sn >>> Included attributes: sn >>> Bind rule type: all >>> Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> ACI target DN: >>> uid=*,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> Type: user >>> Default attributes: l, o, cn >>> >>> >>> I think it would be better if all the "* attributes" parameters are together.: >>> >>> Effective attributes: bla, bla >>> Included attributes: bla, bla >>> Excluded attributes: bla, bla >>> Default attributes: bla, bla >>> >>> so that it is easier to read the output. >>> >>> b) If ipapermdefaultattr is in takes_params, one would be able to do >>> permission-search for default attributes. Even if we don't allow user to change >>> them, we should allow him to search them. >>> >>> 2) (also cosmetic) Given we have ipapermincludedattr described as >>> doc=_('User-specified attributes to which the permission applies'), >>> shouldn't we also describe ipapermexcludedattr as >>> doc=_('User-specified attributes to which the permission explicitly ' >>> 'does not apply'), >>> ? I think it would be more consistent. >>> >>> >>> Besides these 2 cosmetic issues, I think the new patchset works pretty nice - >>> good job! >> >> Thanks for the review, fixed. >> I've also fixed the search filter for --attrs, and added more tests for that. >> > > Looks good to me: > > # ipa permission-show testperm > Permission name: testperm > Permissions: write > Effective attributes: cn, o, sn > Included attributes: sn > Excluded attributes: l > Default attributes: l, o, cn > Bind rule type: all > Subtree: cn=users,cn=accounts,dc=example,dc=com > ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > Type: user > > ACK to all 5 patches (the last patch had 2-fuzz chunk). > > Martin > Thank you! Pushed to master: 3db08227e8c760c688b8886e0b3b072e9b6dd94d -- Petr? From npmccallum at redhat.com Wed Feb 12 16:49:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 12 Feb 2014 11:49:25 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches Message-ID: <1392223765.1816.4.camel@localhost.localdomain> Through the review process, patches are getting shifted around, added, deleted, etc. So I'm now just going to be posting all the patches as an ordered set. The set attached is ordered according to my preferred merge order. It also places easy to review patches up front. I hope this helps reviewers. This format will definitely help me manage the patches. The first three patches should be very easy reviews and can be merged independently. All current patch critiques have, to my knowledge, been addressed in this latest series of patches. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Add-HOTP-support.patch Type: text/x-patch Size: 20673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Add-libotp-internal-library-for-slapi-plugins.patch Type: text/x-patch Size: 33828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Enable-building-in-C99-mode.patch Type: text/x-patch Size: 2014 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-kdb-validate-that-an-OTP-user-has-tokens.patch Type: text/x-patch Size: 10158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Update-ACIs-to-permit-users-to-add-delete-their-own-.patch Type: text/x-patch Size: 4623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-generation-of-invalid-OTP-URIs.patch Type: text/x-patch Size: 1413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-OTP-token-names-labels.patch Type: text/x-patch Size: 1180 bytes Desc: not available URL: From jokajak at gmail.com Wed Feb 12 20:11:59 2014 From: jokajak at gmail.com (Josh) Date: Wed, 12 Feb 2014 15:11:59 -0500 Subject: [Freeipa-devel] [Freeipa-users] SELinux user categories In-Reply-To: <52FB4576.3000309@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <52FB3891.3070908@redhat.com> <52FB4576.3000309@redhat.com> Message-ID: <77AFAF34-F305-4A14-BAA0-D8D8FDCC7E45@gmail.com> On Feb 12, 2014, at 4:57 AM, Petr Viktorin wrote: > Moving to freeipa-devel since we're going rather deep. > > On 02/12/2014 10:02 AM, Martin Kosek wrote: >> On 02/11/2014 08:52 PM, Rob Crittenden wrote: >>> Josh wrote: >>>> >>>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >>> > wrote: >>>> >>>>> Josh wrote: >>>>>> I have a situation where I need to support more than 1024 categories >>>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>>> number of categories I need but ipa still responds with the original >>>>>> error message. Do I need to restart any of the services? >>>>>> >>>>>> Here is the command that was run and the output after applying the >>>>>> patch below: >>>>>> >>>>>> ipa config-mod >>>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>>> >>>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>>> >>>>> Have you updated your SELinux policy to support a larger MCS range? If >>>>> not then this will get you past the IPA validator but it won't work >>>>> with SELinux. See semanage(8). >>>>> >>>>> rob >>>> >>>> Yes. I?m trying to set the SELinux categories in freeipa because when >>>> you have lots of categories all semanage commands slow down (way down). >>>> For other people?s knowledge, this requires recompilation of the >>>> SELinux policy. >>> >>> Ok, then your patch looks reasonable. The current code is for the default >>> values and we haven't had cause to make this configurable before now. You might >>> consider filing a ticket in our trac about this. >>> >>> Also note that this change will be lost on your next IPA upgrade, and you'll >>> need to make this change on any IPA master you want these values to be managed. >>> The data will remain unchanged, but the original python values will be restored >>> if you update the packages. >>> >>> I don't believe validators are currently extensible in the IPA framework. That >>> might be something we need to look at as well. >>> >>> regards >>> >>> rob >> >> I am thinking you may be able to monkeypatch the validator in a custom plugin, >> like selinuxusermap-user.py which would: >> >> ~~~~ >> import ipalib.plugins.selinuxusermap( >> >> def custom_selinux_usermap_validator((ugettext, user): >> ... >> >> ipalib.plugins.selinuxusermap = custom_selinux_usermap_validator >> ~~~~ >> >> Then upgrade would not destroy the change. But of course, things may break as >> well if for example we change the params of this function. >> >> Martin > > No, I don't think something like that will work; the validator is baked into the Param on creation. You'd have to replace `selinuxusermap.takes_params` with a copy that has a new `ipaselinuxuser` Param. > I?m ok with the patch being removed on subsequent upgrades to the software. I only need the validator modified during the initial setup. After that the setting won?t need to be changed. -josh > > -- > Petr? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From pviktori at redhat.com Thu Feb 13 07:19:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Feb 2014 08:19:18 +0100 Subject: [Freeipa-devel] Incompatible schema change in master Message-ID: <52FC71F6.6040408@redhat.com> Hello, Commit 3db0822 (pushed yesterday) changes the schema in a way that will make schema upgrades from 445634d (2013-12-13) fail. If you have recently installed from git master, you will need to re-install IPA on that machine instead of upgrading. This does not affect any released versions of FreeIPA. -- Petr? From pviktori at redhat.com Thu Feb 13 12:12:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Feb 2014 13:12:14 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter Message-ID: <52FCB69E.4040104@redhat.com> Hello, These patches fix https://fedorahosted.org/freeipa/ticket/4074 Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions Since --type, affects only targetfilter values in the form "(objectclass=...)" and leaves others alone, and in the -mod command we don't fetch the existing entry until the pre_callback, I had to put the adds/removes in the context. I don't think the approach is too terrible given the limitations. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0464-permissions-Use-multivalued-targetfilter.patch Type: text/x-patch Size: 86021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0465-Add-permission_filter_objectclasses-for-explicit-typ.patch Type: text/x-patch Size: 11867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0466-Add-tests-for-multivalued-filters.patch Type: text/x-patch Size: 9086 bytes Desc: not available URL: From pviktori at redhat.com Thu Feb 13 12:41:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Feb 2014 13:41:13 +0100 Subject: [Freeipa-devel] [PATCH] 0467 permission plugin: Do not assume attribute-level rights for new attributes are present Message-ID: <52FCBD69.1000405@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/4121 Apply on top of my patches 0464-0466. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0467-permission-plugin-Do-not-assume-attribute-level-righ.patch Type: text/x-patch Size: 2059 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 13 13:12:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Feb 2014 15:12:53 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <20140213131253.GR8040@redhat.com> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >Through the review process, patches are getting shifted around, added, >deleted, etc. So I'm now just going to be posting all the patches as an >ordered set. The set attached is ordered according to my preferred merge >order. It also places easy to review patches up front. I hope this helps >reviewers. This format will definitely help me manage the patches. > >The first three patches should be very easy reviews and can be merged >independently. > >All current patch critiques have, to my knowledge, been addressed in >this latest series of patches. I have tested all the patches altogether, including Web UI patches, and everything works. I have set up a COPR repo for others to try: http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ However, there is one issue which I was not yet able to pin-point in the SLAPI plugins. During FreeIPA install and later on actual use I see these in the dirsrv error log: [13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter [13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL [13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter [13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL [13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 [13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter [13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL [13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter [13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL Additionally, when slapi-nis is enabled, LDAP bind with identity from compat tree fails for OTP use and succeeds for password authentication. In compat tree we are doing this trick: 1731 /* Otherwise force rewrite of the SLAPI_BIND_TARGET_SDN 1732 * and let other plugins to handle it. 1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ 1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); 1735 if (sdn != NULL) { 1736 slapi_sdn_free(&sdn); 1737 } 1738 sdn = slapi_sdn_new_dn_byref(ndn); 1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); 1740 ret = 0; 1741 } I tried to play with plugin precedence and it didn't really help. There is definitely a bug (or more) in ipa-pwd-extop in handling authentication cases. -- / Alexander Bokovoy From mkosek at redhat.com Thu Feb 13 13:33:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Feb 2014 14:33:01 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <527CAC7F.5070608@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> Message-ID: <52FCC98D.6090401@redhat.com> On 11/08/2013 10:18 AM, Martin Kosek wrote: > On 10/17/2013 12:04 PM, Martin Kosek wrote: >> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>> On 17.10.2013 03:06, Simo Sorce wrote: >>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>> also simplifies the section for both redhat and fedora variants. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>> >>>>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>>>> HTML output)? I think that people should see this option all the time. >>>>> >>>>> >>>>> This recalls me another thing: >>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This >>>>> should allow anyone to create ticket even without registration/logging in, >>>>> which lowers the barrier. >>>> >>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>> don't do it. >>>> >>>> Besides you wouldn't be able to notify the reporter that you need more >>>> info and so on, its not worth to have fire-and-forget reports. >>> >>> There is an input box for reporter's e-mail... >> >> Yeah, I wonder who would fill it. I would personally leave it as is, when >> someone really does not not want to register to Fedora, he can send a mail to >> freeipa-users (and thus also give as a way to ask back). >> >> Martin > > I hope that this question was resolved. As for "Report a bug" link on each page > footer, I am not sure if Publican can do that and I am also not sure if it > would not be disturbing. > > I would rather like to let us review the requested change and provided patch. > IMO the provided Trac/Bugzilla links makes the bug filing easier, which was the > point of the ticket - please review. > > Let us review the change and continue with other doc improvements, there is a > lot of those on our plate in this area. > > Martin This patch is stale - the doc patch is on the list, ready and waiting. Petr, if it is ok with you, let's ack&push it, if not and you have reasonable other proposal, let's do it. If you think the ticket does not make sense, let's close it. I just want to see some action and avoid having 4 months long thread for a minor improvement ticket. Martin From pspacek at redhat.com Thu Feb 13 17:36:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Feb 2014 18:36:55 +0100 Subject: [Freeipa-devel] DNSSEC design page Message-ID: <52FD02B7.3060404@redhat.com> Hello list, I would like to point you to design pages for DNSSEC feature: Zone signing: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC Automatic key rotation: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm You can ignore bind-dyndb-ldap specifics and think about interactions with FreeIPA and SSSD. - We need to design LDAP schema for key storage (Ludwig is looking into it). - We need to write PKCS#11 module on top of LDAP database. - We need to design key rotation on client side (SSSD? Certmonger?). - We need to design WebUI/CLI etc. Read sections 'External Impact' carefully :-) Have a nice day! -- Petr^2 Spacek From abokovoy at redhat.com Thu Feb 13 17:56:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Feb 2014 19:56:22 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <20140213175622.GA3496@redhat.com> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >Through the review process, patches are getting shifted around, added, >deleted, etc. So I'm now just going to be posting all the patches as an >ordered set. The set attached is ordered according to my preferred merge >order. It also places easy to review patches up front. I hope this helps >reviewers. This format will definitely help me manage the patches. > >The first three patches should be very easy reviews and can be merged >independently. > >All current patch critiques have, to my knowledge, been addressed in >this latest series of patches. 0001-Fix-OTP-token-names-labels.patch - ACK 0002-Fix-generation-of-invalid-OTP-URIs.patch - ACK 0003-Update-ACIs-to-permit-users-to-add.patch - ACK -- / Alexander Bokovoy From pviktori at redhat.com Thu Feb 13 18:45:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Feb 2014 19:45:43 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140213175622.GA3496@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213175622.GA3496@redhat.com> Message-ID: <52FD12D7.5080900@redhat.com> On 02/13/2014 06:56 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > > 0001-Fix-OTP-token-names-labels.patch - ACK > 0002-Fix-generation-of-invalid-OTP-URIs.patch - ACK > 0003-Update-ACIs-to-permit-users-to-add.patch - ACK > Pushed to master: a91c0972b992dbd15e78f2ba6982768ac958e4bd -- Petr? From pspacek at redhat.com Thu Feb 13 21:39:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Feb 2014 22:39:22 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <52FCC98D.6090401@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> <52FCC98D.6090401@redhat.com> Message-ID: <52FD3B8A.10905@redhat.com> On 13.2.2014 14:33, Martin Kosek wrote: > On 11/08/2013 10:18 AM, Martin Kosek wrote: >> On 10/17/2013 12:04 PM, Martin Kosek wrote: >>> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>>> On 17.10.2013 03:06, Simo Sorce wrote: >>>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>>> also simplifies the section for both redhat and fedora variants. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>>> >>>>>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>>>>> HTML output)? I think that people should see this option all the time. >>>>>> >>>>>> >>>>>> This recalls me another thing: >>>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This >>>>>> should allow anyone to create ticket even without registration/logging in, >>>>>> which lowers the barrier. >>>>> >>>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>>> don't do it. >>>>> >>>>> Besides you wouldn't be able to notify the reporter that you need more >>>>> info and so on, its not worth to have fire-and-forget reports. >>>> >>>> There is an input box for reporter's e-mail... >>> >>> Yeah, I wonder who would fill it. I would personally leave it as is, when >>> someone really does not not want to register to Fedora, he can send a mail to >>> freeipa-users (and thus also give as a way to ask back). >>> >>> Martin >> >> I hope that this question was resolved. As for "Report a bug" link on each page >> footer, I am not sure if Publican can do that and I am also not sure if it >> would not be disturbing. >> >> I would rather like to let us review the requested change and provided patch. >> IMO the provided Trac/Bugzilla links makes the bug filing easier, which was the >> point of the ticket - please review. >> >> Let us review the change and continue with other doc improvements, there is a >> lot of those on our plate in this area. >> >> Martin > > This patch is stale - the doc patch is on the list, ready and waiting. > > Petr, if it is ok with you, let's ack&push it, if not and you have reasonable > other proposal, let's do it. If you think the ticket does not make sense, let's > close it. I just want to see some action and avoid having 4 months long thread > for a minor improvement ticket. Sure, this have fallen through cracks. -- Petr^2 Spacek From rcritten at redhat.com Thu Feb 13 23:07:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 18:07:35 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52F89A5B.2090707@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> Message-ID: <52FD5037.10204@redhat.com> Martin Kosek wrote: > On 01/28/2014 09:35 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: > ... >>> The URL endpoint /ipa/rest suggests that if we implement a complete REST >>> API for IPA it would live here. Is the API supposed to be >>> future-compatible? (The API itself seems to be a good subset of a >>> complete REST API, but can we easily add an frontend with >>> authentication, i18n, etc. here later, and keep the limitations for >>> unauthenticated access?) >>> Perhaps /ipa/smartproxy would be a better choice? >> >> It was future-proofing. I'm fine with changing the URI, it is probably a good >> thing to save that name. > > +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface > in ipa/rest/ in the future. I rather opened a ticket to track that: > > https://fedorahosted.org/freeipa/ticket/4168 > > Martin > I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-3-rest.patch Type: text/x-patch Size: 43750 bytes Desc: not available URL: From dpal at redhat.com Thu Feb 13 23:49:56 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 18:49:56 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD5037.10204@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> Message-ID: <52FD5A24.4010601@redhat.com> On 02/13/2014 06:07 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >> ... >>>> The URL endpoint /ipa/rest suggests that if we implement a complete >>>> REST >>>> API for IPA it would live here. Is the API supposed to be >>>> future-compatible? (The API itself seems to be a good subset of a >>>> complete REST API, but can we easily add an frontend with >>>> authentication, i18n, etc. here later, and keep the limitations for >>>> unauthenticated access?) >>>> Perhaps /ipa/smartproxy would be a better choice? >>> >>> It was future-proofing. I'm fine with changing the URI, it is >>> probably a good >>> thing to save that name. >> >> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >> interface >> in ipa/rest/ in the future. I rather opened a ticket to track that: >> >> https://fedorahosted.org/freeipa/ticket/4168 >> >> Martin >> > > I think I've addressed most of Petr's suggestions with the exception > of the global ipa handle and I stuck with *args, **options as this is > pretty much standard in IPA calls. > > The gssproxy.conf.snippet just makes it easier to copy/paste. I can > drop it if you want, I suppose it is duplication. > > Note that I ran this past the Foreman design again and as a result > added another interface, /realm. It was my understanding that this > Foreman design wasn't set into stone but a patch is working its way > through their system that followed the spec so I went ahead and added > it. It isn't a big deal, the Host() class handles it out of the box. > > I also updated the design page a bit to reflect some of the changes made. > > Right now there are no plans to backport python-kerberos to F20. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 14 02:02:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 21:02:56 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD5A24.4010601@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FD5A24.4010601@redhat.com> Message-ID: <52FD7950.1020006@redhat.com> Dmitri Pal wrote: > On 02/13/2014 06:07 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>> ... >>>>> The URL endpoint /ipa/rest suggests that if we implement a complete >>>>> REST >>>>> API for IPA it would live here. Is the API supposed to be >>>>> future-compatible? (The API itself seems to be a good subset of a >>>>> complete REST API, but can we easily add an frontend with >>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>> unauthenticated access?) >>>>> Perhaps /ipa/smartproxy would be a better choice? >>>> >>>> It was future-proofing. I'm fine with changing the URI, it is >>>> probably a good >>>> thing to save that name. >>> >>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>> interface >>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>> >>> https://fedorahosted.org/freeipa/ticket/4168 >>> >>> Martin >>> >> >> I think I've addressed most of Petr's suggestions with the exception >> of the global ipa handle and I stuck with *args, **options as this is >> pretty much standard in IPA calls. >> >> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >> drop it if you want, I suppose it is duplication. >> >> Note that I ran this past the Foreman design again and as a result >> added another interface, /realm. It was my understanding that this >> Foreman design wasn't set into stone but a patch is working its way >> through their system that followed the spec so I went ahead and added >> it. It isn't a big deal, the Host() class handles it out of the box. >> >> I also updated the design page a bit to reflect some of the changes made. >> >> Right now there are no plans to backport python-kerberos to F20. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Recently we had a ticket in SSSD > https://fedorahosted.org/sssd/ticket/2217 > Should we have a similar one for IPA client and especially for the proxy? > Proxy will be a long term running process so dealing with the stale > tickets becomes important for it if replica is re-installed. Is it > something that is solved in API level or on the proxy level? > Should we have a separate ticket for that? Using gss-proxy so it's not our problem. We never touch tickets. rob From dpal at redhat.com Fri Feb 14 02:17:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 21:17:35 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD7950.1020006@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FD5A24.4010601@redhat.com> <52FD7950.1020006@redhat.com> Message-ID: <52FD7CBF.6090706@redhat.com> On 02/13/2014 09:02 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/13/2014 06:07 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>> ... >>>>>> The URL endpoint /ipa/rest suggests that if we implement a complete >>>>>> REST >>>>>> API for IPA it would live here. Is the API supposed to be >>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>> complete REST API, but can we easily add an frontend with >>>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>>> unauthenticated access?) >>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>> >>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>> probably a good >>>>> thing to save that name. >>>> >>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>> interface >>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4168 >>>> >>>> Martin >>>> >>> >>> I think I've addressed most of Petr's suggestions with the exception >>> of the global ipa handle and I stuck with *args, **options as this is >>> pretty much standard in IPA calls. >>> >>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>> drop it if you want, I suppose it is duplication. >>> >>> Note that I ran this past the Foreman design again and as a result >>> added another interface, /realm. It was my understanding that this >>> Foreman design wasn't set into stone but a patch is working its way >>> through their system that followed the spec so I went ahead and added >>> it. It isn't a big deal, the Host() class handles it out of the box. >>> >>> I also updated the design page a bit to reflect some of the changes >>> made. >>> >>> Right now there are no plans to backport python-kerberos to F20. >>> >>> rob >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Recently we had a ticket in SSSD >> https://fedorahosted.org/sssd/ticket/2217 >> Should we have a similar one for IPA client and especially for the >> proxy? >> Proxy will be a long term running process so dealing with the stale >> tickets becomes important for it if replica is re-installed. Is it >> something that is solved in API level or on the proxy level? >> Should we have a separate ticket for that? > > Using gss-proxy so it's not our problem. We never touch tickets. > > rob > Does gss proxy solve this problem? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Fri Feb 14 08:25:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 09:25:33 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <52FD3B8A.10905@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> <52FCC98D.6090401@redhat.com> <52FD3B8A.10905@redhat.com> Message-ID: <52FDD2FD.6090409@redhat.com> On 13.2.2014 22:39, Petr Spacek wrote: > On 13.2.2014 14:33, Martin Kosek wrote: >> On 11/08/2013 10:18 AM, Martin Kosek wrote: >>> On 10/17/2013 12:04 PM, Martin Kosek wrote: >>>> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>>>> On 17.10.2013 03:06, Simo Sorce wrote: >>>>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>>>> also simplifies the section for both redhat and fedora variants. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>>>> >>>>>>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>>>>>> HTML output)? I think that people should see this option all the time. >>>>>>> >>>>>>> >>>>>>> This recalls me another thing: >>>>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the >>>>>>> Trac? This >>>>>>> should allow anyone to create ticket even without registration/logging in, >>>>>>> which lowers the barrier. >>>>>> >>>>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>>>> don't do it. >>>>>> >>>>>> Besides you wouldn't be able to notify the reporter that you need more >>>>>> info and so on, its not worth to have fire-and-forget reports. >>>>> >>>>> There is an input box for reporter's e-mail... >>>> >>>> Yeah, I wonder who would fill it. I would personally leave it as is, when >>>> someone really does not not want to register to Fedora, he can send a mail to >>>> freeipa-users (and thus also give as a way to ask back). >>>> >>>> Martin >>> >>> I hope that this question was resolved. As for "Report a bug" link on each >>> page >>> footer, I am not sure if Publican can do that and I am also not sure if it >>> would not be disturbing. >>> >>> I would rather like to let us review the requested change and provided patch. >>> IMO the provided Trac/Bugzilla links makes the bug filing easier, which was >>> the >>> point of the ticket - please review. >>> >>> Let us review the change and continue with other doc improvements, there is a >>> lot of those on our plate in this area. >>> >>> Martin >> >> This patch is stale - the doc patch is on the list, ready and waiting. >> >> Petr, if it is ok with you, let's ack&push it, if not and you have reasonable >> other proposal, let's do it. If you think the ticket does not make sense, let's >> close it. I just want to see some action and avoid having 4 months long thread >> for a minor improvement ticket. > > Sure, this have fallen through cracks. ACK -- Petr^2 Spacek From mkosek at redhat.com Fri Feb 14 08:30:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 09:30:38 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <52FDD2FD.6090409@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> <52FCC98D.6090401@redhat.com> <52FD3B8A.10905@redhat.com> <52FDD2FD.6090409@redhat.com> Message-ID: <52FDD42E.2020303@redhat.com> On 02/14/2014 09:25 AM, Petr Spacek wrote: > On 13.2.2014 22:39, Petr Spacek wrote: >> On 13.2.2014 14:33, Martin Kosek wrote: >>> On 11/08/2013 10:18 AM, Martin Kosek wrote: >>>> On 10/17/2013 12:04 PM, Martin Kosek wrote: >>>>> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>>>>> On 17.10.2013 03:06, Simo Sorce wrote: >>>>>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>>>>> also simplifies the section for both redhat and fedora variants. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>>>>> >>>>>>>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>>>>>>> HTML output)? I think that people should see this option all the time. >>>>>>>> >>>>>>>> >>>>>>>> This recalls me another thing: >>>>>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the >>>>>>>> Trac? This >>>>>>>> should allow anyone to create ticket even without registration/logging in, >>>>>>>> which lowers the barrier. >>>>>>> >>>>>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>>>>> don't do it. >>>>>>> >>>>>>> Besides you wouldn't be able to notify the reporter that you need more >>>>>>> info and so on, its not worth to have fire-and-forget reports. >>>>>> >>>>>> There is an input box for reporter's e-mail... >>>>> >>>>> Yeah, I wonder who would fill it. I would personally leave it as is, when >>>>> someone really does not not want to register to Fedora, he can send a mail to >>>>> freeipa-users (and thus also give as a way to ask back). >>>>> >>>>> Martin >>>> >>>> I hope that this question was resolved. As for "Report a bug" link on each >>>> page >>>> footer, I am not sure if Publican can do that and I am also not sure if it >>>> would not be disturbing. >>>> >>>> I would rather like to let us review the requested change and provided patch. >>>> IMO the provided Trac/Bugzilla links makes the bug filing easier, which was >>>> the >>>> point of the ticket - please review. >>>> >>>> Let us review the change and continue with other doc improvements, there is a >>>> lot of those on our plate in this area. >>>> >>>> Martin >>> >>> This patch is stale - the doc patch is on the list, ready and waiting. >>> >>> Petr, if it is ok with you, let's ack&push it, if not and you have reasonable >>> other proposal, let's do it. If you think the ticket does not make sense, let's >>> close it. I just want to see some action and avoid having 4 months long thread >>> for a minor improvement ticket. >> >> Sure, this have fallen through cracks. > > ACK > Thanks. Pushed to master. Martin From mkosek at redhat.com Fri Feb 14 08:43:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 09:43:57 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD5037.10204@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> Message-ID: <52FDD74D.3050504@redhat.com> On 02/14/2014 12:07 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >> ... >>>> The URL endpoint /ipa/rest suggests that if we implement a complete REST >>>> API for IPA it would live here. Is the API supposed to be >>>> future-compatible? (The API itself seems to be a good subset of a >>>> complete REST API, but can we easily add an frontend with >>>> authentication, i18n, etc. here later, and keep the limitations for >>>> unauthenticated access?) >>>> Perhaps /ipa/smartproxy would be a better choice? >>> >>> It was future-proofing. I'm fine with changing the URI, it is probably a good >>> thing to save that name. >> >> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface >> in ipa/rest/ in the future. I rather opened a ticket to track that: >> >> https://fedorahosted.org/freeipa/ticket/4168 >> >> Martin >> > > I think I've addressed most of Petr's suggestions with the exception of the > global ipa handle and I stuck with *args, **options as this is pretty much > standard in IPA calls. > > The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if > you want, I suppose it is duplication. > > Note that I ran this past the Foreman design again and as a result added > another interface, /realm. It was my understanding that this Foreman design > wasn't set into stone but a patch is working its way through their system that > followed the spec so I went ahead and added it. It isn't a big deal, the Host() > class handles it out of the box. > > I also updated the design page a bit to reflect some of the changes made. > > Right now there are no plans to backport python-kerberos to F20. > > rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and "branding" of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as "IPA REST server". This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin From pviktori at redhat.com Fri Feb 14 08:45:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 09:45:03 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <52FDD42E.2020303@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> <52FCC98D.6090401@redhat.com> <52FD3B8A.10905@redhat.com> <52FDD2FD.6090409@redhat.com> <52FDD42E.2020303@redhat.com> Message-ID: <52FDD78F.8060504@redhat.com> On 02/14/2014 09:30 AM, Martin Kosek wrote: > On 02/14/2014 09:25 AM, Petr Spacek wrote: >> On 13.2.2014 22:39, Petr Spacek wrote: >>> On 13.2.2014 14:33, Martin Kosek wrote: >>>> On 11/08/2013 10:18 AM, Martin Kosek wrote: >>>>> On 10/17/2013 12:04 PM, Martin Kosek wrote: >>>>>> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>>>>>> On 17.10.2013 03:06, Simo Sorce wrote: >>>>>>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>>>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>>>>>> also simplifies the section for both redhat and fedora variants. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>>>>>> >>>>>>>>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>>>>>>>> HTML output)? I think that people should see this option all the time. >>>>>>>>> >>>>>>>>> >>>>>>>>> This recalls me another thing: >>>>>>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the >>>>>>>>> Trac? This >>>>>>>>> should allow anyone to create ticket even without registration/logging in, >>>>>>>>> which lowers the barrier. >>>>>>>> >>>>>>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>>>>>> don't do it. >>>>>>>> >>>>>>>> Besides you wouldn't be able to notify the reporter that you need more >>>>>>>> info and so on, its not worth to have fire-and-forget reports. >>>>>>> >>>>>>> There is an input box for reporter's e-mail... >>>>>> >>>>>> Yeah, I wonder who would fill it. I would personally leave it as is, when >>>>>> someone really does not not want to register to Fedora, he can send a mail to >>>>>> freeipa-users (and thus also give as a way to ask back). >>>>>> >>>>>> Martin >>>>> >>>>> I hope that this question was resolved. As for "Report a bug" link on each >>>>> page >>>>> footer, I am not sure if Publican can do that and I am also not sure if it >>>>> would not be disturbing. >>>>> >>>>> I would rather like to let us review the requested change and provided patch. >>>>> IMO the provided Trac/Bugzilla links makes the bug filing easier, which was >>>>> the >>>>> point of the ticket - please review. >>>>> >>>>> Let us review the change and continue with other doc improvements, there is a >>>>> lot of those on our plate in this area. >>>>> >>>>> Martin >>>> >>>> This patch is stale - the doc patch is on the list, ready and waiting. >>>> >>>> Petr, if it is ok with you, let's ack&push it, if not and you have reasonable >>>> other proposal, let's do it. If you think the ticket does not make sense, let's >>>> close it. I just want to see some action and avoid having 4 months long thread >>>> for a minor improvement ticket. >>> >>> Sure, this have fallen through cracks. >> >> ACK >> > > Thanks. Pushed to master. > I see you didn't add a Reviewed-By tag. Shouldn't we use it in the docs well? -- Petr? From mkosek at redhat.com Fri Feb 14 08:50:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 09:50:46 +0100 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <52FDD78F.8060504@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> <525FB629.1090403@redhat.com> <527CAC7F.5070608@redhat.com> <52FCC98D.6090401@redhat.com> <52FD3B8A.10905@redhat.com> <52FDD2FD.6090409@redhat.com> <52FDD42E.2020303@redhat.com> <52FDD78F.8060504@redhat.com> Message-ID: <52FDD8E6.4030400@redhat.com> On 02/14/2014 09:45 AM, Petr Viktorin wrote: > On 02/14/2014 09:30 AM, Martin Kosek wrote: >> On 02/14/2014 09:25 AM, Petr Spacek wrote: >>> On 13.2.2014 22:39, Petr Spacek wrote: >>>> On 13.2.2014 14:33, Martin Kosek wrote: >>>>> On 11/08/2013 10:18 AM, Martin Kosek wrote: >>>>>> On 10/17/2013 12:04 PM, Martin Kosek wrote: >>>>>>> On 10/17/2013 07:25 AM, Petr Spacek wrote: >>>>>>>> On 17.10.2013 03:06, Simo Sorce wrote: >>>>>>>>> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>>>>>>>>> On 16.10.2013 15:31, Martin Kosek wrote: >>>>>>>>>>> This change should enable faster and easier filing of new bugs. Patch >>>>>>>>>>> also simplifies the section for both redhat and fedora variants. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3754 >>>>>>>>>> >>>>>>>>>> Hmm, is there a way to add the "Report a bug" link to each page >>>>>>>>>> footer (in >>>>>>>>>> HTML output)? I think that people should see this option all the time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This recalls me another thing: >>>>>>>>>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the >>>>>>>>>> Trac? This >>>>>>>>>> should allow anyone to create ticket even without >>>>>>>>>> registration/logging in, >>>>>>>>>> which lowers the barrier. >>>>>>>>> >>>>>>>>> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >>>>>>>>> don't do it. >>>>>>>>> >>>>>>>>> Besides you wouldn't be able to notify the reporter that you need more >>>>>>>>> info and so on, its not worth to have fire-and-forget reports. >>>>>>>> >>>>>>>> There is an input box for reporter's e-mail... >>>>>>> >>>>>>> Yeah, I wonder who would fill it. I would personally leave it as is, when >>>>>>> someone really does not not want to register to Fedora, he can send a >>>>>>> mail to >>>>>>> freeipa-users (and thus also give as a way to ask back). >>>>>>> >>>>>>> Martin >>>>>> >>>>>> I hope that this question was resolved. As for "Report a bug" link on each >>>>>> page >>>>>> footer, I am not sure if Publican can do that and I am also not sure if it >>>>>> would not be disturbing. >>>>>> >>>>>> I would rather like to let us review the requested change and provided >>>>>> patch. >>>>>> IMO the provided Trac/Bugzilla links makes the bug filing easier, which was >>>>>> the >>>>>> point of the ticket - please review. >>>>>> >>>>>> Let us review the change and continue with other doc improvements, there >>>>>> is a >>>>>> lot of those on our plate in this area. >>>>>> >>>>>> Martin >>>>> >>>>> This patch is stale - the doc patch is on the list, ready and waiting. >>>>> >>>>> Petr, if it is ok with you, let's ack&push it, if not and you have reasonable >>>>> other proposal, let's do it. If you think the ticket does not make sense, >>>>> let's >>>>> close it. I just want to see some action and avoid having 4 months long >>>>> thread >>>>> for a minor improvement ticket. >>>> >>>> Sure, this have fallen through cracks. >>> >>> ACK >>> >> >> Thanks. Pushed to master. >> > > I see you didn't add a Reviewed-By tag. Shouldn't we use it in the docs well? Good question. So far, we only agreed to use it for the FreeIPA git. If we see value in using it for doc as well, then why not. Martin From jcholast at redhat.com Fri Feb 14 10:03:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 14 Feb 2014 11:03:24 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FD02B7.3060404@redhat.com> References: <52FD02B7.3060404@redhat.com> Message-ID: <52FDE9EC.3040901@redhat.com> Hi, On 13.2.2014 18:36, Petr Spacek wrote: > Hello list, > > I would like to point you to design pages for DNSSEC feature: > > Zone signing: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC > > Automatic key rotation: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm > > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm > > > > You can ignore bind-dyndb-ldap specifics and think about interactions > with FreeIPA and SSSD. > > - We need to design LDAP schema for key storage (Ludwig is looking into > it). Keep in mind the schema has to work with or be extensible enough for other uses as well, ATM at least IPA CA certificate storage. IMO the easiest (from the PKCS#11 module writing perspective) way to do it would be to map PKCS#11 object classes and attributes directly to LDAP object classes and attributes, but that might be too much low-level for us. > - We need to write PKCS#11 module on top of LDAP database. SSSD. > - We need to design key rotation on client side (SSSD? Certmonger?). Also SSSD. I thought we already agreed on that last week? > - We need to design WebUI/CLI > etc. > > Read sections 'External Impact' carefully :-) > > Have a nice day! > Honza -- Jan Cholasta From pviktori at redhat.com Fri Feb 14 11:02:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 12:02:41 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD5037.10204@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> Message-ID: <52FDF7D1.7040105@redhat.com> On 02/14/2014 12:07 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >> ... >>>> The URL endpoint /ipa/rest suggests that if we implement a complete >>>> REST >>>> API for IPA it would live here. Is the API supposed to be >>>> future-compatible? (The API itself seems to be a good subset of a >>>> complete REST API, but can we easily add an frontend with >>>> authentication, i18n, etc. here later, and keep the limitations for >>>> unauthenticated access?) >>>> Perhaps /ipa/smartproxy would be a better choice? >>> >>> It was future-proofing. I'm fine with changing the URI, it is >>> probably a good >>> thing to save that name. >> >> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >> interface >> in ipa/rest/ in the future. I rather opened a ticket to track that: >> >> https://fedorahosted.org/freeipa/ticket/4168 >> >> Martin >> > > I think I've addressed most of Petr's suggestions with the exception of > the global ipa handle and I stuck with *args, **options as this is > pretty much standard in IPA calls. Well, I can't have everything :) Here's some quick feedback. > The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop > it if you want, I suppose it is duplication. Please do. It's not discoverable at all. Anyone can copy it from the man page and keep it around. > Note that I ran this past the Foreman design again and as a result added > another interface, /realm. It was my understanding that this Foreman > design wasn't set into stone but a patch is working its way through > their system that followed the spec so I went ahead and added it. It > isn't a big deal, the Host() class handles it out of the box. > > I also updated the design page a bit to reflect some of the changes made. > > Right now there are no plans to backport python-kerberos to F20. Not even in a COPR? So if this goes in, all developers would need to switch to Rawhide. I'm not sure we're prepared for that yet. > rob Currently we return this for errors in JSON: { "error": { "code": 4002, "message": "user with name \\"admin\\" already exists", "name": "DuplicateEntry" }, "id": 0, "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", "result": null, "version": "3.3.90GIT8e26acb" } It would be more consitent if we used the same "error" dict also for REST. The default port, 8090, is still not documented. -- Petr? From pspacek at redhat.com Fri Feb 14 11:08:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 12:08:04 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FDE9EC.3040901@redhat.com> References: <52FD02B7.3060404@redhat.com> <52FDE9EC.3040901@redhat.com> Message-ID: <52FDF914.9040605@redhat.com> On 14.2.2014 11:03, Jan Cholasta wrote: > On 13.2.2014 18:36, Petr Spacek wrote: >> Hello list, >> >> I would like to point you to design pages for DNSSEC feature: >> >> Zone signing: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC >> >> Automatic key rotation: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >> >> >> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >> >> >> >> You can ignore bind-dyndb-ldap specifics and think about interactions >> with FreeIPA and SSSD. >> >> - We need to design LDAP schema for key storage (Ludwig is looking into >> it). > > Keep in mind the schema has to work with or be extensible enough for other > uses as well, ATM at least IPA CA certificate storage. Feel free to extend the design page as necessary. May be that we should create separate design page specifically for this PKCS#11 module. In fact, it is not related to DNSSEC at all. We just need to add some DNSSEC-specific meta data to keys, nothing else. > IMO the easiest (from the PKCS#11 module writing perspective) way to do it > would be to map PKCS#11 object classes and attributes directly to LDAP object > classes and attributes, but that might be too much low-level for us. > >> - We need to write PKCS#11 module on top of LDAP database. > > SSSD. > >> - We need to design key rotation on client side (SSSD? Certmonger?). > > Also SSSD. > > I thought we already agreed on that last week? Last idea I have heard was about certmonger - Dmitri thought that Certmonger already have all the necessary logic. In any case, nothing is set in stone. We have to discuss pros and cons and then decide. Keep in mind that we have to support key rotation even if the key was compromised ... (Fallback from RFC 5011 to Kerberos+LDAP or something like that.) >> - We need to design WebUI/CLI >> etc. >> >> Read sections 'External Impact' carefully :-) >> >> Have a nice day! -- Petr^2 Spacek From jcholast at redhat.com Fri Feb 14 11:27:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 14 Feb 2014 12:27:45 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FDF914.9040605@redhat.com> References: <52FD02B7.3060404@redhat.com> <52FDE9EC.3040901@redhat.com> <52FDF914.9040605@redhat.com> Message-ID: <52FDFDB1.60700@redhat.com> On 14.2.2014 12:08, Petr Spacek wrote: > On 14.2.2014 11:03, Jan Cholasta wrote: >> On 13.2.2014 18:36, Petr Spacek wrote: >>> Hello list, >>> >>> I would like to point you to design pages for DNSSEC feature: >>> >>> Zone signing: >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC >>> >>> Automatic key rotation: >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>> >>> >>> >>> >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>> >>> >>> >>> >>> You can ignore bind-dyndb-ldap specifics and think about interactions >>> with FreeIPA and SSSD. >>> >>> - We need to design LDAP schema for key storage (Ludwig is looking into >>> it). >> >> Keep in mind the schema has to work with or be extensible enough for >> other >> uses as well, ATM at least IPA CA certificate storage. > > Feel free to extend the design page as necessary. May be that we should > create separate design page specifically for this PKCS#11 module. +1 > > In fact, it is not related to DNSSEC at all. We just need to add some > DNSSEC-specific meta data to keys, nothing else. My point exactly. > >> IMO the easiest (from the PKCS#11 module writing perspective) way to >> do it >> would be to map PKCS#11 object classes and attributes directly to LDAP >> object >> classes and attributes, but that might be too much low-level for us. >> >>> - We need to write PKCS#11 module on top of LDAP database. >> >> SSSD. >> >>> - We need to design key rotation on client side (SSSD? Certmonger?). >> >> Also SSSD. >> >> I thought we already agreed on that last week? > > Last idea I have heard was about certmonger - Dmitri thought that > Certmonger already have all the necessary logic. It does not, for starters there is no LDAP or caching. If anything, it might be a combination of both, but I think that's more relevant to CA certificate rotation than DNSSEC. > > In any case, nothing is set in stone. We have to discuss pros and cons > and then decide. Obviously :-) > > Keep in mind that we have to support key rotation even if the key was > compromised ... (Fallback from RFC 5011 to Kerberos+LDAP or something > like that.) I don't see how this gives advantage to either SSSD or certmonger. > >>> - We need to design WebUI/CLI >>> etc. >>> >>> Read sections 'External Impact' carefully :-) >>> >>> Have a nice day! > -- Jan Cholasta From pspacek at redhat.com Fri Feb 14 11:37:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 12:37:24 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FDFDB1.60700@redhat.com> References: <52FD02B7.3060404@redhat.com> <52FDE9EC.3040901@redhat.com> <52FDF914.9040605@redhat.com> <52FDFDB1.60700@redhat.com> Message-ID: <52FDFFF4.2030105@redhat.com> On 14.2.2014 12:27, Jan Cholasta wrote: > On 14.2.2014 12:08, Petr Spacek wrote: >> On 14.2.2014 11:03, Jan Cholasta wrote: >>> On 13.2.2014 18:36, Petr Spacek wrote: >>>> Hello list, >>>> >>>> I would like to point you to design pages for DNSSEC feature: >>>> >>>> Zone signing: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC >>>> >>>> Automatic key rotation: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>>> >>>> >>>> >>>> >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>>> >>>> >>>> >>>> >>>> >>>> You can ignore bind-dyndb-ldap specifics and think about interactions >>>> with FreeIPA and SSSD. >>>> >>>> - We need to design LDAP schema for key storage (Ludwig is looking into >>>> it). >>> >>> Keep in mind the schema has to work with or be extensible enough for >>> other >>> uses as well, ATM at least IPA CA certificate storage. >> >> Feel free to extend the design page as necessary. May be that we should >> create separate design page specifically for this PKCS#11 module. > > +1 Will you create the design page? I have enjoyed it with DNSSEC and now I would like to spend some time with coding ... :-) http://www.freeipa.org/page/Feature_template >> In fact, it is not related to DNSSEC at all. We just need to add some >> DNSSEC-specific meta data to keys, nothing else. > > My point exactly. > >> >>> IMO the easiest (from the PKCS#11 module writing perspective) way to >>> do it >>> would be to map PKCS#11 object classes and attributes directly to LDAP >>> object >>> classes and attributes, but that might be too much low-level for us. >>> >>>> - We need to write PKCS#11 module on top of LDAP database. >>> >>> SSSD. >>> >>>> - We need to design key rotation on client side (SSSD? Certmonger?). >>> >>> Also SSSD. >>> >>> I thought we already agreed on that last week? >> >> Last idea I have heard was about certmonger - Dmitri thought that >> Certmonger already have all the necessary logic. > > It does not, for starters there is no LDAP or caching. If anything, it might > be a combination of both, but I think that's more relevant to CA certificate > rotation than DNSSEC. > >> >> In any case, nothing is set in stone. We have to discuss pros and cons >> and then decide. > > Obviously :-) > >> >> Keep in mind that we have to support key rotation even if the key was >> compromised ... (Fallback from RFC 5011 to Kerberos+LDAP or something >> like that.) > > I don't see how this gives advantage to either SSSD or certmonger. Sure, I'm just pointing it out so we are all aware of this problem. >>>> - We need to design WebUI/CLI >>>> etc. >>>> >>>> Read sections 'External Impact' carefully :-) >>>> >>>> Have a nice day! -- Petr^2 Spacek From abokovoy at redhat.com Fri Feb 14 11:37:43 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Feb 2014 13:37:43 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <20140214113743.GB3496@redhat.com> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >Through the review process, patches are getting shifted around, added, >deleted, etc. So I'm now just going to be posting all the patches as an >ordered set. The set attached is ordered according to my preferred merge >order. It also places easy to review patches up front. I hope this helps >reviewers. This format will definitely help me manage the patches. > >The first three patches should be very easy reviews and can be merged >independently. > >All current patch critiques have, to my knowledge, been addressed in >this latest series of patches. ACK for 0004-ipa-kdb-validate-that-an-OTP-user-has-tokens.patch -- / Alexander Bokovoy From abokovoy at redhat.com Fri Feb 14 11:39:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Feb 2014 13:39:54 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <20140214113954.GC3496@redhat.com> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >Through the review process, patches are getting shifted around, added, >deleted, etc. So I'm now just going to be posting all the patches as an >ordered set. The set attached is ordered according to my preferred merge >order. It also places easy to review patches up front. I hope this helps >reviewers. This format will definitely help me manage the patches. > >The first three patches should be very easy reviews and can be merged >independently. > >All current patch critiques have, to my knowledge, been addressed in >this latest series of patches. ACK for 0005-Enable-building-in-C99-mode.patch We may want to further improve setting -Werror after compiler was set up in configure, but I'm not really sure it is needed at this point. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Feb 14 12:13:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Feb 2014 14:13:53 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <20140214121353.GD3496@redhat.com> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >Through the review process, patches are getting shifted around, added, >deleted, etc. So I'm now just going to be posting all the patches as an >ordered set. The set attached is ordered according to my preferred merge >order. It also places easy to review patches up front. I hope this helps >reviewers. This format will definitely help me manage the patches. > >The first three patches should be very easy reviews and can be merged >independently. > >All current patch critiques have, to my knowledge, been addressed in >this latest series of patches. ACK for 0006-Add-libotp-internal-library-for-slapi-plugins.patch Should we pay attention to changing default from SHA-1 algo to SHA-2 family (SHA-256, SHA-384, SHA-512)? -- / Alexander Bokovoy From pspacek at redhat.com Fri Feb 14 13:51:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 14:51:54 +0100 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) Message-ID: <52FE1F7A.8030206@redhat.com> Hello, I have got an silly idea to use TPM (Trusted Platform Module) as backend for Keytab storage (via GSS-Proxy). GSS-Proxy prevents application from accessing key material, right? So GSS-Proxy could theoretically store keys in TPM and application wouldn't notice any difference, right? We have libraries for that in Fedora already: https://admin.fedoraproject.org/pkgdb/acls/name/trousers Even sillier idea is to use TPM as a PKCS#11 module: http://trousers.sourceforge.net/pkcs11.html I have no idea what the use case could be ... :-) May be as a "cache" for PKCS#11 module in SSSD? As I said, it is just a silly idea. -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 14 14:10:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 15:10:09 +0100 Subject: [Freeipa-devel] [PATCH 0012] tests: Move zone enable/disable tests to end of test_dns_plugin.p Message-ID: <52FE23C1.1040906@redhat.com> Hello, This patch prevents the test suite from hitting limitations in bind-dyndb-ldap 4.0. It should go to 3.4 (master branch, right?). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0012-tests-Move-zone-enable-disable-tests-to-end-of-test_.patch Type: text/x-patch Size: 6338 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 14 14:29:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 15:29:02 +0100 Subject: [Freeipa-devel] [PATCH 0012] tests: Move zone enable/disable tests to end of test_dns_plugin.p In-Reply-To: <52FE23C1.1040906@redhat.com> References: <52FE23C1.1040906@redhat.com> Message-ID: <52FE282E.1090006@redhat.com> On 02/14/2014 03:10 PM, Petr Spacek wrote: > Hello, > > This patch prevents the test suite from hitting limitations > in bind-dyndb-ldap 4.0. > > It should go to 3.4 (master branch, right?). Tests still pass, but the commit message is not very informative. Could you explain/link to what kind of limitations this avoids? -- Petr? From pspacek at redhat.com Fri Feb 14 14:52:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Feb 2014 15:52:43 +0100 Subject: [Freeipa-devel] [PATCH 0012] tests: Move zone enable/disable tests to end of test_dns_plugin.p In-Reply-To: <52FE282E.1090006@redhat.com> References: <52FE23C1.1040906@redhat.com> <52FE282E.1090006@redhat.com> Message-ID: <52FE2DBB.3050808@redhat.com> On 14.2.2014 15:29, Petr Viktorin wrote: > On 02/14/2014 03:10 PM, Petr Spacek wrote: >> Hello, >> >> This patch prevents the test suite from hitting limitations >> in bind-dyndb-ldap 4.0. >> >> It should go to 3.4 (master branch, right?). > > Tests still pass, but the commit message is not very informative. Could you > explain/link to what kind of limitations this avoids? Good point. Could you add this before push? https://fedorahosted.org/bind-dyndb-ldap/ticket/127 Thank you! -- Petr^2 Spacek From pviktori at redhat.com Fri Feb 14 15:04:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 16:04:06 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140214121353.GD3496@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140214121353.GD3496@redhat.com> Message-ID: <52FE3066.6090105@redhat.com> On 02/14/2014 01:13 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > ACK for 0006-Add-libotp-internal-library-for-slapi-plugins.patch > > Should we pay attention to changing default from SHA-1 algo to SHA-2 > family (SHA-256, SHA-384, SHA-512)? > > Pushed to master: 93d99c92b31adda35804868116b967c5e8d391b8 -- Petr? From pviktori at redhat.com Fri Feb 14 15:04:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 16:04:23 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140214113954.GC3496@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140214113954.GC3496@redhat.com> Message-ID: <52FE3077.2020206@redhat.com> On 02/14/2014 12:39 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > ACK for 0005-Enable-building-in-C99-mode.patch > > We may want to further improve setting -Werror after compiler was set up > in configure, but I'm not really sure it is needed at this point. > Pushed to master: 5c299758b9d26c4d233f49b92e18c558558dea5c -- Petr? From pviktori at redhat.com Fri Feb 14 15:04:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 16:04:40 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140214113743.GB3496@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140214113743.GB3496@redhat.com> Message-ID: <52FE3088.8060700@redhat.com> On 02/14/2014 12:37 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > ACK for 0004-ipa-kdb-validate-that-an-OTP-user-has-tokens.patch > Pushed to master: fd55da9a27f76611b01c38c2741c13652d6a3e60 -- Petr? From pviktori at redhat.com Fri Feb 14 15:08:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Feb 2014 16:08:07 +0100 Subject: [Freeipa-devel] [PATCH 0012] tests: Move zone enable/disable tests to end of test_dns_plugin.p In-Reply-To: <52FE2DBB.3050808@redhat.com> References: <52FE23C1.1040906@redhat.com> <52FE282E.1090006@redhat.com> <52FE2DBB.3050808@redhat.com> Message-ID: <52FE3157.5010408@redhat.com> On 02/14/2014 03:52 PM, Petr Spacek wrote: > On 14.2.2014 15:29, Petr Viktorin wrote: >> On 02/14/2014 03:10 PM, Petr Spacek wrote: >>> Hello, >>> >>> This patch prevents the test suite from hitting limitations >>> in bind-dyndb-ldap 4.0. >>> >>> It should go to 3.4 (master branch, right?). >> >> Tests still pass, but the commit message is not very informative. >> Could you >> explain/link to what kind of limitations this avoids? > > Good point. Could you add this before push? > https://fedorahosted.org/bind-dyndb-ldap/ticket/127 Thanks, ACK, pushed to master: d6c5c6d8dc5117b983def018b329cd6f321c647c -- Petr? From dpal at redhat.com Fri Feb 14 19:53:38 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 14 Feb 2014 14:53:38 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FDD74D.3050504@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> Message-ID: <52FE7442.9060806@redhat.com> On 02/14/2014 03:43 AM, Martin Kosek wrote: > On 02/14/2014 12:07 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>> ... >>>>> The URL endpoint /ipa/rest suggests that if we implement a complete REST >>>>> API for IPA it would live here. Is the API supposed to be >>>>> future-compatible? (The API itself seems to be a good subset of a >>>>> complete REST API, but can we easily add an frontend with >>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>> unauthenticated access?) >>>>> Perhaps /ipa/smartproxy would be a better choice? >>>> It was future-proofing. I'm fine with changing the URI, it is probably a good >>>> thing to save that name. >>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface >>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>> >>> https://fedorahosted.org/freeipa/ticket/4168 >>> >>> Martin >>> >> I think I've addressed most of Petr's suggestions with the exception of the >> global ipa handle and I stuck with *args, **options as this is pretty much >> standard in IPA calls. >> >> The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if >> you want, I suppose it is duplication. >> >> Note that I ran this past the Foreman design again and as a result added >> another interface, /realm. It was my understanding that this Foreman design >> wasn't set into stone but a patch is working its way through their system that >> followed the spec so I went ahead and added it. It isn't a big deal, the Host() >> class handles it out of the box. >> >> I also updated the design page a bit to reflect some of the changes made. >> >> Right now there are no plans to backport python-kerberos to F20. >> >> rob > I will leave functional testing to others, I just read the code. I am still > quite concerned about the positioning, naming and "branding" of this feature. > > 1) Package name > > Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration > use case. > > Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use > this proxy for all other projects. I.e. if we one day implement user > smartproxy, it would need to be part of this otherwise it would lead to strange > organization, like having freeipa-server-smartproxy and > freeipa-server-smartproxy-users packages. Maybe it should be named differently? > > freeipa-server-foreman-smartproxy > freeipa-server-smartproxy-hosts > > 2) ipa-rest stuff > > We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. > However, I have the same concerns as above. This is too general and it may > conflict with future core server needs (like when we implement core IPA REST > interface - #4168). Let us name it consistently with package name: > > ipa-smartproxy.service > ipa-smartproxy-hosts.service > ipa-foreman-smartproxy.service > > The same for binary, man, ... > > 3) Man pages > > The same point, you brand it as "IPA REST server". This is too general. > > To sum it up - let us chose one name/brand of this feature and let's use it > consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, > subdirectory in ipatests, man, conf, script, names in man pages. > > Martin +1 I think it should be "host" ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Feb 14 19:57:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 14 Feb 2014 14:57:01 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FDFFF4.2030105@redhat.com> References: <52FD02B7.3060404@redhat.com> <52FDE9EC.3040901@redhat.com> <52FDF914.9040605@redhat.com> <52FDFDB1.60700@redhat.com> <52FDFFF4.2030105@redhat.com> Message-ID: <52FE750D.2080801@redhat.com> On 02/14/2014 06:37 AM, Petr Spacek wrote: > On 14.2.2014 12:27, Jan Cholasta wrote: >> On 14.2.2014 12:08, Petr Spacek wrote: >>> On 14.2.2014 11:03, Jan Cholasta wrote: >>>> On 13.2.2014 18:36, Petr Spacek wrote: >>>>> Hello list, >>>>> >>>>> I would like to point you to design pages for DNSSEC feature: >>>>> >>>>> Zone signing: >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC >>>>> >>>>> Automatic key rotation: >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> You can ignore bind-dyndb-ldap specifics and think about interactions >>>>> with FreeIPA and SSSD. >>>>> >>>>> - We need to design LDAP schema for key storage (Ludwig is looking >>>>> into >>>>> it). >>>> >>>> Keep in mind the schema has to work with or be extensible enough for >>>> other >>>> uses as well, ATM at least IPA CA certificate storage. >>> >>> Feel free to extend the design page as necessary. May be that we should >>> create separate design page specifically for this PKCS#11 module. >> >> +1 > > Will you create the design page? I have enjoyed it with DNSSEC and now > I would like to spend some time with coding ... :-) > > http://www.freeipa.org/page/Feature_template > >>> In fact, it is not related to DNSSEC at all. We just need to add some >>> DNSSEC-specific meta data to keys, nothing else. >> >> My point exactly. >> >>> >>>> IMO the easiest (from the PKCS#11 module writing perspective) way to >>>> do it >>>> would be to map PKCS#11 object classes and attributes directly to LDAP >>>> object >>>> classes and attributes, but that might be too much low-level for us. >>>> >>>>> - We need to write PKCS#11 module on top of LDAP database. >>>> >>>> SSSD. >>>> >>>>> - We need to design key rotation on client side (SSSD? Certmonger?). >>>> >>>> Also SSSD. >>>> >>>> I thought we already agreed on that last week? >>> >>> Last idea I have heard was about certmonger - Dmitri thought that >>> Certmonger already have all the necessary logic. >> >> It does not, for starters there is no LDAP or caching. If anything, >> it might >> be a combination of both, but I think that's more relevant to CA >> certificate >> rotation than DNSSEC. I do not insist on certmonger. >> >>> >>> In any case, nothing is set in stone. We have to discuss pros and cons >>> and then decide. >> >> Obviously :-) >> >>> >>> Keep in mind that we have to support key rotation even if the key was >>> compromised ... (Fallback from RFC 5011 to Kerberos+LDAP or something >>> like that.) >> >> I don't see how this gives advantage to either SSSD or certmonger. > > Sure, I'm just pointing it out so we are all aware of this problem. > >>>>> - We need to design WebUI/CLI >>>>> etc. >>>>> >>>>> Read sections 'External Impact' carefully :-) >>>>> >>>>> Have a nice day! > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 14 20:09:08 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 15:09:08 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE7442.9060806@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> Message-ID: <52FE77E4.1060701@redhat.com> Dmitri Pal wrote: > On 02/14/2014 03:43 AM, Martin Kosek wrote: >> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>> ... >>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>> complete REST >>>>>> API for IPA it would live here. Is the API supposed to be >>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>> complete REST API, but can we easily add an frontend with >>>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>>> unauthenticated access?) >>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>> probably a good >>>>> thing to save that name. >>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>> interface >>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4168 >>>> >>>> Martin >>>> >>> I think I've addressed most of Petr's suggestions with the exception >>> of the >>> global ipa handle and I stuck with *args, **options as this is pretty >>> much >>> standard in IPA calls. >>> >>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>> drop it if >>> you want, I suppose it is duplication. >>> >>> Note that I ran this past the Foreman design again and as a result added >>> another interface, /realm. It was my understanding that this Foreman >>> design >>> wasn't set into stone but a patch is working its way through their >>> system that >>> followed the spec so I went ahead and added it. It isn't a big deal, >>> the Host() >>> class handles it out of the box. >>> >>> I also updated the design page a bit to reflect some of the changes >>> made. >>> >>> Right now there are no plans to backport python-kerberos to F20. >>> >>> rob >> I will leave functional testing to others, I just read the code. I am >> still >> quite concerned about the positioning, naming and "branding" of this >> feature. >> >> 1) Package name >> >> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >> integration >> use case. >> >> Packaging it as freeipa-server-smartproxy may be ok, but only if we >> plan to use >> this proxy for all other projects. I.e. if we one day implement user >> smartproxy, it would need to be part of this otherwise it would lead >> to strange >> organization, like having freeipa-server-smartproxy and >> freeipa-server-smartproxy-users packages. Maybe it should be named >> differently? >> >> freeipa-server-foreman-smartproxy >> freeipa-server-smartproxy-hosts >> >> 2) ipa-rest stuff >> >> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. >> However, I have the same concerns as above. This is too general and it >> may >> conflict with future core server needs (like when we implement core >> IPA REST >> interface - #4168). Let us name it consistently with package name: >> >> ipa-smartproxy.service >> ipa-smartproxy-hosts.service >> ipa-foreman-smartproxy.service >> >> The same for binary, man, ... >> >> 3) Man pages >> >> The same point, you brand it as "IPA REST server". This is too general. >> >> To sum it up - let us chose one name/brand of this feature and let's >> use it >> consistently in FreeIPA infrastructure - subpackage name, subdirectory >> in git, >> subdirectory in ipatests, man, conf, script, names in man pages. >> >> Martin > +1 > > I think it should be "host" > > ipa-host-smartproxy > > then we will be able to add other smart proxies and then combine them > into one ipa-smartproxy package later if needed. > This would imply we actually run separate servers for the various commands. Given that right now we're focused on just the Foreman use cases I think ipa-smartproxy is sufficient. For our purposes the smartproxy is just a thin wrapper around the IPA API. It is extensible for our needs, we just don't need to yet. But if we did, we'd do so within the cherrypy server and everything would be self-contained. rob From dpal at redhat.com Fri Feb 14 21:07:59 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 14 Feb 2014 16:07:59 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE77E4.1060701@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> Message-ID: <52FE85AF.4080608@redhat.com> On 02/14/2014 03:09 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>> ... >>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>> complete REST >>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>> complete REST API, but can we easily add an frontend with >>>>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>>>> unauthenticated access?) >>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>> probably a good >>>>>> thing to save that name. >>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>> interface >>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>> >>>>> Martin >>>>> >>>> I think I've addressed most of Petr's suggestions with the exception >>>> of the >>>> global ipa handle and I stuck with *args, **options as this is pretty >>>> much >>>> standard in IPA calls. >>>> >>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>> drop it if >>>> you want, I suppose it is duplication. >>>> >>>> Note that I ran this past the Foreman design again and as a result >>>> added >>>> another interface, /realm. It was my understanding that this Foreman >>>> design >>>> wasn't set into stone but a patch is working its way through their >>>> system that >>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>> the Host() >>>> class handles it out of the box. >>>> >>>> I also updated the design page a bit to reflect some of the changes >>>> made. >>>> >>>> Right now there are no plans to backport python-kerberos to F20. >>>> >>>> rob >>> I will leave functional testing to others, I just read the code. I am >>> still >>> quite concerned about the positioning, naming and "branding" of this >>> feature. >>> >>> 1) Package name >>> >>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>> integration >>> use case. >>> >>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>> plan to use >>> this proxy for all other projects. I.e. if we one day implement user >>> smartproxy, it would need to be part of this otherwise it would lead >>> to strange >>> organization, like having freeipa-server-smartproxy and >>> freeipa-server-smartproxy-users packages. Maybe it should be named >>> differently? >>> >>> freeipa-server-foreman-smartproxy >>> freeipa-server-smartproxy-hosts >>> >>> 2) ipa-rest stuff >>> >>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. >>> However, I have the same concerns as above. This is too general and it >>> may >>> conflict with future core server needs (like when we implement core >>> IPA REST >>> interface - #4168). Let us name it consistently with package name: >>> >>> ipa-smartproxy.service >>> ipa-smartproxy-hosts.service >>> ipa-foreman-smartproxy.service >>> >>> The same for binary, man, ... >>> >>> 3) Man pages >>> >>> The same point, you brand it as "IPA REST server". This is too general. >>> >>> To sum it up - let us chose one name/brand of this feature and let's >>> use it >>> consistently in FreeIPA infrastructure - subpackage name, subdirectory >>> in git, >>> subdirectory in ipatests, man, conf, script, names in man pages. >>> >>> Martin >> +1 >> >> I think it should be "host" >> >> ipa-host-smartproxy >> >> then we will be able to add other smart proxies and then combine them >> into one ipa-smartproxy package later if needed. >> > > This would imply we actually run separate servers for the various > commands. Given that right now we're focused on just the Foreman use > cases I think ipa-smartproxy is sufficient. > > For our purposes the smartproxy is just a thin wrapper around the IPA > API. It is extensible for our needs, we just don't need to yet. But if > we did, we'd do so within the cherrypy server and everything would be > self-contained. > > rob Are you saying that we will just extend this smart proxy for other use cases like users and others? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 14 21:52:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 16:52:46 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE85AF.4080608@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> Message-ID: <52FE902E.2050000@redhat.com> Dmitri Pal wrote: > On 02/14/2014 03:09 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>> ... >>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>> complete REST >>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>>>>> unauthenticated access?) >>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>> probably a good >>>>>>> thing to save that name. >>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>>> interface >>>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>> >>>>>> Martin >>>>>> >>>>> I think I've addressed most of Petr's suggestions with the exception >>>>> of the >>>>> global ipa handle and I stuck with *args, **options as this is pretty >>>>> much >>>>> standard in IPA calls. >>>>> >>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>>> drop it if >>>>> you want, I suppose it is duplication. >>>>> >>>>> Note that I ran this past the Foreman design again and as a result >>>>> added >>>>> another interface, /realm. It was my understanding that this Foreman >>>>> design >>>>> wasn't set into stone but a patch is working its way through their >>>>> system that >>>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>>> the Host() >>>>> class handles it out of the box. >>>>> >>>>> I also updated the design page a bit to reflect some of the changes >>>>> made. >>>>> >>>>> Right now there are no plans to backport python-kerberos to F20. >>>>> >>>>> rob >>>> I will leave functional testing to others, I just read the code. I am >>>> still >>>> quite concerned about the positioning, naming and "branding" of this >>>> feature. >>>> >>>> 1) Package name >>>> >>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>> integration >>>> use case. >>>> >>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>> plan to use >>>> this proxy for all other projects. I.e. if we one day implement user >>>> smartproxy, it would need to be part of this otherwise it would lead >>>> to strange >>>> organization, like having freeipa-server-smartproxy and >>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>> differently? >>>> >>>> freeipa-server-foreman-smartproxy >>>> freeipa-server-smartproxy-hosts >>>> >>>> 2) ipa-rest stuff >>>> >>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. >>>> However, I have the same concerns as above. This is too general and it >>>> may >>>> conflict with future core server needs (like when we implement core >>>> IPA REST >>>> interface - #4168). Let us name it consistently with package name: >>>> >>>> ipa-smartproxy.service >>>> ipa-smartproxy-hosts.service >>>> ipa-foreman-smartproxy.service >>>> >>>> The same for binary, man, ... >>>> >>>> 3) Man pages >>>> >>>> The same point, you brand it as "IPA REST server". This is too general. >>>> >>>> To sum it up - let us chose one name/brand of this feature and let's >>>> use it >>>> consistently in FreeIPA infrastructure - subpackage name, subdirectory >>>> in git, >>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>> >>>> Martin >>> +1 >>> >>> I think it should be "host" >>> >>> ipa-host-smartproxy >>> >>> then we will be able to add other smart proxies and then combine them >>> into one ipa-smartproxy package later if needed. >>> >> >> This would imply we actually run separate servers for the various >> commands. Given that right now we're focused on just the Foreman use >> cases I think ipa-smartproxy is sufficient. >> >> For our purposes the smartproxy is just a thin wrapper around the IPA >> API. It is extensible for our needs, we just don't need to yet. But if >> we did, we'd do so within the cherrypy server and everything would be >> self-contained. >> >> rob > > Are you saying that we will just extend this smart proxy for other use > cases like users and others? > It all depends on the use case. If we're talking Foreman then yes. If something else, then we'll discuss it at the time, but it still may be able to be included. The IPA Foreman smart proxy is distinguished by a couple of things: - listens on port 8090, only on localhost - is unauthenticated - uses the /realm URI namespace I'm exposing hosts and hostgroups as well, but per the spec that Dominic came up with only /realm/:domain is required and affects only hosts. We can stick this behind Apache to get authentication, even on a specific URI if we want/need to, but the basic REST stuff can still be handled by cherrypy. We'll need to balance complexity of mixing things vs the complexity of code duplication in multiple servers, unless we come up with some sort of REST server class where we just instantiate whatever we need. But that is for the future. rob From dpal at redhat.com Fri Feb 14 22:01:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 14 Feb 2014 17:01:20 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE902E.2050000@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> Message-ID: <52FE9230.3030906@redhat.com> On 02/14/2014 04:52 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>> ... >>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>> complete REST >>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>> limitations for >>>>>>>>> unauthenticated access?) >>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>> probably a good >>>>>>>> thing to save that name. >>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>>>> interface >>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> I think I've addressed most of Petr's suggestions with the exception >>>>>> of the >>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>> pretty >>>>>> much >>>>>> standard in IPA calls. >>>>>> >>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>>>> drop it if >>>>>> you want, I suppose it is duplication. >>>>>> >>>>>> Note that I ran this past the Foreman design again and as a result >>>>>> added >>>>>> another interface, /realm. It was my understanding that this Foreman >>>>>> design >>>>>> wasn't set into stone but a patch is working its way through their >>>>>> system that >>>>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>>>> the Host() >>>>>> class handles it out of the box. >>>>>> >>>>>> I also updated the design page a bit to reflect some of the changes >>>>>> made. >>>>>> >>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>> >>>>>> rob >>>>> I will leave functional testing to others, I just read the code. I am >>>>> still >>>>> quite concerned about the positioning, naming and "branding" of this >>>>> feature. >>>>> >>>>> 1) Package name >>>>> >>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>> integration >>>>> use case. >>>>> >>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>> plan to use >>>>> this proxy for all other projects. I.e. if we one day implement user >>>>> smartproxy, it would need to be part of this otherwise it would lead >>>>> to strange >>>>> organization, like having freeipa-server-smartproxy and >>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>> differently? >>>>> >>>>> freeipa-server-foreman-smartproxy >>>>> freeipa-server-smartproxy-hosts >>>>> >>>>> 2) ipa-rest stuff >>>>> >>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>> man. >>>>> However, I have the same concerns as above. This is too general >>>>> and it >>>>> may >>>>> conflict with future core server needs (like when we implement core >>>>> IPA REST >>>>> interface - #4168). Let us name it consistently with package name: >>>>> >>>>> ipa-smartproxy.service >>>>> ipa-smartproxy-hosts.service >>>>> ipa-foreman-smartproxy.service >>>>> >>>>> The same for binary, man, ... >>>>> >>>>> 3) Man pages >>>>> >>>>> The same point, you brand it as "IPA REST server". This is too >>>>> general. >>>>> >>>>> To sum it up - let us chose one name/brand of this feature and let's >>>>> use it >>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>> subdirectory >>>>> in git, >>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>> >>>>> Martin >>>> +1 >>>> >>>> I think it should be "host" >>>> >>>> ipa-host-smartproxy >>>> >>>> then we will be able to add other smart proxies and then combine them >>>> into one ipa-smartproxy package later if needed. >>>> >>> >>> This would imply we actually run separate servers for the various >>> commands. Given that right now we're focused on just the Foreman use >>> cases I think ipa-smartproxy is sufficient. >>> >>> For our purposes the smartproxy is just a thin wrapper around the IPA >>> API. It is extensible for our needs, we just don't need to yet. But if >>> we did, we'd do so within the cherrypy server and everything would be >>> self-contained. >>> >>> rob >> >> Are you saying that we will just extend this smart proxy for other use >> cases like users and others? >> > > It all depends on the use case. If we're talking Foreman then yes. If > something else, then we'll discuss it at the time, but it still may be > able to be included. > > The IPA Foreman smart proxy is distinguished by a couple of things: > > - listens on port 8090, only on localhost > - is unauthenticated > - uses the /realm URI namespace > > I'm exposing hosts and hostgroups as well, but per the spec that > Dominic came up with only /realm/:domain is required and affects only > hosts. > > We can stick this behind Apache to get authentication, even on a > specific URI if we want/need to, but the basic REST stuff can still be > handled by cherrypy. > > We'll need to balance complexity of mixing things vs the complexity of > code duplication in multiple servers, unless we come up with some sort > of REST server class where we just instantiate whatever we need. But > that is for the future. > > rob But if it is specific for Foreman then it should have a generic name. I agree with Martin here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 14 22:07:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 17:07:23 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE9230.3030906@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> Message-ID: <52FE939B.9040207@redhat.com> Dmitri Pal wrote: > On 02/14/2014 04:52 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>> ... >>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>> complete REST >>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>> limitations for >>>>>>>>>> unauthenticated access?) >>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>> probably a good >>>>>>>>> thing to save that name. >>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>>>>> interface >>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> I think I've addressed most of Petr's suggestions with the exception >>>>>>> of the >>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>> pretty >>>>>>> much >>>>>>> standard in IPA calls. >>>>>>> >>>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>>>>> drop it if >>>>>>> you want, I suppose it is duplication. >>>>>>> >>>>>>> Note that I ran this past the Foreman design again and as a result >>>>>>> added >>>>>>> another interface, /realm. It was my understanding that this Foreman >>>>>>> design >>>>>>> wasn't set into stone but a patch is working its way through their >>>>>>> system that >>>>>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>>>>> the Host() >>>>>>> class handles it out of the box. >>>>>>> >>>>>>> I also updated the design page a bit to reflect some of the changes >>>>>>> made. >>>>>>> >>>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>>> >>>>>>> rob >>>>>> I will leave functional testing to others, I just read the code. I am >>>>>> still >>>>>> quite concerned about the positioning, naming and "branding" of this >>>>>> feature. >>>>>> >>>>>> 1) Package name >>>>>> >>>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>>> integration >>>>>> use case. >>>>>> >>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>>> plan to use >>>>>> this proxy for all other projects. I.e. if we one day implement user >>>>>> smartproxy, it would need to be part of this otherwise it would lead >>>>>> to strange >>>>>> organization, like having freeipa-server-smartproxy and >>>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>>> differently? >>>>>> >>>>>> freeipa-server-foreman-smartproxy >>>>>> freeipa-server-smartproxy-hosts >>>>>> >>>>>> 2) ipa-rest stuff >>>>>> >>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>>> man. >>>>>> However, I have the same concerns as above. This is too general >>>>>> and it >>>>>> may >>>>>> conflict with future core server needs (like when we implement core >>>>>> IPA REST >>>>>> interface - #4168). Let us name it consistently with package name: >>>>>> >>>>>> ipa-smartproxy.service >>>>>> ipa-smartproxy-hosts.service >>>>>> ipa-foreman-smartproxy.service >>>>>> >>>>>> The same for binary, man, ... >>>>>> >>>>>> 3) Man pages >>>>>> >>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>> general. >>>>>> >>>>>> To sum it up - let us chose one name/brand of this feature and let's >>>>>> use it >>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>> subdirectory >>>>>> in git, >>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>> >>>>>> Martin >>>>> +1 >>>>> >>>>> I think it should be "host" >>>>> >>>>> ipa-host-smartproxy >>>>> >>>>> then we will be able to add other smart proxies and then combine them >>>>> into one ipa-smartproxy package later if needed. >>>>> >>>> >>>> This would imply we actually run separate servers for the various >>>> commands. Given that right now we're focused on just the Foreman use >>>> cases I think ipa-smartproxy is sufficient. >>>> >>>> For our purposes the smartproxy is just a thin wrapper around the IPA >>>> API. It is extensible for our needs, we just don't need to yet. But if >>>> we did, we'd do so within the cherrypy server and everything would be >>>> self-contained. >>>> >>>> rob >>> >>> Are you saying that we will just extend this smart proxy for other use >>> cases like users and others? >>> >> >> It all depends on the use case. If we're talking Foreman then yes. If >> something else, then we'll discuss it at the time, but it still may be >> able to be included. >> >> The IPA Foreman smart proxy is distinguished by a couple of things: >> >> - listens on port 8090, only on localhost >> - is unauthenticated >> - uses the /realm URI namespace >> >> I'm exposing hosts and hostgroups as well, but per the spec that >> Dominic came up with only /realm/:domain is required and affects only >> hosts. >> >> We can stick this behind Apache to get authentication, even on a >> specific URI if we want/need to, but the basic REST stuff can still be >> handled by cherrypy. >> >> We'll need to balance complexity of mixing things vs the complexity of >> code duplication in multiple servers, unless we come up with some sort >> of REST server class where we just instantiate whatever we need. But >> that is for the future. >> >> rob > > But if it is specific for Foreman then it should have a generic name. I > agree with Martin here. I have the feeling we're in basic agreement. smartproxy is the Foreman name. I'm not pushing back against renaming, I'll have a new patch out shortly doing just that. I'm just pushing back against renaming it too deeply. I'm going with ipa-smartproxy. rob From dpal at redhat.com Fri Feb 14 22:26:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 14 Feb 2014 17:26:54 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE939B.9040207@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> Message-ID: <52FE982E.2010604@redhat.com> On 02/14/2014 05:07 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>> ... >>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>> complete REST >>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>> future-compatible? (The API itself seems to be a good subset >>>>>>>>>>> of a >>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>> limitations for >>>>>>>>>>> unauthenticated access?) >>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>> probably a good >>>>>>>>>> thing to save that name. >>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete >>>>>>>>> REST >>>>>>>>> interface >>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track >>>>>>>>> that: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> I think I've addressed most of Petr's suggestions with the >>>>>>>> exception >>>>>>>> of the >>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>> pretty >>>>>>>> much >>>>>>>> standard in IPA calls. >>>>>>>> >>>>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I >>>>>>>> can >>>>>>>> drop it if >>>>>>>> you want, I suppose it is duplication. >>>>>>>> >>>>>>>> Note that I ran this past the Foreman design again and as a result >>>>>>>> added >>>>>>>> another interface, /realm. It was my understanding that this >>>>>>>> Foreman >>>>>>>> design >>>>>>>> wasn't set into stone but a patch is working its way through their >>>>>>>> system that >>>>>>>> followed the spec so I went ahead and added it. It isn't a big >>>>>>>> deal, >>>>>>>> the Host() >>>>>>>> class handles it out of the box. >>>>>>>> >>>>>>>> I also updated the design page a bit to reflect some of the >>>>>>>> changes >>>>>>>> made. >>>>>>>> >>>>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>>>> >>>>>>>> rob >>>>>>> I will leave functional testing to others, I just read the code. >>>>>>> I am >>>>>>> still >>>>>>> quite concerned about the positioning, naming and "branding" of >>>>>>> this >>>>>>> feature. >>>>>>> >>>>>>> 1) Package name >>>>>>> >>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>>>> integration >>>>>>> use case. >>>>>>> >>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>>>> plan to use >>>>>>> this proxy for all other projects. I.e. if we one day implement >>>>>>> user >>>>>>> smartproxy, it would need to be part of this otherwise it would >>>>>>> lead >>>>>>> to strange >>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>>>> differently? >>>>>>> >>>>>>> freeipa-server-foreman-smartproxy >>>>>>> freeipa-server-smartproxy-hosts >>>>>>> >>>>>>> 2) ipa-rest stuff >>>>>>> >>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>>>> man. >>>>>>> However, I have the same concerns as above. This is too general >>>>>>> and it >>>>>>> may >>>>>>> conflict with future core server needs (like when we implement core >>>>>>> IPA REST >>>>>>> interface - #4168). Let us name it consistently with package name: >>>>>>> >>>>>>> ipa-smartproxy.service >>>>>>> ipa-smartproxy-hosts.service >>>>>>> ipa-foreman-smartproxy.service >>>>>>> >>>>>>> The same for binary, man, ... >>>>>>> >>>>>>> 3) Man pages >>>>>>> >>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>> general. >>>>>>> >>>>>>> To sum it up - let us chose one name/brand of this feature and >>>>>>> let's >>>>>>> use it >>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>> subdirectory >>>>>>> in git, >>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>> >>>>>>> Martin >>>>>> +1 >>>>>> >>>>>> I think it should be "host" >>>>>> >>>>>> ipa-host-smartproxy >>>>>> >>>>>> then we will be able to add other smart proxies and then combine >>>>>> them >>>>>> into one ipa-smartproxy package later if needed. >>>>>> >>>>> >>>>> This would imply we actually run separate servers for the various >>>>> commands. Given that right now we're focused on just the Foreman use >>>>> cases I think ipa-smartproxy is sufficient. >>>>> >>>>> For our purposes the smartproxy is just a thin wrapper around the IPA >>>>> API. It is extensible for our needs, we just don't need to yet. >>>>> But if >>>>> we did, we'd do so within the cherrypy server and everything would be >>>>> self-contained. >>>>> >>>>> rob >>>> >>>> Are you saying that we will just extend this smart proxy for other use >>>> cases like users and others? >>>> >>> >>> It all depends on the use case. If we're talking Foreman then yes. If >>> something else, then we'll discuss it at the time, but it still may be >>> able to be included. >>> >>> The IPA Foreman smart proxy is distinguished by a couple of things: >>> >>> - listens on port 8090, only on localhost >>> - is unauthenticated >>> - uses the /realm URI namespace >>> >>> I'm exposing hosts and hostgroups as well, but per the spec that >>> Dominic came up with only /realm/:domain is required and affects only >>> hosts. >>> >>> We can stick this behind Apache to get authentication, even on a >>> specific URI if we want/need to, but the basic REST stuff can still be >>> handled by cherrypy. >>> >>> We'll need to balance complexity of mixing things vs the complexity of >>> code duplication in multiple servers, unless we come up with some sort >>> of REST server class where we just instantiate whatever we need. But >>> that is for the future. >>> >>> rob >> >> But if it is specific for Foreman then it should have a generic name. I >> agree with Martin here. > > I have the feeling we're in basic agreement. > > smartproxy is the Foreman name. I'm not pushing back against renaming, > I'll have a new patch out shortly doing just that. I'm just pushing > back against renaming it too deeply. I'm going with ipa-smartproxy. > > rob The point is that smartproxy is a good name to be reused outside foreman. So rather than assuming that "smartproxy" is foreman specific we can go with: host proxy or host smart proxy - for this use case and then user proxy or user smart proxy - for use cases like User provisioning systems and then DNS proxy or DNS smart proxy - ... and then DHCP proxy or DHCP smart proxy - ... and so on We need to establish a good pattern that we will be able to easily extend. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 14 23:39:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 18:39:37 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FDF7D1.7040105@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDF7D1.7040105@redhat.com> Message-ID: <52FEA939.3050509@redhat.com> Petr Viktorin wrote: > On 02/14/2014 12:07 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>> ... >>>>> The URL endpoint /ipa/rest suggests that if we implement a complete >>>>> REST >>>>> API for IPA it would live here. Is the API supposed to be >>>>> future-compatible? (The API itself seems to be a good subset of a >>>>> complete REST API, but can we easily add an frontend with >>>>> authentication, i18n, etc. here later, and keep the limitations for >>>>> unauthenticated access?) >>>>> Perhaps /ipa/smartproxy would be a better choice? >>>> >>>> It was future-proofing. I'm fine with changing the URI, it is >>>> probably a good >>>> thing to save that name. >>> >>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>> interface >>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>> >>> https://fedorahosted.org/freeipa/ticket/4168 >>> >>> Martin >>> >> >> I think I've addressed most of Petr's suggestions with the exception of >> the global ipa handle and I stuck with *args, **options as this is >> pretty much standard in IPA calls. > > Well, I can't have everything :) > Here's some quick feedback. > >> The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop >> it if you want, I suppose it is duplication. > > Please do. It's not discoverable at all. Anyone can copy it from the man > page and keep it around. > >> Note that I ran this past the Foreman design again and as a result added >> another interface, /realm. It was my understanding that this Foreman >> design wasn't set into stone but a patch is working its way through >> their system that followed the spec so I went ahead and added it. It >> isn't a big deal, the Host() class handles it out of the box. >> >> I also updated the design page a bit to reflect some of the changes made. >> >> Right now there are no plans to backport python-kerberos to F20. > > Not even in a COPR? > So if this goes in, all developers would need to switch to Rawhide. I'm > not sure we're prepared for that yet. > >> rob > > Currently we return this for errors in JSON: > > { > "error": { > "code": 4002, > "message": "user with name \\"admin\\" already exists", > "name": "DuplicateEntry" > }, > "id": 0, > "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", > "result": null, > "version": "3.3.90GIT8e26acb" > } > > It would be more consitent if we used the same "error" dict also for REST. > > > The default port, 8090, is still not documented. > Done some renaming. Still arguing about what to call this thing later in the thread, but that's code-independent. I fixed up the man pages a bit, re-tested everything, improved the spec slightly and probably some other minor things I'm forgetting. I raise a single, server-specific exception which is why I do all the basestring/Exception handwringing in the IPAError class. I'm open to suggestions. I'd rather not declare an error in the IPA Namespace for this. This sort of brings us back to a previous discussion on where errors.py should live... rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-4-rest.patch Type: text/x-patch Size: 45622 bytes Desc: not available URL: From nkinder at redhat.com Sat Feb 15 00:31:50 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 14 Feb 2014 16:31:50 -0800 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE982E.2010604@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> Message-ID: <52FEB576.3090706@redhat.com> On 02/14/2014 02:26 PM, Dmitri Pal wrote: > On 02/14/2014 05:07 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>> ... >>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>> complete REST >>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>> future-compatible? (The API itself seems to be a good subset >>>>>>>>>>>> of a >>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>> limitations for >>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>>> probably a good >>>>>>>>>>> thing to save that name. >>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete >>>>>>>>>> REST >>>>>>>>>> interface >>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track >>>>>>>>>> that: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> I think I've addressed most of Petr's suggestions with the >>>>>>>>> exception >>>>>>>>> of the >>>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>>> pretty >>>>>>>>> much >>>>>>>>> standard in IPA calls. >>>>>>>>> >>>>>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I >>>>>>>>> can >>>>>>>>> drop it if >>>>>>>>> you want, I suppose it is duplication. >>>>>>>>> >>>>>>>>> Note that I ran this past the Foreman design again and as a result >>>>>>>>> added >>>>>>>>> another interface, /realm. It was my understanding that this >>>>>>>>> Foreman >>>>>>>>> design >>>>>>>>> wasn't set into stone but a patch is working its way through their >>>>>>>>> system that >>>>>>>>> followed the spec so I went ahead and added it. It isn't a big >>>>>>>>> deal, >>>>>>>>> the Host() >>>>>>>>> class handles it out of the box. >>>>>>>>> >>>>>>>>> I also updated the design page a bit to reflect some of the >>>>>>>>> changes >>>>>>>>> made. >>>>>>>>> >>>>>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>>>>> >>>>>>>>> rob >>>>>>>> I will leave functional testing to others, I just read the code. >>>>>>>> I am >>>>>>>> still >>>>>>>> quite concerned about the positioning, naming and "branding" of >>>>>>>> this >>>>>>>> feature. >>>>>>>> >>>>>>>> 1) Package name >>>>>>>> >>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>>>>> integration >>>>>>>> use case. >>>>>>>> >>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>>>>> plan to use >>>>>>>> this proxy for all other projects. I.e. if we one day implement >>>>>>>> user >>>>>>>> smartproxy, it would need to be part of this otherwise it would >>>>>>>> lead >>>>>>>> to strange >>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>>>>> differently? >>>>>>>> >>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>> >>>>>>>> 2) ipa-rest stuff >>>>>>>> >>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>>>>> man. >>>>>>>> However, I have the same concerns as above. This is too general >>>>>>>> and it >>>>>>>> may >>>>>>>> conflict with future core server needs (like when we implement core >>>>>>>> IPA REST >>>>>>>> interface - #4168). Let us name it consistently with package name: >>>>>>>> >>>>>>>> ipa-smartproxy.service >>>>>>>> ipa-smartproxy-hosts.service >>>>>>>> ipa-foreman-smartproxy.service >>>>>>>> >>>>>>>> The same for binary, man, ... >>>>>>>> >>>>>>>> 3) Man pages >>>>>>>> >>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>> general. >>>>>>>> >>>>>>>> To sum it up - let us chose one name/brand of this feature and >>>>>>>> let's >>>>>>>> use it >>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>> subdirectory >>>>>>>> in git, >>>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>>> >>>>>>>> Martin >>>>>>> +1 >>>>>>> >>>>>>> I think it should be "host" >>>>>>> >>>>>>> ipa-host-smartproxy >>>>>>> >>>>>>> then we will be able to add other smart proxies and then combine >>>>>>> them >>>>>>> into one ipa-smartproxy package later if needed. >>>>>>> >>>>>> >>>>>> This would imply we actually run separate servers for the various >>>>>> commands. Given that right now we're focused on just the Foreman use >>>>>> cases I think ipa-smartproxy is sufficient. >>>>>> >>>>>> For our purposes the smartproxy is just a thin wrapper around the IPA >>>>>> API. It is extensible for our needs, we just don't need to yet. >>>>>> But if >>>>>> we did, we'd do so within the cherrypy server and everything would be >>>>>> self-contained. >>>>>> >>>>>> rob >>>>> >>>>> Are you saying that we will just extend this smart proxy for other use >>>>> cases like users and others? >>>>> >>>> >>>> It all depends on the use case. If we're talking Foreman then yes. If >>>> something else, then we'll discuss it at the time, but it still may be >>>> able to be included. >>>> >>>> The IPA Foreman smart proxy is distinguished by a couple of things: >>>> >>>> - listens on port 8090, only on localhost >>>> - is unauthenticated >>>> - uses the /realm URI namespace >>>> >>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>> Dominic came up with only /realm/:domain is required and affects only >>>> hosts. >>>> >>>> We can stick this behind Apache to get authentication, even on a >>>> specific URI if we want/need to, but the basic REST stuff can still be >>>> handled by cherrypy. >>>> >>>> We'll need to balance complexity of mixing things vs the complexity of >>>> code duplication in multiple servers, unless we come up with some sort >>>> of REST server class where we just instantiate whatever we need. But >>>> that is for the future. >>>> >>>> rob >>> >>> But if it is specific for Foreman then it should have a generic name. I >>> agree with Martin here. >> >> I have the feeling we're in basic agreement. >> >> smartproxy is the Foreman name. I'm not pushing back against renaming, >> I'll have a new patch out shortly doing just that. I'm just pushing >> back against renaming it too deeply. I'm going with ipa-smartproxy. >> >> rob > The point is that smartproxy is a good name to be reused outside > foreman. What Rob is getting at is that the term "Smart-Proxy" is already Foreman specific: http://theforeman.org/manuals/1.1/index.html http://theforeman.org/manuals/1.1/index.html#4.3SmartProxies We can still overload the term if we want to, but that could cause confusion for non-foreman cases. > So rather than assuming that "smartproxy" is foreman specific > we can go with: > host proxy or host smart proxy - for this use case > and then > user proxy or user smart proxy - for use cases like User provisioning > systems > and then > DNS proxy or DNS smart proxy - ... > and then > DHCP proxy or DHCP smart proxy - ... > and so on > > We need to establish a good pattern that we will be able to easily extend. > > > > From simo at redhat.com Sun Feb 16 11:49:59 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 16 Feb 2014 06:49:59 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE902E.2050000@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> Message-ID: <1392551399.22754.11.camel@willson.li.ssimo.org> On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: > - listens on port 8090, only on localhost > - is unauthenticated Sorry to come late, but I am really at unease with this point. Can we do at least some form of simple authentication ? Even if it is a shared secret in a file accessible by both foreman and smartproxy ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sun Feb 16 11:52:35 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 16 Feb 2014 06:52:35 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FD7CBF.6090706@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FD5A24.4010601@redhat.com> <52FD7950.1020006@redhat.com> <52FD7CBF.6090706@redhat.com> Message-ID: <1392551555.22754.12.camel@willson.li.ssimo.org> On Thu, 2014-02-13 at 21:17 -0500, Dmitri Pal wrote: > On 02/13/2014 09:02 PM, Rob Crittenden wrote: > > Dmitri Pal wrote: > >> Recently we had a ticket in SSSD > >> https://fedorahosted.org/sssd/ticket/2217 > >> Should we have a similar one for IPA client and especially for the > >> proxy? > >> Proxy will be a long term running process so dealing with the stale > >> tickets becomes important for it if replica is re-installed. Is it > >> something that is solved in API level or on the proxy level? > >> Should we have a separate ticket for that? > > > > Using gss-proxy so it's not our problem. We never touch tickets. > > > > rob > > > Does gss proxy solve this problem? We do not have any special code to deal with this failure mode in GSS-Proxy, please open a ticket. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sun Feb 16 12:22:55 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 16 Feb 2014 07:22:55 -0500 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) In-Reply-To: <52FE1F7A.8030206@redhat.com> References: <52FE1F7A.8030206@redhat.com> Message-ID: <1392553375.22754.13.camel@willson.li.ssimo.org> On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: > Hello, > > I have got an silly idea to use TPM (Trusted Platform Module) as backend for > Keytab storage (via GSS-Proxy). > > GSS-Proxy prevents application from accessing key material, right? So > GSS-Proxy could theoretically store keys in TPM and application wouldn't > notice any difference, right? > > We have libraries for that in Fedora already: > https://admin.fedoraproject.org/pkgdb/acls/name/trousers > > > Even sillier idea is to use TPM as a PKCS#11 module: > http://trousers.sourceforge.net/pkcs11.html > > I have no idea what the use case could be ... :-) May be as a "cache" for > PKCS#11 module in SSSD? > > > As I said, it is just a silly idea. > Open a ticket in the GSS-Proxy trac :) Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Feb 17 02:54:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 16 Feb 2014 21:54:21 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <1392551399.22754.11.camel@willson.li.ssimo.org> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <1392551399.22754.11.camel@willson.li.ssimo.org> Message-ID: <530179DD.9060103@redhat.com> On 02/16/2014 06:49 AM, Simo Sorce wrote: > On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: >> - listens on port 8090, only on localhost >> - is unauthenticated > Sorry to come late, but I am really at unease with this point. > > Can we do at least some form of simple authentication ? Even if it is a > shared secret in a file accessible by both foreman and smartproxy ? > > Simo. > Simo, it is such by design. The interface is local only and smart proxy explicitly checks that is it called locally byt a local process. The daemon by itself will then do a remote authenticate against IPA. We trust Foreman machine to make the host changes and allow it to make only these changes using access control rules on the server. I do not think we need or can change anything here. Any kind of authentication would significantly complicate integration with Foreman and I frankly do not see a value in another level of authentication. I.e. how certs or key in the file makes it more secure? I would rather suggest some SELInux policies that would open the REST api port to only specific labels. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Feb 17 07:47:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Feb 2014 08:47:31 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <52FE982E.2010604@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> Message-ID: <5301BE93.4020203@redhat.com> On 02/14/2014 11:26 PM, Dmitri Pal wrote: > On 02/14/2014 05:07 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>> ... >>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>> complete REST >>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>> limitations for >>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>>> probably a good >>>>>>>>>>> thing to save that name. >>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>>>>>>> interface >>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> I think I've addressed most of Petr's suggestions with the exception >>>>>>>>> of the >>>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>>> pretty >>>>>>>>> much >>>>>>>>> standard in IPA calls. >>>>>>>>> >>>>>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>>>>>>> drop it if >>>>>>>>> you want, I suppose it is duplication. >>>>>>>>> >>>>>>>>> Note that I ran this past the Foreman design again and as a result >>>>>>>>> added >>>>>>>>> another interface, /realm. It was my understanding that this Foreman >>>>>>>>> design >>>>>>>>> wasn't set into stone but a patch is working its way through their >>>>>>>>> system that >>>>>>>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>>>>>>> the Host() >>>>>>>>> class handles it out of the box. >>>>>>>>> >>>>>>>>> I also updated the design page a bit to reflect some of the changes >>>>>>>>> made. >>>>>>>>> >>>>>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>>>>> >>>>>>>>> rob >>>>>>>> I will leave functional testing to others, I just read the code. I am >>>>>>>> still >>>>>>>> quite concerned about the positioning, naming and "branding" of this >>>>>>>> feature. >>>>>>>> >>>>>>>> 1) Package name >>>>>>>> >>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>>>>> integration >>>>>>>> use case. >>>>>>>> >>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>>>>> plan to use >>>>>>>> this proxy for all other projects. I.e. if we one day implement user >>>>>>>> smartproxy, it would need to be part of this otherwise it would lead >>>>>>>> to strange >>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>>>>> differently? >>>>>>>> >>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>> >>>>>>>> 2) ipa-rest stuff >>>>>>>> >>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>>>>> man. >>>>>>>> However, I have the same concerns as above. This is too general >>>>>>>> and it >>>>>>>> may >>>>>>>> conflict with future core server needs (like when we implement core >>>>>>>> IPA REST >>>>>>>> interface - #4168). Let us name it consistently with package name: >>>>>>>> >>>>>>>> ipa-smartproxy.service >>>>>>>> ipa-smartproxy-hosts.service >>>>>>>> ipa-foreman-smartproxy.service >>>>>>>> >>>>>>>> The same for binary, man, ... >>>>>>>> >>>>>>>> 3) Man pages >>>>>>>> >>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>> general. >>>>>>>> >>>>>>>> To sum it up - let us chose one name/brand of this feature and let's >>>>>>>> use it >>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>> subdirectory >>>>>>>> in git, >>>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>>> >>>>>>>> Martin >>>>>>> +1 >>>>>>> >>>>>>> I think it should be "host" >>>>>>> >>>>>>> ipa-host-smartproxy >>>>>>> >>>>>>> then we will be able to add other smart proxies and then combine them >>>>>>> into one ipa-smartproxy package later if needed. >>>>>>> >>>>>> >>>>>> This would imply we actually run separate servers for the various >>>>>> commands. Given that right now we're focused on just the Foreman use >>>>>> cases I think ipa-smartproxy is sufficient. >>>>>> >>>>>> For our purposes the smartproxy is just a thin wrapper around the IPA >>>>>> API. It is extensible for our needs, we just don't need to yet. But if >>>>>> we did, we'd do so within the cherrypy server and everything would be >>>>>> self-contained. >>>>>> >>>>>> rob >>>>> >>>>> Are you saying that we will just extend this smart proxy for other use >>>>> cases like users and others? >>>>> >>>> >>>> It all depends on the use case. If we're talking Foreman then yes. If >>>> something else, then we'll discuss it at the time, but it still may be >>>> able to be included. >>>> >>>> The IPA Foreman smart proxy is distinguished by a couple of things: >>>> >>>> - listens on port 8090, only on localhost >>>> - is unauthenticated >>>> - uses the /realm URI namespace >>>> >>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>> Dominic came up with only /realm/:domain is required and affects only >>>> hosts. >>>> >>>> We can stick this behind Apache to get authentication, even on a >>>> specific URI if we want/need to, but the basic REST stuff can still be >>>> handled by cherrypy. >>>> >>>> We'll need to balance complexity of mixing things vs the complexity of >>>> code duplication in multiple servers, unless we come up with some sort >>>> of REST server class where we just instantiate whatever we need. But >>>> that is for the future. >>>> >>>> rob >>> >>> But if it is specific for Foreman then it should have a generic name. I >>> agree with Martin here. >> >> I have the feeling we're in basic agreement. >> >> smartproxy is the Foreman name. I'm not pushing back against renaming, I'll >> have a new patch out shortly doing just that. I'm just pushing back against >> renaming it too deeply. I'm going with ipa-smartproxy. >> >> rob > The point is that smartproxy is a good name to be reused outside foreman. So > rather than assuming that "smartproxy" is foreman specific we can go with: > host proxy or host smart proxy - for this use case > and then > user proxy or user smart proxy - for use cases like User provisioning systems > and then > DNS proxy or DNS smart proxy - ... > and then > DHCP proxy or DHCP smart proxy - ... > and so on > > We need to establish a good pattern that we will be able to easily extend. +1, this was exactly my goal. It is easy to name and organize things now, difficult to do when it is live upstream and/or integrated with Foreman. I think the key for the right naming is a fact if this is really specific to Foreman or it is a truly general design usable also in other use cases. If Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. If general, we can go with freeipa-server-proxy-host freeipa-server-proxy-user freeipa-server-proxy-dhcp The proxies may share the framework and only expose the requested part of the tree - which in advance gives you an option for an API separation, as compared to general freeipa-server-smartproxy. Martin From abokovoy at redhat.com Mon Feb 17 10:32:04 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 12:32:04 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140213131253.GR8040@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> Message-ID: <20140217103204.GA16644@redhat.com> On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >>Through the review process, patches are getting shifted around, added, >>deleted, etc. So I'm now just going to be posting all the patches as an >>ordered set. The set attached is ordered according to my preferred merge >>order. It also places easy to review patches up front. I hope this helps >>reviewers. This format will definitely help me manage the patches. >> >>The first three patches should be very easy reviews and can be merged >>independently. >> >>All current patch critiques have, to my knowledge, been addressed in >>this latest series of patches. >I have tested all the patches altogether, including Web UI patches, and >everything works. > >I have set up a COPR repo for others to try: >http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ > >However, there is one issue which I was not yet able to pin-point in the >SLAPI plugins. During FreeIPA install and later on actual use I see >these in the dirsrv error log: > >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 >[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter >[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL >[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter >[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL > >Additionally, when slapi-nis is enabled, LDAP bind with identity from >compat tree fails for OTP use and succeeds for password authentication. > >In compat tree we are doing this trick: >1731 /* Otherwise force rewrite of the >SLAPI_BIND_TARGET_SDN 1732 * and let >other plugins to handle it. >1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ >1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); >1735 if (sdn != NULL) { >1736 slapi_sdn_free(&sdn); >1737 } >1738 sdn = slapi_sdn_new_dn_byref(ndn); >1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); >1740 ret = 0; >1741 } > >I tried to play with plugin precedence and it didn't really help. > >There is definitely a bug (or more) in ipa-pwd-extop in handling >authentication cases. Some progress on this investigation. Plugin precedence setting is broken in 389-ds. It is only set once, before running init function provided by the plugin and does not take into account all callbacks that the init function may register. As result, all these functions get classified with default precedence (50) and no configuration could change this, we get ipa-pwd-extop's pre-bind callback called before schemacompat's one, thus working on the compat entry DN instead of the new one. Since that entry has no userPassword attribute, OTP code refuses to accept any password. When user is allowed to use password auth along with OTP, the fact that there is no userPassword get ipa-pwd-extop plugin through the failure. schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of 389-ds code checks actual password. So we have two issues here: OTP code needs to gracefully ignore entries without userPassword set, and we need to be able to re-arrange schemacompat and ipa-pwd-extop precedence for pre-bind operation. I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on the latter. The messages from the log are not yet solved... -- / Alexander Bokovoy From simo at redhat.com Mon Feb 17 12:53:18 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Feb 2014 07:53:18 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530179DD.9060103@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <1392551399.22754.11.camel@willson.li.ssimo.org> <530179DD.9060103@redhat.com> Message-ID: <1392641598.22754.20.camel@willson.li.ssimo.org> On Sun, 2014-02-16 at 21:54 -0500, Dmitri Pal wrote: > On 02/16/2014 06:49 AM, Simo Sorce wrote: > > On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: > >> - listens on port 8090, only on localhost > >> - is unauthenticated > > Sorry to come late, but I am really at unease with this point. > > > > Can we do at least some form of simple authentication ? Even if it is a > > shared secret in a file accessible by both foreman and smartproxy ? > > > > Simo. > > > Simo, it is such by design. The design is that foreman can connect to the local proxy in a simple way. We can do it w/o exposing completely open interfaces to the local host. > The interface is local only and smart proxy explicitly checks that is it > called locally byt a local process. If it were using a unix socket that can be protected by permissions I would have no qualms, but afaik this is listening on a network port on localhost. It means *any* process can connect, they are all local. > The daemon by itself will then do a remote authenticate against IPA. > We trust Foreman machine to make the host changes and allow it to make > only these changes using access control rules on the server. > I do not think we need or can change anything here. > Any kind of authentication would significantly complicate integration > with Foreman and I frankly do not see a value in another level of > authentication. > I.e. how certs or key in the file makes it more secure? By allowing only the Foreman process to successfully connect. > I would rather suggest some SELInux policies that would open the REST api port to only > specific labels. Sure SELinux should certainly be used, but not everybody runs SELinux. A shared file with a secret that only foreman and the proxy can access is very simple, it can even be generated on the fly at stratup, w/o requiring any special manual setup. Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Mon Feb 17 14:35:41 2014 From: redhatrises at gmail.com (Darth Vader) Date: Mon, 17 Feb 2014 07:35:41 -0700 Subject: [Freeipa-devel] [Patch] [DOC] documentation patches Message-ID: Hi all, I have a couple of documentation patches that need to be reviewed. Probably the biggest one would be the upgrade procedure as what was in the docs was outdated. I can break these out in separate emails if needed. Trac tickets corresponding to patches are: https://fedorahosted.org/freeipa/ticket/2918 - 0001 https://fedorahosted.org/freeipa/ticket/4065 - 0002 https://fedorahosted.org/freeipa/ticket/4144 - 0003 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0001-doc-upgrade-procedure.patch Type: application/octet-stream Size: 2120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0002-doc-permanent-lockout-option.patch Type: application/octet-stream Size: 1238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0003-doc-installing_xml-consistency.patch Type: application/octet-stream Size: 3145 bytes Desc: not available URL: From pspacek at redhat.com Mon Feb 17 14:42:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 17 Feb 2014 15:42:57 +0100 Subject: [Freeipa-devel] [PATCH 0013-0014] Modify DNS tests to workaround bug in python-dns Message-ID: <53021FF1.2030206@redhat.com> Hello, I have found bug in python-dns and consequently another bug in LOC record parsing in IPA. See commit messages. My next patch for 'wait_for_dns' functionality (required for bind-dyndb-ldap 4.0) depends on these fixes. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0013-Fix-regular-expression-for-LOC-records-in-DNS.patch Type: text/x-patch Size: 1939 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0014-Modify-DNS-tests-with-LOC-records-to-workaround-bug-.patch Type: text/x-patch Size: 3476 bytes Desc: not available URL: From rcritten at redhat.com Mon Feb 17 15:54:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 10:54:32 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <1392551555.22754.12.camel@willson.li.ssimo.org> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FD5A24.4010601@redhat.com> <52FD7950.1020006@redhat.com> <52FD7CBF.6090706@redhat.com> <1392551555.22754.12.camel@willson.li.ssimo.org> Message-ID: <530230B8.6030304@redhat.com> Simo Sorce wrote: > On Thu, 2014-02-13 at 21:17 -0500, Dmitri Pal wrote: >> On 02/13/2014 09:02 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> Recently we had a ticket in SSSD >>>> https://fedorahosted.org/sssd/ticket/2217 >>>> Should we have a similar one for IPA client and especially for the >>>> proxy? >>>> Proxy will be a long term running process so dealing with the stale >>>> tickets becomes important for it if replica is re-installed. Is it >>>> something that is solved in API level or on the proxy level? >>>> Should we have a separate ticket for that? >>> >>> Using gss-proxy so it's not our problem. We never touch tickets. >>> >>> rob >>> >> Does gss proxy solve this problem? > > We do not have any special code to deal with this failure mode in > GSS-Proxy, please open a ticket. > > Simo. > > https://fedorahosted.org/gss-proxy/ticket/119 From dpal at redhat.com Mon Feb 17 16:27:33 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 11:27:33 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <1392641598.22754.20.camel@willson.li.ssimo.org> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <1392551399.22754.11.camel@willson.li.ssimo.org> <530179DD.9060103@redhat.com> <1392641598.22754.20.camel@willson.li.ssimo.org> Message-ID: <53023875.109@redhat.com> On 02/17/2014 07:53 AM, Simo Sorce wrote: > On Sun, 2014-02-16 at 21:54 -0500, Dmitri Pal wrote: >> On 02/16/2014 06:49 AM, Simo Sorce wrote: >>> On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: >>>> - listens on port 8090, only on localhost >>>> - is unauthenticated >>> Sorry to come late, but I am really at unease with this point. >>> >>> Can we do at least some form of simple authentication ? Even if it is a >>> shared secret in a file accessible by both foreman and smartproxy ? >>> >>> Simo. >>> >> Simo, it is such by design. > The design is that foreman can connect to the local proxy in a simple > way. We can do it w/o exposing completely open interfaces to the local > host. > >> The interface is local only and smart proxy explicitly checks that is it >> called locally byt a local process. > If it were using a unix socket that can be protected by permissions I > would have no qualms, but afaik this is listening on a network port on > localhost. It means *any* process can connect, they are all local. > >> The daemon by itself will then do a remote authenticate against IPA. >> We trust Foreman machine to make the host changes and allow it to make >> only these changes using access control rules on the server. >> I do not think we need or can change anything here. >> Any kind of authentication would significantly complicate integration >> with Foreman and I frankly do not see a value in another level of >> authentication. >> I.e. how certs or key in the file makes it more secure? > By allowing only the Foreman process to successfully connect. > >> I would rather suggest some SELInux policies that would open the REST api port to only >> specific labels. > Sure SELinux should certainly be used, but not everybody runs SELinux. Right, but do we care? If you disable SELInux you open it to the whole host this is your choice. > A shared file with a secret that only foreman and the proxy can access > is very simple, it can even be generated on the fly at stratup, w/o > requiring any special manual setup. Then you need to deal with permissions and labeling of this file and make sure that only these two can access again based on SELinux labels. And if you turn SELinux then other applications would be able to access if they can su to that user. IMO we should explore local socket path if possible first and make sure that only foreman can connect, then rely on SELInux and only if these options get exhausted start adding complexity to do the authentication of the API using shared secrets or certs. Keep in mind that the authentication was explicitly out of scope for the first round. I am generally no against it as next step. I am just against it being jammed in now. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Mon Feb 17 16:36:49 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Feb 2014 11:36:49 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53023875.109@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <1392551399.22754.11.camel@willson.li.ssimo.org> <530179DD.9060103@redhat.com> <1392641598.22754.20.camel@willson.li.ssimo.org> <53023875.109@redhat.com> Message-ID: <1392655009.22754.61.camel@willson.li.ssimo.org> On Mon, 2014-02-17 at 11:27 -0500, Dmitri Pal wrote: > On 02/17/2014 07:53 AM, Simo Sorce wrote: > > On Sun, 2014-02-16 at 21:54 -0500, Dmitri Pal wrote: > >> On 02/16/2014 06:49 AM, Simo Sorce wrote: > >>> On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: > >>>> - listens on port 8090, only on localhost > >>>> - is unauthenticated > >>> Sorry to come late, but I am really at unease with this point. > >>> > >>> Can we do at least some form of simple authentication ? Even if it is a > >>> shared secret in a file accessible by both foreman and smartproxy ? > >>> > >>> Simo. > >>> > >> Simo, it is such by design. > > The design is that foreman can connect to the local proxy in a simple > > way. We can do it w/o exposing completely open interfaces to the local > > host. > > > >> The interface is local only and smart proxy explicitly checks that is it > >> called locally byt a local process. > > If it were using a unix socket that can be protected by permissions I > > would have no qualms, but afaik this is listening on a network port on > > localhost. It means *any* process can connect, they are all local. > > > >> The daemon by itself will then do a remote authenticate against IPA. > >> We trust Foreman machine to make the host changes and allow it to make > >> only these changes using access control rules on the server. > >> I do not think we need or can change anything here. > >> Any kind of authentication would significantly complicate integration > >> with Foreman and I frankly do not see a value in another level of > >> authentication. > >> I.e. how certs or key in the file makes it more secure? > > By allowing only the Foreman process to successfully connect. > > > >> I would rather suggest some SELInux policies that would open the REST api port to only > >> specific labels. > > Sure SELinux should certainly be used, but not everybody runs SELinux. > > Right, but do we care? If you disable SELInux you open it to the whole > host this is your choice. SELinux is always optional, it is an add-on layer. It is ok to recommend it, but not to require it for basic protection. Sometimes we also need to put it in permissive to work around bugs, so it cannot be the only protection available. > > A shared file with a secret that only foreman and the proxy can access > > is very simple, it can even be generated on the fly at stratup, w/o > > requiring any special manual setup. > > > Then you need to deal with permissions and labeling of this file and > make sure that only these two can access again based on SELinux labels. > And if you turn SELinux then other applications would be able to access > if they can su to that user. No, this is an incorrect characterization. Although it is true we will also add SELinux protections on a file, the first thing that matters in files are permissions. Of course the file will need to be readable by the user nuder which foreman runs and the user under which the smartproxy runs. But that is doen by making the file readable by only those 2 users, either by adding an ACL or by putting the 2 users in a group and making the file readable only by the group. In either case SELinux is not the gate, it is an added protection. Aside: If an application can "su to a user" it is game over, but that is not the case in normal circumstances so not something we need to worry about. > IMO we should explore local socket path if possible first and make sure > that only foreman can connect, then rely on SELInux and only if these > options get exhausted start adding complexity to do the authentication > of the API using shared secrets or certs. Keep in mind that the > authentication was explicitly out of scope for the first round. I am > generally no against it as next step. I am just against it being jammed > in now. not authenticating is ok at a prototype phase. I am bringing it up now because we are clearly getting out of prototype and we want to push upstream. I cannot sanction something for upstream that works unauthenticated when exposing a port over the network, even if we listen just to 127.0.0.1. Again SELinux is add-on, cannot be the only barrier, for the reasons stated above. Big +1 to using a socket if possible. [still has the same problems as a file (permissions and labels need to be right) but that is also why it can be instead of adding shared secret ot similar, it has protections a network port can't give]. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Mon Feb 17 16:49:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 17 Feb 2014 11:49:43 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <1392655783.12450.11.camel@localhost.localdomain> On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: > Through the review process, patches are getting shifted around, added, > deleted, etc. So I'm now just going to be posting all the patches as an > ordered set. The set attached is ordered according to my preferred merge > order. It also places easy to review patches up front. I hope this helps > reviewers. This format will definitely help me manage the patches. > > The first three patches should be very easy reviews and can be merged > independently. > > All current patch critiques have, to my knowledge, been addressed in > this latest series of patches. Attached are the four remaining patches that have not yet been merged. I have re-ordered them so that reviews can continue in parallel while I track down the two remaining bugs in ipa-pwd-extop. This means the first two patches should be ready for review/merger. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-HOTP-support.patch Type: text/x-patch Size: 20671 bytes Desc: not available URL: From abokovoy at redhat.com Mon Feb 17 17:17:10 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 19:17:10 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392655783.12450.11.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> Message-ID: <20140217171710.GG16644@redhat.com> On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > >Attached are the four remaining patches that have not yet been merged. I >have re-ordered them so that reviews can continue in parallel while I >track down the two remaining bugs in ipa-pwd-extop. This means the first >two patches should be ready for review/merger. 0004 -- ACK. SLAPI_PLUGIN_OPRETURN is used by 389-ds to notify post-callbacks of the result of the actual operation. In the BIND case it is set before running post-callbacks to the result of actual bind operation so that post-callbacks know what has happened and can fetch it. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Feb 17 17:37:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 19:37:31 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392655783.12450.11.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> Message-ID: <20140217173731.GH16644@redhat.com> On patch 0001: On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >index 9cb9d71a81bc1f1089017a2236b4b7b94946ed35..8ab09e92b64b6a2f31c9c25d61a7dacc9fa608e8 100644 >--- a/VERSION >+++ b/VERSION >@@ -90,4 +90,4 @@ IPA_DATA_VERSION=20100614120000 > ######################################################## > IPA_API_VERSION_MAJOR=2 > IPA_API_VERSION_MINOR=73 >-# Last change: pviktori - Managed permissions >+# Last change: npmccallum - HOTP support Please also update IPA_API_VERSION_MINOR to the next one (74) -- / Alexander Bokovoy From npmccallum at redhat.com Mon Feb 17 17:44:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 17 Feb 2014 12:44:16 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140217173731.GH16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> <20140217173731.GH16644@redhat.com> Message-ID: <1392659056.12450.13.camel@localhost.localdomain> On Mon, 2014-02-17 at 19:37 +0200, Alexander Bokovoy wrote: > On patch 0001: > > On Mon, 17 Feb 2014, Nathaniel McCallum wrote: > >index 9cb9d71a81bc1f1089017a2236b4b7b94946ed35..8ab09e92b64b6a2f31c9c25d61a7dacc9fa608e8 100644 > >--- a/VERSION > >+++ b/VERSION > >@@ -90,4 +90,4 @@ IPA_DATA_VERSION=20100614120000 > > ######################################################## > > IPA_API_VERSION_MAJOR=2 > > IPA_API_VERSION_MINOR=73 > >-# Last change: pviktori - Managed permissions > >+# Last change: npmccallum - HOTP support > Please also update IPA_API_VERSION_MINOR to the next one (74) Fixed. Also, I removed the oktodo() function from patch 0004 as its contents were two lines and it was only used one place. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-HOTP-support.patch Type: text/x-patch Size: 20756 bytes Desc: not available URL: From abokovoy at redhat.com Mon Feb 17 17:44:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 19:44:49 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392655783.12450.11.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> Message-ID: <20140217174449.GI16644@redhat.com> On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >>From 357cc6a40c58f3f88f8e86c5224f2c042ab974d8 Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Mon, 16 Dec 2013 16:19:08 -0500 >Subject: [PATCH 2/4] Add OTP last token plugin > >This plugin prevents the deletion or deactivation of the last >valid token for a user. This prevents the user from migrating >back to single factor authentication once OTP has been enabled. > >Thanks to Mark Reynolds for helping me with this patch. >--- > daemons/configure.ac | 1 + > daemons/ipa-slapi-plugins/Makefile.am | 1 + > .../ipa-otp-lasttoken/Makefile.am | 28 ++++ > .../ipa-otp-lasttoken/ipa-otp-lasttoken.sym | 1 + > .../ipa-otp-lasttoken/ipa_otp_lasttoken.c | 183 +++++++++++++++++++++ > .../ipa-otp-lasttoken/otp-lasttoken-conf.ldif | 15 ++ > freeipa.spec.in | 2 + > ipaserver/install/dsinstance.py | 4 + > 8 files changed, 235 insertions(+) > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/otp-lasttoken-conf.ldif > >diff --git a/daemons/configure.ac b/daemons/configure.ac >index e5bf7f552c0d85acc7ae14e3da05ab8c948daa93..b4507a6d972f854331925e72869898576bdfd76f 100644 >--- a/daemons/configure.ac >+++ b/daemons/configure.ac >@@ -314,6 +314,7 @@ AC_CONFIG_FILES([ > ipa-slapi-plugins/ipa-dns/Makefile > ipa-slapi-plugins/ipa-enrollment/Makefile > ipa-slapi-plugins/ipa-lockout/Makefile >+ ipa-slapi-plugins/ipa-otp-lasttoken/Makefile > ipa-slapi-plugins/ipa-pwd-extop/Makefile > ipa-slapi-plugins/ipa-extdom-extop/Makefile > ipa-slapi-plugins/ipa-winsync/Makefile >diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am >index 40725d2259d09010d2f82381543fc77d84435040..06e6ee8b86f138cce05f2184ac98c39ffaf9757f 100644 >--- a/daemons/ipa-slapi-plugins/Makefile.am >+++ b/daemons/ipa-slapi-plugins/Makefile.am >@@ -7,6 +7,7 @@ SUBDIRS = \ > ipa-enrollment \ > ipa-lockout \ > ipa-modrdn \ >+ ipa-otp-lasttoken \ > ipa-pwd-extop \ > ipa-extdom-extop \ > ipa-uuid \ >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am >new file mode 100644 >index 0000000000000000000000000000000000000000..1e3869bfda9f8fd14cd4d93d0d466780932ac40f >--- /dev/null >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am >@@ -0,0 +1,28 @@ >+MAINTAINERCLEANFILES = *~ Makefile.in >+PLUGIN_COMMON_DIR = ../common >+AM_CPPFLAGS = \ >+ -I. \ >+ -I$(srcdir) \ >+ -I$(srcdir)/../libotp \ >+ -I$(PLUGIN_COMMON_DIR) \ >+ -I/usr/include/dirsrv \ >+ -DPREFIX=\""$(prefix)"\" \ >+ -DBINDIR=\""$(bindir)"\" \ >+ -DLIBDIR=\""$(libdir)"\" \ >+ -DLIBEXECDIR=\""$(libexecdir)"\" \ >+ -DDATADIR=\""$(datadir)"\" \ >+ $(AM_CFLAGS) \ >+ $(LDAP_CFLAGS) \ >+ $(WARN_CFLAGS) >+ >+plugindir = $(libdir)/dirsrv/plugins >+plugin_LTLIBRARIES = libipa_otp_lasttoken.la >+libipa_otp_lasttoken_la_SOURCES = ipa_otp_lasttoken.c >+libipa_otp_lasttoken_la_LDFLAGS = -avoid-version -export-symbols ipa-otp-lasttoken.sym >+libipa_otp_lasttoken_la_LIBADD = \ >+ $(LDAP_LIBS) \ >+ $(builddir)/../libotp/libotp.la >+ >+appdir = $(IPA_DATA_DIR) >+app_DATA = otp-lasttoken-conf.ldif >+EXTRA_DIST = $(app_DATA) >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym >new file mode 100644 >index 0000000000000000000000000000000000000000..e32dc32f5693547bf604480490f42511368fdb81 >--- /dev/null >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym >@@ -0,0 +1 @@ >+ipa_otp_lasttoken_init >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >new file mode 100644 >index 0000000000000000000000000000000000000000..4abeb671e29b40cdf9b005ff5bc6b12c6d91bb30 >--- /dev/null >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >@@ -0,0 +1,183 @@ >+/** BEGIN COPYRIGHT BLOCK >+ * This program is free software; you can redistribute it and/or modify >+ * it under the terms of the GNU General Public License as published by >+ * the Free Software Foundation, either version 3 of the License, or >+ * (at your option) any later version. >+ * >+ * This program is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >+ * GNU General Public License for more details. >+ * >+ * You should have received a copy of the GNU General Public License >+ * along with this program. If not, see . >+ * >+ * Additional permission under GPLv3 section 7: >+ * >+ * In the following paragraph, "GPL" means the GNU General Public >+ * License, version 3 or any later version, and "Non-GPL Code" means >+ * code that is governed neither by the GPL nor a license >+ * compatible with the GPL. >+ * >+ * You may link the code of this Program with Non-GPL Code and convey >+ * linked combinations including the two, provided that such Non-GPL >+ * Code only links to the code of this Program through those well >+ * defined interfaces identified in the file named EXCEPTION found in >+ * the source code files (the "Approved Interfaces"). The files of >+ * Non-GPL Code may instantiate templates or use macros or inline >+ * functions from the Approved Interfaces without causing the resulting >+ * work to be covered by the GPL. Only the copyright holders of this >+ * Program may make changes or additions to the list of Approved >+ * Interfaces. >+ * >+ * Authors: >+ * Nathaniel McCallum >+ * >+ * Copyright (C) 2013 Red Hat, Inc. >+ * All rights reserved. >+ * END COPYRIGHT BLOCK **/ >+ >+#ifdef HAVE_CONFIG_H >+# include >+#endif >+ >+#include >+#include >+ >+#define PLUGIN_NAME "ipa-otp-lasttoken" >+#define LOG(sev, ...) \ >+ slapi_log_error(SLAPI_LOG_ ## sev, PLUGIN_NAME, \ >+ "%s: %s\n", __func__, __VA_ARGS__), -1 >+ >+static void *plugin_id; >+static const Slapi_PluginDesc preop_desc = { >+ PLUGIN_NAME, >+ "FreeIPA", >+ "FreeIPA/1.0", >+ "Protect the user's last active token" >+}; >+ >+static bool >+target_is_only_enabled_token(Slapi_PBlock *pb) >+{ >+ Slapi_DN *target_sdn = NULL; >+ Slapi_DN *token_sdn = NULL; >+ struct otptoken **tokens; >+ char *user_dn = NULL; >+ bool match; >+ >+ /* Ignore internal operations. */ >+ if (slapi_op_internal(pb)) >+ return false; >+ >+ /* Get the current user's SDN. */ >+ slapi_pblock_get(pb, SLAPI_CONN_DN, &user_dn); >+ if (user_dn == NULL) >+ return false; >+ >+ /* Get the SDN of the only enabled token. */ >+ tokens = otptoken_find(plugin_id, user_dn, NULL, true, NULL); >+ if (tokens != NULL && tokens[0] != NULL && tokens[1] == NULL) >+ token_sdn = slapi_sdn_dup(otptoken_get_sdn(tokens[0])); >+ otptoken_free_array(tokens); >+ if (token_sdn == NULL) >+ return false; >+ >+ /* Get the target SDN. */ >+ slapi_pblock_get(pb, SLAPI_TARGET_SDN, &target_sdn); >+ if (target_sdn == NULL) { >+ slapi_sdn_free(&token_sdn); >+ return false; >+ } >+ >+ /* Does the target SDN match the only enabled token SDN? */ >+ match = slapi_sdn_compare(token_sdn, target_sdn) == 0; >+ slapi_sdn_free(&token_sdn); >+ return match; >+} >+ >+static inline int >+send_error(Slapi_PBlock *pb, int rc, char *errstr) >+{ >+ slapi_send_ldap_result(pb, rc, NULL, errstr, 0, NULL); >+ slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >+ return rc; >+} >+ >+static int >+preop_del(Slapi_PBlock *pb) >+{ >+ if (!target_is_only_enabled_token(pb)) >+ return 0; >+ >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >+ "Can't delete last active token"); >+} >+ >+static int >+preop_mod(Slapi_PBlock *pb) >+{ >+ LDAPMod **mods = NULL; >+ >+ if (!target_is_only_enabled_token(pb)) >+ return 0; >+ >+ /* Do not permit deactivation of the last active token. */ >+ slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &mods); >+ for (int i = 0; mods != NULL && mods[i] != NULL; i++) { >+ if (strcasecmp(mods[i]->mod_type, "ipatokenDisabled") == 0) { >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >+ "Can't disable last active token"); >+ } >+ >+ if (strcasecmp(mods[i]->mod_type, "ipatokenOwner") == 0) { >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >+ "Can't change last active token's owner"); >+ } >+ >+ if (strcasecmp(mods[i]->mod_type, "ipatokenNotBefore") == 0) { >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >+ "Can't change last active token's start time"); >+ } >+ >+ if (strcasecmp(mods[i]->mod_type, "ipatokenNotAfter") == 0) { >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >+ "Can't change last active token's end time"); >+ } >+ } >+ >+ return 0; >+} >+ >+static int >+preop_init(Slapi_PBlock *pb) >+{ >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_VERSION, SLAPI_PLUGIN_VERSION_01)) >+ goto error; >+ >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_DESCRIPTION, (void *) &preop_desc)) >+ goto error; >+ >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_BE_TXN_PRE_DELETE_FN, preop_del)) >+ goto error; >+ >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_BE_TXN_PRE_MODIFY_FN, preop_mod)) >+ goto error; >+ >+ return 0; >+ >+error: >+ return LOG(FATAL, "failed to register be_txn_pre_op plugin"); >+} >+ >+int >+ipa_otp_lasttoken_init(Slapi_PBlock *pb) >+{ >+ slapi_pblock_get(pb, SLAPI_PLUGIN_IDENTITY, &plugin_id); >+ >+ if (slapi_register_plugin("betxnpreoperation", 1, __func__, preop_init, >+ PLUGIN_NAME, NULL, plugin_id)) >+ return LOG(FATAL, "failed to register plugin"); I think the order is wrong here and it might be the cause for those messages I've been getting in the dirsrv error logs. You need to fetch plugin identity, then set version and description, set callbacks, and only then register the plugin. Finally, preop_init() will be called and it should set the callbacks only. -- / Alexander Bokovoy From rcritten at redhat.com Mon Feb 17 18:21:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 13:21:03 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5301BE93.4020203@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> Message-ID: <5302530F.8010705@redhat.com> Martin Kosek wrote: > On 02/14/2014 11:26 PM, Dmitri Pal wrote: >> On 02/14/2014 05:07 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>>> ... >>>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>>> complete REST >>>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>>> future-compatible? (The API itself seems to be a good subset of a >>>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>>> limitations for >>>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>>>> probably a good >>>>>>>>>>>> thing to save that name. >>>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a complete REST >>>>>>>>>>> interface >>>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to track that: >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>> I think I've addressed most of Petr's suggestions with the exception >>>>>>>>>> of the >>>>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>>>> pretty >>>>>>>>>> much >>>>>>>>>> standard in IPA calls. >>>>>>>>>> >>>>>>>>>> The gssproxy.conf.snippet just makes it easier to copy/paste. I can >>>>>>>>>> drop it if >>>>>>>>>> you want, I suppose it is duplication. >>>>>>>>>> >>>>>>>>>> Note that I ran this past the Foreman design again and as a result >>>>>>>>>> added >>>>>>>>>> another interface, /realm. It was my understanding that this Foreman >>>>>>>>>> design >>>>>>>>>> wasn't set into stone but a patch is working its way through their >>>>>>>>>> system that >>>>>>>>>> followed the spec so I went ahead and added it. It isn't a big deal, >>>>>>>>>> the Host() >>>>>>>>>> class handles it out of the box. >>>>>>>>>> >>>>>>>>>> I also updated the design page a bit to reflect some of the changes >>>>>>>>>> made. >>>>>>>>>> >>>>>>>>>> Right now there are no plans to backport python-kerberos to F20. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> I will leave functional testing to others, I just read the code. I am >>>>>>>>> still >>>>>>>>> quite concerned about the positioning, naming and "branding" of this >>>>>>>>> feature. >>>>>>>>> >>>>>>>>> 1) Package name >>>>>>>>> >>>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for Foreman >>>>>>>>> integration >>>>>>>>> use case. >>>>>>>>> >>>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only if we >>>>>>>>> plan to use >>>>>>>>> this proxy for all other projects. I.e. if we one day implement user >>>>>>>>> smartproxy, it would need to be part of this otherwise it would lead >>>>>>>>> to strange >>>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be named >>>>>>>>> differently? >>>>>>>>> >>>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>>> >>>>>>>>> 2) ipa-rest stuff >>>>>>>>> >>>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest >>>>>>>>> man. >>>>>>>>> However, I have the same concerns as above. This is too general >>>>>>>>> and it >>>>>>>>> may >>>>>>>>> conflict with future core server needs (like when we implement core >>>>>>>>> IPA REST >>>>>>>>> interface - #4168). Let us name it consistently with package name: >>>>>>>>> >>>>>>>>> ipa-smartproxy.service >>>>>>>>> ipa-smartproxy-hosts.service >>>>>>>>> ipa-foreman-smartproxy.service >>>>>>>>> >>>>>>>>> The same for binary, man, ... >>>>>>>>> >>>>>>>>> 3) Man pages >>>>>>>>> >>>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>>> general. >>>>>>>>> >>>>>>>>> To sum it up - let us chose one name/brand of this feature and let's >>>>>>>>> use it >>>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>>> subdirectory >>>>>>>>> in git, >>>>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>>>> >>>>>>>>> Martin >>>>>>>> +1 >>>>>>>> >>>>>>>> I think it should be "host" >>>>>>>> >>>>>>>> ipa-host-smartproxy >>>>>>>> >>>>>>>> then we will be able to add other smart proxies and then combine them >>>>>>>> into one ipa-smartproxy package later if needed. >>>>>>>> >>>>>>> >>>>>>> This would imply we actually run separate servers for the various >>>>>>> commands. Given that right now we're focused on just the Foreman use >>>>>>> cases I think ipa-smartproxy is sufficient. >>>>>>> >>>>>>> For our purposes the smartproxy is just a thin wrapper around the IPA >>>>>>> API. It is extensible for our needs, we just don't need to yet. But if >>>>>>> we did, we'd do so within the cherrypy server and everything would be >>>>>>> self-contained. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Are you saying that we will just extend this smart proxy for other use >>>>>> cases like users and others? >>>>>> >>>>> >>>>> It all depends on the use case. If we're talking Foreman then yes. If >>>>> something else, then we'll discuss it at the time, but it still may be >>>>> able to be included. >>>>> >>>>> The IPA Foreman smart proxy is distinguished by a couple of things: >>>>> >>>>> - listens on port 8090, only on localhost >>>>> - is unauthenticated >>>>> - uses the /realm URI namespace >>>>> >>>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>>> Dominic came up with only /realm/:domain is required and affects only >>>>> hosts. >>>>> >>>>> We can stick this behind Apache to get authentication, even on a >>>>> specific URI if we want/need to, but the basic REST stuff can still be >>>>> handled by cherrypy. >>>>> >>>>> We'll need to balance complexity of mixing things vs the complexity of >>>>> code duplication in multiple servers, unless we come up with some sort >>>>> of REST server class where we just instantiate whatever we need. But >>>>> that is for the future. >>>>> >>>>> rob >>>> >>>> But if it is specific for Foreman then it should have a generic name. I >>>> agree with Martin here. >>> >>> I have the feeling we're in basic agreement. >>> >>> smartproxy is the Foreman name. I'm not pushing back against renaming, I'll >>> have a new patch out shortly doing just that. I'm just pushing back against >>> renaming it too deeply. I'm going with ipa-smartproxy. >>> >>> rob >> The point is that smartproxy is a good name to be reused outside foreman. So >> rather than assuming that "smartproxy" is foreman specific we can go with: >> host proxy or host smart proxy - for this use case >> and then >> user proxy or user smart proxy - for use cases like User provisioning systems >> and then >> DNS proxy or DNS smart proxy - ... >> and then >> DHCP proxy or DHCP smart proxy - ... >> and so on >> >> We need to establish a good pattern that we will be able to easily extend. > > +1, this was exactly my goal. It is easy to name and organize things now, > difficult to do when it is live upstream and/or integrated with Foreman. > > I think the key for the right naming is a fact if this is really specific to > Foreman or it is a truly general design usable also in other use cases. If > Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. > > If general, we can go with > > freeipa-server-proxy-host > freeipa-server-proxy-user > freeipa-server-proxy-dhcp > > The proxies may share the framework and only expose the requested part of the > tree - which in advance gives you an option for an API separation, as compared > to general freeipa-server-smartproxy. I still don't get the point of this. Are you proposing having 3 different servers, each providing a unique service? Or one service that one can turn on/off features, or something else? Do you envision this as 3 separate subpackages? There is no "framework" in my current patch, it is a cherrypy server that exposes parts of IPA on a given URI. It is the thinnest of layers. rob From npmccallum at redhat.com Mon Feb 17 18:42:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 17 Feb 2014 13:42:28 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140217174449.GI16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> <20140217174449.GI16644@redhat.com> Message-ID: <1392662548.12450.15.camel@localhost.localdomain> On Mon, 2014-02-17 at 19:44 +0200, Alexander Bokovoy wrote: > On Mon, 17 Feb 2014, Nathaniel McCallum wrote: > >>From 357cc6a40c58f3f88f8e86c5224f2c042ab974d8 Mon Sep 17 00:00:00 2001 > >From: Nathaniel McCallum > >Date: Mon, 16 Dec 2013 16:19:08 -0500 > >Subject: [PATCH 2/4] Add OTP last token plugin > > > >This plugin prevents the deletion or deactivation of the last > >valid token for a user. This prevents the user from migrating > >back to single factor authentication once OTP has been enabled. > > > >Thanks to Mark Reynolds for helping me with this patch. > >--- > > daemons/configure.ac | 1 + > > daemons/ipa-slapi-plugins/Makefile.am | 1 + > > .../ipa-otp-lasttoken/Makefile.am | 28 ++++ > > .../ipa-otp-lasttoken/ipa-otp-lasttoken.sym | 1 + > > .../ipa-otp-lasttoken/ipa_otp_lasttoken.c | 183 +++++++++++++++++++++ > > .../ipa-otp-lasttoken/otp-lasttoken-conf.ldif | 15 ++ > > freeipa.spec.in | 2 + > > ipaserver/install/dsinstance.py | 4 + > > 8 files changed, 235 insertions(+) > > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am > > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym > > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c > > create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/otp-lasttoken-conf.ldif > > > >diff --git a/daemons/configure.ac b/daemons/configure.ac > >index e5bf7f552c0d85acc7ae14e3da05ab8c948daa93..b4507a6d972f854331925e72869898576bdfd76f 100644 > >--- a/daemons/configure.ac > >+++ b/daemons/configure.ac > >@@ -314,6 +314,7 @@ AC_CONFIG_FILES([ > > ipa-slapi-plugins/ipa-dns/Makefile > > ipa-slapi-plugins/ipa-enrollment/Makefile > > ipa-slapi-plugins/ipa-lockout/Makefile > >+ ipa-slapi-plugins/ipa-otp-lasttoken/Makefile > > ipa-slapi-plugins/ipa-pwd-extop/Makefile > > ipa-slapi-plugins/ipa-extdom-extop/Makefile > > ipa-slapi-plugins/ipa-winsync/Makefile > >diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am > >index 40725d2259d09010d2f82381543fc77d84435040..06e6ee8b86f138cce05f2184ac98c39ffaf9757f 100644 > >--- a/daemons/ipa-slapi-plugins/Makefile.am > >+++ b/daemons/ipa-slapi-plugins/Makefile.am > >@@ -7,6 +7,7 @@ SUBDIRS = \ > > ipa-enrollment \ > > ipa-lockout \ > > ipa-modrdn \ > >+ ipa-otp-lasttoken \ > > ipa-pwd-extop \ > > ipa-extdom-extop \ > > ipa-uuid \ > >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am > >new file mode 100644 > >index 0000000000000000000000000000000000000000..1e3869bfda9f8fd14cd4d93d0d466780932ac40f > >--- /dev/null > >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am > >@@ -0,0 +1,28 @@ > >+MAINTAINERCLEANFILES = *~ Makefile.in > >+PLUGIN_COMMON_DIR = ../common > >+AM_CPPFLAGS = \ > >+ -I. \ > >+ -I$(srcdir) \ > >+ -I$(srcdir)/../libotp \ > >+ -I$(PLUGIN_COMMON_DIR) \ > >+ -I/usr/include/dirsrv \ > >+ -DPREFIX=\""$(prefix)"\" \ > >+ -DBINDIR=\""$(bindir)"\" \ > >+ -DLIBDIR=\""$(libdir)"\" \ > >+ -DLIBEXECDIR=\""$(libexecdir)"\" \ > >+ -DDATADIR=\""$(datadir)"\" \ > >+ $(AM_CFLAGS) \ > >+ $(LDAP_CFLAGS) \ > >+ $(WARN_CFLAGS) > >+ > >+plugindir = $(libdir)/dirsrv/plugins > >+plugin_LTLIBRARIES = libipa_otp_lasttoken.la > >+libipa_otp_lasttoken_la_SOURCES = ipa_otp_lasttoken.c > >+libipa_otp_lasttoken_la_LDFLAGS = -avoid-version -export-symbols ipa-otp-lasttoken.sym > >+libipa_otp_lasttoken_la_LIBADD = \ > >+ $(LDAP_LIBS) \ > >+ $(builddir)/../libotp/libotp.la > >+ > >+appdir = $(IPA_DATA_DIR) > >+app_DATA = otp-lasttoken-conf.ldif > >+EXTRA_DIST = $(app_DATA) > >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym > >new file mode 100644 > >index 0000000000000000000000000000000000000000..e32dc32f5693547bf604480490f42511368fdb81 > >--- /dev/null > >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym > >@@ -0,0 +1 @@ > >+ipa_otp_lasttoken_init > >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c > >new file mode 100644 > >index 0000000000000000000000000000000000000000..4abeb671e29b40cdf9b005ff5bc6b12c6d91bb30 > >--- /dev/null > >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c > >@@ -0,0 +1,183 @@ > >+/** BEGIN COPYRIGHT BLOCK > >+ * This program is free software; you can redistribute it and/or modify > >+ * it under the terms of the GNU General Public License as published by > >+ * the Free Software Foundation, either version 3 of the License, or > >+ * (at your option) any later version. > >+ * > >+ * This program is distributed in the hope that it will be useful, > >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of > >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >+ * GNU General Public License for more details. > >+ * > >+ * You should have received a copy of the GNU General Public License > >+ * along with this program. If not, see . > >+ * > >+ * Additional permission under GPLv3 section 7: > >+ * > >+ * In the following paragraph, "GPL" means the GNU General Public > >+ * License, version 3 or any later version, and "Non-GPL Code" means > >+ * code that is governed neither by the GPL nor a license > >+ * compatible with the GPL. > >+ * > >+ * You may link the code of this Program with Non-GPL Code and convey > >+ * linked combinations including the two, provided that such Non-GPL > >+ * Code only links to the code of this Program through those well > >+ * defined interfaces identified in the file named EXCEPTION found in > >+ * the source code files (the "Approved Interfaces"). The files of > >+ * Non-GPL Code may instantiate templates or use macros or inline > >+ * functions from the Approved Interfaces without causing the resulting > >+ * work to be covered by the GPL. Only the copyright holders of this > >+ * Program may make changes or additions to the list of Approved > >+ * Interfaces. > >+ * > >+ * Authors: > >+ * Nathaniel McCallum > >+ * > >+ * Copyright (C) 2013 Red Hat, Inc. > >+ * All rights reserved. > >+ * END COPYRIGHT BLOCK **/ > >+ > >+#ifdef HAVE_CONFIG_H > >+# include > >+#endif > >+ > >+#include > >+#include > >+ > >+#define PLUGIN_NAME "ipa-otp-lasttoken" > >+#define LOG(sev, ...) \ > >+ slapi_log_error(SLAPI_LOG_ ## sev, PLUGIN_NAME, \ > >+ "%s: %s\n", __func__, __VA_ARGS__), -1 > >+ > >+static void *plugin_id; > >+static const Slapi_PluginDesc preop_desc = { > >+ PLUGIN_NAME, > >+ "FreeIPA", > >+ "FreeIPA/1.0", > >+ "Protect the user's last active token" > >+}; > >+ > >+static bool > >+target_is_only_enabled_token(Slapi_PBlock *pb) > >+{ > >+ Slapi_DN *target_sdn = NULL; > >+ Slapi_DN *token_sdn = NULL; > >+ struct otptoken **tokens; > >+ char *user_dn = NULL; > >+ bool match; > >+ > >+ /* Ignore internal operations. */ > >+ if (slapi_op_internal(pb)) > >+ return false; > >+ > >+ /* Get the current user's SDN. */ > >+ slapi_pblock_get(pb, SLAPI_CONN_DN, &user_dn); > >+ if (user_dn == NULL) > >+ return false; > >+ > >+ /* Get the SDN of the only enabled token. */ > >+ tokens = otptoken_find(plugin_id, user_dn, NULL, true, NULL); > >+ if (tokens != NULL && tokens[0] != NULL && tokens[1] == NULL) > >+ token_sdn = slapi_sdn_dup(otptoken_get_sdn(tokens[0])); > >+ otptoken_free_array(tokens); > >+ if (token_sdn == NULL) > >+ return false; > >+ > >+ /* Get the target SDN. */ > >+ slapi_pblock_get(pb, SLAPI_TARGET_SDN, &target_sdn); > >+ if (target_sdn == NULL) { > >+ slapi_sdn_free(&token_sdn); > >+ return false; > >+ } > >+ > >+ /* Does the target SDN match the only enabled token SDN? */ > >+ match = slapi_sdn_compare(token_sdn, target_sdn) == 0; > >+ slapi_sdn_free(&token_sdn); > >+ return match; > >+} > >+ > >+static inline int > >+send_error(Slapi_PBlock *pb, int rc, char *errstr) > >+{ > >+ slapi_send_ldap_result(pb, rc, NULL, errstr, 0, NULL); > >+ slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > >+ return rc; > >+} > >+ > >+static int > >+preop_del(Slapi_PBlock *pb) > >+{ > >+ if (!target_is_only_enabled_token(pb)) > >+ return 0; > >+ > >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >+ "Can't delete last active token"); > >+} > >+ > >+static int > >+preop_mod(Slapi_PBlock *pb) > >+{ > >+ LDAPMod **mods = NULL; > >+ > >+ if (!target_is_only_enabled_token(pb)) > >+ return 0; > >+ > >+ /* Do not permit deactivation of the last active token. */ > >+ slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &mods); > >+ for (int i = 0; mods != NULL && mods[i] != NULL; i++) { > >+ if (strcasecmp(mods[i]->mod_type, "ipatokenDisabled") == 0) { > >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >+ "Can't disable last active token"); > >+ } > >+ > >+ if (strcasecmp(mods[i]->mod_type, "ipatokenOwner") == 0) { > >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >+ "Can't change last active token's owner"); > >+ } > >+ > >+ if (strcasecmp(mods[i]->mod_type, "ipatokenNotBefore") == 0) { > >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >+ "Can't change last active token's start time"); > >+ } > >+ > >+ if (strcasecmp(mods[i]->mod_type, "ipatokenNotAfter") == 0) { > >+ return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >+ "Can't change last active token's end time"); > >+ } > >+ } > >+ > >+ return 0; > >+} > >+ > >+static int > >+preop_init(Slapi_PBlock *pb) > >+{ > >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_VERSION, SLAPI_PLUGIN_VERSION_01)) > >+ goto error; > >+ > >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_DESCRIPTION, (void *) &preop_desc)) > >+ goto error; > >+ > >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_BE_TXN_PRE_DELETE_FN, preop_del)) > >+ goto error; > >+ > >+ if (slapi_pblock_set(pb, SLAPI_PLUGIN_BE_TXN_PRE_MODIFY_FN, preop_mod)) > >+ goto error; > >+ > >+ return 0; > >+ > >+error: > >+ return LOG(FATAL, "failed to register be_txn_pre_op plugin"); > >+} > >+ > >+int > >+ipa_otp_lasttoken_init(Slapi_PBlock *pb) > >+{ > >+ slapi_pblock_get(pb, SLAPI_PLUGIN_IDENTITY, &plugin_id); > >+ > >+ if (slapi_register_plugin("betxnpreoperation", 1, __func__, preop_init, > >+ PLUGIN_NAME, NULL, plugin_id)) > >+ return LOG(FATAL, "failed to register plugin"); > I think the order is wrong here and it might be the cause for those > messages I've been getting in the dirsrv error logs. > > You need to fetch plugin identity, then set version and description, > set callbacks, and only then register the plugin. Finally, preop_init() will > be called and it should set the callbacks only. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-HOTP-support.patch Type: text/x-patch Size: 20756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34809 bytes Desc: not available URL: From dpal at redhat.com Mon Feb 17 19:09:03 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 14:09:03 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5302530F.8010705@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> Message-ID: <53025E4F.2020201@redhat.com> On 02/17/2014 01:21 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>> On 02/14/2014 05:07 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>>>> ... >>>>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>>>> complete REST >>>>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>>>> future-compatible? (The API itself seems to be a good >>>>>>>>>>>>>> subset of a >>>>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>>>> limitations for >>>>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>>>>> probably a good >>>>>>>>>>>>> thing to save that name. >>>>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a >>>>>>>>>>>> complete REST >>>>>>>>>>>> interface >>>>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to >>>>>>>>>>>> track that: >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>> I think I've addressed most of Petr's suggestions with the >>>>>>>>>>> exception >>>>>>>>>>> of the >>>>>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>>>>> pretty >>>>>>>>>>> much >>>>>>>>>>> standard in IPA calls. >>>>>>>>>>> >>>>>>>>>>> The gssproxy.conf.snippet just makes it easier to >>>>>>>>>>> copy/paste. I can >>>>>>>>>>> drop it if >>>>>>>>>>> you want, I suppose it is duplication. >>>>>>>>>>> >>>>>>>>>>> Note that I ran this past the Foreman design again and as a >>>>>>>>>>> result >>>>>>>>>>> added >>>>>>>>>>> another interface, /realm. It was my understanding that this >>>>>>>>>>> Foreman >>>>>>>>>>> design >>>>>>>>>>> wasn't set into stone but a patch is working its way through >>>>>>>>>>> their >>>>>>>>>>> system that >>>>>>>>>>> followed the spec so I went ahead and added it. It isn't a >>>>>>>>>>> big deal, >>>>>>>>>>> the Host() >>>>>>>>>>> class handles it out of the box. >>>>>>>>>>> >>>>>>>>>>> I also updated the design page a bit to reflect some of the >>>>>>>>>>> changes >>>>>>>>>>> made. >>>>>>>>>>> >>>>>>>>>>> Right now there are no plans to backport python-kerberos to >>>>>>>>>>> F20. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>> I will leave functional testing to others, I just read the >>>>>>>>>> code. I am >>>>>>>>>> still >>>>>>>>>> quite concerned about the positioning, naming and "branding" >>>>>>>>>> of this >>>>>>>>>> feature. >>>>>>>>>> >>>>>>>>>> 1) Package name >>>>>>>>>> >>>>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for >>>>>>>>>> Foreman >>>>>>>>>> integration >>>>>>>>>> use case. >>>>>>>>>> >>>>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only >>>>>>>>>> if we >>>>>>>>>> plan to use >>>>>>>>>> this proxy for all other projects. I.e. if we one day >>>>>>>>>> implement user >>>>>>>>>> smartproxy, it would need to be part of this otherwise it >>>>>>>>>> would lead >>>>>>>>>> to strange >>>>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be >>>>>>>>>> named >>>>>>>>>> differently? >>>>>>>>>> >>>>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>>>> >>>>>>>>>> 2) ipa-rest stuff >>>>>>>>>> >>>>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, >>>>>>>>>> ipa-rest >>>>>>>>>> man. >>>>>>>>>> However, I have the same concerns as above. This is too general >>>>>>>>>> and it >>>>>>>>>> may >>>>>>>>>> conflict with future core server needs (like when we >>>>>>>>>> implement core >>>>>>>>>> IPA REST >>>>>>>>>> interface - #4168). Let us name it consistently with package >>>>>>>>>> name: >>>>>>>>>> >>>>>>>>>> ipa-smartproxy.service >>>>>>>>>> ipa-smartproxy-hosts.service >>>>>>>>>> ipa-foreman-smartproxy.service >>>>>>>>>> >>>>>>>>>> The same for binary, man, ... >>>>>>>>>> >>>>>>>>>> 3) Man pages >>>>>>>>>> >>>>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>>>> general. >>>>>>>>>> >>>>>>>>>> To sum it up - let us chose one name/brand of this feature >>>>>>>>>> and let's >>>>>>>>>> use it >>>>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>>>> subdirectory >>>>>>>>>> in git, >>>>>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> I think it should be "host" >>>>>>>>> >>>>>>>>> ipa-host-smartproxy >>>>>>>>> >>>>>>>>> then we will be able to add other smart proxies and then >>>>>>>>> combine them >>>>>>>>> into one ipa-smartproxy package later if needed. >>>>>>>>> >>>>>>>> >>>>>>>> This would imply we actually run separate servers for the various >>>>>>>> commands. Given that right now we're focused on just the >>>>>>>> Foreman use >>>>>>>> cases I think ipa-smartproxy is sufficient. >>>>>>>> >>>>>>>> For our purposes the smartproxy is just a thin wrapper around >>>>>>>> the IPA >>>>>>>> API. It is extensible for our needs, we just don't need to yet. >>>>>>>> But if >>>>>>>> we did, we'd do so within the cherrypy server and everything >>>>>>>> would be >>>>>>>> self-contained. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Are you saying that we will just extend this smart proxy for >>>>>>> other use >>>>>>> cases like users and others? >>>>>>> >>>>>> >>>>>> It all depends on the use case. If we're talking Foreman then >>>>>> yes. If >>>>>> something else, then we'll discuss it at the time, but it still >>>>>> may be >>>>>> able to be included. >>>>>> >>>>>> The IPA Foreman smart proxy is distinguished by a couple of things: >>>>>> >>>>>> - listens on port 8090, only on localhost >>>>>> - is unauthenticated >>>>>> - uses the /realm URI namespace >>>>>> >>>>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>>>> Dominic came up with only /realm/:domain is required and affects >>>>>> only >>>>>> hosts. >>>>>> >>>>>> We can stick this behind Apache to get authentication, even on a >>>>>> specific URI if we want/need to, but the basic REST stuff can >>>>>> still be >>>>>> handled by cherrypy. >>>>>> >>>>>> We'll need to balance complexity of mixing things vs the >>>>>> complexity of >>>>>> code duplication in multiple servers, unless we come up with some >>>>>> sort >>>>>> of REST server class where we just instantiate whatever we need. But >>>>>> that is for the future. >>>>>> >>>>>> rob >>>>> >>>>> But if it is specific for Foreman then it should have a generic >>>>> name. I >>>>> agree with Martin here. >>>> >>>> I have the feeling we're in basic agreement. >>>> >>>> smartproxy is the Foreman name. I'm not pushing back against >>>> renaming, I'll >>>> have a new patch out shortly doing just that. I'm just pushing back >>>> against >>>> renaming it too deeply. I'm going with ipa-smartproxy. >>>> >>>> rob >>> The point is that smartproxy is a good name to be reused outside >>> foreman. So >>> rather than assuming that "smartproxy" is foreman specific we can go >>> with: >>> host proxy or host smart proxy - for this use case >>> and then >>> user proxy or user smart proxy - for use cases like User >>> provisioning systems >>> and then >>> DNS proxy or DNS smart proxy - ... >>> and then >>> DHCP proxy or DHCP smart proxy - ... >>> and so on >>> >>> We need to establish a good pattern that we will be able to easily >>> extend. >> >> +1, this was exactly my goal. It is easy to name and organize things >> now, >> difficult to do when it is live upstream and/or integrated with Foreman. >> >> I think the key for the right naming is a fact if this is really >> specific to >> Foreman or it is a truly general design usable also in other use >> cases. If >> Foreman-specific, I would go with freeipa-server-smartproxy-host or >> similar. >> >> If general, we can go with >> >> freeipa-server-proxy-host >> freeipa-server-proxy-user >> freeipa-server-proxy-dhcp >> >> The proxies may share the framework and only expose the requested >> part of the >> tree - which in advance gives you an option for an API separation, as >> compared >> to general freeipa-server-smartproxy. > > I still don't get the point of this. Are you proposing having 3 > different servers, each providing a unique service? Or one service > that one can turn on/off features, or something else? Do you envision > this as 3 separate subpackages? > > There is no "framework" in my current patch, it is a cherrypy server > that exposes parts of IPA on a given URI. It is the thinnest of layers. Then it seems to make sense to have 3 different packages that can be optionally coninstalled and would probably share the same principal, keytab and local REST API socket/port. > > rob -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Mon Feb 17 19:22:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 17 Feb 2014 14:22:11 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140217103204.GA16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> Message-ID: <1392664931.12450.17.camel@localhost.localdomain> On Mon, 2014-02-17 at 12:32 +0200, Alexander Bokovoy wrote: > On Thu, 13 Feb 2014, Alexander Bokovoy wrote: > >On Wed, 12 Feb 2014, Nathaniel McCallum wrote: > >>Through the review process, patches are getting shifted around, added, > >>deleted, etc. So I'm now just going to be posting all the patches as an > >>ordered set. The set attached is ordered according to my preferred merge > >>order. It also places easy to review patches up front. I hope this helps > >>reviewers. This format will definitely help me manage the patches. > >> > >>The first three patches should be very easy reviews and can be merged > >>independently. > >> > >>All current patch critiques have, to my knowledge, been addressed in > >>this latest series of patches. > >I have tested all the patches altogether, including Web UI patches, and > >everything works. > > > >I have set up a COPR repo for others to try: > >http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ > > > >However, there is one issue which I was not yet able to pin-point in the > >SLAPI plugins. During FreeIPA install and later on actual use I see > >these in the dirsrv error log: > > > >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter > >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL > >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter > >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL > >[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 > >[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter > >[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL > >[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter > >[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL > > > >Additionally, when slapi-nis is enabled, LDAP bind with identity from > >compat tree fails for OTP use and succeeds for password authentication. > > > >In compat tree we are doing this trick: > >1731 /* Otherwise force rewrite of the > >SLAPI_BIND_TARGET_SDN 1732 * and let > >other plugins to handle it. > >1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ > >1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); > >1735 if (sdn != NULL) { > >1736 slapi_sdn_free(&sdn); > >1737 } > >1738 sdn = slapi_sdn_new_dn_byref(ndn); > >1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); > >1740 ret = 0; > >1741 } > > > >I tried to play with plugin precedence and it didn't really help. > > > >There is definitely a bug (or more) in ipa-pwd-extop in handling > >authentication cases. > Some progress on this investigation. > > Plugin precedence setting is broken in 389-ds. It is only set once, > before running init function provided by the plugin and does not take > into account all callbacks that the init function may register. As > result, all these functions get classified with default precedence (50) > and no configuration could change this, we get ipa-pwd-extop's pre-bind > callback called before schemacompat's one, thus working on the compat > entry DN instead of the new one. Since that entry has no userPassword > attribute, OTP code refuses to accept any password. > > When user is allowed to use password auth along with OTP, the fact that > there is no userPassword get ipa-pwd-extop plugin through the failure. > schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of > 389-ds code checks actual password. > > So we have two issues here: OTP code needs to gracefully ignore entries > without userPassword set, and we need to be able to re-arrange > schemacompat and ipa-pwd-extop precedence for pre-bind operation. If schemacompat goes first, it rewrites the TARGET_SDN to the correct entry. This entry should have userPassword set, no? > I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on > the latter. > > The messages from the log are not yet solved... I've spent the better part of today trying to reproduce this and I haven't been able to yet. Can you reproduce the problem in a clean install? Nathaniel From rcritten at redhat.com Mon Feb 17 19:33:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 14:33:58 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53025E4F.2020201@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> Message-ID: <53026426.8080907@redhat.com> Dmitri Pal wrote: > On 02/17/2014 01:21 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>> On 02/14/2014 05:07 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>>>>> Dmitri Pal wrote: >>>>>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>>>>> ... >>>>>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>>>>> complete REST >>>>>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>>>>> future-compatible? (The API itself seems to be a good >>>>>>>>>>>>>>> subset of a >>>>>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>>>>> limitations for >>>>>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, it is >>>>>>>>>>>>>> probably a good >>>>>>>>>>>>>> thing to save that name. >>>>>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a >>>>>>>>>>>>> complete REST >>>>>>>>>>>>> interface >>>>>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to >>>>>>>>>>>>> track that: >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>>>>> >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>> I think I've addressed most of Petr's suggestions with the >>>>>>>>>>>> exception >>>>>>>>>>>> of the >>>>>>>>>>>> global ipa handle and I stuck with *args, **options as this is >>>>>>>>>>>> pretty >>>>>>>>>>>> much >>>>>>>>>>>> standard in IPA calls. >>>>>>>>>>>> >>>>>>>>>>>> The gssproxy.conf.snippet just makes it easier to >>>>>>>>>>>> copy/paste. I can >>>>>>>>>>>> drop it if >>>>>>>>>>>> you want, I suppose it is duplication. >>>>>>>>>>>> >>>>>>>>>>>> Note that I ran this past the Foreman design again and as a >>>>>>>>>>>> result >>>>>>>>>>>> added >>>>>>>>>>>> another interface, /realm. It was my understanding that this >>>>>>>>>>>> Foreman >>>>>>>>>>>> design >>>>>>>>>>>> wasn't set into stone but a patch is working its way through >>>>>>>>>>>> their >>>>>>>>>>>> system that >>>>>>>>>>>> followed the spec so I went ahead and added it. It isn't a >>>>>>>>>>>> big deal, >>>>>>>>>>>> the Host() >>>>>>>>>>>> class handles it out of the box. >>>>>>>>>>>> >>>>>>>>>>>> I also updated the design page a bit to reflect some of the >>>>>>>>>>>> changes >>>>>>>>>>>> made. >>>>>>>>>>>> >>>>>>>>>>>> Right now there are no plans to backport python-kerberos to >>>>>>>>>>>> F20. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>> I will leave functional testing to others, I just read the >>>>>>>>>>> code. I am >>>>>>>>>>> still >>>>>>>>>>> quite concerned about the positioning, naming and "branding" >>>>>>>>>>> of this >>>>>>>>>>> feature. >>>>>>>>>>> >>>>>>>>>>> 1) Package name >>>>>>>>>>> >>>>>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for >>>>>>>>>>> Foreman >>>>>>>>>>> integration >>>>>>>>>>> use case. >>>>>>>>>>> >>>>>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only >>>>>>>>>>> if we >>>>>>>>>>> plan to use >>>>>>>>>>> this proxy for all other projects. I.e. if we one day >>>>>>>>>>> implement user >>>>>>>>>>> smartproxy, it would need to be part of this otherwise it >>>>>>>>>>> would lead >>>>>>>>>>> to strange >>>>>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be >>>>>>>>>>> named >>>>>>>>>>> differently? >>>>>>>>>>> >>>>>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>>>>> >>>>>>>>>>> 2) ipa-rest stuff >>>>>>>>>>> >>>>>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, >>>>>>>>>>> ipa-rest >>>>>>>>>>> man. >>>>>>>>>>> However, I have the same concerns as above. This is too general >>>>>>>>>>> and it >>>>>>>>>>> may >>>>>>>>>>> conflict with future core server needs (like when we >>>>>>>>>>> implement core >>>>>>>>>>> IPA REST >>>>>>>>>>> interface - #4168). Let us name it consistently with package >>>>>>>>>>> name: >>>>>>>>>>> >>>>>>>>>>> ipa-smartproxy.service >>>>>>>>>>> ipa-smartproxy-hosts.service >>>>>>>>>>> ipa-foreman-smartproxy.service >>>>>>>>>>> >>>>>>>>>>> The same for binary, man, ... >>>>>>>>>>> >>>>>>>>>>> 3) Man pages >>>>>>>>>>> >>>>>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>>>>> general. >>>>>>>>>>> >>>>>>>>>>> To sum it up - let us chose one name/brand of this feature >>>>>>>>>>> and let's >>>>>>>>>>> use it >>>>>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>>>>> subdirectory >>>>>>>>>>> in git, >>>>>>>>>>> subdirectory in ipatests, man, conf, script, names in man pages. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> I think it should be "host" >>>>>>>>>> >>>>>>>>>> ipa-host-smartproxy >>>>>>>>>> >>>>>>>>>> then we will be able to add other smart proxies and then >>>>>>>>>> combine them >>>>>>>>>> into one ipa-smartproxy package later if needed. >>>>>>>>>> >>>>>>>>> >>>>>>>>> This would imply we actually run separate servers for the various >>>>>>>>> commands. Given that right now we're focused on just the >>>>>>>>> Foreman use >>>>>>>>> cases I think ipa-smartproxy is sufficient. >>>>>>>>> >>>>>>>>> For our purposes the smartproxy is just a thin wrapper around >>>>>>>>> the IPA >>>>>>>>> API. It is extensible for our needs, we just don't need to yet. >>>>>>>>> But if >>>>>>>>> we did, we'd do so within the cherrypy server and everything >>>>>>>>> would be >>>>>>>>> self-contained. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Are you saying that we will just extend this smart proxy for >>>>>>>> other use >>>>>>>> cases like users and others? >>>>>>>> >>>>>>> >>>>>>> It all depends on the use case. If we're talking Foreman then >>>>>>> yes. If >>>>>>> something else, then we'll discuss it at the time, but it still >>>>>>> may be >>>>>>> able to be included. >>>>>>> >>>>>>> The IPA Foreman smart proxy is distinguished by a couple of things: >>>>>>> >>>>>>> - listens on port 8090, only on localhost >>>>>>> - is unauthenticated >>>>>>> - uses the /realm URI namespace >>>>>>> >>>>>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>>>>> Dominic came up with only /realm/:domain is required and affects >>>>>>> only >>>>>>> hosts. >>>>>>> >>>>>>> We can stick this behind Apache to get authentication, even on a >>>>>>> specific URI if we want/need to, but the basic REST stuff can >>>>>>> still be >>>>>>> handled by cherrypy. >>>>>>> >>>>>>> We'll need to balance complexity of mixing things vs the >>>>>>> complexity of >>>>>>> code duplication in multiple servers, unless we come up with some >>>>>>> sort >>>>>>> of REST server class where we just instantiate whatever we need. But >>>>>>> that is for the future. >>>>>>> >>>>>>> rob >>>>>> >>>>>> But if it is specific for Foreman then it should have a generic >>>>>> name. I >>>>>> agree with Martin here. >>>>> >>>>> I have the feeling we're in basic agreement. >>>>> >>>>> smartproxy is the Foreman name. I'm not pushing back against >>>>> renaming, I'll >>>>> have a new patch out shortly doing just that. I'm just pushing back >>>>> against >>>>> renaming it too deeply. I'm going with ipa-smartproxy. >>>>> >>>>> rob >>>> The point is that smartproxy is a good name to be reused outside >>>> foreman. So >>>> rather than assuming that "smartproxy" is foreman specific we can go >>>> with: >>>> host proxy or host smart proxy - for this use case >>>> and then >>>> user proxy or user smart proxy - for use cases like User >>>> provisioning systems >>>> and then >>>> DNS proxy or DNS smart proxy - ... >>>> and then >>>> DHCP proxy or DHCP smart proxy - ... >>>> and so on >>>> >>>> We need to establish a good pattern that we will be able to easily >>>> extend. >>> >>> +1, this was exactly my goal. It is easy to name and organize things >>> now, >>> difficult to do when it is live upstream and/or integrated with Foreman. >>> >>> I think the key for the right naming is a fact if this is really >>> specific to >>> Foreman or it is a truly general design usable also in other use >>> cases. If >>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>> similar. >>> >>> If general, we can go with >>> >>> freeipa-server-proxy-host >>> freeipa-server-proxy-user >>> freeipa-server-proxy-dhcp >>> >>> The proxies may share the framework and only expose the requested >>> part of the >>> tree - which in advance gives you an option for an API separation, as >>> compared >>> to general freeipa-server-smartproxy. >> >> I still don't get the point of this. Are you proposing having 3 >> different servers, each providing a unique service? Or one service >> that one can turn on/off features, or something else? Do you envision >> this as 3 separate subpackages? >> >> There is no "framework" in my current patch, it is a cherrypy server >> that exposes parts of IPA on a given URI. It is the thinnest of layers. > > > Then it seems to make sense to have 3 different packages that can be > optionally coninstalled and would probably share the same principal, > keytab and local REST API socket/port. > Well, what you are designing is a central framework with plugins. What I designed is a quick-and-dirty get something up quickly. We need to pick one. The plugable method is going to require a fair bit of rework, though it will potentially pay dividends in the future. rob From abokovoy at redhat.com Mon Feb 17 19:45:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 21:45:35 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392664931.12450.17.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <1392664931.12450.17.camel@localhost.localdomain> Message-ID: <20140217194535.GK16644@redhat.com> On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >On Mon, 2014-02-17 at 12:32 +0200, Alexander Bokovoy wrote: >> On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >> >On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >> >>Through the review process, patches are getting shifted around, added, >> >>deleted, etc. So I'm now just going to be posting all the patches as an >> >>ordered set. The set attached is ordered according to my preferred merge >> >>order. It also places easy to review patches up front. I hope this helps >> >>reviewers. This format will definitely help me manage the patches. >> >> >> >>The first three patches should be very easy reviews and can be merged >> >>independently. >> >> >> >>All current patch critiques have, to my knowledge, been addressed in >> >>this latest series of patches. >> >I have tested all the patches altogether, including Web UI patches, and >> >everything works. >> > >> >I have set up a COPR repo for others to try: >> >http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >> > >> >However, there is one issue which I was not yet able to pin-point in the >> >SLAPI plugins. During FreeIPA install and later on actual use I see >> >these in the dirsrv error log: >> > >> >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >> >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >> >[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >> >[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >> >[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 >> >[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter >> >[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL >> >[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter >> >[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL >> > >> >Additionally, when slapi-nis is enabled, LDAP bind with identity from >> >compat tree fails for OTP use and succeeds for password authentication. >> > >> >In compat tree we are doing this trick: >> >1731 /* Otherwise force rewrite of the >> >SLAPI_BIND_TARGET_SDN 1732 * and let >> >other plugins to handle it. >> >1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ >> >1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); >> >1735 if (sdn != NULL) { >> >1736 slapi_sdn_free(&sdn); >> >1737 } >> >1738 sdn = slapi_sdn_new_dn_byref(ndn); >> >1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); >> >1740 ret = 0; >> >1741 } >> > >> >I tried to play with plugin precedence and it didn't really help. >> > >> >There is definitely a bug (or more) in ipa-pwd-extop in handling >> >authentication cases. >> Some progress on this investigation. >> >> Plugin precedence setting is broken in 389-ds. It is only set once, >> before running init function provided by the plugin and does not take >> into account all callbacks that the init function may register. As >> result, all these functions get classified with default precedence (50) >> and no configuration could change this, we get ipa-pwd-extop's pre-bind >> callback called before schemacompat's one, thus working on the compat >> entry DN instead of the new one. Since that entry has no userPassword >> attribute, OTP code refuses to accept any password. >> >> When user is allowed to use password auth along with OTP, the fact that >> there is no userPassword get ipa-pwd-extop plugin through the failure. >> schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of >> 389-ds code checks actual password. >> >> So we have two issues here: OTP code needs to gracefully ignore entries >> without userPassword set, and we need to be able to re-arrange >> schemacompat and ipa-pwd-extop precedence for pre-bind operation. > >If schemacompat goes first, it rewrites the TARGET_SDN to the correct >entry. This entry should have userPassword set, no? Yes, it should. However, if somebody binds with an entry that has no userPassword, it is not business of ipa-pwd-extop pre-bind callbacks to decide what to answer, we have 389-ds core logic for that already. >> I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on >> the latter. >> >> The messages from the log are not yet solved... > >I've spent the better part of today trying to reproduce this and I >haven't been able to yet. Can you reproduce the problem in a clean >install? Yes, that's my plan, hopefully tomorrow. -- / Alexander Bokovoy From dpal at redhat.com Mon Feb 17 19:45:49 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 14:45:49 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53026426.8080907@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> Message-ID: <530266ED.9020508@redhat.com> On 02/17/2014 02:33 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>> On 02/14/2014 05:07 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/14/2014 04:52 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 02/14/2014 03:09 PM, Rob Crittenden wrote: >>>>>>>>>> Dmitri Pal wrote: >>>>>>>>>>> On 02/14/2014 03:43 AM, Martin Kosek wrote: >>>>>>>>>>>> On 02/14/2014 12:07 AM, Rob Crittenden wrote: >>>>>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>>>>> On 01/28/2014 09:35 PM, Rob Crittenden wrote: >>>>>>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>>>>>> On 01/23/2014 02:17 PM, Petr Viktorin wrote: >>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>> The URL endpoint /ipa/rest suggests that if we implement a >>>>>>>>>>>>>>>> complete REST >>>>>>>>>>>>>>>> API for IPA it would live here. Is the API supposed to be >>>>>>>>>>>>>>>> future-compatible? (The API itself seems to be a good >>>>>>>>>>>>>>>> subset of a >>>>>>>>>>>>>>>> complete REST API, but can we easily add an frontend with >>>>>>>>>>>>>>>> authentication, i18n, etc. here later, and keep the >>>>>>>>>>>>>>>> limitations for >>>>>>>>>>>>>>>> unauthenticated access?) >>>>>>>>>>>>>>>> Perhaps /ipa/smartproxy would be a better choice? >>>>>>>>>>>>>>> It was future-proofing. I'm fine with changing the URI, >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> probably a good >>>>>>>>>>>>>>> thing to save that name. >>>>>>>>>>>>>> +1 for moving to /ipa/smartproxy/rest, we will want a >>>>>>>>>>>>>> complete REST >>>>>>>>>>>>>> interface >>>>>>>>>>>>>> in ipa/rest/ in the future. I rather opened a ticket to >>>>>>>>>>>>>> track that: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4168 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin >>>>>>>>>>>>>> >>>>>>>>>>>>> I think I've addressed most of Petr's suggestions with the >>>>>>>>>>>>> exception >>>>>>>>>>>>> of the >>>>>>>>>>>>> global ipa handle and I stuck with *args, **options as >>>>>>>>>>>>> this is >>>>>>>>>>>>> pretty >>>>>>>>>>>>> much >>>>>>>>>>>>> standard in IPA calls. >>>>>>>>>>>>> >>>>>>>>>>>>> The gssproxy.conf.snippet just makes it easier to >>>>>>>>>>>>> copy/paste. I can >>>>>>>>>>>>> drop it if >>>>>>>>>>>>> you want, I suppose it is duplication. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that I ran this past the Foreman design again and as a >>>>>>>>>>>>> result >>>>>>>>>>>>> added >>>>>>>>>>>>> another interface, /realm. It was my understanding that this >>>>>>>>>>>>> Foreman >>>>>>>>>>>>> design >>>>>>>>>>>>> wasn't set into stone but a patch is working its way through >>>>>>>>>>>>> their >>>>>>>>>>>>> system that >>>>>>>>>>>>> followed the spec so I went ahead and added it. It isn't a >>>>>>>>>>>>> big deal, >>>>>>>>>>>>> the Host() >>>>>>>>>>>>> class handles it out of the box. >>>>>>>>>>>>> >>>>>>>>>>>>> I also updated the design page a bit to reflect some of the >>>>>>>>>>>>> changes >>>>>>>>>>>>> made. >>>>>>>>>>>>> >>>>>>>>>>>>> Right now there are no plans to backport python-kerberos to >>>>>>>>>>>>> F20. >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>> I will leave functional testing to others, I just read the >>>>>>>>>>>> code. I am >>>>>>>>>>>> still >>>>>>>>>>>> quite concerned about the positioning, naming and "branding" >>>>>>>>>>>> of this >>>>>>>>>>>> feature. >>>>>>>>>>>> >>>>>>>>>>>> 1) Package name >>>>>>>>>>>> >>>>>>>>>>>> Currently, it is a host/hostgroup smartproxy, primarily for >>>>>>>>>>>> Foreman >>>>>>>>>>>> integration >>>>>>>>>>>> use case. >>>>>>>>>>>> >>>>>>>>>>>> Packaging it as freeipa-server-smartproxy may be ok, but only >>>>>>>>>>>> if we >>>>>>>>>>>> plan to use >>>>>>>>>>>> this proxy for all other projects. I.e. if we one day >>>>>>>>>>>> implement user >>>>>>>>>>>> smartproxy, it would need to be part of this otherwise it >>>>>>>>>>>> would lead >>>>>>>>>>>> to strange >>>>>>>>>>>> organization, like having freeipa-server-smartproxy and >>>>>>>>>>>> freeipa-server-smartproxy-users packages. Maybe it should be >>>>>>>>>>>> named >>>>>>>>>>>> differently? >>>>>>>>>>>> >>>>>>>>>>>> freeipa-server-foreman-smartproxy >>>>>>>>>>>> freeipa-server-smartproxy-hosts >>>>>>>>>>>> >>>>>>>>>>>> 2) ipa-rest stuff >>>>>>>>>>>> >>>>>>>>>>>> We have ipa-rest script, ipa-rest.conf, ipa-rest.service, >>>>>>>>>>>> ipa-rest >>>>>>>>>>>> man. >>>>>>>>>>>> However, I have the same concerns as above. This is too >>>>>>>>>>>> general >>>>>>>>>>>> and it >>>>>>>>>>>> may >>>>>>>>>>>> conflict with future core server needs (like when we >>>>>>>>>>>> implement core >>>>>>>>>>>> IPA REST >>>>>>>>>>>> interface - #4168). Let us name it consistently with package >>>>>>>>>>>> name: >>>>>>>>>>>> >>>>>>>>>>>> ipa-smartproxy.service >>>>>>>>>>>> ipa-smartproxy-hosts.service >>>>>>>>>>>> ipa-foreman-smartproxy.service >>>>>>>>>>>> >>>>>>>>>>>> The same for binary, man, ... >>>>>>>>>>>> >>>>>>>>>>>> 3) Man pages >>>>>>>>>>>> >>>>>>>>>>>> The same point, you brand it as "IPA REST server". This is too >>>>>>>>>>>> general. >>>>>>>>>>>> >>>>>>>>>>>> To sum it up - let us chose one name/brand of this feature >>>>>>>>>>>> and let's >>>>>>>>>>>> use it >>>>>>>>>>>> consistently in FreeIPA infrastructure - subpackage name, >>>>>>>>>>>> subdirectory >>>>>>>>>>>> in git, >>>>>>>>>>>> subdirectory in ipatests, man, conf, script, names in man >>>>>>>>>>>> pages. >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> I think it should be "host" >>>>>>>>>>> >>>>>>>>>>> ipa-host-smartproxy >>>>>>>>>>> >>>>>>>>>>> then we will be able to add other smart proxies and then >>>>>>>>>>> combine them >>>>>>>>>>> into one ipa-smartproxy package later if needed. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This would imply we actually run separate servers for the >>>>>>>>>> various >>>>>>>>>> commands. Given that right now we're focused on just the >>>>>>>>>> Foreman use >>>>>>>>>> cases I think ipa-smartproxy is sufficient. >>>>>>>>>> >>>>>>>>>> For our purposes the smartproxy is just a thin wrapper around >>>>>>>>>> the IPA >>>>>>>>>> API. It is extensible for our needs, we just don't need to yet. >>>>>>>>>> But if >>>>>>>>>> we did, we'd do so within the cherrypy server and everything >>>>>>>>>> would be >>>>>>>>>> self-contained. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Are you saying that we will just extend this smart proxy for >>>>>>>>> other use >>>>>>>>> cases like users and others? >>>>>>>>> >>>>>>>> >>>>>>>> It all depends on the use case. If we're talking Foreman then >>>>>>>> yes. If >>>>>>>> something else, then we'll discuss it at the time, but it still >>>>>>>> may be >>>>>>>> able to be included. >>>>>>>> >>>>>>>> The IPA Foreman smart proxy is distinguished by a couple of >>>>>>>> things: >>>>>>>> >>>>>>>> - listens on port 8090, only on localhost >>>>>>>> - is unauthenticated >>>>>>>> - uses the /realm URI namespace >>>>>>>> >>>>>>>> I'm exposing hosts and hostgroups as well, but per the spec that >>>>>>>> Dominic came up with only /realm/:domain is required and affects >>>>>>>> only >>>>>>>> hosts. >>>>>>>> >>>>>>>> We can stick this behind Apache to get authentication, even on a >>>>>>>> specific URI if we want/need to, but the basic REST stuff can >>>>>>>> still be >>>>>>>> handled by cherrypy. >>>>>>>> >>>>>>>> We'll need to balance complexity of mixing things vs the >>>>>>>> complexity of >>>>>>>> code duplication in multiple servers, unless we come up with some >>>>>>>> sort >>>>>>>> of REST server class where we just instantiate whatever we >>>>>>>> need. But >>>>>>>> that is for the future. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> But if it is specific for Foreman then it should have a generic >>>>>>> name. I >>>>>>> agree with Martin here. >>>>>> >>>>>> I have the feeling we're in basic agreement. >>>>>> >>>>>> smartproxy is the Foreman name. I'm not pushing back against >>>>>> renaming, I'll >>>>>> have a new patch out shortly doing just that. I'm just pushing back >>>>>> against >>>>>> renaming it too deeply. I'm going with ipa-smartproxy. >>>>>> >>>>>> rob >>>>> The point is that smartproxy is a good name to be reused outside >>>>> foreman. So >>>>> rather than assuming that "smartproxy" is foreman specific we can go >>>>> with: >>>>> host proxy or host smart proxy - for this use case >>>>> and then >>>>> user proxy or user smart proxy - for use cases like User >>>>> provisioning systems >>>>> and then >>>>> DNS proxy or DNS smart proxy - ... >>>>> and then >>>>> DHCP proxy or DHCP smart proxy - ... >>>>> and so on >>>>> >>>>> We need to establish a good pattern that we will be able to easily >>>>> extend. >>>> >>>> +1, this was exactly my goal. It is easy to name and organize things >>>> now, >>>> difficult to do when it is live upstream and/or integrated with >>>> Foreman. >>>> >>>> I think the key for the right naming is a fact if this is really >>>> specific to >>>> Foreman or it is a truly general design usable also in other use >>>> cases. If >>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>>> similar. >>>> >>>> If general, we can go with >>>> >>>> freeipa-server-proxy-host >>>> freeipa-server-proxy-user >>>> freeipa-server-proxy-dhcp >>>> >>>> The proxies may share the framework and only expose the requested >>>> part of the >>>> tree - which in advance gives you an option for an API separation, as >>>> compared >>>> to general freeipa-server-smartproxy. >>> >>> I still don't get the point of this. Are you proposing having 3 >>> different servers, each providing a unique service? Or one service >>> that one can turn on/off features, or something else? Do you envision >>> this as 3 separate subpackages? >>> >>> There is no "framework" in my current patch, it is a cherrypy server >>> that exposes parts of IPA on a given URI. It is the thinnest of layers. >> >> >> Then it seems to make sense to have 3 different packages that can be >> optionally coninstalled and would probably share the same principal, >> keytab and local REST API socket/port. >> > > Well, what you are designing is a central framework with plugins. What > I designed is a quick-and-dirty get something up quickly. We need to > pick one. The plugable method is going to require a fair bit of > rework, though it will potentially pay dividends in the future. I think that we can start where you are but drive towards this architecture via refactoring. But we need to pick the right name now. Even if the architecture is not there yet we should name the package in such way that it does not preclude us from moving towards a clean architecture I described during the next iteration. > > rob -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Feb 17 21:13:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 16:13:09 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530266ED.9020508@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> Message-ID: <53027B65.2020106@redhat.com> Dmitri Pal wrote: > On 02/17/2014 02:33 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>> +1, this was exactly my goal. It is easy to name and organize things >>>>> now, >>>>> difficult to do when it is live upstream and/or integrated with >>>>> Foreman. >>>>> >>>>> I think the key for the right naming is a fact if this is really >>>>> specific to >>>>> Foreman or it is a truly general design usable also in other use >>>>> cases. If >>>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>>>> similar. >>>>> >>>>> If general, we can go with >>>>> >>>>> freeipa-server-proxy-host >>>>> freeipa-server-proxy-user >>>>> freeipa-server-proxy-dhcp >>>>> >>>>> The proxies may share the framework and only expose the requested >>>>> part of the >>>>> tree - which in advance gives you an option for an API separation, as >>>>> compared >>>>> to general freeipa-server-smartproxy. >>>> >>>> I still don't get the point of this. Are you proposing having 3 >>>> different servers, each providing a unique service? Or one service >>>> that one can turn on/off features, or something else? Do you envision >>>> this as 3 separate subpackages? >>>> >>>> There is no "framework" in my current patch, it is a cherrypy server >>>> that exposes parts of IPA on a given URI. It is the thinnest of layers. >>> >>> >>> Then it seems to make sense to have 3 different packages that can be >>> optionally coninstalled and would probably share the same principal, >>> keytab and local REST API socket/port. >>> >> >> Well, what you are designing is a central framework with plugins. What >> I designed is a quick-and-dirty get something up quickly. We need to >> pick one. The plugable method is going to require a fair bit of >> rework, though it will potentially pay dividends in the future. > > I think that we can start where you are but drive towards this > architecture via refactoring. But we need to pick the right name now. > Even if the architecture is not there yet we should name the package in > such way that it does not preclude us from moving towards a clean > architecture I described during the next iteration. Just having a hard time seeing the value. This would be like making each of the IPA plugins a separate package and somehow installing them individually. To do this you'd need at least 2 packages, a high level one with the "framework" and then a separate one for each data type. This could also be achieved, and likely more cleanly, without all these extra packages, as a simple configuration file. Once a package, always a package. Maybe I'm too close to the problem, but to me this is a Foreman-specific solution. The "smartproxy" is a Foreman creation, I don't know that anything else is using it. If you want a RESTful server, then we enable REST in IPA directly, but selectively enabling and disabling APIs is not something we've done before. It has been controlled by ACIs instead. rob From dpal at redhat.com Mon Feb 17 21:23:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 16:23:34 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53027B65.2020106@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> Message-ID: <53027DD6.50903@redhat.com> On 02/17/2014 04:13 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>> +1, this was exactly my goal. It is easy to name and organize things >>>>>> now, >>>>>> difficult to do when it is live upstream and/or integrated with >>>>>> Foreman. >>>>>> >>>>>> I think the key for the right naming is a fact if this is really >>>>>> specific to >>>>>> Foreman or it is a truly general design usable also in other use >>>>>> cases. If >>>>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>>>>> similar. >>>>>> >>>>>> If general, we can go with >>>>>> >>>>>> freeipa-server-proxy-host >>>>>> freeipa-server-proxy-user >>>>>> freeipa-server-proxy-dhcp >>>>>> >>>>>> The proxies may share the framework and only expose the requested >>>>>> part of the >>>>>> tree - which in advance gives you an option for an API >>>>>> separation, as >>>>>> compared >>>>>> to general freeipa-server-smartproxy. >>>>> >>>>> I still don't get the point of this. Are you proposing having 3 >>>>> different servers, each providing a unique service? Or one service >>>>> that one can turn on/off features, or something else? Do you envision >>>>> this as 3 separate subpackages? >>>>> >>>>> There is no "framework" in my current patch, it is a cherrypy server >>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>> layers. >>>> >>>> >>>> Then it seems to make sense to have 3 different packages that can be >>>> optionally coninstalled and would probably share the same principal, >>>> keytab and local REST API socket/port. >>>> >>> >>> Well, what you are designing is a central framework with plugins. What >>> I designed is a quick-and-dirty get something up quickly. We need to >>> pick one. The plugable method is going to require a fair bit of >>> rework, though it will potentially pay dividends in the future. >> >> I think that we can start where you are but drive towards this >> architecture via refactoring. But we need to pick the right name now. >> Even if the architecture is not there yet we should name the package in >> such way that it does not preclude us from moving towards a clean >> architecture I described during the next iteration. > > Just having a hard time seeing the value. This would be like making > each of the IPA plugins a separate package and somehow installing them > individually. > > To do this you'd need at least 2 packages, a high level one with the > "framework" and then a separate one for each data type. > > This could also be achieved, and likely more cleanly, without all > these extra packages, as a simple configuration file. Once a package, > always a package. > > Maybe I'm too close to the problem, but to me this is a > Foreman-specific solution. The "smartproxy" is a Foreman creation, I > don't know that anything else is using it. If you want a RESTful > server, then we enable REST in IPA directly, but selectively enabling > and disabling APIs is not something we've done before. It has been > controlled by ACIs instead. > > rob > We are trying to predict future here. Say we release it as you suggest. Tomorrow we point someone upstream who wants to add users to IPA from a similar proxy to this implementation and say use this as a model. And then Rich needs the same but for DNS for Designate. What would be the best? Rob if you knew that tomorrow two other developers will create similar proxies for users and DNS would you change anything? Would you provide some guidelines to them? If you are close to the problem you should be able to at least tell them: "copy and paste" vs. "add more APIs to the same proxy". If your recommendation is copy and paste then I suspect there will be challenges of running these proxies on the same machine - they will collide on ports and sockets. If we say "extend" shouldn't we use a more generic name? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Feb 17 21:57:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 16:57:35 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53027DD6.50903@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> Message-ID: <530285CF.101@redhat.com> Dmitri Pal wrote: > On 02/17/2014 04:13 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>> +1, this was exactly my goal. It is easy to name and organize things >>>>>>> now, >>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>> Foreman. >>>>>>> >>>>>>> I think the key for the right naming is a fact if this is really >>>>>>> specific to >>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>> cases. If >>>>>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>>>>>> similar. >>>>>>> >>>>>>> If general, we can go with >>>>>>> >>>>>>> freeipa-server-proxy-host >>>>>>> freeipa-server-proxy-user >>>>>>> freeipa-server-proxy-dhcp >>>>>>> >>>>>>> The proxies may share the framework and only expose the requested >>>>>>> part of the >>>>>>> tree - which in advance gives you an option for an API >>>>>>> separation, as >>>>>>> compared >>>>>>> to general freeipa-server-smartproxy. >>>>>> >>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>> different servers, each providing a unique service? Or one service >>>>>> that one can turn on/off features, or something else? Do you envision >>>>>> this as 3 separate subpackages? >>>>>> >>>>>> There is no "framework" in my current patch, it is a cherrypy server >>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>> layers. >>>>> >>>>> >>>>> Then it seems to make sense to have 3 different packages that can be >>>>> optionally coninstalled and would probably share the same principal, >>>>> keytab and local REST API socket/port. >>>>> >>>> >>>> Well, what you are designing is a central framework with plugins. What >>>> I designed is a quick-and-dirty get something up quickly. We need to >>>> pick one. The plugable method is going to require a fair bit of >>>> rework, though it will potentially pay dividends in the future. >>> >>> I think that we can start where you are but drive towards this >>> architecture via refactoring. But we need to pick the right name now. >>> Even if the architecture is not there yet we should name the package in >>> such way that it does not preclude us from moving towards a clean >>> architecture I described during the next iteration. >> >> Just having a hard time seeing the value. This would be like making >> each of the IPA plugins a separate package and somehow installing them >> individually. >> >> To do this you'd need at least 2 packages, a high level one with the >> "framework" and then a separate one for each data type. >> >> This could also be achieved, and likely more cleanly, without all >> these extra packages, as a simple configuration file. Once a package, >> always a package. >> >> Maybe I'm too close to the problem, but to me this is a >> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >> don't know that anything else is using it. If you want a RESTful >> server, then we enable REST in IPA directly, but selectively enabling >> and disabling APIs is not something we've done before. It has been >> controlled by ACIs instead. >> >> rob >> > > We are trying to predict future here. Say we release it as you suggest. > Tomorrow we point someone upstream who wants to add users to IPA from a > similar proxy to this implementation and say use this as a model. > And then Rich needs the same but for DNS for Designate. > > What would be the best? Rob if you knew that tomorrow two other > developers will create similar proxies for users and DNS would you > change anything? Would you provide some guidelines to them? > If you are close to the problem you should be able to at least tell > them: "copy and paste" vs. "add more APIs to the same proxy". > If your recommendation is copy and paste then I suspect there will be > challenges of running these proxies on the same machine - they will > collide on ports and sockets. If we say "extend" shouldn't we use a more > generic name? > I'd say "use the existing IPA API". The only reason we have to write the smartproxy at all is to interoperate with another service that already has a well-defined remote server API which uses REST. rob From dpal at redhat.com Mon Feb 17 23:11:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 18:11:29 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530285CF.101@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> Message-ID: <53029721.9040508@redhat.com> On 02/17/2014 04:57 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>> things >>>>>>>> now, >>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>> Foreman. >>>>>>>> >>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>> specific to >>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>> cases. If >>>>>>>> Foreman-specific, I would go with >>>>>>>> freeipa-server-smartproxy-host or >>>>>>>> similar. >>>>>>>> >>>>>>>> If general, we can go with >>>>>>>> >>>>>>>> freeipa-server-proxy-host >>>>>>>> freeipa-server-proxy-user >>>>>>>> freeipa-server-proxy-dhcp >>>>>>>> >>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>> part of the >>>>>>>> tree - which in advance gives you an option for an API >>>>>>>> separation, as >>>>>>>> compared >>>>>>>> to general freeipa-server-smartproxy. >>>>>>> >>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>> different servers, each providing a unique service? Or one service >>>>>>> that one can turn on/off features, or something else? Do you >>>>>>> envision >>>>>>> this as 3 separate subpackages? >>>>>>> >>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>> server >>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>> layers. >>>>>> >>>>>> >>>>>> Then it seems to make sense to have 3 different packages that can be >>>>>> optionally coninstalled and would probably share the same principal, >>>>>> keytab and local REST API socket/port. >>>>>> >>>>> >>>>> Well, what you are designing is a central framework with plugins. >>>>> What >>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>> pick one. The plugable method is going to require a fair bit of >>>>> rework, though it will potentially pay dividends in the future. >>>> >>>> I think that we can start where you are but drive towards this >>>> architecture via refactoring. But we need to pick the right name now. >>>> Even if the architecture is not there yet we should name the >>>> package in >>>> such way that it does not preclude us from moving towards a clean >>>> architecture I described during the next iteration. >>> >>> Just having a hard time seeing the value. This would be like making >>> each of the IPA plugins a separate package and somehow installing them >>> individually. >>> >>> To do this you'd need at least 2 packages, a high level one with the >>> "framework" and then a separate one for each data type. >>> >>> This could also be achieved, and likely more cleanly, without all >>> these extra packages, as a simple configuration file. Once a package, >>> always a package. >>> >>> Maybe I'm too close to the problem, but to me this is a >>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>> don't know that anything else is using it. If you want a RESTful >>> server, then we enable REST in IPA directly, but selectively enabling >>> and disabling APIs is not something we've done before. It has been >>> controlled by ACIs instead. >>> >>> rob >>> >> >> We are trying to predict future here. Say we release it as you suggest. >> Tomorrow we point someone upstream who wants to add users to IPA from a >> similar proxy to this implementation and say use this as a model. >> And then Rich needs the same but for DNS for Designate. >> >> What would be the best? Rob if you knew that tomorrow two other >> developers will create similar proxies for users and DNS would you >> change anything? Would you provide some guidelines to them? >> If you are close to the problem you should be able to at least tell >> them: "copy and paste" vs. "add more APIs to the same proxy". >> If your recommendation is copy and paste then I suspect there will be >> challenges of running these proxies on the same machine - they will >> collide on ports and sockets. If we say "extend" shouldn't we use a more >> generic name? >> > > I'd say "use the existing IPA API". The only reason we have to write > the smartproxy at all is to interoperate with another service that > already has a well-defined remote server API which uses REST. > > rob OK, so you think that proxy is one off. OK I am fine with it. I was under assumption that it would be a beginning of a trend but I might be wrong as I do not have valid arguments to prove or disprove one way or another. I guess time would show. Any objections to Rob's approach? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From redhatrises at gmail.com Tue Feb 18 00:12:08 2014 From: redhatrises at gmail.com (Darth Vader) Date: Mon, 17 Feb 2014 17:12:08 -0700 Subject: [Freeipa-devel] [PATCH] Message-ID: Hi all, This patch fixes the spelling for hostname in ipa-join instructions. Since it is just a spelling change, I figured the one-liner rule would work and a push to the master would be okay; however, I wanted to see if it was okay or not. https://fedorahosted.org/freeipa/ticket/3250 thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0004-ipa-join-usage-instructions-are-incorrect.patch Type: application/octet-stream Size: 1607 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 18 06:52:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Feb 2014 07:52:57 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53029721.9040508@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> Message-ID: <53030349.8000706@redhat.com> On 02/18/2014 12:11 AM, Dmitri Pal wrote: > On 02/17/2014 04:57 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>> +1, this was exactly my goal. It is easy to name and organize things >>>>>>>>> now, >>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>> Foreman. >>>>>>>>> >>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>> specific to >>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>> cases. If >>>>>>>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or >>>>>>>>> similar. >>>>>>>>> >>>>>>>>> If general, we can go with >>>>>>>>> >>>>>>>>> freeipa-server-proxy-host >>>>>>>>> freeipa-server-proxy-user >>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>> >>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>> part of the >>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>> separation, as >>>>>>>>> compared >>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>> >>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>> that one can turn on/off features, or something else? Do you envision >>>>>>>> this as 3 separate subpackages? >>>>>>>> >>>>>>>> There is no "framework" in my current patch, it is a cherrypy server >>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>> layers. >>>>>>> >>>>>>> >>>>>>> Then it seems to make sense to have 3 different packages that can be >>>>>>> optionally coninstalled and would probably share the same principal, >>>>>>> keytab and local REST API socket/port. >>>>>>> >>>>>> >>>>>> Well, what you are designing is a central framework with plugins. What >>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>> pick one. The plugable method is going to require a fair bit of >>>>>> rework, though it will potentially pay dividends in the future. >>>>> >>>>> I think that we can start where you are but drive towards this >>>>> architecture via refactoring. But we need to pick the right name now. >>>>> Even if the architecture is not there yet we should name the package in >>>>> such way that it does not preclude us from moving towards a clean >>>>> architecture I described during the next iteration. >>>> >>>> Just having a hard time seeing the value. This would be like making >>>> each of the IPA plugins a separate package and somehow installing them >>>> individually. >>>> >>>> To do this you'd need at least 2 packages, a high level one with the >>>> "framework" and then a separate one for each data type. >>>> >>>> This could also be achieved, and likely more cleanly, without all >>>> these extra packages, as a simple configuration file. Once a package, >>>> always a package. >>>> >>>> Maybe I'm too close to the problem, but to me this is a >>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>> don't know that anything else is using it. If you want a RESTful >>>> server, then we enable REST in IPA directly, but selectively enabling >>>> and disabling APIs is not something we've done before. It has been >>>> controlled by ACIs instead. >>>> >>>> rob >>>> >>> >>> We are trying to predict future here. Say we release it as you suggest. >>> Tomorrow we point someone upstream who wants to add users to IPA from a >>> similar proxy to this implementation and say use this as a model. >>> And then Rich needs the same but for DNS for Designate. >>> >>> What would be the best? Rob if you knew that tomorrow two other >>> developers will create similar proxies for users and DNS would you >>> change anything? Would you provide some guidelines to them? >>> If you are close to the problem you should be able to at least tell >>> them: "copy and paste" vs. "add more APIs to the same proxy". >>> If your recommendation is copy and paste then I suspect there will be >>> challenges of running these proxies on the same machine - they will >>> collide on ports and sockets. If we say "extend" shouldn't we use a more >>> generic name? >>> >> >> I'd say "use the existing IPA API". The only reason we have to write the >> smartproxy at all is to interoperate with another service that already has a >> well-defined remote server API which uses REST. >> >> rob > OK, so you think that proxy is one off. OK I am fine with it. > I was under assumption that it would be a beginning of a trend but I might be > wrong as I do not have valid arguments to prove or disprove one way or another. > I guess time would show. > > Any objections to Rob's approach? If this is a one off, specifically designed only for Foreman use case, my question is - do we really want to have this as a part of core FreeIPA repo and a part of it's core subpackages? So that when somebody installs all packages from our repo, he gets Foreman one-off installed? Wouldn't it be better then to keep the FreeIPA smartproxy in a separate package to avoid having FreeIPA core full of one-offs? In my mind, FreeIPA is a general purpose IdM solution and this part does not follow the picture... Just brainstorming here... Martin From abokovoy at redhat.com Tue Feb 18 07:40:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 09:40:02 +0200 Subject: [Freeipa-devel] [PATCH] In-Reply-To: References: Message-ID: <20140218074002.GO16644@redhat.com> On Mon, 17 Feb 2014, Darth Vader wrote: >Hi all, > >This patch fixes the spelling for hostname in ipa-join instructions. Since >it is just a spelling change, I figured the one-liner rule would work and a >push to the master would be okay; however, I wanted to see if it was okay >or not. > >https://fedorahosted.org/freeipa/ticket/3250 ACK. Thanks for the patch! -- / Alexander Bokovoy From abokovoy at redhat.com Tue Feb 18 07:41:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 09:41:31 +0200 Subject: [Freeipa-devel] [Patch] [DOC] documentation patches In-Reply-To: References: Message-ID: <20140218074131.GP16644@redhat.com> On Mon, 17 Feb 2014, Darth Vader wrote: >Hi all, > >I have a couple of documentation patches that need to be reviewed. Probably >the biggest one would be the upgrade procedure as what was in the docs was >outdated. I can break these out in separate emails if needed. Trac tickets >corresponding to patches are: > >https://fedorahosted.org/freeipa/ticket/2918 - 0001 >https://fedorahosted.org/freeipa/ticket/4065 - 0002 >https://fedorahosted.org/freeipa/ticket/4144 - 0003 Thanks, ACK for all three patches. -- / Alexander Bokovoy From mkosek at redhat.com Tue Feb 18 08:42:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Feb 2014 09:42:02 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <52FCB69E.4040104@redhat.com> References: <52FCB69E.4040104@redhat.com> Message-ID: <53031CDA.2060705@redhat.com> On 02/13/2014 01:12 PM, Petr Viktorin wrote: > Hello, > These patches fix https://fedorahosted.org/freeipa/ticket/4074 > Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions > > > Since --type, affects only targetfilter values in the form "(objectclass=...)" > and leaves others alone, and in the -mod command we don't fetch the existing > entry until the pre_callback, I had to put the adds/removes in the context. I > don't think the approach is too terrible given the limitations. 464: 1) Internal Error: # ipa permission-mod can_write2 --filter='foo=bar' ipa: ERROR: an internal error has occurred 2) ACI target filter I would relabel targetfilter from "ACI target filter" to "Target filter" to make it consistent with other ACI attributes. We are sort of hiding there are any underlying ACIs anyway... 3) I am now thinking about the behavior of --memberof and --filter options and how they interact. It looks OK except for the case when I set filter to None: # ipa permission-mod can_write2 --memberof=bar -------------------------------- Modified permission "can_write2" -------------------------------- Permission name: can_write2 Permissions: write Effective attributes: description Bind rule type: permission Subtree: dc=example,dc=com ACI target filter: (foo=bar), (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) Member of group: bar # ipa permission-mod can_write2 --filter= -------------------------------- Modified permission "can_write2" -------------------------------- Permission name: can_write2 Permissions: write Effective attributes: description Bind rule type: permission Subtree: dc=example,dc=com Then both memberOf and filter is erased. Are we ok with that? Shouldn't we keep memberOf part until that is set to None? I am not insisting, just trying to discuss the best behavior. 465: I know this was already discussed previously, but I am now having second thoughts - should we use posixAccount as THE objectclass for user targetfilter? # ipa permission-add can_write --permissions write --attrs=description --type=user ---------------------------- Added permission "can_write" ---------------------------- Permission name: can_write Permissions: write Effective attributes: description Bind rule type: permission Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target filter: (objectclass=posixaccount) Type: user What if we add system users at some point which would miss the posixaccount objectclass? Wouldn't it be better to use the inetOrgPerson structural objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? Otherwise the patches worked fine for me. Martin From pviktori at redhat.com Tue Feb 18 08:42:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 09:42:38 +0100 Subject: [Freeipa-devel] [PATCH] In-Reply-To: <20140218074002.GO16644@redhat.com> References: <20140218074002.GO16644@redhat.com> Message-ID: <53031CFE.6000109@redhat.com> On 02/18/2014 08:40 AM, Alexander Bokovoy wrote: > On Mon, 17 Feb 2014, Darth Vader wrote: >> Hi all, >> >> This patch fixes the spelling for hostname in ipa-join instructions. >> Since >> it is just a spelling change, I figured the one-liner rule would work >> and a >> push to the master would be okay; however, I wanted to see if it was okay >> or not. That rule only applies if you have direct commit access -- otherwise someone necessarily needs to look at the patch before pushing it. >> https://fedorahosted.org/freeipa/ticket/3250 > ACK. > > Thanks for the patch! Thanks indeed! Pushed to master: 96003a45a148706346771a6cf5174b751fe79edd -- Petr? From pspacek at redhat.com Tue Feb 18 08:58:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 18 Feb 2014 09:58:26 +0100 Subject: [Freeipa-devel] [PATCH 0220] Move temporary files to /var/named/dyndb-ldap directory In-Reply-To: <52E7D0A6.7030300@redhat.com> References: <52E7D0A6.7030300@redhat.com> Message-ID: <530320B2.8050701@redhat.com> On 28.1.2014 16:45, Petr Spacek wrote: > Hello, > > Move temporary files to /var/named/dyndb-ldap directory. > > This should make RPM packaging easier. > > This patch should go to master branch before 4.0 release. This version fixes packaging problems found by Tomas Hozza. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0220-2-Move-temporary-files-to-var-named-dyndb-ldap-directo.patch Type: text/x-patch Size: 5977 bytes Desc: not available URL: From pviktori at redhat.com Tue Feb 18 09:01:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 10:01:18 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53030349.8000706@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <53030349.8000706@redhat.com> Message-ID: <5303215E.5050008@redhat.com> On 02/18/2014 07:52 AM, Martin Kosek wrote: > On 02/18/2014 12:11 AM, Dmitri Pal wrote: >> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>> things >>>>>>>>>> now, >>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>> Foreman. >>>>>>>>>> >>>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>>> specific to >>>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>>> cases. If >>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>> similar. >>>>>>>>>> >>>>>>>>>> If general, we can go with >>>>>>>>>> >>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>> >>>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>>> part of the >>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>> separation, as >>>>>>>>>> compared >>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>> >>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>> envision >>>>>>>>> this as 3 separate subpackages? >>>>>>>>> >>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>> server >>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>> layers. >>>>>>>> >>>>>>>> >>>>>>>> Then it seems to make sense to have 3 different packages that >>>>>>>> can be >>>>>>>> optionally coninstalled and would probably share the same >>>>>>>> principal, >>>>>>>> keytab and local REST API socket/port. >>>>>>>> >>>>>>> >>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>> What >>>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>> rework, though it will potentially pay dividends in the future. >>>>>> >>>>>> I think that we can start where you are but drive towards this >>>>>> architecture via refactoring. But we need to pick the right name now. >>>>>> Even if the architecture is not there yet we should name the >>>>>> package in >>>>>> such way that it does not preclude us from moving towards a clean >>>>>> architecture I described during the next iteration. >>>>> >>>>> Just having a hard time seeing the value. This would be like making >>>>> each of the IPA plugins a separate package and somehow installing them >>>>> individually. >>>>> >>>>> To do this you'd need at least 2 packages, a high level one with the >>>>> "framework" and then a separate one for each data type. >>>>> >>>>> This could also be achieved, and likely more cleanly, without all >>>>> these extra packages, as a simple configuration file. Once a package, >>>>> always a package. >>>>> >>>>> Maybe I'm too close to the problem, but to me this is a >>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>> don't know that anything else is using it. If you want a RESTful >>>>> server, then we enable REST in IPA directly, but selectively enabling >>>>> and disabling APIs is not something we've done before. It has been >>>>> controlled by ACIs instead. >>>>> >>>>> rob >>>>> >>>> >>>> We are trying to predict future here. Say we release it as you suggest. >>>> Tomorrow we point someone upstream who wants to add users to IPA from a >>>> similar proxy to this implementation and say use this as a model. >>>> And then Rich needs the same but for DNS for Designate. >>>> >>>> What would be the best? Rob if you knew that tomorrow two other >>>> developers will create similar proxies for users and DNS would you >>>> change anything? Would you provide some guidelines to them? >>>> If you are close to the problem you should be able to at least tell >>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>> If your recommendation is copy and paste then I suspect there will be >>>> challenges of running these proxies on the same machine - they will >>>> collide on ports and sockets. If we say "extend" shouldn't we use a >>>> more >>>> generic name? >>>> >>> >>> I'd say "use the existing IPA API". The only reason we have to write the >>> smartproxy at all is to interoperate with another service that >>> already has a >>> well-defined remote server API which uses REST. >>> >>> rob +1, this is indeed a Foreman-specific one-off. A real REST API would only look similar on the outside. (But I still see the value in making the responses simulate what a real REST API would look like.) >> OK, so you think that proxy is one off. OK I am fine with it. >> I was under assumption that it would be a beginning of a trend but I >> might be >> wrong as I do not have valid arguments to prove or disprove one way or >> another. >> I guess time would show. >> >> Any objections to Rob's approach? > > If this is a one off, specifically designed only for Foreman use case, > my question is - do we really want to have this as a part of core > FreeIPA repo and a part of it's core subpackages? So that when somebody > installs all packages from our repo, he gets Foreman one-off installed? Installed, but definitely not started or configured. It's a few small files, I don't think it's worth it to create a whole different repo for them. > Wouldn't it be better then to keep the FreeIPA smartproxy in a separate > package to avoid having FreeIPA core full of one-offs? In my mind, > FreeIPA is a general purpose IdM solution and this part does not follow > the picture... Maybe it should go to contrib/ then? > Just brainstorming here... > > Martin -- Petr? From pviktori at redhat.com Tue Feb 18 09:11:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 10:11:19 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140217171710.GG16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> <20140217171710.GG16644@redhat.com> Message-ID: <530323B7.8010807@redhat.com> On 02/17/2014 06:17 PM, Alexander Bokovoy wrote: > On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >> On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: >>> Through the review process, patches are getting shifted around, added, >>> deleted, etc. So I'm now just going to be posting all the patches as an >>> ordered set. The set attached is ordered according to my preferred merge >>> order. It also places easy to review patches up front. I hope this helps >>> reviewers. This format will definitely help me manage the patches. >>> >>> The first three patches should be very easy reviews and can be merged >>> independently. >>> >>> All current patch critiques have, to my knowledge, been addressed in >>> this latest series of patches. >> >> Attached are the four remaining patches that have not yet been merged. I >> have re-ordered them so that reviews can continue in parallel while I >> track down the two remaining bugs in ipa-pwd-extop. This means the first >> two patches should be ready for review/merger. > 0004 -- ACK. Wait, 0004? The last one? Nathaniel modified 0004 in a later mail (removed oktodo()), so I'll not push this one. > SLAPI_PLUGIN_OPRETURN is used by 389-ds to notify post-callbacks of the > result of the actual operation. In the BIND case it is set > before running post-callbacks to the result of actual bind operation so > that post-callbacks know what has happened and can fetch it. -- Petr? From abokovoy at redhat.com Tue Feb 18 09:20:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 11:20:05 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <530323B7.8010807@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <1392655783.12450.11.camel@localhost.localdomain> <20140217171710.GG16644@redhat.com> <530323B7.8010807@redhat.com> Message-ID: <20140218092005.GV16644@redhat.com> On Tue, 18 Feb 2014, Petr Viktorin wrote: >On 02/17/2014 06:17 PM, Alexander Bokovoy wrote: >>On Mon, 17 Feb 2014, Nathaniel McCallum wrote: >>>On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: >>>>Through the review process, patches are getting shifted around, added, >>>>deleted, etc. So I'm now just going to be posting all the patches as an >>>>ordered set. The set attached is ordered according to my preferred merge >>>>order. It also places easy to review patches up front. I hope this helps >>>>reviewers. This format will definitely help me manage the patches. >>>> >>>>The first three patches should be very easy reviews and can be merged >>>>independently. >>>> >>>>All current patch critiques have, to my knowledge, been addressed in >>>>this latest series of patches. >>> >>>Attached are the four remaining patches that have not yet been merged. I >>>have re-ordered them so that reviews can continue in parallel while I >>>track down the two remaining bugs in ipa-pwd-extop. This means the first >>>two patches should be ready for review/merger. >>0004 -- ACK. > >Wait, 0004? The last one? >Nathaniel modified 0004 in a later mail (removed oktodo()), so I'll >not push this one. Yes, no need to push the patchset yet, we are still looking for the remaining issue with errors I see in the logs. I'm going to do a clean install today/tomorrow (how time permits) to find out what was wrong with dirsrv setup, if any. -- / Alexander Bokovoy From pspacek at redhat.com Tue Feb 18 09:34:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 18 Feb 2014 10:34:32 +0100 Subject: [Freeipa-devel] [PATCH 0221] Make getcwd() calls safer Message-ID: <53032928.7070107@redhat.com> Hello, Make getcwd() calls safer. Newer GCC complains that I didn't check return value from getcwd() ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0221-Make-getcwd-calls-safer.patch Type: text/x-patch Size: 1641 bytes Desc: not available URL: From lkrispen at redhat.com Tue Feb 18 13:02:59 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 18 Feb 2014 14:02:59 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <52FD02B7.3060404@redhat.com> References: <52FD02B7.3060404@redhat.com> Message-ID: <53035A03.8070409@redhat.com> Hi, yesterday jan asked me about the status of the schema and if it would be ready for certificate storage an dthat puzzled me a bit and showed that I still do not really understand what you want to store in LDAP. Two me there are two very different approaches. 1] LDAP as store for high level objects like certs and keys For certs and related stuff there is rfc4523 and the schema for ldif exists. For keys we would decide if the key is stored in PKCS#8 format or as bind keypairs and define a key attribute and that's it. we could export keys with softhsm, (eventually convert them) and add to ldap, in the long term solution the PKCS#11 replacemnt would need to manage these high level objects 2] low level replacement for eg the sqlite3 database in softhsm. That's what I sometimes get the impression what is wanted. SoftHsm has one component Softdatabase with an API, which more or less passes sets of attributes (attributes defined by PKCS#11) and then stores it as records in sql where each record has a keytype and opaque blob of data. If that is what is wanted the decision would be how fingrained the pkcs objects/attribute types would have to be mapped to ldap: one ldap attribute for each possible attribute type ? Ludwig On 02/13/2014 06:36 PM, Petr Spacek wrote: > Hello list, > > I would like to point you to design pages for DNSSEC feature: > > Zone signing: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC > > Automatic key rotation: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm > > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm > > > > You can ignore bind-dyndb-ldap specifics and think about interactions > with FreeIPA and SSSD. > > - We need to design LDAP schema for key storage (Ludwig is looking > into it). > - We need to write PKCS#11 module on top of LDAP database. > - We need to design key rotation on client side (SSSD? Certmonger?). > - We need to design WebUI/CLI > etc. > > Read sections 'External Impact' carefully :-) > > Have a nice day! > From pviktori at redhat.com Tue Feb 18 13:16:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 14:16:10 +0100 Subject: [Freeipa-devel] [Patch] [DOC] documentation patches In-Reply-To: <20140218074131.GP16644@redhat.com> References: <20140218074131.GP16644@redhat.com> Message-ID: <53035D1A.4070704@redhat.com> On 02/18/2014 08:41 AM, Alexander Bokovoy wrote: > On Mon, 17 Feb 2014, Darth Vader wrote: >> Hi all, >> >> I have a couple of documentation patches that need to be reviewed. >> Probably >> the biggest one would be the upgrade procedure as what was in the docs >> was >> outdated. I can break these out in separate emails if needed. Trac >> tickets >> corresponding to patches are: >> >> https://fedorahosted.org/freeipa/ticket/2918 - 0001 >> https://fedorahosted.org/freeipa/ticket/4065 - 0002 >> https://fedorahosted.org/freeipa/ticket/4144 - 0003 > Thanks, ACK for all three patches. > Pushed to master: 58a034055fb8839b6fa49e35406ca096caf7122a -- Petr? From thozza at redhat.com Tue Feb 18 13:22:22 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 18 Feb 2014 14:22:22 +0100 Subject: [Freeipa-devel] [PATCH 0221] Make getcwd() calls safer In-Reply-To: <53032928.7070107@redhat.com> References: <53032928.7070107@redhat.com> Message-ID: <53035E8E.2000509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2014 10:34 AM, Petr Spacek wrote: > ewer GCC complains that I didn't check return value from getcwd() ... Hi. I reviewed all patches from "PATCH 0181" to the latest one "PATCH 0221" and tested the bind-dyndb-ldap on Fedora 20 (adding/removing records/zones using FreeIPA WebUI, resolving using dig, AXFR, IXFR, adding/removing Dynamic UPDATES). I didn't encounter any issues other than documented in "Known problems and limitations" section of NEWS file. So I finally ACK all of these patches... :) Regards, Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTA16KAAoJEMWIetUdnzwteYcH/iKx8bWOD9AbwSGIezoxZfFO 0k2/XexmFPAkYJ44N7fYm9oYbLkZ7PoKdEdnXW0Etvsna7vS/GKxQvwJnOq3aYSL o8SqyD3KmvXgGWtBDZEkWcoVxyjAFpaDxGSnwjRXrL6AOjN6T7ZqetUJkEMlu+fD mpRoP8l0otk1me6VKMr1UTZuF8NUe7N+onMrHTCD8TQmteK1Kmi7vPasEoGdX30L I0SzEzpmfaDWR3WJXDasiiJo/iqZTuiLL5q7HjNqZVtGPRS4Ey5zYgR+9DEBmQ30 MaYlVbQX8seQvphlBMyeOFlvlV+GBm4zQpzXqeM78uWJvHnZQH/Aijz0OGd534Y= =rt23 -----END PGP SIGNATURE----- From jcholast at redhat.com Tue Feb 18 14:17:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Feb 2014 15:17:35 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53035A03.8070409@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> Message-ID: <53036B7F.2030806@redhat.com> Hi, On 18.2.2014 14:02, Ludwig Krispenz wrote: > Hi, > > yesterday jan asked me about the status of the schema and if it would be > ready for certificate storage an dthat puzzled me a bit and showed that > I still do not really understand what you want to store in LDAP. > Two me there are two very different approaches. > > 1] LDAP as store for high level objects like certs and keys > For certs and related stuff there is rfc4523 and the schema for ldif > exists. For keys we would decide if the key is stored in PKCS#8 format > or as bind keypairs and define a key attribute and that's it. we could > export keys with softhsm, (eventually convert them) and add to ldap, in > the long term solution the PKCS#11 replacemnt would need to manage these > high level objects I think RFC 4523 is not the right schema in this case, as it is suited for PKIs rather than generic cryptographic data storage. For example, RFC 4523 distinguishes between CA and end entity certificates, but in PKCS#11 there are just certificates without any semantics attached to them. > > 2] low level replacement for eg the sqlite3 database in softhsm. > That's what I sometimes get the impression what is wanted. SoftHsm has > one component Softdatabase with an API, which more or less passes sets > of attributes (attributes defined by PKCS#11) and then stores it as > records in sql where each record has a keytype and opaque blob of data. > If that is what is wanted the decision would be how fingrained the pkcs > objects/attribute types would have to be mapped to ldap: one ldap > attribute for each possible attribute type ? One-to-one mapping of attributes from PKCS#11 to LDAP would be the most straightforward way of doing this, but I think we can do some optimization for our needs. For example, like you said above, we can use a single attribute containing PKCS#8 encoded private key rather than using one attribute per private key component. I don't think we need an LDAP attribute for every possible PKCS#11 attribute, ATM it would be sufficient to have just these attributes necessary to represent private key, public key and certificate objects. So, I would say it should be something between high-level and low-level. Honza -- Jan Cholasta From pviktori at redhat.com Tue Feb 18 14:53:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 15:53:58 +0100 Subject: [Freeipa-devel] [PATCH 0013-0014] Modify DNS tests to workaround bug in python-dns In-Reply-To: <53021FF1.2030206@redhat.com> References: <53021FF1.2030206@redhat.com> Message-ID: <53037406.1040701@redhat.com> On 02/17/2014 03:42 PM, Petr Spacek wrote: > Hello, > > I have found bug in python-dns and consequently another bug in LOC > record parsing in IPA. See commit messages. > > My next patch for 'wait_for_dns' functionality (required for > bind-dyndb-ldap 4.0) depends on these fixes. 0013 - ACK 0014 - ACK Pushed to master: 7e9838042d5833cb2d3d7bec3a86857d5ffc526d -- Petr? From rcritten at redhat.com Tue Feb 18 15:23:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Feb 2014 10:23:27 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53036B7F.2030806@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> Message-ID: <53037AEF.7060101@redhat.com> Jan Cholasta wrote: > Hi, > > On 18.2.2014 14:02, Ludwig Krispenz wrote: >> Hi, >> >> yesterday jan asked me about the status of the schema and if it would be >> ready for certificate storage an dthat puzzled me a bit and showed that >> I still do not really understand what you want to store in LDAP. >> Two me there are two very different approaches. >> >> 1] LDAP as store for high level objects like certs and keys >> For certs and related stuff there is rfc4523 and the schema for ldif >> exists. For keys we would decide if the key is stored in PKCS#8 format >> or as bind keypairs and define a key attribute and that's it. we could >> export keys with softhsm, (eventually convert them) and add to ldap, in >> the long term solution the PKCS#11 replacemnt would need to manage these >> high level objects > > I think RFC 4523 is not the right schema in this case, as it is suited > for PKIs rather than generic cryptographic data storage. For example, > RFC 4523 distinguishes between CA and end entity certificates, but in > PKCS#11 there are just certificates without any semantics attached to them. I'm not advocating one vs another, but you can make some educated guesses on a CA vs a cert based on whether there is a private key with it. Note that you may want/need to store CKO_NETSCAPE_TRUST values as well. >> >> 2] low level replacement for eg the sqlite3 database in softhsm. >> That's what I sometimes get the impression what is wanted. SoftHsm has >> one component Softdatabase with an API, which more or less passes sets >> of attributes (attributes defined by PKCS#11) and then stores it as >> records in sql where each record has a keytype and opaque blob of data. >> If that is what is wanted the decision would be how fingrained the pkcs >> objects/attribute types would have to be mapped to ldap: one ldap >> attribute for each possible attribute type ? > > One-to-one mapping of attributes from PKCS#11 to LDAP would be the most > straightforward way of doing this, but I think we can do some > optimization for our needs. For example, like you said above, we can use > a single attribute containing PKCS#8 encoded private key rather than > using one attribute per private key component. > > I don't think we need an LDAP attribute for every possible PKCS#11 > attribute, ATM it would be sufficient to have just these attributes > necessary to represent private key, public key and certificate objects. > > So, I would say it should be something between high-level and low-level. There won't be a separate public key, it's represented by the certificate. And as I mentioned, trust, though you can fake it too if you can find some means of distinguishing a CA from another cert. For example, in the soft-pkcs11 module I showed you they define it in a configuration file with "anchor" and it gets marked as trusted. Or you can generate this on-the-fly entirely. rob From jcholast at redhat.com Tue Feb 18 15:31:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Feb 2014 16:31:04 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53037AEF.7060101@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> Message-ID: <53037CB8.3080703@redhat.com> On 18.2.2014 16:23, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>> Hi, >>> >>> yesterday jan asked me about the status of the schema and if it would be >>> ready for certificate storage an dthat puzzled me a bit and showed that >>> I still do not really understand what you want to store in LDAP. >>> Two me there are two very different approaches. >>> >>> 1] LDAP as store for high level objects like certs and keys >>> For certs and related stuff there is rfc4523 and the schema for ldif >>> exists. For keys we would decide if the key is stored in PKCS#8 format >>> or as bind keypairs and define a key attribute and that's it. we could >>> export keys with softhsm, (eventually convert them) and add to ldap, in >>> the long term solution the PKCS#11 replacemnt would need to manage these >>> high level objects >> >> I think RFC 4523 is not the right schema in this case, as it is suited >> for PKIs rather than generic cryptographic data storage. For example, >> RFC 4523 distinguishes between CA and end entity certificates, but in >> PKCS#11 there are just certificates without any semantics attached to >> them. > > I'm not advocating one vs another, but you can make some educated > guesses on a CA vs a cert based on whether there is a private key with it. > > Note that you may want/need to store CKO_NETSCAPE_TRUST values as well. Yes. (I thought it was CKO_NSS_TRUST though, but that's not important.) > >>> >>> 2] low level replacement for eg the sqlite3 database in softhsm. >>> That's what I sometimes get the impression what is wanted. SoftHsm has >>> one component Softdatabase with an API, which more or less passes sets >>> of attributes (attributes defined by PKCS#11) and then stores it as >>> records in sql where each record has a keytype and opaque blob of data. >>> If that is what is wanted the decision would be how fingrained the pkcs >>> objects/attribute types would have to be mapped to ldap: one ldap >>> attribute for each possible attribute type ? >> >> One-to-one mapping of attributes from PKCS#11 to LDAP would be the most >> straightforward way of doing this, but I think we can do some >> optimization for our needs. For example, like you said above, we can use >> a single attribute containing PKCS#8 encoded private key rather than >> using one attribute per private key component. >> >> I don't think we need an LDAP attribute for every possible PKCS#11 >> attribute, ATM it would be sufficient to have just these attributes >> necessary to represent private key, public key and certificate objects. >> >> So, I would say it should be something between high-level and low-level. > > There won't be a separate public key, it's represented by the certificate. I'm not sure if this is the case for DNSSEC. > > And as I mentioned, trust, though you can fake it too if you can find > some means of distinguishing a CA from another cert. For example, in the > soft-pkcs11 module I showed you they define it in a configuration file > with "anchor" and it gets marked as trusted. > > Or you can generate this on-the-fly entirely. I plan to store trust information in LDAP, see the CA certificate renewal design. > > rob -- Jan Cholasta From pspacek at redhat.com Tue Feb 18 15:35:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 18 Feb 2014 16:35:18 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53037CB8.3080703@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> Message-ID: <53037DB6.80406@redhat.com> On 18.2.2014 16:31, Jan Cholasta wrote: >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of data. >>>> If that is what is wanted the decision would be how fingrained the pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the most >>> straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can use >>> a single attribute containing PKCS#8 encoded private key rather than >>> using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and low-level. >> >> There won't be a separate public key, it's represented by the certificate. > > I'm not sure if this is the case for DNSSEC. Honzo, we really need the design page with some goal statement, high-level overview etc. There is still some confusion, probably from fact that we want to use the same module for cert distribution and at the same time for DNSSEC key storage. -- Petr^2 Spacek From jcholast at redhat.com Tue Feb 18 15:38:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Feb 2014 16:38:21 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53037DB6.80406@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> Message-ID: <53037E6D.1070701@redhat.com> On 18.2.2014 16:35, Petr Spacek wrote: > On 18.2.2014 16:31, Jan Cholasta wrote: >>>>> >>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>>> one component Softdatabase with an API, which more or less passes sets >>>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>>> records in sql where each record has a keytype and opaque blob of >>>>> data. >>>>> If that is what is wanted the decision would be how fingrained the >>>>> pkcs >>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>> attribute for each possible attribute type ? >>>> >>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the most >>>> straightforward way of doing this, but I think we can do some >>>> optimization for our needs. For example, like you said above, we can >>>> use >>>> a single attribute containing PKCS#8 encoded private key rather than >>>> using one attribute per private key component. >>>> >>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>> attribute, ATM it would be sufficient to have just these attributes >>>> necessary to represent private key, public key and certificate objects. >>>> >>>> So, I would say it should be something between high-level and >>>> low-level. >>> >>> There won't be a separate public key, it's represented by the >>> certificate. >> >> I'm not sure if this is the case for DNSSEC. > > Honzo, > > we really need the design page with some goal statement, high-level > overview etc. There is still some confusion, probably from fact that we > want to use the same module for cert distribution and at the same time > for DNSSEC key storage. > It's on my TODO list, I'll try to get it out ASAP. -- Jan Cholasta From mkosek at redhat.com Tue Feb 18 15:40:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Feb 2014 16:40:15 +0100 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <517FD652.3000703@redhat.com> References: <51755366.6090104@redhat.com> <5175B44D.8080705@redhat.com> <51765FC5.6030105@redhat.com> <517F83DE.9050604@redhat.com> <517FCF48.5040206@redhat.com> <517FD652.3000703@redhat.com> Message-ID: <53037EDF.2070001@redhat.com> On 04/30/2013 04:33 PM, Petr Viktorin wrote: > On 04/30/2013 04:03 PM, Ana Krivokapic wrote: >> On 04/30/2013 10:42 AM, Petr Viktorin wrote: >>> On 04/23/2013 12:17 PM, Ana Krivokapic wrote: >>>> On 04/23/2013 12:06 AM, Rob Crittenden wrote: >>>>> Ana Krivokapic wrote: >>>>>> Do not display ports to open when password is incorrect during >>>>>> ipa-client-install >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3573 >>>>>> >>>>> >>>>> What happens if port 88 is not open so it can't connect to the KDC? >>>>> I'm not sure how the best way to determine one vs the other, I don't >>>>> think there are distinct return values. >>>>> >>>>> We could use the fact that Kerberos isn't translated to look for >>>>> specific strings maybe, but that is hackish and could break. >>>>> >>>>> rob >>>> >>>> The return value from kinit is always 1 in case of failure. So the only >>>> way to determine the reason for failure would be to look into the >>>> message string. I agree this is hackish as Rob pointed out. Personally, >>>> I am for leaving everything as it is now. In the case of incorrect >>>> password, the user _does_ get the message that the password was >>>> incorrect (kinit: Password incorrect while getting initial credentials). >>>> So I don't think that displaying the message about ports, in addition to >>>> this message, is confusing/misleading. >>> >>> I think displaying the error messages after the port information would >>> make it clearer that this is the reason for failed installation. >>> >> >> I think this is a good compromise. Updated patch attached. > > So now we have, with bad password: > > $ sudo ipa-client-install -p admin -w bad-password > Discovery was successful! > Hostname: vm-050.idm.lab.eng.brq.redhat.com > Realm: IDM.LAB.ENG.BRQ.REDHAT.COM > DNS Domain: idm.lab.eng.brq.redhat.com > IPA Server: vm-109.idm.lab.eng.brq.redhat.com > BaseDN: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > > Continue to configure the system with these values? [no]: y > Synchronizing time with KDC... > Please make sure the following ports are opened in the firewall settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working properly > after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > Kerberos authentication failed > kinit: Password incorrect while getting initial credentials > > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > > and with no connection: > > $ sudo ipa-client-install -p admin -w good-password > Discovery was successful! > Hostname: vm-050.idm.lab.eng.brq.redhat.com > Realm: IDM.LAB.ENG.BRQ.REDHAT.COM > DNS Domain: idm.lab.eng.brq.redhat.com > IPA Server: vm-109.idm.lab.eng.brq.redhat.com > BaseDN: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > > Continue to configure the system with these values? [no]: y > Synchronizing time with KDC... > Please make sure the following ports are opened in the firewall settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working properly > after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > Kerberos authentication failed > kinit: Cannot contact any KDC for realm 'IDM.LAB.ENG.BRQ.REDHAT.COM' while > getting initial credentials > > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > Rob, is the behavior OK? > > ACK for the implementation. > Looks good to me. Pushed to master: f67268db6855738350481491119b9be29ba1f22d Martin From pspacek at redhat.com Tue Feb 18 15:45:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 18 Feb 2014 16:45:30 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf Message-ID: <5303801A.40502@redhat.com> Hello, Add wait_for_dns option to default.conf. This option makes record changes in DNS tree synchronous. IPA calls will wait until new data are visible over DNS protocol. It is intended only for testing - it should prevent tests from failing if there is bigger delay between change in LDAP and DNS. I would recommend value like 10 seconds. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 12816 bytes Desc: not available URL: From pviktori at redhat.com Tue Feb 18 16:06:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 17:06:41 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <5303801A.40502@redhat.com> References: <5303801A.40502@redhat.com> Message-ID: <53038511.1050508@redhat.com> On 02/18/2014 04:45 PM, Petr Spacek wrote: > Hello, > > Add wait_for_dns option to default.conf. > > This option makes record changes in DNS tree synchronous. > IPA calls will wait until new data are visible over DNS protocol. > > It is intended only for testing - it should prevent tests from > failing if there is bigger delay between change in LDAP and DNS. > > I would recommend value like 10 seconds. Here are a few Python nitpicks you requested. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015+pviktori-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 12929 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 18 16:19:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Feb 2014 17:19:44 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53037E6D.1070701@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> Message-ID: <53038820.8060309@redhat.com> On 02/18/2014 04:38 PM, Jan Cholasta wrote: > On 18.2.2014 16:35, Petr Spacek wrote: >> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>> >>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>>>> one component Softdatabase with an API, which more or less passes sets >>>>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>>>> records in sql where each record has a keytype and opaque blob of >>>>>> data. >>>>>> If that is what is wanted the decision would be how fingrained the >>>>>> pkcs >>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>> attribute for each possible attribute type ? >>>>> >>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the most >>>>> straightforward way of doing this, but I think we can do some >>>>> optimization for our needs. For example, like you said above, we can >>>>> use >>>>> a single attribute containing PKCS#8 encoded private key rather than >>>>> using one attribute per private key component. >>>>> >>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>> attribute, ATM it would be sufficient to have just these attributes >>>>> necessary to represent private key, public key and certificate objects. >>>>> >>>>> So, I would say it should be something between high-level and >>>>> low-level. >>>> >>>> There won't be a separate public key, it's represented by the >>>> certificate. >>> >>> I'm not sure if this is the case for DNSSEC. >> >> Honzo, >> >> we really need the design page with some goal statement, high-level >> overview etc. There is still some confusion, probably from fact that we >> want to use the same module for cert distribution and at the same time >> for DNSSEC key storage. >> > > It's on my TODO list, I'll try to get it out ASAP. > +1, please do. We clearly need some design to start with. Martin From npmccallum at redhat.com Tue Feb 18 16:34:41 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 11:34:41 -0500 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <53038511.1050508@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> Message-ID: <1392741281.12450.18.camel@localhost.localdomain> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: > On 02/18/2014 04:45 PM, Petr Spacek wrote: > > Hello, > > > > Add wait_for_dns option to default.conf. > > > > This option makes record changes in DNS tree synchronous. > > IPA calls will wait until new data are visible over DNS protocol. > > > > It is intended only for testing - it should prevent tests from > > failing if there is bigger delay between change in LDAP and DNS. > > > > I would recommend value like 10 seconds. > > Here are a few Python nitpicks you requested. It seems to me like a more general TimeoutError would be useful in a broader context. DNSTimeout seems overly narrow to me, unless I'm missing something. Nathaniel From npmccallum at redhat.com Tue Feb 18 16:38:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 11:38:46 -0500 Subject: [Freeipa-devel] [PATCH 0220] Move temporary files to /var/named/dyndb-ldap directory In-Reply-To: <530320B2.8050701@redhat.com> References: <52E7D0A6.7030300@redhat.com> <530320B2.8050701@redhat.com> Message-ID: <1392741526.12450.19.camel@localhost.localdomain> On Tue, 2014-02-18 at 09:58 +0100, Petr Spacek wrote: > On 28.1.2014 16:45, Petr Spacek wrote: > > Hello, > > > > Move temporary files to /var/named/dyndb-ldap directory. > > > > This should make RPM packaging easier. > > > > This patch should go to master branch before 4.0 release. > > This version fixes packaging problems found by Tomas Hozza. ACK From mbasti at redhat.com Tue Feb 18 17:12:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Feb 2014 18:12:19 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <5303801A.40502@redhat.com> References: <5303801A.40502@redhat.com> Message-ID: <1392743539.11627.2.camel@unused-4-145.brq.redhat.com> On Tue, 2014-02-18 at 16:45 +0100, Petr Spacek wrote: > Hello, > > Add wait_for_dns option to default.conf. > > This option makes record changes in DNS tree synchronous. > IPA calls will wait until new data are visible over DNS protocol. > > It is intended only for testing - it should prevent tests from > failing if there is bigger delay between change in LDAP and DNS. > > I would recommend value like 10 seconds. > > __ @@ -2681,7 +2799,13 @@ class dnsrecord_mod(LDAPUpdate): break if del_all: - return self.obj.methods.delentry(*keys, version=options['version']) + result = self.obj.methods.delentry(*keys) I think, version param is missing there -----------------^^ > _____________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin^2 Basti From amisnyov at redhat.com Tue Feb 18 17:31:39 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Tue, 18 Feb 2014 12:31:39 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <1608688295.1194579.1392744613030.JavaMail.zimbra@redhat.com> Message-ID: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> Hi, this patch fixes permission-mod command returning duplicate memberships. https://fedorahosted.org/freeipa/ticket/4175 Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0001-1-Permission-MOD-command-fix.patch Type: text/x-patch Size: 899 bytes Desc: not available URL: From npmccallum at redhat.com Tue Feb 18 17:40:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 12:40:16 -0500 Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> References: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> Message-ID: <1392745216.12450.24.camel@localhost.localdomain> On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: > Hi, > this patch fixes permission-mod command returning duplicate memberships. > > https://fedorahosted.org/freeipa/ticket/4175 NACK This patch does not apply to master. Nathaniel From jcholast at redhat.com Tue Feb 18 17:46:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Feb 2014 18:46:45 +0100 Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <1392745216.12450.24.camel@localhost.localdomain> References: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> <1392745216.12450.24.camel@localhost.localdomain> Message-ID: <53039C85.9020405@redhat.com> Hi, On 18.2.2014 18:40, Nathaniel McCallum wrote: > On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: >> Hi, >> this patch fixes permission-mod command returning duplicate memberships. >> >> https://fedorahosted.org/freeipa/ticket/4175 > > NACK > > This patch does not apply to master. > > Nathaniel The ticket is for 3.3. ACK on the patch. Honza -- Jan Cholasta From pviktori at redhat.com Tue Feb 18 17:52:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 18:52:06 +0100 Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <53039C85.9020405@redhat.com> References: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> <1392745216.12450.24.camel@localhost.localdomain> <53039C85.9020405@redhat.com> Message-ID: <53039DC6.4050605@redhat.com> On 02/18/2014 06:46 PM, Jan Cholasta wrote: > Hi, > > On 18.2.2014 18:40, Nathaniel McCallum wrote: >> On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: >>> Hi, >>> this patch fixes permission-mod command returning duplicate memberships. >>> >>> https://fedorahosted.org/freeipa/ticket/4175 >> >> NACK >> >> This patch does not apply to master. >> >> Nathaniel > > The ticket is for 3.3. > > ACK on the patch. > > Honza > Thanks! Welcome to FreeIPA. I've added a few more words and the ticket URL to the commit message. Next time, please be a bit more verbose. Pushed to ipa-3-3: 2ae2e9b142f1e34f5c95da93ec74ccaa90af2d27 -- Petr? From pviktori at redhat.com Tue Feb 18 19:02:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Feb 2014 20:02:16 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <53031CDA.2060705@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> Message-ID: <5303AE38.7050408@redhat.com> On 02/18/2014 09:42 AM, Martin Kosek wrote: > On 02/13/2014 01:12 PM, Petr Viktorin wrote: >> Hello, >> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >> Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >> >> >> Since --type, affects only targetfilter values in the form "(objectclass=...)" >> and leaves others alone, and in the -mod command we don't fetch the existing >> entry until the pre_callback, I had to put the adds/removes in the context. I >> don't think the approach is too terrible given the limitations. > > 464: > > 1) Internal Error: > > # ipa permission-mod can_write2 --filter='foo=bar' > ipa: ERROR: an internal error has occurred Thanks for the catch! Fixed & added to tests. > 2) ACI target filter > > I would relabel targetfilter from "ACI target filter" to "Target filter" to > make it consistent with other ACI attributes. We are sort of hiding there are > any underlying ACIs anyway... Fixed. > 3) I am now thinking about the behavior of --memberof and --filter options and > how they interact. It looks OK except for the case when I set filter to None: The same would happen when setting --filter to any other value(s) that don't include existing memberOf filters. > # ipa permission-mod can_write2 --memberof=bar > -------------------------------- > Modified permission "can_write2" > -------------------------------- > Permission name: can_write2 > Permissions: write > Effective attributes: description > Bind rule type: permission > Subtree: dc=example,dc=com > ACI target filter: (foo=bar), > (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) > Member of group: bar > # ipa permission-mod can_write2 --filter= > -------------------------------- > Modified permission "can_write2" > -------------------------------- > Permission name: can_write2 > Permissions: write > Effective attributes: description > Bind rule type: permission > Subtree: dc=example,dc=com > > Then both memberOf and filter is erased. Are we ok with that? Shouldn't we keep > memberOf part until that is set to None? I am not insisting, just trying to > discuss the best behavior. Memberof affects the filter; this is even pointed out in --help output. The alternative would be to make --filter= exclude filters affected by other options, which I think would be even more confusing. Keep in mind --type sets (objectclass=...) filters in exactly the same way as --memberof works for (memberof=...). The --memberof, --targetgroup, --type options are just shortcuts for setting other permission attributes. I'm hoping we can get this message across, in --help, and in the docs, well enough to reduce the confusion. > 465: I know this was already discussed previously, but I am now having second > thoughts - should we use posixAccount as THE objectclass for user targetfilter? > > # ipa permission-add can_write --permissions write --attrs=description --type=user > ---------------------------- > Added permission "can_write" > ---------------------------- > Permission name: can_write > Permissions: write > Effective attributes: description > Bind rule type: permission > Subtree: cn=users,cn=accounts,dc=example,dc=com > ACI target filter: (objectclass=posixaccount) > Type: user > > What if we add system users at some point which would miss the posixaccount > objectclass? Wouldn't it be better to use the inetOrgPerson structural > objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? I'm not opposed. (I don't think it should block this patchset though. We'll have to add canonical objectclasses to all the types that don't currently have them. Deciding it for `user` can be a part of that effort.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0464.2-permissions-Use-multivalued-targetfilter.patch Type: text/x-patch Size: 87440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0465.2-Add-permission_filter_objectclasses-for-explicit-typ.patch Type: text/x-patch Size: 11867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0466.2-Add-tests-for-multivalued-filters.patch Type: text/x-patch Size: 9086 bytes Desc: not available URL: From npmccallum at redhat.com Tue Feb 18 19:48:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 14:48:11 -0500 Subject: [Freeipa-devel] [PATCH 0035] ipa-kdb: validate that an OTP user has tokens In-Reply-To: <1391702540.20303.68.camel@localhost.localdomain> References: <1391702540.20303.68.camel@localhost.localdomain> Message-ID: <1392752891.12450.25.camel@localhost.localdomain> On Thu, 2014-02-06 at 11:02 -0500, Nathaniel McCallum wrote: > This patch is independent of any of my other patches and can be merged > out of order. This patch still needs a reviewer. It is very small. Nathaniel From npmccallum at redhat.com Tue Feb 18 19:51:44 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 14:51:44 -0500 Subject: [Freeipa-devel] [PATCH 0035] ipa-kdb: validate that an OTP user has tokens In-Reply-To: <1392752891.12450.25.camel@localhost.localdomain> References: <1391702540.20303.68.camel@localhost.localdomain> <1392752891.12450.25.camel@localhost.localdomain> Message-ID: <1392753104.12450.26.camel@localhost.localdomain> On Tue, 2014-02-18 at 14:48 -0500, Nathaniel McCallum wrote: > On Thu, 2014-02-06 at 11:02 -0500, Nathaniel McCallum wrote: > > This patch is independent of any of my other patches and can be merged > > out of order. > > This patch still needs a reviewer. It is very small. Oops! I replied to the wrong email. Ignore this! Nathaniel From npmccallum at redhat.com Tue Feb 18 19:53:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Feb 2014 14:53:07 -0500 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <1384271963.1822.4.camel@localhost.localdomain> References: <1384271963.1822.4.camel@localhost.localdomain> Message-ID: <1392753187.12450.27.camel@localhost.localdomain> On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote: > https://fedorahosted.org/freeipa/ticket/3779 This patch still needs a reviewer. It is very small. Nathaniel From abokovoy at redhat.com Tue Feb 18 20:02:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 22:02:54 +0200 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <1384271963.1822.4.camel@localhost.localdomain> References: <1384271963.1822.4.camel@localhost.localdomain> Message-ID: <20140218200254.GB9533@redhat.com> On Tue, 12 Nov 2013, Nathaniel McCallum wrote: >https://fedorahosted.org/freeipa/ticket/3779 > > >>From 8806c71c1925b697103fb21df4f937a7a05be74c Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Tue, 12 Nov 2013 10:52:51 -0500 >Subject: [PATCH] Add support to ipa-kdb for keyless principals > >https://fedorahosted.org/freeipa/ticket/3779 >--- > daemons/ipa-kdb/ipa_kdb_principals.c | 18 ++++++++++++++++++ > util/ipa_krb5.c | 3 +++ > 2 files changed, 21 insertions(+) > >diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c >index 38059d29f36bca387b7ba95250d44259c1681cda..08b240910c6ddef31dda7bc6ca07efd39ea703c5 100644 >--- a/daemons/ipa-kdb/ipa_kdb_principals.c >+++ b/daemons/ipa-kdb/ipa_kdb_principals.c >@@ -1266,8 +1266,26 @@ static krb5_error_code ipadb_get_ldap_mod_key_data(struct ipadb_mods *imods, > { > krb5_error_code kerr; > struct berval *bval = NULL; >+ LDAPMod *mod; > int ret; > >+ /* If the key data is empty, remove all keys. */ >+ if (n_key_data == 0 || key_data == NULL) { >+ kerr = ipadb_mods_new(imods, &mod); >+ if (kerr != 0) >+ return kerr; >+ >+ mod->mod_op = LDAP_MOD_DELETE; >+ mod->mod_bvalues = NULL; >+ mod->mod_type = strdup("krbPrincipalKey"); >+ if (mod->mod_type == NULL) { >+ ipadb_mods_free_tip(imods); >+ return ENOMEM; >+ } >+ >+ return 0; >+ } >+ > ret = ber_encode_krb5_key_data(key_data, n_key_data, mkvno, &bval); > if (ret != 0) { > kerr = ret; >diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c >index 934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c92dddd6cb765b435c0fbdfac 100644 >--- a/util/ipa_krb5.c >+++ b/util/ipa_krb5.c >@@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys, int num_keys) > { > int i; > >+ if (keys == NULL) >+ return; >+ > for (i = 0; i < num_keys; i++) { > /* try to wipe key from memory, > * hopefully the compiler will not optimize it away */ >-- >1.8.4.2 > ACK -- / Alexander Bokovoy From mkosek at redhat.com Tue Feb 18 20:03:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Feb 2014 21:03:52 +0100 Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <53039DC6.4050605@redhat.com> References: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> <1392745216.12450.24.camel@localhost.localdomain> <53039C85.9020405@redhat.com> <53039DC6.4050605@redhat.com> Message-ID: <5303BCA8.9030208@redhat.com> On 02/18/2014 06:52 PM, Petr Viktorin wrote: > On 02/18/2014 06:46 PM, Jan Cholasta wrote: >> Hi, >> >> On 18.2.2014 18:40, Nathaniel McCallum wrote: >>> On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: >>>> Hi, >>>> this patch fixes permission-mod command returning duplicate memberships. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4175 >>> >>> NACK >>> >>> This patch does not apply to master. >>> >>> Nathaniel >> >> The ticket is for 3.3. >> >> ACK on the patch. >> >> Honza >> > > Thanks! Welcome to FreeIPA. +1! > I've added a few more words and the ticket URL to the commit message. Next > time, please be a bit more verbose. > > Pushed to ipa-3-3: 2ae2e9b142f1e34f5c95da93ec74ccaa90af2d27 > Yes, please see the guidelines we have on our wiki: http://www.freeipa.org/page/Contribute/Code http://www.freeipa.org/page/Contribute/Patch_Format Note to code itself - it would be better to check for "memberofindirect_" instead of "memberofindirect" so that it is consistent with already used "member_" part. Or even better, one could work with self.obj.attribute_members to see all the possible memberships. But this is just a nitpick, this patch lives in ipa-3-3 only anyway. Martin From dpal at redhat.com Tue Feb 18 22:04:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 18 Feb 2014 17:04:34 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5303215E.5050008@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <53030349.8000706@redhat.com> <5303215E.5050008@redhat.com> Message-ID: <5303D8F2.5050008@redhat.com> On 02/18/2014 04:01 AM, Petr Viktorin wrote: > On 02/18/2014 07:52 AM, Martin Kosek wrote: >> On 02/18/2014 12:11 AM, Dmitri Pal wrote: >>> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>>> things >>>>>>>>>>> now, >>>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>>> Foreman. >>>>>>>>>>> >>>>>>>>>>> I think the key for the right naming is a fact if this is >>>>>>>>>>> really >>>>>>>>>>> specific to >>>>>>>>>>> Foreman or it is a truly general design usable also in other >>>>>>>>>>> use >>>>>>>>>>> cases. If >>>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>>> similar. >>>>>>>>>>> >>>>>>>>>>> If general, we can go with >>>>>>>>>>> >>>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>>> >>>>>>>>>>> The proxies may share the framework and only expose the >>>>>>>>>>> requested >>>>>>>>>>> part of the >>>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>>> separation, as >>>>>>>>>>> compared >>>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>>> >>>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>>> different servers, each providing a unique service? Or one >>>>>>>>>> service >>>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>>> envision >>>>>>>>>> this as 3 separate subpackages? >>>>>>>>>> >>>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>>> server >>>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>>> layers. >>>>>>>>> >>>>>>>>> >>>>>>>>> Then it seems to make sense to have 3 different packages that >>>>>>>>> can be >>>>>>>>> optionally coninstalled and would probably share the same >>>>>>>>> principal, >>>>>>>>> keytab and local REST API socket/port. >>>>>>>>> >>>>>>>> >>>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>>> What >>>>>>>> I designed is a quick-and-dirty get something up quickly. We >>>>>>>> need to >>>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>>> rework, though it will potentially pay dividends in the future. >>>>>>> >>>>>>> I think that we can start where you are but drive towards this >>>>>>> architecture via refactoring. But we need to pick the right name >>>>>>> now. >>>>>>> Even if the architecture is not there yet we should name the >>>>>>> package in >>>>>>> such way that it does not preclude us from moving towards a clean >>>>>>> architecture I described during the next iteration. >>>>>> >>>>>> Just having a hard time seeing the value. This would be like making >>>>>> each of the IPA plugins a separate package and somehow installing >>>>>> them >>>>>> individually. >>>>>> >>>>>> To do this you'd need at least 2 packages, a high level one with the >>>>>> "framework" and then a separate one for each data type. >>>>>> >>>>>> This could also be achieved, and likely more cleanly, without all >>>>>> these extra packages, as a simple configuration file. Once a >>>>>> package, >>>>>> always a package. >>>>>> >>>>>> Maybe I'm too close to the problem, but to me this is a >>>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>>> don't know that anything else is using it. If you want a RESTful >>>>>> server, then we enable REST in IPA directly, but selectively >>>>>> enabling >>>>>> and disabling APIs is not something we've done before. It has been >>>>>> controlled by ACIs instead. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> We are trying to predict future here. Say we release it as you >>>>> suggest. >>>>> Tomorrow we point someone upstream who wants to add users to IPA >>>>> from a >>>>> similar proxy to this implementation and say use this as a model. >>>>> And then Rich needs the same but for DNS for Designate. >>>>> >>>>> What would be the best? Rob if you knew that tomorrow two other >>>>> developers will create similar proxies for users and DNS would you >>>>> change anything? Would you provide some guidelines to them? >>>>> If you are close to the problem you should be able to at least tell >>>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>>> If your recommendation is copy and paste then I suspect there will be >>>>> challenges of running these proxies on the same machine - they will >>>>> collide on ports and sockets. If we say "extend" shouldn't we use a >>>>> more >>>>> generic name? >>>>> >>>> >>>> I'd say "use the existing IPA API". The only reason we have to >>>> write the >>>> smartproxy at all is to interoperate with another service that >>>> already has a >>>> well-defined remote server API which uses REST. >>>> >>>> rob > > +1, this is indeed a Foreman-specific one-off. A real REST API would > only look similar on the outside. (But I still see the value in making > the responses simulate what a real REST API would look like.) > >>> OK, so you think that proxy is one off. OK I am fine with it. >>> I was under assumption that it would be a beginning of a trend but I >>> might be >>> wrong as I do not have valid arguments to prove or disprove one way or >>> another. >>> I guess time would show. >>> >>> Any objections to Rob's approach? >> >> If this is a one off, specifically designed only for Foreman use case, >> my question is - do we really want to have this as a part of core >> FreeIPA repo and a part of it's core subpackages? So that when somebody >> installs all packages from our repo, he gets Foreman one-off installed? > > Installed, but definitely not started or configured. > It's a few small files, I don't think it's worth it to create a whole > different repo for them. > >> Wouldn't it be better then to keep the FreeIPA smartproxy in a separate >> package to avoid having FreeIPA core full of one-offs? In my mind, >> FreeIPA is a general purpose IdM solution and this part does not follow >> the picture... > > Maybe it should go to contrib/ then? > >> Just brainstorming here... >> >> Martin > I do not see a reason to have a separate SRPM. So far it will complicate things. As long as we can install it separately I am fine. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Wed Feb 19 08:24:40 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Feb 2014 09:24:40 +0100 Subject: [Freeipa-devel] [PATCH] Permission MOD command fix In-Reply-To: <5303BCA8.9030208@redhat.com> References: <529076443.1194848.1392744699946.JavaMail.zimbra@redhat.com> <1392745216.12450.24.camel@localhost.localdomain> <53039C85.9020405@redhat.com> <53039DC6.4050605@redhat.com> <5303BCA8.9030208@redhat.com> Message-ID: <53046A48.3000307@redhat.com> On 18.2.2014 21:03, Martin Kosek wrote: > On 02/18/2014 06:52 PM, Petr Viktorin wrote: >> On 02/18/2014 06:46 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 18:40, Nathaniel McCallum wrote: >>>> On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: >>>>> Hi, >>>>> this patch fixes permission-mod command returning duplicate >>>>> memberships. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4175 >>>> >>>> NACK >>>> >>>> This patch does not apply to master. >>>> >>>> Nathaniel >>> >>> The ticket is for 3.3. >>> >>> ACK on the patch. >>> >>> Honza >>> >> >> Thanks! Welcome to FreeIPA. > > +1! > >> I've added a few more words and the ticket URL to the commit message. >> Next >> time, please be a bit more verbose. >> >> Pushed to ipa-3-3: 2ae2e9b142f1e34f5c95da93ec74ccaa90af2d27 >> > > Yes, please see the guidelines we have on our wiki: > > http://www.freeipa.org/page/Contribute/Code > http://www.freeipa.org/page/Contribute/Patch_Format > > Note to code itself - it would be better to check for > "memberofindirect_" instead of "memberofindirect" so that it is > consistent with already used "member_" part. Or even better, one could > work with self.obj.attribute_members to see all the possible memberships. Actually I think just "memberindirect" is correct here, because unlike member, both memberindirect and memberindirect_* are not real attributes. > > But this is just a nitpick, this patch lives in ipa-3-3 only anyway. > > Martin -- Jan Cholasta From pviktori at redhat.com Wed Feb 19 09:17:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 19 Feb 2014 10:17:02 +0100 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <20140218200254.GB9533@redhat.com> References: <1384271963.1822.4.camel@localhost.localdomain> <20140218200254.GB9533@redhat.com> Message-ID: <5304768E.60705@redhat.com> On 02/18/2014 09:02 PM, Alexander Bokovoy wrote: > On Tue, 12 Nov 2013, Nathaniel McCallum wrote: >> https://fedorahosted.org/freeipa/ticket/3779 > > ACK Pushed to master: b769d1c18678b5eede7505dec7938f6836070044 -- Petr? From pviktori at redhat.com Wed Feb 19 09:44:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 19 Feb 2014 10:44:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <5303AE38.7050408@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> <5303AE38.7050408@redhat.com> Message-ID: <53047D0C.9060900@redhat.com> On 02/18/2014 08:02 PM, Petr Viktorin wrote: > On 02/18/2014 09:42 AM, Martin Kosek wrote: >> On 02/13/2014 01:12 PM, Petr Viktorin wrote: >>> Hello, >>> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >>> Design: >>> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >>> >>> >>> Since --type, affects only targetfilter values in the form >>> "(objectclass=...)" >>> and leaves others alone, and in the -mod command we don't fetch the >>> existing >>> entry until the pre_callback, I had to put the adds/removes in the >>> context. I >>> don't think the approach is too terrible given the limitations. >> >> 464: >> >> 1) Internal Error: >> >> # ipa permission-mod can_write2 --filter='foo=bar' >> ipa: ERROR: an internal error has occurred > > Thanks for the catch! Fixed & added to tests. > >> 2) ACI target filter >> >> I would relabel targetfilter from "ACI target filter" to "Target >> filter" to >> make it consistent with other ACI attributes. We are sort of hiding >> there are >> any underlying ACIs anyway... > > Fixed. > >> 3) I am now thinking about the behavior of --memberof and --filter >> options and >> how they interact. It looks OK except for the case when I set filter >> to None: > > The same would happen when setting --filter to any other value(s) that > don't include existing memberOf filters. > >> # ipa permission-mod can_write2 --memberof=bar >> -------------------------------- >> Modified permission "can_write2" >> -------------------------------- >> Permission name: can_write2 >> Permissions: write >> Effective attributes: description >> Bind rule type: permission >> Subtree: dc=example,dc=com >> ACI target filter: (foo=bar), >> >> (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) >> Member of group: bar >> # ipa permission-mod can_write2 --filter= >> -------------------------------- >> Modified permission "can_write2" >> -------------------------------- >> Permission name: can_write2 >> Permissions: write >> Effective attributes: description >> Bind rule type: permission >> Subtree: dc=example,dc=com >> >> Then both memberOf and filter is erased. Are we ok with that? >> Shouldn't we keep >> memberOf part until that is set to None? I am not insisting, just >> trying to >> discuss the best behavior. > > Memberof affects the filter; this is even pointed out in --help output. > The alternative would be to make --filter= exclude filters affected by > other options, which I think would be even more confusing. > Keep in mind --type sets (objectclass=...) filters in exactly the same > way as --memberof works for (memberof=...). > The --memberof, --targetgroup, --type options are just shortcuts for > setting other permission attributes. I'm hoping we can get this message > across, in --help, and in the docs, well enough to reduce the confusion. > >> 465: I know this was already discussed previously, but I am now having >> second >> thoughts - should we use posixAccount as THE objectclass for user >> targetfilter? >> >> # ipa permission-add can_write --permissions write --attrs=description >> --type=user >> ---------------------------- >> Added permission "can_write" >> ---------------------------- >> Permission name: can_write >> Permissions: write >> Effective attributes: description >> Bind rule type: permission >> Subtree: cn=users,cn=accounts,dc=example,dc=com >> ACI target filter: (objectclass=posixaccount) >> Type: user >> >> What if we add system users at some point which would miss the >> posixaccount >> objectclass? Wouldn't it be better to use the inetOrgPerson structural >> objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? > > I'm not opposed. > (I don't think it should block this patchset though. We'll have to add > canonical objectclasses to all the types that don't currently have them. > Deciding it for `user` can be a part of that effort.) Apologies, I've sent a slightly wrong version of the tests. Here's the fixed patchset. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0464.3-permissions-Use-multivalued-targetfilter.patch Type: text/x-patch Size: 87427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0465.3-Add-permission_filter_objectclasses-for-explicit-typ.patch Type: text/x-patch Size: 11867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0466.3-Add-tests-for-multivalued-filters.patch Type: text/x-patch Size: 9086 bytes Desc: not available URL: From simo at redhat.com Wed Feb 19 13:19:42 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Feb 2014 08:19:42 -0500 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <1384271963.1822.4.camel@localhost.localdomain> References: <1384271963.1822.4.camel@localhost.localdomain> Message-ID: <1392815982.22754.142.camel@willson.li.ssimo.org> On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote: > diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c > index > 934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c92dddd6cb765b435c0fbdfac 100644 > --- a/util/ipa_krb5.c > +++ b/util/ipa_krb5.c > @@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys, > int num_keys) > { > int i; > > + if (keys == NULL) > + return; > + > for (i = 0; i < num_keys; i++) { > /* try to wipe key from memory, > * hopefully the compiler will not optimize it away */ > -- This part is useless and can be dropped. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Feb 19 13:24:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Feb 2014 15:24:59 +0200 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <1392815982.22754.142.camel@willson.li.ssimo.org> References: <1384271963.1822.4.camel@localhost.localdomain> <1392815982.22754.142.camel@willson.li.ssimo.org> Message-ID: <20140219132459.GZ16644@redhat.com> On Wed, 19 Feb 2014, Simo Sorce wrote: >On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote: >> diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c >> index >> 934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c92dddd6cb765b435c0fbdfac 100644 >> --- a/util/ipa_krb5.c >> +++ b/util/ipa_krb5.c >> @@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys, >> int num_keys) >> { >> int i; >> >> + if (keys == NULL) >> + return; >> + >> for (i = 0; i < num_keys; i++) { >> /* try to wipe key from memory, >> * hopefully the compiler will not optimize it away */ >> -- > >This part is useless and can be dropped. If ever num_key is not 0 and yet keys == NULL, we'll get crash in the line if (keys[i].key_data_length[0]) { because there are no checks at all before that. -- / Alexander Bokovoy From simo at redhat.com Wed Feb 19 13:26:14 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Feb 2014 08:26:14 -0500 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <1392815982.22754.142.camel@willson.li.ssimo.org> References: <1384271963.1822.4.camel@localhost.localdomain> <1392815982.22754.142.camel@willson.li.ssimo.org> Message-ID: <1392816374.22754.143.camel@willson.li.ssimo.org> On Wed, 2014-02-19 at 08:19 -0500, Simo Sorce wrote: > On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote: > > diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c > > index > > 934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c92dddd6cb765b435c0fbdfac 100644 > > --- a/util/ipa_krb5.c > > +++ b/util/ipa_krb5.c > > @@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys, > > int num_keys) > > { > > int i; > > > > + if (keys == NULL) > > + return; > > + > > for (i = 0; i < num_keys; i++) { > > /* try to wipe key from memory, > > * hopefully the compiler will not optimize it away */ > > -- > > This part is useless and can be dropped. Sigh, too late ... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Feb 19 13:27:10 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Feb 2014 08:27:10 -0500 Subject: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals In-Reply-To: <20140219132459.GZ16644@redhat.com> References: <1384271963.1822.4.camel@localhost.localdomain> <1392815982.22754.142.camel@willson.li.ssimo.org> <20140219132459.GZ16644@redhat.com> Message-ID: <1392816430.22754.144.camel@willson.li.ssimo.org> On Wed, 2014-02-19 at 15:24 +0200, Alexander Bokovoy wrote: > On Wed, 19 Feb 2014, Simo Sorce wrote: > >On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote: > >> diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c > >> index > >> 934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c92dddd6cb765b435c0fbdfac 100644 > >> --- a/util/ipa_krb5.c > >> +++ b/util/ipa_krb5.c > >> @@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys, > >> int num_keys) > >> { > >> int i; > >> > >> + if (keys == NULL) > >> + return; > >> + > >> for (i = 0; i < num_keys; i++) { > >> /* try to wipe key from memory, > >> * hopefully the compiler will not optimize it away */ > >> -- > > > >This part is useless and can be dropped. > If ever num_key is not 0 and yet keys == NULL, we'll get crash in the > line > > if (keys[i].key_data_length[0]) { > > because there are no checks at all before that. If num_keys do not reflect the number of keys in the structure at all times you have bigger problems. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Feb 19 13:45:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 19 Feb 2014 14:45:20 +0100 Subject: [Freeipa-devel] [PATCH] 0468 permission-mod: Do not copy member attributes to new entry Message-ID: <5304B570.8040904@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/4178 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0468-permission-mod-Do-not-copy-member-attributes-to-new-.patch Type: text/x-patch Size: 1162 bytes Desc: not available URL: From pspacek at redhat.com Wed Feb 19 14:11:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 15:11:33 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <1392741281.12450.18.camel@localhost.localdomain> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> Message-ID: <5304BB95.1040900@redhat.com> On 18.2.2014 17:34, Nathaniel McCallum wrote: > On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>> Hello, >>> >>> Add wait_for_dns option to default.conf. >>> >>> This option makes record changes in DNS tree synchronous. >>> IPA calls will wait until new data are visible over DNS protocol. >>> >>> It is intended only for testing - it should prevent tests from >>> failing if there is bigger delay between change in LDAP and DNS. >>> >>> I would recommend value like 10 seconds. >> >> Here are a few Python nitpicks you requested. Thank you very much. This new version solves problems you found + adds proper handling for real DNS timeouts. > It seems to me like a more general TimeoutError would be useful in a > broader context. DNSTimeout seems overly narrow to me, unless I'm > missing something. I would like to keep them separate. DNSTimeout shouldn't be handled at all because it means that your DNS server or database is dead or broken in some interesting way. I assume that generic TimeoutError could be interpreted as 'try it again'/'failover' or something like that. Maybe the DNSTimeout is not the best name, I'm open to suggestions. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015-2-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 12816 bytes Desc: not available URL: From jcholast at redhat.com Wed Feb 19 15:17:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Feb 2014 16:17:27 +0100 Subject: [Freeipa-devel] [PATCH] 0468 permission-mod: Do not copy member attributes to new entry In-Reply-To: <5304B570.8040904@redhat.com> References: <5304B570.8040904@redhat.com> Message-ID: <5304CB07.3060403@redhat.com> On 19.2.2014 14:45, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/4178 > Thanks, ACK. -- Jan Cholasta From tbabej at redhat.com Wed Feb 19 15:37:05 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Feb 2014 16:37:05 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring Message-ID: <5304CFA1.9000007@redhat.com> Hi, When restoring files from backup, we do use an incorrect order of operations - we first restore SELinux context and then copy the files from backup, when we need to do the exact opposite. https://fedorahosted.org/freeipa/ticket/4133 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0153-ipatests-Fix-incorrect-order-of-operations-when-rest.patch Type: text/x-patch Size: 1310 bytes Desc: not available URL: From amisnyov at redhat.com Wed Feb 19 15:43:11 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 19 Feb 2014 10:43:11 -0500 (EST) Subject: [Freeipa-devel] [PATCH] ipactl can not restart ipa services if current status is stopped In-Reply-To: <1868129963.1322328.1392823756998.JavaMail.zimbra@redhat.com> Message-ID: <1206078539.1324456.1392824591803.JavaMail.zimbra@redhat.com> Hi, fixed by starting the directory server in the beginning of restarting if it is not currently running to enable fetching running services, although former restart script didn't check that. Also added a check, that if the directory server started at the beginning, there is no need to restart it. https://fedorahosted.org/freeipa/ticket/4050 Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0002-ipactl-can-not-restart-ipa-services.patch Type: text/x-patch Size: 1982 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Feb 19 15:54:13 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 19 Feb 2014 16:54:13 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <5304CFA1.9000007@redhat.com> References: <5304CFA1.9000007@redhat.com> Message-ID: <20140219155413.GB26583@redhat.com> On Wed, Feb 19, 2014 at 04:37:05PM +0100, Tomas Babej wrote: > Hi, > > When restoring files from backup, we do use an incorrect order of > operations - we first restore SELinux context and then copy the > files from backup, when we need to do the exact opposite. > > https://fedorahosted.org/freeipa/ticket/4133 > > >From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001 > From: Tomas Babej > Date: Wed, 19 Feb 2014 16:31:12 +0100 > Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring > backup > > When restoring files from backup, we do use an incorrect order of > operations - we first restore SELinux context and then copy the > files from backup, when we need to do the exact opposite. > > https://fedorahosted.org/freeipa/ticket/4133 > --- > ipatests/test_integration/tasks.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py > index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278 100644 > --- a/ipatests/test_integration/tasks.py > +++ b/ipatests/test_integration/tasks.py > @@ -137,7 +137,7 @@ def restore_files(host): > > # Run both commands in one session. For more information, see: > # https://fedorahosted.org/freeipa/ticket/4133 > - host.run_command('%s ; (%s ||:)' % (restorecon_command, copyfiles_command)) > + host.run_command('%s ; (%s ||:)' % (copyfiles_command, restorecon_command)) ACK -- having the files in place is definitely useful if we then want to find them there. However: since this is about restoring a backup, can't the backup contain the extended attributes, so that the SELinux context gets restored to the original state (which could be different from what the restorecon will give you)? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Wed Feb 19 16:10:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 17:10:42 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <5304BB95.1040900@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> Message-ID: <5304D782.4060704@redhat.com> On 19.2.2014 15:11, Petr Spacek wrote: > On 18.2.2014 17:34, Nathaniel McCallum wrote: >> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Add wait_for_dns option to default.conf. >>>> >>>> This option makes record changes in DNS tree synchronous. >>>> IPA calls will wait until new data are visible over DNS protocol. >>>> >>>> It is intended only for testing - it should prevent tests from >>>> failing if there is bigger delay between change in LDAP and DNS. >>>> >>>> I would recommend value like 10 seconds. >>> >>> Here are a few Python nitpicks you requested. > > Thank you very much. This new version solves problems you found + adds proper > handling for real DNS timeouts. > >> It seems to me like a more general TimeoutError would be useful in a >> broader context. DNSTimeout seems overly narrow to me, unless I'm >> missing something. > > I would like to keep them separate. DNSTimeout shouldn't be handled at all > because it means that your DNS server or database is dead or broken in some > interesting way. > > I assume that generic TimeoutError could be interpreted as 'try it > again'/'failover' or something like that. > > Maybe the DNSTimeout is not the best name, I'm open to suggestions. I have sent the old version with new name, gggrrr. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015-3-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 12947 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 19 16:32:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Feb 2014 17:32:10 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <53047D0C.9060900@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> <5303AE38.7050408@redhat.com> <53047D0C.9060900@redhat.com> Message-ID: <5304DC8A.7030405@redhat.com> On 02/19/2014 10:44 AM, Petr Viktorin wrote: > On 02/18/2014 08:02 PM, Petr Viktorin wrote: >> On 02/18/2014 09:42 AM, Martin Kosek wrote: >>> On 02/13/2014 01:12 PM, Petr Viktorin wrote: >>>> Hello, >>>> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >>>> Design: >>>> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >>>> >>>> >>>> Since --type, affects only targetfilter values in the form >>>> "(objectclass=...)" >>>> and leaves others alone, and in the -mod command we don't fetch the >>>> existing >>>> entry until the pre_callback, I had to put the adds/removes in the >>>> context. I >>>> don't think the approach is too terrible given the limitations. >>> >>> 464: >>> >>> 1) Internal Error: >>> >>> # ipa permission-mod can_write2 --filter='foo=bar' >>> ipa: ERROR: an internal error has occurred >> >> Thanks for the catch! Fixed & added to tests. >> >>> 2) ACI target filter >>> >>> I would relabel targetfilter from "ACI target filter" to "Target >>> filter" to >>> make it consistent with other ACI attributes. We are sort of hiding >>> there are >>> any underlying ACIs anyway... >> >> Fixed. >> >>> 3) I am now thinking about the behavior of --memberof and --filter >>> options and >>> how they interact. It looks OK except for the case when I set filter >>> to None: >> >> The same would happen when setting --filter to any other value(s) that >> don't include existing memberOf filters. >> >>> # ipa permission-mod can_write2 --memberof=bar >>> -------------------------------- >>> Modified permission "can_write2" >>> -------------------------------- >>> Permission name: can_write2 >>> Permissions: write >>> Effective attributes: description >>> Bind rule type: permission >>> Subtree: dc=example,dc=com >>> ACI target filter: (foo=bar), >>> >>> (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) >>> Member of group: bar >>> # ipa permission-mod can_write2 --filter= >>> -------------------------------- >>> Modified permission "can_write2" >>> -------------------------------- >>> Permission name: can_write2 >>> Permissions: write >>> Effective attributes: description >>> Bind rule type: permission >>> Subtree: dc=example,dc=com >>> >>> Then both memberOf and filter is erased. Are we ok with that? >>> Shouldn't we keep >>> memberOf part until that is set to None? I am not insisting, just >>> trying to >>> discuss the best behavior. >> >> Memberof affects the filter; this is even pointed out in --help output. >> The alternative would be to make --filter= exclude filters affected by >> other options, which I think would be even more confusing. >> Keep in mind --type sets (objectclass=...) filters in exactly the same >> way as --memberof works for (memberof=...). >> The --memberof, --targetgroup, --type options are just shortcuts for >> setting other permission attributes. I'm hoping we can get this message >> across, in --help, and in the docs, well enough to reduce the confusion. >> >>> 465: I know this was already discussed previously, but I am now having >>> second >>> thoughts - should we use posixAccount as THE objectclass for user >>> targetfilter? >>> >>> # ipa permission-add can_write --permissions write --attrs=description >>> --type=user >>> ---------------------------- >>> Added permission "can_write" >>> ---------------------------- >>> Permission name: can_write >>> Permissions: write >>> Effective attributes: description >>> Bind rule type: permission >>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>> ACI target filter: (objectclass=posixaccount) >>> Type: user >>> >>> What if we add system users at some point which would miss the >>> posixaccount >>> objectclass? Wouldn't it be better to use the inetOrgPerson structural >>> objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? >> >> I'm not opposed. >> (I don't think it should block this patchset though. We'll have to add >> canonical objectclasses to all the types that don't currently have them. >> Deciding it for `user` can be a part of that effort.) > > Apologies, I've sent a slightly wrong version of the tests. Here's the fixed > patchset. > Thanks. New check works fine, but the attribute name in the error message seems inconsistent: # ipa permission-mod can_write --filter=foo=bar ipa: ERROR: invalid 'filter': must be enclosed in parentheses # ipa permission-mod can_write --filter="(foo=bar))" ipa: ERROR: invalid 'ipapermtargetfilter': Bad search filter If you fix that, it's ACK for all. Martin From mkosek at redhat.com Wed Feb 19 16:48:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Feb 2014 17:48:48 +0100 Subject: [Freeipa-devel] [PATCH] ipactl can not restart ipa services if current status is stopped In-Reply-To: <1206078539.1324456.1392824591803.JavaMail.zimbra@redhat.com> References: <1206078539.1324456.1392824591803.JavaMail.zimbra@redhat.com> Message-ID: <5304E070.7050002@redhat.com> On 02/19/2014 04:43 PM, Adam Misnyovszki wrote: > Hi, > > fixed by starting the directory server in the beginning of restarting if it is not currently running to enable fetching running services, although former restart script didn't check that. Also added a check, that if the directory server started at the beginning, there is no need to restart it. > > https://fedorahosted.org/freeipa/ticket/4050 > > Thanks > Adam I think this is fine - works OK. ACK, pushed to master. Martin From mbasti at redhat.com Wed Feb 19 16:55:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Feb 2014 17:55:05 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <5304D782.4060704@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> Message-ID: <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: > On 19.2.2014 15:11, Petr Spacek wrote: > > On 18.2.2014 17:34, Nathaniel McCallum wrote: > >> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: > >>> On 02/18/2014 04:45 PM, Petr Spacek wrote: > >>>> Hello, > >>>> > >>>> Add wait_for_dns option to default.conf. > >>>> > >>>> This option makes record changes in DNS tree synchronous. > >>>> IPA calls will wait until new data are visible over DNS protocol. > >>>> > >>>> It is intended only for testing - it should prevent tests from > >>>> failing if there is bigger delay between change in LDAP and DNS. > >>>> > >>>> I would recommend value like 10 seconds. > >>> > >>> Here are a few Python nitpicks you requested. > > > > Thank you very much. This new version solves problems you found + adds proper > > handling for real DNS timeouts. > > > >> It seems to me like a more general TimeoutError would be useful in a > >> broader context. DNSTimeout seems overly narrow to me, unless I'm > >> missing something. > > > > I would like to keep them separate. DNSTimeout shouldn't be handled at all > > because it means that your DNS server or database is dead or broken in some > > interesting way. > > > > I assume that generic TimeoutError could be interpreted as 'try it > > again'/'failover' or something like that. > > > > Maybe the DNSTimeout is not the best name, I'm open to suggestions. > > I have sent the old version with new name, gggrrr. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Tests failed: test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone u'zone3.test' ... ok File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in func = lambda: self.check(nice, **test) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in check_output got = api.Command[cmd](*args, **options) File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/freeipa/ipalib/frontend.py", line 761, in run return self.forward(*args, **options) File "/root/freeipa/ipalib/frontend.py", line 782, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/root/freeipa/ipalib/rpc.py", line 836, in forward return self._call_command(command, params) File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command return command(*params) File "/root/freeipa/ipalib/rpc.py", line 951, in _call return self.__request(name, args) File "/root/freeipa/ipalib/rpc.py", line 945, in __request raise error_class(message=error['message']) DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} ====================================================================== ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test' zone record using dnsrecord_add ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in func = lambda: self.check(nice, **test) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in check_output got = api.Command[cmd](*args, **options) File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/freeipa/ipalib/frontend.py", line 761, in run return self.forward(*args, **options) File "/root/freeipa/ipalib/frontend.py", line 782, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/root/freeipa/ipalib/rpc.py", line 836, in forward return self._call_command(command, params) File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command return command(*params) File "/root/freeipa/ipalib/rpc.py", line 951, in _call return self.__request(name, args) File "/root/freeipa/ipalib/rpc.py", line 945, in __request raise error_class(message=error['message']) DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS ns1.dnszone.test. zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} configuration was: wait_for_dns=10 All tests passed without wait_for_dns option. Sometimes at first run, I get only error and testing is interrupted. -- Martin^2 Basti From amisnyov at redhat.com Wed Feb 19 16:58:15 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 19 Feb 2014 11:58:15 -0500 (EST) Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <1240401067.1343486.1392829043382.JavaMail.zimbra@redhat.com> Message-ID: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 Seems like fine to me. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0003-Add-force-option-to-ipactl.patch Type: text/x-patch Size: 5654 bytes Desc: not available URL: From pspacek at redhat.com Wed Feb 19 18:49:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 19:49:15 +0100 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage Message-ID: <5304FCAB.4070804@redhat.com> Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store & use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. From dpal at redhat.com Wed Feb 19 20:10:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Feb 2014 15:10:29 -0500 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> Message-ID: <53050FB5.7030600@redhat.com> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: > Hi, > I reviewed this old patch: > > If an error occurs in the start up sequence in ipactl start/restart, > all the services are stopped. Using the --force/-f option prevents > stopping of services that have successfully started. > > https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: "If ipactl action fails, do not stop the services that are already running" force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. > > Seems like fine to me. > Thanks > Adam > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 19 20:13:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Feb 2014 15:13:15 -0500 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <5304FCAB.4070804@redhat.com> References: <5304FCAB.4070804@redhat.com> Message-ID: <5305105B.7050700@redhat.com> On 02/19/2014 01:49 PM, Petr Spacek wrote: > Hello list, > > I just came across this page: > http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards > > > If I understand correctly, it allows you to store & use your personal > SSH keys via PKCS#11 interface. > > It sounds like a killer feature to me! > > Imagine that you can log-in to any machine in IPA realm and you will > have all your SSH keys with you, without any extra work. > > This extends seamless SSO outside the enterprise (we have Kerberos for > inside, this doesn't change that). > > Petr^2 Spacek > > P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 > support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Wed Feb 19 20:13:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 21:13:27 +0100 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <53050FB5.7030600@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> Message-ID: <53051067.50903@redhat.com> On 19.2.2014 21:10, Dmitri Pal wrote: > On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: >> Hi, >> I reviewed this old patch: >> >> If an error occurs in the start up sequence in ipactl start/restart, >> all the services are stopped. Using the --force/-f option prevents >> stopping of services that have successfully started. >> >> https://fedorahosted.org/freeipa/ticket/3509 > > > I have not read the code but looked at the patch and bug. > I do not understand the -force option especially with help string being: > "If ipactl action fails, do not stop the services that are already running" > force usually means the reverse: if something did not happen force it to happen. > I am not sure that --force option is the right name for the option with this > help. I have proposed --no-rollback but it didn't fit to habits in IPA: https://fedorahosted.org/freeipa/ticket/3509#comment:2 -- Petr^2 Spacek From pspacek at redhat.com Wed Feb 19 20:30:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 21:30:12 +0100 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <5305105B.7050700@redhat.com> References: <5304FCAB.4070804@redhat.com> <5305105B.7050700@redhat.com> Message-ID: <53051454.4060008@redhat.com> On 19.2.2014 21:13, Dmitri Pal wrote: > On 02/19/2014 01:49 PM, Petr Spacek wrote: >> Hello list, >> >> I just came across this page: >> http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards >> >> >> If I understand correctly, it allows you to store & use your personal SSH >> keys via PKCS#11 interface. >> >> It sounds like a killer feature to me! >> >> Imagine that you can log-in to any machine in IPA realm and you will have >> all your SSH keys with you, without any extra work. >> >> This extends seamless SSO outside the enterprise (we have Kerberos for >> inside, this doesn't change that). >> >> Petr^2 Spacek >> >> P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in >> Fedora 20 already. > > > What are the implications for SSSD and IPA? What needs to be changed if anything? First of all, we need the PKCS#11 provider. We plan to write it for DNSSEC and CA rotation anyway, we just need to think about different use case during design phase. The rest should 'just work'. (As usual, nobody knows beforehand where the dead dog is buried :-)) -- Petr^2 Spacek From abokovoy at redhat.com Wed Feb 19 21:01:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Feb 2014 23:01:50 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140217103204.GA16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> Message-ID: <20140219210150.GD16644@redhat.com> On Mon, 17 Feb 2014, Alexander Bokovoy wrote: >On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >>On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >>>Through the review process, patches are getting shifted around, added, >>>deleted, etc. So I'm now just going to be posting all the patches as an >>>ordered set. The set attached is ordered according to my preferred merge >>>order. It also places easy to review patches up front. I hope this helps >>>reviewers. This format will definitely help me manage the patches. >>> >>>The first three patches should be very easy reviews and can be merged >>>independently. >>> >>>All current patch critiques have, to my knowledge, been addressed in >>>this latest series of patches. >>I have tested all the patches altogether, including Web UI patches, and >>everything works. >> >>I have set up a COPR repo for others to try: >>http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >> >>However, there is one issue which I was not yet able to pin-point in the >>SLAPI plugins. During FreeIPA install and later on actual use I see >>these in the dirsrv error log: >> >>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 >>[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter >>[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL >>[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter >>[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL >> >>Additionally, when slapi-nis is enabled, LDAP bind with identity from >>compat tree fails for OTP use and succeeds for password authentication. >> >>In compat tree we are doing this trick: >>1731 /* Otherwise force rewrite of the >>SLAPI_BIND_TARGET_SDN 1732 * and >>let other plugins to handle it. >>1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ >>1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); >>1735 if (sdn != NULL) { >>1736 slapi_sdn_free(&sdn); >>1737 } >>1738 sdn = slapi_sdn_new_dn_byref(ndn); >>1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); >>1740 ret = 0; >>1741 } >> >>I tried to play with plugin precedence and it didn't really help. >> >>There is definitely a bug (or more) in ipa-pwd-extop in handling >>authentication cases. >Some progress on this investigation. > >Plugin precedence setting is broken in 389-ds. It is only set once, >before running init function provided by the plugin and does not take >into account all callbacks that the init function may register. As >result, all these functions get classified with default precedence (50) >and no configuration could change this, we get ipa-pwd-extop's pre-bind >callback called before schemacompat's one, thus working on the compat >entry DN instead of the new one. Since that entry has no userPassword >attribute, OTP code refuses to accept any password. > >When user is allowed to use password auth along with OTP, the fact that >there is no userPassword get ipa-pwd-extop plugin through the failure. >schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of >389-ds code checks actual password. > >So we have two issues here: OTP code needs to gracefully ignore entries >without userPassword set, and we need to be able to re-arrange >schemacompat and ipa-pwd-extop precedence for pre-bind operation. > >I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on >the latter. > >The messages from the log are not yet solved... Finally, I have a clue after tracing with debug level 1: [19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 [19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter [19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL [19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Feb 19 21:25:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Feb 2014 23:25:58 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140219210150.GD16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> Message-ID: <20140219212558.GE16644@redhat.com> On Wed, 19 Feb 2014, Alexander Bokovoy wrote: >On Mon, 17 Feb 2014, Alexander Bokovoy wrote: >>On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >>>On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >>>>Through the review process, patches are getting shifted around, added, >>>>deleted, etc. So I'm now just going to be posting all the patches as an >>>>ordered set. The set attached is ordered according to my preferred merge >>>>order. It also places easy to review patches up front. I hope this helps >>>>reviewers. This format will definitely help me manage the patches. >>>> >>>>The first three patches should be very easy reviews and can be merged >>>>independently. >>>> >>>>All current patch critiques have, to my knowledge, been addressed in >>>>this latest series of patches. >>>I have tested all the patches altogether, including Web UI patches, and >>>everything works. >>> >>>I have set up a COPR repo for others to try: >>>http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >>> >>>However, there is one issue which I was not yet able to pin-point in the >>>SLAPI plugins. During FreeIPA install and later on actual use I see >>>these in the dirsrv error log: >>> >>>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>>[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>>[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>>[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 >>>[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter >>>[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL >>>[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter >>>[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL >>> >>>Additionally, when slapi-nis is enabled, LDAP bind with identity from >>>compat tree fails for OTP use and succeeds for password authentication. >>> >>>In compat tree we are doing this trick: >>>1731 /* Otherwise force rewrite of the >>>SLAPI_BIND_TARGET_SDN 1732 * and >>>let other plugins to handle it. >>>1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ >>>1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); >>>1735 if (sdn != NULL) { >>>1736 slapi_sdn_free(&sdn); >>>1737 } >>>1738 sdn = slapi_sdn_new_dn_byref(ndn); >>>1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); >>>1740 ret = 0; >>>1741 } >>> >>>I tried to play with plugin precedence and it didn't really help. >>> >>>There is definitely a bug (or more) in ipa-pwd-extop in handling >>>authentication cases. >>Some progress on this investigation. >> >>Plugin precedence setting is broken in 389-ds. It is only set once, >>before running init function provided by the plugin and does not take >>into account all callbacks that the init function may register. As >>result, all these functions get classified with default precedence (50) >>and no configuration could change this, we get ipa-pwd-extop's pre-bind >>callback called before schemacompat's one, thus working on the compat >>entry DN instead of the new one. Since that entry has no userPassword >>attribute, OTP code refuses to accept any password. >> >>When user is allowed to use password auth along with OTP, the fact that >>there is no userPassword get ipa-pwd-extop plugin through the failure. >>schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of >>389-ds code checks actual password. >> >>So we have two issues here: OTP code needs to gracefully ignore entries >>without userPassword set, and we need to be able to re-arrange >>schemacompat and ipa-pwd-extop precedence for pre-bind operation. >> >>I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on >>the latter. >> >>The messages from the log are not yet solved... >Finally, I have a clue after tracing with debug level 1: >[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 >[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter >[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL >[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 > >So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. There is an error in libotp's find() function which assumes that get_basedn() always returns non-NULL value. This is not true for at least cn=Directory Manager. Patch attached. -- / Alexander Bokovoy -------------- next part -------------- >From c91c69fb05f5411ce2a583fc4678ce10cb31e894 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 19 Feb 2014 23:24:29 +0200 Subject: [PATCH 16/16] libotp: do not call internal search for NULL dn --- daemons/ipa-slapi-plugins/libotp/libotp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/libotp/libotp.c b/daemons/ipa-slapi-plugins/libotp/libotp.c index 31cc591..e7119f0 100644 --- a/daemons/ipa-slapi-plugins/libotp/libotp.c +++ b/daemons/ipa-slapi-plugins/libotp/libotp.c @@ -332,6 +332,7 @@ static struct otptoken **find(Slapi_ComponentId *id, const char *user_dn, Slapi_PBlock *pb = NULL; Slapi_DN *sdn = NULL; char *filter = NULL; + char basedn = NULL; size_t count = 0; int result = -1; @@ -362,8 +363,12 @@ static struct otptoken **find(Slapi_ComponentId *id, const char *user_dn, if (sdn == NULL) goto error; + basedn = get_basedn(sdn); + if (basedn == NULL) + goto error; + /* Find all user tokens. */ - slapi_search_internal_set_pb(pb, get_basedn(sdn), + slapi_search_internal_set_pb(pb, basedn, LDAP_SCOPE_SUBTREE, filter, NULL, 0, NULL, NULL, id, 0); } -- 1.8.5.3 From dpal at redhat.com Wed Feb 19 21:58:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Feb 2014 16:58:23 -0500 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <53051067.50903@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> Message-ID: <530528FF.7020702@redhat.com> On 02/19/2014 03:13 PM, Petr Spacek wrote: > On 19.2.2014 21:10, Dmitri Pal wrote: >> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: >>> Hi, >>> I reviewed this old patch: >>> >>> If an error occurs in the start up sequence in ipactl start/restart, >>> all the services are stopped. Using the --force/-f option prevents >>> stopping of services that have successfully started. >>> >>> https://fedorahosted.org/freeipa/ticket/3509 >> >> >> I have not read the code but looked at the patch and bug. >> I do not understand the -force option especially with help string being: >> "If ipactl action fails, do not stop the services that are already >> running" >> force usually means the reverse: if something did not happen force it >> to happen. >> I am not sure that --force option is the right name for the option >> with this >> help. > > I have proposed --no-rollback but it didn't fit to habits in IPA: > https://fedorahosted.org/freeipa/ticket/3509#comment:2 > then it should be -fs/--force-start or something of this kind. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 19 22:01:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Feb 2014 17:01:12 -0500 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <53051454.4060008@redhat.com> References: <5304FCAB.4070804@redhat.com> <5305105B.7050700@redhat.com> <53051454.4060008@redhat.com> Message-ID: <530529A8.90204@redhat.com> On 02/19/2014 03:30 PM, Petr Spacek wrote: > On 19.2.2014 21:13, Dmitri Pal wrote: >> On 02/19/2014 01:49 PM, Petr Spacek wrote: >>> Hello list, >>> >>> I just came across this page: >>> http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards >>> >>> >>> >>> If I understand correctly, it allows you to store & use your >>> personal SSH >>> keys via PKCS#11 interface. >>> >>> It sounds like a killer feature to me! >>> >>> Imagine that you can log-in to any machine in IPA realm and you will >>> have >>> all your SSH keys with you, without any extra work. >>> >>> This extends seamless SSO outside the enterprise (we have Kerberos for >>> inside, this doesn't change that). >>> >>> Petr^2 Spacek >>> >>> P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 >>> support in >>> Fedora 20 already. >> >> >> What are the implications for SSSD and IPA? What needs to be changed >> if anything? > > First of all, we need the PKCS#11 provider. We plan to write it for > DNSSEC and CA rotation anyway, we just need to think about different > use case during design phase. > > The rest should 'just work'. (As usual, nobody knows beforehand where > the dead dog is buried :-)) > Provider? You mean SSSD exposing data as a PKCS#11 provider? I understand it in the case when data comes from central server and needs to be passed to consumers via PKCS#11 interface but in this case data comes from a user and actually should not come from SSSD but rather a real smart card inserted by user. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From redhatrises at gmail.com Thu Feb 20 04:47:33 2014 From: redhatrises at gmail.com (Darth Vader) Date: Wed, 19 Feb 2014 21:47:33 -0700 Subject: [Freeipa-devel] [PATCH] ntp sync order in ipa-client-install Message-ID: Hi, Changed when ntp sync's in ipa-client-install for the ticket below: https://fedorahosted.org/freeipa/ticket/3957 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0005-Fix-order-of-synchronizing-time-when-running-ipa-cli.patch Type: application/octet-stream Size: 3577 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 20 08:18:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 09:18:37 +0100 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <530528FF.7020702@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> <530528FF.7020702@redhat.com> Message-ID: <5305BA5D.7040905@redhat.com> On 02/19/2014 10:58 PM, Dmitri Pal wrote: > On 02/19/2014 03:13 PM, Petr Spacek wrote: >> On 19.2.2014 21:10, Dmitri Pal wrote: >>> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: >>>> Hi, >>>> I reviewed this old patch: >>>> >>>> If an error occurs in the start up sequence in ipactl start/restart, >>>> all the services are stopped. Using the --force/-f option prevents >>>> stopping of services that have successfully started. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3509 >>> >>> >>> I have not read the code but looked at the patch and bug. >>> I do not understand the -force option especially with help string being: >>> "If ipactl action fails, do not stop the services that are already running" >>> force usually means the reverse: if something did not happen force it to >>> happen. >>> I am not sure that --force option is the right name for the option with this >>> help. >> >> I have proposed --no-rollback but it didn't fit to habits in IPA: >> https://fedorahosted.org/freeipa/ticket/3509#comment:2 >> > then it should be -fs/--force-start > > or something of this kind. > IMO --force is not that bad, it forces start procedure to finish regardless of the result (if some service started or not). --force-start may be redundant: # ipactl start --force-start # ipactl restart --force-start But I am not insisting on --force, if there is better option I am open to it. Few comments for the patch itself: 1) Please update it so that it does not use this construct: + try: + svc_off.stop(capture_output=False) + except: + pass Bare except clauses also catch for example KeyboardInterrupt. Then if the stop command is stuck, I would not be able to CTRL+C it. "except Exception:" is better. 2) The --force does not work as I would wish. When --force option is used, I would like ipactl to try to start all services it can, regardless to if they failed or not. Now it just does not rollback, but it still does not start all services it can: # ipactl start --force Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details. Failed to start httpd Service Shutting down <== Aborting ipactl See? HTTPD did not start, ipactl stopped and it did not start pki-tomcatd or ipa-otpd even though they do not use HTTPD when starting. 3) I see we still write "Shutting down" even though we use --force. I would rather print "Shutting down suppressed" or "Forced start, no service rollback". Martin From mkosek at redhat.com Thu Feb 20 08:27:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 09:27:43 +0100 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <530529A8.90204@redhat.com> References: <5304FCAB.4070804@redhat.com> <5305105B.7050700@redhat.com> <53051454.4060008@redhat.com> <530529A8.90204@redhat.com> Message-ID: <5305BC7F.1000805@redhat.com> On 02/19/2014 11:01 PM, Dmitri Pal wrote: > On 02/19/2014 03:30 PM, Petr Spacek wrote: >> On 19.2.2014 21:13, Dmitri Pal wrote: >>> On 02/19/2014 01:49 PM, Petr Spacek wrote: >>>> Hello list, >>>> >>>> I just came across this page: >>>> http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards >>>> >>>> >>>> >>>> If I understand correctly, it allows you to store & use your personal SSH >>>> keys via PKCS#11 interface. >>>> >>>> It sounds like a killer feature to me! >>>> >>>> Imagine that you can log-in to any machine in IPA realm and you will have >>>> all your SSH keys with you, without any extra work. >>>> >>>> This extends seamless SSO outside the enterprise (we have Kerberos for >>>> inside, this doesn't change that). >>>> >>>> Petr^2 Spacek >>>> >>>> P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in >>>> Fedora 20 already. >>> >>> >>> What are the implications for SSSD and IPA? What needs to be changed if >>> anything? >> >> First of all, we need the PKCS#11 provider. We plan to write it for DNSSEC >> and CA rotation anyway, we just need to think about different use case during >> design phase. >> >> The rest should 'just work'. (As usual, nobody knows beforehand where the >> dead dog is buried :-)) >> > Provider? You mean SSSD exposing data as a PKCS#11 provider? I understand it in > the case when data comes from central server and needs to be passed to > consumers via PKCS#11 interface but in this case data comes from a user and > actually should not come from SSSD but rather a real smart card inserted by > user. What am I missing? I am also not following. We already have a support for storing public SSH keys for users which is then fed to sshd via sss_ssh_authorizedkeys. What you described seems rather as a different means of giving my SSH private keys to ssh client - they do not live in ~/.ssh/ but rather on a Smart Card. So IIUC, this should work out of the box with FreeIPA. Martin From jcholast at redhat.com Thu Feb 20 08:35:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Feb 2014 09:35:25 +0100 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <530529A8.90204@redhat.com> References: <5304FCAB.4070804@redhat.com> <5305105B.7050700@redhat.com> <53051454.4060008@redhat.com> <530529A8.90204@redhat.com> Message-ID: <5305BE4D.4030309@redhat.com> On 19.2.2014 23:01, Dmitri Pal wrote: > On 02/19/2014 03:30 PM, Petr Spacek wrote: >> On 19.2.2014 21:13, Dmitri Pal wrote: >>> On 02/19/2014 01:49 PM, Petr Spacek wrote: >>>> Hello list, >>>> >>>> I just came across this page: >>>> http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards >>>> >>>> >>>> >>>> If I understand correctly, it allows you to store & use your >>>> personal SSH >>>> keys via PKCS#11 interface. >>>> >>>> It sounds like a killer feature to me! >>>> >>>> Imagine that you can log-in to any machine in IPA realm and you will >>>> have >>>> all your SSH keys with you, without any extra work. >>>> >>>> This extends seamless SSO outside the enterprise (we have Kerberos for >>>> inside, this doesn't change that). >>>> >>>> Petr^2 Spacek >>>> >>>> P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 >>>> support in >>>> Fedora 20 already. >>> >>> >>> What are the implications for SSSD and IPA? What needs to be changed >>> if anything? >> >> First of all, we need the PKCS#11 provider. We plan to write it for >> DNSSEC and CA rotation anyway, we just need to think about different >> use case during design phase. >> >> The rest should 'just work'. (As usual, nobody knows beforehand where >> the dead dog is buried :-)) >> > Provider? You mean SSSD exposing data as a PKCS#11 provider? I > understand it in the case when data comes from central server and needs > to be passed to consumers via PKCS#11 interface but in this case data > comes from a user and actually should not come from SSSD but rather a > real smart card inserted by user. What am I missing? Petr suggests we store users' private keys in IPA. I don't see any benefit in this, but it is doable with what we are planning for DNSSEC and CA rotation. -- Jan Cholasta From pspacek at redhat.com Thu Feb 20 08:48:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 09:48:47 +0100 Subject: [Freeipa-devel] [PATCH] ntp sync order in ipa-client-install In-Reply-To: References: Message-ID: <5305C16F.1060908@redhat.com> On 20.2.2014 05:47, Darth Vader wrote: > Hi, > > Changed when ntp sync's in ipa-client-install for the ticket below: > > https://fedorahosted.org/freeipa/ticket/3957 > > Thanks, > > Gabe Thank you very much for your patch! Somebody will review it. Please be so kind and update Trac with information about your patch. See http://www.freeipa.org/page/Contribute/Code#Submit_a_patch Have a nice day! -- Petr^2 Spacek From pviktori at redhat.com Thu Feb 20 08:54:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 09:54:58 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class Message-ID: <5305C2E2.7050602@redhat.com> Hello, I had this patch sitting around for some time but didn't get around to polishing and submitting it lately. The ticket was now claimed by "rga" (I assume that's the person who goes by Darth Vader here?). I'm sharing the work hoping that it doesn't get done twice. https://fedorahosted.org/freeipa/ticket/3460 BTW, this is the first small step in my framework refactoring master plan (http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0469-Remove-the-unused-ipalib.frontend.Property-class.patch Type: text/x-patch Size: 11858 bytes Desc: not available URL: From pspacek at redhat.com Thu Feb 20 08:58:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 09:58:46 +0100 Subject: [Freeipa-devel] OpenSSH with PKCS#11 for key storage In-Reply-To: <5305BE4D.4030309@redhat.com> References: <5304FCAB.4070804@redhat.com> <5305105B.7050700@redhat.com> <53051454.4060008@redhat.com> <530529A8.90204@redhat.com> <5305BE4D.4030309@redhat.com> Message-ID: <5305C3C6.9060007@redhat.com> On 20.2.2014 09:35, Jan Cholasta wrote: > On 19.2.2014 23:01, Dmitri Pal wrote: >> On 02/19/2014 03:30 PM, Petr Spacek wrote: >>> On 19.2.2014 21:13, Dmitri Pal wrote: >>>> On 02/19/2014 01:49 PM, Petr Spacek wrote: >>>>> Hello list, >>>>> >>>>> I just came across this page: >>>>> http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards >>>>> >>>>> >>>>> >>>>> >>>>> If I understand correctly, it allows you to store & use your >>>>> personal SSH >>>>> keys via PKCS#11 interface. >>>>> >>>>> It sounds like a killer feature to me! >>>>> >>>>> Imagine that you can log-in to any machine in IPA realm and you will >>>>> have >>>>> all your SSH keys with you, without any extra work. >>>>> >>>>> This extends seamless SSO outside the enterprise (we have Kerberos for >>>>> inside, this doesn't change that). >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 >>>>> support in >>>>> Fedora 20 already. >>>> >>>> >>>> What are the implications for SSSD and IPA? What needs to be changed >>>> if anything? >>> >>> First of all, we need the PKCS#11 provider. We plan to write it for >>> DNSSEC and CA rotation anyway, we just need to think about different >>> use case during design phase. >>> >>> The rest should 'just work'. (As usual, nobody knows beforehand where >>> the dead dog is buried :-)) >>> >> Provider? You mean SSSD exposing data as a PKCS#11 provider? I >> understand it in the case when data comes from central server and needs >> to be passed to consumers via PKCS#11 interface but in this case data >> comes from a user and actually should not come from SSSD but rather a >> real smart card inserted by user. What am I missing? > > Petr suggests we store users' private keys in IPA. I don't see any benefit in > this, but it is doable with what we are planning for DNSSEC and CA rotation. I have discussed this with Honza in person. He didn't consider roaming users, i.e. users moving from one workstation to another workstation. This solves problem with safe key distribution between machines. Another advantage is that non-root process can't steal user's private key. (Compare this with file-based storage. Any process running with user privileges can read the key from ~/.ssh/.) Of course, you can do the same thing with real smartcard but - who does that in practice? :-) -- Petr^2 Spacek From pviktori at redhat.com Thu Feb 20 11:03:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 12:03:57 +0100 Subject: [Freeipa-devel] [PATCH] 0470 - .mailmap: Remove spurious Kyle Baker line Message-ID: <5305E11D.9050107@redhat.com> Hello, This removes an unnecessary .mailmap line I left in by mistake. Thanks to adelton for finding it. Pushed to master under the one-liner rule: 340cbd4a7d2fc31ae20843477156a2948529a41e -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0470-.mailmap-Remove-spurious-Kyle-Baker-line.patch Type: text/x-patch Size: 1098 bytes Desc: not available URL: From pviktori at redhat.com Thu Feb 20 11:20:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 12:20:12 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <20140219155413.GB26583@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> Message-ID: <5305E4EC.5000505@redhat.com> On 02/19/2014 04:54 PM, Jan Pazdziora wrote: > On Wed, Feb 19, 2014 at 04:37:05PM +0100, Tomas Babej wrote: >> Hi, >> >> When restoring files from backup, we do use an incorrect order of >> operations - we first restore SELinux context and then copy the >> files from backup, when we need to do the exact opposite. >> >> https://fedorahosted.org/freeipa/ticket/4133 >> > >> >From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Wed, 19 Feb 2014 16:31:12 +0100 >> Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring >> backup >> >> When restoring files from backup, we do use an incorrect order of >> operations - we first restore SELinux context and then copy the >> files from backup, when we need to do the exact opposite. >> >> https://fedorahosted.org/freeipa/ticket/4133 >> --- >> ipatests/test_integration/tasks.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >> index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278 100644 >> --- a/ipatests/test_integration/tasks.py >> +++ b/ipatests/test_integration/tasks.py >> @@ -137,7 +137,7 @@ def restore_files(host): >> >> # Run both commands in one session. For more information, see: >> # https://fedorahosted.org/freeipa/ticket/4133 >> - host.run_command('%s ; (%s ||:)' % (restorecon_command, copyfiles_command)) >> + host.run_command('%s ; (%s ||:)' % (copyfiles_command, restorecon_command)) > > ACK -- having the files in place is definitely useful if we then want > to find them there. > > However: since this is about restoring a backup, can't the backup > contain the extended attributes, so that the SELinux context gets > restored to the original state (which could be different from what > the restorecon will give you)? Well, I guess you're the Beaker authority here. Is that necessary when restoring? The tests expect a "sane" state, and they return to that; using a somehow customized machine to test on is a bad idea anyway. -- Petr? From abokovoy at redhat.com Thu Feb 20 11:27:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Feb 2014 13:27:06 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140219212558.GE16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> Message-ID: <20140220112706.GJ16644@redhat.com> On Wed, 19 Feb 2014, Alexander Bokovoy wrote: > On Wed, 19 Feb 2014, Alexander Bokovoy wrote: >> On Mon, 17 Feb 2014, Alexander Bokovoy wrote: >>> On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >>>> On Wed, 12 Feb 2014, Nathaniel McCallum wrote: >>>>> Through the review process, patches are getting shifted around, added, >>>>> deleted, etc. So I'm now just going to be posting all the patches as an >>>>> ordered set. The set attached is ordered according to my preferred merge >>>>> order. It also places easy to review patches up front. I hope this helps >>>>> reviewers. This format will definitely help me manage the patches. >>>>> >>>>> The first three patches should be very easy reviews and can be merged >>>>> independently. >>>>> >>>>> All current patch critiques have, to my knowledge, been addressed in >>>>> this latest series of patches. >>>> I have tested all the patches altogether, including Web UI patches, and >>>> everything works. >>>> >>>> I have set up a COPR repo for others to try: >>>> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >>>> >>>> However, there is one issue which I was not yet able to pin-point in the >>>> SLAPI plugins. During FreeIPA install and later on actual use I see >>>> these in the dirsrv error log: >>>> >>>> [13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>>> [13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>>> [13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter >>>> [13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL >>>> [13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code -1 >>>> [13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter >>>> [13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL >>>> [13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter >>>> [13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL >>>> >>>> Additionally, when slapi-nis is enabled, LDAP bind with identity from >>>> compat tree fails for OTP use and succeeds for password authentication. >>>> >>>> In compat tree we are doing this trick: >>>> 1731 /* Otherwise force rewrite of the >>>> SLAPI_BIND_TARGET_SDN 1732 * >>>> and let other plugins to handle it. >>>> 1733 * slapi-nis should have plugin ordering set below standard 50 to succeed */ >>>> 1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, &sdn); >>>> 1735 if (sdn != NULL) { >>>> 1736 slapi_sdn_free(&sdn); >>>> 1737 } >>>> 1738 sdn = slapi_sdn_new_dn_byref(ndn); >>>> 1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn); >>>> 1740 ret = 0; >>>> 1741 } >>>> >>>> I tried to play with plugin precedence and it didn't really help. >>>> >>>> There is definitely a bug (or more) in ipa-pwd-extop in handling >>>> authentication cases. >>> Some progress on this investigation. >>> >>> Plugin precedence setting is broken in 389-ds. It is only set once, >>> before running init function provided by the plugin and does not take >>> into account all callbacks that the init function may register. As >>> result, all these functions get classified with default precedence (50) >>> and no configuration could change this, we get ipa-pwd-extop's pre-bind >>> callback called before schemacompat's one, thus working on the compat >>> entry DN instead of the new one. Since that entry has no userPassword >>> attribute, OTP code refuses to accept any password. >>> >>> When user is allowed to use password auth along with OTP, the fact that >>> there is no userPassword get ipa-pwd-extop plugin through the failure. >>> schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of >>> 389-ds code checks actual password. >>> >>> So we have two issues here: OTP code needs to gracefully ignore entries >>> without userPassword set, and we need to be able to re-arrange >>> schemacompat and ipa-pwd-extop precedence for pre-bind operation. >>> >>> I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on >>> the latter. >>> >>> The messages from the log are not yet solved... >> Finally, I have a clue after tracing with debug level 1: >> [19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 >> [19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter >> [19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL >> [19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 >> >> So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. > There is an error in libotp's find() function which assumes that > get_basedn() always returns non-NULL value. This is not true for at > least cn=Directory Manager. > > Patch attached. More fixes required, now that Thierry produced the fix for 389-ds ticket 47699 which allows to re-arrange schema-compat and ipa-pwd-extop plugins. I'm getting crash in find() in libotp.c for internal search in some other conditions but at least user dn now is the correct one. Stay tuned. -- / Alexander Bokovoy From pviktori at redhat.com Thu Feb 20 11:34:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 12:34:25 +0100 Subject: [Freeipa-devel] [PATCH] 0468 permission-mod: Do not copy member attributes to new entry In-Reply-To: <5304CB07.3060403@redhat.com> References: <5304B570.8040904@redhat.com> <5304CB07.3060403@redhat.com> Message-ID: <5305E841.5020006@redhat.com> On 02/19/2014 04:17 PM, Jan Cholasta wrote: > On 19.2.2014 14:45, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/4178 >> > > Thanks, ACK. > Thanks, pushed to master: 0824d12c95d840b1787743e8316b0bc0f7ba5284 -- Petr? From mkosek at redhat.com Thu Feb 20 11:38:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 12:38:27 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <5305E4EC.5000505@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> <5305E4EC.5000505@redhat.com> Message-ID: <5305E933.8070401@redhat.com> On 02/20/2014 12:20 PM, Petr Viktorin wrote: > On 02/19/2014 04:54 PM, Jan Pazdziora wrote: >> On Wed, Feb 19, 2014 at 04:37:05PM +0100, Tomas Babej wrote: >>> Hi, >>> >>> When restoring files from backup, we do use an incorrect order of >>> operations - we first restore SELinux context and then copy the >>> files from backup, when we need to do the exact opposite. >>> >>> https://fedorahosted.org/freeipa/ticket/4133 >>> >> >>> >From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Wed, 19 Feb 2014 16:31:12 +0100 >>> Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring >>> backup >>> >>> When restoring files from backup, we do use an incorrect order of >>> operations - we first restore SELinux context and then copy the >>> files from backup, when we need to do the exact opposite. >>> >>> https://fedorahosted.org/freeipa/ticket/4133 >>> --- >>> ipatests/test_integration/tasks.py | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/ipatests/test_integration/tasks.py >>> b/ipatests/test_integration/tasks.py >>> index >>> 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278 >>> 100644 >>> --- a/ipatests/test_integration/tasks.py >>> +++ b/ipatests/test_integration/tasks.py >>> @@ -137,7 +137,7 @@ def restore_files(host): >>> >>> # Run both commands in one session. For more information, see: >>> # https://fedorahosted.org/freeipa/ticket/4133 >>> - host.run_command('%s ; (%s ||:)' % (restorecon_command, >>> copyfiles_command)) >>> + host.run_command('%s ; (%s ||:)' % (copyfiles_command, >>> restorecon_command)) >> >> ACK -- having the files in place is definitely useful if we then want >> to find them there. >> >> However: since this is about restoring a backup, can't the backup >> contain the extended attributes, so that the SELinux context gets >> restored to the original state (which could be different from what >> the restorecon will give you)? > > Well, I guess you're the Beaker authority here. Is that necessary when restoring? > The tests expect a "sane" state, and they return to that; using a somehow > customized machine to test on is a bad idea anyway. +1. If you added a proper SELinux rule on that machine to set the right file context, it will still be right after restorecon. Martin From tbabej at redhat.com Thu Feb 20 11:50:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Feb 2014 12:50:33 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <20140219155413.GB26583@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> Message-ID: <5305EC09.6080109@redhat.com> On 02/19/2014 04:54 PM, Jan Pazdziora wrote: > On Wed, Feb 19, 2014 at 04:37:05PM +0100, Tomas Babej wrote: >> Hi, >> >> When restoring files from backup, we do use an incorrect order of >> operations - we first restore SELinux context and then copy the >> files from backup, when we need to do the exact opposite. >> >> https://fedorahosted.org/freeipa/ticket/4133 >> >> >From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Wed, 19 Feb 2014 16:31:12 +0100 >> Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring >> backup >> >> When restoring files from backup, we do use an incorrect order of >> operations - we first restore SELinux context and then copy the >> files from backup, when we need to do the exact opposite. >> >> https://fedorahosted.org/freeipa/ticket/4133 >> --- >> ipatests/test_integration/tasks.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >> index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278 100644 >> --- a/ipatests/test_integration/tasks.py >> +++ b/ipatests/test_integration/tasks.py >> @@ -137,7 +137,7 @@ def restore_files(host): >> >> # Run both commands in one session. For more information, see: >> # https://fedorahosted.org/freeipa/ticket/4133 >> - host.run_command('%s ; (%s ||:)' % (restorecon_command, copyfiles_command)) >> + host.run_command('%s ; (%s ||:)' % (copyfiles_command, restorecon_command)) > ACK -- having the files in place is definitely useful if we then want > to find them there. > > However: since this is about restoring a backup, can't the backup > contain the extended attributes, so that the SELinux context gets > restored to the original state (which could be different from what > the restorecon will give you)? > Yes, it could. Preserving the context is not hard, we can just use: cp --preserve=context for backup & restore. But as others mention, we rather work with a "return-to-the-sane-state" rather than "return-to-the-previous-state" assumption here. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Thu Feb 20 11:57:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 12:57:21 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <5304DC8A.7030405@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> <5303AE38.7050408@redhat.com> <53047D0C.9060900@redhat.com> <5304DC8A.7030405@redhat.com> Message-ID: <5305EDA1.2020507@redhat.com> On 02/19/2014 05:32 PM, Martin Kosek wrote: > On 02/19/2014 10:44 AM, Petr Viktorin wrote: >> On 02/18/2014 08:02 PM, Petr Viktorin wrote: >>> On 02/18/2014 09:42 AM, Martin Kosek wrote: >>>> On 02/13/2014 01:12 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >>>>> Design: >>>>> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >>>>> >>>>> >>>>> Since --type, affects only targetfilter values in the form >>>>> "(objectclass=...)" >>>>> and leaves others alone, and in the -mod command we don't fetch the >>>>> existing >>>>> entry until the pre_callback, I had to put the adds/removes in the >>>>> context. I >>>>> don't think the approach is too terrible given the limitations. >>>> >>>> 464: >>>> >>>> 1) Internal Error: >>>> >>>> # ipa permission-mod can_write2 --filter='foo=bar' >>>> ipa: ERROR: an internal error has occurred >>> >>> Thanks for the catch! Fixed & added to tests. >>> >>>> 2) ACI target filter >>>> >>>> I would relabel targetfilter from "ACI target filter" to "Target >>>> filter" to >>>> make it consistent with other ACI attributes. We are sort of hiding >>>> there are >>>> any underlying ACIs anyway... >>> >>> Fixed. >>> >>>> 3) I am now thinking about the behavior of --memberof and --filter >>>> options and >>>> how they interact. It looks OK except for the case when I set filter >>>> to None: >>> >>> The same would happen when setting --filter to any other value(s) that >>> don't include existing memberOf filters. >>> >>>> # ipa permission-mod can_write2 --memberof=bar >>>> -------------------------------- >>>> Modified permission "can_write2" >>>> -------------------------------- >>>> Permission name: can_write2 >>>> Permissions: write >>>> Effective attributes: description >>>> Bind rule type: permission >>>> Subtree: dc=example,dc=com >>>> ACI target filter: (foo=bar), >>>> >>>> (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) >>>> Member of group: bar >>>> # ipa permission-mod can_write2 --filter= >>>> -------------------------------- >>>> Modified permission "can_write2" >>>> -------------------------------- >>>> Permission name: can_write2 >>>> Permissions: write >>>> Effective attributes: description >>>> Bind rule type: permission >>>> Subtree: dc=example,dc=com >>>> >>>> Then both memberOf and filter is erased. Are we ok with that? >>>> Shouldn't we keep >>>> memberOf part until that is set to None? I am not insisting, just >>>> trying to >>>> discuss the best behavior. >>> >>> Memberof affects the filter; this is even pointed out in --help output. >>> The alternative would be to make --filter= exclude filters affected by >>> other options, which I think would be even more confusing. >>> Keep in mind --type sets (objectclass=...) filters in exactly the same >>> way as --memberof works for (memberof=...). >>> The --memberof, --targetgroup, --type options are just shortcuts for >>> setting other permission attributes. I'm hoping we can get this message >>> across, in --help, and in the docs, well enough to reduce the confusion. >>> >>>> 465: I know this was already discussed previously, but I am now having >>>> second >>>> thoughts - should we use posixAccount as THE objectclass for user >>>> targetfilter? >>>> >>>> # ipa permission-add can_write --permissions write --attrs=description >>>> --type=user >>>> ---------------------------- >>>> Added permission "can_write" >>>> ---------------------------- >>>> Permission name: can_write >>>> Permissions: write >>>> Effective attributes: description >>>> Bind rule type: permission >>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>> ACI target filter: (objectclass=posixaccount) >>>> Type: user >>>> >>>> What if we add system users at some point which would miss the >>>> posixaccount >>>> objectclass? Wouldn't it be better to use the inetOrgPerson structural >>>> objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? >>> >>> I'm not opposed. >>> (I don't think it should block this patchset though. We'll have to add >>> canonical objectclasses to all the types that don't currently have them. >>> Deciding it for `user` can be a part of that effort.) >> >> Apologies, I've sent a slightly wrong version of the tests. Here's the fixed >> patchset. >> > > Thanks. New check works fine, but the attribute name in the error message seems > inconsistent: > > # ipa permission-mod can_write --filter=foo=bar > ipa: ERROR: invalid 'filter': must be enclosed in parentheses > > # ipa permission-mod can_write --filter="(foo=bar))" > ipa: ERROR: invalid 'ipapermtargetfilter': Bad search filter > > If you fix that, it's ACK for all. > > Martin > It turns out this is a deeper issue; for the time being I'd rather defer it for more discussion & refactoring than hack around it. https://fedorahosted.org/freeipa/ticket/4183 -- Petr? From jpazdziora at redhat.com Thu Feb 20 11:58:53 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 20 Feb 2014 12:58:53 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <5305E4EC.5000505@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> <5305E4EC.5000505@redhat.com> Message-ID: <20140220115852.GJ26583@redhat.com> On Thu, Feb 20, 2014 at 12:20:12PM +0100, Petr Viktorin wrote: > On 02/19/2014 04:54 PM, Jan Pazdziora wrote: > > > >However: since this is about restoring a backup, can't the backup > >contain the extended attributes, so that the SELinux context gets > >restored to the original state (which could be different from what > >the restorecon will give you)? > > Well, I guess you're the Beaker authority here. Is that necessary This is not about Beaker, is it? But since you mention it, beakerlib does cp -a upon backup and restore https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n484 https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n593 for files to preserve the SELinux context, plus chcon --reference upon backup for directories: https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n495 > when restoring? > The tests expect a "sane" state, and they return to that; using a > somehow customized machine to test on is a bad idea anyway. You might specifically want to run your test on non-sane state because you want to test that the non-sane state will for example produce correct error, SELinux-related or other. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Thu Feb 20 12:06:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 13:06:46 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <5305EDA1.2020507@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> <5303AE38.7050408@redhat.com> <53047D0C.9060900@redhat.com> <5304DC8A.7030405@redhat.com> <5305EDA1.2020507@redhat.com> Message-ID: <5305EFD6.6000205@redhat.com> On 02/20/2014 12:57 PM, Petr Viktorin wrote: > On 02/19/2014 05:32 PM, Martin Kosek wrote: >> On 02/19/2014 10:44 AM, Petr Viktorin wrote: >>> On 02/18/2014 08:02 PM, Petr Viktorin wrote: >>>> On 02/18/2014 09:42 AM, Martin Kosek wrote: >>>>> On 02/13/2014 01:12 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >>>>>> Design: >>>>>> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >>>>>> >>>>>> >>>>>> Since --type, affects only targetfilter values in the form >>>>>> "(objectclass=...)" >>>>>> and leaves others alone, and in the -mod command we don't fetch the >>>>>> existing >>>>>> entry until the pre_callback, I had to put the adds/removes in the >>>>>> context. I >>>>>> don't think the approach is too terrible given the limitations. >>>>> >>>>> 464: >>>>> >>>>> 1) Internal Error: >>>>> >>>>> # ipa permission-mod can_write2 --filter='foo=bar' >>>>> ipa: ERROR: an internal error has occurred >>>> >>>> Thanks for the catch! Fixed & added to tests. >>>> >>>>> 2) ACI target filter >>>>> >>>>> I would relabel targetfilter from "ACI target filter" to "Target >>>>> filter" to >>>>> make it consistent with other ACI attributes. We are sort of hiding >>>>> there are >>>>> any underlying ACIs anyway... >>>> >>>> Fixed. >>>> >>>>> 3) I am now thinking about the behavior of --memberof and --filter >>>>> options and >>>>> how they interact. It looks OK except for the case when I set filter >>>>> to None: >>>> >>>> The same would happen when setting --filter to any other value(s) that >>>> don't include existing memberOf filters. >>>> >>>>> # ipa permission-mod can_write2 --memberof=bar >>>>> -------------------------------- >>>>> Modified permission "can_write2" >>>>> -------------------------------- >>>>> Permission name: can_write2 >>>>> Permissions: write >>>>> Effective attributes: description >>>>> Bind rule type: permission >>>>> Subtree: dc=example,dc=com >>>>> ACI target filter: (foo=bar), >>>>> >>>>> (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) >>>>> Member of group: bar >>>>> # ipa permission-mod can_write2 --filter= >>>>> -------------------------------- >>>>> Modified permission "can_write2" >>>>> -------------------------------- >>>>> Permission name: can_write2 >>>>> Permissions: write >>>>> Effective attributes: description >>>>> Bind rule type: permission >>>>> Subtree: dc=example,dc=com >>>>> >>>>> Then both memberOf and filter is erased. Are we ok with that? >>>>> Shouldn't we keep >>>>> memberOf part until that is set to None? I am not insisting, just >>>>> trying to >>>>> discuss the best behavior. >>>> >>>> Memberof affects the filter; this is even pointed out in --help output. >>>> The alternative would be to make --filter= exclude filters affected by >>>> other options, which I think would be even more confusing. >>>> Keep in mind --type sets (objectclass=...) filters in exactly the same >>>> way as --memberof works for (memberof=...). >>>> The --memberof, --targetgroup, --type options are just shortcuts for >>>> setting other permission attributes. I'm hoping we can get this message >>>> across, in --help, and in the docs, well enough to reduce the confusion. >>>> >>>>> 465: I know this was already discussed previously, but I am now having >>>>> second >>>>> thoughts - should we use posixAccount as THE objectclass for user >>>>> targetfilter? >>>>> >>>>> # ipa permission-add can_write --permissions write --attrs=description >>>>> --type=user >>>>> ---------------------------- >>>>> Added permission "can_write" >>>>> ---------------------------- >>>>> Permission name: can_write >>>>> Permissions: write >>>>> Effective attributes: description >>>>> Bind rule type: permission >>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>> ACI target filter: (objectclass=posixaccount) >>>>> Type: user >>>>> >>>>> What if we add system users at some point which would miss the >>>>> posixaccount >>>>> objectclass? Wouldn't it be better to use the inetOrgPerson structural >>>>> objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? >>>> >>>> I'm not opposed. >>>> (I don't think it should block this patchset though. We'll have to add >>>> canonical objectclasses to all the types that don't currently have them. >>>> Deciding it for `user` can be a part of that effort.) >>> >>> Apologies, I've sent a slightly wrong version of the tests. Here's the fixed >>> patchset. >>> >> >> Thanks. New check works fine, but the attribute name in the error message seems >> inconsistent: >> >> # ipa permission-mod can_write --filter=foo=bar >> ipa: ERROR: invalid 'filter': must be enclosed in parentheses >> >> # ipa permission-mod can_write --filter="(foo=bar))" >> ipa: ERROR: invalid 'ipapermtargetfilter': Bad search filter >> >> If you fix that, it's ACK for all. >> >> Martin >> > > It turns out this is a deeper issue; for the time being I'd rather defer it for > more discussion & refactoring than hack around it. > > https://fedorahosted.org/freeipa/ticket/4183 > Ok, agreed. ACK to the original patches then. Martin From pviktori at redhat.com Thu Feb 20 12:07:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 13:07:01 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <20140220115852.GJ26583@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> <5305E4EC.5000505@redhat.com> <20140220115852.GJ26583@redhat.com> Message-ID: <5305EFE5.70809@redhat.com> On 02/20/2014 12:58 PM, Jan Pazdziora wrote: > On Thu, Feb 20, 2014 at 12:20:12PM +0100, Petr Viktorin wrote: >> On 02/19/2014 04:54 PM, Jan Pazdziora wrote: >>> >>> However: since this is about restoring a backup, can't the backup >>> contain the extended attributes, so that the SELinux context gets >>> restored to the original state (which could be different from what >>> the restorecon will give you)? >> >> Well, I guess you're the Beaker authority here. Is that necessary > > This is not about Beaker, is it? It is; all other use cases I know of use disposable or at least single-purpose VMs. > But since you mention it, beakerlib does cp -a upon backup and restore > > https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n484 > https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n593 > > for files to preserve the SELinux context, plus chcon --reference > upon backup for directories: > > https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n495 > >> when restoring? >> The tests expect a "sane" state, and they return to that; using a >> somehow customized machine to test on is a bad idea anyway. > > You might specifically want to run your test on non-sane state because > you want to test that the non-sane state will for example produce > correct error, SELinux-related or other. In that case you're on your own, you should wrap the test in custom setup & teardown code. There's no way we can perfectly restore a system after IPA has been installed on it, much less if it was an unstable/testing version of IPA, so returning to a sane state seems good for me. -- Petr? From pviktori at redhat.com Thu Feb 20 12:12:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 13:12:25 +0100 Subject: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter In-Reply-To: <5305EFD6.6000205@redhat.com> References: <52FCB69E.4040104@redhat.com> <53031CDA.2060705@redhat.com> <5303AE38.7050408@redhat.com> <53047D0C.9060900@redhat.com> <5304DC8A.7030405@redhat.com> <5305EDA1.2020507@redhat.com> <5305EFD6.6000205@redhat.com> Message-ID: <5305F129.7020604@redhat.com> On 02/20/2014 01:06 PM, Martin Kosek wrote: > On 02/20/2014 12:57 PM, Petr Viktorin wrote: >> On 02/19/2014 05:32 PM, Martin Kosek wrote: >>> On 02/19/2014 10:44 AM, Petr Viktorin wrote: >>>> On 02/18/2014 08:02 PM, Petr Viktorin wrote: >>>>> On 02/18/2014 09:42 AM, Martin Kosek wrote: >>>>>> On 02/13/2014 01:12 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> These patches fix https://fedorahosted.org/freeipa/ticket/4074 >>>>>>> Design: >>>>>>> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >>>>>>> >>>>>>> >>>>>>> Since --type, affects only targetfilter values in the form >>>>>>> "(objectclass=...)" >>>>>>> and leaves others alone, and in the -mod command we don't fetch the >>>>>>> existing >>>>>>> entry until the pre_callback, I had to put the adds/removes in the >>>>>>> context. I >>>>>>> don't think the approach is too terrible given the limitations. >>>>>> >>>>>> 464: >>>>>> >>>>>> 1) Internal Error: >>>>>> >>>>>> # ipa permission-mod can_write2 --filter='foo=bar' >>>>>> ipa: ERROR: an internal error has occurred >>>>> >>>>> Thanks for the catch! Fixed & added to tests. >>>>> >>>>>> 2) ACI target filter >>>>>> >>>>>> I would relabel targetfilter from "ACI target filter" to "Target >>>>>> filter" to >>>>>> make it consistent with other ACI attributes. We are sort of hiding >>>>>> there are >>>>>> any underlying ACIs anyway... >>>>> >>>>> Fixed. >>>>> >>>>>> 3) I am now thinking about the behavior of --memberof and --filter >>>>>> options and >>>>>> how they interact. It looks OK except for the case when I set filter >>>>>> to None: >>>>> >>>>> The same would happen when setting --filter to any other value(s) that >>>>> don't include existing memberOf filters. >>>>> >>>>>> # ipa permission-mod can_write2 --memberof=bar >>>>>> -------------------------------- >>>>>> Modified permission "can_write2" >>>>>> -------------------------------- >>>>>> Permission name: can_write2 >>>>>> Permissions: write >>>>>> Effective attributes: description >>>>>> Bind rule type: permission >>>>>> Subtree: dc=example,dc=com >>>>>> ACI target filter: (foo=bar), >>>>>> >>>>>> (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) >>>>>> Member of group: bar >>>>>> # ipa permission-mod can_write2 --filter= >>>>>> -------------------------------- >>>>>> Modified permission "can_write2" >>>>>> -------------------------------- >>>>>> Permission name: can_write2 >>>>>> Permissions: write >>>>>> Effective attributes: description >>>>>> Bind rule type: permission >>>>>> Subtree: dc=example,dc=com >>>>>> >>>>>> Then both memberOf and filter is erased. Are we ok with that? >>>>>> Shouldn't we keep >>>>>> memberOf part until that is set to None? I am not insisting, just >>>>>> trying to >>>>>> discuss the best behavior. >>>>> >>>>> Memberof affects the filter; this is even pointed out in --help output. >>>>> The alternative would be to make --filter= exclude filters affected by >>>>> other options, which I think would be even more confusing. >>>>> Keep in mind --type sets (objectclass=...) filters in exactly the same >>>>> way as --memberof works for (memberof=...). >>>>> The --memberof, --targetgroup, --type options are just shortcuts for >>>>> setting other permission attributes. I'm hoping we can get this message >>>>> across, in --help, and in the docs, well enough to reduce the confusion. >>>>> >>>>>> 465: I know this was already discussed previously, but I am now having >>>>>> second >>>>>> thoughts - should we use posixAccount as THE objectclass for user >>>>>> targetfilter? >>>>>> >>>>>> # ipa permission-add can_write --permissions write --attrs=description >>>>>> --type=user >>>>>> ---------------------------- >>>>>> Added permission "can_write" >>>>>> ---------------------------- >>>>>> Permission name: can_write >>>>>> Permissions: write >>>>>> Effective attributes: description >>>>>> Bind rule type: permission >>>>>> Subtree: cn=users,cn=accounts,dc=example,dc=com >>>>>> ACI target filter: (objectclass=posixaccount) >>>>>> Type: user >>>>>> >>>>>> What if we add system users at some point which would miss the >>>>>> posixaccount >>>>>> objectclass? Wouldn't it be better to use the inetOrgPerson structural >>>>>> objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? >>>>> >>>>> I'm not opposed. >>>>> (I don't think it should block this patchset though. We'll have to add >>>>> canonical objectclasses to all the types that don't currently have them. >>>>> Deciding it for `user` can be a part of that effort.) >>>> >>>> Apologies, I've sent a slightly wrong version of the tests. Here's the fixed >>>> patchset. >>>> >>> >>> Thanks. New check works fine, but the attribute name in the error message seems >>> inconsistent: >>> >>> # ipa permission-mod can_write --filter=foo=bar >>> ipa: ERROR: invalid 'filter': must be enclosed in parentheses >>> >>> # ipa permission-mod can_write --filter="(foo=bar))" >>> ipa: ERROR: invalid 'ipapermtargetfilter': Bad search filter >>> >>> If you fix that, it's ACK for all. >>> >>> Martin >>> >> >> It turns out this is a deeper issue; for the time being I'd rather defer it for >> more discussion & refactoring than hack around it. >> >> https://fedorahosted.org/freeipa/ticket/4183 >> > > Ok, agreed. ACK to the original patches then. > > Martin > Thanks, pushed to master: 0f1e13761993cdc77a573a68686723fa816ce5a9 -- Petr? From mkosek at redhat.com Thu Feb 20 12:14:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 13:14:50 +0100 Subject: [Freeipa-devel] Reviewer in Trac Message-ID: <5305F1BA.8080008@redhat.com> We had a discussion with other developers how better track who is reviewing which patch. Recently, we introduced the Reviewed-By tag in a commit message, but that is a post-review tag which is not useful for someone who wants to know which patches are already reviewed and which are not reviewed. We were testing Patch Work [1] in last months to contain this information, but I personally think that it is suboptimal - it introduces 2 tracking tools that needs to be maintained (Trac and Patch Work) and the Patch Work still requires lot of manual actions when maintaining it's state. I think it would be better to hold this information rather in a single tracking tool - Trac. There are 2 options: 1) "Patch on review" flag, similar to "Patch posted for review" flag which would hold 1 bit information if the patch is just lying there or has somebody assigned. 2) "Reviewed by" text field which would hold a login of a person who is reviewing it. It would be filled either by a person starting the review or by a supervisor like me to forcefully assign a reviewer ;-) With that information in Trac, we could run using a single tracking tool for all patches that have a ticket (which is 95% of patches). It would be then fairly easy to see which patches are sent for review but are reviewer-less. It would also have a benefit for Petr's sendpatches.py script which could pull the reviewer from a ticket and one would not have to use the "-r" option to hard code a reviewer. Any objections to using "Reviewed by" field? [1] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Thu Feb 20 12:22:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 13:22:56 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F1BA.8080008@redhat.com> References: <5305F1BA.8080008@redhat.com> Message-ID: <5305F3A0.60606@redhat.com> On 02/20/2014 01:14 PM, Martin Kosek wrote: > We had a discussion with other developers how better track who is reviewing > which patch. Recently, we introduced the Reviewed-By tag in a commit message, > but that is a post-review tag which is not useful for someone who wants to know > which patches are already reviewed and which are not reviewed. > > We were testing Patch Work [1] in last months to contain this information, but > I personally think that it is suboptimal - it introduces 2 tracking tools that > needs to be maintained (Trac and Patch Work) and the Patch Work still requires > lot of manual actions when maintaining it's state. > > I think it would be better to hold this information rather in a single tracking > tool - Trac. There are 2 options: > > 1) "Patch on review" flag, similar to "Patch posted for review" flag which > would hold 1 bit information if the patch is just lying there or has somebody > assigned. > > 2) "Reviewed by" text field which would hold a login of a person who is > reviewing it. It would be filled either by a person starting the review or by a > supervisor like me to forcefully assign a reviewer ;-) > > With that information in Trac, we could run using a single tracking tool for > all patches that have a ticket (which is 95% of patches). It would be then > fairly easy to see which patches are sent for review but are reviewer-less. > > It would also have a benefit for Petr's sendpatches.py script which could pull > the reviewer from a ticket and one would not have to use the "-r" option to > hard code a reviewer. > > Any objections to using "Reviewed by" field? +1, this is the only thing I used Patchwork for, and keeping Patchwork up to date just for this took a lot of unnecessary mindless clicking. Just a nitpick: name it "Patch Reviewer" - there's more to a ticket than a patch - the review is not done yet when the field is filled out -- Petr? From sbose at redhat.com Thu Feb 20 12:31:22 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 20 Feb 2014 13:31:22 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F1BA.8080008@redhat.com> References: <5305F1BA.8080008@redhat.com> Message-ID: <20140220123122.GB25217@localhost.localdomain> On Thu, Feb 20, 2014 at 01:14:50PM +0100, Martin Kosek wrote: > We had a discussion with other developers how better track who is reviewing > which patch. Recently, we introduced the Reviewed-By tag in a commit message, > but that is a post-review tag which is not useful for someone who wants to know > which patches are already reviewed and which are not reviewed. > > We were testing Patch Work [1] in last months to contain this information, but > I personally think that it is suboptimal - it introduces 2 tracking tools that > needs to be maintained (Trac and Patch Work) and the Patch Work still requires > lot of manual actions when maintaining it's state. > > I think it would be better to hold this information rather in a single tracking > tool - Trac. There are 2 options: > > 1) "Patch on review" flag, similar to "Patch posted for review" flag which > would hold 1 bit information if the patch is just lying there or has somebody > assigned. > > 2) "Reviewed by" text field which would hold a login of a person who is > reviewing it. It would be filled either by a person starting the review or by a > supervisor like me to forcefully assign a reviewer ;-) +1 is it possible to instruct trac to send an email to the reviewer to let him know the he's the chosen one? I guess this would help to even better integrate with the workflow of many developers? bye, Sumit > > With that information in Trac, we could run using a single tracking tool for > all patches that have a ticket (which is 95% of patches). It would be then > fairly easy to see which patches are sent for review but are reviewer-less. > > It would also have a benefit for Petr's sendpatches.py script which could pull > the reviewer from a ticket and one would not have to use the "-r" option to > hard code a reviewer. > > Any objections to using "Reviewed by" field? > > [1] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tbabej at redhat.com Thu Feb 20 12:31:24 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Feb 2014 13:31:24 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F3A0.60606@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> Message-ID: <5305F59C.3050808@redhat.com> On 02/20/2014 01:22 PM, Petr Viktorin wrote: > On 02/20/2014 01:14 PM, Martin Kosek wrote: >> We had a discussion with other developers how better track who is >> reviewing >> which patch. Recently, we introduced the Reviewed-By tag in a commit >> message, >> but that is a post-review tag which is not useful for someone who >> wants to know >> which patches are already reviewed and which are not reviewed. >> >> We were testing Patch Work [1] in last months to contain this >> information, but >> I personally think that it is suboptimal - it introduces 2 tracking >> tools that >> needs to be maintained (Trac and Patch Work) and the Patch Work still >> requires >> lot of manual actions when maintaining it's state. >> >> I think it would be better to hold this information rather in a >> single tracking >> tool - Trac. There are 2 options: >> >> 1) "Patch on review" flag, similar to "Patch posted for review" flag >> which >> would hold 1 bit information if the patch is just lying there or has >> somebody >> assigned. >> >> 2) "Reviewed by" text field which would hold a login of a person who is >> reviewing it. It would be filled either by a person starting the >> review or by a >> supervisor like me to forcefully assign a reviewer ;-) >> >> With that information in Trac, we could run using a single tracking >> tool for >> all patches that have a ticket (which is 95% of patches). It would be >> then >> fairly easy to see which patches are sent for review but are >> reviewer-less. >> >> It would also have a benefit for Petr's sendpatches.py script which >> could pull >> the reviewer from a ticket and one would not have to use the "-r" >> option to >> hard code a reviewer. >> >> Any objections to using "Reviewed by" field? > > +1, this is the only thing I used Patchwork for, and keeping Patchwork > up to date just for this took a lot of unnecessary mindless clicking. > > Just a nitpick: name it "Patch Reviewer" > - there's more to a ticket than a patch > - the review is not done yet when the field is filled out > I agree with all said above (and with Petr's comments as well). Honestly I'm surprised this solution did not occur to us sooner. Having the "Patch Reviewer" rather than "Patch on review" field is beneficial in that: 1.) you can query the tickets by the reviewer (e.g. look up the patches you volunteered to review) 2.) you don't have to look up in ticket comments to see who changed the "Patch on review" flag -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Thu Feb 20 12:33:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Feb 2014 14:33:38 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140220112706.GJ16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> Message-ID: <20140220123338.GK16644@redhat.com> On Thu, 20 Feb 2014, Alexander Bokovoy wrote: >>>>>There is definitely a bug (or more) in ipa-pwd-extop in handling >>>>>authentication cases. >>>>Some progress on this investigation. >>>> >>>>Plugin precedence setting is broken in 389-ds. It is only set once, >>>>before running init function provided by the plugin and does not take >>>>into account all callbacks that the init function may register. As >>>>result, all these functions get classified with default precedence (50) >>>>and no configuration could change this, we get ipa-pwd-extop's pre-bind >>>>callback called before schemacompat's one, thus working on the compat >>>>entry DN instead of the new one. Since that entry has no userPassword >>>>attribute, OTP code refuses to accept any password. >>>> >>>>When user is allowed to use password auth along with OTP, the fact that >>>>there is no userPassword get ipa-pwd-extop plugin through the failure. >>>>schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of >>>>389-ds code checks actual password. >>>> >>>>So we have two issues here: OTP code needs to gracefully ignore entries >>>>without userPassword set, and we need to be able to re-arrange >>>>schemacompat and ipa-pwd-extop precedence for pre-bind operation. >>>> >>>>I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on >>>>the latter. >>>> >>>>The messages from the log are not yet solved... >>>Finally, I have a clue after tracing with debug level 1: >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 >>>[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter >>>[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 >>> >>>So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. >>There is an error in libotp's find() function which assumes that >>get_basedn() always returns non-NULL value. This is not true for at >>least cn=Directory Manager. >> >>Patch attached. >More fixes required, now that Thierry produced the fix for 389-ds ticket >47699 which allows to re-arrange schema-compat and ipa-pwd-extop >plugins. I'm getting crash in find() in libotp.c for internal search in >some other conditions but at least user dn now is the correct one. > >Stay tuned. OK, finally I've got it working -- my last patch had error which could be attributed to the late night time. New patch is attached to fix libotp to work properly with empty base dn (such as cn=Directory Manager). Also I'm attaching the patch that sets precedence of schema-compat plugin to 49 (less than default 50). With this patch and 389-ds with patch from ticket 47699 compat tree binds work with OTP. When updated 389-ds-base will be released, we'll need to add Requires: to our RPM spec to depend on it. Without the updated 389-ds-base compat tree binds will not work with OTP but the rest will be working fine. Finally, ACK to all OTP patches. -- / Alexander Bokovoy -------------- next part -------------- >From de0c56f98b4558a591cc0d416815141c0cbdfbf3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 19 Feb 2014 23:24:29 +0200 Subject: [PATCH 16/17] libotp: do not call internal search for NULL dn --- daemons/ipa-slapi-plugins/libotp/libotp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/libotp/libotp.c b/daemons/ipa-slapi-plugins/libotp/libotp.c index 31cc591..e6c8eaa 100644 --- a/daemons/ipa-slapi-plugins/libotp/libotp.c +++ b/daemons/ipa-slapi-plugins/libotp/libotp.c @@ -332,6 +332,7 @@ static struct otptoken **find(Slapi_ComponentId *id, const char *user_dn, Slapi_PBlock *pb = NULL; Slapi_DN *sdn = NULL; char *filter = NULL; + const char *basedn = NULL; size_t count = 0; int result = -1; @@ -362,8 +363,12 @@ static struct otptoken **find(Slapi_ComponentId *id, const char *user_dn, if (sdn == NULL) goto error; + basedn = get_basedn(sdn); + if (basedn == NULL) + goto error; + /* Find all user tokens. */ - slapi_search_internal_set_pb(pb, get_basedn(sdn), + slapi_search_internal_set_pb(pb, basedn, LDAP_SCOPE_SUBTREE, filter, NULL, 0, NULL, NULL, id, 0); } -- 1.8.5.3 -------------- next part -------------- >From fa4e982f7c424bad9105b283cee34a1758fa6e9d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 20 Feb 2014 12:18:16 +0200 Subject: [PATCH 17/17] schema-compat: set precedence to 49 to allow OTP binds over compat tree schema-compat plugin rewrites bind DN to point to the original entry on LDAP bind operation. To work with OTP tokens this requires that schema-compat's pre-bind callback is called before pre-bind callback of the ipa-pwd-extop plugin. Therefore, schema-compat plugin should have a nsslapd-pluginprecedence value lower than (default) 50 which is used by the ipa-pwd-extop plugin. Note that this will only work if ticket 47699 is fixed in 389-ds. --- install/share/schema_compat.uldif | 4 ++++ install/updates/10-schema_compat.update | 7 +++++++ 2 files changed, 11 insertions(+) diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index 40b9611..9a9607e 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -13,6 +13,10 @@ default:nsslapd-plugininitfunc: schema_compat_plugin_init default:nsslapd-plugintype: object default:nsslapd-pluginenabled: on default:nsslapd-pluginid: schema-compat-plugin +# We need to run schema-compat pre-bind callback before +# other IPA pre-bind callbacks to make sure bind DN is +# rewritten to the original entry if needed +default:nsslapd-pluginprecedence: 49 default:nsslapd-pluginversion: 0.8 default:nsslapd-pluginbetxn: on default:nsslapd-pluginvendor: redhat.com diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index 1199ef3..505bfca 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -23,3 +23,10 @@ default:schema-compat-entry-attribute: macAddress=%{macAddress} dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config add:schema-compat-entry-attribute: sudoOrder=%{sudoOrder} + +dn: cn=Schema Compatibility,cn=plugins,cn=config +# We need to run schema-compat pre-bind callback before +# other IPA pre-bind callbacks to make sure bind DN is +# rewritten to the original entry if needed +add:nsslapd-pluginprecedence: 49 + -- 1.8.5.3 From lkrispen at redhat.com Thu Feb 20 12:39:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 20 Feb 2014 13:39:46 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53036B7F.2030806@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> Message-ID: <5305F792.4010200@redhat.com> Hi, I am now getting more familiar with PKCS#11 and did check which objects are handled by softhsm and I think the best way would be a direct mapping of a subset of the pkcs#11 objectclasses and attributes to LDAP. In my understanding we would only need the objectclasses of storage objects: certificate, {private|public|secret}key, evtl data. The attributes would then be the attributes required by these objectclassses. And here I am having a bit difficulties, eg in the spec: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf in the example (11.7) for adding a publicKey the attributes CKA_MODULUS and CKA_PUBLIC_EXPONENT are used, but these are not listed in the tables in 10.7 as "Common Key Attributes", so how do I know which are the required and allowed attributes for these objectclasses ? I will start to write a draft for the schema definitions we can discuss, but any input is welcome. Regards, Ludwig On 02/18/2014 03:17 PM, Jan Cholasta wrote: > Hi, > > On 18.2.2014 14:02, Ludwig Krispenz wrote: >> Hi, >> >> yesterday jan asked me about the status of the schema and if it would be >> ready for certificate storage an dthat puzzled me a bit and showed that >> I still do not really understand what you want to store in LDAP. >> Two me there are two very different approaches. >> >> 1] LDAP as store for high level objects like certs and keys >> For certs and related stuff there is rfc4523 and the schema for ldif >> exists. For keys we would decide if the key is stored in PKCS#8 format >> or as bind keypairs and define a key attribute and that's it. we could >> export keys with softhsm, (eventually convert them) and add to ldap, in >> the long term solution the PKCS#11 replacemnt would need to manage these >> high level objects > > I think RFC 4523 is not the right schema in this case, as it is suited > for PKIs rather than generic cryptographic data storage. For example, > RFC 4523 distinguishes between CA and end entity certificates, but in > PKCS#11 there are just certificates without any semantics attached to > them. > >> >> 2] low level replacement for eg the sqlite3 database in softhsm. >> That's what I sometimes get the impression what is wanted. SoftHsm has >> one component Softdatabase with an API, which more or less passes sets >> of attributes (attributes defined by PKCS#11) and then stores it as >> records in sql where each record has a keytype and opaque blob of data. >> If that is what is wanted the decision would be how fingrained the pkcs >> objects/attribute types would have to be mapped to ldap: one ldap >> attribute for each possible attribute type ? > > One-to-one mapping of attributes from PKCS#11 to LDAP would be the > most straightforward way of doing this, but I think we can do some > optimization for our needs. For example, like you said above, we can > use a single attribute containing PKCS#8 encoded private key rather > than using one attribute per private key component. > > I don't think we need an LDAP attribute for every possible PKCS#11 > attribute, ATM it would be sufficient to have just these attributes > necessary to represent private key, public key and certificate objects. > > So, I would say it should be something between high-level and low-level. > > Honza > From mkosek at redhat.com Thu Feb 20 12:36:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 13:36:07 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F3A0.60606@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> Message-ID: <5305F6B7.4090701@redhat.com> On 02/20/2014 01:22 PM, Petr Viktorin wrote: > On 02/20/2014 01:14 PM, Martin Kosek wrote: >> We had a discussion with other developers how better track who is reviewing >> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >> but that is a post-review tag which is not useful for someone who wants to know >> which patches are already reviewed and which are not reviewed. >> >> We were testing Patch Work [1] in last months to contain this information, but >> I personally think that it is suboptimal - it introduces 2 tracking tools that >> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >> lot of manual actions when maintaining it's state. >> >> I think it would be better to hold this information rather in a single tracking >> tool - Trac. There are 2 options: >> >> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >> would hold 1 bit information if the patch is just lying there or has somebody >> assigned. >> >> 2) "Reviewed by" text field which would hold a login of a person who is >> reviewing it. It would be filled either by a person starting the review or by a >> supervisor like me to forcefully assign a reviewer ;-) >> >> With that information in Trac, we could run using a single tracking tool for >> all patches that have a ticket (which is 95% of patches). It would be then >> fairly easy to see which patches are sent for review but are reviewer-less. >> >> It would also have a benefit for Petr's sendpatches.py script which could pull >> the reviewer from a ticket and one would not have to use the "-r" option to >> hard code a reviewer. >> >> Any objections to using "Reviewed by" field? > > +1, this is the only thing I used Patchwork for, and keeping Patchwork up to > date just for this took a lot of unnecessary mindless clicking. > > Just a nitpick: name it "Patch Reviewer" > - there's more to a ticket than a patch > - the review is not done yet when the field is filled out I named it to be consistent to other fields: Reported by Owned by So maybe the name could be "Patch Review by"? Martin From pviktori at redhat.com Thu Feb 20 12:44:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 13:44:28 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F6B7.4090701@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <5305F6B7.4090701@redhat.com> Message-ID: <5305F8AC.7010905@redhat.com> On 02/20/2014 01:36 PM, Martin Kosek wrote: > On 02/20/2014 01:22 PM, Petr Viktorin wrote: >> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>> We had a discussion with other developers how better track who is reviewing >>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>> but that is a post-review tag which is not useful for someone who wants to know >>> which patches are already reviewed and which are not reviewed. >>> >>> We were testing Patch Work [1] in last months to contain this information, but >>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>> lot of manual actions when maintaining it's state. >>> >>> I think it would be better to hold this information rather in a single tracking >>> tool - Trac. There are 2 options: >>> >>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>> would hold 1 bit information if the patch is just lying there or has somebody >>> assigned. >>> >>> 2) "Reviewed by" text field which would hold a login of a person who is >>> reviewing it. It would be filled either by a person starting the review or by a >>> supervisor like me to forcefully assign a reviewer ;-) >>> >>> With that information in Trac, we could run using a single tracking tool for >>> all patches that have a ticket (which is 95% of patches). It would be then >>> fairly easy to see which patches are sent for review but are reviewer-less. >>> >>> It would also have a benefit for Petr's sendpatches.py script which could pull >>> the reviewer from a ticket and one would not have to use the "-r" option to >>> hard code a reviewer. >>> >>> Any objections to using "Reviewed by" field? >> >> +1, this is the only thing I used Patchwork for, and keeping Patchwork up to >> date just for this took a lot of unnecessary mindless clicking. >> >> Just a nitpick: name it "Patch Reviewer" >> - there's more to a ticket than a patch >> - the review is not done yet when the field is filled out > > I named it to be consistent to other fields: > > Reported by > Owned by > > So maybe the name could be "Patch Review by"? Fine by me. I'll stop my bikeshedding now. -- Petr? From pspacek at redhat.com Thu Feb 20 13:02:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 14:02:41 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <20140220123122.GB25217@localhost.localdomain> References: <5305F1BA.8080008@redhat.com> <20140220123122.GB25217@localhost.localdomain> Message-ID: <5305FCF1.3050901@redhat.com> On 20.2.2014 13:31, Sumit Bose wrote: > On Thu, Feb 20, 2014 at 01:14:50PM +0100, Martin Kosek wrote: >> We had a discussion with other developers how better track who is reviewing >> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >> but that is a post-review tag which is not useful for someone who wants to know >> which patches are already reviewed and which are not reviewed. >> >> We were testing Patch Work [1] in last months to contain this information, but >> I personally think that it is suboptimal - it introduces 2 tracking tools that >> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >> lot of manual actions when maintaining it's state. >> >> I think it would be better to hold this information rather in a single tracking >> tool - Trac. There are 2 options: >> >> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >> would hold 1 bit information if the patch is just lying there or has somebody >> assigned. >> >> 2) "Reviewed by" text field which would hold a login of a person who is >> reviewing it. It would be filled either by a person starting the review or by a >> supervisor like me to forcefully assign a reviewer ;-) > > +1 > > is it possible to instruct trac to send an email to the reviewer to let > him know the he's the chosen one? I guess this would help to even better > integrate with the workflow of many developers? It is definitely good idea! +1 >> With that information in Trac, we could run using a single tracking tool for >> all patches that have a ticket (which is 95% of patches). It would be then >> fairly easy to see which patches are sent for review but are reviewer-less. >> >> It would also have a benefit for Petr's sendpatches.py script which could pull >> the reviewer from a ticket and one would not have to use the "-r" option to >> hard code a reviewer. >> >> Any objections to using "Reviewed by" field? >> >> [1] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 -- Petr^2 Spacek From mkosek at redhat.com Thu Feb 20 13:15:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 14:15:22 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305FCF1.3050901@redhat.com> References: <5305F1BA.8080008@redhat.com> <20140220123122.GB25217@localhost.localdomain> <5305FCF1.3050901@redhat.com> Message-ID: <5305FFEA.4000403@redhat.com> On 02/20/2014 02:02 PM, Petr Spacek wrote: > On 20.2.2014 13:31, Sumit Bose wrote: >> On Thu, Feb 20, 2014 at 01:14:50PM +0100, Martin Kosek wrote: >>> We had a discussion with other developers how better track who is reviewing >>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>> but that is a post-review tag which is not useful for someone who wants to know >>> which patches are already reviewed and which are not reviewed. >>> >>> We were testing Patch Work [1] in last months to contain this information, but >>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>> lot of manual actions when maintaining it's state. >>> >>> I think it would be better to hold this information rather in a single tracking >>> tool - Trac. There are 2 options: >>> >>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>> would hold 1 bit information if the patch is just lying there or has somebody >>> assigned. >>> >>> 2) "Reviewed by" text field which would hold a login of a person who is >>> reviewing it. It would be filled either by a person starting the review or by a >>> supervisor like me to forcefully assign a reviewer ;-) >> >> +1 >> >> is it possible to instruct trac to send an email to the reviewer to let >> him know the he's the chosen one? I guess this would help to even better >> integrate with the workflow of many developers? > > It is definitely good idea! > +1 As always - this is a good idea. However, the execution is an integral part of a successful idea :) And in this case I am not sure how to do it in Trac. I tried looking for different notification or workflow plugin but did not find something applicable to our Trac - ideas welcome. A workaround for me is to fill both reviewer + CC when assigning a reviewer or also by adding a "My Active Patch Reviews by Milestone" view. Martin From amisnyov at redhat.com Thu Feb 20 13:15:24 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Thu, 20 Feb 2014 08:15:24 -0500 (EST) Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <5305BA5D.7040905@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> <530528FF.7020702@redhat.com> <5305BA5D.7040905@redhat.com> Message-ID: <1597764190.1440922.1392902124568.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Martin Kosek" > To: dpal at redhat.com, "Petr Spacek" > Cc: freeipa-devel at redhat.com > Sent: Thursday, February 20, 2014 9:18:37 AM > Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl > > On 02/19/2014 10:58 PM, Dmitri Pal wrote: > > On 02/19/2014 03:13 PM, Petr Spacek wrote: > >> On 19.2.2014 21:10, Dmitri Pal wrote: > >>> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: > >>>> Hi, > >>>> I reviewed this old patch: > >>>> > >>>> If an error occurs in the start up sequence in ipactl start/restart, > >>>> all the services are stopped. Using the --force/-f option prevents > >>>> stopping of services that have successfully started. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3509 > >>> > >>> > >>> I have not read the code but looked at the patch and bug. > >>> I do not understand the -force option especially with help string being: > >>> "If ipactl action fails, do not stop the services that are already > >>> running" > >>> force usually means the reverse: if something did not happen force it to > >>> happen. > >>> I am not sure that --force option is the right name for the option with > >>> this > >>> help. > >> > >> I have proposed --no-rollback but it didn't fit to habits in IPA: > >> https://fedorahosted.org/freeipa/ticket/3509#comment:2 > >> > > then it should be -fs/--force-start > > > > or something of this kind. > > > > IMO --force is not that bad, it forces start procedure to finish regardless > of > the result (if some service started or not). --force-start may be redundant: > > # ipactl start --force-start > # ipactl restart --force-start > > But I am not insisting on --force, if there is better option I am open to it. > > Few comments for the patch itself: > > 1) Please update it so that it does not use this construct: > > + try: > + svc_off.stop(capture_output=False) > + except: > + pass > > Bare except clauses also catch for example KeyboardInterrupt. Then if the > stop > command is stuck, I would not be able to CTRL+C it. "except Exception:" is > better. > > 2) The --force does not work as I would wish. When --force option is used, I > would like ipactl to try to start all services it can, regardless to if they > failed or not. > > Now it just does not rollback, but it still does not start all services it > can: > > # ipactl start --force > Existing service file detected! > Assuming stale, cleaning and proceeding > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting ipa_memcached Service > Starting httpd Service > Job for httpd.service failed. See 'systemctl status httpd.service' and > 'journalctl -xn' for details. > Failed to start httpd Service > Shutting down <== > Aborting ipactl > > See? HTTPD did not start, ipactl stopped and it did not start pki-tomcatd or > ipa-otpd even though they do not use HTTPD when starting. > > 3) I see we still write "Shutting down" even though we use --force. I would > rather print "Shutting down suppressed" or "Forced start, no service > rollback". > > Martin Hi, - Corrected to the desired behaviour - ipactl status now shows stopped services also, if the directory server is running. Please review! Thanks: Adam > > _______________________________________________ > 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-amisnyov-0003-Add-force-option-to-ipactl.patch Type: text/x-patch Size: 7317 bytes Desc: not available URL: From jcholast at redhat.com Thu Feb 20 13:20:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Feb 2014 14:20:45 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <5305F792.4010200@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <5305F792.4010200@redhat.com> Message-ID: <5306012D.7020402@redhat.com> On 20.2.2014 13:39, Ludwig Krispenz wrote: > Hi, > > I am now getting more familiar with PKCS#11 and did check which objects > are handled by softhsm and I think the best way would be a direct > mapping of a subset of the pkcs#11 objectclasses and attributes to LDAP. > In my understanding we would only need the objectclasses of storage > objects: certificate, {private|public|secret}key, evtl data. The > attributes would then be the attributes required by these > objectclassses. I agree, that's the way I imagined it. One thing to note is that in PKCS#11 an object is allowed to have only single object class, so when you want to get e.g. certificate and private key of a single entity, you must lookup a certificate object and a private key object which have the same CKA_ID. I think it would be nice if we could store them both in a single entry in LDAP, given that an entry is allowed to have multiple object classes. > And here I am having a bit difficulties, eg in the spec: > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf in > the example (11.7) for adding a publicKey the attributes CKA_MODULUS and > CKA_PUBLIC_EXPONENT are used, but these are not listed in the tables in > 10.7 as "Common Key Attributes", so how do I know which are the required > and allowed attributes for these objectclasses ? The attributes that hold the actual key data depend on the key algorithm, CKA_MODULUS and CKA_PUBLIC_EXPONENT are relevant to RSA, but they might not be relevant to other algorithms. But I don't think we need such a level of detail, I like your previous idea of storing private key material as PKCS#8 - it has all the key algorithm-specific bits inside, so we would be able to have just one object class for private keys (with common private keys attributes and one attribute to store the PKCS#8 blob in), instead of one object class per algorithm (with common private key attributes and algorithm-specific attributes). > I will start to write a draft for the schema definitions we can discuss, > but any input is welcome. > > Regards, > Ludwig > > On 02/18/2014 03:17 PM, Jan Cholasta wrote: >> Hi, >> >> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>> Hi, >>> >>> yesterday jan asked me about the status of the schema and if it would be >>> ready for certificate storage an dthat puzzled me a bit and showed that >>> I still do not really understand what you want to store in LDAP. >>> Two me there are two very different approaches. >>> >>> 1] LDAP as store for high level objects like certs and keys >>> For certs and related stuff there is rfc4523 and the schema for ldif >>> exists. For keys we would decide if the key is stored in PKCS#8 format >>> or as bind keypairs and define a key attribute and that's it. we could >>> export keys with softhsm, (eventually convert them) and add to ldap, in >>> the long term solution the PKCS#11 replacemnt would need to manage these >>> high level objects >> >> I think RFC 4523 is not the right schema in this case, as it is suited >> for PKIs rather than generic cryptographic data storage. For example, >> RFC 4523 distinguishes between CA and end entity certificates, but in >> PKCS#11 there are just certificates without any semantics attached to >> them. >> >>> >>> 2] low level replacement for eg the sqlite3 database in softhsm. >>> That's what I sometimes get the impression what is wanted. SoftHsm has >>> one component Softdatabase with an API, which more or less passes sets >>> of attributes (attributes defined by PKCS#11) and then stores it as >>> records in sql where each record has a keytype and opaque blob of data. >>> If that is what is wanted the decision would be how fingrained the pkcs >>> objects/attribute types would have to be mapped to ldap: one ldap >>> attribute for each possible attribute type ? >> >> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >> most straightforward way of doing this, but I think we can do some >> optimization for our needs. For example, like you said above, we can >> use a single attribute containing PKCS#8 encoded private key rather >> than using one attribute per private key component. >> >> I don't think we need an LDAP attribute for every possible PKCS#11 >> attribute, ATM it would be sufficient to have just these attributes >> necessary to represent private key, public key and certificate objects. >> >> So, I would say it should be something between high-level and low-level. >> >> Honza >> > -- Jan Cholasta From jcholast at redhat.com Thu Feb 20 13:31:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Feb 2014 14:31:51 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F1BA.8080008@redhat.com> References: <5305F1BA.8080008@redhat.com> Message-ID: <530603C7.9080808@redhat.com> On 20.2.2014 13:14, Martin Kosek wrote: > We had a discussion with other developers how better track who is reviewing > which patch. Recently, we introduced the Reviewed-By tag in a commit message, > but that is a post-review tag which is not useful for someone who wants to know > which patches are already reviewed and which are not reviewed. > > We were testing Patch Work [1] in last months to contain this information, but > I personally think that it is suboptimal - it introduces 2 tracking tools that > needs to be maintained (Trac and Patch Work) and the Patch Work still requires > lot of manual actions when maintaining it's state. > > I think it would be better to hold this information rather in a single tracking > tool - Trac. There are 2 options: > > 1) "Patch on review" flag, similar to "Patch posted for review" flag which > would hold 1 bit information if the patch is just lying there or has somebody > assigned. Is it possible to add new ticket states in Trac? I'm thinking extending it so that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work in progress -> assigned:patch available -> assigned:patch under review -> closed:fixed", or something like that. > > 2) "Reviewed by" text field which would hold a login of a person who is > reviewing it. It would be filled either by a person starting the review or by a > supervisor like me to forcefully assign a reviewer ;-) > > With that information in Trac, we could run using a single tracking tool for > all patches that have a ticket (which is 95% of patches). It would be then > fairly easy to see which patches are sent for review but are reviewer-less. > > It would also have a benefit for Petr's sendpatches.py script which could pull > the reviewer from a ticket and one would not have to use the "-r" option to > hard code a reviewer. > > Any objections to using "Reviewed by" field? > > [1] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 > -- Jan Cholasta From pspacek at redhat.com Thu Feb 20 13:36:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 14:36:28 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> Message-ID: <530604DC.5090801@redhat.com> On 19.2.2014 17:55, Martin Basti wrote: > On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >> On 19.2.2014 15:11, Petr Spacek wrote: >>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> Add wait_for_dns option to default.conf. >>>>>> >>>>>> This option makes record changes in DNS tree synchronous. >>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>> >>>>>> It is intended only for testing - it should prevent tests from >>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>> >>>>>> I would recommend value like 10 seconds. >>>>> >>>>> Here are a few Python nitpicks you requested. >>> >>> Thank you very much. This new version solves problems you found + adds proper >>> handling for real DNS timeouts. >>> >>>> It seems to me like a more general TimeoutError would be useful in a >>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>> missing something. >>> >>> I would like to keep them separate. DNSTimeout shouldn't be handled at all >>> because it means that your DNS server or database is dead or broken in some >>> interesting way. >>> >>> I assume that generic TimeoutError could be interpreted as 'try it >>> again'/'failover' or something like that. >>> >>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >> >> I have sent the old version with new name, gggrrr. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Tests failed: > test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone > u'zone3.test' ... ok > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in > check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in > check_output > got = api.Command[cmd](*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ > ret = self.run(*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 761, in run > return self.forward(*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 782, in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/root/freeipa/ipalib/rpc.py", line 836, in forward > return self._call_command(command, params) > File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command > return command(*params) > File "/root/freeipa/ipalib/rpc.py", line 951, in _call > return self.__request(name, args) > File "/root/freeipa/ipalib/rpc.py", line 945, in __request > raise error_class(message=error['message']) > DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN > TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} > > ====================================================================== > ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test' > zone record using dnsrecord_add > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in > check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in > check_output > got = api.Command[cmd](*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ > ret = self.run(*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 761, in run > return self.forward(*args, **options) > File "/root/freeipa/ipalib/frontend.py", line 782, in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/root/freeipa/ipalib/rpc.py", line 836, in forward > return self._call_command(command, params) > File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command > return command(*params) > File "/root/freeipa/ipalib/rpc.py", line 951, in _call > return self.__request(name, args) > File "/root/freeipa/ipalib/rpc.py", line 945, in __request > raise error_class(message=error['message']) > DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS > ns1.dnszone.test. > zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} > > configuration was: wait_for_dns=10 > > All tests passed without wait_for_dns option. > > Sometimes at first run, I get only error and testing is interrupted. I hope I covered all corner cases in this version. I renamed DNSTimeout exception to DNSDataMismatch in hope that it will be less confusing. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015-4-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 13333 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 20 13:47:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 14:47:13 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <530603C7.9080808@redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> Message-ID: <53060761.7090100@redhat.com> On 02/20/2014 02:31 PM, Jan Cholasta wrote: > On 20.2.2014 13:14, Martin Kosek wrote: >> We had a discussion with other developers how better track who is reviewing >> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >> but that is a post-review tag which is not useful for someone who wants to know >> which patches are already reviewed and which are not reviewed. >> >> We were testing Patch Work [1] in last months to contain this information, but >> I personally think that it is suboptimal - it introduces 2 tracking tools that >> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >> lot of manual actions when maintaining it's state. >> >> I think it would be better to hold this information rather in a single tracking >> tool - Trac. There are 2 options: >> >> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >> would hold 1 bit information if the patch is just lying there or has somebody >> assigned. > > Is it possible to add new ticket states in Trac? I'm thinking extending it so > that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work > in progress -> assigned:patch available -> assigned:patch under review -> > closed:fixed", or something like that. It is possible to change the workflow, yes - this is something I was also considering. It can be done with this plugin: https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin Unfortunately, the plugin that's in Fedorahosted Trac does not work properly, it gave me some Internal Errors. I filed a ticket for that: https://fedorahosted.org/fedora-infrastructure/ticket/4237 When it is fixed, we can try to think about adjusting the workflow. Maybe we can indeed add new states "submitted" and "onreview" to the workflow. But even then I think we could use the "Patch Review by" field so that we know who is reviewing, if anybody. Martin From pspacek at redhat.com Thu Feb 20 13:49:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 14:49:36 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <530603C7.9080808@redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> Message-ID: <530607F0.1000800@redhat.com> On 20.2.2014 14:31, Jan Cholasta wrote: > On 20.2.2014 13:14, Martin Kosek wrote: >> We had a discussion with other developers how better track who is reviewing >> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >> but that is a post-review tag which is not useful for someone who wants to know >> which patches are already reviewed and which are not reviewed. >> >> We were testing Patch Work [1] in last months to contain this information, but >> I personally think that it is suboptimal - it introduces 2 tracking tools that >> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >> lot of manual actions when maintaining it's state. >> >> I think it would be better to hold this information rather in a single tracking >> tool - Trac. There are 2 options: >> >> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >> would hold 1 bit information if the patch is just lying there or has somebody >> assigned. > > Is it possible to add new ticket states in Trac? I'm thinking extending it so > that instead of "new -> assigned -> closed:fixed" we have "new -> > assigned:work in progress -> assigned:patch available -> assigned:patch under > review -> closed:fixed", or something like that. This sounds like http://trac.edgewall.org/wiki/TracWorkflow see sections "Example: Add simple optional generic review state" and "Example: Adding optional Testing with Workflow". BTW the text mentions "How to combine the tracopt.ticket.commit_updater with the testing workflow": If I understand correctly, it allows you to close tickers in post-commit hook and things like that. Petr^2 Spacek >> 2) "Reviewed by" text field which would hold a login of a person who is >> reviewing it. It would be filled either by a person starting the review or by a >> supervisor like me to forcefully assign a reviewer ;-) >> >> With that information in Trac, we could run using a single tracking tool for >> all patches that have a ticket (which is 95% of patches). It would be then >> fairly easy to see which patches are sent for review but are reviewer-less. >> >> It would also have a benefit for Petr's sendpatches.py script which could pull >> the reviewer from a ticket and one would not have to use the "-r" option to >> hard code a reviewer. >> >> Any objections to using "Reviewed by" field? >> >> [1] >> http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 From pspacek at redhat.com Thu Feb 20 13:54:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 14:54:19 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53060761.7090100@redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> <53060761.7090100@redhat.com> Message-ID: <5306090B.5040406@redhat.com> On 20.2.2014 14:47, Martin Kosek wrote: > On 02/20/2014 02:31 PM, Jan Cholasta wrote: >> On 20.2.2014 13:14, Martin Kosek wrote: >>> We had a discussion with other developers how better track who is reviewing >>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>> but that is a post-review tag which is not useful for someone who wants to know >>> which patches are already reviewed and which are not reviewed. >>> >>> We were testing Patch Work [1] in last months to contain this information, but >>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>> lot of manual actions when maintaining it's state. >>> >>> I think it would be better to hold this information rather in a single tracking >>> tool - Trac. There are 2 options: >>> >>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>> would hold 1 bit information if the patch is just lying there or has somebody >>> assigned. >> >> Is it possible to add new ticket states in Trac? I'm thinking extending it so >> that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work >> in progress -> assigned:patch available -> assigned:patch under review -> >> closed:fixed", or something like that. > > It is possible to change the workflow, yes - this is something I was also > considering. > > It can be done with this plugin: > > https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin > > Unfortunately, the plugin that's in Fedorahosted Trac does not work properly, > it gave me some Internal Errors. I filed a ticket for that: > https://fedorahosted.org/fedora-infrastructure/ticket/4237 > > When it is fixed, we can try to think about adjusting the workflow. Maybe we > can indeed add new states "submitted" and "onreview" to the workflow. But even > then I think we could use the "Patch Review by" field so that we know who is > reviewing, if anybody. Thinking a bit more the e-mail notifications ... We can reassign ticket to reviewer if we have state "onreview". IMHO ticket owner always get e-mails, right? Nice side-effect is that report "{4} Assigned, Active Tickets by Owner" will give you exact list of open tickets (state != new && state != closed) and you will see who is in charge for each ticket right in the report. Ticket owner is not set in stone and everything is still in Trac history (and Git, of course :-). -- Petr^2 Spacek From mkosek at redhat.com Thu Feb 20 14:00:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 15:00:39 +0100 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <1597764190.1440922.1392902124568.JavaMail.zimbra@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> <530528FF.7020702@redhat.com> <5305BA5D.7040905@redhat.com> <1597764190.1440922.1392902124568.JavaMail.zimbra@redhat.com> Message-ID: <53060A87.6000200@redhat.com> On 02/20/2014 02:15 PM, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Martin Kosek" >> To: dpal at redhat.com, "Petr Spacek" >> Cc: freeipa-devel at redhat.com >> Sent: Thursday, February 20, 2014 9:18:37 AM >> Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl >> >> On 02/19/2014 10:58 PM, Dmitri Pal wrote: >>> On 02/19/2014 03:13 PM, Petr Spacek wrote: >>>> On 19.2.2014 21:10, Dmitri Pal wrote: >>>>> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: >>>>>> Hi, >>>>>> I reviewed this old patch: >>>>>> >>>>>> If an error occurs in the start up sequence in ipactl start/restart, >>>>>> all the services are stopped. Using the --force/-f option prevents >>>>>> stopping of services that have successfully started. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3509 >>>>> >>>>> >>>>> I have not read the code but looked at the patch and bug. >>>>> I do not understand the -force option especially with help string being: >>>>> "If ipactl action fails, do not stop the services that are already >>>>> running" >>>>> force usually means the reverse: if something did not happen force it to >>>>> happen. >>>>> I am not sure that --force option is the right name for the option with >>>>> this >>>>> help. >>>> >>>> I have proposed --no-rollback but it didn't fit to habits in IPA: >>>> https://fedorahosted.org/freeipa/ticket/3509#comment:2 >>>> >>> then it should be -fs/--force-start >>> >>> or something of this kind. >>> >> >> IMO --force is not that bad, it forces start procedure to finish regardless >> of >> the result (if some service started or not). --force-start may be redundant: >> >> # ipactl start --force-start >> # ipactl restart --force-start >> >> But I am not insisting on --force, if there is better option I am open to it. >> >> Few comments for the patch itself: >> >> 1) Please update it so that it does not use this construct: >> >> + try: >> + svc_off.stop(capture_output=False) >> + except: >> + pass >> >> Bare except clauses also catch for example KeyboardInterrupt. Then if the >> stop >> command is stuck, I would not be able to CTRL+C it. "except Exception:" is >> better. >> >> 2) The --force does not work as I would wish. When --force option is used, I >> would like ipactl to try to start all services it can, regardless to if they >> failed or not. >> >> Now it just does not rollback, but it still does not start all services it >> can: >> >> # ipactl start --force >> Existing service file detected! >> Assuming stale, cleaning and proceeding >> Starting Directory Service >> Starting krb5kdc Service >> Starting kadmin Service >> Starting named Service >> Starting ipa_memcached Service >> Starting httpd Service >> Job for httpd.service failed. See 'systemctl status httpd.service' and >> 'journalctl -xn' for details. >> Failed to start httpd Service >> Shutting down <== >> Aborting ipactl >> >> See? HTTPD did not start, ipactl stopped and it did not start pki-tomcatd or >> ipa-otpd even though they do not use HTTPD when starting. >> >> 3) I see we still write "Shutting down" even though we use --force. I would >> rather print "Shutting down suppressed" or "Forced start, no service >> rollback". >> >> Martin > > Hi, > - Corrected to the desired behaviour > - ipactl status now shows stopped services also, if the directory server is running. > Please review! > Thanks: > Adam Functionally works fine, thanks. I am personally ok with --force option, so if anyone still objects to that, please yell. I still see few process issues though: 1) Please use "FirstName LastName" format of your name in From field to make it consistent with all others. Unfortunately, I did not notice that in previous review so it was commited wrongly. Thus I fixed that in .mailmap with a one-liner (attached). 2) Patch file name should contain patch version. See http://www.freeipa.org/page/Contribute/Patch_Format#Naming 3) Use shorter patch titles This is what happens now: $ git am /tmp/freeipa-amisnyov-0003-Add-force-option-to-ipactl.patch Applying: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force option prevents stopping of services that have successfully started, just skips the services which can not be started. 4) Wrap commit description to 80 chars. See `git log` for examples. 5) Try to keep your lines in code max 80 chars, when possible. This one is too long: + parser.add_option("-f", "--force", action="store_true", dest="force", + help="If any service start fails, do not rollback the services, continue with the operation") Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-457-.mailmap-use-correct-name-format-for-adam.patch Type: text/x-patch Size: 861 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 20 14:09:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 15:09:15 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5306090B.5040406@redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> <53060761.7090100@redhat.com> <5306090B.5040406@redhat.com> Message-ID: <53060C8B.4@redhat.com> On 02/20/2014 02:54 PM, Petr Spacek wrote: > On 20.2.2014 14:47, Martin Kosek wrote: >> On 02/20/2014 02:31 PM, Jan Cholasta wrote: >>> On 20.2.2014 13:14, Martin Kosek wrote: >>>> We had a discussion with other developers how better track who is reviewing >>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>> but that is a post-review tag which is not useful for someone who wants to >>>> know >>>> which patches are already reviewed and which are not reviewed. >>>> >>>> We were testing Patch Work [1] in last months to contain this information, but >>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>> lot of manual actions when maintaining it's state. >>>> >>>> I think it would be better to hold this information rather in a single >>>> tracking >>>> tool - Trac. There are 2 options: >>>> >>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>> would hold 1 bit information if the patch is just lying there or has somebody >>>> assigned. >>> >>> Is it possible to add new ticket states in Trac? I'm thinking extending it so >>> that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work >>> in progress -> assigned:patch available -> assigned:patch under review -> >>> closed:fixed", or something like that. >> >> It is possible to change the workflow, yes - this is something I was also >> considering. >> >> It can be done with this plugin: >> >> https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin >> >> Unfortunately, the plugin that's in Fedorahosted Trac does not work properly, >> it gave me some Internal Errors. I filed a ticket for that: >> https://fedorahosted.org/fedora-infrastructure/ticket/4237 >> >> When it is fixed, we can try to think about adjusting the workflow. Maybe we >> can indeed add new states "submitted" and "onreview" to the workflow. But even >> then I think we could use the "Patch Review by" field so that we know who is >> reviewing, if anybody. > > Thinking a bit more the e-mail notifications ... > > We can reassign ticket to reviewer if we have state "onreview". IMHO ticket > owner always get e-mails, right? > > Nice side-effect is that report "{4} Assigned, Active Tickets by Owner" will > give you exact list of open tickets (state != new && state != closed) and you > will see who is in charge for each ticket right in the report. > > Ticket owner is not set in stone and everything is still in Trac history (and > Git, of course :-). Maybe. But that would mean that when you NACK a patch, you would need to move the ticket back to previous state to reset the owner. As I know how much you like the bureaucracy, are you sure you want this change? :) When the ticket is closed I personally like that owner is set to the implementer. As that way I quickly see who I need to yell when this ticket breaks something. IMO ideal state would be to have a workflow: "Accept as reviewer" - adds your name to reviewer field, moves to onreview "Assign reviewer: ________" - adds some login to reviewer field, moves to onreview We would just need to find out how to do this with some Workflow plugin when it is ready. Martin From npmccallum at redhat.com Thu Feb 20 14:19:24 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 09:19:24 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140220123338.GK16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> Message-ID: <1392905964.1957.0.camel@localhost.localdomain> On Thu, 2014-02-20 at 14:33 +0200, Alexander Bokovoy wrote: > On Thu, 20 Feb 2014, Alexander Bokovoy wrote: > >>>>>There is definitely a bug (or more) in ipa-pwd-extop in handling > >>>>>authentication cases. > >>>>Some progress on this investigation. > >>>> > >>>>Plugin precedence setting is broken in 389-ds. It is only set once, > >>>>before running init function provided by the plugin and does not take > >>>>into account all callbacks that the init function may register. As > >>>>result, all these functions get classified with default precedence (50) > >>>>and no configuration could change this, we get ipa-pwd-extop's pre-bind > >>>>callback called before schemacompat's one, thus working on the compat > >>>>entry DN instead of the new one. Since that entry has no userPassword > >>>>attribute, OTP code refuses to accept any password. > >>>> > >>>>When user is allowed to use password auth along with OTP, the fact that > >>>>there is no userPassword get ipa-pwd-extop plugin through the failure. > >>>>schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of > >>>>389-ds code checks actual password. > >>>> > >>>>So we have two issues here: OTP code needs to gracefully ignore entries > >>>>without userPassword set, and we need to be able to re-arrange > >>>>schemacompat and ipa-pwd-extop precedence for pre-bind operation. > >>>> > >>>>I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on > >>>>the latter. > >>>> > >>>>The messages from the log are not yet solved... > >>>Finally, I have a clue after tracing with debug level 1: > >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 > >>>[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter > >>>[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL > >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 > >>> > >>>So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. > >>There is an error in libotp's find() function which assumes that > >>get_basedn() always returns non-NULL value. This is not true for at > >>least cn=Directory Manager. > >> > >>Patch attached. > >More fixes required, now that Thierry produced the fix for 389-ds ticket > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop > >plugins. I'm getting crash in find() in libotp.c for internal search in > >some other conditions but at least user dn now is the correct one. > > > >Stay tuned. > OK, finally I've got it working -- my last patch had error which could > be attributed to the late night time. > > New patch is attached to fix libotp to work properly with empty base dn > (such as cn=Directory Manager). > > Also I'm attaching the patch that sets precedence of schema-compat > plugin to 49 (less than default 50). With this patch and 389-ds with > patch from ticket 47699 compat tree binds work with OTP. > > When updated 389-ds-base will be released, we'll need to add Requires: > to our RPM spec to depend on it. Without the updated 389-ds-base compat > tree binds will not work with OTP but the rest will be working fine. > > Finally, ACK to all OTP patches. ACK to both of these patches. From redhatrises at gmail.com Thu Feb 20 14:35:54 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 20 Feb 2014 07:35:54 -0700 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: <5305C2E2.7050602@redhat.com> References: <5305C2E2.7050602@redhat.com> Message-ID: Sorry about that Petr. I got a little overzealous.... :) I can give it back to you since you already have a patch in progress. Gabe On Thu, Feb 20, 2014 at 1:54 AM, Petr Viktorin wrote: > Hello, > I had this patch sitting around for some time but didn't get around to > polishing and submitting it lately. > The ticket was now claimed by "rga" (I assume that's the person who goes > by Darth Vader here?). I'm sharing the work hoping that it doesn't get done > twice. > > https://fedorahosted.org/freeipa/ticket/3460 > > > BTW, this is the first small step in my framework refactoring master plan ( > http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). > > -- > Petr? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 20 14:39:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 15:39:12 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: References: <5305C2E2.7050602@redhat.com> Message-ID: <53061390.2030303@redhat.com> No problem, we are all learning. The common rule is that when a ticket is not assigned to "someone", i.e. free, it is better to ask the asignee on IRC and check if he is OK with letting this ticket go. The person may already have some work in progress (as Petr did in this case) or at least an idea how to implement the ticket. Thanks, Martin On 02/20/2014 03:35 PM, Gabe Alford wrote: > Sorry about that Petr. I got a little overzealous.... :) I can give it back > to you since you already have a patch in progress. > > Gabe > > > On Thu, Feb 20, 2014 at 1:54 AM, Petr Viktorin wrote: > >> Hello, >> I had this patch sitting around for some time but didn't get around to >> polishing and submitting it lately. >> The ticket was now claimed by "rga" (I assume that's the person who goes >> by Darth Vader here?). I'm sharing the work hoping that it doesn't get done >> twice. >> >> https://fedorahosted.org/freeipa/ticket/3460 >> >> >> BTW, this is the first small step in my framework refactoring master plan ( >> http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). >> >> -- >> Petr? >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From amisnyov at redhat.com Thu Feb 20 14:42:19 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Thu, 20 Feb 2014 09:42:19 -0500 (EST) Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <53060A87.6000200@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> <530528FF.7020702@redhat.com> <5305BA5D.7040905@redhat.com> <1597764190.1440922.1392902124568.JavaMail.zimbra@redhat.com> <53060A87.6000200@redhat.com> Message-ID: <1713284541.1487556.1392907339569.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Martin Kosek" > To: "Adam Misnyovszki" , freeipa-devel at redhat.com > Sent: Thursday, February 20, 2014 3:00:39 PM > Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl > > On 02/20/2014 02:15 PM, Adam Misnyovszki wrote: > > > > > > ----- Original Message ----- > >> From: "Martin Kosek" > >> To: dpal at redhat.com, "Petr Spacek" > >> Cc: freeipa-devel at redhat.com > >> Sent: Thursday, February 20, 2014 9:18:37 AM > >> Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl > >> > >> On 02/19/2014 10:58 PM, Dmitri Pal wrote: > >>> On 02/19/2014 03:13 PM, Petr Spacek wrote: > >>>> On 19.2.2014 21:10, Dmitri Pal wrote: > >>>>> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: > >>>>>> Hi, > >>>>>> I reviewed this old patch: > >>>>>> > >>>>>> If an error occurs in the start up sequence in ipactl start/restart, > >>>>>> all the services are stopped. Using the --force/-f option prevents > >>>>>> stopping of services that have successfully started. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/3509 > >>>>> > >>>>> > >>>>> I have not read the code but looked at the patch and bug. > >>>>> I do not understand the -force option especially with help string > >>>>> being: > >>>>> "If ipactl action fails, do not stop the services that are already > >>>>> running" > >>>>> force usually means the reverse: if something did not happen force it > >>>>> to > >>>>> happen. > >>>>> I am not sure that --force option is the right name for the option with > >>>>> this > >>>>> help. > >>>> > >>>> I have proposed --no-rollback but it didn't fit to habits in IPA: > >>>> https://fedorahosted.org/freeipa/ticket/3509#comment:2 > >>>> > >>> then it should be -fs/--force-start > >>> > >>> or something of this kind. > >>> > >> > >> IMO --force is not that bad, it forces start procedure to finish > >> regardless > >> of > >> the result (if some service started or not). --force-start may be > >> redundant: > >> > >> # ipactl start --force-start > >> # ipactl restart --force-start > >> > >> But I am not insisting on --force, if there is better option I am open to > >> it. > >> > >> Few comments for the patch itself: > >> > >> 1) Please update it so that it does not use this construct: > >> > >> + try: > >> + svc_off.stop(capture_output=False) > >> + except: > >> + pass > >> > >> Bare except clauses also catch for example KeyboardInterrupt. Then if the > >> stop > >> command is stuck, I would not be able to CTRL+C it. "except Exception:" is > >> better. > >> > >> 2) The --force does not work as I would wish. When --force option is used, > >> I > >> would like ipactl to try to start all services it can, regardless to if > >> they > >> failed or not. > >> > >> Now it just does not rollback, but it still does not start all services it > >> can: > >> > >> # ipactl start --force > >> Existing service file detected! > >> Assuming stale, cleaning and proceeding > >> Starting Directory Service > >> Starting krb5kdc Service > >> Starting kadmin Service > >> Starting named Service > >> Starting ipa_memcached Service > >> Starting httpd Service > >> Job for httpd.service failed. See 'systemctl status httpd.service' and > >> 'journalctl -xn' for details. > >> Failed to start httpd Service > >> Shutting down <== > >> Aborting ipactl > >> > >> See? HTTPD did not start, ipactl stopped and it did not start pki-tomcatd > >> or > >> ipa-otpd even though they do not use HTTPD when starting. > >> > >> 3) I see we still write "Shutting down" even though we use --force. I > >> would > >> rather print "Shutting down suppressed" or "Forced start, no service > >> rollback". > >> > >> Martin > > > > Hi, > > - Corrected to the desired behaviour > > - ipactl status now shows stopped services also, if the directory server is > > running. > > Please review! > > Thanks: > > Adam > > Functionally works fine, thanks. I am personally ok with --force option, so > if > anyone still objects to that, please yell. > > I still see few process issues though: > > 1) Please use "FirstName LastName" format of your name in From field to make > it > consistent with all others. Unfortunately, I did not notice that in previous > review so it was commited wrongly. Thus I fixed that in .mailmap with a > one-liner (attached). > > 2) Patch file name should contain patch version. > > See http://www.freeipa.org/page/Contribute/Patch_Format#Naming > > 3) Use shorter patch titles > > This is what happens now: > > $ git am /tmp/freeipa-amisnyov-0003-Add-force-option-to-ipactl.patch > Applying: If an error occurs in the start up sequence in ipactl > start/restart, > all the services are stopped. Using the --force option prevents stopping of > services that have successfully started, just skips the services which can > not > be started. > > 4) Wrap commit description to 80 chars. > > See `git log` for examples. > > 5) Try to keep your lines in code max 80 chars, when possible. This one is > too > long: > > + parser.add_option("-f", "--force", action="store_true", dest="force", > + help="If any service start fails, do not rollback the > services, continue with the operation") > > Martin > > > Hi, corrected all above. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0003-2-Add-force-option-to-ipactl.patch Type: text/x-patch Size: 7418 bytes Desc: not available URL: From jhrozek at redhat.com Thu Feb 20 14:52:06 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 20 Feb 2014 15:52:06 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F3A0.60606@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> Message-ID: <20140220145206.GE2073@hendrix.brq.redhat.com> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: > On 02/20/2014 01:14 PM, Martin Kosek wrote: > >We had a discussion with other developers how better track who is reviewing > >which patch. Recently, we introduced the Reviewed-By tag in a commit message, > >but that is a post-review tag which is not useful for someone who wants to know > >which patches are already reviewed and which are not reviewed. > > > >We were testing Patch Work [1] in last months to contain this information, but > >I personally think that it is suboptimal - it introduces 2 tracking tools that > >needs to be maintained (Trac and Patch Work) and the Patch Work still requires > >lot of manual actions when maintaining it's state. > > > >I think it would be better to hold this information rather in a single tracking > >tool - Trac. There are 2 options: > > > >1) "Patch on review" flag, similar to "Patch posted for review" flag which > >would hold 1 bit information if the patch is just lying there or has somebody > >assigned. > > > >2) "Reviewed by" text field which would hold a login of a person who is > >reviewing it. It would be filled either by a person starting the review or by a > >supervisor like me to forcefully assign a reviewer ;-) > > > >With that information in Trac, we could run using a single tracking tool for > >all patches that have a ticket (which is 95% of patches). It would be then > >fairly easy to see which patches are sent for review but are reviewer-less. > > > >It would also have a benefit for Petr's sendpatches.py script which could pull > >the reviewer from a ticket and one would not have to use the "-r" option to > >hard code a reviewer. > > > >Any objections to using "Reviewed by" field? > > +1, this is the only thing I used Patchwork for, and keeping > Patchwork up to date just for this took a lot of unnecessary > mindless clicking. > > Just a nitpick: name it "Patch Reviewer" > - there's more to a ticket than a patch > - the review is not done yet when the field is filled out The only use-case I use patchwork for right now is a 'dashboard' to see which patches need attention. If we could get this dashboard-like view from Trac with some custom query, then I'm fine with deprecating Patchwork. However, one feature of patchwork was that each re-submission of a patch triggered a new thread so as a reviewer you could easily see there is a new instance of the patch that you need to look at. I suspect Trac wouldn't give us anything like that? From redhatrises at gmail.com Thu Feb 20 14:52:35 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 20 Feb 2014 07:52:35 -0700 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: <53061390.2030303@redhat.com> References: <5305C2E2.7050602@redhat.com> <53061390.2030303@redhat.com> Message-ID: Will do. Email okay since I am not on IIRC? Thanks, Gabe On Thu, Feb 20, 2014 at 7:39 AM, Martin Kosek wrote: > No problem, we are all learning. The common rule is that when a ticket is > not > assigned to "someone", i.e. free, it is better to ask the asignee on IRC > and > check if he is OK with letting this ticket go. The person may already have > some > work in progress (as Petr did in this case) or at least an idea how to > implement the ticket. > > Thanks, > Martin > > On 02/20/2014 03:35 PM, Gabe Alford wrote: > > Sorry about that Petr. I got a little overzealous.... :) I can give it > back > > to you since you already have a patch in progress. > > > > Gabe > > > > > > On Thu, Feb 20, 2014 at 1:54 AM, Petr Viktorin > wrote: > > > >> Hello, > >> I had this patch sitting around for some time but didn't get around to > >> polishing and submitting it lately. > >> The ticket was now claimed by "rga" (I assume that's the person who goes > >> by Darth Vader here?). I'm sharing the work hoping that it doesn't get > done > >> twice. > >> > >> https://fedorahosted.org/freeipa/ticket/3460 > >> > >> > >> BTW, this is the first small step in my framework refactoring master > plan ( > >> http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). > >> > >> -- > >> Petr? > >> > > > > > > > > _______________________________________________ > > 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 Thu Feb 20 14:56:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 15:56:04 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: References: <5305C2E2.7050602@redhat.com> <53061390.2030303@redhat.com> Message-ID: <53061784.1090603@redhat.com> It would as well. But I think for short quick question like this one, the IRC is better. If you do not have an IRC client configured on your machine you can use freenode web interface: http://webchat.freenode.net/?channels=freeipa It is quite easy to use. Martin On 02/20/2014 03:52 PM, Gabe Alford wrote: > Will do. Email okay since I am not on IIRC? > > Thanks, > > Gabe > > > On Thu, Feb 20, 2014 at 7:39 AM, Martin Kosek wrote: > >> No problem, we are all learning. The common rule is that when a ticket is >> not >> assigned to "someone", i.e. free, it is better to ask the asignee on IRC >> and >> check if he is OK with letting this ticket go. The person may already have >> some >> work in progress (as Petr did in this case) or at least an idea how to >> implement the ticket. >> >> Thanks, >> Martin >> >> On 02/20/2014 03:35 PM, Gabe Alford wrote: >>> Sorry about that Petr. I got a little overzealous.... :) I can give it >> back >>> to you since you already have a patch in progress. >>> >>> Gabe >>> >>> >>> On Thu, Feb 20, 2014 at 1:54 AM, Petr Viktorin >> wrote: >>> >>>> Hello, >>>> I had this patch sitting around for some time but didn't get around to >>>> polishing and submitting it lately. >>>> The ticket was now claimed by "rga" (I assume that's the person who goes >>>> by Darth Vader here?). I'm sharing the work hoping that it doesn't get >> done >>>> twice. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3460 >>>> >>>> >>>> BTW, this is the first small step in my framework refactoring master >> plan ( >>>> http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). >>>> >>>> -- >>>> Petr? >>>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> > From mbasti at redhat.com Thu Feb 20 14:56:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Feb 2014 15:56:10 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <530604DC.5090801@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> Message-ID: <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: > On 19.2.2014 17:55, Martin Basti wrote: > > On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: > >> On 19.2.2014 15:11, Petr Spacek wrote: > >>> On 18.2.2014 17:34, Nathaniel McCallum wrote: > >>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: > >>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: > >>>>>> Hello, > >>>>>> > >>>>>> Add wait_for_dns option to default.conf. > >>>>>> > >>>>>> This option makes record changes in DNS tree synchronous. > >>>>>> IPA calls will wait until new data are visible over DNS protocol. > >>>>>> > >>>>>> It is intended only for testing - it should prevent tests from > >>>>>> failing if there is bigger delay between change in LDAP and DNS. > >>>>>> > >>>>>> I would recommend value like 10 seconds. > >>>>> > >>>>> Here are a few Python nitpicks you requested. > >>> > >>> Thank you very much. This new version solves problems you found + adds proper > >>> handling for real DNS timeouts. > >>> > >>>> It seems to me like a more general TimeoutError would be useful in a > >>>> broader context. DNSTimeout seems overly narrow to me, unless I'm > >>>> missing something. > >>> > >>> I would like to keep them separate. DNSTimeout shouldn't be handled at all > >>> because it means that your DNS server or database is dead or broken in some > >>> interesting way. > >>> > >>> I assume that generic TimeoutError could be interpreted as 'try it > >>> again'/'failover' or something like that. > >>> > >>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. > >> > >> I have sent the old version with new name, gggrrr. > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Tests failed: > > test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone > > u'zone3.test' ... ok > > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > > runTest > > self.test(*self.arg) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in > > > > func = lambda: self.check(nice, **test) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in > > check > > self.check_output(nice, cmd, args, options, expected, extra_check) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in > > check_output > > got = api.Command[cmd](*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ > > ret = self.run(*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 761, in run > > return self.forward(*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 782, in forward > > return self.Backend.rpcclient.forward(self.name, *args, **kw) > > File "/root/freeipa/ipalib/rpc.py", line 836, in forward > > return self._call_command(command, params) > > File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command > > return command(*params) > > File "/root/freeipa/ipalib/rpc.py", line 951, in _call > > return self.__request(name, args) > > File "/root/freeipa/ipalib/rpc.py", line 945, in __request > > raise error_class(message=error['message']) > > DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN > > TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} > > > > ====================================================================== > > ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test' > > zone record using dnsrecord_add > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > > runTest > > self.test(*self.arg) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in > > > > func = lambda: self.check(nice, **test) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in > > check > > self.check_output(nice, cmd, args, options, expected, extra_check) > > File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in > > check_output > > got = api.Command[cmd](*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ > > ret = self.run(*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 761, in run > > return self.forward(*args, **options) > > File "/root/freeipa/ipalib/frontend.py", line 782, in forward > > return self.Backend.rpcclient.forward(self.name, *args, **kw) > > File "/root/freeipa/ipalib/rpc.py", line 836, in forward > > return self._call_command(command, params) > > File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command > > return command(*params) > > File "/root/freeipa/ipalib/rpc.py", line 951, in _call > > return self.__request(name, args) > > File "/root/freeipa/ipalib/rpc.py", line 945, in __request > > raise error_class(message=error['message']) > > DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS > > ns1.dnszone.test. > > zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} > > > > configuration was: wait_for_dns=10 > > > > All tests passed without wait_for_dns option. > > > > Sometimes at first run, I get only error and testing is interrupted. > > I hope I covered all corner cases in this version. > > I renamed DNSTimeout exception to DNSDataMismatch in hope that it will be less > confusing. > A change in patch was required to pass doctest. With this change ACK. Updated patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0015-5-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 13313 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 20 14:59:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 15:59:35 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <20140220145206.GE2073@hendrix.brq.redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> Message-ID: <53061857.8060606@redhat.com> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: > On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>> We had a discussion with other developers how better track who is reviewing >>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>> but that is a post-review tag which is not useful for someone who wants to know >>> which patches are already reviewed and which are not reviewed. >>> >>> We were testing Patch Work [1] in last months to contain this information, but >>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>> lot of manual actions when maintaining it's state. >>> >>> I think it would be better to hold this information rather in a single tracking >>> tool - Trac. There are 2 options: >>> >>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>> would hold 1 bit information if the patch is just lying there or has somebody >>> assigned. >>> >>> 2) "Reviewed by" text field which would hold a login of a person who is >>> reviewing it. It would be filled either by a person starting the review or by a >>> supervisor like me to forcefully assign a reviewer ;-) >>> >>> With that information in Trac, we could run using a single tracking tool for >>> all patches that have a ticket (which is 95% of patches). It would be then >>> fairly easy to see which patches are sent for review but are reviewer-less. >>> >>> It would also have a benefit for Petr's sendpatches.py script which could pull >>> the reviewer from a ticket and one would not have to use the "-r" option to >>> hard code a reviewer. >>> >>> Any objections to using "Reviewed by" field? >> >> +1, this is the only thing I used Patchwork for, and keeping >> Patchwork up to date just for this took a lot of unnecessary >> mindless clicking. >> >> Just a nitpick: name it "Patch Reviewer" >> - there's more to a ticket than a patch >> - the review is not done yet when the field is filled out > > The only use-case I use patchwork for right now is a 'dashboard' to see > which patches need attention. If we could get this dashboard-like view > from Trac with some custom query, then I'm fine with deprecating > Patchwork. +1. I would like to add the reviewer to default report 3 + prepare a new view "My Active Reviews by Milestone" to see the reviews which one should track. > > However, one feature of patchwork was that each re-submission of a > patch triggered a new thread so as a reviewer you could easily see there > is a new instance of the patch that you need to look at. I suspect Trac > wouldn't give us anything like that? When I get a review, I like to get the response to inbox - then I always know. When replies are only being sent to the list, we would have to use the advanced Trac workflow and cautiously change states between accepted - submitted - onreview. Martin From simo at redhat.com Thu Feb 20 15:09:58 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 10:09:58 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53061857.8060606@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> Message-ID: <1392908998.22754.219.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: > On 02/20/2014 03:52 PM, Jakub Hrozek wrote: > > On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: > >> On 02/20/2014 01:14 PM, Martin Kosek wrote: > >>> We had a discussion with other developers how better track who is reviewing > >>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, > >>> but that is a post-review tag which is not useful for someone who wants to know > >>> which patches are already reviewed and which are not reviewed. > >>> > >>> We were testing Patch Work [1] in last months to contain this information, but > >>> I personally think that it is suboptimal - it introduces 2 tracking tools that > >>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires > >>> lot of manual actions when maintaining it's state. > >>> > >>> I think it would be better to hold this information rather in a single tracking > >>> tool - Trac. There are 2 options: > >>> > >>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which > >>> would hold 1 bit information if the patch is just lying there or has somebody > >>> assigned. > >>> > >>> 2) "Reviewed by" text field which would hold a login of a person who is > >>> reviewing it. It would be filled either by a person starting the review or by a > >>> supervisor like me to forcefully assign a reviewer ;-) > >>> > >>> With that information in Trac, we could run using a single tracking tool for > >>> all patches that have a ticket (which is 95% of patches). It would be then > >>> fairly easy to see which patches are sent for review but are reviewer-less. > >>> > >>> It would also have a benefit for Petr's sendpatches.py script which could pull > >>> the reviewer from a ticket and one would not have to use the "-r" option to > >>> hard code a reviewer. > >>> > >>> Any objections to using "Reviewed by" field? > >> > >> +1, this is the only thing I used Patchwork for, and keeping > >> Patchwork up to date just for this took a lot of unnecessary > >> mindless clicking. > >> > >> Just a nitpick: name it "Patch Reviewer" > >> - there's more to a ticket than a patch > >> - the review is not done yet when the field is filled out > > > > The only use-case I use patchwork for right now is a 'dashboard' to see > > which patches need attention. If we could get this dashboard-like view > > from Trac with some custom query, then I'm fine with deprecating > > Patchwork. > > +1. I would like to add the reviewer to default report 3 + prepare a new view > "My Active Reviews by Milestone" to see the reviews which one should track. > > > > > However, one feature of patchwork was that each re-submission of a > > patch triggered a new thread so as a reviewer you could easily see there > > is a new instance of the patch that you need to look at. I suspect Trac > > wouldn't give us anything like that? > > When I get a review, I like to get the response to inbox - then I always know. > When replies are only being sent to the list, we would have to use the advanced > Trac workflow and cautiously change states between accepted - submitted - onreview. I think this means we'll be back to have to carefully track the mailing list because stuff will be missed. This is something patchwork "fixed". I wonder if we can build some automatism to not loose the good things here. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Feb 20 15:13:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 16:13:14 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392908998.22754.219.camel@willson.li.ssimo.org> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> Message-ID: <53061B8A.2070500@redhat.com> On 02/20/2014 04:09 PM, Simo Sorce wrote: > On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>> We had a discussion with other developers how better track who is reviewing >>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>> but that is a post-review tag which is not useful for someone who wants to know >>>>> which patches are already reviewed and which are not reviewed. >>>>> >>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>> lot of manual actions when maintaining it's state. >>>>> >>>>> I think it would be better to hold this information rather in a single tracking >>>>> tool - Trac. There are 2 options: >>>>> >>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>> assigned. >>>>> >>>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>>> reviewing it. It would be filled either by a person starting the review or by a >>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>> >>>>> With that information in Trac, we could run using a single tracking tool for >>>>> all patches that have a ticket (which is 95% of patches). It would be then >>>>> fairly easy to see which patches are sent for review but are reviewer-less. >>>>> >>>>> It would also have a benefit for Petr's sendpatches.py script which could pull >>>>> the reviewer from a ticket and one would not have to use the "-r" option to >>>>> hard code a reviewer. >>>>> >>>>> Any objections to using "Reviewed by" field? >>>> >>>> +1, this is the only thing I used Patchwork for, and keeping >>>> Patchwork up to date just for this took a lot of unnecessary >>>> mindless clicking. >>>> >>>> Just a nitpick: name it "Patch Reviewer" >>>> - there's more to a ticket than a patch >>>> - the review is not done yet when the field is filled out >>> >>> The only use-case I use patchwork for right now is a 'dashboard' to see >>> which patches need attention. If we could get this dashboard-like view >>> from Trac with some custom query, then I'm fine with deprecating >>> Patchwork. >> >> +1. I would like to add the reviewer to default report 3 + prepare a new view >> "My Active Reviews by Milestone" to see the reviews which one should track. >> >>> >>> However, one feature of patchwork was that each re-submission of a >>> patch triggered a new thread so as a reviewer you could easily see there >>> is a new instance of the patch that you need to look at. I suspect Trac >>> wouldn't give us anything like that? >> >> When I get a review, I like to get the response to inbox - then I always know. >> When replies are only being sent to the list, we would have to use the advanced >> Trac workflow and cautiously change states between accepted - submitted - onreview. > > I think this means we'll be back to have to carefully track the mailing > list because stuff will be missed. This is something patchwork "fixed". > I wonder if we can build some automatism to not loose the good things > here. > > Simo. Majority of patches going to freeipa-devel are tied to some Trac ticket. These are tracked and watched by the on_review flag and the new reviewer field. Those that are not covered by any Trac ticket need to be tracked and cared of manually by the submitter IMO. Martin From redhatrises at gmail.com Thu Feb 20 15:14:26 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 20 Feb 2014 08:14:26 -0700 Subject: [Freeipa-devel] [PATCH] ntp sync order in ipa-client-install In-Reply-To: <5305C16F.1060908@redhat.com> References: <5305C16F.1060908@redhat.com> Message-ID: ooops! Missed that. Updated Trac. Thanks, Gabe On Thu, Feb 20, 2014 at 1:48 AM, Petr Spacek wrote: > On 20.2.2014 05:47, Darth Vader wrote: > >> Hi, >> >> Changed when ntp sync's in ipa-client-install for the ticket below: >> >> https://fedorahosted.org/freeipa/ticket/3957 >> >> Thanks, >> >> Gabe >> > > Thank you very much for your patch! Somebody will review it. > > Please be so kind and update Trac with information about your patch. > See http://www.freeipa.org/page/Contribute/Code#Submit_a_patch > > Have a nice day! > > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Feb 20 15:15:23 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 10:15:23 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53061B8A.2070500@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> Message-ID: <1392909323.22754.222.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: > On 02/20/2014 04:09 PM, Simo Sorce wrote: > > On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: > >> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: > >>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: > >>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: > >>>>> We had a discussion with other developers how better track who is reviewing > >>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, > >>>>> but that is a post-review tag which is not useful for someone who wants to know > >>>>> which patches are already reviewed and which are not reviewed. > >>>>> > >>>>> We were testing Patch Work [1] in last months to contain this information, but > >>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that > >>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires > >>>>> lot of manual actions when maintaining it's state. > >>>>> > >>>>> I think it would be better to hold this information rather in a single tracking > >>>>> tool - Trac. There are 2 options: > >>>>> > >>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which > >>>>> would hold 1 bit information if the patch is just lying there or has somebody > >>>>> assigned. > >>>>> > >>>>> 2) "Reviewed by" text field which would hold a login of a person who is > >>>>> reviewing it. It would be filled either by a person starting the review or by a > >>>>> supervisor like me to forcefully assign a reviewer ;-) > >>>>> > >>>>> With that information in Trac, we could run using a single tracking tool for > >>>>> all patches that have a ticket (which is 95% of patches). It would be then > >>>>> fairly easy to see which patches are sent for review but are reviewer-less. > >>>>> > >>>>> It would also have a benefit for Petr's sendpatches.py script which could pull > >>>>> the reviewer from a ticket and one would not have to use the "-r" option to > >>>>> hard code a reviewer. > >>>>> > >>>>> Any objections to using "Reviewed by" field? > >>>> > >>>> +1, this is the only thing I used Patchwork for, and keeping > >>>> Patchwork up to date just for this took a lot of unnecessary > >>>> mindless clicking. > >>>> > >>>> Just a nitpick: name it "Patch Reviewer" > >>>> - there's more to a ticket than a patch > >>>> - the review is not done yet when the field is filled out > >>> > >>> The only use-case I use patchwork for right now is a 'dashboard' to see > >>> which patches need attention. If we could get this dashboard-like view > >>> from Trac with some custom query, then I'm fine with deprecating > >>> Patchwork. > >> > >> +1. I would like to add the reviewer to default report 3 + prepare a new view > >> "My Active Reviews by Milestone" to see the reviews which one should track. > >> > >>> > >>> However, one feature of patchwork was that each re-submission of a > >>> patch triggered a new thread so as a reviewer you could easily see there > >>> is a new instance of the patch that you need to look at. I suspect Trac > >>> wouldn't give us anything like that? > >> > >> When I get a review, I like to get the response to inbox - then I always know. > >> When replies are only being sent to the list, we would have to use the advanced > >> Trac workflow and cautiously change states between accepted - submitted - onreview. > > > > I think this means we'll be back to have to carefully track the mailing > > list because stuff will be missed. This is something patchwork "fixed". > > I wonder if we can build some automatism to not loose the good things > > here. > > > > Simo. > > Majority of patches going to freeipa-devel are tied to some Trac ticket. These > are tracked and watched by the on_review flag and the new reviewer field. If people remember to do it every time they just send an email, very process heavy. > Those that are not covered by any Trac ticket need to be tracked and cared of > manually by the submitter IMO. Not very friendly to external submitters. I guess I'll keep the patchwork instance up for now ... Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Thu Feb 20 15:24:03 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 20 Feb 2014 16:24:03 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392909323.22754.222.camel@willson.li.ssimo.org> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> Message-ID: <20140220152403.GI2073@hendrix.brq.redhat.com> On Thu, Feb 20, 2014 at 10:15:23AM -0500, Simo Sorce wrote: > On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: > > On 02/20/2014 04:09 PM, Simo Sorce wrote: > > > On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: > > >> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: > > >>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: > > >>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: > > >>>>> We had a discussion with other developers how better track who is reviewing > > >>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, > > >>>>> but that is a post-review tag which is not useful for someone who wants to know > > >>>>> which patches are already reviewed and which are not reviewed. > > >>>>> > > >>>>> We were testing Patch Work [1] in last months to contain this information, but > > >>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that > > >>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires > > >>>>> lot of manual actions when maintaining it's state. > > >>>>> > > >>>>> I think it would be better to hold this information rather in a single tracking > > >>>>> tool - Trac. There are 2 options: > > >>>>> > > >>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which > > >>>>> would hold 1 bit information if the patch is just lying there or has somebody > > >>>>> assigned. > > >>>>> > > >>>>> 2) "Reviewed by" text field which would hold a login of a person who is > > >>>>> reviewing it. It would be filled either by a person starting the review or by a > > >>>>> supervisor like me to forcefully assign a reviewer ;-) > > >>>>> > > >>>>> With that information in Trac, we could run using a single tracking tool for > > >>>>> all patches that have a ticket (which is 95% of patches). It would be then > > >>>>> fairly easy to see which patches are sent for review but are reviewer-less. > > >>>>> > > >>>>> It would also have a benefit for Petr's sendpatches.py script which could pull > > >>>>> the reviewer from a ticket and one would not have to use the "-r" option to > > >>>>> hard code a reviewer. > > >>>>> > > >>>>> Any objections to using "Reviewed by" field? > > >>>> > > >>>> +1, this is the only thing I used Patchwork for, and keeping > > >>>> Patchwork up to date just for this took a lot of unnecessary > > >>>> mindless clicking. > > >>>> > > >>>> Just a nitpick: name it "Patch Reviewer" > > >>>> - there's more to a ticket than a patch > > >>>> - the review is not done yet when the field is filled out > > >>> > > >>> The only use-case I use patchwork for right now is a 'dashboard' to see > > >>> which patches need attention. If we could get this dashboard-like view > > >>> from Trac with some custom query, then I'm fine with deprecating > > >>> Patchwork. > > >> > > >> +1. I would like to add the reviewer to default report 3 + prepare a new view > > >> "My Active Reviews by Milestone" to see the reviews which one should track. > > >> > > >>> > > >>> However, one feature of patchwork was that each re-submission of a > > >>> patch triggered a new thread so as a reviewer you could easily see there > > >>> is a new instance of the patch that you need to look at. I suspect Trac > > >>> wouldn't give us anything like that? > > >> > > >> When I get a review, I like to get the response to inbox - then I always know. > > >> When replies are only being sent to the list, we would have to use the advanced > > >> Trac workflow and cautiously change states between accepted - submitted - onreview. > > > > > > I think this means we'll be back to have to carefully track the mailing > > > list because stuff will be missed. This is something patchwork "fixed". > > > I wonder if we can build some automatism to not loose the good things > > > here. > > > > > > Simo. > > > > Majority of patches going to freeipa-devel are tied to some Trac ticket. These > > are tracked and watched by the on_review flag and the new reviewer field. > > If people remember to do it every time they just send an email, very > process heavy. > > > Those that are not covered by any Trac ticket need to be tracked and cared of > > manually by the submitter IMO. > > Not very friendly to external submitters. > > I guess I'll keep the patchwork instance up for now ... > > Simo. > Oh, another thing we lose from Patchwork is the "Changes Requested" state of the review. In other words, with Trac you only know who is the reviewer, but you don't know who is supposed to act now. btw all this bending of Trac makes me wonder if we shouldn't make the leap to some completely different review tool rather than trying to force Trac into something it's not? From pviktori at redhat.com Thu Feb 20 15:34:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 16:34:26 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392909323.22754.222.camel@willson.li.ssimo.org> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> Message-ID: <53062082.9020805@redhat.com> On 02/20/2014 04:15 PM, Simo Sorce wrote: > On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: >> On 02/20/2014 04:09 PM, Simo Sorce wrote: >>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>>>> We had a discussion with other developers how better track who is reviewing >>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>>>> but that is a post-review tag which is not useful for someone who wants to know >>>>>>> which patches are already reviewed and which are not reviewed. >>>>>>> >>>>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>>>> lot of manual actions when maintaining it's state. >>>>>>> >>>>>>> I think it would be better to hold this information rather in a single tracking >>>>>>> tool - Trac. There are 2 options: >>>>>>> >>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>>>> assigned. >>>>>>> >>>>>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>>>>> reviewing it. It would be filled either by a person starting the review or by a >>>>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>>>> >>>>>>> With that information in Trac, we could run using a single tracking tool for >>>>>>> all patches that have a ticket (which is 95% of patches). It would be then >>>>>>> fairly easy to see which patches are sent for review but are reviewer-less. >>>>>>> >>>>>>> It would also have a benefit for Petr's sendpatches.py script which could pull >>>>>>> the reviewer from a ticket and one would not have to use the "-r" option to >>>>>>> hard code a reviewer. >>>>>>> >>>>>>> Any objections to using "Reviewed by" field? >>>>>> >>>>>> +1, this is the only thing I used Patchwork for, and keeping >>>>>> Patchwork up to date just for this took a lot of unnecessary >>>>>> mindless clicking. >>>>>> >>>>>> Just a nitpick: name it "Patch Reviewer" >>>>>> - there's more to a ticket than a patch >>>>>> - the review is not done yet when the field is filled out >>>>> >>>>> The only use-case I use patchwork for right now is a 'dashboard' to see >>>>> which patches need attention. If we could get this dashboard-like view >>>>> from Trac with some custom query, then I'm fine with deprecating >>>>> Patchwork. >>>> >>>> +1. I would like to add the reviewer to default report 3 + prepare a new view >>>> "My Active Reviews by Milestone" to see the reviews which one should track. >>>> >>>>> >>>>> However, one feature of patchwork was that each re-submission of a >>>>> patch triggered a new thread so as a reviewer you could easily see there >>>>> is a new instance of the patch that you need to look at. I suspect Trac >>>>> wouldn't give us anything like that? >>>> >>>> When I get a review, I like to get the response to inbox - then I always know. >>>> When replies are only being sent to the list, we would have to use the advanced >>>> Trac workflow and cautiously change states between accepted - submitted - onreview. >>> >>> I think this means we'll be back to have to carefully track the mailing >>> list because stuff will be missed. This is something patchwork "fixed". No. The only thing that happened automatically in Patchwork was that entries got created. Patchwork doesn't even have threads - each version of a patch needed to be individually marked as superseded. Very much mindless clicking is needed to keep Patchwork up to date. >>> I wonder if we can build some automatism to not loose the good things >>> here. >>> >>> Simo. >> >> Majority of patches going to freeipa-devel are tied to some Trac ticket. These >> are tracked and watched by the on_review flag and the new reviewer field. > > If people remember to do it every time they just send an email, very > process heavy. How is this different from Patchwork? >> Those that are not covered by any Trac ticket need to be tracked and cared of >> manually by the submitter IMO. > > Not very friendly to external submitters. External submitters can easily open tickets. > I guess I'll keep the patchwork instance up for now ... I was basically the only one who used the IPA Patchwork any more. I have stopped using it and I'm waiting for the Patch Reviewer field (in any form!). Without someone to *manually* mark all the patches as On review, then Changes Requested, then Pushed... Patchwork is quite useless. You can keep it running but no one from the FreeIPA team will use it. Sorry. -- Petr? From pspacek at redhat.com Thu Feb 20 15:41:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 16:41:11 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062082.9020805@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> Message-ID: <53062217.6080005@redhat.com> On 20.2.2014 16:34, Petr Viktorin wrote: > On 02/20/2014 04:15 PM, Simo Sorce wrote: >> On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: >>> On 02/20/2014 04:09 PM, Simo Sorce wrote: >>>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >>>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>>>>> We had a discussion with other developers how better track who is >>>>>>>> reviewing >>>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit >>>>>>>> message, >>>>>>>> but that is a post-review tag which is not useful for someone who >>>>>>>> wants to know >>>>>>>> which patches are already reviewed and which are not reviewed. >>>>>>>> >>>>>>>> We were testing Patch Work [1] in last months to contain this >>>>>>>> information, but >>>>>>>> I personally think that it is suboptimal - it introduces 2 tracking >>>>>>>> tools that >>>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still >>>>>>>> requires >>>>>>>> lot of manual actions when maintaining it's state. >>>>>>>> >>>>>>>> I think it would be better to hold this information rather in a single >>>>>>>> tracking >>>>>>>> tool - Trac. There are 2 options: >>>>>>>> >>>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag >>>>>>>> which >>>>>>>> would hold 1 bit information if the patch is just lying there or has >>>>>>>> somebody >>>>>>>> assigned. >>>>>>>> >>>>>>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>>>>>> reviewing it. It would be filled either by a person starting the >>>>>>>> review or by a >>>>>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>>>>> >>>>>>>> With that information in Trac, we could run using a single tracking >>>>>>>> tool for >>>>>>>> all patches that have a ticket (which is 95% of patches). It would be >>>>>>>> then >>>>>>>> fairly easy to see which patches are sent for review but are >>>>>>>> reviewer-less. >>>>>>>> >>>>>>>> It would also have a benefit for Petr's sendpatches.py script which >>>>>>>> could pull >>>>>>>> the reviewer from a ticket and one would not have to use the "-r" >>>>>>>> option to >>>>>>>> hard code a reviewer. >>>>>>>> >>>>>>>> Any objections to using "Reviewed by" field? >>>>>>> >>>>>>> +1, this is the only thing I used Patchwork for, and keeping >>>>>>> Patchwork up to date just for this took a lot of unnecessary >>>>>>> mindless clicking. >>>>>>> >>>>>>> Just a nitpick: name it "Patch Reviewer" >>>>>>> - there's more to a ticket than a patch >>>>>>> - the review is not done yet when the field is filled out >>>>>> >>>>>> The only use-case I use patchwork for right now is a 'dashboard' to see >>>>>> which patches need attention. If we could get this dashboard-like view >>>>>> from Trac with some custom query, then I'm fine with deprecating >>>>>> Patchwork. >>>>> >>>>> +1. I would like to add the reviewer to default report 3 + prepare a new >>>>> view >>>>> "My Active Reviews by Milestone" to see the reviews which one should track. >>>>> >>>>>> >>>>>> However, one feature of patchwork was that each re-submission of a >>>>>> patch triggered a new thread so as a reviewer you could easily see there >>>>>> is a new instance of the patch that you need to look at. I suspect Trac >>>>>> wouldn't give us anything like that? >>>>> >>>>> When I get a review, I like to get the response to inbox - then I always >>>>> know. >>>>> When replies are only being sent to the list, we would have to use the >>>>> advanced >>>>> Trac workflow and cautiously change states between accepted - submitted - >>>>> onreview. >>>> >>>> I think this means we'll be back to have to carefully track the mailing >>>> list because stuff will be missed. This is something patchwork "fixed". > > No. The only thing that happened automatically in Patchwork was that entries > got created. Patchwork doesn't even have threads - each version of a patch > needed to be individually marked as superseded. Very much mindless clicking is > needed to keep Patchwork up to date. > >>>> I wonder if we can build some automatism to not loose the good things >>>> here. >>>> >>>> Simo. >>> >>> Majority of patches going to freeipa-devel are tied to some Trac ticket. These >>> are tracked and watched by the on_review flag and the new reviewer field. >> >> If people remember to do it every time they just send an email, very >> process heavy. > > How is this different from Patchwork? > >>> Those that are not covered by any Trac ticket need to be tracked and cared of >>> manually by the submitter IMO. >> >> Not very friendly to external submitters. > > External submitters can easily open tickets. > >> I guess I'll keep the patchwork instance up for now ... > > I was basically the only one who used the IPA Patchwork any more. I have > stopped using it and I'm waiting for the Patch Reviewer field (in any form!). > Without someone to *manually* mark all the patches as On review, then Changes > Requested, then Pushed... Patchwork is quite useless. > > You can keep it running but no one from the FreeIPA team will use it. Sorry. Note that Trac has XMLRPC so it is very very easy to have script for review assignment etc. $ start_review.py somerandomstring.patch can very easily grep ticket URL and add your name to 'Reviewer' field in the ticket. (I have similar scripts for paperwork related to push/ticket closing so it is not pure theory.) -- Petr^2 Spacek From rcritten at redhat.com Thu Feb 20 15:41:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Feb 2014 10:41:21 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392909323.22754.222.camel@willson.li.ssimo.org> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> Message-ID: <53062221.5030007@redhat.com> Simo Sorce wrote: > On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: >> On 02/20/2014 04:09 PM, Simo Sorce wrote: >>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>>>> We had a discussion with other developers how better track who is reviewing >>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>>>> but that is a post-review tag which is not useful for someone who wants to know >>>>>>> which patches are already reviewed and which are not reviewed. >>>>>>> >>>>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>>>> lot of manual actions when maintaining it's state. >>>>>>> >>>>>>> I think it would be better to hold this information rather in a single tracking >>>>>>> tool - Trac. There are 2 options: >>>>>>> >>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>>>> assigned. >>>>>>> >>>>>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>>>>> reviewing it. It would be filled either by a person starting the review or by a >>>>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>>>> >>>>>>> With that information in Trac, we could run using a single tracking tool for >>>>>>> all patches that have a ticket (which is 95% of patches). It would be then >>>>>>> fairly easy to see which patches are sent for review but are reviewer-less. >>>>>>> >>>>>>> It would also have a benefit for Petr's sendpatches.py script which could pull >>>>>>> the reviewer from a ticket and one would not have to use the "-r" option to >>>>>>> hard code a reviewer. >>>>>>> >>>>>>> Any objections to using "Reviewed by" field? >>>>>> >>>>>> +1, this is the only thing I used Patchwork for, and keeping >>>>>> Patchwork up to date just for this took a lot of unnecessary >>>>>> mindless clicking. >>>>>> >>>>>> Just a nitpick: name it "Patch Reviewer" >>>>>> - there's more to a ticket than a patch >>>>>> - the review is not done yet when the field is filled out >>>>> >>>>> The only use-case I use patchwork for right now is a 'dashboard' to see >>>>> which patches need attention. If we could get this dashboard-like view >>>>> from Trac with some custom query, then I'm fine with deprecating >>>>> Patchwork. >>>> >>>> +1. I would like to add the reviewer to default report 3 + prepare a new view >>>> "My Active Reviews by Milestone" to see the reviews which one should track. >>>> >>>>> >>>>> However, one feature of patchwork was that each re-submission of a >>>>> patch triggered a new thread so as a reviewer you could easily see there >>>>> is a new instance of the patch that you need to look at. I suspect Trac >>>>> wouldn't give us anything like that? >>>> >>>> When I get a review, I like to get the response to inbox - then I always know. >>>> When replies are only being sent to the list, we would have to use the advanced >>>> Trac workflow and cautiously change states between accepted - submitted - onreview. >>> >>> I think this means we'll be back to have to carefully track the mailing >>> list because stuff will be missed. This is something patchwork "fixed". >>> I wonder if we can build some automatism to not loose the good things >>> here. >>> >>> Simo. >> >> Majority of patches going to freeipa-devel are tied to some Trac ticket. These >> are tracked and watched by the on_review flag and the new reviewer field. > > If people remember to do it every time they just send an email, very > process heavy. > >> Those that are not covered by any Trac ticket need to be tracked and cared of >> manually by the submitter IMO. > > Not very friendly to external submitters. > > I guess I'll keep the patchwork instance up for now ... I agree. I can't say I'm particularly thrilled about this new attribute either but I'm not exactly reviewing and submitting a ton of patches these days so I'll let let this play out. To me this seems weak compared to a Gerrit-style review (not that I'm advocating Gerrit, which I hate for various other reasons). rob From mkosek at redhat.com Thu Feb 20 15:42:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 16:42:15 +0100 Subject: [Freeipa-devel] [PATCH]Add -f option to ipactl In-Reply-To: <1713284541.1487556.1392907339569.JavaMail.zimbra@redhat.com> References: <1933990135.1343714.1392829095379.JavaMail.zimbra@redhat.com> <53050FB5.7030600@redhat.com> <53051067.50903@redhat.com> <530528FF.7020702@redhat.com> <5305BA5D.7040905@redhat.com> <1597764190.1440922.1392902124568.JavaMail.zimbra@redhat.com> <53060A87.6000200@redhat.com> <1713284541.1487556.1392907339569.JavaMail.zimbra@redhat.com> Message-ID: <53062257.4090407@redhat.com> On 02/20/2014 03:42 PM, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Martin Kosek" >> To: "Adam Misnyovszki" , freeipa-devel at redhat.com >> Sent: Thursday, February 20, 2014 3:00:39 PM >> Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl >> >> On 02/20/2014 02:15 PM, Adam Misnyovszki wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Martin Kosek" >>>> To: dpal at redhat.com, "Petr Spacek" >>>> Cc: freeipa-devel at redhat.com >>>> Sent: Thursday, February 20, 2014 9:18:37 AM >>>> Subject: Re: [Freeipa-devel] [PATCH]Add -f option to ipactl >>>> >>>> On 02/19/2014 10:58 PM, Dmitri Pal wrote: >>>>> On 02/19/2014 03:13 PM, Petr Spacek wrote: >>>>>> On 19.2.2014 21:10, Dmitri Pal wrote: >>>>>>> On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: >>>>>>>> Hi, >>>>>>>> I reviewed this old patch: >>>>>>>> >>>>>>>> If an error occurs in the start up sequence in ipactl start/restart, >>>>>>>> all the services are stopped. Using the --force/-f option prevents >>>>>>>> stopping of services that have successfully started. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3509 >>>>>>> >>>>>>> >>>>>>> I have not read the code but looked at the patch and bug. >>>>>>> I do not understand the -force option especially with help string >>>>>>> being: >>>>>>> "If ipactl action fails, do not stop the services that are already >>>>>>> running" >>>>>>> force usually means the reverse: if something did not happen force it >>>>>>> to >>>>>>> happen. >>>>>>> I am not sure that --force option is the right name for the option with >>>>>>> this >>>>>>> help. >>>>>> >>>>>> I have proposed --no-rollback but it didn't fit to habits in IPA: >>>>>> https://fedorahosted.org/freeipa/ticket/3509#comment:2 >>>>>> >>>>> then it should be -fs/--force-start >>>>> >>>>> or something of this kind. >>>>> >>>> >>>> IMO --force is not that bad, it forces start procedure to finish >>>> regardless >>>> of >>>> the result (if some service started or not). --force-start may be >>>> redundant: >>>> >>>> # ipactl start --force-start >>>> # ipactl restart --force-start >>>> >>>> But I am not insisting on --force, if there is better option I am open to >>>> it. >>>> >>>> Few comments for the patch itself: >>>> >>>> 1) Please update it so that it does not use this construct: >>>> >>>> + try: >>>> + svc_off.stop(capture_output=False) >>>> + except: >>>> + pass >>>> >>>> Bare except clauses also catch for example KeyboardInterrupt. Then if the >>>> stop >>>> command is stuck, I would not be able to CTRL+C it. "except Exception:" is >>>> better. >>>> >>>> 2) The --force does not work as I would wish. When --force option is used, >>>> I >>>> would like ipactl to try to start all services it can, regardless to if >>>> they >>>> failed or not. >>>> >>>> Now it just does not rollback, but it still does not start all services it >>>> can: >>>> >>>> # ipactl start --force >>>> Existing service file detected! >>>> Assuming stale, cleaning and proceeding >>>> Starting Directory Service >>>> Starting krb5kdc Service >>>> Starting kadmin Service >>>> Starting named Service >>>> Starting ipa_memcached Service >>>> Starting httpd Service >>>> Job for httpd.service failed. See 'systemctl status httpd.service' and >>>> 'journalctl -xn' for details. >>>> Failed to start httpd Service >>>> Shutting down <== >>>> Aborting ipactl >>>> >>>> See? HTTPD did not start, ipactl stopped and it did not start pki-tomcatd >>>> or >>>> ipa-otpd even though they do not use HTTPD when starting. >>>> >>>> 3) I see we still write "Shutting down" even though we use --force. I >>>> would >>>> rather print "Shutting down suppressed" or "Forced start, no service >>>> rollback". >>>> >>>> Martin >>> >>> Hi, >>> - Corrected to the desired behaviour >>> - ipactl status now shows stopped services also, if the directory server is >>> running. >>> Please review! >>> Thanks: >>> Adam >> >> Functionally works fine, thanks. I am personally ok with --force option, so >> if >> anyone still objects to that, please yell. >> >> I still see few process issues though: >> >> 1) Please use "FirstName LastName" format of your name in From field to make >> it >> consistent with all others. Unfortunately, I did not notice that in previous >> review so it was commited wrongly. Thus I fixed that in .mailmap with a >> one-liner (attached). >> >> 2) Patch file name should contain patch version. >> >> See http://www.freeipa.org/page/Contribute/Patch_Format#Naming >> >> 3) Use shorter patch titles >> >> This is what happens now: >> >> $ git am /tmp/freeipa-amisnyov-0003-Add-force-option-to-ipactl.patch >> Applying: If an error occurs in the start up sequence in ipactl >> start/restart, >> all the services are stopped. Using the --force option prevents stopping of >> services that have successfully started, just skips the services which can >> not >> be started. >> >> 4) Wrap commit description to 80 chars. >> >> See `git log` for examples. >> >> 5) Try to keep your lines in code max 80 chars, when possible. This one is >> too >> long: >> >> + parser.add_option("-f", "--force", action="store_true", dest="force", >> + help="If any service start fails, do not rollback the >> services, continue with the operation") >> >> Martin >> >> >> > > Hi, > corrected all above. > Thanks > Adam > Thanks. ACK. Pushed to master: 189bdcb95d4d2346ad5859c2717e7b94dcca018b Martin From tbabej at redhat.com Thu Feb 20 15:43:45 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Feb 2014 16:43:45 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062082.9020805@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> Message-ID: <530622B1.5090405@redhat.com> On 02/20/2014 04:34 PM, Petr Viktorin wrote: > On 02/20/2014 04:15 PM, Simo Sorce wrote: >> On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: >>> On 02/20/2014 04:09 PM, Simo Sorce wrote: >>>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >>>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>>>>> We had a discussion with other developers how better track who >>>>>>>> is reviewing >>>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a >>>>>>>> commit message, >>>>>>>> but that is a post-review tag which is not useful for someone >>>>>>>> who wants to know >>>>>>>> which patches are already reviewed and which are not reviewed. >>>>>>>> >>>>>>>> We were testing Patch Work [1] in last months to contain this >>>>>>>> information, but >>>>>>>> I personally think that it is suboptimal - it introduces 2 >>>>>>>> tracking tools that >>>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work >>>>>>>> still requires >>>>>>>> lot of manual actions when maintaining it's state. >>>>>>>> >>>>>>>> I think it would be better to hold this information rather in a >>>>>>>> single tracking >>>>>>>> tool - Trac. There are 2 options: >>>>>>>> >>>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" >>>>>>>> flag which >>>>>>>> would hold 1 bit information if the patch is just lying there >>>>>>>> or has somebody >>>>>>>> assigned. >>>>>>>> >>>>>>>> 2) "Reviewed by" text field which would hold a login of a >>>>>>>> person who is >>>>>>>> reviewing it. It would be filled either by a person starting >>>>>>>> the review or by a >>>>>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>>>>> >>>>>>>> With that information in Trac, we could run using a single >>>>>>>> tracking tool for >>>>>>>> all patches that have a ticket (which is 95% of patches). It >>>>>>>> would be then >>>>>>>> fairly easy to see which patches are sent for review but are >>>>>>>> reviewer-less. >>>>>>>> >>>>>>>> It would also have a benefit for Petr's sendpatches.py script >>>>>>>> which could pull >>>>>>>> the reviewer from a ticket and one would not have to use the >>>>>>>> "-r" option to >>>>>>>> hard code a reviewer. >>>>>>>> >>>>>>>> Any objections to using "Reviewed by" field? >>>>>>> >>>>>>> +1, this is the only thing I used Patchwork for, and keeping >>>>>>> Patchwork up to date just for this took a lot of unnecessary >>>>>>> mindless clicking. >>>>>>> >>>>>>> Just a nitpick: name it "Patch Reviewer" >>>>>>> - there's more to a ticket than a patch >>>>>>> - the review is not done yet when the field is filled out >>>>>> >>>>>> The only use-case I use patchwork for right now is a 'dashboard' >>>>>> to see >>>>>> which patches need attention. If we could get this dashboard-like >>>>>> view >>>>>> from Trac with some custom query, then I'm fine with deprecating >>>>>> Patchwork. >>>>> >>>>> +1. I would like to add the reviewer to default report 3 + prepare >>>>> a new view >>>>> "My Active Reviews by Milestone" to see the reviews which one >>>>> should track. >>>>> >>>>>> >>>>>> However, one feature of patchwork was that each re-submission of a >>>>>> patch triggered a new thread so as a reviewer you could easily >>>>>> see there >>>>>> is a new instance of the patch that you need to look at. I >>>>>> suspect Trac >>>>>> wouldn't give us anything like that? >>>>> >>>>> When I get a review, I like to get the response to inbox - then I >>>>> always know. >>>>> When replies are only being sent to the list, we would have to use >>>>> the advanced >>>>> Trac workflow and cautiously change states between accepted - >>>>> submitted - onreview. >>>> >>>> I think this means we'll be back to have to carefully track the >>>> mailing >>>> list because stuff will be missed. This is something patchwork >>>> "fixed". > > No. The only thing that happened automatically in Patchwork was that > entries got created. Patchwork doesn't even have threads - each > version of a patch needed to be individually marked as superseded. > Very much mindless clicking is needed to keep Patchwork up to date. > Manually marking all the lost threads as superseeded was the exact reason I stopped using Patchwork. >>>> I wonder if we can build some automatism to not loose the good things >>>> here. >>>> >>>> Simo. >>> >>> Majority of patches going to freeipa-devel are tied to some Trac >>> ticket. These >>> are tracked and watched by the on_review flag and the new reviewer >>> field. >> >> If people remember to do it every time they just send an email, very >> process heavy. > > How is this different from Patchwork? > >>> Those that are not covered by any Trac ticket need to be tracked and >>> cared of >>> manually by the submitter IMO. >> >> Not very friendly to external submitters. > > External submitters can easily open tickets. > >> I guess I'll keep the patchwork instance up for now ... > > I was basically the only one who used the IPA Patchwork any more. I > have stopped using it and I'm waiting for the Patch Reviewer field (in > any form!). > Without someone to *manually* mark all the patches as On review, then > Changes Requested, then Pushed... Patchwork is quite useless. > > You can keep it running but no one from the FreeIPA team will use it. > Sorry. > Patchwork would be a great tool, if it could automatically derive the information it needs (work with threads properly, set patch status depending on the email headers / keywords in the text). Having to manually update it however, it becomes too heavyweight, because of the imperfections Petr mentioned. The proposal we have for the reviewer field does not solve the problem, but the actual maintenance load becomes much lighter, and we do get the reasonable portion of benefit. My 2 cents, -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pspacek at redhat.com Thu Feb 20 15:46:29 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 16:46:29 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <5306012D.7020402@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <5305F792.4010200@redhat.com> <5306012D.7020402@redhat.com> Message-ID: <53062355.3020507@redhat.com> On 20.2.2014 14:20, Jan Cholasta wrote: > On 20.2.2014 13:39, Ludwig Krispenz wrote: >> Hi, >> >> I am now getting more familiar with PKCS#11 and did check which objects >> are handled by softhsm and I think the best way would be a direct >> mapping of a subset of the pkcs#11 objectclasses and attributes to LDAP. >> In my understanding we would only need the objectclasses of storage >> objects: certificate, {private|public|secret}key, evtl data. The >> attributes would then be the attributes required by these >> objectclassses. > > I agree, that's the way I imagined it. > > One thing to note is that in PKCS#11 an object is allowed to have only single > object class, so when you want to get e.g. certificate and private key of a > single entity, you must lookup a certificate object and a private key object > which have the same CKA_ID. I think it would be nice if we could store them > both in a single entry in LDAP, given that an entry is allowed to have > multiple object classes. > >> And here I am having a bit difficulties, eg in the spec: >> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf in >> the example (11.7) for adding a publicKey the attributes CKA_MODULUS and >> CKA_PUBLIC_EXPONENT are used, but these are not listed in the tables in >> 10.7 as "Common Key Attributes", so how do I know which are the required >> and allowed attributes for these objectclasses ? > > The attributes that hold the actual key data depend on the key algorithm, > CKA_MODULUS and CKA_PUBLIC_EXPONENT are relevant to RSA, but they might not be > relevant to other algorithms. > > But I don't think we need such a level of detail, I like your previous idea of > storing private key material as PKCS#8 - it has all the key algorithm-specific > bits inside, so we would be able to have just one object class for private > keys (with common private keys attributes and one attribute to store the > PKCS#8 blob in), instead of one object class per algorithm (with common > private key attributes and algorithm-specific attributes). I'm attaching a file with key metadata used by BIND 9. Most important field is "label", it assigns key with the DNS zone. (Name of DNS zone is derived from file name.) It seems that we don't need any special identifier in the key itself, standard label is just fine. Petr^2 Spacek >> I will start to write a draft for the schema definitions we can discuss, >> but any input is welcome. >> >> Regards, >> Ludwig >> >> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> yesterday jan asked me about the status of the schema and if it would be >>>> ready for certificate storage an dthat puzzled me a bit and showed that >>>> I still do not really understand what you want to store in LDAP. >>>> Two me there are two very different approaches. >>>> >>>> 1] LDAP as store for high level objects like certs and keys >>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>> or as bind keypairs and define a key attribute and that's it. we could >>>> export keys with softhsm, (eventually convert them) and add to ldap, in >>>> the long term solution the PKCS#11 replacemnt would need to manage these >>>> high level objects >>> >>> I think RFC 4523 is not the right schema in this case, as it is suited >>> for PKIs rather than generic cryptographic data storage. For example, >>> RFC 4523 distinguishes between CA and end entity certificates, but in >>> PKCS#11 there are just certificates without any semantics attached to >>> them. >>> >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of data. >>>> If that is what is wanted the decision would be how fingrained the pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>> most straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can >>> use a single attribute containing PKCS#8 encoded private key rather >>> than using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and low-level. >>> >>> Honza -------------- next part -------------- Private-key-format: v1.3 Algorithm: 5 (RSASHA1) Modulus: xjgfDGfpgvdPuwwQDMB8dvXH/qmqPWiR6dIn+VTRuJAkdjX5OUUmVP0BE9iaXK3pxwGG3E8g152oakUovcpC3trvZZbEc1JHfeF0lPdH5HrKVF8LgwLLRN+eF4m6n1zs0P/rG19DeVRhZU0xr5BNrOaEmz6N5VXiJ7kPgCMaww4VB5QZ2xVpVQRIsY7Isp0q39gbrjvsa/JrfEQm9SP4ID/MFxbczflf9itfgSAZiOPwK5gxvnzbfZvezR3zXh7/NxP6z7+RLIgfcgkidjxgZzkSbbHX1/oSdhANDODgNsd40F6VGz3/Bbsa9mBmmUSLCJO7jw2vJFSNBBah0mQ4UQ== PublicExponent: AQAB Engine: cGtjczExAA== Label: bGFiZWxfT3BlbkROU1NFQwA= Created: 20140201122624 Publish: 20140201122624 Activate: 20140201122624 From simo at redhat.com Thu Feb 20 15:55:10 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 10:55:10 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062082.9020805@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> Message-ID: <1392911710.22754.228.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 16:34 +0100, Petr Viktorin wrote: > On 02/20/2014 04:15 PM, Simo Sorce wrote: > > On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: > >> On 02/20/2014 04:09 PM, Simo Sorce wrote: > >>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: > >>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: > >>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: > >>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: > >>>>>>> We had a discussion with other developers how better track who is reviewing > >>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, > >>>>>>> but that is a post-review tag which is not useful for someone who wants to know > >>>>>>> which patches are already reviewed and which are not reviewed. > >>>>>>> > >>>>>>> We were testing Patch Work [1] in last months to contain this information, but > >>>>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that > >>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires > >>>>>>> lot of manual actions when maintaining it's state. > >>>>>>> > >>>>>>> I think it would be better to hold this information rather in a single tracking > >>>>>>> tool - Trac. There are 2 options: > >>>>>>> > >>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which > >>>>>>> would hold 1 bit information if the patch is just lying there or has somebody > >>>>>>> assigned. > >>>>>>> > >>>>>>> 2) "Reviewed by" text field which would hold a login of a person who is > >>>>>>> reviewing it. It would be filled either by a person starting the review or by a > >>>>>>> supervisor like me to forcefully assign a reviewer ;-) > >>>>>>> > >>>>>>> With that information in Trac, we could run using a single tracking tool for > >>>>>>> all patches that have a ticket (which is 95% of patches). It would be then > >>>>>>> fairly easy to see which patches are sent for review but are reviewer-less. > >>>>>>> > >>>>>>> It would also have a benefit for Petr's sendpatches.py script which could pull > >>>>>>> the reviewer from a ticket and one would not have to use the "-r" option to > >>>>>>> hard code a reviewer. > >>>>>>> > >>>>>>> Any objections to using "Reviewed by" field? > >>>>>> > >>>>>> +1, this is the only thing I used Patchwork for, and keeping > >>>>>> Patchwork up to date just for this took a lot of unnecessary > >>>>>> mindless clicking. > >>>>>> > >>>>>> Just a nitpick: name it "Patch Reviewer" > >>>>>> - there's more to a ticket than a patch > >>>>>> - the review is not done yet when the field is filled out > >>>>> > >>>>> The only use-case I use patchwork for right now is a 'dashboard' to see > >>>>> which patches need attention. If we could get this dashboard-like view > >>>>> from Trac with some custom query, then I'm fine with deprecating > >>>>> Patchwork. > >>>> > >>>> +1. I would like to add the reviewer to default report 3 + prepare a new view > >>>> "My Active Reviews by Milestone" to see the reviews which one should track. > >>>> > >>>>> > >>>>> However, one feature of patchwork was that each re-submission of a > >>>>> patch triggered a new thread so as a reviewer you could easily see there > >>>>> is a new instance of the patch that you need to look at. I suspect Trac > >>>>> wouldn't give us anything like that? > >>>> > >>>> When I get a review, I like to get the response to inbox - then I always know. > >>>> When replies are only being sent to the list, we would have to use the advanced > >>>> Trac workflow and cautiously change states between accepted - submitted - onreview. > >>> > >>> I think this means we'll be back to have to carefully track the mailing > >>> list because stuff will be missed. This is something patchwork "fixed". > > No. The only thing that happened automatically in Patchwork was that > entries got created. Patchwork doesn't even have threads This is not true, patchwork keeps together all answers to a patch (the review) until you send a new one. > - each version > of a patch needed to be individually marked as superseded. Very much > mindless clicking is needed to keep Patchwork up to date. It is not perfect for sure, not claiming that. > >>> I wonder if we can build some automatism to not loose the good things > >>> here. > >>> > >>> Simo. > >> > >> Majority of patches going to freeipa-devel are tied to some Trac ticket. These > >> are tracked and watched by the on_review flag and the new reviewer field. > > > > If people remember to do it every time they just send an email, very > > process heavy. > > How is this different from Patchwork? You get a new thread with every submission, so you know there is something new autoatically by just looking at the list of patches, all replys are also inline, so you know if a specific version of a patch has got replies (there are caveats I know). > >> Those that are not covered by any Trac ticket need to be tracked and cared of > >> manually by the submitter IMO. > > > > Not very friendly to external submitters. > > External submitters can easily open tickets. Very process heavy, we need to make things easier not more complicated. > > I guess I'll keep the patchwork instance up for now ... > > I was basically the only one who used the IPA Patchwork any more. I have > stopped using it and I'm waiting for the Patch Reviewer field (in any > form!). > Without someone to *manually* mark all the patches as On review, then > Changes Requested, then Pushed... Patchwork is quite useless. I will eventually retire it for freeipa, but I am not satisfied by using a field in trac. > You can keep it running but no one from the FreeIPA team will use it. Sorry. This is fine, nobody is forced to. I still keep it on for the SSSD people which uses it so far. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Feb 20 15:58:27 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 10:58:27 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <530622B1.5090405@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <530622B1.5090405@redhat.com> Message-ID: <1392911907.22754.231.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 16:43 +0100, Tomas Babej wrote: > > No. The only thing that happened automatically in Patchwork was that > > entries got created. Patchwork doesn't even have threads - each > > version of a patch needed to be individually marked as superseded. > > Very much mindless clicking is needed to keep Patchwork up to date. > > > > Manually marking all the lost threads as superseeded was the exact > reason I stopped using Patchwork. And this is my fault, it would be actually rasonably easy to automatically make it mark older threads superseeded... > Patchwork would be a great tool, if it could automatically derive the > information it needs (work with threads properly, set patch status > depending on the email headers / keywords in the text). Having to > manually update it however, it becomes too heavyweight, because of the > imperfections Petr mentioned. It can do a lot of these things, we tried to enable sending status via email but something didn't work and we couldn't find time to fix it. But the infrastructure is there to do what you ask, it's just a matter of giving it some time. > The proposal we have for the reviewer field does not solve the problem, > but the actual maintenance load becomes much lighter, and we do get the > reasonable portion of benefit. I guess. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Feb 20 16:29:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 17:29:07 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392911710.22754.228.camel@willson.li.ssimo.org> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <1392911710.22754.228.camel@willson.li.ssimo.org> Message-ID: <53062D53.5080301@redhat.com> On 02/20/2014 04:55 PM, Simo Sorce wrote: > On Thu, 2014-02-20 at 16:34 +0100, Petr Viktorin wrote: >> On 02/20/2014 04:15 PM, Simo Sorce wrote: >>> On Thu, 2014-02-20 at 16:13 +0100, Martin Kosek wrote: >>>> On 02/20/2014 04:09 PM, Simo Sorce wrote: >>>>> On Thu, 2014-02-20 at 15:59 +0100, Martin Kosek wrote: >>>>>> On 02/20/2014 03:52 PM, Jakub Hrozek wrote: >>>>>>> On Thu, Feb 20, 2014 at 01:22:56PM +0100, Petr Viktorin wrote: >>>>>>>> On 02/20/2014 01:14 PM, Martin Kosek wrote: >>>>>>>>> We had a discussion with other developers how better track who is reviewing >>>>>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>>>>>> but that is a post-review tag which is not useful for someone who wants to know >>>>>>>>> which patches are already reviewed and which are not reviewed. >>>>>>>>> >>>>>>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>>>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>>>>>> lot of manual actions when maintaining it's state. >>>>>>>>> >>>>>>>>> I think it would be better to hold this information rather in a single tracking >>>>>>>>> tool - Trac. There are 2 options: >>>>>>>>> >>>>>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>>>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>>>>>> assigned. >>>>>>>>> >>>>>>>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>>>>>>> reviewing it. It would be filled either by a person starting the review or by a >>>>>>>>> supervisor like me to forcefully assign a reviewer ;-) >>>>>>>>> >>>>>>>>> With that information in Trac, we could run using a single tracking tool for >>>>>>>>> all patches that have a ticket (which is 95% of patches). It would be then >>>>>>>>> fairly easy to see which patches are sent for review but are reviewer-less. >>>>>>>>> >>>>>>>>> It would also have a benefit for Petr's sendpatches.py script which could pull >>>>>>>>> the reviewer from a ticket and one would not have to use the "-r" option to >>>>>>>>> hard code a reviewer. >>>>>>>>> >>>>>>>>> Any objections to using "Reviewed by" field? >>>>>>>> >>>>>>>> +1, this is the only thing I used Patchwork for, and keeping >>>>>>>> Patchwork up to date just for this took a lot of unnecessary >>>>>>>> mindless clicking. >>>>>>>> >>>>>>>> Just a nitpick: name it "Patch Reviewer" >>>>>>>> - there's more to a ticket than a patch >>>>>>>> - the review is not done yet when the field is filled out >>>>>>> >>>>>>> The only use-case I use patchwork for right now is a 'dashboard' to see >>>>>>> which patches need attention. If we could get this dashboard-like view >>>>>>> from Trac with some custom query, then I'm fine with deprecating >>>>>>> Patchwork. >>>>>> >>>>>> +1. I would like to add the reviewer to default report 3 + prepare a new view >>>>>> "My Active Reviews by Milestone" to see the reviews which one should track. >>>>>> >>>>>>> >>>>>>> However, one feature of patchwork was that each re-submission of a >>>>>>> patch triggered a new thread so as a reviewer you could easily see there >>>>>>> is a new instance of the patch that you need to look at. I suspect Trac >>>>>>> wouldn't give us anything like that? >>>>>> >>>>>> When I get a review, I like to get the response to inbox - then I always know. >>>>>> When replies are only being sent to the list, we would have to use the advanced >>>>>> Trac workflow and cautiously change states between accepted - submitted - onreview. >>>>> >>>>> I think this means we'll be back to have to carefully track the mailing >>>>> list because stuff will be missed. This is something patchwork "fixed". >> >> No. The only thing that happened automatically in Patchwork was that >> entries got created. Patchwork doesn't even have threads > > This is not true, patchwork keeps together all answers to a patch (the > review) until you send a new one. > >> - each version >> of a patch needed to be individually marked as superseded. Very much >> mindless clicking is needed to keep Patchwork up to date. > > It is not perfect for sure, not claiming that. > >>>>> I wonder if we can build some automatism to not loose the good things >>>>> here. >>>>> >>>>> Simo. >>>> >>>> Majority of patches going to freeipa-devel are tied to some Trac ticket. These >>>> are tracked and watched by the on_review flag and the new reviewer field. >>> >>> If people remember to do it every time they just send an email, very >>> process heavy. >> >> How is this different from Patchwork? > > You get a new thread with every submission, so you know there is > something new autoatically by just looking at the list of patches, all Yeah, one part is automatic. That's not enough. Patchwork: patch arrives: nothing mark self as reviewer: use web interface send review: reply, find patch in Patchwork, mark status send fixed patch: send the mail, find patch in Patchwork, mark status, find old patch in Patchwork, mark old patch as superseded patch pushed/superseded: find patch in Patchwork, mark as pushed (where "find patch in Patchwork" is frustrating when done so often) Mail+Trac: patch arrives: tag message TODO when it comes in (1 keystroke) mark self as reviewer: use web interface (or API) send review: just reply ("changes requested" status is not kept though) send fixed patch: send the mail patch pushed: move from the push messsage to the tagged message (~1 keystroke), untag message (1 keystroke) > replys are also inline, so you know if a specific version of a patch has > got replies (there are caveats I know). That assumes I read the replies in patchwork. Obviously Patchwork can't hope to be a better mail client than my favorite mail client. >>>> Those that are not covered by any Trac ticket need to be tracked and cared of >>>> manually by the submitter IMO. >>> >>> Not very friendly to external submitters. >> >> External submitters can easily open tickets. > > Very process heavy, we need to make things easier not more complicated. They don't have to. But if they forget their patches *and* we manage let it slip, all that means is that nobody cares. Anyway, with the amount of outside contributions we're getting, this is premature optimization. >>> I guess I'll keep the patchwork instance up for now ... >> >> I was basically the only one who used the IPA Patchwork any more. I have >> stopped using it and I'm waiting for the Patch Reviewer field (in any >> form!). >> Without someone to *manually* mark all the patches as On review, then >> Changes Requested, then Pushed... Patchwork is quite useless. > > I will eventually retire it for freeipa, but I am not satisfied by using > a field in trac. Not a silver bullet, but better than Patchwork I'm afraid. >> You can keep it running but no one from the FreeIPA team will use it. Sorry. > > This is fine, nobody is forced to. I still keep it on for the SSSD > people which uses it so far. Sounds good. Thanks for the experiment, it just didn't work out for us. -- Petr? From amisnyov at redhat.com Thu Feb 20 17:15:35 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Thu, 20 Feb 2014 12:15:35 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <1048727184.1530147.1392916473823.JavaMail.zimbra@redhat.com> Message-ID: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> Hi, this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 maximum serial number field now accepts only positive numbers Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0004-Certificate-search-max_serial_number-problem-fixed.patch Type: text/x-patch Size: 878 bytes Desc: not available URL: From dpal at redhat.com Thu Feb 20 17:47:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 12:47:15 -0500 Subject: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes In-Reply-To: <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> References: <038.1cba090b8bd39942646e9915d52008be@fedorahosted.org> <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> Message-ID: <53063FA3.9020703@redhat.com> On 02/20/2014 12:39 PM, freeipa wrote: > #4185: Index plugin namespaces by classes > -------------------------------------+------------------------------------- > Reporter: pviktori | Owner: pviktori > Type: refactoring | Status: new > Priority: major | Milestone: 0.0 > Component: IPA | NEEDS_TRIAGE > Resolution: | Version: > Blocked By: | Keywords: > Affects Documentation: 0 | Blocking: > Red Hat Bugzilla: | Patch posted for review: 0 > Design link: | External tracker: > Fedora test page: | Needs UI design: > Source: | Feature: > | Expertise: > -------------------------------------+------------------------------------- > Release Notes: > > > -------------------------------------+------------------------------------- > > Comment (by pviktori): > > It's very easy to enable this so I'd like to do that now, and adapt the > rest of the code whenever it's touched. > Should it be captured in some guidelines somewhere on the wiki? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Thu Feb 20 17:57:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Feb 2014 18:57:46 +0100 Subject: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes In-Reply-To: <53063FA3.9020703@redhat.com> References: <038.1cba090b8bd39942646e9915d52008be@fedorahosted.org> <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> <53063FA3.9020703@redhat.com> Message-ID: <5306421A.6000801@redhat.com> On 02/20/2014 06:47 PM, Dmitri Pal wrote: > On 02/20/2014 12:39 PM, freeipa wrote: >> #4185: Index plugin namespaces by classes >> -------------------------------------+------------------------------------- >> >> Reporter: pviktori | Owner: >> pviktori >> Type: refactoring | Status: new >> Priority: major | Milestone: 0.0 >> Component: IPA | NEEDS_TRIAGE >> Resolution: | Version: >> Blocked By: | Keywords: >> Affects Documentation: 0 | Blocking: >> Red Hat Bugzilla: | Patch posted for review: 0 >> Design link: | External tracker: >> Fedora test page: | Needs UI design: >> Source: | Feature: >> | Expertise: >> -------------------------------------+------------------------------------- >> >> Release Notes: >> >> >> -------------------------------------+------------------------------------- >> >> >> Comment (by pviktori): >> >> It's very easy to enable this so I'd like to do that now, and adapt the >> rest of the code whenever it's touched. >> > > Should it be captured in some guidelines somewhere on the wiki? I was planning to add some instructions to the [Refactorings] page, as I did with the new way to register plugins. I'm open to other suggestions. [Refactorings] http://www.freeipa.org/page/V3/Refactorings -- Petr? From dpal at redhat.com Thu Feb 20 18:02:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 13:02:53 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305FFEA.4000403@redhat.com> References: <5305F1BA.8080008@redhat.com> <20140220123122.GB25217@localhost.localdomain> <5305FCF1.3050901@redhat.com> <5305FFEA.4000403@redhat.com> Message-ID: <5306434D.6090709@redhat.com> On 02/20/2014 08:15 AM, Martin Kosek wrote: > On 02/20/2014 02:02 PM, Petr Spacek wrote: >> On 20.2.2014 13:31, Sumit Bose wrote: >>> On Thu, Feb 20, 2014 at 01:14:50PM +0100, Martin Kosek wrote: >>>> We had a discussion with other developers how better track who is reviewing >>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>> but that is a post-review tag which is not useful for someone who wants to know >>>> which patches are already reviewed and which are not reviewed. >>>> >>>> We were testing Patch Work [1] in last months to contain this information, but >>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>> lot of manual actions when maintaining it's state. >>>> >>>> I think it would be better to hold this information rather in a single tracking >>>> tool - Trac. There are 2 options: >>>> >>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>> would hold 1 bit information if the patch is just lying there or has somebody >>>> assigned. >>>> >>>> 2) "Reviewed by" text field which would hold a login of a person who is >>>> reviewing it. It would be filled either by a person starting the review or by a >>>> supervisor like me to forcefully assign a reviewer ;-) >>> +1 >>> >>> is it possible to instruct trac to send an email to the reviewer to let >>> him know the he's the chosen one? I guess this would help to even better >>> integrate with the workflow of many developers? >> It is definitely good idea! >> +1 > As always - this is a good idea. However, the execution is an integral part of > a successful idea :) And in this case I am not sure how to do it in Trac. I > tried looking for different notification or workflow plugin but did not find > something applicable to our Trac - ideas welcome. > > A workaround for me is to fill both reviewer + CC when assigning a reviewer or > also by adding a "My Active Patch Reviews by Milestone" view. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I am currently subscribed to all changes happening in trac. IMO what can be done is: a) You can subscribe to the notifications to or I can help with that b) Setup your mail filter to detect that the value of the field changed and has your name in it Then you will end up with the folder that has notifications that are relevant to only you being a reviewer. It is not going to be 100% clean but would work for 99% of the cases. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Thu Feb 20 18:45:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 13:45:04 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392223765.1816.4.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> Message-ID: <1392921904.1957.8.camel@localhost.localdomain> On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: > Through the review process, patches are getting shifted around, added, > deleted, etc. So I'm now just going to be posting all the patches as an > ordered set. The set attached is ordered according to my preferred merge > order. It also places easy to review patches up front. I hope this helps > reviewers. This format will definitely help me manage the patches. > > The first three patches should be very easy reviews and can be merged > independently. > > All current patch critiques have, to my knowledge, been addressed in > this latest series of patches. Attached are 8 patches, the first 5 of which should be ready for merge: 0001-0004: Already ACK'd by abokovoy; rebased for master VERSION changes 0005: Patch by abokovy; ACK'd by me 0006-0008: New patches Patch 0006 is a one-liner easy review. In patch 0008, I change the existing otptoken api. How should I change VERSION in this case since we haven't released the otptoken api yet? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-HOTP-support.patch Type: text/x-patch Size: 20774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 13035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-OTP-sync-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 56554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Teach-ipa-pwd-extop-to-respect-global-ipaUserAuthTyp.patch Type: text/x-patch Size: 34809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-libotp-do-not-call-internal-search-for-NULL-dn.patch Type: text/x-patch Size: 1419 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Fix-a-typo-where-self-was-omitted.patch Type: text/x-patch Size: 991 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Make-all-ipatokenTOTP-attributes-mandatory.patch Type: text/x-patch Size: 2844 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Rework-how-otptoken-defaults-are-handled.patch Type: text/x-patch Size: 17527 bytes Desc: not available URL: From npmccallum at redhat.com Thu Feb 20 18:53:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 13:53:40 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8D034.2040009@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> Message-ID: <1392922420.23210.1.camel@localhost.localdomain> On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: > > Hi, > > > > these patches implements the OTP Web UI. > > > > Last 5 patches is the OTP UI. > > > > First 6 patches is a little refactoring/bug fixes needed for them. > > General password dialog is introduced to avoid another implementation. > > > > Self-service UI is implemented to be very simple. Atm user can choose > > only token name. Admin interface allows to enter all values. > > > > It's based on the RCUE work -> we need to push RCUE first. Thanks > > Nathaniel for review of the last font package. It will speed things up. > > > > Know bugs: > > - there is clash in id's of checkboxes preventing editation of > > subsequently displayed ones with the same name. Will be fixed in > > separate patch. > > - bugs caused by bugs in API (adding/removal of own tokens in > > self-service, inability to enter key on token creation - > > https://fedorahosted.org/freeipa/ticket/4099) > > - datetime format (widget+validator) will be implemented in separate patch > > - no support of not reviewed CLI patches (HOTP..) > > > > Cgit: > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > > > > https://fedorahosted.org/freeipa/ticket/3369 > > > > patch 540-1 has been updated > - QR code is centered > - QR code correction level was lowered from H to M > > All other current patches from sub-threads are attached as well (it was > getting hard to keep track of them). I have proposed a change in the parameter defaults here: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html This should permit us to avoid the "default" radio button in the UI. Also, I'd like to see HOTP support added to the UI (should be trivial). I think that is all I have left. Nathaniel From npmccallum at redhat.com Thu Feb 20 18:56:52 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 13:56:52 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392905964.1957.0.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> Message-ID: <1392922612.23210.3.camel@localhost.localdomain> On Thu, 2014-02-20 at 09:19 -0500, Nathaniel McCallum wrote: > On Thu, 2014-02-20 at 14:33 +0200, Alexander Bokovoy wrote: > > On Thu, 20 Feb 2014, Alexander Bokovoy wrote: > > >>>>>There is definitely a bug (or more) in ipa-pwd-extop in handling > > >>>>>authentication cases. > > >>>>Some progress on this investigation. > > >>>> > > >>>>Plugin precedence setting is broken in 389-ds. It is only set once, > > >>>>before running init function provided by the plugin and does not take > > >>>>into account all callbacks that the init function may register. As > > >>>>result, all these functions get classified with default precedence (50) > > >>>>and no configuration could change this, we get ipa-pwd-extop's pre-bind > > >>>>callback called before schemacompat's one, thus working on the compat > > >>>>entry DN instead of the new one. Since that entry has no userPassword > > >>>>attribute, OTP code refuses to accept any password. > > >>>> > > >>>>When user is allowed to use password auth along with OTP, the fact that > > >>>>there is no userPassword get ipa-pwd-extop plugin through the failure. > > >>>>schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of > > >>>>389-ds code checks actual password. > > >>>> > > >>>>So we have two issues here: OTP code needs to gracefully ignore entries > > >>>>without userPassword set, and we need to be able to re-arrange > > >>>>schemacompat and ipa-pwd-extop precedence for pre-bind operation. > > >>>> > > >>>>I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on > > >>>>the latter. > > >>>> > > >>>>The messages from the log are not yet solved... > > >>>Finally, I have a clue after tracing with debug level 1: > > >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461 > > >>>[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter > > >>>[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL > > >>>[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type 461 > > >>> > > >>>So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more. > > >>There is an error in libotp's find() function which assumes that > > >>get_basedn() always returns non-NULL value. This is not true for at > > >>least cn=Directory Manager. > > >> > > >>Patch attached. > > >More fixes required, now that Thierry produced the fix for 389-ds ticket > > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop > > >plugins. I'm getting crash in find() in libotp.c for internal search in > > >some other conditions but at least user dn now is the correct one. > > > > > >Stay tuned. > > OK, finally I've got it working -- my last patch had error which could > > be attributed to the late night time. > > > > New patch is attached to fix libotp to work properly with empty base dn > > (such as cn=Directory Manager). > > > > Also I'm attaching the patch that sets precedence of schema-compat > > plugin to 49 (less than default 50). With this patch and 389-ds with > > patch from ticket 47699 compat tree binds work with OTP. > > > > When updated 389-ds-base will be released, we'll need to add Requires: > > to our RPM spec to depend on it. Without the updated 389-ds-base compat > > tree binds will not work with OTP but the rest will be working fine. > > > > Finally, ACK to all OTP patches. > > ACK to both of these patches. I've merged the first patch here -- https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html I just realized the second patch shouldn't be ACK'd until we have a new 389DS release with the fix. When that happens, reissue this patch with an update versioned require. Nathaniel From npmccallum at redhat.com Thu Feb 20 18:58:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 13:58:39 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140214121353.GD3496@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140214121353.GD3496@redhat.com> Message-ID: <1392922719.23210.5.camel@localhost.localdomain> On Fri, 2014-02-14 at 14:13 +0200, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Nathaniel McCallum wrote: > >Through the review process, patches are getting shifted around, added, > >deleted, etc. So I'm now just going to be posting all the patches as an > >ordered set. The set attached is ordered according to my preferred merge > >order. It also places easy to review patches up front. I hope this helps > >reviewers. This format will definitely help me manage the patches. > > > >The first three patches should be very easy reviews and can be merged > >independently. > > > >All current patch critiques have, to my knowledge, been addressed in > >this latest series of patches. > ACK for 0006-Add-libotp-internal-library-for-slapi-plugins.patch > > Should we pay attention to changing default from SHA-1 algo to SHA-2 > family (SHA-256, SHA-384, SHA-512)? Unfortunately, Google Authenticator only supports SHA-1. FreeOTP, however, supports them all. If we change the default, we'll have to document that the defaults don't work with GA. Nathaniel From dpal at redhat.com Thu Feb 20 19:00:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 14:00:57 -0500 Subject: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes In-Reply-To: <5306421A.6000801@redhat.com> References: <038.1cba090b8bd39942646e9915d52008be@fedorahosted.org> <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> <53063FA3.9020703@redhat.com> <5306421A.6000801@redhat.com> Message-ID: <530650E9.5070802@redhat.com> On 02/20/2014 12:57 PM, Petr Viktorin wrote: > On 02/20/2014 06:47 PM, Dmitri Pal wrote: >> On 02/20/2014 12:39 PM, freeipa wrote: >>> #4185: Index plugin namespaces by classes >>> -------------------------------------+------------------------------------- >>> >>> >>> Reporter: pviktori | Owner: >>> pviktori >>> Type: refactoring | Status: new >>> Priority: major | Milestone: 0.0 >>> Component: IPA | NEEDS_TRIAGE >>> Resolution: | Version: >>> Blocked By: | Keywords: >>> Affects Documentation: 0 | Blocking: >>> Red Hat Bugzilla: | Patch posted for review: 0 >>> Design link: | External tracker: >>> Fedora test page: | Needs UI design: >>> Source: | Feature: >>> | Expertise: >>> -------------------------------------+------------------------------------- >>> >>> >>> Release Notes: >>> >>> >>> -------------------------------------+------------------------------------- >>> >>> >>> >>> Comment (by pviktori): >>> >>> It's very easy to enable this so I'd like to do that now, and >>> adapt the >>> rest of the code whenever it's touched. >>> >> >> Should it be captured in some guidelines somewhere on the wiki? > > I was planning to add some instructions to the [Refactorings] page, as > I did with the new way to register plugins. > I'm open to other suggestions. > > > [Refactorings] http://www.freeipa.org/page/V3/Refactorings > If we have some do and do not's it should be similar to Style guide but rather developer best practices guide. It should be a quick reference of: do not do X do Y instead like do not treat DN as string - use DN class ... use this notation instead of that notation etc. Then we can point people to it as part of the review process. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Thu Feb 20 19:08:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 20:08:23 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062D53.5080301@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <1392911710.22754.228.camel@willson.li.ssimo.org> <53062D53.5080301@redhat.com> Message-ID: <530652A7.2080207@redhat.com> On 02/20/2014 05:29 PM, Petr Viktorin wrote: > On 02/20/2014 04:55 PM, Simo Sorce wrote: >> On Thu, 2014-02-20 at 16:34 +0100, Petr Viktorin wrote: ... > Mail+Trac: > patch arrives: tag message TODO when it comes in (1 keystroke) > mark self as reviewer: use web interface (or API) > send review: just reply ("changes requested" status is not kept though) > send fixed patch: send the mail > patch pushed: move from the push messsage to the tagged message (~1 > keystroke), untag message (1 keystroke) +1, I use the same process and it works fine for me. If we are crazy enough, I guess it would not be so difficult to do some actions from MUA via Trac API. For example, select new message with patch, click on "Start review" button which would set my login to the respective ticket and one could start reviewing without touching Trac at all. Hm hm... So, Petr1, what are you doing over the weekend, fancy learning how to write a Thunderbird plugin?;-) But I think a simple script like "startreview.py some.patch" that Petr mentioned is a good start, few lines of code. ... >>> I was basically the only one who used the IPA Patchwork any more. I have >>> stopped using it and I'm waiting for the Patch Reviewer field (in any >>> form!). >>> Without someone to *manually* mark all the patches as On review, then >>> Changes Requested, then Pushed... Patchwork is quite useless. >> >> I will eventually retire it for freeipa, but I am not satisfied by using >> a field in trac. > > Not a silver bullet, but better than Patchwork I'm afraid. I am not saying we need to always use the reviewer field, maybe it won't work well for us - we can delete it and think about something different. >>> You can keep it running but no one from the FreeIPA team will use it. Sorry. >> >> This is fine, nobody is forced to. I still keep it on for the SSSD >> people which uses it so far. > > Sounds good. Thanks for the experiment, it just didn't work out for us. > +1, thanks for your effort Simo, very valued. Martin From simo at redhat.com Thu Feb 20 19:11:08 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 14:11:08 -0500 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062D53.5080301@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <1392911710.22754.228.camel@willson.li.ssimo.org> <53062D53.5080301@redhat.com> Message-ID: <1392923468.22754.247.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 17:29 +0100, Petr Viktorin wrote: > Patchwork: > patch arrives: nothing > mark self as reviewer: use web interface > send review: reply, find patch in Patchwork, mark status > send fixed patch: send the mail, find patch in Patchwork, mark > status, > find old patch in Patchwork, mark old patch as superseded > patch pushed/superseded: find patch in Patchwork, mark as pushed > > (where "find patch in Patchwork" is frustrating when done so often) > Well now I have patches that do 2 things: 1. accept commands to change state and reviewer via email headers 2. automatically marks superseded older patches in the same mailthread I will install these patches shortly Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Feb 20 19:20:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 20:20:20 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53062217.6080005@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <53062217.6080005@redhat.com> Message-ID: <53065574.6030901@redhat.com> On 02/20/2014 04:41 PM, Petr Spacek wrote: > On 20.2.2014 16:34, Petr Viktorin wrote: ... > Note that Trac has XMLRPC so it is very very easy to have script for review > assignment etc. > $ start_review.py somerandomstring.patch > can very easily grep ticket URL and add your name to 'Reviewer' field in the > ticket. > > (I have similar scripts for paperwork related to push/ticket closing so it is > not pure theory.) > +1. This is an idea with easy and realizable execution :-) Martin From lslebodn at redhat.com Thu Feb 20 21:32:25 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 20 Feb 2014 22:32:25 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <53060C8B.4@redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> <53060761.7090100@redhat.com> <5306090B.5040406@redhat.com> <53060C8B.4@redhat.com> Message-ID: <20140220213224.GA10098@mail.corp.redhat.com> On (20/02/14 15:09), Martin Kosek wrote: >On 02/20/2014 02:54 PM, Petr Spacek wrote: >> On 20.2.2014 14:47, Martin Kosek wrote: >>> On 02/20/2014 02:31 PM, Jan Cholasta wrote: >>>> On 20.2.2014 13:14, Martin Kosek wrote: >>>>> We had a discussion with other developers how better track who is reviewing >>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>> but that is a post-review tag which is not useful for someone who wants to >>>>> know >>>>> which patches are already reviewed and which are not reviewed. >>>>> >>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>> lot of manual actions when maintaining it's state. >>>>> >>>>> I think it would be better to hold this information rather in a single >>>>> tracking >>>>> tool - Trac. There are 2 options: >>>>> >>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>> assigned. >>>> >>>> Is it possible to add new ticket states in Trac? I'm thinking extending it so >>>> that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work >>>> in progress -> assigned:patch available -> assigned:patch under review -> >>>> closed:fixed", or something like that. >>> >>> It is possible to change the workflow, yes - this is something I was also >>> considering. >>> >>> It can be done with this plugin: >>> >>> https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin >>> >>> Unfortunately, the plugin that's in Fedorahosted Trac does not work properly, >>> it gave me some Internal Errors. I filed a ticket for that: >>> https://fedorahosted.org/fedora-infrastructure/ticket/4237 >>> >>> When it is fixed, we can try to think about adjusting the workflow. Maybe we >>> can indeed add new states "submitted" and "onreview" to the workflow. But even >>> then I think we could use the "Patch Review by" field so that we know who is >>> reviewing, if anybody. >> >> Thinking a bit more the e-mail notifications ... >> >> We can reassign ticket to reviewer if we have state "onreview". IMHO ticket >> owner always get e-mails, right? >> >> Nice side-effect is that report "{4} Assigned, Active Tickets by Owner" will >> give you exact list of open tickets (state != new && state != closed) and you >> will see who is in charge for each ticket right in the report. >> >> Ticket owner is not set in stone and everything is still in Trac history (and >> Git, of course :-). > >Maybe. But that would mean that when you NACK a patch, you would need to move >the ticket back to previous state to reset the owner. As I know how much you >like the bureaucracy, are you sure you want this change? :) > >When the ticket is closed I personally like that owner is set to the >implementer. As that way I quickly see who I need to yell when this ticket >breaks something. > >IMO ideal state would be to have a workflow: >"Accept as reviewer" - adds your name to reviewer field, moves to onreview >"Assign reviewer: ________" - adds some login to reviewer field, moves to onreview > >We would just need to find out how to do this with some Workflow plugin when it >is ready. > I could not resist. This effort with the trac looks like reinventing wheel (gerrit or similar tool) LS From npmccallum at redhat.com Thu Feb 20 21:59:48 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Feb 2014 16:59:48 -0500 Subject: [Freeipa-devel] OTP Sync Client In-Reply-To: <1390424357.1984.104.camel@localhost.localdomain> References: <1390424357.1984.104.camel@localhost.localdomain> Message-ID: <1392933588.23210.13.camel@localhost.localdomain> On Wed, 2014-01-22 at 15:59 -0500, Nathaniel McCallum wrote: > In attempting to write an OTP synchronization client, I've noticed it > doesn't fit into the framework very well. The job of the client is to > perform the synchronization extended operation. The format of the > request is this: > > OTPSyncRequestValue ::= SEQUENCE { > userDN OCTET STRING, > tokenDN [0] OCTET STRING OPTIONAL, > firstFactor [1] OCTET STRING OPTIONAL, > firstCode INTEGER, > secondCode INTEGER > } > > In all cases, the user MUST provide two token codes and MAY provide the > DN of a token to sync. > > >From here two cases exist: bound and unbound. > > In the unbound case, both the userDN and firstFactor fields are required > and authentication is performed internally. > > In the bound case, the client has already bound (usually via a kerberos > ticket). In this case, the client must provide userDN only. There are > two options here. First, the client can generate the userDN > automatically from the kerberos ticket metadata. Second, the extop > plugin can make the userDN field optional and simply rely on the > internal bind DN. This is my preferred route, and will require a new > revision of the otp sync patch (no problem). In this second case, if the > user is bound, the DS plugin would ignore the values of > userDN/firstFactor. > > Assuming the second case to be true, how do I write a command in the > framework that will attempt a krb5 bind and then prompt for > username/password if the bind fails? Also, how do I, on the client side, > without any bind to LDAP translate the username to the userDN? The same > is true for the token ID to DN translation? Would it be better to write > this code independently of the FreeIPA client command framework? Attached is a first attempt at implementing a sync client. It works, but isn't ready for merger. Please help me suggest ways to overcome the various problems: 1. This requires a krb5 TGT in order to perform the command. I am assuming that everything in execute() is happening on the server-side and the server wants authentication. Obviously, we can't require a TGT to sync the token. 2. If a TGT *is* present, it would be really nice to bypass the username/password options entirely and do a SASL bind (from the client? Is 389DS guaranteed to be available to the client? 3. There has to be a better way to get the LDAP URI than what I'm doing. 4. I have concerns about passing the password over the wire. We are doing this two places: A. client => freeipa B. freeipa => 389DS Thoughts? 5. What should I do about the return value of the command? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-First-stab-at-sync-client.patch Type: text/x-patch Size: 5294 bytes Desc: not available URL: From pspacek at redhat.com Thu Feb 20 22:02:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Feb 2014 23:02:53 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <530652A7.2080207@redhat.com> References: <5305F1BA.8080008@redhat.com> <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <1392911710.22754.228.camel@willson.li.ssimo.org> <53062D53.5080301@redhat.com> <530652A7.2080207@redhat.com> Message-ID: <53067B8D.2060806@redhat.com> On 20.2.2014 20:08, Martin Kosek wrote: > But I think a simple script like "startreview.py some.patch" that Petr > mentioned is a good start, few lines of code. I have modified my push.py to start_review.py. Clone https://github.com/spacekpe/freeipa-processes.git and read the commit message :-) It reads git log as input, you will have to extend git.py if you want to use it with patch file. The code quality is horrrrible, feel free to rework it as necessary and of course - send pull requests! :-) I didn't even try to find Python library for git and so on ... -- Petr^2 Spacek From abokovoy at redhat.com Thu Feb 20 22:08:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 21 Feb 2014 00:08:59 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392922612.23210.3.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> <1392922612.23210.3.camel@localhost.localdomain> Message-ID: <20140220220859.GR16644@redhat.com> On Thu, 20 Feb 2014, Nathaniel McCallum wrote: >> > >>There is an error in libotp's find() function which assumes that >> > >>get_basedn() always returns non-NULL value. This is not true for at >> > >>least cn=Directory Manager. >> > >> >> > >>Patch attached. >> > >More fixes required, now that Thierry produced the fix for 389-ds ticket >> > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop >> > >plugins. I'm getting crash in find() in libotp.c for internal search in >> > >some other conditions but at least user dn now is the correct one. >> > > >> > >Stay tuned. >> > OK, finally I've got it working -- my last patch had error which could >> > be attributed to the late night time. >> > >> > New patch is attached to fix libotp to work properly with empty base dn >> > (such as cn=Directory Manager). >> > >> > Also I'm attaching the patch that sets precedence of schema-compat >> > plugin to 49 (less than default 50). With this patch and 389-ds with >> > patch from ticket 47699 compat tree binds work with OTP. >> > >> > When updated 389-ds-base will be released, we'll need to add Requires: >> > to our RPM spec to depend on it. Without the updated 389-ds-base compat >> > tree binds will not work with OTP but the rest will be working fine. >> > >> > Finally, ACK to all OTP patches. >> >> ACK to both of these patches. > >I've merged the first patch here -- >https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html > >I just realized the second patch shouldn't be ACK'd until we have a new >389DS release with the fix. When that happens, reissue this patch with >an update versioned require. No, it can be safely merged as 389DS will use default precedence (50) unless the fix is there. So the worst we get is the same as now -- OTP binds will not work over compat tree. And when 389DS will be upgraded, they will start working after 389DS restart. -- / Alexander Bokovoy From mkosek at redhat.com Fri Feb 21 07:37:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Feb 2014 08:37:57 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <20140220213224.GA10098@mail.corp.redhat.com> References: <5305F1BA.8080008@redhat.com> <530603C7.9080808@redhat.com> <53060761.7090100@redhat.com> <5306090B.5040406@redhat.com> <53060C8B.4@redhat.com> <20140220213224.GA10098@mail.corp.redhat.com> Message-ID: <53070255.2040204@redhat.com> On 02/20/2014 10:32 PM, Lukas Slebodnik wrote: > On (20/02/14 15:09), Martin Kosek wrote: >> On 02/20/2014 02:54 PM, Petr Spacek wrote: >>> On 20.2.2014 14:47, Martin Kosek wrote: >>>> On 02/20/2014 02:31 PM, Jan Cholasta wrote: >>>>> On 20.2.2014 13:14, Martin Kosek wrote: >>>>>> We had a discussion with other developers how better track who is reviewing >>>>>> which patch. Recently, we introduced the Reviewed-By tag in a commit message, >>>>>> but that is a post-review tag which is not useful for someone who wants to >>>>>> know >>>>>> which patches are already reviewed and which are not reviewed. >>>>>> >>>>>> We were testing Patch Work [1] in last months to contain this information, but >>>>>> I personally think that it is suboptimal - it introduces 2 tracking tools that >>>>>> needs to be maintained (Trac and Patch Work) and the Patch Work still requires >>>>>> lot of manual actions when maintaining it's state. >>>>>> >>>>>> I think it would be better to hold this information rather in a single >>>>>> tracking >>>>>> tool - Trac. There are 2 options: >>>>>> >>>>>> 1) "Patch on review" flag, similar to "Patch posted for review" flag which >>>>>> would hold 1 bit information if the patch is just lying there or has somebody >>>>>> assigned. >>>>> >>>>> Is it possible to add new ticket states in Trac? I'm thinking extending it so >>>>> that instead of "new -> assigned -> closed:fixed" we have "new -> assigned:work >>>>> in progress -> assigned:patch available -> assigned:patch under review -> >>>>> closed:fixed", or something like that. >>>> >>>> It is possible to change the workflow, yes - this is something I was also >>>> considering. >>>> >>>> It can be done with this plugin: >>>> >>>> https://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin >>>> >>>> Unfortunately, the plugin that's in Fedorahosted Trac does not work properly, >>>> it gave me some Internal Errors. I filed a ticket for that: >>>> https://fedorahosted.org/fedora-infrastructure/ticket/4237 >>>> >>>> When it is fixed, we can try to think about adjusting the workflow. Maybe we >>>> can indeed add new states "submitted" and "onreview" to the workflow. But even >>>> then I think we could use the "Patch Review by" field so that we know who is >>>> reviewing, if anybody. >>> >>> Thinking a bit more the e-mail notifications ... >>> >>> We can reassign ticket to reviewer if we have state "onreview". IMHO ticket >>> owner always get e-mails, right? >>> >>> Nice side-effect is that report "{4} Assigned, Active Tickets by Owner" will >>> give you exact list of open tickets (state != new && state != closed) and you >>> will see who is in charge for each ticket right in the report. >>> >>> Ticket owner is not set in stone and everything is still in Trac history (and >>> Git, of course :-). >> >> Maybe. But that would mean that when you NACK a patch, you would need to move >> the ticket back to previous state to reset the owner. As I know how much you >> like the bureaucracy, are you sure you want this change? :) >> >> When the ticket is closed I personally like that owner is set to the >> implementer. As that way I quickly see who I need to yell when this ticket >> breaks something. >> >> IMO ideal state would be to have a workflow: >> "Accept as reviewer" - adds your name to reviewer field, moves to onreview >> "Assign reviewer: ________" - adds some login to reviewer field, moves to onreview >> >> We would just need to find out how to do this with some Workflow plugin when it >> is ready. >> > I could not resist. That's fine, but you are still not the first SSSD dev who could not resist with this question :) > > This effort with the trac looks like reinventing wheel (gerrit or similar tool) > > LS I am not saying it doesn't - we are partially reinventing a wheel. However, there were several discussions already about using a tool like Gerrit or Review Board and there was even a bigger push back against it. So moving one step forward to a home grown review system currently seems as our best option. As I said, if we see that it does not work and we start using other review tool, we can always delete this field in Trac. When ticket is closed, the real reviewer information is stored in the git commit anyway. Martin From abokovoy at redhat.com Fri Feb 21 09:29:04 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 21 Feb 2014 11:29:04 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392921904.1957.8.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <1392921904.1957.8.camel@localhost.localdomain> Message-ID: <20140221092904.GS16644@redhat.com> On Thu, 20 Feb 2014, Nathaniel McCallum wrote: >From ead3ef011667dadacfc817725179f38c05177a00 Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Thu, 20 Feb 2014 13:20:01 -0500 >Subject: [PATCH 6/8] Fix a typo where self was omitted > >https://fedorahosted.org/freeipa/ticket/4099 >--- > ipalib/plugins/otptoken.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py >index 77c17150d83f0562823698e1ad585ec523f16ad7..6b142989fd306472ede3e0a528fb103cd46fca77 100644 >--- a/ipalib/plugins/otptoken.py >+++ b/ipalib/plugins/otptoken.py >@@ -80,7 +80,7 @@ class OTPTokenKey(Bytes): > except TypeError, e: > raise ConversionError(name=self.name, index=index, error=str(e)) > >- return Bytes._convert_scalar(value, index) >+ return Bytes._convert_scalar(self, value, index) > > def _convert_owner(userobj, entry_attrs, options): > if 'ipatokenowner' in entry_attrs and not options.get('raw', False): NACK, it should use super() instead: return super(OTPTokenKey, self)._convert_scalar(value, index) see ipalib/parameters.py:1369 as an example. -- / Alexander Bokovoy From pviktori at redhat.com Fri Feb 21 09:31:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 10:31:50 +0100 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392921904.1957.8.camel@localhost.localdomain> References: <1392223765.1816.4.camel@localhost.localdomain> <1392921904.1957.8.camel@localhost.localdomain> Message-ID: <53071D06.7060204@redhat.com> On 02/20/2014 07:45 PM, Nathaniel McCallum wrote: > On Wed, 2014-02-12 at 11:49 -0500, Nathaniel McCallum wrote: >> Through the review process, patches are getting shifted around, added, >> deleted, etc. So I'm now just going to be posting all the patches as an >> ordered set. The set attached is ordered according to my preferred merge >> order. It also places easy to review patches up front. I hope this helps >> reviewers. This format will definitely help me manage the patches. >> >> The first three patches should be very easy reviews and can be merged >> independently. >> >> All current patch critiques have, to my knowledge, been addressed in >> this latest series of patches. > > Attached are 8 patches, the first 5 of which should be ready for merge: > 0001-0004: Already ACK'd by abokovoy; rebased for master VERSION changes > 0005: Patch by abokovy; ACK'd by me Pushed these 5 to master: 9a8f44c09e0e78550b126235240214e7b11af081 > 0006-0008: New patches > > Patch 0006 is a one-liner easy review. > > In patch 0008, I change the existing otptoken api. How should I change > VERSION in this case since we haven't released the otptoken api yet? > > Nathaniel This thread is getting very confusing. In the future, could you not reuse the numbers 0001-0008 for different patches? Generally we try to follow the patch naming guide: http://www.freeipa.org/page/Contribute/Patch_Format -- Petr? From pspacek at redhat.com Fri Feb 21 09:46:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 10:46:00 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) Message-ID: <53072058.3000500@redhat.com> Hello list, I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found that we need to enable SELinux boolean named_write_master_zones otherwise the plugin will not be able to write journal files to /var/named. I have asked Miroslav Grepl for advice and his recommendation is to use another context for our dyndb-ldap sub-directory or to enable named_write_master_zones. (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) I have decided to use more generic named_write_master_zones because it will be need for DNSSEC key management anyway. Miroslav told me that it is allowed to change SELinux booleans in RPM scriptlets - it is normal operation - but that we have to disable the boolean during package un-installation. Please review %post and %postun sections in SPEC file. Thank you! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: pspacek-bind-dyndb-ldap-0223-Update-Fedora-SPEC-file-for-v4.0.patch Type: text/x-patch Size: 2793 bytes Desc: not available URL: From jcholast at redhat.com Fri Feb 21 10:05:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Feb 2014 11:05:12 +0100 Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> References: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> Message-ID: <530724D8.8060503@redhat.com> Hi, On 20.2.2014 18:15, Adam Misnyovszki wrote: > Hi, > > this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 > maximum serial number field now accepts only positive numbers > > Thanks > Adam I think you should also add maxvalue to min_serial_number, so that they are consistent. Honza -- Jan Cholasta From thozza at redhat.com Fri Feb 21 10:05:56 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 21 Feb 2014 11:05:56 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <53072058.3000500@redhat.com> References: <53072058.3000500@redhat.com> Message-ID: <53072504.1070407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter. See comments below... On 02/21/2014 10:46 AM, Petr Spacek wrote: > Hello list, > > I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found that we > need to enable SELinux boolean named_write_master_zones otherwise the plugin > will not be able to write journal files to /var/named. > > I have asked Miroslav Grepl for advice and his > recommendation is to use another context for our dyndb-ldap sub-directory or > to enable named_write_master_zones. > > (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) > > I have decided to use more generic named_write_master_zones because it will be > need for DNSSEC key management anyway. > > Miroslav told me that it is allowed to change SELinux booleans in RPM > scriptlets - it is normal operation - but that we have to disable the boolean > during package un-installation. > > Please review %post and %postun sections in SPEC file. > > Thank you! > > -- Petr^2 Spacek > > > > From a7329ae3459a135eff2897d3de9da607280b4615 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 21 Feb 2014 10:35:35 +0100 > Subject: [PATCH] Update to 4.0. > > Signed-off-by: Petr Spacek > --- > bind-dyndb-ldap.spec | 31 ++++++++++++++++++++++++------- > 1 file changed, 24 insertions(+), 7 deletions(-) > > ======================================= > > diff --git a/bind-dyndb-ldap.spec b/bind-dyndb-ldap.spec > index 85b59e40035a35276ee0997764cdd976a8716df5..cbe6b7c76327a9df8e49d4acf925be8f9c1da29b 100644 > > --- a/bind-dyndb-ldap.spec > > +++ b/bind-dyndb-ldap.spec > > @@ -1,26 +1,22 @@ > > -#%define PATCHVER P4 > -#%define PREVER 20121009git6a86b1 > -#%define VERSION %{version}-%{PATCHVER} > -#%define VERSION %{version}-%{PREVER} > %define VERSION %{version} > Name: bind-dyndb-ldap > -Version: 3.5 > +Version: 4.0 > Release: 1%{?dist} > Summary: LDAP back-end plug-in for BIND > Group: System Environment/Libraries > License: GPLv2+ > URL: https://fedorahosted.org/bind-dyndb-ldap > Source0: > https://fedorahosted.org/released/%{name}/%{name}-%{VERSION}.tar.bz2 > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > -BuildRequires: bind-devel >= 32:9.6.1-0.3.b1 > +BuildRequires: bind-devel >= 32:9.9.0-1, bind-lite-devel >= 32:9.9.0-1 > BuildRequires: krb5-devel > BuildRequires: openldap-devel > BuildRequires: automake, autoconf, libtool > -Requires: bind >= 32:9.6.1-0.3.b1 > +Requires: bind >= 32:9.9.0-1 > %description > This package provides an LDAP back-end plug-in for BIND. It features > > @@ -41,25 +37,45 @@ > > make %{?_smp_mflags} > %install > rm -rf %{buildroot} > make install DESTDIR=%{buildroot} > +mkdir -m 770 -p %{buildroot}/%{_localstatedir}/named/dyndb-ldap > # Remove unwanted files > rm %{buildroot}%{_libdir}/bind/ldap.la > rm -r %{buildroot}%{_datadir}/doc/%{name} > +# SELinux boolean named_write_master_zones has to be enabled > +# otherwise plugin will not be able to write to /var/named > +%post > +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then > + echo "Enabling SELinux boolean named_write_master_zones" > + /usr/sbin/setsebool -P named_write_master_zones=1 || true I think you should redirect all output from the setsebool to /dev/null so it does not produce any output during the "yum install". The same for the "echo" I'm not sure if it should be there, but I didn't find any rule in packaging guidelines that is prohibiting you from doing so. It is also "common" to use ":" instead of "true" after OR, but this is a cosmetic thing. You can find more information (if you didn't already) here: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets > +fi > + > + > +%postun > +if [ "0$1" -eq "0" ] && [ -x "/usr/sbin/setsebool" ] ; then > + echo "Disabling SELinux boolean named_write_master_zones" > + /usr/sbin/setsebool -P named_write_master_zones=0 || true The same as above... > +fi > + > + > %clean > rm -rf %{buildroot} > %files > %defattr(-,root,root,-) > %doc NEWS README COPYING doc/{example.ldif,schema} > +%dir %attr(770, root, named) %{_localstatedir}/named/dyndb-ldap > %{_libdir}/bind/ldap.so > %changelog > +* Wed Feb 19 2014 Petr Spacek 4.0-1 > +- update to 4.0 > + > * Thu Jul 18 2013 Petr Spacek 3.5-1 > - update to 3.5 > -- > > 1.8.5.3 Regards, Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTByT9AAoJEMWIetUdnzwtbW0H/38n6O3KKuwbwZgV+SVToZLE CIu7RvzLcLejhVyi8ncVrFUs4jS6xl4Uf2t9OmGjQlkuHECjXu/0Nz1Rkher2fZh c4qyvKrpBaKXpcWtOHEdOKBCKEjq2Qjque1c4zeklSIqtJL5qqrLjcJGrtET5p8C hFy3+FrnvY2va+vK1NJMFfvQ0qhU2OGOJG6SKrsOJcVy1GIVX3dRAMYL1mPyKlb3 LazBqa7vgWkw9ZwSzMH/5CMrih6te7DeEzCsTsXQY4oMGEro+2VoTMaVhNMu19jb DuxUUG8AbPwh1p8yhhppf0s8gXZnKPGzBBnezkC6KBXmw3ppnUm8DLeclcNlrPU= =6o0G -----END PGP SIGNATURE----- From jcholast at redhat.com Fri Feb 21 10:13:40 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Feb 2014 11:13:40 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: <5305C2E2.7050602@redhat.com> References: <5305C2E2.7050602@redhat.com> Message-ID: <530726D4.9040505@redhat.com> Hi, On 20.2.2014 09:54, Petr Viktorin wrote: > Hello, > I had this patch sitting around for some time but didn't get around to > polishing and submitting it lately. > The ticket was now claimed by "rga" (I assume that's the person who goes > by Darth Vader here?). I'm sharing the work hoping that it doesn't get > done twice. > > https://fedorahosted.org/freeipa/ticket/3460 > > > BTW, this is the first small step in my framework refactoring master > plan (http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). ACK on the patch. Honza -- Jan Cholasta From pviktori at redhat.com Fri Feb 21 11:00:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 12:00:46 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 0469 - Remove the unused ipalib.frontend.Property class In-Reply-To: <530726D4.9040505@redhat.com> References: <5305C2E2.7050602@redhat.com> <530726D4.9040505@redhat.com> Message-ID: <530731DE.2000502@redhat.com> On 02/21/2014 11:13 AM, Jan Cholasta wrote: > Hi, > > On 20.2.2014 09:54, Petr Viktorin wrote: >> Hello, >> I had this patch sitting around for some time but didn't get around to >> polishing and submitting it lately. >> The ticket was now claimed by "rga" (I assume that's the person who goes >> by Darth Vader here?). I'm sharing the work hoping that it doesn't get >> done twice. >> >> https://fedorahosted.org/freeipa/ticket/3460 >> >> >> BTW, this is the first small step in my framework refactoring master >> plan >> (http://www.freeipa.org/page/V3/Refactorings#Mutable_Command_objects). > > ACK on the patch. > > Honza > Thank you! Pushed to master: eef5acd9d73c81133969521ed9fc7e82d5f180ab -- Petr? From pspacek at redhat.com Fri Feb 21 11:10:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:10:15 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <53072504.1070407@redhat.com> References: <53072058.3000500@redhat.com> <53072504.1070407@redhat.com> Message-ID: <53073417.6050300@redhat.com> On 21.2.2014 11:05, Tomas Hozza wrote: > On 02/21/2014 10:46 AM, Petr Spacek wrote: >> I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found that we >> need to enable SELinux boolean named_write_master_zones otherwise the plugin >> will not be able to write journal files to /var/named. >> >> I have asked Miroslav Grepl for advice and his >> recommendation is to use another context for our dyndb-ldap sub-directory or >> to enable named_write_master_zones. >> >> (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) >> >> I have decided to use more generic named_write_master_zones because it will be >> need for DNSSEC key management anyway. >> >> Miroslav told me that it is allowed to change SELinux booleans in RPM >> scriptlets - it is normal operation - but that we have to disable the boolean >> during package un-installation. >> >> Please review %post and %postun sections in SPEC file. >> >> Thank you! >> >> -- Petr^2 Spacek >> >> >> >> From a7329ae3459a135eff2897d3de9da607280b4615 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 21 Feb 2014 10:35:35 +0100 >> Subject: [PATCH] Update to 4.0. >> >> Signed-off-by: Petr Spacek >> --- >> bind-dyndb-ldap.spec | 31 ++++++++++++++++++++++++------- >> 1 file changed, 24 insertions(+), 7 deletions(-) >> >> ======================================= >> >> diff --git a/bind-dyndb-ldap.spec b/bind-dyndb-ldap.spec >> index 85b59e40035a35276ee0997764cdd976a8716df5..cbe6b7c76327a9df8e49d4acf925be8f9c1da29b 100644 >> >> --- a/bind-dyndb-ldap.spec >> >> +++ b/bind-dyndb-ldap.spec >> >> @@ -1,26 +1,22 @@ >> >> -#%define PATCHVER P4 >> -#%define PREVER 20121009git6a86b1 >> -#%define VERSION %{version}-%{PATCHVER} >> -#%define VERSION %{version}-%{PREVER} >> %define VERSION %{version} >> Name: bind-dyndb-ldap >> -Version: 3.5 >> +Version: 4.0 >> Release: 1%{?dist} >> Summary: LDAP back-end plug-in for BIND >> Group: System Environment/Libraries >> License: GPLv2+ >> URL: https://fedorahosted.org/bind-dyndb-ldap >> Source0: >> https://fedorahosted.org/released/%{name}/%{name}-%{VERSION}.tar.bz2 >> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) >> -BuildRequires: bind-devel >= 32:9.6.1-0.3.b1 >> +BuildRequires: bind-devel >= 32:9.9.0-1, bind-lite-devel >= 32:9.9.0-1 >> BuildRequires: krb5-devel >> BuildRequires: openldap-devel >> BuildRequires: automake, autoconf, libtool >> -Requires: bind >= 32:9.6.1-0.3.b1 >> +Requires: bind >= 32:9.9.0-1 >> %description >> This package provides an LDAP back-end plug-in for BIND. It features >> >> @@ -41,25 +37,45 @@ >> >> make %{?_smp_mflags} >> %install >> rm -rf %{buildroot} >> make install DESTDIR=%{buildroot} >> +mkdir -m 770 -p %{buildroot}/%{_localstatedir}/named/dyndb-ldap >> # Remove unwanted files >> rm %{buildroot}%{_libdir}/bind/ldap.la >> rm -r %{buildroot}%{_datadir}/doc/%{name} >> +# SELinux boolean named_write_master_zones has to be enabled >> +# otherwise plugin will not be able to write to /var/named >> +%post >> +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then >> + echo "Enabling SELinux boolean named_write_master_zones" >> + /usr/sbin/setsebool -P named_write_master_zones=1 || true > > I think you should redirect all output from the setsebool to /dev/null > so it does not produce any output during the "yum install". The same > for the "echo" I'm not sure if it should be there, but I didn't find any > rule in packaging guidelines that is prohibiting you from doing so. I don't understand what is the point. I guess that it is an anachronism from old times when RPM have problems with that. If you don't insist (or find any rule about this) I will let the output as is. IMHO it is much much better to show to user what went wrong instead of telling just "post scriptlet failed". > It is also "common" to use ":" instead of "true" after OR, but this is > a cosmetic thing. Done. > > You can find more information (if you didn't already) here: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets > >> +fi >> + >> + >> +%postun >> +if [ "0$1" -eq "0" ] && [ -x "/usr/sbin/setsebool" ] ; then >> + echo "Disabling SELinux boolean named_write_master_zones" >> + /usr/sbin/setsebool -P named_write_master_zones=0 || true > > The same as above... > >> +fi >> + >> + >> %clean >> rm -rf %{buildroot} >> %files >> %defattr(-,root,root,-) >> %doc NEWS README COPYING doc/{example.ldif,schema} >> +%dir %attr(770, root, named) %{_localstatedir}/named/dyndb-ldap >> %{_libdir}/bind/ldap.so >> %changelog >> +* Wed Feb 19 2014 Petr Spacek 4.0-1 >> +- update to 4.0 >> + >> * Thu Jul 18 2013 Petr Spacek 3.5-1 >> - update to 3.5 >> -- >> >> 1.8.5.3 > > Regards, > > Tomas -- Petr^2 Spacek From amisnyov at redhat.com Fri Feb 21 11:11:01 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Fri, 21 Feb 2014 06:11:01 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <530724D8.8060503@redhat.com> References: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> <530724D8.8060503@redhat.com> Message-ID: <940530339.1630241.1392981061265.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jan Cholasta" > To: "Adam Misnyovszki" , freeipa-devel at redhat.com > Sent: Friday, February 21, 2014 11:05:12 AM > Subject: Re: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed > > Hi, > > On 20.2.2014 18:15, Adam Misnyovszki wrote: > > Hi, > > > > this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 > > maximum serial number field now accepts only positive numbers > > > > Thanks > > Adam > > I think you should also add maxvalue to min_serial_number, so that they > are consistent. > > Honza > > -- > Jan Cholasta > Makes sense, new patch added. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0004-2-Certificate-search-max_serial_number-problem-fixed.patch Type: text/x-patch Size: 1027 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 21 11:31:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 12:31:05 +0100 Subject: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes In-Reply-To: <530650E9.5070802@redhat.com> References: <038.1cba090b8bd39942646e9915d52008be@fedorahosted.org> <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> <53063FA3.9020703@redhat.com> <5306421A.6000801@redhat.com> <530650E9.5070802@redhat.com> Message-ID: <530738F9.6000509@redhat.com> On 02/20/2014 08:00 PM, Dmitri Pal wrote: > On 02/20/2014 12:57 PM, Petr Viktorin wrote: >> On 02/20/2014 06:47 PM, Dmitri Pal wrote: >>> On 02/20/2014 12:39 PM, freeipa wrote: >>>> #4185: Index plugin namespaces by classes >>>> -------------------------------------+------------------------------------- >>>> >>>> >>>> Reporter: pviktori | Owner: >>>> pviktori >>>> Type: refactoring | Status: new >>>> Priority: major | Milestone: 0.0 >>>> Component: IPA | NEEDS_TRIAGE >>>> Resolution: | Version: >>>> Blocked By: | Keywords: >>>> Affects Documentation: 0 | Blocking: >>>> Red Hat Bugzilla: | Patch posted for review: 0 >>>> Design link: | External tracker: >>>> Fedora test page: | Needs UI design: >>>> Source: | Feature: >>>> | Expertise: >>>> -------------------------------------+------------------------------------- >>>> >>>> >>>> Release Notes: >>>> >>>> >>>> -------------------------------------+------------------------------------- >>>> >>>> >>>> >>>> Comment (by pviktori): >>>> >>>> It's very easy to enable this so I'd like to do that now, and >>>> adapt the >>>> rest of the code whenever it's touched. >>>> >>> >>> Should it be captured in some guidelines somewhere on the wiki? >> >> I was planning to add some instructions to the [Refactorings] page, as >> I did with the new way to register plugins. >> I'm open to other suggestions. >> >> >> [Refactorings] http://www.freeipa.org/page/V3/Refactorings >> > If we have some do and do not's it should be similar to Style guide but > rather developer best practices guide. > > It should be a quick reference of: > do not do X do Y instead > > like do not treat DN as string - use DN class > ... > use this notation instead of that notation > etc. > > Then we can point people to it as part of the review process. > Aye sir! http://www.freeipa.org/page/Coding_Best_Practices Linked from http://www.freeipa.org/page/Contribute/Code#Change_the_code -- Petr? From thozza at redhat.com Fri Feb 21 11:54:44 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 21 Feb 2014 12:54:44 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <53073417.6050300@redhat.com> References: <53072058.3000500@redhat.com> <53072504.1070407@redhat.com> <53073417.6050300@redhat.com> Message-ID: <53073E84.3090104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/21/2014 12:10 PM, Petr Spacek wrote: > On 21.2.2014 11:05, Tomas Hozza wrote: >> On 02/21/2014 10:46 AM, Petr Spacek wrote: >>> I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found >>> that we >>> need to enable SELinux boolean named_write_master_zones otherwise the >>> plugin >>> will not be able to write journal files to /var/named. >>> >>> I have asked Miroslav Grepl for advice and his >>> recommendation is to use another context for our dyndb-ldap >>> sub-directory or >>> to enable named_write_master_zones. >>> >>> (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) >>> >>> I have decided to use more generic named_write_master_zones because >>> it will be >>> need for DNSSEC key management anyway. >>> >>> Miroslav told me that it is allowed to change SELinux booleans in RPM >>> scriptlets - it is normal operation - but that we have to disable the >>> boolean >>> during package un-installation. >>> >>> Please review %post and %postun sections in SPEC file. >>> >>> Thank you! >>> >>> -- Petr^2 Spacek >>> >>> >>> >>> From a7329ae3459a135eff2897d3de9da607280b4615 Mon Sep 17 00:00:00 2001 >>> From: Petr Spacek >>> Date: Fri, 21 Feb 2014 10:35:35 +0100 >>> Subject: [PATCH] Update to 4.0. >>> >>> Signed-off-by: Petr Spacek >>> --- >>> bind-dyndb-ldap.spec | 31 ++++++++++++++++++++++++------- >>> 1 file changed, 24 insertions(+), 7 deletions(-) >>> >>> ======================================= >>> >>> diff --git a/bind-dyndb-ldap.spec b/bind-dyndb-ldap.spec >>> index >>> 85b59e40035a35276ee0997764cdd976a8716df5..cbe6b7c76327a9df8e49d4acf925be8f9c1da29b >>> 100644 >>> >>> --- a/bind-dyndb-ldap.spec >>> >>> +++ b/bind-dyndb-ldap.spec >>> >>> @@ -1,26 +1,22 @@ >>> >>> -#%define PATCHVER P4 >>> -#%define PREVER 20121009git6a86b1 >>> -#%define VERSION %{version}-%{PATCHVER} >>> -#%define VERSION %{version}-%{PREVER} >>> %define VERSION %{version} >>> Name: bind-dyndb-ldap >>> -Version: 3.5 >>> +Version: 4.0 >>> Release: 1%{?dist} >>> Summary: LDAP back-end plug-in for BIND >>> Group: System Environment/Libraries >>> License: GPLv2+ >>> URL: https://fedorahosted.org/bind-dyndb-ldap >>> Source0: >>> https://fedorahosted.org/released/%{name}/%{name}-%{VERSION}.tar.bz2 >>> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} >>> -n) >>> -BuildRequires: bind-devel >= 32:9.6.1-0.3.b1 >>> +BuildRequires: bind-devel >= 32:9.9.0-1, bind-lite-devel >= 32:9.9.0-1 >>> BuildRequires: krb5-devel >>> BuildRequires: openldap-devel >>> BuildRequires: automake, autoconf, libtool >>> -Requires: bind >= 32:9.6.1-0.3.b1 >>> +Requires: bind >= 32:9.9.0-1 >>> %description >>> This package provides an LDAP back-end plug-in for BIND. It features >>> >>> @@ -41,25 +37,45 @@ >>> >>> make %{?_smp_mflags} >>> %install >>> rm -rf %{buildroot} >>> make install DESTDIR=%{buildroot} >>> +mkdir -m 770 -p %{buildroot}/%{_localstatedir}/named/dyndb-ldap >>> # Remove unwanted files >>> rm %{buildroot}%{_libdir}/bind/ldap.la >>> rm -r %{buildroot}%{_datadir}/doc/%{name} >>> +# SELinux boolean named_write_master_zones has to be enabled >>> +# otherwise plugin will not be able to write to /var/named >>> +%post >>> +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then >>> + echo "Enabling SELinux boolean named_write_master_zones" >>> + /usr/sbin/setsebool -P named_write_master_zones=1 || true >> >> I think you should redirect all output from the setsebool to /dev/null >> so it does not produce any output during the "yum install". The same >> for the "echo" I'm not sure if it should be there, but I didn't find any >> rule in packaging guidelines that is prohibiting you from doing so. > > I don't understand what is the point. I guess that it is an anachronism > from old times when RPM have problems with that. > > If you don't insist (or find any rule about this) I will let the output > as is. > > IMHO it is much much better to show to user what went wrong instead of > telling just "post scriptlet failed". I don't insist on this. However from my point of view at least the STDOUT should be discarded. You may leave the STDERR as is. Keep in mind that user using graphical installation tool will not see those outputs anyway. > > >> It is also "common" to use ":" instead of "true" after OR, but this is >> a cosmetic thing. > Done. > >> >> You can find more information (if you didn't already) here: >> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets >> >>> +fi >>> + >>> + >>> +%postun >>> +if [ "0$1" -eq "0" ] && [ -x "/usr/sbin/setsebool" ] ; then >>> + echo "Disabling SELinux boolean named_write_master_zones" >>> + /usr/sbin/setsebool -P named_write_master_zones=0 || true >> >> The same as above... >> >>> +fi >>> + >>> + >>> %clean >>> rm -rf %{buildroot} >>> %files >>> %defattr(-,root,root,-) >>> %doc NEWS README COPYING doc/{example.ldif,schema} >>> +%dir %attr(770, root, named) %{_localstatedir}/named/dyndb-ldap >>> %{_libdir}/bind/ldap.so >>> %changelog >>> +* Wed Feb 19 2014 Petr Spacek 4.0-1 >>> +- update to 4.0 >>> + >>> * Thu Jul 18 2013 Petr Spacek 3.5-1 >>> - update to 3.5 >>> -- >>> >>> 1.8.5.3 >> >> Regards, >> >> Tomas > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBz6EAAoJEMWIetUdnzwtFekH/An6s41BL9j3vfMpOJBbREKq 67vrxdWQlar8yc1iahpa3Fny4rJ5puFxJi4BhN3foxQhrcF8alLHukYOuk8zMIXl p9WnfXwMoxzflJb+7idHlkkKBNHl//AJ+Ej4TTL1ljwW34vjoBVVi4ag2Y23JfDU zAFOTXCZNDRWRChjmTO62UdZTM14E4RtUAcNzfyJly7bsQkaCCBBqKf+fHgfW3v+ DKgqPr8g6HuvbrNYY1kuNDF2uL5BRcHbWJh1DQ2yKQceGlljAO68Idf2s5dN6diW xFU8eFPkn+zwjd3nxSBFcbleTdc7NJn4xb+CFA052LSnq3yP2XTGOzyaYQtkQk4= =aqH2 -----END PGP SIGNATURE----- From thozza at redhat.com Fri Feb 21 12:02:23 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 21 Feb 2014 13:02:23 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <53073E84.3090104@redhat.com> References: <53072058.3000500@redhat.com> <53072504.1070407@redhat.com> <53073417.6050300@redhat.com> <53073E84.3090104@redhat.com> Message-ID: <5307404F.3030608@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/21/2014 12:54 PM, Tomas Hozza wrote: > On 02/21/2014 12:10 PM, Petr Spacek wrote: >> On 21.2.2014 11:05, Tomas Hozza wrote: >>> On 02/21/2014 10:46 AM, Petr Spacek wrote: >>>> I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found >>>> that we >>>> need to enable SELinux boolean named_write_master_zones otherwise the >>>> plugin >>>> will not be able to write journal files to /var/named. >>>> >>>> I have asked Miroslav Grepl for advice and his >>>> recommendation is to use another context for our dyndb-ldap >>>> sub-directory or >>>> to enable named_write_master_zones. >>>> >>>> (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) >>>> >>>> I have decided to use more generic named_write_master_zones because >>>> it will be >>>> need for DNSSEC key management anyway. >>>> >>>> Miroslav told me that it is allowed to change SELinux booleans in RPM >>>> scriptlets - it is normal operation - but that we have to disable the >>>> boolean >>>> during package un-installation. >>>> >>>> Please review %post and %postun sections in SPEC file. >>>> >>>> Thank you! >>>> >>>> -- Petr^2 Spacek >>>> >>>> >>>> >>>> From a7329ae3459a135eff2897d3de9da607280b4615 Mon Sep 17 00:00:00 2001 >>>> From: Petr Spacek >>>> Date: Fri, 21 Feb 2014 10:35:35 +0100 >>>> Subject: [PATCH] Update to 4.0. >>>> >>>> Signed-off-by: Petr Spacek >>>> --- >>>> bind-dyndb-ldap.spec | 31 ++++++++++++++++++++++++------- >>>> 1 file changed, 24 insertions(+), 7 deletions(-) >>>> >>>> ======================================= >>>> >>>> diff --git a/bind-dyndb-ldap.spec b/bind-dyndb-ldap.spec >>>> index >>>> 85b59e40035a35276ee0997764cdd976a8716df5..cbe6b7c76327a9df8e49d4acf925be8f9c1da29b >>>> 100644 >>>> >>>> --- a/bind-dyndb-ldap.spec >>>> >>>> +++ b/bind-dyndb-ldap.spec >>>> >>>> @@ -1,26 +1,22 @@ >>>> >>>> -#%define PATCHVER P4 >>>> -#%define PREVER 20121009git6a86b1 >>>> -#%define VERSION %{version}-%{PATCHVER} >>>> -#%define VERSION %{version}-%{PREVER} >>>> %define VERSION %{version} >>>> Name: bind-dyndb-ldap >>>> -Version: 3.5 >>>> +Version: 4.0 >>>> Release: 1%{?dist} >>>> Summary: LDAP back-end plug-in for BIND >>>> Group: System Environment/Libraries >>>> License: GPLv2+ >>>> URL: https://fedorahosted.org/bind-dyndb-ldap >>>> Source0: >>>> https://fedorahosted.org/released/%{name}/%{name}-%{VERSION}.tar.bz2 >>>> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} >>>> -n) >>>> -BuildRequires: bind-devel >= 32:9.6.1-0.3.b1 >>>> +BuildRequires: bind-devel >= 32:9.9.0-1, bind-lite-devel >= 32:9.9.0-1 >>>> BuildRequires: krb5-devel >>>> BuildRequires: openldap-devel >>>> BuildRequires: automake, autoconf, libtool >>>> -Requires: bind >= 32:9.6.1-0.3.b1 >>>> +Requires: bind >= 32:9.9.0-1 >>>> %description >>>> This package provides an LDAP back-end plug-in for BIND. It features >>>> >>>> @@ -41,25 +37,45 @@ >>>> >>>> make %{?_smp_mflags} >>>> %install >>>> rm -rf %{buildroot} >>>> make install DESTDIR=%{buildroot} >>>> +mkdir -m 770 -p %{buildroot}/%{_localstatedir}/named/dyndb-ldap >>>> # Remove unwanted files >>>> rm %{buildroot}%{_libdir}/bind/ldap.la >>>> rm -r %{buildroot}%{_datadir}/doc/%{name} >>>> +# SELinux boolean named_write_master_zones has to be enabled >>>> +# otherwise plugin will not be able to write to /var/named >>>> +%post >>>> +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then I just noticed that you are setting the SELinux option ONLY when installing the package. I think you want to set it also if updating the package from older version... So you should use "-ge" instead of "-eq". >>>> + echo "Enabling SELinux boolean named_write_master_zones" >>>> + /usr/sbin/setsebool -P named_write_master_zones=1 || true >>> >>> I think you should redirect all output from the setsebool to /dev/null >>> so it does not produce any output during the "yum install". The same >>> for the "echo" I'm not sure if it should be there, but I didn't find any >>> rule in packaging guidelines that is prohibiting you from doing so. > >> I don't understand what is the point. I guess that it is an anachronism >> from old times when RPM have problems with that. > >> If you don't insist (or find any rule about this) I will let the output >> as is. > >> IMHO it is much much better to show to user what went wrong instead of >> telling just "post scriptlet failed". > > I don't insist on this. However from my point of view at least the > STDOUT should be discarded. You may leave the STDERR as is. > > Keep in mind that user using graphical installation tool will not > see those outputs anyway. > > > >>> It is also "common" to use ":" instead of "true" after OR, but this is >>> a cosmetic thing. >> Done. > >>> >>> You can find more information (if you didn't already) here: >>> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets >>> >>>> +fi >>>> + >>>> + >>>> +%postun >>>> +if [ "0$1" -eq "0" ] && [ -x "/usr/sbin/setsebool" ] ; then >>>> + echo "Disabling SELinux boolean named_write_master_zones" >>>> + /usr/sbin/setsebool -P named_write_master_zones=0 || true >>> >>> The same as above... >>> >>>> +fi >>>> + >>>> + >>>> %clean >>>> rm -rf %{buildroot} >>>> %files >>>> %defattr(-,root,root,-) >>>> %doc NEWS README COPYING doc/{example.ldif,schema} >>>> +%dir %attr(770, root, named) %{_localstatedir}/named/dyndb-ldap >>>> %{_libdir}/bind/ldap.so >>>> %changelog >>>> +* Wed Feb 19 2014 Petr Spacek 4.0-1 >>>> +- update to 4.0 >>>> + >>>> * Thu Jul 18 2013 Petr Spacek 3.5-1 >>>> - update to 3.5 >>>> -- >>>> >>>> 1.8.5.3 >>> >>> Regards, >>> >>> Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTB0BOAAoJEMWIetUdnzwtPHoH/j8fLJTWeiPWUDINyuJFZ9rz 3aucl5q3w0gxZlMl1E7Lg2J0/Jd/7f8VCfxeDDHSu1Tyo26e7VnGOZiq7joXRsXj bPZat5iFpI8aFRFvDBqzDz4b1PS9FMOViKlQV6a6RCHSWJWDvvcoL+PO79d1lOGd 53xzTy33nq23yggophr5PuGN2ZMF+lG6M+VhBC6zkSAIKR/GYtxKf7PS1evZp9og Z8F9brless1pqFQ5m4wFNclMggAd0127OzjCWcYWTGeTGsBHY/8pAtVrlUL3ZY8d pJMHCNCir43595OeLYSO/NUAZfxHRlGZOXhycXBLEsEawBlPp5PBhVUax9jbKcY= =ejAk -----END PGP SIGNATURE----- From pspacek at redhat.com Fri Feb 21 12:08:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:08:16 +0100 Subject: [Freeipa-devel] [PATCH 0183] Move data structures for parser from ldap_qresult_t to ldap_entry_t In-Reply-To: <5252B533.1090100@redhat.com> References: <51FA6782.6060601@redhat.com> <5252B533.1090100@redhat.com> Message-ID: <53073BD9.2030103@redhat.com> On 7.10.2013 15:20, Tomas Hozza wrote: > On 08/01/2013 03:49 PM, Petr Spacek wrote: >> Hello, >> >> Move data structures for parser from ldap_qresult_t to ldap_entry_t. >> >> >> The target branch is master. >> > > ACK. > > Tested Patch bundle 181 - 185. Common tasks like > adding/deleting/updating records work fine. Also PTR sync, zone serial > number > incrementation is OK. Pushed to v3 and master branch: f9db18e7074f8938245b90d4a00774cbc07e261b -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:08:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:08:10 +0100 Subject: [Freeipa-devel] [PATCH 0185] Do not execute new LDAP search for each updated object In-Reply-To: <51FA6837.60103@redhat.com> References: <51FA6837.60103@redhat.com> Message-ID: <53073C1B.50308@redhat.com> On 1.8.2013 15:52, Petr Spacek wrote: > Hello, > > Do not execute new LDAP search for each updated object. > > Syncrepl delivers notification about change in particular object > along with all data from the object. Resource Records are parsed out > from this data instead of data obtained via separate LDAP search. > > Current code doesn't have any rate limitation. As a result, > ldap_sync_init/poll() can enqueue update events faster than rest of BIND > is able to dequeue and process them. Unprocessed events can consume > significant amount of memory. This area definitely needs improvement. > > > This is next in complete transition to RBTDB. It should go to master. Pushed to master branch: fed8f393980b14f57b2a19cd8f4c0645e8151747 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:08:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:08:01 +0100 Subject: [Freeipa-devel] [PATCH 0184] Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition In-Reply-To: <51FA67D0.4040103@redhat.com> References: <51FA67D0.4040103@redhat.com> Message-ID: <53073BF3.3090502@redhat.com> On 1.8.2013 15:51, Petr Spacek wrote: > Hello, > > Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition. > > > This minor fix could go to v3 and master. Pushed to v3 and master branch: ad4beb6968114eb85c639772050b54dbab53ba7f -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:04:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:04:51 +0100 Subject: [Freeipa-devel] [PATCH 0220] Move temporary files to /var/named/dyndb-ldap directory In-Reply-To: <1392741526.12450.19.camel@localhost.localdomain> References: <52E7D0A6.7030300@redhat.com> <530320B2.8050701@redhat.com> <1392741526.12450.19.camel@localhost.localdomain> Message-ID: <530740E3.3030607@redhat.com> On 18.2.2014 17:38, Nathaniel McCallum wrote: > On Tue, 2014-02-18 at 09:58 +0100, Petr Spacek wrote: >> On 28.1.2014 16:45, Petr Spacek wrote: >>> Hello, >>> >>> Move temporary files to /var/named/dyndb-ldap directory. >>> >>> This should make RPM packaging easier. >>> >>> This patch should go to master branch before 4.0 release. >> >> This version fixes packaging problems found by Tomas Hozza. > > ACK Pushed to master branch: 88d89bb9c6941321b57dadb59403c4cf975a2165 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:04:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:04:11 +0100 Subject: [Freeipa-devel] [PATCH 0221] Make getcwd() calls safer In-Reply-To: <53035E8E.2000509@redhat.com> References: <53032928.7070107@redhat.com> <53035E8E.2000509@redhat.com> Message-ID: <530740BB.8070200@redhat.com> On 18.2.2014 14:22, Tomas Hozza wrote: > On 02/18/2014 10:34 AM, Petr Spacek wrote: >> ewer GCC complains that I didn't check return value from getcwd() ... > > Hi. > > I reviewed all patches from "PATCH 0181" to the latest one "PATCH 0221" > and tested the bind-dyndb-ldap on Fedora 20 (adding/removing > records/zones using FreeIPA WebUI, resolving using dig, AXFR, IXFR, > adding/removing Dynamic UPDATES). > > I didn't encounter any issues other than documented in "Known problems > and limitations" section of NEWS file. > > So I finally ACK all of these patches... :) Pushed to master branch: 457b7f4bc4d9e9a80731e502f22b3f5506fb5180 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:03:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:03:28 +0100 Subject: [Freeipa-devel] [PATCH 0219] Prevent crash if working directory for zone cannot be created In-Reply-To: <52E7CECB.1090609@redhat.com> References: <52E7CECB.1090609@redhat.com> Message-ID: <53074090.7070605@redhat.com> On 28.1.2014 16:37, Petr Spacek wrote: > Hello, > > Prevent crash if working directory for zone cannot be created. > > This patch should go to master branch before 4.0 release. Pushed to master branch: a2c5b89e46f556555dc82e42a754e0c2c4102dd6 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:02:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:02:53 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix warning duplicate 'const' declaration specifier In-Reply-To: <52D946E3.8060805@redhat.com> References: <20131030082131.GA32671@mail.corp.redhat.com> <52D946E3.8060805@redhat.com> Message-ID: <5307406D.3010004@redhat.com> On 17.1.2014 16:06, Tomas Hozza wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/30/2013 09:21 AM, Lukas Slebodnik wrote: >> ehlo, >> >> There were few warnings in bind-dyndb-ldap "duplicate 'const' declaration >> specifier". >> >> It does not make sense to have const twice in declaration >> like a "const settings_set_t const settings_default_set" >> This one was false positive. >> >> The 2nd warning revealed potential problem. >> const char const * dns_str >> With previous declaration, you cannot modify data, but you can modify >> pointer itself. >> *dns_str = "asdasd" //compilation error >> dns_str++ //works fine >> >> If you want to disable modification data and disable modification of pointer >> you will need to have 2nd const modifier after star "*" >> >> You can find some examples of "const" usage in attached file test.c or >> you can read article with explanation of next declaration >> "char *(*(**foo [][8])())[];" >> http://eli.thegreenplace.net/2008/07/18/reading-c-type-declarations/ >> >> Simple patch is attached. >> >> LS >> > > ACK. > > Looks good. Pushed to v3 and master branch: b39142b9d75ac296662b42d7efd98475d2bd7608 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:01:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:01:06 +0100 Subject: [Freeipa-devel] [PATCH 0217] Cleanup zone and journal files on LDAP reconnect In-Reply-To: <52AB39B9.4090201@redhat.com> References: <52AB39B9.4090201@redhat.com> Message-ID: <53073FDF.1010002@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Cleanup zone and journal files on LDAP reconnect. > > This cleanup solves potential inconsistencies between order > of operations in LDAP and order of operations recorded in journal. > > This patch should go to master branch. Pushed to master branch: 53aca706731337d7f84ca9d5f8ea15a1523729f8 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:00:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:00:54 +0100 Subject: [Freeipa-devel] [PATCH 0218] Limit number of unprocessed syncrepl events in queue to 100 In-Reply-To: <52CC4937.5060309@redhat.com> References: <52CC4937.5060309@redhat.com> Message-ID: <53073FF6.50103@redhat.com> On 7.1.2014 19:36, Petr Spacek wrote: > Hello, > > Limit number of unprocessed syncrepl events in queue to 100. > > All syncrepl events are processed sequentialy. This patch limits > memory consumption in cases where the LDAP server is sending > syncrepl events too quickly. > > LDAP client library should handle this situation so no events > will be lost. > > > This patch should go to the head of future master branch (rbtdb.v22). Pushed to master branch: d173eabf49b15025770b6a441a235b19b036e719 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:00:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:00:02 +0100 Subject: [Freeipa-devel] [PATCH 0215] Update NEWS for upcoming 3.6 release In-Reply-To: <52AB39AD.7010601@redhat.com> References: <52AB39AD.7010601@redhat.com> Message-ID: <53073F96.2070305@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Update NEWS for upcoming 3.6 release. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 775cad18a63c973a7c437c988fc82087643fa54e -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:59:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:59:49 +0100 Subject: [Freeipa-devel] [PATCH 0216] Bump NVR to 3.6 In-Reply-To: <52AB39B2.90506@redhat.com> References: <52AB39B2.90506@redhat.com> Message-ID: <53073FB5.1080007@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Bump NVR to 3.6. > > BIND 9.9.0 is required. > > Tomas, shouldn't I use > Requires: bind >= 32:9.9.0-1 > ? > > This patch should go to branches v3 and master. Pushed to v3 and master branch: a6d7aee2af0c410aeeb51d4295fbb17798661f63 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:59:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:59:02 +0100 Subject: [Freeipa-devel] [PATCH 0214] Make ldap_parse_rrentry() idempotent In-Reply-To: <52AB39A9.6090501@redhat.com> References: <52AB39A9.6090501@redhat.com> Message-ID: <53073F86.5030704@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Make ldap_parse_rrentry() idempotent. > > Now, a call to ldap_parse_rrentry() resets the internal entry > interators in ldap_entry_t so the results are always correct. > > Without this patch, a second call returned empty ldapdb_rdatalist_t > because all iterators were at the end of internal lists. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 60ff493fe21e24004f7f32c27055905b5a59d665 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:58:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:58:42 +0100 Subject: [Freeipa-devel] [PATCH 0213] Fix crash caused by invalid data in SOA record In-Reply-To: <52AB39A6.8040604@redhat.com> References: <52AB39A6.8040604@redhat.com> Message-ID: <53073F72.2000703@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Fix crash caused by invalid data in SOA record. > > E.g. try to put '\0' to the idnsSOAmName attribute... > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 6da35665011aa7e9ad9567b5ea098c998e846630 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:58:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:58:26 +0100 Subject: [Freeipa-devel] [PATCH 0212] Remove unused parameter attrlist from ldap_entry_nextattr() In-Reply-To: <52AB39A4.4050107@redhat.com> References: <52AB39A4.4050107@redhat.com> Message-ID: <53073F62.8030102@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Remove unused parameter attrlist from ldap_entry_nextattr(). > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 03620d3a448149ff0dc4c75e12b06d896af52a1a -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:58:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:58:06 +0100 Subject: [Freeipa-devel] [PATCH 0211] Improve error handling in code for LDAP modification In-Reply-To: <52AB39A1.3070905@redhat.com> References: <52AB39A1.3070905@redhat.com> Message-ID: <53073F4E.8060901@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Improve error handling in code for LDAP modification. > > Failed LDAP modification is retried once. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: b19977b11455e771250f5f5d61f3cb4d6afe1fbf -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:57:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:57:46 +0100 Subject: [Freeipa-devel] [PATCH 0210] Add missing default branches to switch statemets In-Reply-To: <52AB399F.9020702@redhat.com> References: <52AB399F.9020702@redhat.com> Message-ID: <53073F3A.6000705@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Add missing default branches to switch statemets. > > This should help little bit with uninitialized memory usage. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: ce14966943de2b5e2f577cc5130c511edb132a7c -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:57:25 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:57:25 +0100 Subject: [Freeipa-devel] [PATCH 0209] Silence GCC warnings produced by -Wjump-misses-init In-Reply-To: <52AB399C.8020204@redhat.com> References: <52AB399C.8020204@redhat.com> Message-ID: <53073F25.60307@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Silence GCC warnings produced by -Wjump-misses-init. > > It seems that it is false alarm in our case. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 2471ce0b3c0682a65237965188e79c46fa4228ac -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:56:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:56:58 +0100 Subject: [Freeipa-devel] [PATCH 0208] Remove local variables which shadow variables from a upper level In-Reply-To: <52AB3999.6090502@redhat.com> References: <52AB3999.6090502@redhat.com> Message-ID: <53073F0A.3040602@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > Hello, > > Remove local variables which shadow variables from a upper level. > > This patch should go to branches v3 and master. Pushed to v3 and master branch: 618b3a8c9a6c808f72d9121b6da27ac1e611a382 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:56:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:56:12 +0100 Subject: [Freeipa-devel] [PATCH 0207] Do not load invalid zones In-Reply-To: <52AB3992.9050507@redhat.com> References: <52961103.1020101@redhat.com> <52AB3992.9050507@redhat.com> Message-ID: <53073EDC.6040802@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > On 27.11.2013 16:34, Petr Spacek wrote: >> Hello, >> >> Do not load invalid zones. >> >> Without this patch, it was possible to load an invalid zone without >> proper SOA or NS records because the fake SOA and NS records allowed >> checks in dns_zone_load() to pass. >> >> With this patch, no fake SOA or NS records are created and >> dns_zone_load() is not called before end of the initial synchronization. >> >> See the function ldapdb_associate() in ldap_driver.c and it's comments. > > Patch 207 v2 fixes reconnecting to LDAP. > > dns_db_detachnode() call in update_record() function was moved to the cleanup > section - this is workaround for ISC bug #35080. > > This patch should go to master branch. Pushed to master branch: e39df82aaf12746525d5a53ebc638aa4c07fcb4a -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:55:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:55:51 +0100 Subject: [Freeipa-devel] [PATCH 0206] Publish zones only after all LDAP events have been processed In-Reply-To: <52AB398E.7000806@redhat.com> References: <52824464.2070503@redhat.com> <52AB398E.7000806@redhat.com> Message-ID: <53073EC7.6040101@redhat.com> On 13.12.2013 17:45, Petr Spacek wrote: > On 12.11.2013 16:08, Petr Spacek wrote: >> Hello, >> >> Publish zones only after all LDAP events have been processed. >> >> Zones are not exposed in _default DNS view until all events >> generated before LDAP intermediate message have been processed. >> >> This prevents BIND from returning NXDOMAIN for some names from >> a zone but NOERROR answers for other names in the same zone. >> It would be pretty confusing and not easy to debug. > > I'm attaching rebased patch. > > This patch should go to master branch. Pushed to master branch: 91535a635cf6bdb5e6864d0549970fb1a34ea59b -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:55:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:55:33 +0100 Subject: [Freeipa-devel] [PATCH 0205] Fix race condition during write to internal RBTDB In-Reply-To: <52AB398B.4030008@redhat.com> References: <5280C794.3060503@redhat.com> <52AB398B.4030008@redhat.com> Message-ID: <53073EB5.5000904@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 11.11.2013 13:03, Petr Spacek wrote: >> Hello, >> >> Fix race condition during write to internal RBTDB. >> >> RBTDB implementation allows to open only one RBTDB instance >> for writing at the same time. This patch adds mutex to >> newversion() implementation in ldap_driver.c. >> >> See comments around ldapdb_t, newversion() and closeversion(). > > I'm attaching rebased patch. > > This patch should go to master branch. Pushed to master branch: 90df1289c9dc4a61c6b5d0a852947699a0db23ad -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:54:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:54:43 +0100 Subject: [Freeipa-devel] [PATCH 0202-0203] Improve performance of initial LDAP synchronizationDetect end of initial LDAP synchronization phase In-Reply-To: <52AB3984.8010005@redhat.com> References: <5273AD7D.5020402@redhat.com> <1939839260.12480070.1383650984710.JavaMail.root@redhat.com> <5282458B.4000808@redhat.com> <52AB3984.8010005@redhat.com> Message-ID: <53073E83.9040709@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 12.11.2013 16:13, Petr Spacek wrote: >> On 5.11.2013 12:29, Tomas Hozza wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> Improve performance of initial LDAP synchronization. >>>> >>>> Changes are not journaled and SOA serial is not incremented during initial >>>> LDAP synchronization. >>>> >>>> This eliminates unnecessary synchronous writes to journal and also >>>> unnecessary SOA serial writes to LDAP. >>>> >>>> See commit messages and comments in syncrepl.c for all the gory details. >>> >>> >>> ACK. >>> >>> Patches look good. AXFR and IXFR works as expected. Also BIND starts up much >>> faster with these patches. Good job... :) >>> >>> Regards, >>> >>> Tomas >> >> Hmm, further testing revealed that patch 203 changed behavior little bit: >> Zones were loaded from LDAP correctly, but the SOA serial wasn't changed at >> all. As a result, zone transfers return inconsistent results if the data in >> LDAP are changed when BIND was not running. >> >> Patch 203-v2 imitates the old behavior from bind-dyndb-ldap 3.x: Zone serial >> is bumped *once* for each zone, so any changed in LDAP will be transferred >> correctly (with new serial). > > Patch 202 v2 was rebased and fixes reconnection to LDAP and solves deadlock > caused by too eager locking. > > Patch 203 v3 was rebased and fixes reconnection to LDAP. > > These patches should go to master branch. Pushed to master branch: 218af8258536bcbe9aad515dcefa82ae671e1ddf 0c4b7584da340d80c5c64b238256d8616d0d85ba -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:53:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:53:38 +0100 Subject: [Freeipa-devel] [PATCH 0201] Report error if RFC 4533 initialization failed In-Reply-To: <52AB397C.4070901@redhat.com> References: <5267E7CF.2000202@redhat.com> <526927E7.9060404@redhat.com> <52AB397C.4070901@redhat.com> Message-ID: <53073E42.4060209@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 24.10.2013 16:00, Tomas Hozza wrote: >> On 10/23/2013 05:14 PM, Petr Spacek wrote: >>> Hello, >>> >>> this patch belongs to 4.0 release. It allows the user to catch some >>> mis-configurations. >>> >>> It produces error messages like this: >>> LDAP error: Critical extension is unavailable: unable to start SyncRepl >>> session: is RFC 4533 supported on LDAP server? > > Patch 201 v2 was rebased and modified. > > Now the code prints an error and continues to re-try as usual instead of > killing BIND. Shutdown in early stages of start-up had various strange effects > including assertion failures. > > This patch should go only to master branch. Pushed to master branch: e1a6d6f7d7de82fe02a6d97b6e23b9c911f7eb91 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:52:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:52:43 +0100 Subject: [Freeipa-devel] [PATCH 0197-0200] Preparation for bind-dyndb-ldap release 4.0 In-Reply-To: <52AB3974.3030605@redhat.com> References: <5257FEB1.6020306@redhat.com> <5267E768.1020709@redhat.com> <52AB3974.3030605@redhat.com> Message-ID: <53073E0B.4060504@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 23.10.2013 17:12, Tomas Hozza wrote: >> On 10/11/2013 03:35 PM, Petr Spacek wrote: >>> Hello, >>> >>> update documentation and schema files for upcoming version 4.0. >>> >>> This fixes typo in schema file: >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/121 >>> >>> Have a nice weekend! > > I updated NEWS file in patch 199 v2, other files are only rebased. > > Patch 198 should go to v3 and master branch, other patches should go only to > master branch. Pushed to v3 and master branch: 7e0bb627d591171f2095578fccc743027d1863bc Pushed to master branch: c7aa0d576baecc2073904c80b34420e1f982bf78 2f1b8f7d79d2a96d695e8839e5a87b3c9dd9ab48 06d8701ed44a0a17c2fd78917054c307e01c58b8 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:50:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:50:45 +0100 Subject: [Freeipa-devel] [PATCH 0192-0196] Write all changes to journal In-Reply-To: <52AB3970.10003@redhat.com> References: <5256DE40.4060000@redhat.com> <5267E748.5000800@redhat.com> <5267E94E.1050001@redhat.com> <52AB3970.10003@redhat.com> Message-ID: <53073D95.1070400@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 23.10.2013 17:20, Petr Spacek wrote: >> On 23.10.2013 17:12, Tomas Hozza wrote: >>> On 10/10/2013 07:05 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> this patch set adds journaling to bind-dyndb-ldap. >>>> >>>> Journaling requires proper SOA serial maintenance, so from now >>>> SOA serial auto-incrementation is mandatory. >>>> >>>> Journal file is deleted on each start, so IXFR is limited to time frame >>>> from last BIND start. >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/64 >>>> >>>> >>>> You can use my personal branch for testing: >>>> https://github.com/spacekpe/bind-dyndb-ldap/tree/rbtdb.v7 >>>> >>>> It contains all unpushed patches. Basically, next master should be identical >>>> to this branch. >>>> >>>> Thank you for your time! >>>> >>>> -- Petr^2 Spacek >>> >>> ACK. >>> >>> IXFR works as should. Also tested that journal is cleared after BIND >>> restart, so server responds with AXFR. >>> >>> Patches look good, I have only one small thing to patch 0193: >>> >>>> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >>>> index >>>> 0786979a1970f4b61ac5b92dd5554bf87032d1ff..89acbe610519bbe0610a07d5fa5d4ffceddc71cd >>>> >>>> 100644 >>>> >>>> --- a/src/ldap_helper.c >>>> >>>> +++ b/src/ldap_helper.c >>>> >>>> ... >>>> >>>> @@ -1401,7 +1405,155 @@ >>>> >>>> cleanup: >>>> return result; >>>> } >>>> +/** >>>> + * Process strictly minimal diff and detect if data were changed >>>> + * and return latest SOA RR. >>>> + * >>>> + * @pre Input diff has to be minimal, i.e. it can't contain DEL & ADD >>>> operation >>>> + * for the same data under the same name and TTL. >>>> + * >>>> + * @pre If the tuple list contains SOA RR, then exactly one SOA RR >>>> deletion >>>> + * has to precede exactly one SOA RR addition. >>>> + * (Each SOA RR deletion has to have matching addition.) >>>> + * >>>> + * @param[in] diff Input diff. List of tuples can be empty. >>>> + * @param[out] soa_latest Pointer to last added SOA RR from tuple list. >>>> + * Result can be NULL if there is no added SOA RR >>>> + * in the tuple list. >>>> + * @param[out] data_changed ISC_TRUE if any data other than SOA serial >>>> were >>>> + * changed. ISC_FALSE if nothing (except SOA >>>> + * serial) was changed. >>>> + * >>>> + */ >>>> +static isc_result_t ATTR_NONNULLS >>>> +diff_analyze_serial(dns_diff_t *diff, dns_difftuple_t **soa_latest, >>>> + isc_boolean_t *data_changed) { >>>> + dns_difftuple_t *t = NULL; >>>> + dns_rdata_t *del_soa = NULL; /* last seen SOA with op == DEL */ >>>> + dns_difftuple_t *tmp_tuple = NULL; /* tuple used for SOA comparison */ >>>> + isc_result_t result = ISC_R_SUCCESS; >>>> + int ret; >>>> + >>>> + REQUIRE(DNS_DIFF_VALID(diff)); >>>> + REQUIRE(soa_latest != NULL && *soa_latest == NULL); >>>> + REQUIRE(data_changed != NULL); >>>> + >>>> + *data_changed = ISC_FALSE; >>>> + for (t = HEAD(diff->tuples); >>>> + t != NULL; >>>> + t = NEXT(t, link)) { >>>> + INSIST(tmp_tuple == NULL); >>> after this ^^^ line tmp_tuple is NULL in the current for loop cycle. >>>> + if (t->rdata.type != dns_rdatatype_soa) >>>> + *data_changed = ISC_TRUE; >>>> + else { /* SOA is always special case */ >>>> + if (t->op == DNS_DIFFOP_DEL || >>>> + t->op == DNS_DIFFOP_DELRESIGN) { >>>> + /* delete operation has to precede add */ >>>> + INSIST(del_soa == NULL); >>>> + INSIST(tmp_tuple == NULL); >>> so this ^^^ check is duplicit >>>> + del_soa = &t->rdata; >>>> + } else if (t->op == DNS_DIFFOP_ADD || >>>> + t->op == DNS_DIFFOP_ADDRESIGN) { >>>> + /* add operation has to follow a delete */ >>>> + INSIST(del_soa != NULL); >>>> + INSIST(tmp_tuple == NULL); >>> and also this ^^^ check is duplicit >>>> + *soa_latest = t; >>>> + >>>> + /* detect if fields other than serial >>>> + * were changed (compute only if necessary) */ >>>> + if (*data_changed == ISC_FALSE) { >>>> + CHECK(dns_difftuple_copy(t, &tmp_tuple)); >>>> + dns_soa_setserial(dns_soa_getserial(del_soa), >>>> + &tmp_tuple->rdata); >>>> + ret = dns_rdata_compare(del_soa, >>>> + &tmp_tuple->rdata); >>>> + *data_changed = ISC_TF(ret != 0); >>>> + } >>>> + if (tmp_tuple != NULL) >>>> + dns_difftuple_free(&tmp_tuple); >>>> + /* re-start the SOA delete-add search cycle */ >>>> + del_soa = NULL; >>>> + } else { >>>> + INSIST("unexpected diff: op != ADD || DEL" >>>> + == NULL); >>>> + } >>>> + } >>>> + } >>>> + /* SOA deletions & additions has to create self-contained couples */ >>>> + INSIST(del_soa == NULL && tmp_tuple == NULL); >>>> + >>>> +cleanup: >>>> + if (tmp_tuple != NULL) >>>> + dns_difftuple_free(&tmp_tuple); >>>> + return result; >>>> +} >>>> + >>>> ... >>> >>> Sorry for the formatting, obviously my email client is not perfect. >>> Hope you can understand it... >> >> I will fix it before push. > > Patch 192 was unchanged. > > Patch 193 v2 > - redundant INSIST calls were removed > - patch was rebased > > Patch 194 v2 > - copyright header was fixed > > Patch 196 v2 > - README was updated > - missing header dns/journal.h was added > - fixes in error handling: journal is correctly closed as necessary > - patch was rebased Pushed to master branch: 08e3b9deb31a060c85bba69539b68916181895d4 d881f7395c592f57589d049fb2733416f266dc3a 211954a5c6ce1e5cbf99520cb8b97a49000acfc3 29563e6b09459b9d4e2e65cc512a022d56a711ce 76bc77f0b0318590424e0c997528b742d888768e -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:48:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:48:34 +0100 Subject: [Freeipa-devel] [PATCH 0181] Replace LDAP persistent search with syncrepl (RFC 4533) In-Reply-To: <52AB3966.9050205@redhat.com> References: <51ED1647.5020805@redhat.com> <51ED3091.8050003@redhat.com> <5252B4CC.3000407@redhat.com> <52AB3966.9050205@redhat.com> Message-ID: <53073D12.4000108@redhat.com> On 13.12.2013 17:44, Petr Spacek wrote: > On 7.10.2013 15:19, Tomas Hozza wrote: >> On 07/22/2013 03:16 PM, Petr Spacek wrote: >>> On 22.7.2013 13:23, Petr Spacek wrote: >>>> Hello, >>>> >>>> Replace LDAP persistent search with syncrepl (RFC 4533). >>>> >>>> All direct operations with LDAP Persistent Search control are replaced >>>> by ldap_sync_* calls. >>>> >>>> Syncrepl code works in exactly same way as old psearch code: >>>> Only the DN of the modified object is re-used from the message, >>>> data from the object are fetched via separate LDAP search. >>>> >>>> Current code is not able to detect object renaming because we don't have >>>> UUID->DN mapping yet. >>>> >>>> Another limitation is that current code can't detect unchanged entries, >>>> so serial is incremented after each parsed LDAP object. >>> >>> Clang noticed potential NULL dereference in cleanup section of >>> ldap_syncrepl_watcher(). Fixed patch is attached. >>> >> >> ACK. >> >> Tested Patch bundle 181 - 185. Common tasks like >> adding/deleting/updating records work fine. Also PTR sync, zone serial >> number >> incrementation is OK. > > I have found that patch 181-2 doesn't handle reconnection to LDAP. > > This new version should handle reconnections better. > > This patch should go to master branch only. > > > It is known limitation that zones and records deleted when connection is down > are not refreshed properly after reconnection. This will be fixed some future > version. > > I use this command for testing: > socat tcp-listen:3899,fork,reuseaddr tcp-connect:localhost:389 > > It is necessary to modify port in /etc/named.conf to connect via socat. Then I > can kill & restart socat to simulate connection breakage. Pushed to master branch: 9c8aa4fb7d798015d8f889a008b5807b73c55341 -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 11:46:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 12:46:14 +0100 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <52AB218E.9050601@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> <524BFBFD.1000901@redhat.com> <5253D7A0.2020108@redhat.com> <5256DCBC.3070901@redhat.com> <5267E30E.4010401@redhat.com> <52AB218E.9050601@redhat.com> Message-ID: <53073C86.3030103@redhat.com> On 13.12.2013 16:02, Petr Spacek wrote: > On 23.10.2013 16:54, Tomas Hozza wrote: >> On 10/10/2013 06:58 PM, Petr Spacek wrote: >>> On 8.10.2013 12:00, Tomas Hozza wrote: >>>> On 10/02/2013 12:57 PM, Petr Spacek wrote: >>>>> On 13.9.2013 15:31, Petr Spacek wrote: >>>>>> On 14.8.2013 16:42, Petr Spacek wrote: >>>>>>> On 14.8.2013 16:25, Petr Spacek wrote: >>>>>>>> On 1.8.2013 15:57, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> attached monster patches replace our internal cache/database with >>>>>>>>> RBTDB >>>>>>>>> implementation. See commit messages and comments inside. >>>>>>>>> >>>>>>>>> This patch set provides very basic functionality (including DNS >>>>>>>>> support for >>>>>>>>> updates). Error handling definitely needs more love, but it should >>>>>>>>> be enough >>>>>>>>> for rapid DNSSEC prototyping. >>>>>>>> >>>>>>>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>>>>>>> in-memory database. Commit message was modified to mention that >>>>>>>> wildcards are >>>>>>>> now supported. >>>>>>>> >>>>>>>> Patch 187 v2: The code was re-worked and now it respects >>>>>>>> serial_autoincrement >>>>>>>> option. >>>>>>>> >>>>>>>> Patch 188 v2: Minor comment clean-up and rebase on top of patch >>>>>>>> 187 v2. >>>>>>>> >>>>>>>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() >>>>>>>> was >>>>>>>> deleted. This code was meant only for testing purposes. >>>>>>>> >>>>>>>> These patch set is now ready for review. Please see commit messages! >>>>>>>> Some >>>>>>>> functionality is missing intentionally, but it will be fixed by >>>>>>>> separate >>>>>>>> patches. >>>>>>> >>>>>>> It would be too easy! >>>>>>> >>>>>>> Patch 186 v3: Commit message was extended with information that LDAP >>>>>>> MODRDN >>>>>>> operation is not supported at the moment. >>>>>>> >>>>>>> Patch 187 v3: Missing file ldap_driver.h was added. >>>>>> >>>>>> This extended patch set handles correctly object deletion from LDAP. >>>>>> >>>>>> Patches 186-189 contain very minor changes, only moving code from one >>>>>> place to >>>>>> the other. >>>>>> >>>>>> See commit messages for patches 190 and 191. >>>>>> >>>>>> This should be testable. I would recommend to test the whole patch >>>>>> set at >>>>>> once, most probably it doesn't make much sense to test patches >>>>>> separately. >>>>> >>>>> bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch >>>>> >>>>> >>>>> adds missing missing include (db.h) to zone_register.c. >>>>> >>>> >>>> ACK. >>>> >>>> Patches 186-191 tested. Adding/removing/modifying records works fine. >>>> Also PTR synchronization works. Zone transfer to slave and NOTIFY >>>> tested when changes occurred on master. >>> >>> Patch 191-2 fixed problem with zone removal and race condition during >>> zone load. I would recommend you to test it with other patch I plan to >>> send today :-) >>> >> >> ACK. >> >> Patch looks good. > > Changes in patch 186 v6: > - README was updated > - update_record() events is terminated sooner in case of BIND shutdown > -- This prevents some nasty surprises during shutdown. > - Crash in update_record() was fixed: > E.g. imagine a zone in LDAP without A record record for name in NS record. > update_record() is restarted after any modification to invalid zone. This > allows us to reload previously invalid zone if e.g. the missing A record was > added. Version 5 of the patch crashed in this situation. > > This patch should go to master branch only. Pushed to master branch: a78db0312873babbccd4a94dec90b46b02c694ad 4a6b8caa6bff4f9c33411c5d72aafb04ceb5396c f6e74da2e27803d9b8a8e3fd399aa26b901ab932 827c8d676e3a871010e63eda82997a2f729a347c -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 12:37:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:37:56 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <5307404F.3030608@redhat.com> References: <53072058.3000500@redhat.com> <53072504.1070407@redhat.com> <53073417.6050300@redhat.com> <53073E84.3090104@redhat.com> <5307404F.3030608@redhat.com> Message-ID: <530748A4.7090309@redhat.com> On 21.2.2014 13:02, Tomas Hozza wrote: > On 02/21/2014 12:54 PM, Tomas Hozza wrote: >> On 02/21/2014 12:10 PM, Petr Spacek wrote: >>> On 21.2.2014 11:05, Tomas Hozza wrote: >>>> On 02/21/2014 10:46 AM, Petr Spacek wrote: >>>>> I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found >>>>> that we >>>>> need to enable SELinux boolean named_write_master_zones otherwise the >>>>> plugin >>>>> will not be able to write journal files to /var/named. >>>>> >>>>> I have asked Miroslav Grepl for advice and his >>>>> recommendation is to use another context for our dyndb-ldap >>>>> sub-directory or >>>>> to enable named_write_master_zones. >>>>> >>>>> (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) >>>>> >>>>> I have decided to use more generic named_write_master_zones because >>>>> it will be >>>>> need for DNSSEC key management anyway. >>>>> >>>>> Miroslav told me that it is allowed to change SELinux booleans in RPM >>>>> scriptlets - it is normal operation - but that we have to disable the >>>>> boolean >>>>> during package un-installation. >>>>> >>>>> Please review %post and %postun sections in SPEC file. >>>>> >>>>> Thank you! >>>>> >>>>> -- Petr^2 Spacek >>>>> +%post >>>>> +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then > > I just noticed that you are setting the SELinux option ONLY when > installing the package. I think you want to set it also if updating > the package from older version... > > So you should use "-ge" instead of "-eq". Good catch! Fixes patch is attached. According to https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax the condition is redundant so I replaced it with a comment about intended effect. >>>>> + echo "Enabling SELinux boolean named_write_master_zones" >>>>> + /usr/sbin/setsebool -P named_write_master_zones=1 || true >>>> >>>> I think you should redirect all output from the setsebool to /dev/null >>>> so it does not produce any output during the "yum install". The same >>>> for the "echo" I'm not sure if it should be there, but I didn't find any >>>> rule in packaging guidelines that is prohibiting you from doing so. >> >>> I don't understand what is the point. I guess that it is an anachronism >>> from old times when RPM have problems with that. >> >>> If you don't insist (or find any rule about this) I will let the output >>> as is. >> >>> IMHO it is much much better to show to user what went wrong instead of >>> telling just "post scriptlet failed". >> >> I don't insist on this. However from my point of view at least the >> STDOUT should be discarded. You may leave the STDERR as is. setsebool prints nothing anyway (unless there is an problem). I think that SELinux policy is sensitive enough so any error/warning should be visible to a user. >> Keep in mind that user using graphical installation tool will not >> see those outputs anyway. I would call it a bug in the GUI tool. As far as I remember from Synaptic utility (on Debian) have had a button like "Show me log". It seems perfectly reasonable to me. However, I have never seen any graphical package manager for Fedora :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0223-2-Update-Fedora-SPEC-file-for-v4.0.patch Type: text/x-patch Size: 2976 bytes Desc: not available URL: From thozza at redhat.com Fri Feb 21 12:42:55 2014 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 21 Feb 2014 13:42:55 +0100 Subject: [Freeipa-devel] [PATCH 0223] Update Fedora SPEC file for v4.0 (RPM expert needed) In-Reply-To: <530748A4.7090309@redhat.com> References: <53072058.3000500@redhat.com> <53072504.1070407@redhat.com> <53073417.6050300@redhat.com> <53073E84.3090104@redhat.com> <5307404F.3030608@redhat.com> <530748A4.7090309@redhat.com> Message-ID: <530749CF.7060904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/21/2014 01:37 PM, Petr Spacek wrote: > On 21.2.2014 13:02, Tomas Hozza wrote: >> On 02/21/2014 12:54 PM, Tomas Hozza wrote: >>> On 02/21/2014 12:10 PM, Petr Spacek wrote: >>>> On 21.2.2014 11:05, Tomas Hozza wrote: >>>>> On 02/21/2014 10:46 AM, Petr Spacek wrote: >>>>>> I want to release bind-dyndb-ldap 4.0 to Fedora 20+ but I have found >>>>>> that we >>>>>> need to enable SELinux boolean named_write_master_zones otherwise the >>>>>> plugin >>>>>> will not be able to write journal files to /var/named. >>>>>> >>>>>> I have asked Miroslav Grepl for advice and his >>>>>> recommendation is to use another context for our dyndb-ldap >>>>>> sub-directory or >>>>>> to enable named_write_master_zones. >>>>>> >>>>>> (See https://bugzilla.redhat.com/show_bug.cgi?id=1066333) >>>>>> >>>>>> I have decided to use more generic named_write_master_zones because >>>>>> it will be >>>>>> need for DNSSEC key management anyway. >>>>>> >>>>>> Miroslav told me that it is allowed to change SELinux booleans in RPM >>>>>> scriptlets - it is normal operation - but that we have to disable the >>>>>> boolean >>>>>> during package un-installation. >>>>>> >>>>>> Please review %post and %postun sections in SPEC file. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> -- Petr^2 Spacek > > >>>>>> +%post >>>>>> +if [ "0$1" -eq "1" ] && [ -x "/usr/sbin/setsebool" ] ; then >> >> I just noticed that you are setting the SELinux option ONLY when >> installing the package. I think you want to set it also if updating >> the package from older version... >> >> So you should use "-ge" instead of "-eq". > > Good catch! Fixes patch is attached. > > According to > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax > the condition is redundant so I replaced it with a comment about > intended effect. > >>>>>> + echo "Enabling SELinux boolean named_write_master_zones" >>>>>> + /usr/sbin/setsebool -P named_write_master_zones=1 || true >>>>> >>>>> I think you should redirect all output from the setsebool to /dev/null >>>>> so it does not produce any output during the "yum install". The same >>>>> for the "echo" I'm not sure if it should be there, but I didn't >>>>> find any >>>>> rule in packaging guidelines that is prohibiting you from doing so. >>> >>>> I don't understand what is the point. I guess that it is an anachronism >>>> from old times when RPM have problems with that. >>> >>>> If you don't insist (or find any rule about this) I will let the output >>>> as is. >>> >>>> IMHO it is much much better to show to user what went wrong instead of >>>> telling just "post scriptlet failed". >>> >>> I don't insist on this. However from my point of view at least the >>> STDOUT should be discarded. You may leave the STDERR as is. > > setsebool prints nothing anyway (unless there is an problem). I think > that SELinux policy is sensitive enough so any error/warning should be > visible to a user. > >>> Keep in mind that user using graphical installation tool will not >>> see those outputs anyway. > > I would call it a bug in the GUI tool. As far as I remember from > Synaptic utility (on Debian) have had a button like "Show me log". It > seems perfectly reasonable to me. However, I have never seen any > graphical package manager for Fedora :-) > Changes to the SPEC look good now. ACK from my side. Regards, Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTB0nPAAoJEMWIetUdnzwtONwIAJpc7mB1ptP7k6Ma6B8vv/55 IW9+YI4o9VydxhsW/2BHNsunX52/VT/bG1XKGhDtk5obK0QUudFj6nVFcwvm3wfM oImt0+4W/ALPJho28wil4IdRopJL72k0nssbCc6CudtafvCU/bAPYRrY6GtT8Aol yQh3dn2jsmqM7Vd0TUvU+zSm6Uo2ir3Lv7evubo9bGKUzWODy95XTjFy9QOBi26x 0UpKRrO4147bO19LLTM5gPyUUmZvTRxQAGcwhnpZwPY8+zr86lT4mmmmBoeKwAOC Bl96gAuwzhmQPxJXZZvYtUYeuDiaVhnQW3qC0QbYFQB1rAt7a3SKpyj/hEHec/c= =9hLp -----END PGP SIGNATURE----- From pspacek at redhat.com Fri Feb 21 12:44:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 13:44:23 +0100 Subject: [Freeipa-devel] [PATCH 0204] Remove obsolete zr_get_rbt() function from zone register In-Reply-To: <52D94886.7000902@redhat.com> References: <5280C540.8030604@redhat.com> <52D94886.7000902@redhat.com> Message-ID: <53074A27.7030602@redhat.com> On 17.1.2014 16:13, Tomas Hozza wrote: > On 11/11/2013 12:53 PM, Petr Spacek wrote: >> Hello, >> >> Remove obsolete zr_get_rbt() function from zone register. >> > > ACK. > > Patch looks good. Pushed to v3 and master branch: fa03da94d04c539ed84cc75d0ac070feb1052820 -- Petr^2 Spacek From mkosek at redhat.com Fri Feb 21 13:34:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Feb 2014 14:34:59 +0100 Subject: [Freeipa-devel] [PATCH] 0467 permission plugin: Do not assume attribute-level rights for new attributes are present In-Reply-To: <52FCBD69.1000405@redhat.com> References: <52FCBD69.1000405@redhat.com> Message-ID: <53075603.5060700@redhat.com> On 02/13/2014 01:41 PM, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/4121 > > Apply on top of my patches 0464-0466. Works for me. ACK. Pushed to master: 773e006ddd98cf9beabfada9d2830276826ab043 Martin From mkosek at redhat.com Fri Feb 21 13:57:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Feb 2014 14:57:52 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <5305F1BA.8080008@redhat.com> References: <5305F1BA.8080008@redhat.com> Message-ID: <53075B60.2090301@redhat.com> On 02/20/2014 01:14 PM, Martin Kosek wrote: > We had a discussion with other developers how better track who is reviewing > which patch. Recently, we introduced the Reviewed-By tag in a commit message, > but that is a post-review tag which is not useful for someone who wants to know > which patches are already reviewed and which are not reviewed. > > We were testing Patch Work [1] in last months to contain this information, but > I personally think that it is suboptimal - it introduces 2 tracking tools that > needs to be maintained (Trac and Patch Work) and the Patch Work still requires > lot of manual actions when maintaining it's state. > > I think it would be better to hold this information rather in a single tracking > tool - Trac. There are 2 options: > > 1) "Patch on review" flag, similar to "Patch posted for review" flag which > would hold 1 bit information if the patch is just lying there or has somebody > assigned. > > 2) "Reviewed by" text field which would hold a login of a person who is > reviewing it. It would be filled either by a person starting the review or by a > supervisor like me to forcefully assign a reviewer ;-) > > With that information in Trac, we could run using a single tracking tool for > all patches that have a ticket (which is 95% of patches). It would be then > fairly easy to see which patches are sent for review but are reviewer-less. > > It would also have a benefit for Petr's sendpatches.py script which could pull > the reviewer from a ticket and one would not have to use the "-r" option to > hard code a reviewer. > > Any objections to using "Reviewed by" field? > > [1] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 > Thanks for discussion, looks like a critical mass of developers want this change, let's do it. I did several changes to make this change life: * Add the new ticket field, obviously * Created or updated handy reports to handle the new field, namely: - https://fedorahosted.org/freeipa/report/3: now contains the reviewer field - https://fedorahosted.org/freeipa/report/11: My Reviews by Milestone - https://fedorahosted.org/freeipa/report/19: Tickets On Review by Milestone * Updated the process in http://www.freeipa.org/page/Contribute/Code * Bootstrapped the Reviewer field with current reviews. Please add any ongoing reviews I missed. I think that especially report 19 gives a nice overview which patch reviews are already taken and which are free to be taken. Let the reviews begin! Martin From pspacek at redhat.com Fri Feb 21 13:57:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 14:57:56 +0100 Subject: [Freeipa-devel] [PATCH 0016] Clarify error message about missing DNS component in ipa-replica-prepare Message-ID: <53075B64.30408@redhat.com> Hello, Clarify error message about missing DNS component in ipa-replica-prepare. Use 'dane' on #freeipa channel have spent half an hour finding out what is wrong because the error message was misleading. I think that it is enough to justify this change :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0016-Clarify-error-message-about-missing-DNS-component-in.patch Type: text/x-patch Size: 1604 bytes Desc: not available URL: From lslebodn at redhat.com Fri Feb 21 14:12:48 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 21 Feb 2014 15:12:48 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Include missing header files. Message-ID: <20140221141247.GA32238@mail.corp.redhat.com> ehlo, Function get_krb5_tgt is declared in header file krb5_helper.h, but this header file was not included in implementation file krb5_helper.c Function fs_dirs_create is declared in header file fs.h, but this header file was not included in the implementation file fs.c LS -------------- next part -------------- >From 02ed610587749b6a0981a9be64dda1c62adb0589 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 27 Jan 2014 23:20:16 +0100 Subject: [PATCH] Include missing header files. Function get_krb5_tgt is declared in header file krb5_helper.h, but this header file was not included in implementation file krb5_helper.c Function fs_dirs_create is declared in header file fs.h, but this header file was not included in the implementation file fs.c --- src/fs.c | 1 + src/krb5_helper.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/fs.c b/src/fs.c index a7582d0a51db5083c505e6f8fcbdf0725e9eb460..861865d48688b649e68552177f3e56b98d5b59f9 100644 --- a/src/fs.c +++ b/src/fs.c @@ -32,6 +32,7 @@ #include #include "log.h" +#include "fs.h" static const char msg_getcwd_failed[PATH_MAX] = ""; diff --git a/src/krb5_helper.c b/src/krb5_helper.c index 25de7f80ee56a6a2c6c6591266edf621914a10b9..8a1501e75fd62a4e039759c7095f693cac037849 100644 --- a/src/krb5_helper.c +++ b/src/krb5_helper.c @@ -24,6 +24,7 @@ #include "util.h" #include "str.h" #include "log.h" +#include "krb5_helper.h" #define DEFAULT_KEYTAB "FILE:/etc/named.keytab" #define MIN_TIME 300 /* 5 minutes */ -- 1.8.5.3 From pvoborni at redhat.com Fri Feb 21 14:24:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Feb 2014 15:24:00 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <52F8D034.2040009@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> Message-ID: <53076180.7020103@redhat.com> On 10.2.2014 14:12, Petr Vobornik wrote: > On 13.1.2014 17:09, Petr Vobornik wrote: >> Hi, >> >> these patches implements the OTP Web UI. >> >> Last 5 patches is the OTP UI. >> >> First 6 patches is a little refactoring/bug fixes needed for them. >> General password dialog is introduced to avoid another implementation. >> >> Self-service UI is implemented to be very simple. Atm user can choose >> only token name. Admin interface allows to enter all values. >> >> It's based on the RCUE work -> we need to push RCUE first. Thanks >> Nathaniel for review of the last font package. It will speed things up. >> >> Know bugs: >> - there is clash in id's of checkboxes preventing editation of >> subsequently displayed ones with the same name. Will be fixed in >> separate patch. >> - bugs caused by bugs in API (adding/removal of own tokens in >> self-service, inability to enter key on token creation - >> https://fedorahosted.org/freeipa/ticket/4099) >> - datetime format (widget+validator) will be implemented in separate >> patch >> - no support of not reviewed CLI patches (HOTP..) >> >> Cgit: >> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >> >> https://fedorahosted.org/freeipa/ticket/3369 >> > > patch 540-1 has been updated > - QR code is centered > - QR code correction level was lowered from H to M > > All other current patches from sub-threads are attached as well (it was > getting hard to keep track of them). > Attaching new version of patch 537: 537-4 It: * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter field in details facet * removes 'default' radio button in adder dialog in ipatokenotpalgorithm and ipatokenotpdigits field Btw I've encountered an issue on Web UI login when: - user is created - token is created for him - admin resets user's password and changes auth type to 'otp' - user tries to login with psw+otp The initial login-password call is successful but subsequent change password fails - it uses the old psw+otp. I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 which is almost implemented. I also plan to hide fields without any value in otp token details page in self-service mode. This will be done after #3903 because some prerequisites for #3903 add useful code for that task. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-4-UI-for-OTP-tokens.patch Type: text/x-patch Size: 16273 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 21 14:25:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 15:25:59 +0100 Subject: [Freeipa-devel] [PATCH 0016] Clarify error message about missing DNS component in ipa-replica-prepare In-Reply-To: <53075B64.30408@redhat.com> References: <53075B64.30408@redhat.com> Message-ID: <530761F7.8080805@redhat.com> On 02/21/2014 02:57 PM, Petr Spacek wrote: > Hello, > > Clarify error message about missing DNS component in ipa-replica-prepare. > > Use 'dane' on #freeipa channel have spent half an hour finding out what > is wrong because the error message was misleading. I think that it is > enough to justify this change :-) Sounds reasonable. I'll take the patch review. https://fedorahosted.org/freeipa/ticket/4188 -- Petr? From pviktori at redhat.com Fri Feb 21 14:30:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 15:30:22 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails Message-ID: <530762FE.7080703@redhat.com> Hello, A permission object was not removed in permission-add when adding the ACI failed. Here is a fix. https://fedorahosted.org/freeipa/ticket/4187 Earlier we agreed that patch authors should bug the reviewer. I guess now this means I should set Patch-review-by in the ticket, right? So: Martin, you reviewed the other ACI patches so I think you should continue. If you don't agree, unset the field in the ticket. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0471-permission_add-Remove-permission-entry-if-adding-the.patch Type: text/x-patch Size: 3224 bytes Desc: not available URL: From npmccallum at redhat.com Fri Feb 21 14:36:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 09:36:18 -0500 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140220220859.GR16644@redhat.com> References: <1392223765.1816.4.camel@localhost.localdomain> <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> <1392922612.23210.3.camel@localhost.localdomain> <20140220220859.GR16644@redhat.com> Message-ID: <1392993378.23210.15.camel@localhost.localdomain> On Fri, 2014-02-21 at 00:08 +0200, Alexander Bokovoy wrote: > On Thu, 20 Feb 2014, Nathaniel McCallum wrote: > >> > >>There is an error in libotp's find() function which assumes that > >> > >>get_basedn() always returns non-NULL value. This is not true for at > >> > >>least cn=Directory Manager. > >> > >> > >> > >>Patch attached. > >> > >More fixes required, now that Thierry produced the fix for 389-ds ticket > >> > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop > >> > >plugins. I'm getting crash in find() in libotp.c for internal search in > >> > >some other conditions but at least user dn now is the correct one. > >> > > > >> > >Stay tuned. > >> > OK, finally I've got it working -- my last patch had error which could > >> > be attributed to the late night time. > >> > > >> > New patch is attached to fix libotp to work properly with empty base dn > >> > (such as cn=Directory Manager). > >> > > >> > Also I'm attaching the patch that sets precedence of schema-compat > >> > plugin to 49 (less than default 50). With this patch and 389-ds with > >> > patch from ticket 47699 compat tree binds work with OTP. > >> > > >> > When updated 389-ds-base will be released, we'll need to add Requires: > >> > to our RPM spec to depend on it. Without the updated 389-ds-base compat > >> > tree binds will not work with OTP but the rest will be working fine. > >> > > >> > Finally, ACK to all OTP patches. > >> > >> ACK to both of these patches. > > > >I've merged the first patch here -- > >https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html > > > >I just realized the second patch shouldn't be ACK'd until we have a new > >389DS release with the fix. When that happens, reissue this patch with > >an update versioned require. > No, it can be safely merged as 389DS will use default precedence (50) unless > the fix is there. So the worst we get is the same as now -- OTP binds > will not work over compat tree. And when 389DS will be upgraded, they > will start working after 389DS restart. But this patch doesn't actually do anything until we get the new version of 389DS. If we are ever going to add a versioned dependency on the new 389DS for this feature, it should go in this patch. Otherwise, it is an ACK from me. Nathaniel From npmccallum at redhat.com Fri Feb 21 14:40:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 09:40:39 -0500 Subject: [Freeipa-devel] [PATCH 0040] Use super() properly to avoid an exception Message-ID: <1392993639.23210.17.camel@localhost.localdomain> https://fedorahosted.org/freeipa/ticket/4099 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0040-Use-super-properly-to-avoid-an-exception.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: From npmccallum at redhat.com Fri Feb 21 14:41:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 09:41:43 -0500 Subject: [Freeipa-devel] [PATCH 0041] Make all ipatokenTOTP attributes mandatory Message-ID: <1392993703.23210.18.camel@localhost.localdomain> Originally we made them all optional as a workaround for the lack of SELFDN support in 389DS. However, with the advent of SELFDN, this hack is no longer necessary. This patch updates TOTP to match HOTP in this regard. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0041-Make-all-ipatokenTOTP-attributes-mandatory.patch Type: text/x-patch Size: 2840 bytes Desc: not available URL: From npmccallum at redhat.com Fri Feb 21 14:45:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 09:45:50 -0500 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled Message-ID: <1392993950.23210.22.camel@localhost.localdomain> We had originally decided to provide defaults on the server side so that they could be part of a global config for the admin. However, on further reflection, only certain defaults really make sense given the limitations of Google Authenticator. Similarly, other defaults may be token specific. Attempting to handle defaults on the server side also makes both the UI and the generated documentation unclear. NOTE: this patch changes an existing API. VERSION says that we should bump the major version in this case. But we haven't actually released this API yet. Please advise. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0042-Rework-how-otptoken-defaults-are-handled.patch Type: text/x-patch Size: 17523 bytes Desc: not available URL: From amisnyov at redhat.com Fri Feb 21 14:45:53 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Fri, 21 Feb 2014 09:45:53 -0500 (EST) Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <150886292.1683003.1392993793839.JavaMail.zimbra@redhat.com> Message-ID: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> Hi, According to http://tools.ietf.org/html/rfc2798 ipa client and web ui extended with employeenumber field. https://fedorahosted.org/freeipa/ticket/4165 Question is, that should we extend user with other fields which are in the RFC, (carLicense, departmentNumber, employeeType, etc) if we already touched this code? Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-1-Extending-user-plugin-with-employeenumber-field.patch Type: text/x-patch Size: 1641 bytes Desc: not available URL: From abokovoy at redhat.com Fri Feb 21 14:51:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 21 Feb 2014 16:51:50 +0200 Subject: [Freeipa-devel] [PATCH 0040] Use super() properly to avoid an exception In-Reply-To: <1392993639.23210.17.camel@localhost.localdomain> References: <1392993639.23210.17.camel@localhost.localdomain> Message-ID: <20140221145150.GT16644@redhat.com> On Fri, 21 Feb 2014, Nathaniel McCallum wrote: >https://fedorahosted.org/freeipa/ticket/4099 >>From b77bf5c7fdacc7b0224033d608d387be282f98bc Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Thu, 20 Feb 2014 13:20:01 -0500 >Subject: [PATCH] Use super() properly to avoid an exception > >https://fedorahosted.org/freeipa/ticket/4099 >--- > ipalib/plugins/otptoken.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py >index 77c17150d83f0562823698e1ad585ec523f16ad7..8e76ada907c161ffc6a7e83c02d41daa5849e515 100644 >--- a/ipalib/plugins/otptoken.py >+++ b/ipalib/plugins/otptoken.py >@@ -80,7 +80,7 @@ class OTPTokenKey(Bytes): > except TypeError, e: > raise ConversionError(name=self.name, index=index, error=str(e)) > >- return Bytes._convert_scalar(value, index) >+ return super(OTPTokenKey, self)._convert_scalar(value, index) > > def _convert_owner(userobj, entry_attrs, options): > if 'ipatokenowner' in entry_attrs and not options.get('raw', False): ACK. -- / Alexander Bokovoy From pviktori at redhat.com Fri Feb 21 15:02:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 16:02:19 +0100 Subject: [Freeipa-devel] [PATCH 0040] Use super() properly to avoid an exception In-Reply-To: <20140221145150.GT16644@redhat.com> References: <1392993639.23210.17.camel@localhost.localdomain> <20140221145150.GT16644@redhat.com> Message-ID: <53076A7B.10301@redhat.com> On 02/21/2014 03:51 PM, Alexander Bokovoy wrote: > On Fri, 21 Feb 2014, Nathaniel McCallum wrote: >> https://fedorahosted.org/freeipa/ticket/4099 > >>> From b77bf5c7fdacc7b0224033d608d387be282f98bc Mon Sep 17 00:00:00 2001 >> From: Nathaniel McCallum >> Date: Thu, 20 Feb 2014 13:20:01 -0500 >> Subject: [PATCH] Use super() properly to avoid an exception >> >> https://fedorahosted.org/freeipa/ticket/4099 > ACK. > > Pushed to master: 70e2217d7301185713b7d7391c7f1018f7d0d523 -- Petr? From jcholast at redhat.com Fri Feb 21 15:05:02 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Feb 2014 16:05:02 +0100 Subject: [Freeipa-devel] [PATCH 0041] Make all ipatokenTOTP attributes mandatory In-Reply-To: <1392993703.23210.18.camel@localhost.localdomain> References: <1392993703.23210.18.camel@localhost.localdomain> Message-ID: <53076B1E.8010308@redhat.com> Hi, On 21.2.2014 15:41, Nathaniel McCallum wrote: > Originally we made them all optional as a workaround for the lack of > SELFDN support in 389DS. However, with the advent of SELFDN, this hack > is no longer necessary. This patch updates TOTP to match HOTP in this > regard. I can't argue with that and the patch does what is advertised, so ACK. Honza -- Jan Cholasta From pviktori at redhat.com Fri Feb 21 15:04:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 16:04:49 +0100 Subject: [Freeipa-devel] [PATCH 0016] Clarify error message about missing DNS component in ipa-replica-prepare In-Reply-To: <530761F7.8080805@redhat.com> References: <53075B64.30408@redhat.com> <530761F7.8080805@redhat.com> Message-ID: <53076B11.9050301@redhat.com> On 02/21/2014 03:25 PM, Petr Viktorin wrote: > On 02/21/2014 02:57 PM, Petr Spacek wrote: >> Hello, >> >> Clarify error message about missing DNS component in ipa-replica-prepare. >> >> Use 'dane' on #freeipa channel have spent half an hour finding out what >> is wrong because the error message was misleading. I think that it is >> enough to justify this change :-) > > Sounds reasonable. I'll take the patch review. > https://fedorahosted.org/freeipa/ticket/4188 > ACK, pushed to master: dd55e13aa94a7540324239cac61b286262542d1e -- Petr? From pvoborni at redhat.com Fri Feb 21 15:06:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Feb 2014 16:06:27 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> Message-ID: <53076B73.9020008@redhat.com> On 21.2.2014 15:45, Adam Misnyovszki wrote: > Hi, > According to http://tools.ietf.org/html/rfc2798 ipa client and web ui extended with employeenumber field. > > https://fedorahosted.org/freeipa/ticket/4165 > > Question is, that should we extend user with other fields which are in the RFC, (carLicense, departmentNumber, employeeType, etc) if we already touched this code? > > Thanks > Adam > + Int('employeenumber?', + label=_('Employee ID'), + minvalue=1, + ), Why Int and different label? IMO it should be Str and 'Employee Number' 2.4. Employee Number Numeric or alphanumeric identifier assigned to a person, typically based on order of hire or association with an organization. Single valued. ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) -- Petr Vobornik From pviktori at redhat.com Fri Feb 21 15:07:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 16:07:57 +0100 Subject: [Freeipa-devel] [PATCH 0041] Make all ipatokenTOTP attributes mandatory In-Reply-To: <53076B1E.8010308@redhat.com> References: <1392993703.23210.18.camel@localhost.localdomain> <53076B1E.8010308@redhat.com> Message-ID: <53076BCD.4090204@redhat.com> On 02/21/2014 04:05 PM, Jan Cholasta wrote: > Hi, > > On 21.2.2014 15:41, Nathaniel McCallum wrote: >> Originally we made them all optional as a workaround for the lack of >> SELFDN support in 389DS. However, with the advent of SELFDN, this hack >> is no longer necessary. This patch updates TOTP to match HOTP in this >> regard. > > I can't argue with that and the patch does what is advertised, so ACK. > > Honza > Pushed to master: adcd373931c50d91550f6b74b191d08ecce5b137 -- Petr? From npmccallum at redhat.com Fri Feb 21 15:09:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 10:09:50 -0500 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <1392993950.23210.22.camel@localhost.localdomain> References: <1392993950.23210.22.camel@localhost.localdomain> Message-ID: <1392995390.23210.27.camel@localhost.localdomain> On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: > We had originally decided to provide defaults on the server side so that > they could be part of a global config for the admin. However, on further > reflection, only certain defaults really make sense given the > limitations of Google Authenticator. Similarly, other defaults may be > token specific. > > Attempting to handle defaults on the server side also makes both the UI > and the generated documentation unclear. > > NOTE: this patch changes an existing API. VERSION says that we should > bump the major version in this case. But we haven't actually released > this API yet. Please advise. I forgot to mention something else about this patch. The default_from in the key parameter generates a warning. This is because the default is a bytes string and internally a check is done against NULLS (constants.py:36). The u'' in NULLS forces an attempt to convert the byte string to unicode. When this fails (because ipatokenotpkey is *NOT* a string but a byte array), a warning is thrown. Since '' and u'' evaluate as equal, what is the point of having u'' in NULLS? I don't see any way to suppress this warning except to remove u'' from NULLS. Nathaniel From pspacek at redhat.com Fri Feb 21 15:12:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 16:12:01 +0100 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations Message-ID: <53076CC1.2070902@redhat.com> Hello, Add function attributes warn_unused_result and nonnull where appropriate and add missing CHECK()s to string operations. Lukas, thanks for catching the missing CHECK() around str_new(). As a reward, you can review attached patches. Have fun! :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0224-Add-missing-CHECK-s-to-string-operations.patch Type: text/x-patch Size: 5882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0225-Add-function-attributes-warn_unused_result-and-nonnu.patch Type: text/x-patch Size: 49240 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 21 15:13:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 16:13:45 +0100 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <1392993950.23210.22.camel@localhost.localdomain> References: <1392993950.23210.22.camel@localhost.localdomain> Message-ID: <53076D29.2070606@redhat.com> On 02/21/2014 03:45 PM, Nathaniel McCallum wrote: [...] > NOTE: this patch changes an existing API. VERSION says that we should > bump the major version in this case. But we haven't actually released > this API yet. Please advise. > If I understand correctly, there were other VERSION bumps in master between the original and this update. I think that's a good reason to bump the VERSION again. -- Petr? From npmccallum at redhat.com Fri Feb 21 15:16:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 10:16:07 -0500 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <53076CC1.2070902@redhat.com> References: <53076CC1.2070902@redhat.com> Message-ID: <1392995767.23210.29.camel@localhost.localdomain> On Fri, 2014-02-21 at 16:12 +0100, Petr Spacek wrote: > Hello, > > Add function attributes warn_unused_result and nonnull > where appropriate and add missing CHECK()s to string operations. > > Lukas, thanks for catching the missing CHECK() around str_new(). > > As a reward, you can review attached patches. > > Have fun! :-) NACK Adding attributes to a function definition is a no-op and can create potential confusion should the definitions and declarations differ. I would strongly prefer that they are only used in function declarations. Nathaniel From pspacek at redhat.com Fri Feb 21 15:16:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 16:16:07 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Include missing header files. In-Reply-To: <20140221141247.GA32238@mail.corp.redhat.com> References: <20140221141247.GA32238@mail.corp.redhat.com> Message-ID: <53076DB7.10301@redhat.com> On 21.2.2014 15:12, Lukas Slebodnik wrote: > ehlo, > > Function get_krb5_tgt is declared in header file krb5_helper.h, but this header > file was not included in implementation file krb5_helper.c > > Function fs_dirs_create is declared in header file fs.h, but this header file > was not included in the implementation file fs.c > > LS ACK, thanks. -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 21 15:17:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 21 Feb 2014 16:17:45 +0100 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <1392995767.23210.29.camel@localhost.localdomain> References: <53076CC1.2070902@redhat.com> <1392995767.23210.29.camel@localhost.localdomain> Message-ID: <53076E19.6080700@redhat.com> On 21.2.2014 16:16, Nathaniel McCallum wrote: > On Fri, 2014-02-21 at 16:12 +0100, Petr Spacek wrote: >> Hello, >> >> Add function attributes warn_unused_result and nonnull >> where appropriate and add missing CHECK()s to string operations. >> >> Lukas, thanks for catching the missing CHECK() around str_new(). >> >> As a reward, you can review attached patches. >> >> Have fun! :-) > > NACK > > Adding attributes to a function definition is a no-op and can create > potential confusion should the definitions and declarations differ. > > I would strongly prefer that they are only used in function > declarations. > > Nathaniel Sorry, but you are not right. Attributes work perfectly fine for static functions without previous declaration. -- Petr^2 Spacek From pviktori at redhat.com Fri Feb 21 15:20:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Feb 2014 16:20:09 +0100 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <53076D29.2070606@redhat.com> References: <1392993950.23210.22.camel@localhost.localdomain> <53076D29.2070606@redhat.com> Message-ID: <53076EA9.9060100@redhat.com> On 02/21/2014 04:13 PM, Petr Viktorin wrote: > On 02/21/2014 03:45 PM, Nathaniel McCallum wrote: > [...] >> NOTE: this patch changes an existing API. VERSION says that we should >> bump the major version in this case. But we haven't actually released >> this API yet. Please advise. >> > > If I understand correctly, there were other VERSION bumps in master > between the original and this update. I think that's a good reason to > bump the VERSION again. Oh, sorry, you were talking about the *major* version. Don't bump that one, just the minor. Never update the major API version, it would break all existing clients. -- Petr? From npmccallum at redhat.com Fri Feb 21 15:20:41 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 10:20:41 -0500 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <53076E19.6080700@redhat.com> References: <53076CC1.2070902@redhat.com> <1392995767.23210.29.camel@localhost.localdomain> <53076E19.6080700@redhat.com> Message-ID: <1392996041.23210.30.camel@localhost.localdomain> On Fri, 2014-02-21 at 16:17 +0100, Petr Spacek wrote: > On 21.2.2014 16:16, Nathaniel McCallum wrote: > > On Fri, 2014-02-21 at 16:12 +0100, Petr Spacek wrote: > >> Hello, > >> > >> Add function attributes warn_unused_result and nonnull > >> where appropriate and add missing CHECK()s to string operations. > >> > >> Lukas, thanks for catching the missing CHECK() around str_new(). > >> > >> As a reward, you can review attached patches. > >> > >> Have fun! :-) > > > > NACK > > > > Adding attributes to a function definition is a no-op and can create > > potential confusion should the definitions and declarations differ. > > > > I would strongly prefer that they are only used in function > > declarations. > > > > Nathaniel > > Sorry, but you are not right. > > Attributes work perfectly fine for static functions without previous declaration. Gah. You're right. I had assumed the header changes were duplicates of the static functions. Please disregard. Nathaniel From jcholast at redhat.com Fri Feb 21 15:29:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Feb 2014 16:29:29 +0100 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <1392995390.23210.27.camel@localhost.localdomain> References: <1392993950.23210.22.camel@localhost.localdomain> <1392995390.23210.27.camel@localhost.localdomain> Message-ID: <530770D9.4020104@redhat.com> Hi, On 21.2.2014 16:09, Nathaniel McCallum wrote: > On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: >> We had originally decided to provide defaults on the server side so that >> they could be part of a global config for the admin. However, on further >> reflection, only certain defaults really make sense given the >> limitations of Google Authenticator. Similarly, other defaults may be >> token specific. >> >> Attempting to handle defaults on the server side also makes both the UI >> and the generated documentation unclear. >> >> NOTE: this patch changes an existing API. VERSION says that we should >> bump the major version in this case. But we haven't actually released >> this API yet. Please advise. There were similar changes in the past and bumping minor version was always enough (we never ever bump major version). > > I forgot to mention something else about this patch. The default_from in > the key parameter generates a warning. This is because the default is a > bytes string and internally a check is done against NULLS > (constants.py:36). The u'' in NULLS forces an attempt to convert the > byte string to unicode. When this fails (because ipatokenotpkey is *NOT* > a string but a byte array), a warning is thrown. > > Since '' and u'' evaluate as equal, what is the point of having u'' in > NULLS? I don't see any way to suppress this warning except to remove u'' > from NULLS. I think we can get rid of NULLS entirely and do something better instead (like "if not value and value is not False:"). Is this worth filing a ticket? > > Nathaniel Honza -- Jan Cholasta From lslebodn at redhat.com Fri Feb 21 15:32:28 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 21 Feb 2014 16:32:28 +0100 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <1392996041.23210.30.camel@localhost.localdomain> References: <53076CC1.2070902@redhat.com> <1392995767.23210.29.camel@localhost.localdomain> <53076E19.6080700@redhat.com> <1392996041.23210.30.camel@localhost.localdomain> Message-ID: <20140221153228.GC32238@mail.corp.redhat.com> On (21/02/14 10:20), Nathaniel McCallum wrote: >On Fri, 2014-02-21 at 16:17 +0100, Petr Spacek wrote: >> On 21.2.2014 16:16, Nathaniel McCallum wrote: >> > On Fri, 2014-02-21 at 16:12 +0100, Petr Spacek wrote: >> >> Hello, >> >> >> >> Add function attributes warn_unused_result and nonnull >> >> where appropriate and add missing CHECK()s to string operations. >> >> >> >> Lukas, thanks for catching the missing CHECK() around str_new(). >> >> >> >> As a reward, you can review attached patches. >> >> >> >> Have fun! :-) >> > >> > NACK >> > >> > Adding attributes to a function definition is a no-op and can create >> > potential confusion should the definitions and declarations differ. >> > >> > I would strongly prefer that they are only used in function >> > declarations. >> > >> > Nathaniel >> >> Sorry, but you are not right. >> >> Attributes work perfectly fine for static functions without previous declaration. > >Gah. You're right. I had assumed the header changes were duplicates of >the static functions. Please disregard. > 1. It does not make sense to have declaration of static function in header file 2. Sometimes, it's better to test patches instead of sending useless reply. For your information: You need to use attribute after declaration. isc_result_t manager_get_ldap_instance(const char *name, ldap_instance_t **ldap_inst) ATTR_NONNULLS; In case of static function, you need to use attribute before name of function. In other case, it would be no-op. This is a small difference between using attributes with function declaration and function definition. static isc_result_t ATTR_NONNULLS setting_get(const char *const name, const setting_type_t type, const settings_set_t *const set, void *target) { /* body */ return 0; } LS From rcritten at redhat.com Fri Feb 21 15:37:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 10:37:15 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53029721.9040508@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> Message-ID: <530772AB.2060409@redhat.com> Dmitri Pal wrote: > On 02/17/2014 04:57 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>> things >>>>>>>>> now, >>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>> Foreman. >>>>>>>>> >>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>> specific to >>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>> cases. If >>>>>>>>> Foreman-specific, I would go with >>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>> similar. >>>>>>>>> >>>>>>>>> If general, we can go with >>>>>>>>> >>>>>>>>> freeipa-server-proxy-host >>>>>>>>> freeipa-server-proxy-user >>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>> >>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>> part of the >>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>> separation, as >>>>>>>>> compared >>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>> >>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>> envision >>>>>>>> this as 3 separate subpackages? >>>>>>>> >>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>> server >>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>> layers. >>>>>>> >>>>>>> >>>>>>> Then it seems to make sense to have 3 different packages that can be >>>>>>> optionally coninstalled and would probably share the same principal, >>>>>>> keytab and local REST API socket/port. >>>>>>> >>>>>> >>>>>> Well, what you are designing is a central framework with plugins. >>>>>> What >>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>> pick one. The plugable method is going to require a fair bit of >>>>>> rework, though it will potentially pay dividends in the future. >>>>> >>>>> I think that we can start where you are but drive towards this >>>>> architecture via refactoring. But we need to pick the right name now. >>>>> Even if the architecture is not there yet we should name the >>>>> package in >>>>> such way that it does not preclude us from moving towards a clean >>>>> architecture I described during the next iteration. >>>> >>>> Just having a hard time seeing the value. This would be like making >>>> each of the IPA plugins a separate package and somehow installing them >>>> individually. >>>> >>>> To do this you'd need at least 2 packages, a high level one with the >>>> "framework" and then a separate one for each data type. >>>> >>>> This could also be achieved, and likely more cleanly, without all >>>> these extra packages, as a simple configuration file. Once a package, >>>> always a package. >>>> >>>> Maybe I'm too close to the problem, but to me this is a >>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>> don't know that anything else is using it. If you want a RESTful >>>> server, then we enable REST in IPA directly, but selectively enabling >>>> and disabling APIs is not something we've done before. It has been >>>> controlled by ACIs instead. >>>> >>>> rob >>>> >>> >>> We are trying to predict future here. Say we release it as you suggest. >>> Tomorrow we point someone upstream who wants to add users to IPA from a >>> similar proxy to this implementation and say use this as a model. >>> And then Rich needs the same but for DNS for Designate. >>> >>> What would be the best? Rob if you knew that tomorrow two other >>> developers will create similar proxies for users and DNS would you >>> change anything? Would you provide some guidelines to them? >>> If you are close to the problem you should be able to at least tell >>> them: "copy and paste" vs. "add more APIs to the same proxy". >>> If your recommendation is copy and paste then I suspect there will be >>> challenges of running these proxies on the same machine - they will >>> collide on ports and sockets. If we say "extend" shouldn't we use a more >>> generic name? >>> >> >> I'd say "use the existing IPA API". The only reason we have to write >> the smartproxy at all is to interoperate with another service that >> already has a well-defined remote server API which uses REST. >> >> rob > OK, so you think that proxy is one off. OK I am fine with it. > I was under assumption that it would be a beginning of a trend but I > might be wrong as I do not have valid arguments to prove or disprove one > way or another. > I guess time would show. > > Any objections to Rob's approach? > Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other authentication method, so we're blocked with this. The certs for this would initially come out of Foreman/puppet. I'll submit a new patch with an updated spec but I think otherwise I've addressed the isuses Petr has raised. This thread has taken a lot of turns so it is very possible I missed something though :-) rob From mkosek at redhat.com Fri Feb 21 16:09:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Feb 2014 17:09:52 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530772AB.2060409@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> Message-ID: <53077A50.7090201@redhat.com> On 02/21/2014 04:37 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>> things >>>>>>>>>> now, >>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>> Foreman. >>>>>>>>>> >>>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>>> specific to >>>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>>> cases. If >>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>> similar. >>>>>>>>>> >>>>>>>>>> If general, we can go with >>>>>>>>>> >>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>> >>>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>>> part of the >>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>> separation, as >>>>>>>>>> compared >>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>> >>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>> envision >>>>>>>>> this as 3 separate subpackages? >>>>>>>>> >>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>> server >>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>> layers. >>>>>>>> >>>>>>>> >>>>>>>> Then it seems to make sense to have 3 different packages that can be >>>>>>>> optionally coninstalled and would probably share the same principal, >>>>>>>> keytab and local REST API socket/port. >>>>>>>> >>>>>>> >>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>> What >>>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>> rework, though it will potentially pay dividends in the future. >>>>>> >>>>>> I think that we can start where you are but drive towards this >>>>>> architecture via refactoring. But we need to pick the right name now. >>>>>> Even if the architecture is not there yet we should name the >>>>>> package in >>>>>> such way that it does not preclude us from moving towards a clean >>>>>> architecture I described during the next iteration. >>>>> >>>>> Just having a hard time seeing the value. This would be like making >>>>> each of the IPA plugins a separate package and somehow installing them >>>>> individually. >>>>> >>>>> To do this you'd need at least 2 packages, a high level one with the >>>>> "framework" and then a separate one for each data type. >>>>> >>>>> This could also be achieved, and likely more cleanly, without all >>>>> these extra packages, as a simple configuration file. Once a package, >>>>> always a package. >>>>> >>>>> Maybe I'm too close to the problem, but to me this is a >>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>> don't know that anything else is using it. If you want a RESTful >>>>> server, then we enable REST in IPA directly, but selectively enabling >>>>> and disabling APIs is not something we've done before. It has been >>>>> controlled by ACIs instead. >>>>> >>>>> rob >>>>> >>>> >>>> We are trying to predict future here. Say we release it as you suggest. >>>> Tomorrow we point someone upstream who wants to add users to IPA from a >>>> similar proxy to this implementation and say use this as a model. >>>> And then Rich needs the same but for DNS for Designate. >>>> >>>> What would be the best? Rob if you knew that tomorrow two other >>>> developers will create similar proxies for users and DNS would you >>>> change anything? Would you provide some guidelines to them? >>>> If you are close to the problem you should be able to at least tell >>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>> If your recommendation is copy and paste then I suspect there will be >>>> challenges of running these proxies on the same machine - they will >>>> collide on ports and sockets. If we say "extend" shouldn't we use a more >>>> generic name? >>>> >>> >>> I'd say "use the existing IPA API". The only reason we have to write >>> the smartproxy at all is to interoperate with another service that >>> already has a well-defined remote server API which uses REST. >>> >>> rob >> OK, so you think that proxy is one off. OK I am fine with it. >> I was under assumption that it would be a beginning of a trend but I >> might be wrong as I do not have valid arguments to prove or disprove one >> way or another. >> I guess time would show. >> >> Any objections to Rob's approach? >> > > Ok, so try to summarize this long-running thread, I'll rename the subpackage to > freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now > it requires manual configuration so having the package installed should have no > negative impacts (other than potentially pulling in additional dependencies). > > I'll leave it in smartproxy for now, it's just cleaner and better integrates > with ipatests IMHO. Ok, sounds reasonable to me. > Foreman supports SSL client auth which is great, by cherrypy does not yet. > There is a pull request to add this, > https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity > . Foreman otherwise supports no other authentication method, so we're blocked > with this. The certs for this would initially come out of Foreman/puppet. Does that then mean that the first version will be without any authentication or socket connection? Is that OK with everybody? Martin From npmccallum at redhat.com Fri Feb 21 16:42:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 11:42:45 -0500 Subject: [Freeipa-devel] [PATCH 0043] Remove NULLS from constants.py Message-ID: <1393000965.23210.38.camel@localhost.localdomain> In the parameters system, we have been checking for a positive list of values which get converted to None. The problem is that this method can in some cases throw warnings when type coercion doesn't work (particularly, string to unicode). Instead, any values that evaluate to False that are neither numeric nor boolean should be converted to None. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0043-Remove-NULLS-from-constants.py.patch Type: text/x-patch Size: 4672 bytes Desc: not available URL: From npmccallum at redhat.com Fri Feb 21 16:45:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 11:45:29 -0500 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <530770D9.4020104@redhat.com> References: <1392993950.23210.22.camel@localhost.localdomain> <1392995390.23210.27.camel@localhost.localdomain> <530770D9.4020104@redhat.com> Message-ID: <1393001129.23210.40.camel@localhost.localdomain> On Fri, 2014-02-21 at 16:29 +0100, Jan Cholasta wrote: > Hi, > > On 21.2.2014 16:09, Nathaniel McCallum wrote: > > On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: > >> We had originally decided to provide defaults on the server side so that > >> they could be part of a global config for the admin. However, on further > >> reflection, only certain defaults really make sense given the > >> limitations of Google Authenticator. Similarly, other defaults may be > >> token specific. > >> > >> Attempting to handle defaults on the server side also makes both the UI > >> and the generated documentation unclear. > >> > >> NOTE: this patch changes an existing API. VERSION says that we should > >> bump the major version in this case. But we haven't actually released > >> this API yet. Please advise. > > There were similar changes in the past and bumping minor version was > always enough (we never ever bump major version). Fixed. > > > > I forgot to mention something else about this patch. The default_from in > > the key parameter generates a warning. This is because the default is a > > bytes string and internally a check is done against NULLS > > (constants.py:36). The u'' in NULLS forces an attempt to convert the > > byte string to unicode. When this fails (because ipatokenotpkey is *NOT* > > a string but a byte array), a warning is thrown. > > > > Since '' and u'' evaluate as equal, what is the point of having u'' in > > NULLS? I don't see any way to suppress this warning except to remove u'' > > from NULLS. > > I think we can get rid of NULLS entirely and do something better instead > (like "if not value and value is not False:"). > > Is this worth filing a ticket? How about a patch? https://www.redhat.com/archives/freeipa-devel/2014-February/msg00426.html Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0042.1-Rework-how-otptoken-defaults-are-handled.patch Type: text/x-patch Size: 18054 bytes Desc: not available URL: From lslebodn at redhat.com Fri Feb 21 18:14:37 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 21 Feb 2014 19:14:37 +0100 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <53076CC1.2070902@redhat.com> References: <53076CC1.2070902@redhat.com> Message-ID: <20140221181436.GD32238@mail.corp.redhat.com> On (21/02/14 16:12), Petr Spacek wrote: >Hello, > >Add function attributes warn_unused_result and nonnull >where appropriate and add missing CHECK()s to string operations. > >Lukas, thanks for catching the missing CHECK() around str_new(). > >As a reward, you can review attached patches. > >Have fun! :-) > >-- >Petr^2 Spacek >From 063f776fc083c1fa26419a1ea63df98b9953826f Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Fri, 21 Feb 2014 15:21:36 +0100 >Subject: [PATCH] Add missing CHECK()s to string operations. > >Signed-off-by: Petr Spacek >--- > src/ldap_helper.c | 4 ++-- > src/str.c | 4 ++-- > src/str.h | 28 ++++++++++++++-------------- > src/util.h | 2 ++ > 4 files changed, 20 insertions(+), 18 deletions(-) > >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >index b0dd3391f4dca88992ac7869b34d943a381d51be..be37ce575c0965856afabcb59c5eba949ad902fd 100644 >--- a/src/ldap_helper.c >+++ b/src/ldap_helper.c >@@ -1772,7 +1772,7 @@ ldap_replace_serial(ldap_instance_t *inst, dns_name_t *zone, > > REQUIRE(inst != NULL); > >- str_new(inst->mctx, &dn); >+ CHECK(str_new(inst->mctx, &dn)); > CHECK(dnsname_to_dn(inst->zone_register, zone, dn)); > > change.mod_op = LDAP_MOD_REPLACE; >@@ -2405,7 +2405,7 @@ ldap_query(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, > CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > > va_start(ap, filter); >- str_vsprintf(ldap_qresult->query_string, filter, ap); >+ CHECK(str_vsprintf(ldap_qresult->query_string, filter, ap)); > va_end(ap); ^^^^^^^^^^ va_end have to be called every time. It would be better to move check after va_end(ap) va_start(ap, filter); result = str_vsprintf(ldap_qresult->query_string, filter, ap); va_end(ap); CHECK(result); >From 50cb2a22cad24463145b8e18582d13fc20dc8011 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Fri, 21 Feb 2014 15:58:19 +0100 >Subject: [PATCH] Add function attributes warn_unused_result and nonnull where > appropriate. > >Signed-off-by: Petr Spacek >--- > src/acl.c | 22 ++++---- > src/acl.h | 6 +- > src/fs.h | 4 +- > src/fwd_register.h | 10 ++-- > src/krb5_helper.c | 2 +- > src/krb5_helper.h | 2 +- > src/ldap_convert.c | 8 +-- > src/ldap_convert.h | 10 ++-- > src/ldap_entry.c | 2 +- > src/ldap_entry.h | 26 ++++----- > src/ldap_helper.c | 156 ++++++++++++++++++++++++++-------------------------- > src/ldap_helper.h | 2 +- > src/rbt_helper.c | 2 +- > src/rbt_helper.h | 4 +- > src/rdlist.c | 4 +- > src/rdlist.h | 8 +-- > src/semaphore.h | 4 +- > src/settings.c | 4 +- > src/settings.h | 18 +++--- > src/syncrepl.c | 2 +- > src/syncrepl.h | 14 ++--- > src/zone_manager.c | 4 +- > src/zone_manager.h | 6 +- > src/zone_register.h | 18 +++--- > 24 files changed, 169 insertions(+), 169 deletions(-) > Patch works well. I did a small test with a function find_db_instance. - result = find_db_instance(name, &db_inst); + find_db_instance(name, &db_inst); CC ldap_la-zone_manager.lo ../src/zone_manager.c:126:2: error: ignoring return value of function declared with warn_unused_result attribute [-Werror,-Wunused-result] find_db_instance(name, &db_inst); ^~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ 1 error generated. Attribute "__attribute__((warn_unused_result))" is not generated if macro __GNUC__ is not defined. (make CFLAGS+="-U__GNUC__") Some lines are longer than 80 columns, but I am not very familiar with your coding style. Otherwise 2nd patch looks good. LS From lslebodn at redhat.com Fri Feb 21 18:35:22 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 21 Feb 2014 19:35:22 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix potential dereference of NULL pointer in sync_ctx_init In-Reply-To: <52AB3984.8010005@redhat.com> References: <5273AD7D.5020402@redhat.com> <1939839260.12480070.1383650984710.JavaMail.root@redhat.com> <5282458B.4000808@redhat.com> <52AB3984.8010005@redhat.com> Message-ID: <20140221183522.GE32238@mail.corp.redhat.com> On (13/12/13 17:44), Petr Spacek wrote: >On 12.11.2013 16:13, Petr Spacek wrote: >>On 5.11.2013 12:29, Tomas Hozza wrote: >>>----- Original Message ----- >>>>Hello, >>>> >>>>Improve performance of initial LDAP synchronization. >>>> >>>>Changes are not journaled and SOA serial is not incremented during initial >>>>LDAP synchronization. >>>> >>>>This eliminates unnecessary synchronous writes to journal and also >>>>unnecessary SOA serial writes to LDAP. >>>> >>>>See commit messages and comments in syncrepl.c for all the gory details. >>> >>> >>>ACK. >>> >>>Patches look good. AXFR and IXFR works as expected. Also BIND starts up much >>>faster with these patches. Good job... :) >>> >>>Regards, >>> >>>Tomas >> >>Hmm, further testing revealed that patch 203 changed behavior little bit: >>Zones were loaded from LDAP correctly, but the SOA serial wasn't changed at >>all. As a result, zone transfers return inconsistent results if the data in >>LDAP are changed when BIND was not running. >> >>Patch 203-v2 imitates the old behavior from bind-dyndb-ldap 3.x: Zone serial >>is bumped *once* for each zone, so any changed in LDAP will be transferred >>correctly (with new serial). > >Patch 202 v2 was rebased and fixes reconnection to LDAP and solves >deadlock caused by too eager locking. > >Patch 203 v3 was rebased and fixes reconnection to LDAP. > >These patches should go to master branch. > >-- >Petr^2 Spacek > When I was testing upcoming bind-dyndb-ldap 4.0 release, There was an interesting warning from clang static analyser. I thought it was a false passitive, but it isn't. Patch is attached >From b73e345393d55fe411875d52e6fe4c98e1de8c04 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Mon, 9 Dec 2013 11:11:10 +0100 >Subject: [PATCH] Detect end of initial LDAP synchronization phase. > >LDAP intermediate message with refreshDone = TRUE is translated to >sync_barrier_wait() call. This call sends 'barrier event' to all tasks >involved in syncrepl event processing. The call will return when all tasks >have processed all events enqueued before the call. > >Effectively, all events produced by initial LDAP synchronization >are processed first. Current state of synchronization is available via >sync_state_get() call. > >See comments in syncrepl.c for all the gory details. > >Signed-off-by: Petr Spacek >--- > src/Makefile.am | 2 + > src/ldap_helper.c | 67 +++++++++-- > src/ldap_helper.h | 2 + > src/syncrepl.c | 351 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/syncrepl.h | 63 ++++++++++ > 5 files changed, 473 insertions(+), 12 deletions(-) > create mode 100644 src/syncrepl.c > create mode 100644 src/syncrepl.h > >+/** >+ * Initialize synchronization context. >+ * >+ * @param[in] task Task used for first synchronization events. >+ * Typically the ldap_inst->task. >+ * @param[out] sctxp The new synchronization context. >+ * >+ * @post state == sync_init >+ * @post task_cnt == 1 >+ * @post tasks list contains the task >+ */ >+isc_result_t >+sync_ctx_init(isc_mem_t *mctx, isc_task_t *task, sync_ctx_t **sctxp) { >+ isc_result_t result; >+ sync_ctx_t *sctx = NULL; >+ isc_boolean_t lock_ready = ISC_FALSE; >+ isc_boolean_t cond_ready = ISC_FALSE; >+ isc_boolean_t refcount_ready = ISC_FALSE; >+ >+ REQUIRE(sctxp != NULL && *sctxp == NULL); ^^^^^^^^^^^^^^ *sctxp is NULL >+ REQUIRE(ISCAPI_TASK_VALID(task)); >+ >+ CHECKED_MEM_GET_PTR(mctx, sctx); >+ ZERO_PTR(sctx); >+ isc_mem_attach(mctx, &sctx->mctx); >+ >+ CHECK(isc_mutex_init(&sctx->mutex)); >+ lock_ready = ISC_TRUE; >+ CHECK(isc_condition_init(&sctx->cond)); >+ cond_ready = ISC_TRUE; >+ >+ /* refcount includes ldap_inst->task implicitly */ >+ CHECK(isc_refcount_init(&sctx->task_cnt, 0)); >+ refcount_ready = ISC_TRUE; >+ >+ ISC_LIST_INIT(sctx->tasks); >+ >+ sctx->state = sync_init; >+ CHECK(sync_task_add(sctx, task)); >+ >+ *sctxp = sctx; ^^^^^^ value to *sctxp is asigned only on this line. >+ return ISC_R_SUCCESS; >+ >+cleanup: *sctxp will be NULL in cleanup section >+ if (lock_ready == ISC_TRUE) >+ isc_mutex_destroy(&(*sctxp)->mutex); &(NULL)->mutex It does not look like a good idea :-) >+ if (cond_ready == ISC_TRUE) >+ isc_condition_init(&(*sctxp)->cond); >+ if (refcount_ready == ISC_TRUE) >+ isc_refcount_destroy(&(*sctxp)->task_cnt); >+ MEM_PUT_AND_DETACH(*sctxp); >+ return result; >+} >+ LS -------------- next part -------------- >From dcf99122eb33b63799be91d3c13a9967420880c3 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 21 Feb 2014 19:18:28 +0100 Subject: [PATCH] Fix potential dereference of NULL pointer in sync_ctx_init Value is asigned to the output argument sync_ctx_t **sctxp before returning ISC_R_SUCCESS. Thus we should use local variable sctx in cleanup section. --- src/syncrepl.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/syncrepl.c b/src/syncrepl.c index 2a6d159fe16fffbf928198f9240cd8b1fcd41005..c6b326bab9733f7cb5065381d26e999ddbb570db 100644 --- a/src/syncrepl.c +++ b/src/syncrepl.c @@ -215,12 +215,12 @@ sync_ctx_init(isc_mem_t *mctx, isc_task_t *task, sync_ctx_t **sctxp) { cleanup: if (lock_ready == ISC_TRUE) - isc_mutex_destroy(&(*sctxp)->mutex); + isc_mutex_destroy(&sctx->mutex); if (cond_ready == ISC_TRUE) - isc_condition_init(&(*sctxp)->cond); + isc_condition_init(&sctx->cond); if (refcount_ready == ISC_TRUE) - isc_refcount_destroy(&(*sctxp)->task_cnt); - MEM_PUT_AND_DETACH(*sctxp); + isc_refcount_destroy(&sctx->task_cnt); + MEM_PUT_AND_DETACH(sctx); return result; } -- 1.8.5.3 From npmccallum at redhat.com Fri Feb 21 19:00:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Feb 2014 14:00:51 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <53076180.7020103@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> Message-ID: <1393009251.23210.47.camel@localhost.localdomain> Is it possible to do something more intelligent for the key and date fields in the add-token UI? Date fields are currently just a text box. Is there any sort of calendar we could use here? If not, I'm still unsure of what the format should be for this field. The key field should probably have a note indicating that it is Base32 encoding. It would also be nice to restrict the input to Base32 characters. Maybe even automatic case correction... Nathaniel On Fri, 2014-02-21 at 15:24 +0100, Petr Vobornik wrote: > On 10.2.2014 14:12, Petr Vobornik wrote: > > On 13.1.2014 17:09, Petr Vobornik wrote: > >> Hi, > >> > >> these patches implements the OTP Web UI. > >> > >> Last 5 patches is the OTP UI. > >> > >> First 6 patches is a little refactoring/bug fixes needed for them. > >> General password dialog is introduced to avoid another implementation. > >> > >> Self-service UI is implemented to be very simple. Atm user can choose > >> only token name. Admin interface allows to enter all values. > >> > >> It's based on the RCUE work -> we need to push RCUE first. Thanks > >> Nathaniel for review of the last font package. It will speed things up. > >> > >> Know bugs: > >> - there is clash in id's of checkboxes preventing editation of > >> subsequently displayed ones with the same name. Will be fixed in > >> separate patch. > >> - bugs caused by bugs in API (adding/removal of own tokens in > >> self-service, inability to enter key on token creation - > >> https://fedorahosted.org/freeipa/ticket/4099) > >> - datetime format (widget+validator) will be implemented in separate > >> patch > >> - no support of not reviewed CLI patches (HOTP..) > >> > >> Cgit: > >> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >> > >> https://fedorahosted.org/freeipa/ticket/3369 > >> > > > > patch 540-1 has been updated > > - QR code is centered > > - QR code correction level was lowered from H to M > > > > All other current patches from sub-threads are attached as well (it was > > getting hard to keep track of them). > > > > Attaching new version of patch 537: 537-4 > > It: > * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter > field in details facet > * removes 'default' radio button in adder dialog in ipatokenotpalgorithm > and ipatokenotpdigits field > > > Btw I've encountered an issue on Web UI login when: > - user is created > - token is created for him > - admin resets user's password and changes auth type to 'otp' > - user tries to login with psw+otp > > The initial login-password call is successful but subsequent change > password fails - it uses the old psw+otp. > > I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 > which is almost implemented. > > > I also plan to hide fields without any value in otp token details page > in self-service mode. This will be done after #3903 because some > prerequisites for #3903 add useful code for that task. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Fri Feb 21 21:18:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Feb 2014 16:18:15 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53077A50.7090201@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <53077A50.7090201@redhat.com> Message-ID: <5307C297.9010000@redhat.com> On 02/21/2014 11:09 AM, Martin Kosek wrote: > On 02/21/2014 04:37 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>>> things >>>>>>>>>>> now, >>>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>>> Foreman. >>>>>>>>>>> >>>>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>>>> specific to >>>>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>>>> cases. If >>>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>>> similar. >>>>>>>>>>> >>>>>>>>>>> If general, we can go with >>>>>>>>>>> >>>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>>> >>>>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>>>> part of the >>>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>>> separation, as >>>>>>>>>>> compared >>>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>>> envision >>>>>>>>>> this as 3 separate subpackages? >>>>>>>>>> >>>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>>> server >>>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>>> layers. >>>>>>>>> >>>>>>>>> Then it seems to make sense to have 3 different packages that can be >>>>>>>>> optionally coninstalled and would probably share the same principal, >>>>>>>>> keytab and local REST API socket/port. >>>>>>>>> >>>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>>> What >>>>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>>> rework, though it will potentially pay dividends in the future. >>>>>>> I think that we can start where you are but drive towards this >>>>>>> architecture via refactoring. But we need to pick the right name now. >>>>>>> Even if the architecture is not there yet we should name the >>>>>>> package in >>>>>>> such way that it does not preclude us from moving towards a clean >>>>>>> architecture I described during the next iteration. >>>>>> Just having a hard time seeing the value. This would be like making >>>>>> each of the IPA plugins a separate package and somehow installing them >>>>>> individually. >>>>>> >>>>>> To do this you'd need at least 2 packages, a high level one with the >>>>>> "framework" and then a separate one for each data type. >>>>>> >>>>>> This could also be achieved, and likely more cleanly, without all >>>>>> these extra packages, as a simple configuration file. Once a package, >>>>>> always a package. >>>>>> >>>>>> Maybe I'm too close to the problem, but to me this is a >>>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>>> don't know that anything else is using it. If you want a RESTful >>>>>> server, then we enable REST in IPA directly, but selectively enabling >>>>>> and disabling APIs is not something we've done before. It has been >>>>>> controlled by ACIs instead. >>>>>> >>>>>> rob >>>>>> >>>>> We are trying to predict future here. Say we release it as you suggest. >>>>> Tomorrow we point someone upstream who wants to add users to IPA from a >>>>> similar proxy to this implementation and say use this as a model. >>>>> And then Rich needs the same but for DNS for Designate. >>>>> >>>>> What would be the best? Rob if you knew that tomorrow two other >>>>> developers will create similar proxies for users and DNS would you >>>>> change anything? Would you provide some guidelines to them? >>>>> If you are close to the problem you should be able to at least tell >>>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>>> If your recommendation is copy and paste then I suspect there will be >>>>> challenges of running these proxies on the same machine - they will >>>>> collide on ports and sockets. If we say "extend" shouldn't we use a more >>>>> generic name? >>>>> >>>> I'd say "use the existing IPA API". The only reason we have to write >>>> the smartproxy at all is to interoperate with another service that >>>> already has a well-defined remote server API which uses REST. >>>> >>>> rob >>> OK, so you think that proxy is one off. OK I am fine with it. >>> I was under assumption that it would be a beginning of a trend but I >>> might be wrong as I do not have valid arguments to prove or disprove one >>> way or another. >>> I guess time would show. >>> >>> Any objections to Rob's approach? >>> >> Ok, so try to summarize this long-running thread, I'll rename the subpackage to >> freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now >> it requires manual configuration so having the package installed should have no >> negative impacts (other than potentially pulling in additional dependencies). >> >> I'll leave it in smartproxy for now, it's just cleaner and better integrates >> with ipatests IMHO. > Ok, sounds reasonable to me. > >> Foreman supports SSL client auth which is great, by cherrypy does not yet. >> There is a pull request to add this, >> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >> . Foreman otherwise supports no other authentication method, so we're blocked >> with this. The certs for this would initially come out of Foreman/puppet. > Does that then mean that the first version will be without any authentication > or socket connection? Is that OK with everybody? > > Martin The pull request seems like a year old and suck. Any way to unstuck it? Can we accept the changes so far by not release it upstream until the change is accepted and help with it to be accepted? We can still start developing and integrating with Foreman using smart proxy without authentication for now and include it once the problem above is sorted. It would be a blocker for IPA release though so we should look into it but it should not be a blocker for this patch review. May be we should add a ticket to IPA trac this so that we explicitly indicate that we can't release if this cherrypy auth issue is not resolved. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Feb 21 21:29:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Feb 2014 16:29:31 -0500 Subject: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes In-Reply-To: <530738F9.6000509@redhat.com> References: <038.1cba090b8bd39942646e9915d52008be@fedorahosted.org> <053.0853d244c399eb72b7b0e720ee5ff0bb@fedorahosted.org> <53063FA3.9020703@redhat.com> <5306421A.6000801@redhat.com> <530650E9.5070802@redhat.com> <530738F9.6000509@redhat.com> Message-ID: <5307C53B.6040106@redhat.com> On 02/21/2014 06:31 AM, Petr Viktorin wrote: > On 02/20/2014 08:00 PM, Dmitri Pal wrote: >> On 02/20/2014 12:57 PM, Petr Viktorin wrote: >>> On 02/20/2014 06:47 PM, Dmitri Pal wrote: >>>> On 02/20/2014 12:39 PM, freeipa wrote: >>>>> #4185: Index plugin namespaces by classes >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> >>>>> >>>>> Reporter: pviktori | Owner: >>>>> pviktori >>>>> Type: refactoring | Status: >>>>> new >>>>> Priority: major | Milestone: >>>>> 0.0 >>>>> Component: IPA | NEEDS_TRIAGE >>>>> Resolution: | Version: >>>>> Blocked By: | Keywords: >>>>> Affects Documentation: 0 | Blocking: >>>>> Red Hat Bugzilla: | Patch posted for review: 0 >>>>> Design link: | External tracker: >>>>> Fedora test page: | Needs UI design: >>>>> Source: | Feature: >>>>> | Expertise: >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> >>>>> >>>>> Release Notes: >>>>> >>>>> >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> Comment (by pviktori): >>>>> >>>>> It's very easy to enable this so I'd like to do that now, and >>>>> adapt the >>>>> rest of the code whenever it's touched. >>>>> >>>> >>>> Should it be captured in some guidelines somewhere on the wiki? >>> >>> I was planning to add some instructions to the [Refactorings] page, as >>> I did with the new way to register plugins. >>> I'm open to other suggestions. >>> >>> >>> [Refactorings] http://www.freeipa.org/page/V3/Refactorings >>> >> If we have some do and do not's it should be similar to Style guide but >> rather developer best practices guide. >> >> It should be a quick reference of: >> do not do X do Y instead >> >> like do not treat DN as string - use DN class >> ... >> use this notation instead of that notation >> etc. >> >> Then we can point people to it as part of the review process. >> > > Aye sir! > http://www.freeipa.org/page/Coding_Best_Practices > Linked from http://www.freeipa.org/page/Contribute/Code#Change_the_code > Thank you, Sir! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 21 21:49:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 16:49:21 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5307C297.9010000@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <53077A50.7090201@redhat.com> <5307C297.9010000@redhat.com> Message-ID: <5307C9E1.102@redhat.com> Dmitri Pal wrote: > On 02/21/2014 11:09 AM, Martin Kosek wrote: >> On 02/21/2014 04:37 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>>>> Dmitri Pal wrote: >>>>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>>>> things >>>>>>>>>>>> now, >>>>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>>>> Foreman. >>>>>>>>>>>> >>>>>>>>>>>> I think the key for the right naming is a fact if this is >>>>>>>>>>>> really >>>>>>>>>>>> specific to >>>>>>>>>>>> Foreman or it is a truly general design usable also in other >>>>>>>>>>>> use >>>>>>>>>>>> cases. If >>>>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>>>> similar. >>>>>>>>>>>> >>>>>>>>>>>> If general, we can go with >>>>>>>>>>>> >>>>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>>>> >>>>>>>>>>>> The proxies may share the framework and only expose the >>>>>>>>>>>> requested >>>>>>>>>>>> part of the >>>>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>>>> separation, as >>>>>>>>>>>> compared >>>>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>>>> different servers, each providing a unique service? Or one >>>>>>>>>>> service >>>>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>>>> envision >>>>>>>>>>> this as 3 separate subpackages? >>>>>>>>>>> >>>>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>>>> server >>>>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>>>> layers. >>>>>>>>>> >>>>>>>>>> Then it seems to make sense to have 3 different packages that >>>>>>>>>> can be >>>>>>>>>> optionally coninstalled and would probably share the same >>>>>>>>>> principal, >>>>>>>>>> keytab and local REST API socket/port. >>>>>>>>>> >>>>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>>>> What >>>>>>>>> I designed is a quick-and-dirty get something up quickly. We >>>>>>>>> need to >>>>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>>>> rework, though it will potentially pay dividends in the future. >>>>>>>> I think that we can start where you are but drive towards this >>>>>>>> architecture via refactoring. But we need to pick the right name >>>>>>>> now. >>>>>>>> Even if the architecture is not there yet we should name the >>>>>>>> package in >>>>>>>> such way that it does not preclude us from moving towards a clean >>>>>>>> architecture I described during the next iteration. >>>>>>> Just having a hard time seeing the value. This would be like making >>>>>>> each of the IPA plugins a separate package and somehow installing >>>>>>> them >>>>>>> individually. >>>>>>> >>>>>>> To do this you'd need at least 2 packages, a high level one with the >>>>>>> "framework" and then a separate one for each data type. >>>>>>> >>>>>>> This could also be achieved, and likely more cleanly, without all >>>>>>> these extra packages, as a simple configuration file. Once a >>>>>>> package, >>>>>>> always a package. >>>>>>> >>>>>>> Maybe I'm too close to the problem, but to me this is a >>>>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>>>> don't know that anything else is using it. If you want a RESTful >>>>>>> server, then we enable REST in IPA directly, but selectively >>>>>>> enabling >>>>>>> and disabling APIs is not something we've done before. It has been >>>>>>> controlled by ACIs instead. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> We are trying to predict future here. Say we release it as you >>>>>> suggest. >>>>>> Tomorrow we point someone upstream who wants to add users to IPA >>>>>> from a >>>>>> similar proxy to this implementation and say use this as a model. >>>>>> And then Rich needs the same but for DNS for Designate. >>>>>> >>>>>> What would be the best? Rob if you knew that tomorrow two other >>>>>> developers will create similar proxies for users and DNS would you >>>>>> change anything? Would you provide some guidelines to them? >>>>>> If you are close to the problem you should be able to at least tell >>>>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>>>> If your recommendation is copy and paste then I suspect there will be >>>>>> challenges of running these proxies on the same machine - they will >>>>>> collide on ports and sockets. If we say "extend" shouldn't we use >>>>>> a more >>>>>> generic name? >>>>>> >>>>> I'd say "use the existing IPA API". The only reason we have to write >>>>> the smartproxy at all is to interoperate with another service that >>>>> already has a well-defined remote server API which uses REST. >>>>> >>>>> rob >>>> OK, so you think that proxy is one off. OK I am fine with it. >>>> I was under assumption that it would be a beginning of a trend but I >>>> might be wrong as I do not have valid arguments to prove or disprove >>>> one >>>> way or another. >>>> I guess time would show. >>>> >>>> Any objections to Rob's approach? >>>> >>> Ok, so try to summarize this long-running thread, I'll rename the >>> subpackage to >>> freeipa-server-foreman-smartproxy to make it clearer what it is/does. >>> Right now >>> it requires manual configuration so having the package installed >>> should have no >>> negative impacts (other than potentially pulling in additional >>> dependencies). >>> >>> I'll leave it in smartproxy for now, it's just cleaner and better >>> integrates >>> with ipatests IMHO. >> Ok, sounds reasonable to me. >> >>> Foreman supports SSL client auth which is great, by cherrypy does not >>> yet. >>> There is a pull request to add this, >>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>> >>> . Foreman otherwise supports no other authentication method, so we're >>> blocked >>> with this. The certs for this would initially come out of >>> Foreman/puppet. >> Does that then mean that the first version will be without any >> authentication >> or socket connection? Is that OK with everybody? >> >> Martin > The pull request seems like a year old and suck. Any way to unstuck it? > Can we accept the changes so far by not release it upstream until the > change is accepted and help with it to be accepted? > We can still start developing and integrating with Foreman using smart > proxy without authentication for now and include it once the problem > above is sorted. > It would be a blocker for IPA release though so we should look into it > but it should not be a blocker for this patch review. > May be we should add a ticket to IPA trac this so that we explicitly > indicate that we can't release if this cherrypy auth issue is not resolved. > I've poked at the issue, we'll see what happens. It got a positive review but AFAICT needed rebasing and that was never done. Then we'd need to see about getting it backported. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-5-rest.patch Type: text/x-patch Size: 45662 bytes Desc: not available URL: From jcholast at redhat.com Mon Feb 24 09:18:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Feb 2014 10:18:19 +0100 Subject: [Freeipa-devel] [PATCH] 240 Always use real entry DNs for memberOf in ldap2 Message-ID: <530B0E5B.5010304@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-240-Always-use-real-entry-DNs-for-memberOf-in-ldap2.patch Type: text/x-patch Size: 906 bytes Desc: not available URL: From pvoborni at redhat.com Mon Feb 24 10:04:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Feb 2014 11:04:18 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1393009251.23210.47.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> Message-ID: <530B1922.7060809@redhat.com> On 21.2.2014 20:00, Nathaniel McCallum wrote: > Is it possible to do something more intelligent for the key and date > fields in the add-token UI? > > Date fields are currently just a text box. Is there any sort of calendar > we could use here? If not, I'm still unsure of what the format should be > for this field. It's the format you chose :), try to fill it in CLI, you will have the same proble. From API level it's just string, from LDAP it's generalized time. I've an UI patch prepared where you can write it in ISO format, with a validator attached to it, so user will be noticed about the format, but it's waiting for: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html > > The key field should probably have a note indicating that it is Base32 > encoding. It would also be nice to restrict the input to Base32 > characters. Maybe even automatic case correction... Actually I think it doesn't help much. Show me a person who can write base32 encoded string.... But I agree that a validator with some regex to limit the chars and a note that it should be base32 string is better. The question is what's the purpose of this field from user perspective. Is a human being suppose to fill it or is it meant to be only filled by some provisioning systems? In UI it's just as a backup? If there is a use case where user is suppose to choose the key, it would be better to fill the key and convert it to base32 string on a server. > > Nathaniel > > On Fri, 2014-02-21 at 15:24 +0100, Petr Vobornik wrote: >> On 10.2.2014 14:12, Petr Vobornik wrote: >>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>> Hi, >>>> >>>> these patches implements the OTP Web UI. >>>> >>>> Last 5 patches is the OTP UI. >>>> >>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>> General password dialog is introduced to avoid another implementation. >>>> >>>> Self-service UI is implemented to be very simple. Atm user can choose >>>> only token name. Admin interface allows to enter all values. >>>> >>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>> Nathaniel for review of the last font package. It will speed things up. >>>> >>>> Know bugs: >>>> - there is clash in id's of checkboxes preventing editation of >>>> subsequently displayed ones with the same name. Will be fixed in >>>> separate patch. >>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>> self-service, inability to enter key on token creation - >>>> https://fedorahosted.org/freeipa/ticket/4099) >>>> - datetime format (widget+validator) will be implemented in separate >>>> patch >>>> - no support of not reviewed CLI patches (HOTP..) >>>> >>>> Cgit: >>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>> >>>> https://fedorahosted.org/freeipa/ticket/3369 >>>> >>> >>> patch 540-1 has been updated >>> - QR code is centered >>> - QR code correction level was lowered from H to M >>> >>> All other current patches from sub-threads are attached as well (it was >>> getting hard to keep track of them). >>> >> >> Attaching new version of patch 537: 537-4 >> >> It: >> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter >> field in details facet >> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm >> and ipatokenotpdigits field >> >> >> Btw I've encountered an issue on Web UI login when: >> - user is created >> - token is created for him >> - admin resets user's password and changes auth type to 'otp' >> - user tries to login with psw+otp >> >> The initial login-password call is successful but subsequent change >> password fails - it uses the old psw+otp. >> >> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 >> which is almost implemented. >> >> >> I also plan to hide fields without any value in otp token details page >> in self-service mode. This will be done after #3903 because some >> prerequisites for #3903 add useful code for that task. >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Petr Vobornik From lkrispen at redhat.com Mon Feb 24 12:11:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 24 Feb 2014 13:11:14 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53036B7F.2030806@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> Message-ID: <530B36E2.9050101@redhat.com> Hi, here is a draft to start discussion. Lt me know if it is the right direction and what you're missing. https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Ludwig On 02/18/2014 03:17 PM, Jan Cholasta wrote: > Hi, > > On 18.2.2014 14:02, Ludwig Krispenz wrote: >> Hi, >> >> yesterday jan asked me about the status of the schema and if it would be >> ready for certificate storage an dthat puzzled me a bit and showed that >> I still do not really understand what you want to store in LDAP. >> Two me there are two very different approaches. >> >> 1] LDAP as store for high level objects like certs and keys >> For certs and related stuff there is rfc4523 and the schema for ldif >> exists. For keys we would decide if the key is stored in PKCS#8 format >> or as bind keypairs and define a key attribute and that's it. we could >> export keys with softhsm, (eventually convert them) and add to ldap, in >> the long term solution the PKCS#11 replacemnt would need to manage these >> high level objects > > I think RFC 4523 is not the right schema in this case, as it is suited > for PKIs rather than generic cryptographic data storage. For example, > RFC 4523 distinguishes between CA and end entity certificates, but in > PKCS#11 there are just certificates without any semantics attached to > them. > >> >> 2] low level replacement for eg the sqlite3 database in softhsm. >> That's what I sometimes get the impression what is wanted. SoftHsm has >> one component Softdatabase with an API, which more or less passes sets >> of attributes (attributes defined by PKCS#11) and then stores it as >> records in sql where each record has a keytype and opaque blob of data. >> If that is what is wanted the decision would be how fingrained the pkcs >> objects/attribute types would have to be mapped to ldap: one ldap >> attribute for each possible attribute type ? > > One-to-one mapping of attributes from PKCS#11 to LDAP would be the > most straightforward way of doing this, but I think we can do some > optimization for our needs. For example, like you said above, we can > use a single attribute containing PKCS#8 encoded private key rather > than using one attribute per private key component. > > I don't think we need an LDAP attribute for every possible PKCS#11 > attribute, ATM it would be sufficient to have just these attributes > necessary to represent private key, public key and certificate objects. > > So, I would say it should be something between high-level and low-level. > > Honza > From pspacek at redhat.com Mon Feb 24 12:36:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 13:36:12 +0100 Subject: [Freeipa-devel] [PATCH 0225] Remove unused variables and dead code from syncrepl_update() Message-ID: <530B3CBC.5020907@redhat.com> Hello, Remove unused variables and dead code from syncrepl_update(). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0225-Remove-unused-variables-and-dead-code-from-syncrepl_.patch Type: text/x-patch Size: 1546 bytes Desc: not available URL: From lslebodn at redhat.com Mon Feb 24 12:53:57 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 24 Feb 2014 13:53:57 +0100 Subject: [Freeipa-devel] [PATCH 0225] Remove unused variables and dead code from syncrepl_update() In-Reply-To: <530B3CBC.5020907@redhat.com> References: <530B3CBC.5020907@redhat.com> Message-ID: <20140224125356.GB7116@mail.corp.redhat.com> On (24/02/14 13:36), Petr Spacek wrote: >Hello, > >Remove unused variables and dead code from syncrepl_update(). > >-- >Petr^2 Spacek >From 0a779d8cbf7a9d63567967600786202a060d7859 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Mon, 24 Feb 2014 13:35:23 +0100 >Subject: [PATCH] Remove unused variables and dead code from syncrepl_update(). > >Signed-off-by: Petr Spacek >--- > src/ldap_helper.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >index c81131101648368e209414e7612623fad4405ff3..05951fccbc655aef20177ea4a905159141665800 100644 >--- a/src/ldap_helper.c >+++ b/src/ldap_helper.c >@@ -4274,8 +4274,6 @@ syncrepl_update(ldap_instance_t *inst, ldap_entry_t *entry, int chgtype) > dns_name_t zone_name; > dns_zone_t *zone_ptr = NULL; > char *dn = NULL; >- char *prevdn_ldap = NULL; >- char *prevdn = NULL; > char *dbname = NULL; > const char *ldap_base = NULL; > isc_boolean_t isbase; >@@ -4385,7 +4383,7 @@ syncrepl_update(ldap_instance_t *inst, ldap_entry_t *entry, int chgtype) > pevent->mctx = mctx; > pevent->dbname = dbname; > pevent->dn = dn; >- pevent->prevdn = prevdn; >+ pevent->prevdn = NULL; > pevent->chgtype = chgtype; > pevent->entry = entry; > isc_task_send(task, (isc_event_t **)&pevent); >@@ -4406,12 +4404,8 @@ cleanup: > isc_mem_free(mctx, dbname); > if (dn != NULL) > isc_mem_free(mctx, dn); >- if (prevdn != NULL) >- isc_mem_free(mctx, prevdn); > if (mctx != NULL) > isc_mem_detach(&mctx); >- if (prevdn_ldap != NULL) >- ldap_memfree(prevdn); > ldap_entry_destroy(inst->mctx, &entry); > if (task != NULL) > isc_task_detach(&task); >-- >1.8.5.3 > ACK LS From pspacek at redhat.com Mon Feb 24 13:04:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 14:04:31 +0100 Subject: [Freeipa-devel] [PATCH 0224-0225] Add function attributes warn_unused_result and nonnull and add missing CHECK()s to string operations In-Reply-To: <20140221181436.GD32238@mail.corp.redhat.com> References: <53076CC1.2070902@redhat.com> <20140221181436.GD32238@mail.corp.redhat.com> Message-ID: <530B435F.9020301@redhat.com> On 21.2.2014 19:14, Lukas Slebodnik wrote: > On (21/02/14 16:12), Petr Spacek wrote: >> Hello, >> >> Add function attributes warn_unused_result and nonnull >> where appropriate and add missing CHECK()s to string operations. >> >> Lukas, thanks for catching the missing CHECK() around str_new(). >> >> As a reward, you can review attached patches. >> >> Have fun! :-) >> >> -- >> Petr^2 Spacek > >>From 063f776fc083c1fa26419a1ea63df98b9953826f Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 21 Feb 2014 15:21:36 +0100 >> Subject: [PATCH] Add missing CHECK()s to string operations. >> >> Signed-off-by: Petr Spacek >> --- >> src/ldap_helper.c | 4 ++-- >> src/str.c | 4 ++-- >> src/str.h | 28 ++++++++++++++-------------- >> src/util.h | 2 ++ >> 4 files changed, 20 insertions(+), 18 deletions(-) >> >> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> index b0dd3391f4dca88992ac7869b34d943a381d51be..be37ce575c0965856afabcb59c5eba949ad902fd 100644 >> --- a/src/ldap_helper.c >> +++ b/src/ldap_helper.c >> @@ -1772,7 +1772,7 @@ ldap_replace_serial(ldap_instance_t *inst, dns_name_t *zone, >> >> REQUIRE(inst != NULL); >> >> - str_new(inst->mctx, &dn); >> + CHECK(str_new(inst->mctx, &dn)); >> CHECK(dnsname_to_dn(inst->zone_register, zone, dn)); >> >> change.mod_op = LDAP_MOD_REPLACE; >> @@ -2405,7 +2405,7 @@ ldap_query(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn, >> CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); >> >> va_start(ap, filter); >> - str_vsprintf(ldap_qresult->query_string, filter, ap); >> + CHECK(str_vsprintf(ldap_qresult->query_string, filter, ap)); >> va_end(ap); > ^^^^^^^^^^ > va_end have to be called every time. > It would be better to move check after va_end(ap) > va_start(ap, filter); > result = str_vsprintf(ldap_qresult->query_string, filter, ap); > va_end(ap); > CHECK(result); > > Fixed and pushed to master: 960e00f4dee9a4be82c61a968e7b31aa863638cd >>From 50cb2a22cad24463145b8e18582d13fc20dc8011 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 21 Feb 2014 15:58:19 +0100 >> Subject: [PATCH] Add function attributes warn_unused_result and nonnull where >> appropriate. >> >> Signed-off-by: Petr Spacek >> --- >> src/acl.c | 22 ++++---- >> src/acl.h | 6 +- >> src/fs.h | 4 +- >> src/fwd_register.h | 10 ++-- >> src/krb5_helper.c | 2 +- >> src/krb5_helper.h | 2 +- >> src/ldap_convert.c | 8 +-- >> src/ldap_convert.h | 10 ++-- >> src/ldap_entry.c | 2 +- >> src/ldap_entry.h | 26 ++++----- >> src/ldap_helper.c | 156 ++++++++++++++++++++++++++-------------------------- >> src/ldap_helper.h | 2 +- >> src/rbt_helper.c | 2 +- >> src/rbt_helper.h | 4 +- >> src/rdlist.c | 4 +- >> src/rdlist.h | 8 +-- >> src/semaphore.h | 4 +- >> src/settings.c | 4 +- >> src/settings.h | 18 +++--- >> src/syncrepl.c | 2 +- >> src/syncrepl.h | 14 ++--- >> src/zone_manager.c | 4 +- >> src/zone_manager.h | 6 +- >> src/zone_register.h | 18 +++--- >> 24 files changed, 169 insertions(+), 169 deletions(-) >> > > Patch works well. I did a small test with a function find_db_instance. Pushed to master: 7e4323eacb74ad6a5658cc256fc4c347abc01ddc > > - result = find_db_instance(name, &db_inst); > + find_db_instance(name, &db_inst); > > CC ldap_la-zone_manager.lo > ../src/zone_manager.c:126:2: error: ignoring return value of function declared with > warn_unused_result attribute [-Werror,-Wunused-result] > find_db_instance(name, &db_inst); > ^~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ > 1 error generated. > > Attribute "__attribute__((warn_unused_result))" is not generated > if macro __GNUC__ is not defined. (make CFLAGS+="-U__GNUC__") > > Some lines are longer than 80 columns, but I am not very familiar with > your coding style. Otherwise 2nd patch looks good. > > LS Thank you very much for your time! -- Petr^2 Spacek From pspacek at redhat.com Mon Feb 24 13:04:35 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 14:04:35 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Include missing header files. In-Reply-To: <53076DB7.10301@redhat.com> References: <20140221141247.GA32238@mail.corp.redhat.com> <53076DB7.10301@redhat.com> Message-ID: <530B4363.3090005@redhat.com> On 21.2.2014 16:16, Petr Spacek wrote: > On 21.2.2014 15:12, Lukas Slebodnik wrote: >> ehlo, >> >> Function get_krb5_tgt is declared in header file krb5_helper.h, but this header >> file was not included in implementation file krb5_helper.c >> >> Function fs_dirs_create is declared in header file fs.h, but this header file >> was not included in the implementation file fs.c >> >> LS > > ACK, thanks. Pushed to master: eb93b6796619e2a93031dbf60ef00f3c0c88b018 -- Petr^2 Spacek From pspacek at redhat.com Mon Feb 24 13:04:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 14:04:37 +0100 Subject: [Freeipa-devel] [PATCH 0225] Remove unused variables and dead code from syncrepl_update() In-Reply-To: <20140224125356.GB7116@mail.corp.redhat.com> References: <530B3CBC.5020907@redhat.com> <20140224125356.GB7116@mail.corp.redhat.com> Message-ID: <530B4365.9060108@redhat.com> On 24.2.2014 13:53, Lukas Slebodnik wrote: > On (24/02/14 13:36), Petr Spacek wrote: >> Hello, >> >> Remove unused variables and dead code from syncrepl_update(). >> >> -- >> Petr^2 Spacek > >>From 0a779d8cbf7a9d63567967600786202a060d7859 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Mon, 24 Feb 2014 13:35:23 +0100 >> Subject: [PATCH] Remove unused variables and dead code from syncrepl_update(). >> >> Signed-off-by: Petr Spacek >> --- >> src/ldap_helper.c | 8 +------- >> 1 file changed, 1 insertion(+), 7 deletions(-) >> >> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> index c81131101648368e209414e7612623fad4405ff3..05951fccbc655aef20177ea4a905159141665800 100644 >> --- a/src/ldap_helper.c >> +++ b/src/ldap_helper.c >> @@ -4274,8 +4274,6 @@ syncrepl_update(ldap_instance_t *inst, ldap_entry_t *entry, int chgtype) >> dns_name_t zone_name; >> dns_zone_t *zone_ptr = NULL; >> char *dn = NULL; >> - char *prevdn_ldap = NULL; >> - char *prevdn = NULL; >> char *dbname = NULL; >> const char *ldap_base = NULL; >> isc_boolean_t isbase; >> @@ -4385,7 +4383,7 @@ syncrepl_update(ldap_instance_t *inst, ldap_entry_t *entry, int chgtype) >> pevent->mctx = mctx; >> pevent->dbname = dbname; >> pevent->dn = dn; >> - pevent->prevdn = prevdn; >> + pevent->prevdn = NULL; >> pevent->chgtype = chgtype; >> pevent->entry = entry; >> isc_task_send(task, (isc_event_t **)&pevent); >> @@ -4406,12 +4404,8 @@ cleanup: >> isc_mem_free(mctx, dbname); >> if (dn != NULL) >> isc_mem_free(mctx, dn); >> - if (prevdn != NULL) >> - isc_mem_free(mctx, prevdn); >> if (mctx != NULL) >> isc_mem_detach(&mctx); >> - if (prevdn_ldap != NULL) >> - ldap_memfree(prevdn); >> ldap_entry_destroy(inst->mctx, &entry); >> if (task != NULL) >> isc_task_detach(&task); >> -- >> 1.8.5.3 >> > > ACK Thanks, pushed to master: 84aafe2fdb416ffa243f3b6815e1aad65db45a51 -- Petr^2 Spacek From pspacek at redhat.com Mon Feb 24 13:04:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 14:04:47 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix potential dereference of NULL pointer in sync_ctx_init In-Reply-To: <20140221183522.GE32238@mail.corp.redhat.com> References: <5273AD7D.5020402@redhat.com> <1939839260.12480070.1383650984710.JavaMail.root@redhat.com> <5282458B.4000808@redhat.com> <52AB3984.8010005@redhat.com> <20140221183522.GE32238@mail.corp.redhat.com> Message-ID: <530B436F.4090006@redhat.com> On 21.2.2014 19:35, Lukas Slebodnik wrote: > On (13/12/13 17:44), Petr Spacek wrote: >> On 12.11.2013 16:13, Petr Spacek wrote: >>> On 5.11.2013 12:29, Tomas Hozza wrote: >>>> ----- Original Message ----- >>>>> Hello, >>>>> >>>>> Improve performance of initial LDAP synchronization. >>>>> >>>>> Changes are not journaled and SOA serial is not incremented during initial >>>>> LDAP synchronization. >>>>> >>>>> This eliminates unnecessary synchronous writes to journal and also >>>>> unnecessary SOA serial writes to LDAP. >>>>> >>>>> See commit messages and comments in syncrepl.c for all the gory details. >>>> >>>> >>>> ACK. >>>> >>>> Patches look good. AXFR and IXFR works as expected. Also BIND starts up much >>>> faster with these patches. Good job... :) >>>> >>>> Regards, >>>> >>>> Tomas >>> >>> Hmm, further testing revealed that patch 203 changed behavior little bit: >>> Zones were loaded from LDAP correctly, but the SOA serial wasn't changed at >>> all. As a result, zone transfers return inconsistent results if the data in >>> LDAP are changed when BIND was not running. >>> >>> Patch 203-v2 imitates the old behavior from bind-dyndb-ldap 3.x: Zone serial >>> is bumped *once* for each zone, so any changed in LDAP will be transferred >>> correctly (with new serial). >> >> Patch 202 v2 was rebased and fixes reconnection to LDAP and solves >> deadlock caused by too eager locking. >> >> Patch 203 v3 was rebased and fixes reconnection to LDAP. >> >> These patches should go to master branch. >> >> -- >> Petr^2 Spacek >> > > When I was testing upcoming bind-dyndb-ldap 4.0 release, > There was an interesting warning from clang static analyser. > I thought it was a false passitive, but it isn't. > > Patch is attached > > >>From b73e345393d55fe411875d52e6fe4c98e1de8c04 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Mon, 9 Dec 2013 11:11:10 +0100 >> Subject: [PATCH] Detect end of initial LDAP synchronization phase. >> >> LDAP intermediate message with refreshDone = TRUE is translated to >> sync_barrier_wait() call. This call sends 'barrier event' to all tasks >> involved in syncrepl event processing. The call will return when all tasks >> have processed all events enqueued before the call. >> >> Effectively, all events produced by initial LDAP synchronization >> are processed first. Current state of synchronization is available via >> sync_state_get() call. >> >> See comments in syncrepl.c for all the gory details. >> >> Signed-off-by: Petr Spacek >> --- >> src/Makefile.am | 2 + >> src/ldap_helper.c | 67 +++++++++-- >> src/ldap_helper.h | 2 + >> src/syncrepl.c | 351 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> src/syncrepl.h | 63 ++++++++++ >> 5 files changed, 473 insertions(+), 12 deletions(-) >> create mode 100644 src/syncrepl.c >> create mode 100644 src/syncrepl.h >> > > > >> +/** >> + * Initialize synchronization context. >> + * >> + * @param[in] task Task used for first synchronization events. >> + * Typically the ldap_inst->task. >> + * @param[out] sctxp The new synchronization context. >> + * >> + * @post state == sync_init >> + * @post task_cnt == 1 >> + * @post tasks list contains the task >> + */ >> +isc_result_t >> +sync_ctx_init(isc_mem_t *mctx, isc_task_t *task, sync_ctx_t **sctxp) { >> + isc_result_t result; >> + sync_ctx_t *sctx = NULL; >> + isc_boolean_t lock_ready = ISC_FALSE; >> + isc_boolean_t cond_ready = ISC_FALSE; >> + isc_boolean_t refcount_ready = ISC_FALSE; >> + >> + REQUIRE(sctxp != NULL && *sctxp == NULL); > ^^^^^^^^^^^^^^ > *sctxp is NULL > > >> + REQUIRE(ISCAPI_TASK_VALID(task)); >> + >> + CHECKED_MEM_GET_PTR(mctx, sctx); >> + ZERO_PTR(sctx); >> + isc_mem_attach(mctx, &sctx->mctx); >> + >> + CHECK(isc_mutex_init(&sctx->mutex)); >> + lock_ready = ISC_TRUE; >> + CHECK(isc_condition_init(&sctx->cond)); >> + cond_ready = ISC_TRUE; >> + >> + /* refcount includes ldap_inst->task implicitly */ >> + CHECK(isc_refcount_init(&sctx->task_cnt, 0)); >> + refcount_ready = ISC_TRUE; >> + >> + ISC_LIST_INIT(sctx->tasks); >> + >> + sctx->state = sync_init; >> + CHECK(sync_task_add(sctx, task)); >> + >> + *sctxp = sctx; > ^^^^^^ > value to *sctxp is asigned only on this line. > >> + return ISC_R_SUCCESS; >> + >> +cleanup: > *sctxp will be NULL in cleanup section > >> + if (lock_ready == ISC_TRUE) >> + isc_mutex_destroy(&(*sctxp)->mutex); > &(NULL)->mutex > It does not look like a good idea :-) >> + if (cond_ready == ISC_TRUE) >> + isc_condition_init(&(*sctxp)->cond); >> + if (refcount_ready == ISC_TRUE) >> + isc_refcount_destroy(&(*sctxp)->task_cnt); >> + MEM_PUT_AND_DETACH(*sctxp); >> + return result; >> +} >> + > > LS ACK. Thank you for discovering this! Pushed to master: e346fbce099eacb1cd860e0624dcaaea36161169 -- Petr^2 Spacek From pspacek at redhat.com Mon Feb 24 13:05:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 14:05:01 +0100 Subject: [Freeipa-devel] [PATCH 0226-0227] Update NEWS & Bump NVR to 4.1 Message-ID: <530B437D.9080807@redhat.com> Hello, Update NEWS for upcoming 4.1 release & Bump NVR to 4.1. Pushed to master: da67bf43d89886dd2cce9f1fd3f75ce44c3ab9ed 2dec00224214045d7f00d901fb107b789c8c082d -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0226-Update-NEWS-for-upcoming-4.1-release.patch Type: text/x-patch Size: 653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0227-Bump-NVR-to-4.1.patch Type: text/x-patch Size: 1517 bytes Desc: not available URL: From pviktori at redhat.com Mon Feb 24 13:31:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Feb 2014 14:31:00 +0100 Subject: [Freeipa-devel] [PATCH] 240 Always use real entry DNs for memberOf in ldap2 In-Reply-To: <530B0E5B.5010304@redhat.com> References: <530B0E5B.5010304@redhat.com> Message-ID: <530B4994.4010200@redhat.com> On 02/24/2014 10:18 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Thanks, ACK, pushed to master: 792c3f9c8c65e24953241247a242490c8fb32492 -- Petr? From tbabej at redhat.com Mon Feb 24 13:58:13 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Feb 2014 14:58:13 +0100 Subject: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client Message-ID: <530B4FF5.60107@redhat.com> Hi, If SSH keys have not been generated prior to enrolling the client to the IPA server, they will not be uploaded to the server, since they're not present. Clarify this issue in the man pages. https://fedorahosted.org/freeipa/ticket/4055 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0154-man-sshd-should-be-run-at-least-once-before-client-e.patch Type: text/x-patch Size: 2094 bytes Desc: not available URL: From npmccallum at redhat.com Mon Feb 24 14:31:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 24 Feb 2014 09:31:49 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530B1922.7060809@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> Message-ID: <1393252309.21604.3.camel@localhost.localdomain> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: > On 21.2.2014 20:00, Nathaniel McCallum wrote: > > Is it possible to do something more intelligent for the key and date > > fields in the add-token UI? > > > > Date fields are currently just a text box. Is there any sort of calendar > > we could use here? If not, I'm still unsure of what the format should be > > for this field. > > It's the format you chose :), try to fill it in CLI, you will have the > same proble. From API level it's just string, from LDAP it's generalized > time. Is there a better option? I'm open to suggestions. > I've an UI patch prepared where you can write it in ISO format, with a > validator attached to it, so user will be noticed about the format, but > it's waiting for: > https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html > https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html > > > > > The key field should probably have a note indicating that it is Base32 > > encoding. It would also be nice to restrict the input to Base32 > > characters. Maybe even automatic case correction... > > Actually I think it doesn't help much. Show me a person who can write > base32 encoded string.... But I agree that a validator with some regex > to limit the chars and a note that it should be base32 string is better. > The question is what's the purpose of this field from user perspective. > Is a human being suppose to fill it or is it meant to be only filled by > some provisioning systems? In UI it's just as a backup? > > If there is a use case where user is suppose to choose the key, it would > be better to fill the key and convert it to base32 string on a server. I can't think of any case where a user would use the key field. However, there are at least two important cases where an admin would do this: 1. Hardware tokens 2. Transferring OATH (TOTP/HOTP) tokens from another system Nathaniel From pspacek at redhat.com Mon Feb 24 14:46:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 15:46:40 +0100 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 4.1 Message-ID: <530B5B50.90900@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 4.1. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-4.1-1.fc20 This release *requires an LDAP server with support for RFC 4533* (aka SyncRepl) and contains other significant changes. Please read all the following text! :-) == Changes in 4.0 and 4.1 == [1] Persistent search and zone refresh were replaced by RFC 4533 (SyncRepl). Options zone_refresh, cache_ttl and psearch were removed. LDAP attributes idnsZoneRefresh and idnsPersistentSearch were removed. https://fedorahosted.org/bind-dyndb-ldap/ticket/120 [2] Internal database was re-factored and replaced by RBT DB from BIND 9. As a result, read-query performance is nearly same as with plain BIND. Wildcard records are supported and queries for non-existing records do not impose additional load on LDAP server. https://fedorahosted.org/bind-dyndb-ldap/ticket/95 https://fedorahosted.org/bind-dyndb-ldap/ticket/6 [3] Plug-in creates journal file for each DNS zone in LDAP. This allows us to support IXFR. Working directory has to be writable by named, please see README - configuration option "directory". https://fedorahosted.org/bind-dyndb-ldap/ticket/64 [4] SOA serial auto-increment feature is now mandatory. The plugin has to have write access to LDAP. (Proper SOA serial maintenance is required for journaling.) [5] Data are not served to clients until initial synchronization with LDAP is finished. All queries are answered with NXDOMAIN during synchronization. [6] Crash caused by invalid SOA record was fixed. [7] Empty instance names (specified by "dynamic-db" directive) were disallowed. [8] Typo in LDAP schema was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/121 [9] Minor bugs in error handling found by static code analyzers were fixed. Known problems and limitations [1] LDAP MODRDN (rename) is not supported at the moment. [2] Zones enabled at run-time are not loaded properly. You have to restart BIND after changing idnsZoneActive attribute to TRUE. [3] Zones and records deleted when connection to LDAP is down are not refreshed properly after re-connection. You have to restart BIND to restore consistency. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. *Make sure that BIND can write to working directory as described in README* before you restart BIND. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 3.x version is supported as long as record types not supported by old version are not utilized. == 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 Spacek Software engineer Red Hat From pvoborni at redhat.com Mon Feb 24 14:48:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Feb 2014 15:48:03 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1393252309.21604.3.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> <1393252309.21604.3.camel@localhost.localdomain> Message-ID: <530B5BA3.4070403@redhat.com> On 24.2.2014 15:31, Nathaniel McCallum wrote: > On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: >> On 21.2.2014 20:00, Nathaniel McCallum wrote: >>> Is it possible to do something more intelligent for the key and date >>> fields in the add-token UI? >>> >>> Date fields are currently just a text box. Is there any sort of calendar >>> we could use here? If not, I'm still unsure of what the format should be >>> for this field. >> >> It's the format you chose :), try to fill it in CLI, you will have the >> same proble. From API level it's just string, from LDAP it's generalized >> time. > > Is there a better option? I'm open to suggestions. As I mentioned below, it's being implemented. The datetime patches will be send separately. The core OTP UI patches should not be blocked by them. > >> I've an UI patch prepared where you can write it in ISO format, with a >> validator attached to it, so user will be noticed about the format, but >> it's waiting for: >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html >> >>> >>> The key field should probably have a note indicating that it is Base32 >>> encoding. It would also be nice to restrict the input to Base32 >>> characters. Maybe even automatic case correction... >> >> Actually I think it doesn't help much. Show me a person who can write >> base32 encoded string.... But I agree that a validator with some regex >> to limit the chars and a note that it should be base32 string is better. >> The question is what's the purpose of this field from user perspective. >> Is a human being suppose to fill it or is it meant to be only filled by >> some provisioning systems? In UI it's just as a backup? >> >> If there is a use case where user is suppose to choose the key, it would >> be better to fill the key and convert it to base32 string on a server. > > I can't think of any case where a user would use the key field. > > However, there are at least two important cases where an admin would do > this: > 1. Hardware tokens > 2. Transferring OATH (TOTP/HOTP) tokens from another system > > Nathaniel > What is the input format for these two cases? Is it base32 so admin can enter it into UI or is it plain text so he has to use different tool to encode it to base32 and then fill into UI? -- Petr Vobornik From npmccallum at redhat.com Mon Feb 24 15:21:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 24 Feb 2014 10:21:43 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530B5BA3.4070403@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> <1393252309.21604.3.camel@localhost.localdomain> <530B5BA3.4070403@redhat.com> Message-ID: <1393255303.21604.12.camel@localhost.localdomain> On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: > On 24.2.2014 15:31, Nathaniel McCallum wrote: > > On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: > >> On 21.2.2014 20:00, Nathaniel McCallum wrote: > >>> Is it possible to do something more intelligent for the key and date > >>> fields in the add-token UI? > >>> > >>> Date fields are currently just a text box. Is there any sort of calendar > >>> we could use here? If not, I'm still unsure of what the format should be > >>> for this field. > >> > >> It's the format you chose :), try to fill it in CLI, you will have the > >> same proble. From API level it's just string, from LDAP it's generalized > >> time. > > > > Is there a better option? I'm open to suggestions. > > As I mentioned below, it's being implemented. The datetime patches will > be send separately. The core OTP UI patches should not be blocked by them. > > > > >> I've an UI patch prepared where you can write it in ISO format, with a > >> validator attached to it, so user will be noticed about the format, but > >> it's waiting for: > >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html > >> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html > >> > >>> > >>> The key field should probably have a note indicating that it is Base32 > >>> encoding. It would also be nice to restrict the input to Base32 > >>> characters. Maybe even automatic case correction... > >> > >> Actually I think it doesn't help much. Show me a person who can write > >> base32 encoded string.... But I agree that a validator with some regex > >> to limit the chars and a note that it should be base32 string is better. > >> The question is what's the purpose of this field from user perspective. > >> Is a human being suppose to fill it or is it meant to be only filled by > >> some provisioning systems? In UI it's just as a backup? > >> > >> If there is a use case where user is suppose to choose the key, it would > >> be better to fill the key and convert it to base32 string on a server. > > > > I can't think of any case where a user would use the key field. > > > > However, there are at least two important cases where an admin would do > > this: > > 1. Hardware tokens > > 2. Transferring OATH (TOTP/HOTP) tokens from another system > > > > Nathaniel > > > What is the input format for these two cases? Is it base32 so admin can > enter it into UI or is it plain text so he has to use different tool to > encode it to base32 and then fill into UI? In both of the above cases, I suspect the predominant use will be scripts written to take a token store and import the tokens. This is mostly a non-UI case. RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. This is largely because, with fewer characters and no case-sensitivity, Base32 is easier to type. I don't know of any other encodings in wide use. It would be nice to support both of them, but I'm not sure how this is possible. Suggestions are welcome. Nathaniel From pspacek at redhat.com Mon Feb 24 15:48:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 16:48:48 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE Message-ID: <530B69E0.7000705@redhat.com> Hello, Drop unnecessary #define _BSD_SOURCE. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0228-Drop-unnecessary-define-_BSD_SOURCE.patch Type: text/x-patch Size: 712 bytes Desc: not available URL: From lslebodn at redhat.com Mon Feb 24 17:56:37 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 24 Feb 2014 18:56:37 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <530B69E0.7000705@redhat.com> References: <530B69E0.7000705@redhat.com> Message-ID: <20140224175636.GD7116@mail.corp.redhat.com> On (24/02/14 16:48), Petr Spacek wrote: >Hello, > >Drop unnecessary #define _BSD_SOURCE. > >-- >Petr^2 Spacek >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Mon, 24 Feb 2014 16:48:09 +0100 >Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. > >Signed-off-by: Petr Spacek >--- > src/krb5_helper.c | 2 -- > 1 file changed, 2 deletions(-) > >diff --git a/src/krb5_helper.c b/src/krb5_helper.c >index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >--- a/src/krb5_helper.c >+++ b/src/krb5_helper.c >@@ -15,8 +15,6 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > >-#define _BSD_SOURCE >- > #include > #include > #include >-- >1.8.5.3 > Simo is an author (according to git blame) He defined this macro due to function setenv from man setenv: NAME setenv - change or add an environment variable SYNOPSIS #include int setenv(const char *name, const char *value, int overwrite); int unsetenv(const char *name); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): setenv(), unsetenv(): _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 ---------------------------------------------------------------------------- Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included header file . I tested only on fedora 20. It can be used on the other distributions. I would rather let this macro as is. If you really want to remove unused macro, you should look to the another file :-) ldap_helper.c:3829:0: warning: macro "LDAP_ENTRYCHANGE_ALL" is not used [-Wunused-macros] #define LDAP_ENTRYCHANGE_ALL (LDAP_SYNC_CAPI_ADD | LDAP_SYNC_CAPI_DELETE | LDAP_SYNC_CAPI_MODIFY) LS From npmccallum at redhat.com Mon Feb 24 19:26:27 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 24 Feb 2014 14:26:27 -0500 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration Message-ID: <1393269987.21604.16.camel@localhost.localdomain> Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0044-Periodically-refresh-global-ipa-kdb-configuration.patch Type: text/x-patch Size: 10147 bytes Desc: not available URL: From simo at redhat.com Mon Feb 24 19:20:46 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Feb 2014 14:20:46 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530B36E2.9050101@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> Message-ID: <1393269646.22754.410.camel@willson.li.ssimo.org> On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: > Hi, > > here is a draft to start discussion. Lt me know if it is the right > direction and what you're missing. > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema I think we need to think hard if you really can make all those attributes a MUST for the private key, as not all the attributes seem to apply to all encryption algorithms. Would have to have to add bogus attributes in some cases. Also can you add some examples on how we would use these classes to store DNS keys ? Ideally the example would show the LDAP tree and some example data in detail, and also what operation we think would be common. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Tue Feb 25 07:34:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Feb 2014 08:34:38 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <52CEC0C9.70905@redhat.com> References: <52CEC0C9.70905@redhat.com> Message-ID: <530C478E.4080307@redhat.com> Rebased to current master. On 01/09/2014 04:31 PM, Tomas Babej wrote: > Hi, > > Adds a krbPrincipalExpiration attribute to the user class > in user.py ipalib plugin as a DateTime parameter. > > Part of: https://fedorahosted.org/freeipa/ticket/3306 > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0138-2-ipalib-Expose-krbPrincipalExpiration-in-CLI.patch Type: text/x-patch Size: 7365 bytes Desc: not available URL: From tbabej at redhat.com Tue Feb 25 07:56:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Feb 2014 08:56:04 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <5305EFE5.70809@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> <5305E4EC.5000505@redhat.com> <20140220115852.GJ26583@redhat.com> <5305EFE5.70809@redhat.com> Message-ID: <530C4C94.40708@redhat.com> Given the fact that the patch has been ACKed, can we push the current iteration? On 02/20/2014 01:07 PM, Petr Viktorin wrote: > On 02/20/2014 12:58 PM, Jan Pazdziora wrote: >> On Thu, Feb 20, 2014 at 12:20:12PM +0100, Petr Viktorin wrote: >>> On 02/19/2014 04:54 PM, Jan Pazdziora wrote: >>>> >>>> However: since this is about restoring a backup, can't the backup >>>> contain the extended attributes, so that the SELinux context gets >>>> restored to the original state (which could be different from what >>>> the restorecon will give you)? >>> >>> Well, I guess you're the Beaker authority here. Is that necessary >> >> This is not about Beaker, is it? > > It is; all other use cases I know of use disposable or at least > single-purpose VMs. > >> But since you mention it, beakerlib does cp -a upon backup and restore >> >> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n484 >> >> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n593 >> >> >> for files to preserve the SELinux context, plus chcon --reference >> upon backup for directories: >> >> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n495 >> >> >>> when restoring? >>> The tests expect a "sane" state, and they return to that; using a >>> somehow customized machine to test on is a bad idea anyway. >> >> You might specifically want to run your test on non-sane state because >> you want to test that the non-sane state will for example produce >> correct error, SELinux-related or other. > > In that case you're on your own, you should wrap the test in custom > setup & teardown code. > > > There's no way we can perfectly restore a system after IPA has been > installed on it, much less if it was an unstable/testing version of > IPA, so returning to a sane state seems good for me. > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pspacek at redhat.com Tue Feb 25 08:54:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 09:54:08 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <20140224175636.GD7116@mail.corp.redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> Message-ID: <530C5A30.2070401@redhat.com> On 24.2.2014 18:56, Lukas Slebodnik wrote: > On (24/02/14 16:48), Petr Spacek wrote: >> Hello, >> >> Drop unnecessary #define _BSD_SOURCE. >> >> -- >> Petr^2 Spacek > >>From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Mon, 24 Feb 2014 16:48:09 +0100 >> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >> >> Signed-off-by: Petr Spacek >> --- >> src/krb5_helper.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >> --- a/src/krb5_helper.c >> +++ b/src/krb5_helper.c >> @@ -15,8 +15,6 @@ >> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >> */ >> >> -#define _BSD_SOURCE >> - >> #include >> #include >> #include >> -- >> 1.8.5.3 >> > > Simo is an author (according to git blame) > He defined this macro due to function setenv > > from man setenv: > NAME > setenv - change or add an environment variable > > SYNOPSIS > #include > > int setenv(const char *name, const char *value, int overwrite); > > int unsetenv(const char *name); > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > setenv(), unsetenv(): > _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 > ---------------------------------------------------------------------------- > > Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included > header file . I tested only on fedora 20. It can be used > on the other distributions. > > I would rather let this macro as is. Wow, I didn't expect that somebody will spend time on this :-) See build logs from Fedora 21 http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log and https://bugzilla.redhat.com/show_bug.cgi?id=1067110 Patches with 'the right' solution are welcome. I'm not going to spend more time on this. > If you really want to remove unused macro, you should look > to the another file :-) > > ldap_helper.c:3829:0: warning: macro "LDAP_ENTRYCHANGE_ALL" is not used [-Wunused-macros] > #define LDAP_ENTRYCHANGE_ALL (LDAP_SYNC_CAPI_ADD | LDAP_SYNC_CAPI_DELETE | LDAP_SYNC_CAPI_MODIFY) Have a nice day! -- Petr^2 Spacek From pviktori at redhat.com Tue Feb 25 09:30:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Feb 2014 10:30:25 +0100 Subject: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring In-Reply-To: <530C4C94.40708@redhat.com> References: <5304CFA1.9000007@redhat.com> <20140219155413.GB26583@redhat.com> <5305E4EC.5000505@redhat.com> <20140220115852.GJ26583@redhat.com> <5305EFE5.70809@redhat.com> <530C4C94.40708@redhat.com> Message-ID: <530C62B1.3010809@redhat.com> On 02/25/2014 08:56 AM, Tomas Babej wrote: > Given the fact that the patch has been ACKed, can we push the current > iteration? > > On 02/20/2014 01:07 PM, Petr Viktorin wrote: >> On 02/20/2014 12:58 PM, Jan Pazdziora wrote: >>> On Thu, Feb 20, 2014 at 12:20:12PM +0100, Petr Viktorin wrote: >>>> On 02/19/2014 04:54 PM, Jan Pazdziora wrote: >>>>> >>>>> However: since this is about restoring a backup, can't the backup >>>>> contain the extended attributes, so that the SELinux context gets >>>>> restored to the original state (which could be different from what >>>>> the restorecon will give you)? >>>> >>>> Well, I guess you're the Beaker authority here. Is that necessary >>> >>> This is not about Beaker, is it? >> >> It is; all other use cases I know of use disposable or at least >> single-purpose VMs. >> >>> But since you mention it, beakerlib does cp -a upon backup and restore >>> >>> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n484 >>> >>> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n593 >>> >>> >>> for files to preserve the SELinux context, plus chcon --reference >>> upon backup for directories: >>> >>> https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n495 >>> >>> >>>> when restoring? >>>> The tests expect a "sane" state, and they return to that; using a >>>> somehow customized machine to test on is a bad idea anyway. >>> >>> You might specifically want to run your test on non-sane state because >>> you want to test that the non-sane state will for example produce >>> correct error, SELinux-related or other. >> >> In that case you're on your own, you should wrap the test in custom >> setup & teardown code. >> >> >> There's no way we can perfectly restore a system after IPA has been >> installed on it, much less if it was an unstable/testing version of >> IPA, so returning to a sane state seems good for me. >> > Pushed to: master: bc0872cc0b33379a2a4109c9b353ac81d10cec83 ipa-3-3: edba30d2c6c9b01cf023abb6c5bcc378a3d56272 -- Petr? From pspacek at redhat.com Tue Feb 25 09:32:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 10:32:38 +0100 Subject: [Freeipa-devel] FreeIPA documentation: getting started & devel docs (FOSDEM takeaways - Software Archaeology for Beginners) Message-ID: <530C6336.7020503@redhat.com> Hello list, I have seen talk "Software Archaeology for Beginners" from FOSDEM 2014 [1] and I have couple notes: 1) User docs: Make sure that project's documentation tells its own story: Documentation is not so useful if it is a bunch of unrelated documents. Make sure that there is 'introduction' document starting with project description. The 'story' should continue to installation and very basic configuration and use cases. There should not be a 'gap' between steps like missing steps between installation and client configuration etc. We have something like that in RHEL IdM guide. Should we add "Getting Started" link to the very beginning of http://www.freeipa.org/page/Documentation#User_Documentation ? Maybe the RHEL guide is too huge and scary for 'getting started' so we would need to write something/compile it from existing blogs posts etc. 2) Pictures with a story are nice: Diagrams with system components are more useful when they *visualize some basic workflows step by step*. Imagine one SSSD client and one IPA server and describe what happens if the user enters his username and password to login prompt. - Arrow #0 from NSS db /passwd/ to SSSD component /s1/ with description /d/ - Arrow #1 from SSSD component /s1/ to IPA component /i1/ with description /d/ - Arrow #2 from NSS db /shadow/ to SSSD component /s2/ with description /d/ - Arrow #3 from SSSD component /s2/ to IPA component /i2/ with description /d/ etc. Such diagram not only helps to new developers but also gives tremendous help to people debugging the whole solution. (We have to admit that debugging is always PITA.) As usual, this sounds like a good task for newcomers (sorry Adam! :-). [1] http://video.fosdem.org/2014/Janson/Saturday/Software_Archaeology_for_Beginners.webm -- Petr^2 Spacek From pspacek at redhat.com Tue Feb 25 10:08:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 11:08:20 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393269646.22754.410.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> Message-ID: <530C6B94.9030201@redhat.com> On 24.2.2014 20:20, Simo Sorce wrote: > On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > I think we need to think hard if you really can make all those > attributes a MUST for the private key, as not all the attributes seem to > apply to all encryption algorithms. Would have to have to add bogus > attributes in some cases. > > Also can you add some examples on how we would use these classes to > store DNS keys ? We need to think about it a bit more. We plan to use PKCS#11 for key manipulation and data signing so the key itself will be unaware of any DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass. I'm discussing this with CZ.NIC guys and they propose to add a 'layer of indirection' between DNS zones and keys so one key set can be used by more DNS zones. They claim that it is relatively common practice and I trust them. Note that I'm not saying that IPA should use one key for multiple DNS zones by default, but the schema should be future-proof and allow that if necessary. Let's start with this proposal: DNS zone: idnsname=dnssec.test, cn=dns, dc=example There will be multi-valued attribute idnsseckey pointing to DNs of keys stored somewhere else. Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store keys there. I expect that PKCS#11 module will handle keys scattered over the LDAP tree somehow. > Ideally the example would show the LDAP tree and some example data in > detail, and also what operation we think would be common. -- Petr^2 Spacek From tbabej at redhat.com Tue Feb 25 10:15:12 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Feb 2014 11:15:12 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <52D5011D.30707@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> Message-ID: <530C6D30.5070509@redhat.com> On 01/14/2014 10:19 AM, Petr Viktorin wrote: > On 01/14/2014 09:27 AM, Jan Cholasta wrote: >> On 13.1.2014 14:57, Petr Vobornik wrote: >>> On 13.1.2014 13:41, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 10.1.2014 21:21, Nathaniel McCallum wrote: >>>>> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Adds a parameter that represents a DateTime format using >>>>>> datetime.datetime >>>>>> object from python's native datetime library. >>>>>> >>>>>> In the CLI, accepts one of the following formats: >>>>>> Accepts subset of values defined by ISO 8601: >>>>>> %Y-%m-%dT%H:%M:%S >>>>>> %Y-%m-%dT%H:%M >>>>>> '%Y%m%dT%H:%M:%S' >>>>>> '%Y%m%dT%H:%M' >>>>>> >>>>>> Also accepts LDAP Generalized time in the following format: >>>>>> '%Y%m%d%H%M%SZ' >>>>>> >>>>>> As a simplification, it does not deal with timezone info and ISO >>>>>> 8601 >>>>>> values with timezone info (+-hhmm) are rejected. Values are expected >>>>>> to be in the UTC timezone. >>>>>> >>>>>> Values are saved to LDAP as LDAP Generalized time values in the >>>>>> format >>>>>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To >>>>>> avoid >>>>>> confusion, in addition to subset of ISO 8601 values, the LDAP >>>>>> generalized >>>>>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as >>>>>> this >>>>>> is the >>>>>> format user will see on the output). >>>>>> >>>>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>>>> >>>>> The date/time syntax formats are not compliant with ISO 8601. You >>>>> stated >>>>> they are expected to be in UTC timezone, but no 'Z' is expected in >>>>> most >>>>> of them. This is not only non-standard, but would prevent you from >>>>> every >>>>> supporting local time in the future. >>>> >>>> +1, please require the trailing "Z". >>>> >>>> >>>> I think generalized time format should be the preferred one, as it is >>>> stored in LDAP and thus returned by commands. Also, do we really need >>>> all of these other formats? >>> >>> +1 That API should accept and always return generalized time. >>> >>> But UIs(CLI, Web) should display something more human readable. Like: >>> %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d >>> %H:%M:%SZ >>> ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or >>> 20140308141655Z >>> >>> Both should accept input value in the same format. Usage of different >>> output and input formats is confusing. Thus I agree with supporting >>> more >>> input formats. Decision whether it should be done on API level or >>> client >>> level is another matter. >> >> If you want human readable output, you have to do the conversion from >> generalized time on clients. If you want to support local time and >> timezones, you have to do some processing on the client as well. I would >> be perfectly happy if we supported only generalized time over the wire >> and did conversion from/to human readable on clients. >> >>> >>> I has been implementing the Web UI part and I think we should also >>> support a formats without time component. My initial impl. supports >>> combinations of: >>> >>> var dates = [ >>> ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], >>> ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] >>> ]; >>> >>> var times = [ >>> ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], >>> ['HH:mm', /^(\d\d):(\d\d)Z$/], >>> ['HH', /^(\d\d)Z$/] >>> ]; >>> + generalized time >>> ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] >>> >>> with /( |T)/ as divider and time optional. >>> >>> Both UIs should also tell the user what is the expected format (at >>> least >>> one of them). Getting incorrect format error without knowing it is >>> annoying. >> >> The current code raises a ValidationError including the list of formats. > > On yesterday's meeting, Simo said that on the wire and for CLI output, > we should use generalized time. > I disagree with using it for CLI ouptut, as I find generalized time > unreadable, but for the API it's the obvious choice. > > I believe we should require the "Z" postfix in all formats, so that 1) > users are forced to be aware that it's UTC, and 2) we can > theoretically support local time in the future. > > I think the supported input formats should be: > > %Y%m%d%H%M%SZ (generalized time) > %Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds) > %Y-%m-%dT%H:%MZ (ISO 8601, without seconds) > %Y-%m-%dZ (ISO 8601, date only) > > I also think we should accept a space instead of the "T", as Petr? > said above. > Thanks for review, everybody. * All accepted formats now require explicit Z * Accept values with ' ' instead of T * LDAP generalized time used on the wire with JSON * Minor implementation fixes Updated patch should address all the issues. -- Tomas Babej Associate Software Engeneer | 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-0137-2-ipalib-Add-DateTime-parameter.patch Type: text/x-patch Size: 7176 bytes Desc: not available URL: From lkrispen at redhat.com Tue Feb 25 10:28:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 11:28:51 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393269646.22754.410.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> Message-ID: <530C7063.7080706@redhat.com> On 02/24/2014 08:20 PM, Simo Sorce wrote: > On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > I think we need to think hard if you really can make all those > attributes a MUST for the private key, as not all the attributes seem to > apply to all encryption algorithms. Would have to have to add bogus > attributes in some cases. most of them are MAY, right now I have only" ipaPkcs11keyType ipaPkcs11label ipaPkcs11id" as MUST, but this can be argued. I looke what softhsm is doing when importing a keypair: |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin 123456 so I thought ID and LABEL woul be something provided from the application and should be there to describe the key. When storing the key (which is in pkcs#8 format) softhsm breaks up the data from the file and creates two pkcs#11 attribute templates: CK_ATTRIBUTE pubTemplate[] = { { CKA_CLASS, &pubClass, sizeof(pubClass) }, { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, { CKA_LABEL, label, strlen(label) }, { CKA_ID, objID, objIDLen }, { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } }; CK_ATTRIBUTE privTemplate[] = { { CKA_CLASS, &privClass, sizeof(privClass) }, { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, { CKA_LABEL, label, strlen(label) }, { CKA_ID, objID, objIDLen }, { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } }; I thought that CLASS would be translated to an LDAP objectclass, | |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to rsa)|. For the the private key itself it could be either stored completely as ipaPkcs8privateKey or as individual key attributes: ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, ipaPkcs11prim2 I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only defaults were used, but maybe this is my ignorance. And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed redundant to me, calculated from other components. If we need any of the attributes I omitted or if we need other attributes for other keytypes let me know. | > ipaPkcs8privateKey > > Also can you add some examples on how we would use these classes to > store DNS keys ? in what format do you provide the dns key ? The public key could be stored using modulus and exponent, do we need the flags, protocol adn algorithm attribute ? Does a schema for DNS records already exist ? > > Ideally the example would show the LDAP tree and some example data in > detail, and also what operation we think would be common. > > Simo. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Feb 25 12:21:49 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Feb 2014 13:21:49 +0100 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall Message-ID: <530C8ADD.9030803@redhat.com> Hi, As a part of a better cleanup procedure in the integration tests, make sure that winbindd is not running after uninstalling the IPA server. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0155-ipatests-Kill-winbindd-process-after-uninstall.patch Type: text/x-patch Size: 1217 bytes Desc: not available URL: From pspacek at redhat.com Tue Feb 25 12:30:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 13:30:01 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C7063.7080706@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> Message-ID: <530C8CC9.6010306@redhat.com> On 25.2.2014 11:28, Ludwig Krispenz wrote: > > On 02/24/2014 08:20 PM, Simo Sorce wrote: >> On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >>> Hi, >>> >>> here is a draft to start discussion. Lt me know if it is the right >>> direction and what you're missing. >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >> I think we need to think hard if you really can make all those >> attributes a MUST for the private key, as not all the attributes seem to >> apply to all encryption algorithms. Would have to have to add bogus >> attributes in some cases. > most of them are MAY, right now I have only" ipaPkcs11keyType ipaPkcs11label > ipaPkcs11id" as MUST, but this can be argued. I looke what softhsm is doing > when importing a keypair: > |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin 123456 > so I thought ID and LABEL woul be something provided from the application and > should be there to describe the key. When storing the key (which is in pkcs#8 > format) softhsm breaks up the data from the file and creates two pkcs#11 > attribute templates: > > > CK_ATTRIBUTE pubTemplate[] = { > { CKA_CLASS, &pubClass, sizeof(pubClass) }, > { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, > { CKA_LABEL, label, strlen(label) }, > { CKA_ID, objID, objIDLen }, > { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, > { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, > { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, > { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, > { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, > { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } > }; > CK_ATTRIBUTE privTemplate[] = { > { CKA_CLASS, &privClass, sizeof(privClass) }, > { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, > { CKA_LABEL, label, strlen(label) }, > { CKA_ID, objID, objIDLen }, > { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, > { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, > { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, > { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, > { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, > { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, > { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, > { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, > { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, > { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, > { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, > { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, > { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, > { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, > { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } > }; > > I thought that CLASS would be translated to an LDAP objectclass, | > > |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to rsa)|. > > For the the private key itself it could be either stored completely as > ipaPkcs8privateKey or as individual key attributes: ipaPkcs11publicExponent, > ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, ipaPkcs11prim2 > I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only defaults > were used, but maybe this is my ignorance. > And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed redundant > to me, calculated from other components. > > If we need any of the attributes I omitted or if we need other attributes for > other keytypes let me know. > | > >> ipaPkcs8privateKey >> >> Also can you add some examples on how we would use these classes to >> store DNS keys ? > in what format do you provide the dns key ? The public key could be stored > using modulus and exponent, do we need the flags, protocol adn algorithm > attribute ? Does a schema for DNS records already exist ? I would store DNSSEC-specific attributes in separate objectClass not to pollute pure PKCS#11 object classes. We have to be able to reproduce BIND key-files in the first implementation phase. I'm attaching public-private key pairs with different algorithms and flags to this e-mail. .key files contain DNSKEY record. It is basically public key, algorithm and flags as used by DNS clients. This is just one long string stored in normal idnsZone object. DNSKEY format is described on http://tools.ietf.org/html/rfc4034#section-2.3 .private files contain private keys and metadata for BIND, stored as key-value pairs. Some values can be derived from standard PKCS#11 attributes, some other have to be stored explicitly. For example (file Kdsa-ksk.+006+51642.private): > Private-key-format: v1.3 > Algorithm: 6 (NSEC3DSA) - We need to check if this can be derived from PKCS#11 type or not. (It could contain some DNSSEC-specific values.) - See http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > Prime(p): 6h4K2APYLBWTOFgoo9b2aMpCNz9QfhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJRc37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCtk1Dse6xdRrWAi1CXhpQfyHD > Subprime(q): tzQKBcEOLQT5/R7WzaMij86hwEM= > Base(g): uHVjFBrRFijLHFUWP+1aWZA1kiq85Wrn+npPu39F4P9VOIyasJaxSEncw7F0T1b2h+ADZ3/Ny1aQPBeJJ4o5NuTNUb92tifjr6peP8UZWG3NHoyU+RZJkoHIjaMiTHaPwBJItRQdEg+3nSCjmCEDNaFhUwwfG+yJ1FZJ > Private_value(x): avcS6O/s60qa4TZ8m5dlHvyiSQI= > Public_value(y): 5cb5cH2hLkIrLGO9xCv4fgWYOTN+txiVD4hRILTJHG8GXhadIPuKmvuvyc6ynnPIn8XgZnrpVqCJXteMoPk0ERQh1wmSoxPqks9pyKJlnIGADW8zH5uEueBT53lx6I2WkNXU+BK0/A7psVPpqo51iX1s0h5f - All this is algorithm-specific but we need to be able to extract each field separately for BIND-keyfile generation There is also a bunch of DNSSEC-specific timestamps: > Created: 20140225113328 > Publish: 20140327113328 - When the key will be made visible for the first time. > Activate: 20140327113328 - When the key will be used for signing the first time. - Probably can be mapped to PKCS#11 ?? > Inactive: 20140426113328 - From when the key will not be used for signing anymore. - Probably can be mapped to PKCS#11 ?? > Revoke: 20140526113328 > Delete: 20140625113328 There is also some information coded in file name: - name of the DNS zone - key_id - some value computed from the DNSKEY record - key_alg - the same value as in .key and .private files I hope this clarifies requirements from DNSSEC-point of view. We need to find what is possible to derive from PKCS#11 attributes and create auxiliary object class for remaining values. Petr^2 Spacek >> Ideally the example would show the LDAP tree and some example data in >> detail, and also what operation we think would be common. >> >> Simo. -------------- next part -------------- ; This is a key-signing key, keyid 51642, for dsa-ksk. ; Created: 20140225113328 (Tue Feb 25 12:33:28 2014) ; Publish: 20140327113328 (Thu Mar 27 12:33:28 2014) ; Activate: 20140327113328 (Thu Mar 27 12:33:28 2014) ; Revoke: 20140526113328 (Mon May 26 13:33:28 2014) ; Inactive: 20140426113328 (Sat Apr 26 13:33:28 2014) ; Delete: 20140625113328 (Wed Jun 25 13:33:28 2014) dsa-ksk. IN DNSKEY 257 3 6 CLc0CgXBDi0E+f0e1s2jIo/OocBD6h4K2APYLBWTOFgoo9b2aMpCNz9Q fhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJR c37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCt k1Dse6xdRrWAi1CXhpQfyHD3CAeskv+4dWMUGtEWKMscVRY/7VpZkDWS Krzlauf6ek+7f0Xg/1U4jJqwlrFISdzDsXRPVvaH4ANnf83LVpA8F4kn ijk25M1Rv3a2J+Ovql4/xRlYbc0ejJT5FkmSgciNoyJMdo/AEki1FB0S D7edIKOYIQM1oWFTDB8b7InUVkl2dDaY9uXG+XB9oS5CKyxjvcQr+H4F mDkzfrcYlQ+IUSC0yRxvBl4WnSD7ipr7r8nOsp5zyJ/F4GZ66VagiV7X jKD5NBEUIdcJkqMT6pLPaciiZZyBgA1vMx+bhLngU+d5ceiNlpDV1PgS tPwO6bFT6aqOdYl9bNIeXxn78vJ4kixgebZg -------------- next part -------------- Private-key-format: v1.3 Algorithm: 6 (NSEC3DSA) Prime(p): 6h4K2APYLBWTOFgoo9b2aMpCNz9QfhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJRc37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCtk1Dse6xdRrWAi1CXhpQfyHD3CAeskv8= Subprime(q): tzQKBcEOLQT5/R7WzaMij86hwEM= Base(g): uHVjFBrRFijLHFUWP+1aWZA1kiq85Wrn+npPu39F4P9VOIyasJaxSEncw7F0T1b2h+ADZ3/Ny1aQPBeJJ4o5NuTNUb92tifjr6peP8UZWG3NHoyU+RZJkoHIjaMiTHaPwBJItRQdEg+3nSCjmCEDNaFhUwwfG+yJ1FZJdnQ2mPY= Private_value(x): avcS6O/s60qa4TZ8m5dlHvyiSQI= Public_value(y): 5cb5cH2hLkIrLGO9xCv4fgWYOTN+txiVD4hRILTJHG8GXhadIPuKmvuvyc6ynnPIn8XgZnrpVqCJXteMoPk0ERQh1wmSoxPqks9pyKJlnIGADW8zH5uEueBT53lx6I2WkNXU+BK0/A7psVPpqo51iX1s0h5fGfvy8niSLGB5tmA= Created: 20140225113328 Publish: 20140327113328 Activate: 20140327113328 Revoke: 20140526113328 Inactive: 20140426113328 Delete: 20140625113328 -------------- next part -------------- ; This is a zone-signing key, keyid 34022, for dsa-zsk. ; Created: 20140225113316 (Tue Feb 25 12:33:16 2014) ; Publish: 20140327113316 (Thu Mar 27 12:33:16 2014) ; Activate: 20140327113316 (Thu Mar 27 12:33:16 2014) ; Inactive: 20140426113316 (Sat Apr 26 13:33:16 2014) ; Delete: 20140625113316 (Wed Jun 25 13:33:16 2014) dsa-zsk. IN DNSKEY 256 3 6 CLw577W6Afi25v14UBwxFbqI01XLtITHhMsRK8NUm4UV0OLIHcv0SCut QTByMPMYfzZwC790XXUfrIonXHiZmECXYKhKaqB2tUEV+2F2jIJ1saM4 n7RzN+LHQ4ucaSxLqpMnX4bktplp1N3V25nZGj18nc8zGGVqVIv6lK/G ALqsjWWw0o1/wYOUwvQetM6aOubPsukgklRhDkbdfsaBj35HqRzyH1XM d6Ws77IwbKC5P65EBID8rJ+SbBWUbOGINyaL6gwEQbCQEf+0+H+P9ftA rBMDULS8+6x1Tvm76uL+KslgB716oHBfxuMY96JSJMW8rnDZ5e0pQAAu xBibSdvq6/2BntzwC1/46/cZ6fpr/6x0jQsMgoYcaEz6nvy6HN6HpLKE 5PvkdyBKZoMFmw1NrrjLxzLgS3k4s2KaTFto520ZaiA4YRm/Bg5rufFp 6a9rI5mLpVqubKYgxLj+IOYRDnVMmhf6+1ciuhgskfzFueV451BQdP6S /mMS5w8uZBXxmnCG0UYYs4rkUCJ1IIhNSU8C -------------- next part -------------- Private-key-format: v1.3 Algorithm: 6 (NSEC3DSA) Prime(p): tITHhMsRK8NUm4UV0OLIHcv0SCutQTByMPMYfzZwC790XXUfrIonXHiZmECXYKhKaqB2tUEV+2F2jIJ1saM4n7RzN+LHQ4ucaSxLqpMnX4bktplp1N3V25nZGj18nc8zGGVqVIv6lK/GALqsjWWw0o1/wYOUwvQetM6aOubPsuk= Subprime(q): vDnvtboB+Lbm/XhQHDEVuojTVcs= Base(g): IJJUYQ5G3X7GgY9+R6kc8h9VzHelrO+yMGyguT+uRASA/KyfkmwVlGzhiDcmi+oMBEGwkBH/tPh/j/X7QKwTA1C0vPusdU75u+ri/irJYAe9eqBwX8bjGPeiUiTFvK5w2eXtKUAALsQYm0nb6uv9gZ7c8Atf+Ov3Gen6a/+sdI0= Private_value(x): QFxKGAu60nOWd4P+N0jLH8KgZto= Public_value(y): CwyChhxoTPqe/Loc3oeksoTk++R3IEpmgwWbDU2uuMvHMuBLeTizYppMW2jnbRlqIDhhGb8GDmu58Wnpr2sjmYulWq5spiDEuP4g5hEOdUyaF/r7VyK6GCyR/MW55XjnUFB0/pL+YxLnDy5kFfGacIbRRhiziuRQInUgiE1JTwI= Created: 20140225113316 Publish: 20140327113316 Activate: 20140327113316 Inactive: 20140426113316 Delete: 20140625113316 -------------- next part -------------- ; This is a key-signing key, keyid 3138, for ecc-ksk. ; Created: 20140225113429 (Tue Feb 25 12:34:29 2014) ; Publish: 20140327113429 (Thu Mar 27 12:34:29 2014) ; Activate: 20140327113429 (Thu Mar 27 12:34:29 2014) ; Revoke: 20140526113429 (Mon May 26 13:34:29 2014) ; Inactive: 20140426113429 (Sat Apr 26 13:34:29 2014) ; Delete: 20140625113429 (Wed Jun 25 13:34:29 2014) ecc-ksk. IN DNSKEY 257 3 14 N1IogBs1smfXszrY5b4COMa2+U95q8kbwzeMwnMzPF7F/vFoQ2NcLHgd ChuoBfBdXgzm6RIxqReUxAqfTS35GSCr2Gjzvjdfrqu8wen6oxW7ESnM iik/ji32LVPPD5DK -------------- next part -------------- Private-key-format: v1.3 Algorithm: 14 (ECDSAP384SHA384) PrivateKey: 9cRc/AcAff4+NNTUwSIMC2FJHmJGWPpgm9viw6EFaHzXyOw9tM2V7nIuKAWxcVIr Created: 20140225113429 Publish: 20140327113429 Activate: 20140327113429 Revoke: 20140526113429 Inactive: 20140426113429 Delete: 20140625113429 -------------- next part -------------- ; This is a zone-signing key, keyid 10600, for ecc-zsk. ; Created: 20140225113440 (Tue Feb 25 12:34:40 2014) ; Publish: 20140327113440 (Thu Mar 27 12:34:40 2014) ; Activate: 20140327113440 (Thu Mar 27 12:34:40 2014) ; Inactive: 20140426113440 (Sat Apr 26 13:34:40 2014) ; Delete: 20140625113440 (Wed Jun 25 13:34:40 2014) ecc-zsk. IN DNSKEY 256 3 14 6jbaCR8W+TgZVRYr2Wo1ql2nGqopSLwaJL4IdKT4BDPhXOv0mAaNFOs8 yN7qOoV6Kfsvs8hoNWYdbxQC4r+CGY4E2ZhXaBqYJrZuF3JIjLg06o2P bp7oiYZgYda59qjg -------------- next part -------------- Private-key-format: v1.3 Algorithm: 14 (ECDSAP384SHA384) PrivateKey: ZnF++WhaaTPuJNxWEn7sVbsqEqgDTDQsmEk4oq978QsmantE9k/Fg1aFQz8o5RaF Created: 20140225113440 Publish: 20140327113440 Activate: 20140327113440 Inactive: 20140426113440 Delete: 20140625113440 -------------- next part -------------- ; This is a key-signing key, keyid 54606, for rsa-ksk. ; Created: 20140225113234 (Tue Feb 25 12:32:34 2014) ; Publish: 20140327113234 (Thu Mar 27 12:32:34 2014) ; Activate: 20140327113234 (Thu Mar 27 12:32:34 2014) ; Revoke: 20140526113234 (Mon May 26 13:32:34 2014) ; Inactive: 20140426113234 (Sat Apr 26 13:32:34 2014) ; Delete: 20140625113234 (Wed Jun 25 13:32:34 2014) rsa-ksk. IN DNSKEY 257 3 7 AwEAAcmqk3If9PxNKFKlsLKVe7VxHGz6TRUXlAY8aCcdmBxnRIDRTyxV 3WbR1msoT+azoe485m9iOMFxmpldQYQhUqblGfXwf0ZTMSAmJQEstzM/ hwWob1BBBbX+jFXZKZS6iyEOQMO5mL7IDdQpLOBZ34aCOq7ScgO6GjRt U/SPU1blC3goWzsujn40PoLxiyVuul/pYglggSbW5oZt6vFsVyDsrOMF l3AEz76zZvQga33EgaJi4UhCLc4c9M+tklbikb6UF1OthzH5VdqcPjM9 WfcJV5NwRkb9uHiFz0UeOi2UyOvNuuyxRdcXjAc7vX9ryjfHrN9V12Ub 2uWR8tbQep8= -------------- next part -------------- Private-key-format: v1.3 Algorithm: 7 (NSEC3RSASHA1) Modulus: yaqTch/0/E0oUqWwspV7tXEcbPpNFReUBjxoJx2YHGdEgNFPLFXdZtHWayhP5rOh7jzmb2I4wXGamV1BhCFSpuUZ9fB/RlMxICYlASy3Mz+HBahvUEEFtf6MVdkplLqLIQ5Aw7mYvsgN1Cks4FnfhoI6rtJyA7oaNG1T9I9TVuULeChbOy6OfjQ+gvGLJW66X+liCWCBJtbmhm3q8WxXIOys4wWXcATPvrNm9CBrfcSBomLhSEItzhz0z62SVuKRvpQXU62HMflV2pw+Mz1Z9wlXk3BGRv24eIXPRR46LZTI68267LFF1xeMBzu9f2vKN8es31XXZRva5ZHy1tB6nw== PublicExponent: AQAB PrivateExponent: twZnkSEtv7nrCa80wa9nOhHxIXq9cJIYltxGDpIOVmDmzB6qw2seaE2zU0ef1JpdMZH19UrohbAsBlqbtmZj0/KDcDEX4eRo5muYFAvYLNvQGDN46xZIL5dZGCTiVwhCcvqzjq8n0KZR3qaMAwWuFy6kQbvfHEDPvZsnogJeObJDwHOGdubIacLl6z7k2bMzRPTE9jSUIBYah4qpt5F7x5nVE1ifn13FEWg+x2JjA0psGwKK6ltgkf4SP02AmH8iQhMDnuJB62ycHn77khPto/rXW18b9HQg7uRkqfN/CMw0GLovBzSajzL5Eew8nSdIUcXUBlA51H/tTiw6tN8w+Q== Prime1: 7NgeHz91ccQ4NpxTMmVnZvYsrf9eaLzwBp0NzNt0L75MRQ6CaNFHJx5hiEp0D1cdcVHec9i0oIuLBFb1RqrPIf//1LvQtHHO8WIKrMMIi5qYwA+L+G0f9N8hHJvOK2RSQ2+H0T+XP2j1rm8hznbF6Dd5aljaQAIUb/fGpMYzPcU= Prime2: 2foYtYt1slmNF1+N5FT2Cnr7teGe/TatsV1tw7eaN3gWlCXnMxRAm3SDDjg/igmpuwPjwguFf87uQFk/9ZmYdU3rcsk2ltKTdL+W0rRaszhfyq9daxuD8zKONleNcA99/aVbtrx24I9PUcTtMxQ3ujxl6DnYDe8nAGdJSxcioRM= Exponent1: wBB6TOjPOtTeqRqYNTQaaFqV3PxL+S/Oje5qtIf6boUpoI6lno6n3sc6XKXT/GSu0aiMdvFzeQXwVDKYcRgvJOlO85rjIpFwOjtBYNxAX8WcvZNd9LW5xn/zgBmxVWrjcyBMyZmB88AQC8a/aYjT8P6bjWxEgMeu/yW1hwXbo+k= Exponent2: sTu38Y0GUtCbduC792bZcyYSGg3sfwiBbBCCWjukCev7t9OlzBNwgLXYhaxYhX1b43LDMpi5oHT5pZqr9Z9ApkiH45oVZ8aqHKhXEtWQVd7FjIDQHXGO9SQrG6ZOm0oNcDqOeuN8aRQ9M0hCcWDD+wp29b5qnNHSTXKt1n9mKb8= Coefficient: SQRB5bWr7XBb0Z+GdnnhmDgGu9pgcFgWdEFiEogwc9i+IEMduhjB2+8xPp4rvN0LJqPJN+/+mnuP4RNgjMy5A2OwThHXK5qJb0VWuy1a4oPf+ka2x+bKq2sWLG4H/6F3kbpFYtzn8Nvs+eG7ibJFf0nvMgNn7xqax3LgJ5zHSNg= Created: 20140225113234 Publish: 20140327113234 Activate: 20140327113234 Revoke: 20140526113234 Inactive: 20140426113234 Delete: 20140625113234 -------------- next part -------------- ; This is a zone-signing key, keyid 61538, for rsa-zsk. ; Created: 20140225113244 (Tue Feb 25 12:32:44 2014) ; Publish: 20140327113244 (Thu Mar 27 12:32:44 2014) ; Activate: 20140327113244 (Thu Mar 27 12:32:44 2014) ; Inactive: 20140426113244 (Sat Apr 26 13:32:44 2014) ; Delete: 20140625113244 (Wed Jun 25 13:32:44 2014) rsa-zsk. IN DNSKEY 256 3 7 AwEAAd9X8XiXJQ7LiL0c8K7SjEdJEq7Jt4W04iFL6arv0aFcXbY2+XUF 6GB+vCR7if3ux6gL713nPNishyWpItuKcBu1L+NSAO8NU9uVTCwmHVXn TqNoJJVxwCXG8IFxZo4vlj3E+CvfiAhnghsmXL2NonZj8FFllIoQHu8y zAj0E0r3 -------------- next part -------------- Private-key-format: v1.3 Algorithm: 7 (NSEC3RSASHA1) Modulus: 31fxeJclDsuIvRzwrtKMR0kSrsm3hbTiIUvpqu/RoVxdtjb5dQXoYH68JHuJ/e7HqAvvXec82KyHJaki24pwG7Uv41IA7w1T25VMLCYdVedOo2gklXHAJcbwgXFmji+WPcT4K9+ICGeCGyZcvY2idmPwUWWUihAe7zLMCPQTSvc= PublicExponent: AQAB PrivateExponent: qyUM2MeZkhjNk30VwiF9dTK9qkrQ4xiVH8a4LFDRZsEM3pCJ3+7C/w6exaYVPA052cArkN2ddrveZDGTkIApHuNswhsjDPXq2yNaGPbmgZaTxfJWSBZzyDlwt8WTDiv8VVA8GOEk0kJocFEw01hkuVqP9mc9HL5sCpRnEtSRwGE= Prime1: +5E3hYXf7hKeS+ogTC1unFN90uId8J7QdS7euZrksR1KMZZonN9hzLLyoHgsp1mIecej7oHjNE6MQS7UWpRZ9Q== Prime2: 40dpy8LaTmsi1EZ6HevIO6P+/m56IYqNy1GGDtPHWaz14H2hbTRjcWxvXvZDFYIn7b2qGtRmfSiHUVvBrokhuw== Exponent1: 8ROUtWw50Bgfgnh3Qwk2urB4H6N5NaG7+tBTuGJrTh/XffW5gru/KT9Dq+v+PtFaK/nZazMl3HZ5ie2qqrMIEQ== Exponent2: dVIZ1Kri0fQP6I/w3Z0moVLIgEI7HTFOfJO6pdDAaRQVYCq5t4uBgb09yEFK48FqJxjuxCa8OQNAxsictCHpnQ== Coefficient: 406tbA5MnYprgYhDQ4momtJzPtnwmYAjp8rEwBt9LQVCokH4JJX8dF1p/QO6z+m//X6IeYCxM24iHpnszrPdDA== Created: 20140225113244 Publish: 20140327113244 Activate: 20140327113244 Inactive: 20140426113244 Delete: 20140625113244 From jcholast at redhat.com Tue Feb 25 12:47:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 13:47:23 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530B36E2.9050101@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> Message-ID: <530C90DB.9020206@redhat.com> Hi, here is a draft of the PKCS#11 design: . On 24.2.2014 13:11, Ludwig Krispenz wrote: > Hi, > > here is a draft to start discussion. Lt me know if it is the right > direction and what you're missing. > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema IMO we don't need attribute types for key components (ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't think we need such granularity in LDAP and it would limit us to RSA only (unless we add attribute types for every other key type). We can store both private keys and public keys in single attribute as a DER blob (I would name the attributes ipaPkcs11privateKeyValue instead of ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for public keys, there already is ipaPkcs11certificateValue for certificates). OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when generating new key pairs, and the PKCS#11 spec says that keys generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have attribute types for all of them. > > Ludwig > > On 02/18/2014 03:17 PM, Jan Cholasta wrote: >> Hi, >> >> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>> Hi, >>> >>> yesterday jan asked me about the status of the schema and if it would be >>> ready for certificate storage an dthat puzzled me a bit and showed that >>> I still do not really understand what you want to store in LDAP. >>> Two me there are two very different approaches. >>> >>> 1] LDAP as store for high level objects like certs and keys >>> For certs and related stuff there is rfc4523 and the schema for ldif >>> exists. For keys we would decide if the key is stored in PKCS#8 format >>> or as bind keypairs and define a key attribute and that's it. we could >>> export keys with softhsm, (eventually convert them) and add to ldap, in >>> the long term solution the PKCS#11 replacemnt would need to manage these >>> high level objects >> >> I think RFC 4523 is not the right schema in this case, as it is suited >> for PKIs rather than generic cryptographic data storage. For example, >> RFC 4523 distinguishes between CA and end entity certificates, but in >> PKCS#11 there are just certificates without any semantics attached to >> them. >> >>> >>> 2] low level replacement for eg the sqlite3 database in softhsm. >>> That's what I sometimes get the impression what is wanted. SoftHsm has >>> one component Softdatabase with an API, which more or less passes sets >>> of attributes (attributes defined by PKCS#11) and then stores it as >>> records in sql where each record has a keytype and opaque blob of data. >>> If that is what is wanted the decision would be how fingrained the pkcs >>> objects/attribute types would have to be mapped to ldap: one ldap >>> attribute for each possible attribute type ? >> >> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >> most straightforward way of doing this, but I think we can do some >> optimization for our needs. For example, like you said above, we can >> use a single attribute containing PKCS#8 encoded private key rather >> than using one attribute per private key component. >> >> I don't think we need an LDAP attribute for every possible PKCS#11 >> attribute, ATM it would be sufficient to have just these attributes >> necessary to represent private key, public key and certificate objects. >> >> So, I would say it should be something between high-level and low-level. >> >> Honza >> > -- Jan Cholasta From abokovoy at redhat.com Tue Feb 25 12:50:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Feb 2014 14:50:13 +0200 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <530C8ADD.9030803@redhat.com> References: <530C8ADD.9030803@redhat.com> Message-ID: <20140225125013.GV16644@redhat.com> On Tue, 25 Feb 2014, Tomas Babej wrote: >Hi, > >As a part of a better cleanup procedure in the integration tests, >make sure that winbindd is not running after uninstalling the IPA >server. > >-- >Tomas Babej >Associate Software Engeneer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > > >>From ae2c3a7d3c559c53d7c4b61b80599145e8956db5 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Tue, 25 Feb 2014 12:53:44 +0100 >Subject: [PATCH] ipatests: Kill winbindd process after uninstall > >As a part of a better cleanup procedure in the integration tests, >make sure that winbindd is not running after uninstalling the IPA >server. >--- > ipatests/test_integration/tasks.py | 9 +++++++++ > 1 file changed, 9 insertions(+) > >diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..c180b0af0ba41b05f3e95ada63aa3aa68d6fc31c 100644 >--- a/ipatests/test_integration/tasks.py >+++ b/ipatests/test_integration/tasks.py >@@ -444,6 +444,15 @@ def uninstall_master(host): > > host.run_command(['ipa-server-install', '--uninstall', '-U'], > raiseonerr=False) >+ >+ # Processes that should not be left running after uninstall >+ # So far we encountered stray processes of winbind only, >+ # add more if required >+ >+ processes_to_kill = ('winbindd', ) >+ for process in processes_to_kill: >+ host.run_command(['killall', '-9', process], raiseonerr=False) >+ > unapply_fixes(host) > ACK. -- / Alexander Bokovoy From lkrispen at redhat.com Tue Feb 25 12:49:58 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 13:49:58 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C8CC9.6010306@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <530C8CC9.6010306@redhat.com> Message-ID: <530C9176.1050303@redhat.com> On 02/25/2014 01:30 PM, Petr Spacek wrote: > On 25.2.2014 11:28, Ludwig Krispenz wrote: >> >> On 02/24/2014 08:20 PM, Simo Sorce wrote: >>> On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> here is a draft to start discussion. Lt me know if it is the right >>>> direction and what you're missing. >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >>>> >>> I think we need to think hard if you really can make all those >>> attributes a MUST for the private key, as not all the attributes >>> seem to >>> apply to all encryption algorithms. Would have to have to add bogus >>> attributes in some cases. >> most of them are MAY, right now I have only" ipaPkcs11keyType >> ipaPkcs11label >> ipaPkcs11id" as MUST, but this can be argued. I looke what softhsm is >> doing >> when importing a keypair: >> |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin >> 123456 >> so I thought ID and LABEL woul be something provided from the >> application and >> should be there to describe the key. When storing the key (which is >> in pkcs#8 >> format) softhsm breaks up the data from the file and creates two pkcs#11 >> attribute templates: >> >> >> CK_ATTRIBUTE pubTemplate[] = { >> { CKA_CLASS, &pubClass, sizeof(pubClass) }, >> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >> { CKA_LABEL, label, strlen(label) }, >> { CKA_ID, objID, objIDLen }, >> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >> { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, >> { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, >> { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, >> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } >> }; >> CK_ATTRIBUTE privTemplate[] = { >> { CKA_CLASS, &privClass, sizeof(privClass) }, >> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >> { CKA_LABEL, label, strlen(label) }, >> { CKA_ID, objID, objIDLen }, >> { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, >> { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, >> { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, >> { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, >> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >> { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, >> { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, >> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, >> { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, >> { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, >> { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, >> { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, >> { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, >> { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } >> }; >> >> I thought that CLASS would be translated to an LDAP objectclass, | >> >> |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to >> rsa)|. >> >> For the the private key itself it could be either stored completely as >> ipaPkcs8privateKey or as individual key attributes: >> ipaPkcs11publicExponent, >> ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, >> ipaPkcs11prim2 >> I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only >> defaults >> were used, but maybe this is my ignorance. >> And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed >> redundant >> to me, calculated from other components. >> >> If we need any of the attributes I omitted or if we need other >> attributes for >> other keytypes let me know. >> | >> >>> ipaPkcs8privateKey >>> >>> Also can you add some examples on how we would use these classes to >>> store DNS keys ? >> in what format do you provide the dns key ? The public key could be >> stored >> using modulus and exponent, do we need the flags, protocol adn algorithm >> attribute ? Does a schema for DNS records already exist ? > > I would store DNSSEC-specific attributes in separate objectClass not > to pollute pure PKCS#11 object classes. > > We have to be able to reproduce BIND key-files in the first > implementation phase. I'm attaching public-private key pairs with > different algorithms and flags to this e-mail. > > .key files contain DNSKEY record. It is basically public key, > algorithm and flags as used by DNS clients. This is just one long > string stored in normal idnsZone object. > > DNSKEY format is described on > http://tools.ietf.org/html/rfc4034#section-2.3 but you already have a KeyRecord defined in ".../schema/60ipadns.ldif" which refers to RFC2535, which is obsoleted by 4034, the one you reference. Do you wan to split this up into several attributes in a new objectclass (why)? I will look at the examples, thanks. > > > > .private files contain private keys and metadata for BIND, stored as > key-value pairs. > > Some values can be derived from standard PKCS#11 attributes, some > other have to be stored explicitly. > > For example (file Kdsa-ksk.+006+51642.private): > > Private-key-format: v1.3 > > Algorithm: 6 (NSEC3DSA) > - We need to check if this can be derived from PKCS#11 type or not. > (It could contain some DNSSEC-specific values.) > - See > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > > > Prime(p): > 6h4K2APYLBWTOFgoo9b2aMpCNz9QfhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJRc37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCtk1Dse6xdRrWAi1CXhpQfyHD > > Subprime(q): tzQKBcEOLQT5/R7WzaMij86hwEM= > > Base(g): > uHVjFBrRFijLHFUWP+1aWZA1kiq85Wrn+npPu39F4P9VOIyasJaxSEncw7F0T1b2h+ADZ3/Ny1aQPBeJJ4o5NuTNUb92tifjr6peP8UZWG3NHoyU+RZJkoHIjaMiTHaPwBJItRQdEg+3nSCjmCEDNaFhUwwfG+yJ1FZJ > > Private_value(x): avcS6O/s60qa4TZ8m5dlHvyiSQI= > > Public_value(y): > 5cb5cH2hLkIrLGO9xCv4fgWYOTN+txiVD4hRILTJHG8GXhadIPuKmvuvyc6ynnPIn8XgZnrpVqCJXteMoPk0ERQh1wmSoxPqks9pyKJlnIGADW8zH5uEueBT53lx6I2WkNXU+BK0/A7psVPpqo51iX1s0h5f > - All this is algorithm-specific but we need to be able to extract > each field separately for BIND-keyfile generation > > There is also a bunch of DNSSEC-specific timestamps: > > Created: 20140225113328 > > Publish: 20140327113328 > - When the key will be made visible for the first time. > > Activate: 20140327113328 > - When the key will be used for signing the first time. > - Probably can be mapped to PKCS#11 ?? > > Inactive: 20140426113328 > - From when the key will not be used for signing anymore. > - Probably can be mapped to PKCS#11 ?? > > Revoke: 20140526113328 > > Delete: 20140625113328 > > There is also some information coded in file name: > - name of the DNS zone > - key_id - some value computed from the DNSKEY record > - key_alg - the same value as in .key and .private files > > I hope this clarifies requirements from DNSSEC-point of view. > > We need to find what is possible to derive from PKCS#11 attributes and > create auxiliary object class for remaining values. > > Petr^2 Spacek > >>> Ideally the example would show the LDAP tree and some example data in >>> detail, and also what operation we think would be common. >>> >>> Simo. > > > _______________________________________________ > 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 lkrispen at redhat.com Tue Feb 25 12:51:39 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 13:51:39 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C90DB.9020206@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> Message-ID: <530C91DB.1090107@redhat.com> On 02/25/2014 01:47 PM, Jan Cholasta wrote: > Hi, > > here is a draft of the PKCS#11 design: > . > > On 24.2.2014 13:11, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > IMO we don't need attribute types for key components > (ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, > ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't > think we need such granularity in LDAP and it would limit us to RSA > only (unless we add attribute types for every other key type). We can > store both private keys and public keys in single attribute as a DER > blob (I would name the attributes ipaPkcs11privateKeyValue instead of > ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for > public keys, there already is ipaPkcs11certificateValue for > certificates). > > OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, > CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE > when generating new key pairs, and the PKCS#11 spec says that keys > generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM > set, so I think we should have attribute types for all of them. ok. > >> >> Ludwig >> >> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> yesterday jan asked me about the status of the schema and if it >>>> would be >>>> ready for certificate storage an dthat puzzled me a bit and showed >>>> that >>>> I still do not really understand what you want to store in LDAP. >>>> Two me there are two very different approaches. >>>> >>>> 1] LDAP as store for high level objects like certs and keys >>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>> or as bind keypairs and define a key attribute and that's it. we could >>>> export keys with softhsm, (eventually convert them) and add to >>>> ldap, in >>>> the long term solution the PKCS#11 replacemnt would need to manage >>>> these >>>> high level objects >>> >>> I think RFC 4523 is not the right schema in this case, as it is suited >>> for PKIs rather than generic cryptographic data storage. For example, >>> RFC 4523 distinguishes between CA and end entity certificates, but in >>> PKCS#11 there are just certificates without any semantics attached to >>> them. >>> >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of >>>> data. >>>> If that is what is wanted the decision would be how fingrained the >>>> pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>> most straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can >>> use a single attribute containing PKCS#8 encoded private key rather >>> than using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and >>> low-level. >>> >>> Honza >>> >> > > From lkrispen at redhat.com Tue Feb 25 12:52:34 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 13:52:34 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C90DB.9020206@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> Message-ID: <530C9212.5010100@redhat.com> On 02/25/2014 01:47 PM, Jan Cholasta wrote: > Hi, > > here is a draft of the PKCS#11 design: > . > > On 24.2.2014 13:11, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > IMO we don't need attribute types for key components > (ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, > ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't > think we need such granularity in LDAP and it would limit us to RSA > only (unless we add attribute types for every other key type). We can > store both private keys and public keys in single attribute as a DER > blob (I would name the attributes ipaPkcs11privateKeyValue instead of > ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for > public keys, there already is ipaPkcs11certificateValue for > certificates). ok for me, if everybody agrees. > > OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, > CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE > when generating new key pairs, and the PKCS#11 spec says that keys > generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM > set, so I think we should have attribute types for all of them. ok. > >> >> Ludwig >> >> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> yesterday jan asked me about the status of the schema and if it >>>> would be >>>> ready for certificate storage an dthat puzzled me a bit and showed >>>> that >>>> I still do not really understand what you want to store in LDAP. >>>> Two me there are two very different approaches. >>>> >>>> 1] LDAP as store for high level objects like certs and keys >>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>> or as bind keypairs and define a key attribute and that's it. we could >>>> export keys with softhsm, (eventually convert them) and add to >>>> ldap, in >>>> the long term solution the PKCS#11 replacemnt would need to manage >>>> these >>>> high level objects >>> >>> I think RFC 4523 is not the right schema in this case, as it is suited >>> for PKIs rather than generic cryptographic data storage. For example, >>> RFC 4523 distinguishes between CA and end entity certificates, but in >>> PKCS#11 there are just certificates without any semantics attached to >>> them. >>> >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of >>>> data. >>>> If that is what is wanted the decision would be how fingrained the >>>> pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>> most straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can >>> use a single attribute containing PKCS#8 encoded private key rather >>> than using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and >>> low-level. >>> >>> Honza >>> >> > > From lkrispen at redhat.com Tue Feb 25 12:52:18 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 13:52:18 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C90DB.9020206@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> Message-ID: <530C9202.6090009@redhat.com> On 02/25/2014 01:47 PM, Jan Cholasta wrote: > Hi, > > here is a draft of the PKCS#11 design: > . > > On 24.2.2014 13:11, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > IMO we don't need attribute types for key components > (ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, > ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't > think we need such granularity in LDAP and it would limit us to RSA > only (unless we add attribute types for every other key type). We can > store both private keys and public keys in single attribute as a DER > blob (I would name the attributes ipaPkcs11privateKeyValue instead of > ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for > public keys, there already is ipaPkcs11certificateValue for > certificates). ok for me, if anybody agrees. > > OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, > CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE > when generating new key pairs, and the PKCS#11 spec says that keys > generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM > set, so I think we should have attribute types for all of them. ok. > >> >> Ludwig >> >> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> yesterday jan asked me about the status of the schema and if it >>>> would be >>>> ready for certificate storage an dthat puzzled me a bit and showed >>>> that >>>> I still do not really understand what you want to store in LDAP. >>>> Two me there are two very different approaches. >>>> >>>> 1] LDAP as store for high level objects like certs and keys >>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>> or as bind keypairs and define a key attribute and that's it. we could >>>> export keys with softhsm, (eventually convert them) and add to >>>> ldap, in >>>> the long term solution the PKCS#11 replacemnt would need to manage >>>> these >>>> high level objects >>> >>> I think RFC 4523 is not the right schema in this case, as it is suited >>> for PKIs rather than generic cryptographic data storage. For example, >>> RFC 4523 distinguishes between CA and end entity certificates, but in >>> PKCS#11 there are just certificates without any semantics attached to >>> them. >>> >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of >>>> data. >>>> If that is what is wanted the decision would be how fingrained the >>>> pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>> most straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can >>> use a single attribute containing PKCS#8 encoded private key rather >>> than using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and >>> low-level. >>> >>> Honza >>> >> > > From pspacek at redhat.com Tue Feb 25 12:58:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 13:58:08 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C9176.1050303@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <530C8CC9.6010306@redhat.com> <530C9176.1050303@redhat.com> Message-ID: <530C9360.2090104@redhat.com> On 25.2.2014 13:49, Ludwig Krispenz wrote: > > On 02/25/2014 01:30 PM, Petr Spacek wrote: >> On 25.2.2014 11:28, Ludwig Krispenz wrote: >>> >>> On 02/24/2014 08:20 PM, Simo Sorce wrote: >>>> On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> here is a draft to start discussion. Lt me know if it is the right >>>>> direction and what you're missing. >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >>>> I think we need to think hard if you really can make all those >>>> attributes a MUST for the private key, as not all the attributes seem to >>>> apply to all encryption algorithms. Would have to have to add bogus >>>> attributes in some cases. >>> most of them are MAY, right now I have only" ipaPkcs11keyType ipaPkcs11label >>> ipaPkcs11id" as MUST, but this can be argued. I looke what softhsm is doing >>> when importing a keypair: >>> |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin 123456 >>> so I thought ID and LABEL woul be something provided from the application and >>> should be there to describe the key. When storing the key (which is in pkcs#8 >>> format) softhsm breaks up the data from the file and creates two pkcs#11 >>> attribute templates: >>> >>> >>> CK_ATTRIBUTE pubTemplate[] = { >>> { CKA_CLASS, &pubClass, sizeof(pubClass) }, >>> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >>> { CKA_LABEL, label, strlen(label) }, >>> { CKA_ID, objID, objIDLen }, >>> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >>> { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, >>> { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, >>> { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, >>> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >>> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } >>> }; >>> CK_ATTRIBUTE privTemplate[] = { >>> { CKA_CLASS, &privClass, sizeof(privClass) }, >>> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >>> { CKA_LABEL, label, strlen(label) }, >>> { CKA_ID, objID, objIDLen }, >>> { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, >>> { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, >>> { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, >>> { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, >>> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >>> { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, >>> { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, >>> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >>> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, >>> { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, >>> { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, >>> { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, >>> { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, >>> { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, >>> { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } >>> }; >>> >>> I thought that CLASS would be translated to an LDAP objectclass, | >>> >>> |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to rsa)|. >>> >>> For the the private key itself it could be either stored completely as >>> ipaPkcs8privateKey or as individual key attributes: ipaPkcs11publicExponent, >>> ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, ipaPkcs11prim2 >>> I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only defaults >>> were used, but maybe this is my ignorance. >>> And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed redundant >>> to me, calculated from other components. >>> >>> If we need any of the attributes I omitted or if we need other attributes for >>> other keytypes let me know. >>> | >>> >>>> ipaPkcs8privateKey >>>> >>>> Also can you add some examples on how we would use these classes to >>>> store DNS keys ? >>> in what format do you provide the dns key ? The public key could be stored >>> using modulus and exponent, do we need the flags, protocol adn algorithm >>> attribute ? Does a schema for DNS records already exist ? >> >> I would store DNSSEC-specific attributes in separate objectClass not to >> pollute pure PKCS#11 object classes. >> >> We have to be able to reproduce BIND key-files in the first implementation >> phase. I'm attaching public-private key pairs with different algorithms and >> flags to this e-mail. >> >> .key files contain DNSKEY record. It is basically public key, algorithm and >> flags as used by DNS clients. This is just one long string stored in normal >> idnsZone object. >> >> DNSKEY format is described on http://tools.ietf.org/html/rfc4034#section-2.3 > but you already have a KeyRecord defined in ".../schema/60ipadns.ldif" which > refers to RFC2535, which is obsoleted by 4034, the one you reference. Do you > wan to split this up into several attributes in a new objectclass (why)? I'm sorry for not being clear. I don't insist on splitting it to multiple attributes as long as we are able to reconstruct BIND key files. "This is just one long string stored in normal idnsZone object." was meant as "we can re-use DNSKEY records as currently defined". Petr^2 Spacek > I will look at the examples, thanks. >> >> >> >> .private files contain private keys and metadata for BIND, stored as >> key-value pairs. >> >> Some values can be derived from standard PKCS#11 attributes, some other have >> to be stored explicitly. >> >> For example (file Kdsa-ksk.+006+51642.private): >> > Private-key-format: v1.3 >> > Algorithm: 6 (NSEC3DSA) >> - We need to check if this can be derived from PKCS#11 type or not. (It >> could contain some DNSSEC-specific values.) >> - See >> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 >> >> >> > Prime(p): >> 6h4K2APYLBWTOFgoo9b2aMpCNz9QfhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJRc37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCtk1Dse6xdRrWAi1CXhpQfyHD >> >> > Subprime(q): tzQKBcEOLQT5/R7WzaMij86hwEM= >> > Base(g): >> uHVjFBrRFijLHFUWP+1aWZA1kiq85Wrn+npPu39F4P9VOIyasJaxSEncw7F0T1b2h+ADZ3/Ny1aQPBeJJ4o5NuTNUb92tifjr6peP8UZWG3NHoyU+RZJkoHIjaMiTHaPwBJItRQdEg+3nSCjmCEDNaFhUwwfG+yJ1FZJ >> >> > Private_value(x): avcS6O/s60qa4TZ8m5dlHvyiSQI= >> > Public_value(y): >> 5cb5cH2hLkIrLGO9xCv4fgWYOTN+txiVD4hRILTJHG8GXhadIPuKmvuvyc6ynnPIn8XgZnrpVqCJXteMoPk0ERQh1wmSoxPqks9pyKJlnIGADW8zH5uEueBT53lx6I2WkNXU+BK0/A7psVPpqo51iX1s0h5f >> >> - All this is algorithm-specific but we need to be able to extract each >> field separately for BIND-keyfile generation >> >> There is also a bunch of DNSSEC-specific timestamps: >> > Created: 20140225113328 >> > Publish: 20140327113328 >> - When the key will be made visible for the first time. >> > Activate: 20140327113328 >> - When the key will be used for signing the first time. >> - Probably can be mapped to PKCS#11 ?? >> > Inactive: 20140426113328 >> - From when the key will not be used for signing anymore. >> - Probably can be mapped to PKCS#11 ?? >> > Revoke: 20140526113328 >> > Delete: 20140625113328 >> >> There is also some information coded in file name: >> - name of the DNS zone >> - key_id - some value computed from the DNSKEY record >> - key_alg - the same value as in .key and .private files >> >> I hope this clarifies requirements from DNSSEC-point of view. >> >> We need to find what is possible to derive from PKCS#11 attributes and >> create auxiliary object class for remaining values. >> >> Petr^2 Spacek >> >>>> Ideally the example would show the LDAP tree and some example data in >>>> detail, and also what operation we think would be common. >>>> >>>> Simo. From pvoborni at redhat.com Tue Feb 25 13:19:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 14:19:21 +0100 Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog Message-ID: <530C9859.7090709@redhat.com> Dialog loses focus when the links are clicked making the dialog uncontrollable by keyboard. This patch focuses the link again after expanding/collapsing the error list. Thus keeping the focus in a dialog https://fedorahosted.org/freeipa/ticket/4097 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0544-webui-Focus-expand-collapse-link-in-batch_error-dial.patch Type: text/x-patch Size: 1346 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 25 13:20:11 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 14:20:11 +0100 Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog Message-ID: <530C988B.90504@redhat.com> Fixes issue when: 1. 2 dialogs are opened 2. top dialog's close button is focused 3. user presses enter to execute 'close' action 4. dialog is immediately closed (enter key is still pressed) 5. second dialog automatically receives focus (it's top dialog now) 6. user releases the key 7. second dialog reacts to keyup event - which is by default confirmation mixin's confirm event 8. UNDESIRED behavior occurs Now confirmation mixin remembers which keys were pressed and released and reacts only to those which originated there. https://fedorahosted.org/freeipa/ticket/4098 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0545-webui-Don-t-act-on-keyboard-events-which-originated-.patch Type: text/x-patch Size: 3986 bytes Desc: not available URL: From simo at redhat.com Tue Feb 25 13:44:15 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 08:44:15 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C7063.7080706@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> Message-ID: <1393335855.18299.8.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 11:28 +0100, Ludwig Krispenz wrote: > On 02/24/2014 08:20 PM, Simo Sorce wrote: > > On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: > >> Hi, > >> > >> here is a draft to start discussion. Lt me know if it is the right > >> direction and what you're missing. > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > I think we need to think hard if you really can make all those > > attributes a MUST for the private key, as not all the attributes seem to > > apply to all encryption algorithms. Would have to have to add bogus > > attributes in some cases. > most of them are MAY, right now I have only" ipaPkcs11keyType > ipaPkcs11label ipaPkcs11id" as MUST, but this can be argued. I looke > what softhsm is doing when importing a keypair: > |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin 123456 > so I thought ID and LABEL woul be something provided from the > application and should be there to describe the key. When storing the > key (which is in pkcs#8 format) softhsm breaks up the data from the file > and creates two pkcs#11 attribute templates: Any reason why we should follow in detail what softshm does ? > CK_ATTRIBUTE pubTemplate[] = { > { CKA_CLASS, &pubClass, sizeof(pubClass) }, > { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, > { CKA_LABEL, label, strlen(label) }, > { CKA_ID, objID, objIDLen }, > { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, > { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, > { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, > { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, > { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, > { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } > }; > CK_ATTRIBUTE privTemplate[] = { > { CKA_CLASS, &privClass, sizeof(privClass) }, > { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, > { CKA_LABEL, label, strlen(label) }, > { CKA_ID, objID, objIDLen }, > { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, > { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, > { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, > { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, > { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, > { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, > { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, > { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, > { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, > { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, > { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, > { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, > { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, > { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, > { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } > }; > > I thought that CLASS would be translated to an LDAP objectclass, | > > |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to rsa)|. > > For the the private key itself it could be either stored completely as ipaPkcs8privateKey or as individual key attributes: ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, ipaPkcs11prim2 > I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only defaults were used, but maybe this is my ignorance. > And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed redundant to me, calculated from other components. > > If we need any of the attributes I omitted or if we need other attributes for other keytypes let me know. > | I am unsure that splitting keys this way really is useful to us, in what case an LDAP client will ever need such details ? Wouldn't it make sense to keep a pkcs11 blob and only split out attributes we need to identify the key for our needs ? > > ipaPkcs8privateKey > > > > Also can you add some examples on how we would use these classes to > > store DNS keys ? > in what format do you provide the dns key ? The public key could be > stored using modulus and exponent, do we need the flags, protocol adn > algorithm attribute ? Does a schema for DNS records already exist ? Well for example we store SSH keys in DNS, the whole key in one single attribute. I am not sure what is the point for us to split keys in parts, the only thing I see is a risk of messing up keys by inadvertently changing one of the attributes only and a burden to recompose keys every time they are queried. > > Ideally the example would show the LDAP tree and some example data in > > detail, and also what operation we think would be common. > > > > Simo. > > > Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Feb 25 13:47:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 14:47:00 +0100 Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <940530339.1630241.1392981061265.JavaMail.zimbra@redhat.com> References: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> <530724D8.8060503@redhat.com> <940530339.1630241.1392981061265.JavaMail.zimbra@redhat.com> Message-ID: <530C9ED4.3070206@redhat.com> On 21.2.2014 12:11, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Jan Cholasta" >> To: "Adam Misnyovszki" , freeipa-devel at redhat.com >> Sent: Friday, February 21, 2014 11:05:12 AM >> Subject: Re: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed >> >> Hi, >> >> On 20.2.2014 18:15, Adam Misnyovszki wrote: >>> Hi, >>> >>> this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 >>> maximum serial number field now accepts only positive numbers >>> >>> Thanks >>> Adam >> >> I think you should also add maxvalue to min_serial_number, so that they >> are consistent. >> >> Honza >> >> -- >> Jan Cholasta >> > > Makes sense, new patch added. > > Adam > Thanks, ACK. -- Jan Cholasta From simo at redhat.com Tue Feb 25 13:46:18 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 08:46:18 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C6B94.9030201@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> Message-ID: <1393335978.18299.10.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote: > On 24.2.2014 20:20, Simo Sorce wrote: > > Also can you add some examples on how we would use these classes to > > store DNS keys ? > > We need to think about it a bit more. We plan to use PKCS#11 for key > manipulation and data signing so the key itself will be unaware of any > DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass. > > I'm discussing this with CZ.NIC guys and they propose to add a 'layer of > indirection' between DNS zones and keys so one key set can be used by more DNS > zones. They claim that it is relatively common practice and I trust them. > > Note that I'm not saying that IPA should use one key for multiple DNS zones by > default, but the schema should be future-proof and allow that if necessary. Makes sense. > Let's start with this proposal: > DNS zone: idnsname=dnssec.test, cn=dns, dc=example > There will be multi-valued attribute idnsseckey pointing to DNs of keys stored > somewhere else. > > Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store > keys there. Ok, do we really want to have zones pointing at keys ? Or do we want keys have a list of zones they are supposed to apply to ? > I expect that PKCS#11 module will handle keys scattered over the LDAP tree > somehow. Sure as long as it can understand what the keys are for. > > Ideally the example would show the LDAP tree and some example data in > > detail, and also what operation we think would be common. > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Feb 25 13:52:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 14:52:00 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C90DB.9020206@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> Message-ID: <530CA000.2060003@redhat.com> On 25.2.2014 13:47, Jan Cholasta wrote: > here is a draft of the PKCS#11 design: > . I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 module will have to search for token with given TOKEN_ID or LABEL anyway, right? Do I miss something? Where the token will be placed if someobody generates new key via PKCS#11? How it will determine the right sub-tree? I would rather see keys stored under user account: uid=admin,cn=users,cn=accounts,dc=ipa,dc=example I like this approach because it allows you to manipulate with the user account easily without paying special attention to dangling references etc. Key storage under service account like: krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example doesn't solve problem with shared keys in DNS tree... I can imagine that objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 module will do full sub-tree search for particular ID or LABEL value, so the key can be always found. On the other side, it would require special handling for replica deletion etc. Petr^2 Spacek > On 24.2.2014 13:11, Ludwig Krispenz wrote: >> Hi, >> >> here is a draft to start discussion. Lt me know if it is the right >> direction and what you're missing. >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > IMO we don't need attribute types for key components (ipaPkcs11publicExponent, > ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1, ipaPkcs11prime2) > at all. As I said before, I don't think we need such granularity in LDAP and > it would limit us to RSA only (unless we add attribute types for every other > key type). We can store both private keys and public keys in single attribute > as a DER blob (I would name the attributes ipaPkcs11privateKeyValue instead of > ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for public keys, > there already is ipaPkcs11certificateValue for certificates). > > OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT, > CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when generating new > key pairs, and the PKCS#11 spec says that keys generated on a token should > have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have > attribute types for all of them. > >> >> Ludwig >> >> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> yesterday jan asked me about the status of the schema and if it would be >>>> ready for certificate storage an dthat puzzled me a bit and showed that >>>> I still do not really understand what you want to store in LDAP. >>>> Two me there are two very different approaches. >>>> >>>> 1] LDAP as store for high level objects like certs and keys >>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>> or as bind keypairs and define a key attribute and that's it. we could >>>> export keys with softhsm, (eventually convert them) and add to ldap, in >>>> the long term solution the PKCS#11 replacemnt would need to manage these >>>> high level objects >>> >>> I think RFC 4523 is not the right schema in this case, as it is suited >>> for PKIs rather than generic cryptographic data storage. For example, >>> RFC 4523 distinguishes between CA and end entity certificates, but in >>> PKCS#11 there are just certificates without any semantics attached to >>> them. >>> >>>> >>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>> one component Softdatabase with an API, which more or less passes sets >>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>> records in sql where each record has a keytype and opaque blob of data. >>>> If that is what is wanted the decision would be how fingrained the pkcs >>>> objects/attribute types would have to be mapped to ldap: one ldap >>>> attribute for each possible attribute type ? >>> >>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>> most straightforward way of doing this, but I think we can do some >>> optimization for our needs. For example, like you said above, we can >>> use a single attribute containing PKCS#8 encoded private key rather >>> than using one attribute per private key component. >>> >>> I don't think we need an LDAP attribute for every possible PKCS#11 >>> attribute, ATM it would be sufficient to have just these attributes >>> necessary to represent private key, public key and certificate objects. >>> >>> So, I would say it should be something between high-level and low-level. >>> >>> Honza From lkrispen at redhat.com Tue Feb 25 13:54:22 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 14:54:22 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393335855.18299.8.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> Message-ID: <530CA08E.2060304@redhat.com> On 02/25/2014 02:44 PM, Simo Sorce wrote: > On Tue, 2014-02-25 at 11:28 +0100, Ludwig Krispenz wrote: >> On 02/24/2014 08:20 PM, Simo Sorce wrote: >>> On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> here is a draft to start discussion. Lt me know if it is the right >>>> direction and what you're missing. >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >>> I think we need to think hard if you really can make all those >>> attributes a MUST for the private key, as not all the attributes seem to >>> apply to all encryption algorithms. Would have to have to add bogus >>> attributes in some cases. >> most of them are MAY, right now I have only" ipaPkcs11keyType >> ipaPkcs11label ipaPkcs11id" as MUST, but this can be argued. I looke >> what softhsm is doing when importing a keypair: >> |softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin 123456 >> so I thought ID and LABEL woul be something provided from the >> application and should be there to describe the key. When storing the >> key (which is in pkcs#8 format) softhsm breaks up the data from the file >> and creates two pkcs#11 attribute templates: > Any reason why we should follow in detail what softshm does ? because I did't know what is really needed. If you want to have a pkcs11 module, which stores data in ldap, I though it should have all the attributes potentially needed. Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE, so there is at least one requirement for fine grained attributes. > >> CK_ATTRIBUTE pubTemplate[] = { >> { CKA_CLASS, &pubClass, sizeof(pubClass) }, >> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >> { CKA_LABEL, label, strlen(label) }, >> { CKA_ID, objID, objIDLen }, >> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >> { CKA_VERIFY, &ckTrue, sizeof(ckTrue) }, >> { CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) }, >> { CKA_WRAP, &ckFalse, sizeof(ckFalse) }, >> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN } >> }; >> CK_ATTRIBUTE privTemplate[] = { >> { CKA_CLASS, &privClass, sizeof(privClass) }, >> { CKA_KEY_TYPE, &keyType, sizeof(keyType) }, >> { CKA_LABEL, label, strlen(label) }, >> { CKA_ID, objID, objIDLen }, >> { CKA_SIGN, &ckTrue, sizeof(ckTrue) }, >> { CKA_DECRYPT, &ckFalse, sizeof(ckFalse) }, >> { CKA_UNWRAP, &ckFalse, sizeof(ckFalse) }, >> { CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) }, >> { CKA_TOKEN, &ckTrue, sizeof(ckTrue) }, >> { CKA_PRIVATE, &ckTrue, sizeof(ckTrue) }, >> { CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) }, >> { CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE }, >> { CKA_MODULUS, keyMat->bigN, keyMat->sizeN }, >> { CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD }, >> { CKA_PRIME_1, keyMat->bigP, keyMat->sizeP }, >> { CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ }, >> { CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 }, >> { CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 }, >> { CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP } >> }; >> >> I thought that CLASS would be translated to an LDAP objectclass, | >> >> |CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to rsa)|. >> >> For the the private key itself it could be either stored completely as ipaPkcs8privateKey or as individual key attributes: ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1, ipaPkcs11prim2 >> I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only defaults were used, but maybe this is my ignorance. >> And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed redundant to me, calculated from other components. >> >> If we need any of the attributes I omitted or if we need other attributes for other keytypes let me know. >> | > I am unsure that splitting keys this way really is useful to us, in what > case an LDAP client will ever need such details ? Wouldn't it make sense > to keep a pkcs11 blob and only split out attributes we need to identify > the key for our needs ? > > >>> ipaPkcs8privateKey >>> >>> Also can you add some examples on how we would use these classes to >>> store DNS keys ? >> in what format do you provide the dns key ? The public key could be >> stored using modulus and exponent, do we need the flags, protocol adn >> algorithm attribute ? Does a schema for DNS records already exist ? > Well for example we store SSH keys in DNS, the whole key in one single > attribute. I am not sure what is the point for us to split keys in > parts, the only thing I see is a risk of messing up keys by > inadvertently changing one of the attributes only and a burden to > recompose keys every time they are queried. > >>> Ideally the example would show the LDAP tree and some example data in >>> detail, and also what operation we think would be common. >>> >>> Simo. >>> > Simo. > From lslebodn at redhat.com Tue Feb 25 14:05:40 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 25 Feb 2014 15:05:40 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <530C5A30.2070401@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> Message-ID: <20140225140540.GA6432@mail.corp.redhat.com> On (25/02/14 09:54), Petr Spacek wrote: >On 24.2.2014 18:56, Lukas Slebodnik wrote: >>On (24/02/14 16:48), Petr Spacek wrote: >>>Hello, >>> >>>Drop unnecessary #define _BSD_SOURCE. >>> >>>-- >>>Petr^2 Spacek >> >>>From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>From: Petr Spacek >>>Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>> >>>Signed-off-by: Petr Spacek >>>--- >>>src/krb5_helper.c | 2 -- >>>1 file changed, 2 deletions(-) >>> >>>diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>--- a/src/krb5_helper.c >>>+++ b/src/krb5_helper.c >>>@@ -15,8 +15,6 @@ >>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>> */ >>> >>>-#define _BSD_SOURCE >>>- >>>#include >>>#include >>>#include >>>-- >>>1.8.5.3 >>> >> >>Simo is an author (according to git blame) >>He defined this macro due to function setenv >> >>from man setenv: >>NAME >> setenv - change or add an environment variable >> >>SYNOPSIS >> #include >> >> int setenv(const char *name, const char *value, int overwrite); >> >> int unsetenv(const char *name); >> >> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >> >> setenv(), unsetenv(): >> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>---------------------------------------------------------------------------- >> >>Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>header file . I tested only on fedora 20. It can be used >>on the other distributions. >> >>I would rather let this macro as is. > >Wow, I didn't expect that somebody will spend time on this :-) > >See build logs from Fedora 21 >http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log You should have noticed this in the 1st mail. Because it is difference between removing unnecessary macro and depprecated usage of macro. /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >Patches with 'the right' solution are welcome. I'm not going to spend >more time on this. > ACK LS From jpazdziora at redhat.com Tue Feb 25 14:07:32 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 25 Feb 2014 15:07:32 +0100 Subject: [Freeipa-devel] [PATCH 0043] Remove NULLS from constants.py In-Reply-To: <1393000965.23210.38.camel@localhost.localdomain> References: <1393000965.23210.38.camel@localhost.localdomain> Message-ID: <20140225140732.GB12722@redhat.com> On Fri, Feb 21, 2014 at 11:42:45AM -0500, Nathaniel McCallum wrote: > In the parameters system, we have been checking for a positive list of > values which get converted to None. The problem is that this method can > in some cases throw warnings when type coercion doesn't work > (particularly, string to unicode). Instead, any values that evaluate to > False that are neither numeric nor boolean should be converted to None. > >From 98911a96a9b023081458e0f3674bf8096f8f5c43 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Fri, 21 Feb 2014 11:38:32 -0500 > Subject: [PATCH] Remove NULLS from constants.py > > In the parameters system, we have been checking for a positive list of values > which get converted to None. The problem is that this method can in some > cases throw warnings when type coercion doesn't work (particularly, string > to unicode). Instead, any values that evaluate to False that are neither > numeric nor boolean should be converted to None. [...] Ack, all original values pass the _is_null() test. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Tue Feb 25 14:11:08 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 09:11:08 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CA08E.2060304@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> Message-ID: <1393337468.18299.23.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: > > Any reason why we should follow in detail what softshm does ? > because I did't know what is really needed. If you want to have a > pkcs11 > module, which stores data in ldap, I though it should have all the > attributes potentially needed. > Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, > CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, > CKA_EXTRACTABLE, > so there is at least one requirement for fine grained attributes. Does OpenDNSSEC store them as separate entities and need access to them independently ? Or is this internal use that can be satisfied by unpacking a blob in OpenDNSSEC ? What does bind9 uses ? Petr, can you provide example key files ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Feb 25 14:30:52 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 15:30:52 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CA000.2060003@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> <530CA000.2060003@redhat.com> Message-ID: <530CA91C.2050007@redhat.com> On 25.2.2014 14:52, Petr Spacek wrote: > On 25.2.2014 13:47, Jan Cholasta wrote: >> here is a draft of the PKCS#11 design: >> . > > I don't understand the purpose of cn=crypto suffix. I thought that > PKCS#11 module will have to search for token with given TOKEN_ID or > LABEL anyway, right? Do I miss something? That's just a base DN for LDAP searches I came up with, it has no particular meaning. > > Where the token will be placed if someobody generates new key via > PKCS#11? How it will determine the right sub-tree? In order to generate a key, you must have an open session (see C_GenerateKeyPair). When you open a session, you must specify slot ID (see C_OpenSession). This is where the association takes place. > > I would rather see keys stored under user account: > uid=admin,cn=users,cn=accounts,dc=ipa,dc=example Do you mean storing private keys in a single attribute in user's entry? We wouldn't be able to store per-key metadata that way. If you mean storing private keys in entries under user's entry, there is nothing similar in our current schema, so I thought we just don't do that (there probably is a reason for that). (Anyway, we don't need to solve this right away, DNSSEC and CA certificates are what matters now.) > > I like this approach because it allows you to manipulate with the user > account easily without paying special attention to dangling references etc. References are managed automatically by the referint plugin. > > Key storage under service account like: > krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example > > doesn't solve problem with shared keys in DNS tree... I can imagine that > objects in LDAP have TOKEN_ID and LABEL attributes indexed and the > PKCS#11 module will do full sub-tree search for particular ID or LABEL > value, so the key can be always found. The objects need to be associated with a particular token somehow. Having them in a token-specific sub-tree seems like the easiest way to do it to me. > > On the other side, it would require special handling for replica > deletion etc. > > Petr^2 Spacek > >> On 24.2.2014 13:11, Ludwig Krispenz wrote: >>> Hi, >>> >>> here is a draft to start discussion. Lt me know if it is the right >>> direction and what you're missing. >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >> >> IMO we don't need attribute types for key components >> (ipaPkcs11publicExponent, >> ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1, >> ipaPkcs11prime2) >> at all. As I said before, I don't think we need such granularity in >> LDAP and >> it would limit us to RSA only (unless we add attribute types for every >> other >> key type). We can store both private keys and public keys in single >> attribute >> as a DER blob (I would name the attributes ipaPkcs11privateKeyValue >> instead of >> ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for >> public keys, >> there already is ipaPkcs11certificateValue for certificates). >> >> OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT, >> CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when >> generating new >> key pairs, and the PKCS#11 spec says that keys generated on a token >> should >> have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have >> attribute types for all of them. >> >>> >>> Ludwig >>> >>> On 02/18/2014 03:17 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 18.2.2014 14:02, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> yesterday jan asked me about the status of the schema and if it >>>>> would be >>>>> ready for certificate storage an dthat puzzled me a bit and showed >>>>> that >>>>> I still do not really understand what you want to store in LDAP. >>>>> Two me there are two very different approaches. >>>>> >>>>> 1] LDAP as store for high level objects like certs and keys >>>>> For certs and related stuff there is rfc4523 and the schema for ldif >>>>> exists. For keys we would decide if the key is stored in PKCS#8 format >>>>> or as bind keypairs and define a key attribute and that's it. we could >>>>> export keys with softhsm, (eventually convert them) and add to >>>>> ldap, in >>>>> the long term solution the PKCS#11 replacemnt would need to manage >>>>> these >>>>> high level objects >>>> >>>> I think RFC 4523 is not the right schema in this case, as it is suited >>>> for PKIs rather than generic cryptographic data storage. For example, >>>> RFC 4523 distinguishes between CA and end entity certificates, but in >>>> PKCS#11 there are just certificates without any semantics attached to >>>> them. >>>> >>>>> >>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>>> one component Softdatabase with an API, which more or less passes sets >>>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>>> records in sql where each record has a keytype and opaque blob of >>>>> data. >>>>> If that is what is wanted the decision would be how fingrained the >>>>> pkcs >>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>> attribute for each possible attribute type ? >>>> >>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the >>>> most straightforward way of doing this, but I think we can do some >>>> optimization for our needs. For example, like you said above, we can >>>> use a single attribute containing PKCS#8 encoded private key rather >>>> than using one attribute per private key component. >>>> >>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>> attribute, ATM it would be sufficient to have just these attributes >>>> necessary to represent private key, public key and certificate objects. >>>> >>>> So, I would say it should be something between high-level and >>>> low-level. >>>> >>>> Honza -- Jan Cholasta From simo at redhat.com Tue Feb 25 14:29:36 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 09:29:36 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530C9360.2090104@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <530C8CC9.6010306@redhat.com> <530C9176.1050303@redhat.com> <530C9360.2090104@redhat.com> Message-ID: <1393338576.18299.24.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 13:58 +0100, Petr Spacek wrote: > I'm sorry for not being clear. I don't insist on splitting it to > multiple > attributes as long as we are able to reconstruct BIND key files. > > "This is just one long string stored in normal idnsZone object." was > meant as > "we can re-use DNSKEY records as currently defined". > I personally favor using the defined DNSKEY records, as this is future proof. If the spec changes in future it will have to be backwards compatible, meaning we will be able to also follow the DNSSEC spec w/o major changes to our data. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Feb 25 14:32:05 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 09:32:05 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CA000.2060003@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> <530CA000.2060003@redhat.com> Message-ID: <1393338725.18299.26.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote: > On 25.2.2014 13:47, Jan Cholasta wrote: > > here is a draft of the PKCS#11 design: > > . > > I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 > module will have to search for token with given TOKEN_ID or LABEL anyway, > right? Do I miss something? > > Where the token will be placed if someobody generates new key via PKCS#11? How > it will determine the right sub-tree? > > I would rather see keys stored under user account: > uid=admin,cn=users,cn=accounts,dc=ipa,dc=example User objects should stay as leaves imo. We can use the managed-by attribute to easily allow control by a user. > I like this approach because it allows you to manipulate with the user account > easily without paying special attention to dangling references etc. the referential integrity plugin can handle references, usually. > Key storage under service account like: > krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example > doesn't solve problem with shared keys in DNS tree... I can imagine that > objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 > module will do full sub-tree search for particular ID or LABEL value, so the > key can be always found. DNS Keys should stay in the DNS tree IMHO. > On the other side, it would require special handling for replica deletion etc. Right. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Feb 25 14:43:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 15:43:15 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393338725.18299.26.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> <530CA000.2060003@redhat.com> <1393338725.18299.26.camel@willson.li.ssimo.org> Message-ID: <530CAC03.1010006@redhat.com> On 25.2.2014 15:32, Simo Sorce wrote: > On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote: >> On 25.2.2014 13:47, Jan Cholasta wrote: >>> here is a draft of the PKCS#11 design: >>> . >> >> I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 >> module will have to search for token with given TOKEN_ID or LABEL anyway, >> right? Do I miss something? >> >> Where the token will be placed if someobody generates new key via PKCS#11? How >> it will determine the right sub-tree? >> >> I would rather see keys stored under user account: >> uid=admin,cn=users,cn=accounts,dc=ipa,dc=example > > User objects should stay as leaves imo. > We can use the managed-by attribute to easily allow control by a user. I have never understood to this design. Could you elaborate on that, please? I'm curious why it is designed in this way because from my point of view it adds complexity (managed by etc.) and I don't see the benefit. >> I like this approach because it allows you to manipulate with the user account >> easily without paying special attention to dangling references etc. > > the referential integrity plugin can handle references, usually. ... but the plugin can only delete references and nothing else, right? It works perfectly for user-group membership but it is not that great for keys. If you delete a user account then all associated keys will be there until somebody deletes them manually. That is the reason why I don't like this design. >> Key storage under service account like: >> krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example >> doesn't solve problem with shared keys in DNS tree... I can imagine that >> objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 >> module will do full sub-tree search for particular ID or LABEL value, so the >> key can be always found. > > DNS Keys should stay in the DNS tree IMHO. That seems like an optimal solution, sure. I didn't realize that PKCS#11 slot_id can be used to determine the right container for new keys. >> On the other side, it would require special handling for replica deletion etc. > > Right. > > Simo. -- Petr^2 Spacek From lkrispen at redhat.com Tue Feb 25 14:48:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 15:48:46 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393337468.18299.23.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> Message-ID: <530CAD4E.4060103@redhat.com> On 02/25/2014 03:11 PM, Simo Sorce wrote: > On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>> Any reason why we should follow in detail what softshm does ? >> because I did't know what is really needed. If you want to have a >> pkcs11 >> module, which stores data in ldap, I though it should have all the >> attributes potentially needed. >> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >> CKA_EXTRACTABLE, >> so there is at least one requirement for fine grained attributes. > Does OpenDNSSEC store them as separate entities and need access to them > independently ? It's all individual records in the attribute table in teh sql database, dont know what the access pattern is. > Or is this internal use that can be satisfied by unpacking a blob in > OpenDNSSEC ? > > What does bind9 uses ? Petr, can you provide example key files ? > > Simo. > From jcholast at redhat.com Tue Feb 25 15:00:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 16:00:36 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CAD4E.4060103@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAD4E.4060103@redhat.com> Message-ID: <530CB014.2050103@redhat.com> On 25.2.2014 15:48, Ludwig Krispenz wrote: > > On 02/25/2014 03:11 PM, Simo Sorce wrote: >> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>> Any reason why we should follow in detail what softshm does ? >>> because I did't know what is really needed. If you want to have a >>> pkcs11 >>> module, which stores data in ldap, I though it should have all the >>> attributes potentially needed. >>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>> CKA_EXTRACTABLE, >>> so there is at least one requirement for fine grained attributes. >> Does OpenDNSSEC store them as separate entities and need access to them >> independently ? > It's all individual records in the attribute table in teh sql database, > dont know what the access pattern is. >> Or is this internal use that can be satisfied by unpacking a blob in >> OpenDNSSEC ? >> >> What does bind9 uses ? Petr, can you provide example key files ? >> >> Simo. >> > Both OpenDNSSEC and BIND use PKCS#11 directly, so no blob unpacking. IMO key material (modulus, exponents, etc.) should be stored in a blob, but metadata (such as the CKAs above) should be in separate attributes (for starters, I don't think there is a way to encode them in PKCS#8, so we would have to invent our own blob type for private keys). -- Jan Cholasta From simo at redhat.com Tue Feb 25 14:58:53 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 09:58:53 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CAC03.1010006@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <530C90DB.9020206@redhat.com> <530CA000.2060003@redhat.com> <1393338725.18299.26.camel@willson.li.ssimo.org> <530CAC03.1010006@redhat.com> Message-ID: <1393340333.18299.32.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 15:43 +0100, Petr Spacek wrote: > On 25.2.2014 15:32, Simo Sorce wrote: > > On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote: > >> On 25.2.2014 13:47, Jan Cholasta wrote: > >>> here is a draft of the PKCS#11 design: > >>> . > >> > >> I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 > >> module will have to search for token with given TOKEN_ID or LABEL anyway, > >> right? Do I miss something? > >> > >> Where the token will be placed if someobody generates new key via PKCS#11? How > >> it will determine the right sub-tree? > >> > >> I would rather see keys stored under user account: > >> uid=admin,cn=users,cn=accounts,dc=ipa,dc=example > > > > User objects should stay as leaves imo. > > We can use the managed-by attribute to easily allow control by a user. > > I have never understood to this design. Could you elaborate on that, please? > I'm curious why it is designed in this way because from my point of view it > adds complexity (managed by etc.) and I don't see the benefit. One of the reasons is that normally you delete leaves with an ldap delete operation, bit that will fail if the object is a node in a subtree instead of a leaf. You can delete entire subtrees but you need to explicitly make a recursive delete and a lot of tools probably don't. Adding leaves therefore has consequences that should not be underestimated. > >> I like this approach because it allows you to manipulate with the user account > >> easily without paying special attention to dangling references etc. > > > > the referential integrity plugin can handle references, usually. > > ... but the plugin can only delete references and nothing else, right? It > works perfectly for user-group membership but it is not that great for keys. > If you delete a user account then all associated keys will be there until > somebody deletes them manually. > > That is the reason why I don't like this design. We can solve this through the use of the managed entries plugin too I think. We have ways to cope with this, I do not think we should waste too much time on it though, for now. > >> Key storage under service account like: > >> krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example > >> doesn't solve problem with shared keys in DNS tree... I can imagine that > >> objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 > >> module will do full sub-tree search for particular ID or LABEL value, so the > >> key can be always found. > > > > DNS Keys should stay in the DNS tree IMHO. > > That seems like an optimal solution, sure. I didn't realize that PKCS#11 > slot_id can be used to determine the right container for new keys. Ok. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Feb 25 14:59:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 15:59:50 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393337468.18299.23.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> Message-ID: <530CAFE6.1050007@redhat.com> On 25.2.2014 15:11, Simo Sorce wrote: > On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>> Any reason why we should follow in detail what softshm does ? >> because I did't know what is really needed. If you want to have a >> pkcs11 >> module, which stores data in ldap, I though it should have all the >> attributes potentially needed. >> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >> CKA_EXTRACTABLE, >> so there is at least one requirement for fine grained attributes. > > Does OpenDNSSEC store them as separate entities and need access to them > independently ? AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema doesn't matter as long as our PKCS#11 module can derive all values defined by standard. Honza, you did investigate OpenDNSSEC integration, please add some details if you can. > Or is this internal use that can be satisfied by unpacking a blob in > OpenDNSSEC ? > > What does bind9 uses ? Petr, can you provide example key files ? Private+public keys stored in files: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html Private keys stored in HSM and public keys in files: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html (I.e. some values in .private file are replaced by PKCS#11 label.) -- Petr^2 Spacek From pviktori at redhat.com Tue Feb 25 15:01:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Feb 2014 16:01:44 +0100 Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <530C9ED4.3070206@redhat.com> References: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> <530724D8.8060503@redhat.com> <940530339.1630241.1392981061265.JavaMail.zimbra@redhat.com> <530C9ED4.3070206@redhat.com> Message-ID: <530CB058.1070501@redhat.com> On 02/25/2014 02:47 PM, Jan Cholasta wrote: > On 21.2.2014 12:11, Adam Misnyovszki wrote: >> >> >> ----- Original Message ----- >>> From: "Jan Cholasta" >>> To: "Adam Misnyovszki" , freeipa-devel at redhat.com >>> Sent: Friday, February 21, 2014 11:05:12 AM >>> Subject: Re: [Freeipa-devel] [PATCH] Certificate search >>> max_serial_number problem fixed >>> >>> Hi, >>> >>> On 20.2.2014 18:15, Adam Misnyovszki wrote: >>>> Hi, >>>> >>>> this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 >>>> maximum serial number field now accepts only positive numbers >>>> >>>> Thanks >>>> Adam >>> >>> I think you should also add maxvalue to min_serial_number, so that they >>> are consistent. >>> >>> Honza >>> >>> -- >>> Jan Cholasta >>> >> >> Makes sense, new patch added. >> >> Adam >> > > Thanks, ACK. > Pushed to master: be7b1b94e300b137c34bab80df3dc91195259c89 -- Petr? From tbordaz at redhat.com Tue Feb 25 15:04:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 25 Feb 2014 16:04:39 +0100 Subject: [Freeipa-devel] 389-DS ACI improvement to control MODDN Message-ID: <530CB107.3020806@redhat.com> Hello, Ticket https://fedorahosted.org/389/ticket/47553, is a 389-ds enhancement to allow a finer access control during a MODDN (new superior) operation. The use case being to allow/deny a bound user to move an entry from one specified part of the DIT to an other part. This without the need to grant the ADD permission. I started a design of it http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation. Comments are welcomed. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Feb 25 15:05:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Feb 2014 16:05:39 +0100 Subject: [Freeipa-devel] [PATCH 0043] Remove NULLS from constants.py In-Reply-To: <20140225140732.GB12722@redhat.com> References: <1393000965.23210.38.camel@localhost.localdomain> <20140225140732.GB12722@redhat.com> Message-ID: <530CB143.9090709@redhat.com> On 02/25/2014 03:07 PM, Jan Pazdziora wrote: > On Fri, Feb 21, 2014 at 11:42:45AM -0500, Nathaniel McCallum wrote: >> In the parameters system, we have been checking for a positive list of >> values which get converted to None. The problem is that this method can >> in some cases throw warnings when type coercion doesn't work >> (particularly, string to unicode). Instead, any values that evaluate to >> False that are neither numeric nor boolean should be converted to None. > >> >From 98911a96a9b023081458e0f3674bf8096f8f5c43 Mon Sep 17 00:00:00 2001 >> From: Nathaniel McCallum >> Date: Fri, 21 Feb 2014 11:38:32 -0500 >> Subject: [PATCH] Remove NULLS from constants.py >> >> In the parameters system, we have been checking for a positive list of values >> which get converted to None. The problem is that this method can in some >> cases throw warnings when type coercion doesn't work (particularly, string >> to unicode). Instead, any values that evaluate to False that are neither >> numeric nor boolean should be converted to None. > > [...] > > Ack, all original values pass the _is_null() test. > Pushed to master: 4499b25be90227e54fc4a9f54598cadc8d2f6394 -- Petr? From simo at redhat.com Tue Feb 25 15:11:45 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 10:11:45 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CAFE6.1050007@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> Message-ID: <1393341105.18299.36.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: > On 25.2.2014 15:11, Simo Sorce wrote: > > On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: > >>> Any reason why we should follow in detail what softshm does ? > >> because I did't know what is really needed. If you want to have a > >> pkcs11 > >> module, which stores data in ldap, I though it should have all the > >> attributes potentially needed. > >> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, > >> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, > >> CKA_EXTRACTABLE, > >> so there is at least one requirement for fine grained attributes. > > > > Does OpenDNSSEC store them as separate entities and need access to them > > independently ? > AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema > doesn't matter as long as our PKCS#11 module can derive all values defined by > standard. > > Honza, you did investigate OpenDNSSEC integration, please add some details if > you can. > > > Or is this internal use that can be satisfied by unpacking a blob in > > OpenDNSSEC ? > > > > What does bind9 uses ? Petr, can you provide example key files ? > > Private+public keys stored in files: > https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html > > Private keys stored in HSM and public keys in files: > https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html > (I.e. some values in .private file are replaced by PKCS#11 label.) Ok it seem clear to me we do not need to spell out a lot of values when using pkcs#11 as bind doesn't need them in the key files. So I assume it can query the pkcs#11 module to find what it needs. I would use these key files as a sort of guide to understand what we need in LDAP. I would try to put in a single blob as much as we can that we do not explicitly need by a client querying LDAP directly. I think in order to nail down exactly what we need, at this point, we require some example use cases and queries the various clients would perform with spelled out what they are looking for to identify or manipulate keys. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Feb 25 15:18:59 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 16:18:59 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393341105.18299.36.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> Message-ID: <530CB463.4000804@redhat.com> On 25.2.2014 16:11, Simo Sorce wrote: > On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >> On 25.2.2014 15:11, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>> Any reason why we should follow in detail what softshm does ? >>>> because I did't know what is really needed. If you want to have a >>>> pkcs11 >>>> module, which stores data in ldap, I though it should have all the >>>> attributes potentially needed. >>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>> CKA_EXTRACTABLE, >>>> so there is at least one requirement for fine grained attributes. >>> >>> Does OpenDNSSEC store them as separate entities and need access to them >>> independently ? >> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema >> doesn't matter as long as our PKCS#11 module can derive all values defined by >> standard. >> >> Honza, you did investigate OpenDNSSEC integration, please add some details if >> you can. >> >>> Or is this internal use that can be satisfied by unpacking a blob in >>> OpenDNSSEC ? >>> >>> What does bind9 uses ? Petr, can you provide example key files ? >> >> Private+public keys stored in files: >> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >> >> Private keys stored in HSM and public keys in files: >> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >> (I.e. some values in .private file are replaced by PKCS#11 label.) > > Ok it seem clear to me we do not need to spell out a lot of values when > using pkcs#11 as bind doesn't need them in the key files. So I assume it > can query the pkcs#11 module to find what it needs. > > I would use these key files as a sort of guide to understand what we > need in LDAP. I would try to put in a single blob as much as we can that > we do not explicitly need by a client querying LDAP directly. > > I think in order to nail down exactly what we need, at this point, we > require some example use cases and queries the various clients would > perform with spelled out what they are looking for to identify or > manipulate keys. > > Simo. > See "How applications interact with PKCS#11" at . Tl;dr: applications don't search for keys by key data, but by metadata, so like I said in the other thread, key data can be in a single blob, but metadata should be in separate attributes. -- Jan Cholasta From pviktori at redhat.com Tue Feb 25 15:32:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Feb 2014 16:32:01 +0100 Subject: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed In-Reply-To: <530CB058.1070501@redhat.com> References: <1914936383.1530240.1392916535461.JavaMail.zimbra@redhat.com> <530724D8.8060503@redhat.com> <940530339.1630241.1392981061265.JavaMail.zimbra@redhat.com> <530C9ED4.3070206@redhat.com> <530CB058.1070501@redhat.com> Message-ID: <530CB771.8080001@redhat.com> On 02/25/2014 04:01 PM, Petr Viktorin wrote: > On 02/25/2014 02:47 PM, Jan Cholasta wrote: >> On 21.2.2014 12:11, Adam Misnyovszki wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Jan Cholasta" >>>> To: "Adam Misnyovszki" , freeipa-devel at redhat.com >>>> Sent: Friday, February 21, 2014 11:05:12 AM >>>> Subject: Re: [Freeipa-devel] [PATCH] Certificate search >>>> max_serial_number problem fixed >>>> >>>> Hi, >>>> >>>> On 20.2.2014 18:15, Adam Misnyovszki wrote: >>>>> Hi, >>>>> >>>>> this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 >>>>> maximum serial number field now accepts only positive numbers >>>>> >>>>> Thanks >>>>> Adam >>>> >>>> I think you should also add maxvalue to min_serial_number, so that they >>>> are consistent. >>>> >>>> Honza >>>> >>>> -- >>>> Jan Cholasta >>>> >>> >>> Makes sense, new patch added. >>> >>> Adam >>> >> >> Thanks, ACK. >> > > Pushed to master: be7b1b94e300b137c34bab80df3dc91195259c89 Adam, you have not updated API.txt. To do this you need to run the makeapi script when changing the API. When you run `make rpms` you will be warned if there is a mismatch. FWIW, I have the following in my .git/hooks/post-commit, so Git alerts me of problems after a commit: ./makeapi git status --short # Show modified files, mainly for the case that makeapi modified API.txt Honza, please make sure IPA actually builds before you ACK a patch. Attached fix pushed as one-(well,two)-liner to master: 00d6b529c977c19fc5bb2e230da551ac01c79d79 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0472-Update-API.txt.patch Type: text/x-patch Size: 1226 bytes Desc: not available URL: From rcritten at redhat.com Tue Feb 25 15:42:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Feb 2014 10:42:13 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CB463.4000804@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> Message-ID: <530CB9D5.6030905@redhat.com> Jan Cholasta wrote: > On 25.2.2014 16:11, Simo Sorce wrote: >> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>> On 25.2.2014 15:11, Simo Sorce wrote: >>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>> Any reason why we should follow in detail what softshm does ? >>>>> because I did't know what is really needed. If you want to have a >>>>> pkcs11 >>>>> module, which stores data in ldap, I though it should have all the >>>>> attributes potentially needed. >>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>> CKA_EXTRACTABLE, >>>>> so there is at least one requirement for fine grained attributes. >>>> >>>> Does OpenDNSSEC store them as separate entities and need access to them >>>> independently ? >>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema >>> doesn't matter as long as our PKCS#11 module can derive all values >>> defined by >>> standard. >>> >>> Honza, you did investigate OpenDNSSEC integration, please add some >>> details if >>> you can. >>> >>>> Or is this internal use that can be satisfied by unpacking a blob in >>>> OpenDNSSEC ? >>>> >>>> What does bind9 uses ? Petr, can you provide example key files ? >>> >>> Private+public keys stored in files: >>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>> >>> >>> Private keys stored in HSM and public keys in files: >>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>> >>> (I.e. some values in .private file are replaced by PKCS#11 label.) >> >> Ok it seem clear to me we do not need to spell out a lot of values when >> using pkcs#11 as bind doesn't need them in the key files. So I assume it >> can query the pkcs#11 module to find what it needs. >> >> I would use these key files as a sort of guide to understand what we >> need in LDAP. I would try to put in a single blob as much as we can that >> we do not explicitly need by a client querying LDAP directly. >> >> I think in order to nail down exactly what we need, at this point, we >> require some example use cases and queries the various clients would >> perform with spelled out what they are looking for to identify or >> manipulate keys. >> >> Simo. >> > > See "How applications interact with PKCS#11" at > . Tl;dr: applications > don't search for keys by key data, but by metadata, so like I said in > the other thread, key data can be in a single blob, but metadata should > be in separate attributes. > Splitting hairs, I think that one can search based on the cert DER which I guess represents the public key. You mean search by private key? How do you plan to generate the CKA_ID? IIRC it needs to be unique per token and since this will be rather dynamically available. I think it's just a set of bytes so maybe a UUID is adequate. I think you're on the right path defining these as discrete attributes. IMHO it will be worth submitting this as an RFC once the schema design is complete. So I wonder if the 'ipa' string should be dropped from the proposed schema. I guess that would also require specifying the other CKA values for other key types (e.g. DSA and DH). In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment should be CKA_PRIME_1. rob From jcholast at redhat.com Tue Feb 25 15:59:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 16:59:51 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CB9D5.6030905@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <530CB9D5.6030905@redhat.com> Message-ID: <530CBDF7.3080505@redhat.com> On 25.2.2014 16:42, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 25.2.2014 16:11, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>> because I did't know what is really needed. If you want to have a >>>>>> pkcs11 >>>>>> module, which stores data in ldap, I though it should have all the >>>>>> attributes potentially needed. >>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>> CKA_EXTRACTABLE, >>>>>> so there is at least one requirement for fine grained attributes. >>>>> >>>>> Does OpenDNSSEC store them as separate entities and need access to >>>>> them >>>>> independently ? >>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP >>>> schema >>>> doesn't matter as long as our PKCS#11 module can derive all values >>>> defined by >>>> standard. >>>> >>>> Honza, you did investigate OpenDNSSEC integration, please add some >>>> details if >>>> you can. >>>> >>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>> OpenDNSSEC ? >>>>> >>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>> >>>> Private+public keys stored in files: >>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>> >>>> >>>> >>>> Private keys stored in HSM and public keys in files: >>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>> >>>> >>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>> >>> Ok it seem clear to me we do not need to spell out a lot of values when >>> using pkcs#11 as bind doesn't need them in the key files. So I assume it >>> can query the pkcs#11 module to find what it needs. >>> >>> I would use these key files as a sort of guide to understand what we >>> need in LDAP. I would try to put in a single blob as much as we can that >>> we do not explicitly need by a client querying LDAP directly. >>> >>> I think in order to nail down exactly what we need, at this point, we >>> require some example use cases and queries the various clients would >>> perform with spelled out what they are looking for to identify or >>> manipulate keys. >>> >>> Simo. >>> >> >> See "How applications interact with PKCS#11" at >> . Tl;dr: applications >> don't search for keys by key data, but by metadata, so like I said in >> the other thread, key data can be in a single blob, but metadata should >> be in separate attributes. >> > > Splitting hairs, I think that one can search based on the cert DER which > I guess represents the public key. You mean search by private key? Public keys in PKCS#11 are represented by a set of attributes (e.g. CKA_MODULUS, CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT for RSA public keys), I meant search by values of some of them. > > How do you plan to generate the CKA_ID? IIRC it needs to be unique per > token and since this will be rather dynamically available. I think it's > just a set of bytes so maybe a UUID is adequate. That's a possibility. OpenDNSSEC puts 16 random bytes in CKA_ID. > > I think you're on the right path defining these as discrete attributes. > IMHO it will be worth submitting this as an RFC once the schema design > is complete. So I wonder if the 'ipa' string should be dropped from the > proposed schema. I guess that would also require specifying the other > CKA values for other key types (e.g. DSA and DH). > > In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment > should be CKA_PRIME_1. > > rob -- Jan Cholasta From abokovoy at redhat.com Tue Feb 25 16:00:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Feb 2014 18:00:20 +0200 Subject: [Freeipa-devel] [PATCH] 0138 ipa-kdb: in case of delegation use original client's database entry, not the proxy Message-ID: <20140225160020.GW16644@redhat.com> Hi! In case we've got constraint delegation, we need to look into the delegated entry, not the service that is going to delegate it. I'm not sure we need to pass original entry in both cases but with this patch we have solved long standing problem of testing AD trusts in automated CI. https://fedorahosted.org/freeipa/ticket/4195 -- / Alexander Bokovoy -------------- next part -------------- >From 8e7c41bf35d68bfad2dc5b790cf6f5b964949417 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 17:50:55 +0200 Subject: [PATCH v1 1/2] ipa-kdb: in case of delegation use original client's database entry, not the proxy https://fedorahosted.org/freeipa/ticket/4195 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index ff67391..2a0480f 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1983,12 +1983,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, bool with_pac; bool with_pad; int result; + krb5_db_entry *client_entry = NULL; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf * of the proxied user. So always use client_princ in preference */ if (client_princ != NULL) { ks_client_princ = client_princ; + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); } else { ks_client_princ = client->princ; } @@ -2025,7 +2027,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, } } - kerr = ipadb_get_pac(context, client, &pac); + kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } @@ -2041,7 +2043,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, /* check or generate pac data */ if ((pac_auth_data == NULL) || (pac_auth_data[0] == NULL)) { if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) { - kerr = ipadb_get_pac(context, client, &pac); + kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } @@ -2094,6 +2096,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, kerr = 0; done: + if (client_entry != NULL) { + ipadb_free_principal(context, client_entry); + } krb5_pac_free(context, pac); return kerr; } -- 1.8.3.1 From simo at redhat.com Tue Feb 25 16:12:39 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 11:12:39 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CB463.4000804@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> Message-ID: <1393344759.18299.45.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: > On 25.2.2014 16:11, Simo Sorce wrote: > > On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: > >> On 25.2.2014 15:11, Simo Sorce wrote: > >>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: > >>>>> Any reason why we should follow in detail what softshm does ? > >>>> because I did't know what is really needed. If you want to have a > >>>> pkcs11 > >>>> module, which stores data in ldap, I though it should have all the > >>>> attributes potentially needed. > >>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, > >>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, > >>>> CKA_EXTRACTABLE, > >>>> so there is at least one requirement for fine grained attributes. > >>> > >>> Does OpenDNSSEC store them as separate entities and need access to them > >>> independently ? > >> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema > >> doesn't matter as long as our PKCS#11 module can derive all values defined by > >> standard. > >> > >> Honza, you did investigate OpenDNSSEC integration, please add some details if > >> you can. > >> > >>> Or is this internal use that can be satisfied by unpacking a blob in > >>> OpenDNSSEC ? > >>> > >>> What does bind9 uses ? Petr, can you provide example key files ? > >> > >> Private+public keys stored in files: > >> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html > >> > >> Private keys stored in HSM and public keys in files: > >> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html > >> (I.e. some values in .private file are replaced by PKCS#11 label.) > > > > Ok it seem clear to me we do not need to spell out a lot of values when > > using pkcs#11 as bind doesn't need them in the key files. So I assume it > > can query the pkcs#11 module to find what it needs. > > > > I would use these key files as a sort of guide to understand what we > > need in LDAP. I would try to put in a single blob as much as we can that > > we do not explicitly need by a client querying LDAP directly. > > > > I think in order to nail down exactly what we need, at this point, we > > require some example use cases and queries the various clients would > > perform with spelled out what they are looking for to identify or > > manipulate keys. > > > > Simo. > > > > See "How applications interact with PKCS#11" at > . Tl;dr: applications > don't search for keys by key data, but by metadata, so like I said in > the other thread, key data can be in a single blob, but metadata should > be in separate attributes. Ah sorry, I hadn't looked at that one yet. It helps quite a bit. So are the class, key_type, id, label, token, 'sign' the only values we should really care to split off ? Can you describe what are these values ? What is class ? Why is it important, and how does it differ from key_type ? What is the token ? What is 'sign' ? Feel free to give references to specific documents to read up about these attributes. Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Tue Feb 25 16:36:45 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 25 Feb 2014 17:36:45 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393344759.18299.45.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> Message-ID: <530CC69D.9090106@redhat.com> On 02/25/2014 05:12 PM, Simo Sorce wrote: > On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >> On 25.2.2014 16:11, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>> because I did't know what is really needed. If you want to have a >>>>>> pkcs11 >>>>>> module, which stores data in ldap, I though it should have all the >>>>>> attributes potentially needed. >>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>> CKA_EXTRACTABLE, >>>>>> so there is at least one requirement for fine grained attributes. >>>>> Does OpenDNSSEC store them as separate entities and need access to them >>>>> independently ? >>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema >>>> doesn't matter as long as our PKCS#11 module can derive all values defined by >>>> standard. >>>> >>>> Honza, you did investigate OpenDNSSEC integration, please add some details if >>>> you can. >>>> >>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>> OpenDNSSEC ? >>>>> >>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>> Private+public keys stored in files: >>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>> >>>> Private keys stored in HSM and public keys in files: >>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>> Ok it seem clear to me we do not need to spell out a lot of values when >>> using pkcs#11 as bind doesn't need them in the key files. So I assume it >>> can query the pkcs#11 module to find what it needs. >>> >>> I would use these key files as a sort of guide to understand what we >>> need in LDAP. I would try to put in a single blob as much as we can that >>> we do not explicitly need by a client querying LDAP directly. >>> >>> I think in order to nail down exactly what we need, at this point, we >>> require some example use cases and queries the various clients would >>> perform with spelled out what they are looking for to identify or >>> manipulate keys. >>> >>> Simo. >>> >> See "How applications interact with PKCS#11" at >> . Tl;dr: applications >> don't search for keys by key data, but by metadata, so like I said in >> the other thread, key data can be in a single blob, but metadata should >> be in separate attributes. > Ah sorry, I hadn't looked at that one yet. > It helps quite a bit. > > So are the class, key_type, id, label, token, 'sign' the only values we > should really care to split off ? > > Can you describe what are these values ? > What is class ? Why is it important, and how does it differ from > key_type ? > What is the token ? What is 'sign' ? > > Feel free to give references to specific documents to read up about > these attributes. I'm a newcomer to this area and am orienting myself at this doc: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf and looking into opendnssec andsofthsm code. It explains CKA_SIGN as: "TheCKA_SIGN attribute of the signature key, whic h indicates whether the key supports signatures with appendix, must be CK_TRUE." I cannot tell if this will be needed, just can make up an attribute and allow it in an objectclass :-) But I think Jan's doc is a good start where he explains which attributes will be used by specific modules eg for searches. > > Thanks, > Simo. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Feb 25 17:05:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 18:05:28 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: Datetime parsing and formatting Message-ID: <530CCD58.5030403@redhat.com> prerequisite for patch 547, 548 depends on tbabej's datetime patch this patch implements: - output_formatter in field. It should be used in par with formatter. Formatter serves for datasource->widget conversion, output_formatter for widget->datasource format conversion. - datetime module which parses/format strings in subset of ISO 8601 and LDAP generalized time format to Date. - utc formatter replaced with new datetime formatter - datetime_validator introduced - new datetime field, extension of text field, which by default uses datetime formatter and validator Dojo was regenerated to include dojo/string module https://fedorahosted.org/freeipa/ticket/4194 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0546-webui-Datetime-parsing-and-formatting.patch Type: text/x-patch Size: 198389 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 25 17:07:23 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 18:07:23 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: expose krbprincipalexpiration Message-ID: <530CCDCB.6000009@redhat.com> Depends on tbabej's patches # 137, 138 and my 546. https://fedorahosted.org/freeipa/ticket/3306 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0547-webui-expose-krbprincipalexpiration.patch Type: text/x-patch Size: 1041 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 25 17:10:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 18:10:13 +0100 Subject: [Freeipa-devel] [PATCH] 548 webui: change ipatokennotbefore and ipatokennotafter types to datetime Message-ID: <530CCE75.7010808@redhat.com> Depends on tbabej's patches # 137, 140 and pvoborni's 546 and 531-541. https://fedorahosted.org/freeipa/ticket/3369 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0548-webui-change-ipatokennotbefore-and-ipatokennotafter-.patch Type: text/x-patch Size: 1861 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 25 17:12:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Feb 2014 18:12:20 +0100 Subject: [Freeipa-devel] [PATCH] 549 webui: use unique ids for checkboxes Message-ID: <530CCEF4.4060905@redhat.com> This is a minor fix. Please don't close ticket 3904 yet if committed. Checkboxes have not used unique ids across the whole UI. It broke checking by clicking on label for later displayed instances. It became serious problem when rcue introduced new checkbox styles with 'label clicking' as default check method. https://fedorahosted.org/freeipa/ticket/3904 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0549-webui-use-unique-ids-for-checkboxes.patch Type: text/x-patch Size: 1327 bytes Desc: not available URL: From jcholast at redhat.com Tue Feb 25 17:26:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Feb 2014 18:26:05 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CC69D.9090106@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> Message-ID: <530CD22D.7010806@redhat.com> On 25.2.2014 17:36, Ludwig Krispenz wrote: > > On 02/25/2014 05:12 PM, Simo Sorce wrote: >> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >>> On 25.2.2014 16:11, Simo Sorce wrote: >>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>>> because I did't know what is really needed. If you want to have a >>>>>>> pkcs11 >>>>>>> module, which stores data in ldap, I though it should have all the >>>>>>> attributes potentially needed. >>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>>> CKA_EXTRACTABLE, >>>>>>> so there is at least one requirement for fine grained attributes. >>>>>> Does OpenDNSSEC store them as separate entities and need access to them >>>>>> independently ? >>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema >>>>> doesn't matter as long as our PKCS#11 module can derive all values defined by >>>>> standard. >>>>> >>>>> Honza, you did investigate OpenDNSSEC integration, please add some details if >>>>> you can. >>>>> >>>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>>> OpenDNSSEC ? >>>>>> >>>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>>> Private+public keys stored in files: >>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>>> >>>>> Private keys stored in HSM and public keys in files: >>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>>> Ok it seem clear to me we do not need to spell out a lot of values when >>>> using pkcs#11 as bind doesn't need them in the key files. So I assume it >>>> can query the pkcs#11 module to find what it needs. >>>> >>>> I would use these key files as a sort of guide to understand what we >>>> need in LDAP. I would try to put in a single blob as much as we can that >>>> we do not explicitly need by a client querying LDAP directly. >>>> >>>> I think in order to nail down exactly what we need, at this point, we >>>> require some example use cases and queries the various clients would >>>> perform with spelled out what they are looking for to identify or >>>> manipulate keys. >>>> >>>> Simo. >>>> >>> See "How applications interact with PKCS#11" at >>> . Tl;dr: applications >>> don't search for keys by key data, but by metadata, so like I said in >>> the other thread, key data can be in a single blob, but metadata should >>> be in separate attributes. >> Ah sorry, I hadn't looked at that one yet. >> It helps quite a bit. >> >> So are the class, key_type, id, label, token, 'sign' the only values we >> should really care to split off ? They are all metadata related to PKCS#11 operation. I don't think you can easily encode them in PKCS#8 or certificate blob, so they actually need to be split off. You can find the full list of them in the PKCS#11 spec (link below). >> >> Can you describe what are these values ? >> What is class ? Why is it important, and how does it differ from >> key_type ? >> What is the token ? What is 'sign' ? >> >> Feel free to give references to specific documents to read up about >> these attributes. > I'm a newcomer to this area and am orienting myself at this doc: > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf > and looking into opendnssec andsofthsm code. I use mainly , as 2.30 is a draft ATM. > > It explains CKA_SIGN as: > "TheCKA_SIGN attribute of the signature key, whic h indicates whether > the key supports signatures with appendix, must be CK_TRUE." > I cannot tell if this will be needed, just can make up an attribute and > allow it in an objectclass :-) OpenDNSSEC puts it in public key objects it generates, so it's needed at least for the sake of it. Actually, I think we should support all of the metadata attributes, so that our PKCS#11 module is reasonably generic and not tailored to needs of a specific consumer. > > But I think Jan's doc is a good start where he explains which attributes > will be used by specific modules eg for searches. > >> >> Thanks, >> Simo. >> > -- Jan Cholasta From kchamart at redhat.com Tue Feb 25 17:33:24 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 25 Feb 2014 23:03:24 +0530 Subject: [Freeipa-devel] Thank you for FreeOTP! Message-ID: <20140225173324.GA18282@tesla.redhat.com> Heya, Just wanted to say thank you for FreeOTP, Nathaniel and co. And, of course, more thankful to all the Identity open source/free software from this awesome team! A happy user. -- /kashyap From nkinder at redhat.com Tue Feb 25 17:44:34 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 25 Feb 2014 09:44:34 -0800 Subject: [Freeipa-devel] FreeIPA documentation: getting started & devel docs (FOSDEM takeaways - Software Archaeology for Beginners) In-Reply-To: <530C6336.7020503@redhat.com> References: <530C6336.7020503@redhat.com> Message-ID: <530CD682.4010602@redhat.com> On 02/25/2014 01:32 AM, Petr Spacek wrote: > Hello list, > > I have seen talk "Software Archaeology for Beginners" from FOSDEM 2014 > [1] and I have couple notes: > > 1) User docs: > Make sure that project's documentation tells its own story: > Documentation is not so useful if it is a bunch of unrelated documents. > Make sure that there is 'introduction' document starting with project > description. The 'story' should continue to installation and very basic > configuration and use cases. > > There should not be a 'gap' between steps like missing steps between > installation and client configuration etc. > > We have something like that in RHEL IdM guide. Should we add "Getting > Started" link to the very beginning of > http://www.freeipa.org/page/Documentation#User_Documentation ? > > Maybe the RHEL guide is too huge and scary for 'getting started' so we > would need to write something/compile it from existing blogs posts etc. > > > 2) Pictures with a story are nice: > Diagrams with system components are more useful when they *visualize > some basic workflows step by step*. I find diagrams very useful for workflows as well. They are very useful when used in combination with your typical architecture diagram. I used http://www.websequencediagrams.com to generate workflow diagrams for the Password Vault design proposal: http://www.freeipa.org/page/V3/Password_Vault I'd recommend trying that tool, as it's really pretty quick/easy to write the "code" to cretre the diagram, and you don't need to mess around with an actual drawing program. -NGK > > Imagine one SSSD client and one IPA server and describe what happens if > the user enters his username and password to login prompt. > > - Arrow #0 from NSS db /passwd/ to SSSD component /s1/ with description /d/ > - Arrow #1 from SSSD component /s1/ to IPA component /i1/ with > description /d/ > - Arrow #2 from NSS db /shadow/ to SSSD component /s2/ with description /d/ > - Arrow #3 from SSSD component /s2/ to IPA component /i2/ with > description /d/ > etc. > > Such diagram not only helps to new developers but also gives tremendous > help to people debugging the whole solution. (We have to admit that > debugging is always PITA.) > > > As usual, this sounds like a good task for newcomers (sorry Adam! :-). > > [1] > http://video.fosdem.org/2014/Janson/Saturday/Software_Archaeology_for_Beginners.webm > > From abokovoy at redhat.com Tue Feb 25 17:56:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Feb 2014 19:56:16 +0200 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified Message-ID: <20140225175616.GX16644@redhat.com> Hi, Simple patch to fix KeyError as --pkey-only causes no attributes to be returned and trustdomain_find.post_callback checked them unconditionally. https://fedorahosted.org/freeipa/ticket/4196 -- / Alexander Bokovoy -------------- next part -------------- >From a8540634ddac57ce3c05416b3a08a958b01d99b3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 19:47:10 +0200 Subject: [PATCH 2/2] trustdomain_find: make sure we skip short entries when --pkey-only is specified With --pkey-only only primary key is returned. It makes no sense to check and replace boolean values then. https://fedorahosted.org/freeipa/ticket/4196 --- ipalib/plugins/trust.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 5ab4b25..050c468 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1192,6 +1192,9 @@ class trustdomain_find(LDAPSearch): trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') trust_entry = ldap.get_entry(trust_dn) for entry in entries: + if 'ipanttrustedomainsid' not in entry: + # --pkey-only case + continue sid = entry['ipanttrusteddomainsid'][0] if sid in trust_entry['ipantsidblacklistincoming']: entry['domain_enabled'] = [False] -- 1.8.3.1 From dpal at redhat.com Tue Feb 25 18:13:03 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 25 Feb 2014 13:13:03 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393335978.18299.10.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> Message-ID: <530CDD2F.5000209@redhat.com> On 02/25/2014 08:46 AM, Simo Sorce wrote: > On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote: >> On 24.2.2014 20:20, Simo Sorce wrote: >>> Also can you add some examples on how we would use these classes to >>> store DNS keys ? >> We need to think about it a bit more. We plan to use PKCS#11 for key >> manipulation and data signing so the key itself will be unaware of any >> DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass. >> >> I'm discussing this with CZ.NIC guys and they propose to add a 'layer of >> indirection' between DNS zones and keys so one key set can be used by more DNS >> zones. They claim that it is relatively common practice and I trust them. >> >> Note that I'm not saying that IPA should use one key for multiple DNS zones by >> default, but the schema should be future-proof and allow that if necessary. > Makes sense. > >> Let's start with this proposal: >> DNS zone: idnsname=dnssec.test, cn=dns, dc=example >> There will be multi-valued attribute idnsseckey pointing to DNs of keys stored >> somewhere else. >> >> Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store >> keys there. > Ok, do we really want to have zones pointing at keys ? > Or do we want keys have a list of zones they are supposed to apply to ? If we plan to store DNS keys in one place and other keys in other places in the tree (no common key store) then it really does not matter much. It should be derived from the LDAP searches that would need to be conducted by the software. We need keys for signing, right? Any other use case? If for signing we will start with a zone and would need to find keys that are relevant to this zone. It seems that having a generic key class + auxiliary class that would keep metadata about the key, its expiration and DN it applies to would be a way to go. So it seems that I agree with Simo that it would make sense to have the zone the key applies to specified in the key entry rather than in the zone entry. > >> I expect that PKCS#11 module will handle keys scattered over the LDAP tree >> somehow. > Sure as long as it can understand what the keys are for. > >>> Ideally the example would show the LDAP tree and some example data in >>> detail, and also what operation we think would be common. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue Feb 25 18:15:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Feb 2014 20:15:03 +0200 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <530C8ADD.9030803@redhat.com> References: <530C8ADD.9030803@redhat.com> Message-ID: <20140225181503.GY16644@redhat.com> On Tue, 25 Feb 2014, Tomas Babej wrote: >Hi, > >As a part of a better cleanup procedure in the integration tests, >make sure that winbindd is not running after uninstalling the IPA >server. Better patch 0140 attached. We simply need to stop and disable winbind in adtrustinstance.uninstall() -- / Alexander Bokovoy -------------- next part -------------- >From 01c230ddcc3b70ddc147c1b46e766e5cab93c380 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 20:11:50 +0200 Subject: [PATCH 3/3] adtrustinstance: make sure to stop and disable winbind in uninstall() This makes unnecessary Tomas' patch 0155. --- ipaserver/install/adtrustinstance.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 621e3fd..6e30d5a 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -889,11 +889,14 @@ class ADTRUSTInstance(service.Service): self.restore_state("running") self.restore_state("enabled") + winbind = ipaservices.service("winbind") # Always try to stop and disable smb service, since we do not leave # working configuration after uninstall try: self.stop() self.disable() + winbind.stop() + winbind.disable() except: pass -- 1.8.3.1 From pviktori at redhat.com Tue Feb 25 18:21:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Feb 2014 19:21:09 +0100 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <530C8ADD.9030803@redhat.com> References: <530C8ADD.9030803@redhat.com> Message-ID: <530CDF15.3010304@redhat.com> On 02/25/2014 01:21 PM, Tomas Babej wrote: > Hi, > > As a part of a better cleanup procedure in the integration tests, > make sure that winbindd is not running after uninstalling the IPA > server. -9, what a brutal way to kill. Usually when I stop a service this way, systemd restarts it right away. Does that not happen in this case? -- Petr? From rcritten at redhat.com Tue Feb 25 18:22:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Feb 2014 13:22:30 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CD22D.7010806@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> Message-ID: <530CDF66.4000609@redhat.com> Jan Cholasta wrote: > On 25.2.2014 17:36, Ludwig Krispenz wrote: >> >> On 02/25/2014 05:12 PM, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >>>> On 25.2.2014 16:11, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>>>> because I did't know what is really needed. If you want to have a >>>>>>>> pkcs11 >>>>>>>> module, which stores data in ldap, I though it should have all the >>>>>>>> attributes potentially needed. >>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>>>> CKA_EXTRACTABLE, >>>>>>>> so there is at least one requirement for fine grained attributes. >>>>>>> Does OpenDNSSEC store them as separate entities and need access >>>>>>> to them >>>>>>> independently ? >>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP >>>>>> schema >>>>>> doesn't matter as long as our PKCS#11 module can derive all values >>>>>> defined by >>>>>> standard. >>>>>> >>>>>> Honza, you did investigate OpenDNSSEC integration, please add some >>>>>> details if >>>>>> you can. >>>>>> >>>>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>>>> OpenDNSSEC ? >>>>>>> >>>>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>>>> Private+public keys stored in files: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>>>> >>>>>> >>>>>> Private keys stored in HSM and public keys in files: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>>>> >>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>>>> Ok it seem clear to me we do not need to spell out a lot of values >>>>> when >>>>> using pkcs#11 as bind doesn't need them in the key files. So I >>>>> assume it >>>>> can query the pkcs#11 module to find what it needs. >>>>> >>>>> I would use these key files as a sort of guide to understand what we >>>>> need in LDAP. I would try to put in a single blob as much as we can >>>>> that >>>>> we do not explicitly need by a client querying LDAP directly. >>>>> >>>>> I think in order to nail down exactly what we need, at this point, we >>>>> require some example use cases and queries the various clients would >>>>> perform with spelled out what they are looking for to identify or >>>>> manipulate keys. >>>>> >>>>> Simo. >>>>> >>>> See "How applications interact with PKCS#11" at >>>> . Tl;dr: applications >>>> don't search for keys by key data, but by metadata, so like I said in >>>> the other thread, key data can be in a single blob, but metadata should >>>> be in separate attributes. >>> Ah sorry, I hadn't looked at that one yet. >>> It helps quite a bit. >>> >>> So are the class, key_type, id, label, token, 'sign' the only values we >>> should really care to split off ? > > They are all metadata related to PKCS#11 operation. I don't think you > can easily encode them in PKCS#8 or certificate blob, so they actually > need to be split off. You can find the full list of them in the PKCS#11 > spec (link below). > >>> >>> Can you describe what are these values ? >>> What is class ? Why is it important, and how does it differ from >>> key_type ? >>> What is the token ? What is 'sign' ? >>> >>> Feel free to give references to specific documents to read up about >>> these attributes. >> I'm a newcomer to this area and am orienting myself at this doc: >> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >> and looking into opendnssec andsofthsm code. > > I use mainly > , as > 2.30 is a draft ATM. > >> >> It explains CKA_SIGN as: >> "TheCKA_SIGN attribute of the signature key, whic h indicates whether >> the key supports signatures with appendix, must be CK_TRUE." >> I cannot tell if this will be needed, just can make up an attribute and >> allow it in an objectclass :-) > > OpenDNSSEC puts it in public key objects it generates, so it's needed at > least for the sake of it. > > Actually, I think we should support all of the metadata attributes, so > that our PKCS#11 module is reasonably generic and not tailored to needs > of a specific consumer. We could hardcode some of these values but it will very likely cause problems later. It seems simple enough to just define schema for all of them and store them, except perhaps in the cases where they are easily derived. If we, for example, store the prime numbers and exponents, they need to be protected as carefully as the private key. rob From abokovoy at redhat.com Tue Feb 25 18:58:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Feb 2014 20:58:03 +0200 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes Message-ID: <20140225185803.GZ16644@redhat.com> Resending patch 0138 together with another case Simo found out today: when authdata flag is cleared by admin for the service principal, we'll get NULL client database entry. In such case we have to bail out. -- / Alexander Bokovoy -------------- next part -------------- >From 8e7c41bf35d68bfad2dc5b790cf6f5b964949417 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 17:50:55 +0200 Subject: [PATCH v1 1/2] ipa-kdb: in case of delegation use original client's database entry, not the proxy https://fedorahosted.org/freeipa/ticket/4195 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index ff67391..2a0480f 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1983,12 +1983,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, bool with_pac; bool with_pad; int result; + krb5_db_entry *client_entry = NULL; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf * of the proxied user. So always use client_princ in preference */ if (client_princ != NULL) { ks_client_princ = client_princ; + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); } else { ks_client_princ = client->princ; } @@ -2025,7 +2027,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, } } - kerr = ipadb_get_pac(context, client, &pac); + kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } @@ -2041,7 +2043,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, /* check or generate pac data */ if ((pac_auth_data == NULL) || (pac_auth_data[0] == NULL)) { if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) { - kerr = ipadb_get_pac(context, client, &pac); + kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac); if (kerr != 0 && kerr != ENOENT) { goto done; } @@ -2094,6 +2096,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, kerr = 0; done: + if (client_entry != NULL) { + ipadb_free_principal(context, client_entry); + } krb5_pac_free(context, pac); return kerr; } -- 1.8.3.1 -------------- next part -------------- >From d3af14384d6612121dfa8e75b3cb690c490a1004 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 20:53:49 +0200 Subject: [PATCH 4/4] ipa-kdb: make sure we don't produce MS-PAC in case of authdata flag cleared by admin When admin clears authdata flag for the service principal, KDC will pass NULL client pointer (service proxy) to the DAL driver. Make sure we bail out correctly. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 2170675..771b40b 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1989,6 +1989,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, int result; krb5_db_entry *client_entry = NULL; + + /* When client is NULL, authdata flag on the service principal was cleared + * by an admin. We don't generate MS-PAC in this case */ + if (client == NULL) { + *signed_auth_data = NULL; + return 0; + } + /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf * of the proxied user. So always use client_princ in preference */ -- 1.8.3.1 From simo at redhat.com Tue Feb 25 18:59:58 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 13:59:58 -0500 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <20140225185803.GZ16644@redhat.com> References: <20140225185803.GZ16644@redhat.com> Message-ID: <1393354798.18299.56.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: > Resending patch 0138 together with another case Simo found out today: > when authdata flag is cleared by admin for the service principal, we'll > get NULL client database entry. In such case we have to bail out. The patches look correct code-flow-wise to me. So tentative ack pending testing. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Feb 25 19:22:05 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Feb 2014 14:22:05 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CDF66.4000609@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> Message-ID: <1393356125.18299.67.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote: > Jan Cholasta wrote: > > On 25.2.2014 17:36, Ludwig Krispenz wrote: > >> > >> On 02/25/2014 05:12 PM, Simo Sorce wrote: > >>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: > >>>> On 25.2.2014 16:11, Simo Sorce wrote: > >>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: > >>>>>> On 25.2.2014 15:11, Simo Sorce wrote: > >>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: > >>>>>>>>> Any reason why we should follow in detail what softshm does ? > >>>>>>>> because I did't know what is really needed. If you want to have a > >>>>>>>> pkcs11 > >>>>>>>> module, which stores data in ldap, I though it should have all the > >>>>>>>> attributes potentially needed. > >>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, > >>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, > >>>>>>>> CKA_EXTRACTABLE, > >>>>>>>> so there is at least one requirement for fine grained attributes. > >>>>>>> Does OpenDNSSEC store them as separate entities and need access > >>>>>>> to them > >>>>>>> independently ? > >>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP > >>>>>> schema > >>>>>> doesn't matter as long as our PKCS#11 module can derive all values > >>>>>> defined by > >>>>>> standard. > >>>>>> > >>>>>> Honza, you did investigate OpenDNSSEC integration, please add some > >>>>>> details if > >>>>>> you can. > >>>>>> > >>>>>>> Or is this internal use that can be satisfied by unpacking a blob in > >>>>>>> OpenDNSSEC ? > >>>>>>> > >>>>>>> What does bind9 uses ? Petr, can you provide example key files ? > >>>>>> Private+public keys stored in files: > >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html > >>>>>> > >>>>>> > >>>>>> Private keys stored in HSM and public keys in files: > >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html > >>>>>> > >>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) > >>>>> Ok it seem clear to me we do not need to spell out a lot of values > >>>>> when > >>>>> using pkcs#11 as bind doesn't need them in the key files. So I > >>>>> assume it > >>>>> can query the pkcs#11 module to find what it needs. > >>>>> > >>>>> I would use these key files as a sort of guide to understand what we > >>>>> need in LDAP. I would try to put in a single blob as much as we can > >>>>> that > >>>>> we do not explicitly need by a client querying LDAP directly. > >>>>> > >>>>> I think in order to nail down exactly what we need, at this point, we > >>>>> require some example use cases and queries the various clients would > >>>>> perform with spelled out what they are looking for to identify or > >>>>> manipulate keys. > >>>>> > >>>>> Simo. > >>>>> > >>>> See "How applications interact with PKCS#11" at > >>>> . Tl;dr: applications > >>>> don't search for keys by key data, but by metadata, so like I said in > >>>> the other thread, key data can be in a single blob, but metadata should > >>>> be in separate attributes. > >>> Ah sorry, I hadn't looked at that one yet. > >>> It helps quite a bit. > >>> > >>> So are the class, key_type, id, label, token, 'sign' the only values we > >>> should really care to split off ? > > > > They are all metadata related to PKCS#11 operation. I don't think you > > can easily encode them in PKCS#8 or certificate blob, so they actually > > need to be split off. You can find the full list of them in the PKCS#11 > > spec (link below). > > > >>> > >>> Can you describe what are these values ? > >>> What is class ? Why is it important, and how does it differ from > >>> key_type ? > >>> What is the token ? What is 'sign' ? > >>> > >>> Feel free to give references to specific documents to read up about > >>> these attributes. > >> I'm a newcomer to this area and am orienting myself at this doc: > >> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf > >> and looking into opendnssec andsofthsm code. > > > > I use mainly > > , as > > 2.30 is a draft ATM. > > > >> > >> It explains CKA_SIGN as: > >> "TheCKA_SIGN attribute of the signature key, whic h indicates whether > >> the key supports signatures with appendix, must be CK_TRUE." > >> I cannot tell if this will be needed, just can make up an attribute and > >> allow it in an objectclass :-) > > > > OpenDNSSEC puts it in public key objects it generates, so it's needed at > > least for the sake of it. > > > > Actually, I think we should support all of the metadata attributes, so > > that our PKCS#11 module is reasonably generic and not tailored to needs > > of a specific consumer. > > We could hardcode some of these values but it will very likely cause > problems later. It seems simple enough to just define schema for all of > them and store them, except perhaps in the cases where they are easily > derived. If we, for example, store the prime numbers and exponents, they > need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as "Directory Manager", which is one of the reasons why we encrypt kerberos key material before storing it into the db. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Feb 25 19:26:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 20:26:45 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CDD2F.5000209@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> Message-ID: <530CEE75.1070801@redhat.com> On 25.2.2014 19:13, Dmitri Pal wrote: > On 02/25/2014 08:46 AM, Simo Sorce wrote: >> On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote: >>> On 24.2.2014 20:20, Simo Sorce wrote: >>>> Also can you add some examples on how we would use these classes to >>>> store DNS keys ? >>> We need to think about it a bit more. We plan to use PKCS#11 for key >>> manipulation and data signing so the key itself will be unaware of any >>> DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary >>> objectClass. >>> >>> I'm discussing this with CZ.NIC guys and they propose to add a 'layer of >>> indirection' between DNS zones and keys so one key set can be used by more DNS >>> zones. They claim that it is relatively common practice and I trust them. >>> >>> Note that I'm not saying that IPA should use one key for multiple DNS zones by >>> default, but the schema should be future-proof and allow that if necessary. >> Makes sense. >> >>> Let's start with this proposal: >>> DNS zone: idnsname=dnssec.test, cn=dns, dc=example >>> There will be multi-valued attribute idnsseckey pointing to DNs of keys stored >>> somewhere else. >>> >>> Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store >>> keys there. >> Ok, do we really want to have zones pointing at keys ? >> Or do we want keys have a list of zones they are supposed to apply to ? > > > If we plan to store DNS keys in one place and other keys in other places in > the tree (no common key store) then it really does not matter much. > It should be derived from the LDAP searches that would need to be conducted by > the software. > > We need keys for signing, right? > Any other use case? In DNSSEC-context no, but the same principle will be re-used for CA certificates and possibly user-keys (in future, like SSH private keys or certificated used from Firefox). > If for signing we will start with a zone and would need to find keys that are > relevant to this zone. > It seems that having a generic key class + auxiliary class that would keep > metadata about the key, its expiration and DN it applies to would be a way to go. Yes, this is the plan. > So it seems that I agree with Simo that it would make sense to have the zone > the key applies to specified in the key entry rather than in the zone entry. Practically it doesn't matter. You have to do either search to find zones associated with given key or another search to find keys associated with given zone. Maybe the version with list of zones stored in key is better from ACI's point of view. Access to list of zones will be controlled with ACI attached to the key object. ... Would it be a problem to have bi-directional link between key and zone (member-memberOf style)? It would ease processing on the client side and I think that the price is not that high. We can use existing member and memberOf attributes if we decide to do that. >>> I expect that PKCS#11 module will handle keys scattered over the LDAP tree >>> somehow. >> Sure as long as it can understand what the keys are for. >> >>>> Ideally the example would show the LDAP tree and some example data in >>>> detail, and also what operation we think would be common. I was talking about 'layer of indirection' previously. I'm digging into details and it seems like a good idea to imitate what DNS registrars do - use concept of key sets. It means that keys are not linked to a zone one by one but rather a whole set of keys is linked to a zone. It eases key rotation because you just need to drop a new key to a key set and you don't have to add DNs of all zones to the new key (or the other way around). Another thing is that you could have different key rotation policies for different key sets... we need to think about it carefully. For example (without policies for now): - two DNS zones example.com and example.net contain a pointer to keyset called 'setA' - zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns - key sets are stored under cn=keysets, cn=sec, cn=dns - individual keys are stored under keyid=key1, keysetid=setA, cn=keysets, cn=sec, cn=dns See the attached picture. Are you okay with that? If so, we need to somehow add key rotation policy to this mix :-) This machinery has to allow algorithm-rollover, keysize-rollover etc. We can get some inspiration from https://wiki.opendnssec.org/display/DOCS/kasp.xml . Note that OpenDNSSEC 1.x can't do algorithm-rollover so we need to be creative with the design. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: keyset-tree.png Type: image/png Size: 49208 bytes Desc: not available URL: From pspacek at redhat.com Tue Feb 25 19:52:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 20:52:11 +0100 Subject: [Freeipa-devel] DNSSEC design page: PKCS#11 references In-Reply-To: <530CD22D.7010806@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> Message-ID: <530CF46B.10807@redhat.com> On 25.2.2014 18:26, Jan Cholasta wrote: > On 25.2.2014 17:36, Ludwig Krispenz wrote: >> >> On 02/25/2014 05:12 PM, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >>>> On 25.2.2014 16:11, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>>>> because I did't know what is really needed. If you want to have a >>>>>>>> pkcs11 >>>>>>>> module, which stores data in ldap, I though it should have all the >>>>>>>> attributes potentially needed. >>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>>>> CKA_EXTRACTABLE, >>>>>>>> so there is at least one requirement for fine grained attributes. >>>>>>> Does OpenDNSSEC store them as separate entities and need access to them >>>>>>> independently ? >>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema >>>>>> doesn't matter as long as our PKCS#11 module can derive all values >>>>>> defined by >>>>>> standard. >>>>>> >>>>>> Honza, you did investigate OpenDNSSEC integration, please add some >>>>>> details if >>>>>> you can. >>>>>> >>>>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>>>> OpenDNSSEC ? >>>>>>> >>>>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>>>> Private+public keys stored in files: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>>>> >>>>>> Private keys stored in HSM and public keys in files: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>>>> Ok it seem clear to me we do not need to spell out a lot of values when >>>>> using pkcs#11 as bind doesn't need them in the key files. So I assume it >>>>> can query the pkcs#11 module to find what it needs. >>>>> >>>>> I would use these key files as a sort of guide to understand what we >>>>> need in LDAP. I would try to put in a single blob as much as we can that >>>>> we do not explicitly need by a client querying LDAP directly. >>>>> >>>>> I think in order to nail down exactly what we need, at this point, we >>>>> require some example use cases and queries the various clients would >>>>> perform with spelled out what they are looking for to identify or >>>>> manipulate keys. >>>>> >>>>> Simo. >>>>> >>>> See "How applications interact with PKCS#11" at >>>> . Tl;dr: applications >>>> don't search for keys by key data, but by metadata, so like I said in >>>> the other thread, key data can be in a single blob, but metadata should >>>> be in separate attributes. >>> Ah sorry, I hadn't looked at that one yet. >>> It helps quite a bit. >>> >>> So are the class, key_type, id, label, token, 'sign' the only values we >>> should really care to split off ? > > They are all metadata related to PKCS#11 operation. I don't think you can > easily encode them in PKCS#8 or certificate blob, so they actually need to be > split off. You can find the full list of them in the PKCS#11 spec (link below). > >>> >>> Can you describe what are these values ? >>> What is class ? Why is it important, and how does it differ from >>> key_type ? >>> What is the token ? What is 'sign' ? >>> >>> Feel free to give references to specific documents to read up about >>> these attributes. >> I'm a newcomer to this area and am orienting myself at this doc: >> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >> and looking into opendnssec andsofthsm code. > > I use mainly > , as 2.30 > is a draft ATM. > >> >> It explains CKA_SIGN as: >> "TheCKA_SIGN attribute of the signature key, whic h indicates whether >> the key supports signatures with appendix, must be CK_TRUE." >> I cannot tell if this will be needed, just can make up an attribute and >> allow it in an objectclass :-) > > OpenDNSSEC puts it in public key objects it generates, so it's needed at least > for the sake of it. > > Actually, I think we should support all of the metadata attributes, so that > our PKCS#11 module is reasonably generic and not tailored to needs of a > specific consumer. > >> >> But I think Jan's doc is a good start where he explains which attributes >> will be used by specific modules eg for searches. This page contains couple interesting links to standards and related software: https://wiki.opendnssec.org/display/DOCREF/PKCS11 -- Petr^2 Spacek From jhrozek at redhat.com Tue Feb 25 20:18:22 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 25 Feb 2014 21:18:22 +0100 Subject: [Freeipa-devel] Reviewer in Trac In-Reply-To: <1392923468.22754.247.camel@willson.li.ssimo.org> References: <5305F3A0.60606@redhat.com> <20140220145206.GE2073@hendrix.brq.redhat.com> <53061857.8060606@redhat.com> <1392908998.22754.219.camel@willson.li.ssimo.org> <53061B8A.2070500@redhat.com> <1392909323.22754.222.camel@willson.li.ssimo.org> <53062082.9020805@redhat.com> <1392911710.22754.228.camel@willson.li.ssimo.org> <53062D53.5080301@redhat.com> <1392923468.22754.247.camel@willson.li.ssimo.org> Message-ID: <20140225201822.GK28369@hendrix.brq.redhat.com> On Thu, Feb 20, 2014 at 02:11:08PM -0500, Simo Sorce wrote: > On Thu, 2014-02-20 at 17:29 +0100, Petr Viktorin wrote: > > Patchwork: > > patch arrives: nothing > > mark self as reviewer: use web interface > > send review: reply, find patch in Patchwork, mark status > > send fixed patch: send the mail, find patch in Patchwork, mark > > status, > > find old patch in Patchwork, mark old patch as superseded > > patch pushed/superseded: find patch in Patchwork, mark as pushed > > > > (where "find patch in Patchwork" is frustrating when done so often) > > > Well now I have patches that do 2 things: Thank you, this is really helpful! > 1. accept commands to change state and reviewer via email headers What I do now with my MUA (mutt+vim) is: * in the compose view, hit "E" which brings me to a view that also allows to edit headers in addition to body * Hit Ctrl+a to ack the patch, Ctrl+t to nack the patch, Ctrl+r to just mark myself the patch as "Under review" To add the headers I've defined the following macro in ~/.vimrc: function! PatchworkMacros() " a -> ack nmap ggiX-Patchwork-State: Accepted " n -> nack nmap ggiX-Patchwork-State: Changes Requested " r -> review nmap ggiX-Patchwork-State: Under Review " t -> take nmap ggiX-Patchwork-Delegate: jhrozek at redhat.com endf autocmd BufWinEnter /var/tmp/mutt-* call PatchworkMacros() (Arguably I could fold C-t into the three combos above, but I'm still experimenting with the setup..) So the added logistics is to learn to press "E" instead of "e" in the compose view and one key combo. Of course, the setup is higly dependant on the mail client.. Also, maybe someone with more mutt knowledge will educate me how to define the macros directly in .muttrc so I didn't have to go to the special compose mode with 'E', but my attempts with using "my_hdr" failed.. > 2. automatically marks superseded older patches in the same mailthread This works like a charm automagically. > > I will install these patches shortly > > Simo. From dpal at redhat.com Wed Feb 26 00:55:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 25 Feb 2014 19:55:00 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1393255303.21604.12.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> <1393252309.21604.3.camel@localhost.localdomain> <530B5BA3.4070403@redhat.com> <1393255303.21604.12.camel@localhost.localdomain> Message-ID: <530D3B64.7090501@redhat.com> On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: > On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: >> On 24.2.2014 15:31, Nathaniel McCallum wrote: >>> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: >>>> On 21.2.2014 20:00, Nathaniel McCallum wrote: >>>>> Is it possible to do something more intelligent for the key and date >>>>> fields in the add-token UI? >>>>> >>>>> Date fields are currently just a text box. Is there any sort of calendar >>>>> we could use here? If not, I'm still unsure of what the format should be >>>>> for this field. >>>> It's the format you chose :), try to fill it in CLI, you will have the >>>> same proble. From API level it's just string, from LDAP it's generalized >>>> time. >>> Is there a better option? I'm open to suggestions. >> As I mentioned below, it's being implemented. The datetime patches will >> be send separately. The core OTP UI patches should not be blocked by them. >> >>>> I've an UI patch prepared where you can write it in ISO format, with a >>>> validator attached to it, so user will be noticed about the format, but >>>> it's waiting for: >>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html >>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html >>>> >>>>> The key field should probably have a note indicating that it is Base32 >>>>> encoding. It would also be nice to restrict the input to Base32 >>>>> characters. Maybe even automatic case correction... >>>> Actually I think it doesn't help much. Show me a person who can write >>>> base32 encoded string.... But I agree that a validator with some regex >>>> to limit the chars and a note that it should be base32 string is better. >>>> The question is what's the purpose of this field from user perspective. >>>> Is a human being suppose to fill it or is it meant to be only filled by >>>> some provisioning systems? In UI it's just as a backup? >>>> >>>> If there is a use case where user is suppose to choose the key, it would >>>> be better to fill the key and convert it to base32 string on a server. >>> I can't think of any case where a user would use the key field. >>> >>> However, there are at least two important cases where an admin would do >>> this: >>> 1. Hardware tokens >>> 2. Transferring OATH (TOTP/HOTP) tokens from another system >>> >>> Nathaniel >>> >> What is the input format for these two cases? Is it base32 so admin can >> enter it into UI or is it plain text so he has to use different tool to >> encode it to base32 and then fill into UI? > In both of the above cases, I suspect the predominant use will be > scripts written to take a token store and import the tokens. This is > mostly a non-UI case. > > RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. > This is largely because, with fewer characters and no case-sensitivity, > Base32 is easier to type. I don't know of any other encodings in wide > use. > > It would be nice to support both of them, but I'm not sure how this is > possible. Suggestions are welcome. I do not think we should allow typing the key (and other attributes) manually. We should rather ask user to import a token or tokens from the XML file that uses RFC6030. There are vendors of the hardware tokens that actually using it to distribute the tokens. Here are the examples http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files Please click around the site for more info. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Feb 26 07:53:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 08:53:15 +0100 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <1393354798.18299.56.camel@willson.li.ssimo.org> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> Message-ID: <530D9D6B.6090103@redhat.com> On 02/25/2014 07:59 PM, Simo Sorce wrote: > On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >> Resending patch 0138 together with another case Simo found out today: >> when authdata flag is cleared by admin for the service principal, we'll >> get NULL client database entry. In such case we have to bail out. > > The patches look correct code-flow-wise to me. > > So tentative ack pending testing. > > Simo. > Just checking - are we ok performance wise? If we for example add one additional LDAP search for every Kerberos authentication, it may increase the load on our LDAP server. Martin From abokovoy at redhat.com Wed Feb 26 08:33:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 10:33:03 +0200 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <530D9D6B.6090103@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> Message-ID: <20140226083303.GB16644@redhat.com> On Wed, 26 Feb 2014, Martin Kosek wrote: >On 02/25/2014 07:59 PM, Simo Sorce wrote: >> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >>> Resending patch 0138 together with another case Simo found out today: >>> when authdata flag is cleared by admin for the service principal, we'll >>> get NULL client database entry. In such case we have to bail out. >> >> The patches look correct code-flow-wise to me. >> >> So tentative ack pending testing. >> >> Simo. >> > >Just checking - are we ok performance wise? If we for example add one >additional LDAP search for every Kerberos authentication, it may increase the >load on our LDAP server. One additional LDAP query per S4U2Proxy ticket issuing. It is not much and it has to be done because current code does it wrongly for MS-PAC. It is worth noting that issuing tickets should be relatively rare operation -- with sessions in IPA server we don't hit HTTP/->ldap/ service ticket granting in S4U2Proxy case more than once. 'ipa trust-add' case is a bit more specific but you rarely establish trusts every second of the day, aren't you? For normal operations it wouldn't affect anything beyond statistical noise level. -- / Alexander Bokovoy From pspacek at redhat.com Wed Feb 26 09:03:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Feb 2014 10:03:42 +0100 Subject: [Freeipa-devel] [PATCH 0229] Require BIND >= 9.8.2 instead of >= 9.9.0 Message-ID: <530DADEE.2060101@redhat.com> Hello, Require BIND >= 9.8.2 instead of >= 9.9.0. Pushed to v3 branch: 28cd600ddc0a9473b3adb31dd82ea99d7c92f983 -- Petr^2 Spacek From abokovoy at redhat.com Wed Feb 26 09:13:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 11:13:51 +0200 Subject: [Freeipa-devel] [PATCH] 0142: initialize BindInstance.zonemgr for short-circuited instance use in replica setup Message-ID: <20140226091351.GC16644@redhat.com> Hi, BindInstance is used in two different ways, with replica setup not calling BindInstance.setup() before adding master records. This causes some properties to be uninitialized and an exception when installing replica. https://fedorahosted.org/freeipa/ticket/4186 -- / Alexander Bokovoy -------------- next part -------------- >From 644ac4508f9f357c75c1cf954386590828bbeb3e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 26 Feb 2014 11:06:29 +0200 Subject: [PATCH 5/5] bindinstance: make sure zone manager is initialized in add_master_dns_records Bind instance is configured using a short-circuited way when replica is set up. Make sure required properties are in place for that. https://fedorahosted.org/freeipa/ticket/4186 --- ipaserver/install/bindinstance.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py index 6d5a1d4..4dc4103 100644 --- a/ipaserver/install/bindinstance.py +++ b/ipaserver/install/bindinstance.py @@ -828,6 +828,7 @@ class BindInstance(service.Service): self.reverse_zone = reverse_zone self.ca_configured = ca_configured self.first_instance = False + self.zonemgr = 'hostmaster.%s' % self.domain self.__add_self() self.__add_ipa_ca_record() -- 1.8.3.1 From pviktori at redhat.com Wed Feb 26 09:44:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Feb 2014 10:44:42 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 Message-ID: <530DB78A.4040003@redhat.com> Hello, Here are a few fixes/improvements, and the first part of a managed permission updater. The patches should go in this order but don't need to be ACKed/pushed all at once. Design: http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 This part is a "preview" of sorts, to get the basic mechanism and the metadata format reviewed before I add all of the default read permissions. It implements the first section of "Default Permission Updater" in the design; "Replacing legacy default permissions" and "Removing the global anonymous read ACI" is left for later. Metadata is added for the netgroup plugin* for starters, so installing this will give you two shiny new read permissions: $ ipa permission-find ipa: --all --------------------- 2 permissions matched --------------------- dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX Permission name: ipa:Read Netgroup Membership Permissions: read, compare, search Effective attributes: externalhost, member, memberof, memberuser Default attributes: member, memberof, memberuser, externalhost Bind rule type: all Subtree: cn=ng,cn=alt,$SUFFIX Target filter: (objectclass=ipanisnetgroup) Type: netgroup ipapermissiontype: V2, MANAGED, SYSTEM objectclass: ipapermission, groupofnames, top, ipapermissionv2 dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX Permission name: ipa:Read Netgroups Permissions: read, compare, search Effective attributes: cn, description, hostcategory, ipaenabledflag, ipauniqueid, nisdomainname, usercategory Default attributes: cn, usercategory, hostcategory, ipauniqueid, ipaenabledflag, nisdomainname, description Bind rule type: all Subtree: cn=ng,cn=alt,$SUFFIX Target filter: (objectclass=ipanisnetgroup) Type: netgroup ipapermissiontype: V2, MANAGED, SYSTEM objectclass: ipapermission, groupofnames, top, ipapermissionv2 ---------------------------- Number of entries returned 2 ---------------------------- with corresponding ACIs at cn=ng,cn=alt,$SUFFIX: (targetattr = "externalhost || member || memberof || memberuser")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read Netgroup Membership";allow (read,compare,search) userdn = "ldap:///all";) (targetattr = "cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read Netgroups";allow (read,compare,search) userdn = "ldap:///all";) Patches: 0473: Enables refactoring that will make it more clear (to humans and machines) what plugins code depends on. https://fedorahosted.org/freeipa/ticket/4185 0474: Fix handling of the search term for legacy permissions My code that's in master now handles the search term incorrectly. This does a better job. 0475: Fix tests that relied on some assumptions I'll be breaking 0476: Allow modifying (but not creating) permissions with ":" in the name 0477: Permission updater & sample metadata -- Petr? (* picked by fair dice roll) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0473-Allow-indexing-API-object-types-by-class.patch Type: text/x-patch Size: 4114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0474-permission-find-Fix-handling-of-the-search-term-for-.patch Type: text/x-patch Size: 3632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0475-test_permission_plugin-Fix-tests-that-make-too-broad.patch Type: text/x-patch Size: 6973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0476-Allow-modifying-permissions-with-in-the-name.patch Type: text/x-patch Size: 11359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0477-Add-Object-metadata-and-update-plugin-for-managed-pe.patch Type: text/x-patch Size: 8998 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 26 11:24:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 12:24:42 +0100 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 Message-ID: <530DCEFA.2090108@redhat.com> Hello all, I would like to discuss a proposal that Simo had on FreeIPA devel meeting. Given permission/ACI refactoring that Petr3 is working on, people may have issues with access to their LDAP if they played too much with the default ACIs or if they expect that some information stays accessible in the new version. It may not stay accessible we are removing the SUFFIX level all allowing ACIs and creating custom read ACIs. Bottom line is we need to do our best in making our users aware that there are big changes in this version they need to be aware of. One way is to release a new major release with appropriate release notes. I support that move, I think we have enough big features planned to justify new major release: * Permissions/ACIs * OTP * DNSSEC (hopefully) * CA Certificate Management Tool * Big Web UI face lift and refactoring * ... If there is no push back against that idea, let's do it. I would then rename the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Wed Feb 26 11:30:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 12:30:29 +0100 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <20140225181503.GY16644@redhat.com> References: <530C8ADD.9030803@redhat.com> <20140225181503.GY16644@redhat.com> Message-ID: <530DD055.3000809@redhat.com> On 02/25/2014 07:15 PM, Alexander Bokovoy wrote: > On Tue, 25 Feb 2014, Tomas Babej wrote: >> Hi, >> >> As a part of a better cleanup procedure in the integration tests, >> make sure that winbindd is not running after uninstalling the IPA >> server. > Better patch 0140 attached. We simply need to stop and disable winbind in > adtrustinstance.uninstall() Looks good to me (and a better approach than Tomas' 155 it seems). Since you are touching this section anyway, can you please also replace bare except with "except Exception:"? It will allow admin to CTRL+C the stopping process when needed. Thanks, Martin From abokovoy at redhat.com Wed Feb 26 11:31:43 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 13:31:43 +0200 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <530DCEFA.2090108@redhat.com> References: <530DCEFA.2090108@redhat.com> Message-ID: <20140226113143.GD16644@redhat.com> On Wed, 26 Feb 2014, Martin Kosek wrote: >Hello all, > >I would like to discuss a proposal that Simo had on FreeIPA devel meeting. >Given permission/ACI refactoring that Petr3 is working on, people may have >issues with access to their LDAP if they played too much with the default ACIs >or if they expect that some information stays accessible in the new version. It >may not stay accessible we are removing the SUFFIX level all allowing ACIs and >creating custom read ACIs. > >Bottom line is we need to do our best in making our users aware that there are >big changes in this version they need to be aware of. One way is to release a >new major release with appropriate release notes. > >I support that move, I think we have enough big features planned to justify new >major release: > >* Permissions/ACIs >* OTP >* DNSSEC (hopefully) >* CA Certificate Management Tool >* Big Web UI face lift and refactoring >* ... I agree. If we succeed with global catalog work, it would too be big enough feature. >If there is no push back against that idea, let's do it. I would then rename >the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. Yep. -- / Alexander Bokovoy From mkosek at redhat.com Wed Feb 26 11:37:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 12:37:35 +0100 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <20140226113143.GD16644@redhat.com> References: <530DCEFA.2090108@redhat.com> <20140226113143.GD16644@redhat.com> Message-ID: <530DD1FF.9070309@redhat.com> On 02/26/2014 12:31 PM, Alexander Bokovoy wrote: > On Wed, 26 Feb 2014, Martin Kosek wrote: >> Hello all, >> >> I would like to discuss a proposal that Simo had on FreeIPA devel meeting. >> Given permission/ACI refactoring that Petr3 is working on, people may have >> issues with access to their LDAP if they played too much with the default ACIs >> or if they expect that some information stays accessible in the new version. It >> may not stay accessible we are removing the SUFFIX level all allowing ACIs and >> creating custom read ACIs. >> >> Bottom line is we need to do our best in making our users aware that there are >> big changes in this version they need to be aware of. One way is to release a >> new major release with appropriate release notes. >> >> I support that move, I think we have enough big features planned to justify new >> major release: >> >> * Permissions/ACIs >> * OTP >> * DNSSEC (hopefully) >> * CA Certificate Management Tool >> * Big Web UI face lift and refactoring >> * ... > I agree. If we succeed with global catalog work, it would too be big > enough feature. Right. Though in this particular case it would also fit in the 3.x line as it would be actually completing our 3.x theme which is AD trust. It would add the IPA -> AD part. Martin From mkosek at redhat.com Wed Feb 26 11:39:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 12:39:41 +0100 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <20140226083303.GB16644@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> <20140226083303.GB16644@redhat.com> Message-ID: <530DD27D.5050303@redhat.com> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote: > On Wed, 26 Feb 2014, Martin Kosek wrote: >> On 02/25/2014 07:59 PM, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >>>> Resending patch 0138 together with another case Simo found out today: >>>> when authdata flag is cleared by admin for the service principal, we'll >>>> get NULL client database entry. In such case we have to bail out. >>> >>> The patches look correct code-flow-wise to me. >>> >>> So tentative ack pending testing. >>> >>> Simo. >>> >> >> Just checking - are we ok performance wise? If we for example add one >> additional LDAP search for every Kerberos authentication, it may increase the >> load on our LDAP server. > One additional LDAP query per S4U2Proxy ticket issuing. It is not much > and it has to be done because current code does it wrongly for MS-PAC. > > It is worth noting that issuing tickets should be relatively rare > operation -- with sessions in IPA server we don't hit HTTP/->ldap/ > service ticket granting in S4U2Proxy case more than once. > 'ipa trust-add' case is a bit more specific but you rarely establish > trusts every second of the day, aren't you? > > For normal operations it wouldn't affect anything beyond statistical > noise level. > If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the usual SSSD operations, then I have no concerns here. Martin From abokovoy at redhat.com Wed Feb 26 11:40:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 13:40:00 +0200 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <530DD055.3000809@redhat.com> References: <530C8ADD.9030803@redhat.com> <20140225181503.GY16644@redhat.com> <530DD055.3000809@redhat.com> Message-ID: <20140226114000.GE16644@redhat.com> On Wed, 26 Feb 2014, Martin Kosek wrote: >On 02/25/2014 07:15 PM, Alexander Bokovoy wrote: >> On Tue, 25 Feb 2014, Tomas Babej wrote: >>> Hi, >>> >>> As a part of a better cleanup procedure in the integration tests, >>> make sure that winbindd is not running after uninstalling the IPA >>> server. >> Better patch 0140 attached. We simply need to stop and disable winbind in >> adtrustinstance.uninstall() > >Looks good to me (and a better approach than Tomas' 155 it seems). Since you >are touching this section anyway, can you please also replace bare except with >"except Exception:"? > >It will allow admin to CTRL+C the stopping process when needed. Sure, new patch is attached. There are two potentially long external processes executed in the uninstall() so I changed to 'except Exception:' in both. -- / Alexander Bokovoy -------------- next part -------------- >From 74b7d5a3ffe77e6430d1b6c0cd175fea708c1855 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Feb 2014 20:11:50 +0200 Subject: [PATCH 3/5] adtrustinstance: make sure to stop and disable winbind in uninstall() This makes unnecessary Tomas' patch 0155. --- ipaserver/install/adtrustinstance.py | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 621e3fd..118b2fe 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -889,12 +889,15 @@ class ADTRUSTInstance(service.Service): self.restore_state("running") self.restore_state("enabled") + winbind = ipaservices.service("winbind") # Always try to stop and disable smb service, since we do not leave # working configuration after uninstall try: self.stop() self.disable() - except: + winbind.stop() + winbind.disable() + except Exception: pass # Since we do not guarantee restoring back to working samba state, @@ -907,7 +910,7 @@ class ADTRUSTInstance(service.Service): try: ipautil.run(["/usr/sbin/setsebool", "-P", var, sebool_state]) - except: + except Exception: self.print_msg(SELINUX_WARNING % dict(var=var)) # Remove samba's credentials cache -- 1.8.3.1 From abokovoy at redhat.com Wed Feb 26 11:42:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 13:42:29 +0200 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <530DD1FF.9070309@redhat.com> References: <530DCEFA.2090108@redhat.com> <20140226113143.GD16644@redhat.com> <530DD1FF.9070309@redhat.com> Message-ID: <20140226114229.GF16644@redhat.com> On Wed, 26 Feb 2014, Martin Kosek wrote: >On 02/26/2014 12:31 PM, Alexander Bokovoy wrote: >> On Wed, 26 Feb 2014, Martin Kosek wrote: >>> Hello all, >>> >>> I would like to discuss a proposal that Simo had on FreeIPA devel meeting. >>> Given permission/ACI refactoring that Petr3 is working on, people may have >>> issues with access to their LDAP if they played too much with the default ACIs >>> or if they expect that some information stays accessible in the new version. It >>> may not stay accessible we are removing the SUFFIX level all allowing ACIs and >>> creating custom read ACIs. >>> >>> Bottom line is we need to do our best in making our users aware that there are >>> big changes in this version they need to be aware of. One way is to release a >>> new major release with appropriate release notes. >>> >>> I support that move, I think we have enough big features planned to justify new >>> major release: >>> >>> * Permissions/ACIs >>> * OTP >>> * DNSSEC (hopefully) >>> * CA Certificate Management Tool >>> * Big Web UI face lift and refactoring >>> * ... >> I agree. If we succeed with global catalog work, it would too be big >> enough feature. > >Right. Though in this particular case it would also fit in the 3.x line as it >would be actually completing our 3.x theme which is AD trust. It would add the >IPA -> AD part. Technically it would be considerable change -- with new (cached) DS instance and a specialized schema, etc. -- / Alexander Bokovoy From pviktori at redhat.com Wed Feb 26 11:54:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Feb 2014 12:54:53 +0100 Subject: [Freeipa-devel] [PATCH] 0142: initialize BindInstance.zonemgr for short-circuited instance use in replica setup In-Reply-To: <20140226091351.GC16644@redhat.com> References: <20140226091351.GC16644@redhat.com> Message-ID: <530DD60D.5050503@redhat.com> On 02/26/2014 10:13 AM, Alexander Bokovoy wrote: > Hi, > > BindInstance is used in two different ways, with replica setup not > calling BindInstance.setup() before adding master records. This causes > some properties to be uninitialized and an exception when installing > replica. > > https://fedorahosted.org/freeipa/ticket/4186 Thanks, ACK, pushed to: master: 090a9669d8457a47880554bfbd1d99d0584e24ff ipa-3-3: 61654ea6f3a00266732cf19d769f62262ed80935 -- Petr? From pvoborni at redhat.com Wed Feb 26 11:57:34 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Feb 2014 12:57:34 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530D3B64.7090501@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> <1393252309.21604.3.camel@localhost.localdomain> <530B5BA3.4070403@redhat.com> <1393255303.21604.12.camel@localhost.localdomain> <530D3B64.7090501@redhat.com> Message-ID: <530DD6AE.507@redhat.com> On 26.2.2014 01:55, Dmitri Pal wrote: > On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: >> On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: >>> On 24.2.2014 15:31, Nathaniel McCallum wrote: >>>> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: >>>>> On 21.2.2014 20:00, Nathaniel McCallum wrote: >>>>>> Is it possible to do something more intelligent for the key and date >>>>>> fields in the add-token UI? >>>>>> >>>>>> Date fields are currently just a text box. Is there any sort of >>>>>> calendar >>>>>> we could use here? If not, I'm still unsure of what the format >>>>>> should be >>>>>> for this field. >>>>> It's the format you chose :), try to fill it in CLI, you will have the >>>>> same proble. From API level it's just string, from LDAP it's >>>>> generalized >>>>> time. >>>> Is there a better option? I'm open to suggestions. >>> As I mentioned below, it's being implemented. The datetime patches will >>> be send separately. The core OTP UI patches should not be blocked by >>> them. >>> >>>>> I've an UI patch prepared where you can write it in ISO format, with a >>>>> validator attached to it, so user will be noticed about the format, >>>>> but >>>>> it's waiting for: >>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html >>>>> >>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html >>>>> >>>>> >>>>>> The key field should probably have a note indicating that it is >>>>>> Base32 >>>>>> encoding. It would also be nice to restrict the input to Base32 >>>>>> characters. Maybe even automatic case correction... >>>>> Actually I think it doesn't help much. Show me a person who can write >>>>> base32 encoded string.... But I agree that a validator with some regex >>>>> to limit the chars and a note that it should be base32 string is >>>>> better. >>>>> The question is what's the purpose of this field from user >>>>> perspective. >>>>> Is a human being suppose to fill it or is it meant to be only >>>>> filled by >>>>> some provisioning systems? In UI it's just as a backup? >>>>> >>>>> If there is a use case where user is suppose to choose the key, it >>>>> would >>>>> be better to fill the key and convert it to base32 string on a server. >>>> I can't think of any case where a user would use the key field. >>>> >>>> However, there are at least two important cases where an admin would do >>>> this: >>>> 1. Hardware tokens >>>> 2. Transferring OATH (TOTP/HOTP) tokens from another system >>>> >>>> Nathaniel >>>> >>> What is the input format for these two cases? Is it base32 so admin can >>> enter it into UI or is it plain text so he has to use different tool to >>> encode it to base32 and then fill into UI? >> In both of the above cases, I suspect the predominant use will be >> scripts written to take a token store and import the tokens. This is >> mostly a non-UI case. >> >> RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. >> This is largely because, with fewer characters and no case-sensitivity, >> Base32 is easier to type. I don't know of any other encodings in wide >> use. >> >> It would be nice to support both of them, but I'm not sure how this is >> possible. Suggestions are welcome. > > I do not think we should allow typing the key (and other attributes) > manually. > We should rather ask user to import a token or tokens from the XML file > that uses RFC6030. > There are vendors of the hardware tokens that actually using it to > distribute the tokens. > > Here are the examples > http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files > > Please click around the site for more info. > This is one vendor. Do we have information that the other ones (or just the major ones) use the XML PSKC schema from RFC6030 as well? If that's the case, we have enough information for implementing otp-import (design page says that we don't have enough info). Back to UI. The UI might be useful if the admin has the values in different form than XML data, i.e., printed on a paper. Having the UI doesn't do any harm, right? If vendors mostly use base64 keys, adding only base32 support in our API doesn't make much sense. IMO it actually adds more work because you have to convert it first. Anyway: NACK for the patch because it shows totp/hotp switch in selfservice without possibility to define other hotp specifics. I'll remove it so there will be only totp in self-service (just token name+description). -- Petr Vobornik From amisnyov at redhat.com Wed Feb 26 12:00:45 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 26 Feb 2014 07:00:45 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Too big font in input fields In-Reply-To: <592875063.2565881.1393415933013.JavaMail.zimbra@redhat.com> Message-ID: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> Hi, too big font issue in ipa-3-3 and Firefox 27 fixed: In Firefox 27, default font size has bigger priority than body css, text input font size is therefore explicitly set to 1em https://fedorahosted.org/freeipa/ticket/4180 Thanks: Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0006-Too-big-font-in-input-fields.patch Type: text/x-patch Size: 819 bytes Desc: not available URL: From tbabej at redhat.com Wed Feb 26 13:16:07 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Feb 2014 14:16:07 +0100 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <530DD27D.5050303@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> <20140226083303.GB16644@redhat.com> <530DD27D.5050303@redhat.com> Message-ID: <530DE917.8070805@redhat.com> On 02/26/2014 12:39 PM, Martin Kosek wrote: > On 02/26/2014 09:33 AM, Alexander Bokovoy wrote: >> On Wed, 26 Feb 2014, Martin Kosek wrote: >>> On 02/25/2014 07:59 PM, Simo Sorce wrote: >>>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >>>>> Resending patch 0138 together with another case Simo found out today: >>>>> when authdata flag is cleared by admin for the service principal, we'll >>>>> get NULL client database entry. In such case we have to bail out. >>>> The patches look correct code-flow-wise to me. >>>> >>>> So tentative ack pending testing. >>>> >>>> Simo. >>>> >>> Just checking - are we ok performance wise? If we for example add one >>> additional LDAP search for every Kerberos authentication, it may increase the >>> load on our LDAP server. >> One additional LDAP query per S4U2Proxy ticket issuing. It is not much >> and it has to be done because current code does it wrongly for MS-PAC. >> >> It is worth noting that issuing tickets should be relatively rare >> operation -- with sessions in IPA server we don't hit HTTP/->ldap/ >> service ticket granting in S4U2Proxy case more than once. >> 'ipa trust-add' case is a bit more specific but you rarely establish >> trusts every second of the day, aren't you? >> >> For normal operations it wouldn't affect anything beyond statistical >> noise level. >> > If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the > usual SSSD operations, then I have no concerns here. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel After some thorough testing, ACK! With this patch, not only we solve the referenced IPA ticket, but adding a trust no longer requires retries in CI (and works on the first attempt). -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Wed Feb 26 13:17:25 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Feb 2014 14:17:25 +0100 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <530DE917.8070805@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> <20140226083303.GB16644@redhat.com> <530DD27D.5050303@redhat.com> <530DE917.8070805@redhat.com> Message-ID: <530DE965.3070000@redhat.com> On 02/26/2014 02:16 PM, Tomas Babej wrote: > On 02/26/2014 12:39 PM, Martin Kosek wrote: >> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote: >>> On Wed, 26 Feb 2014, Martin Kosek wrote: >>>> On 02/25/2014 07:59 PM, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >>>>>> Resending patch 0138 together with another case Simo found out today: >>>>>> when authdata flag is cleared by admin for the service principal, we'll >>>>>> get NULL client database entry. In such case we have to bail out. >>>>> The patches look correct code-flow-wise to me. >>>>> >>>>> So tentative ack pending testing. >>>>> >>>>> Simo. >>>>> >>>> Just checking - are we ok performance wise? If we for example add one >>>> additional LDAP search for every Kerberos authentication, it may increase the >>>> load on our LDAP server. >>> One additional LDAP query per S4U2Proxy ticket issuing. It is not much >>> and it has to be done because current code does it wrongly for MS-PAC. >>> >>> It is worth noting that issuing tickets should be relatively rare >>> operation -- with sessions in IPA server we don't hit HTTP/->ldap/ >>> service ticket granting in S4U2Proxy case more than once. >>> 'ipa trust-add' case is a bit more specific but you rarely establish >>> trusts every second of the day, aren't you? >>> >>> For normal operations it wouldn't affect anything beyond statistical >>> noise level. >>> >> If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the >> usual SSSD operations, then I have no concerns here. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > After some thorough testing, ACK! > > With this patch, not only we solve the referenced IPA ticket, but > adding a trust no longer requires retries in CI (and works on the first > attempt). > And by patch, I mean both 138 and 141, of course. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Wed Feb 26 13:21:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Feb 2014 14:21:17 +0100 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <530DE965.3070000@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> <20140226083303.GB16644@redhat.com> <530DD27D.5050303@redhat.com> <530DE917.8070805@redhat.com> <530DE965.3070000@redhat.com> Message-ID: <530DEA4D.4080105@redhat.com> On 02/26/2014 02:17 PM, Tomas Babej wrote: > > On 02/26/2014 02:16 PM, Tomas Babej wrote: >> On 02/26/2014 12:39 PM, Martin Kosek wrote: >>> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote: >>>> On Wed, 26 Feb 2014, Martin Kosek wrote: >>>>> On 02/25/2014 07:59 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: >>>>>>> Resending patch 0138 together with another case Simo found out today: >>>>>>> when authdata flag is cleared by admin for the service principal, we'll >>>>>>> get NULL client database entry. In such case we have to bail out. >>>>>> The patches look correct code-flow-wise to me. >>>>>> >>>>>> So tentative ack pending testing. >>>>>> >>>>>> Simo. >>>>>> >>>>> Just checking - are we ok performance wise? If we for example add one >>>>> additional LDAP search for every Kerberos authentication, it may increase the >>>>> load on our LDAP server. >>>> One additional LDAP query per S4U2Proxy ticket issuing. It is not much >>>> and it has to be done because current code does it wrongly for MS-PAC. >>>> >>>> It is worth noting that issuing tickets should be relatively rare >>>> operation -- with sessions in IPA server we don't hit HTTP/->ldap/ >>>> service ticket granting in S4U2Proxy case more than once. >>>> 'ipa trust-add' case is a bit more specific but you rarely establish >>>> trusts every second of the day, aren't you? >>>> >>>> For normal operations it wouldn't affect anything beyond statistical >>>> noise level. >>>> >>> If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the >>> usual SSSD operations, then I have no concerns here. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> After some thorough testing, ACK! >> >> With this patch, not only we solve the referenced IPA ticket, but >> adding a trust no longer requires retries in CI (and works on the first >> attempt). >> > And by patch, I mean both 138 and 141, of course. > Pushed to: master: f7955abdda854e58c60b74039bbd155f2dc66e75 ipa-3-3: c771ba23a88ef6869499f53d172f2282be19dd4d -- Petr? From pvoborni at redhat.com Wed Feb 26 13:32:52 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Feb 2014 14:32:52 +0100 Subject: [Freeipa-devel] [PATCH] Too big font in input fields In-Reply-To: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> References: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> Message-ID: <530DED04.6010704@redhat.com> On 26.2.2014 13:00, Adam Misnyovszki wrote: > Hi, > too big font issue in ipa-3-3 and Firefox 27 fixed: > > In Firefox 27, default font size has bigger priority than body css, > text input font size is therefore explicitly set to 1em > > https://fedorahosted.org/freeipa/ticket/4180 > > Thanks: > Adam > > NACK The issue is not present only in textboxes but also in comboboxes and selects. Btw, why the height: 12px? I suggest to use: input, select, textarea { font-size: 1em } this should set the defaults for the whole UI. In other topic Dmitri complained about ugliness of trust UI in 3.3 because of jammed radios and labels. Martin, can we steal this CSS ticket and fix it with? input[type=radio], input[type=checkbox], .ui-widget input[type=radio], .ui-widget input[type=checkbox]{ margin-right: 5px; position: relative; top: 2px; } -- Petr Vobornik From simo at redhat.com Wed Feb 26 13:40:30 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Feb 2014 08:40:30 -0500 Subject: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes In-Reply-To: <530DD27D.5050303@redhat.com> References: <20140225185803.GZ16644@redhat.com> <1393354798.18299.56.camel@willson.li.ssimo.org> <530D9D6B.6090103@redhat.com> <20140226083303.GB16644@redhat.com> <530DD27D.5050303@redhat.com> Message-ID: <1393422030.18299.119.camel@willson.li.ssimo.org> On Wed, 2014-02-26 at 12:39 +0100, Martin Kosek wrote: > On 02/26/2014 09:33 AM, Alexander Bokovoy wrote: > > On Wed, 26 Feb 2014, Martin Kosek wrote: > >> On 02/25/2014 07:59 PM, Simo Sorce wrote: > >>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: > >>>> Resending patch 0138 together with another case Simo found out today: > >>>> when authdata flag is cleared by admin for the service principal, we'll > >>>> get NULL client database entry. In such case we have to bail out. > >>> > >>> The patches look correct code-flow-wise to me. > >>> > >>> So tentative ack pending testing. > >>> > >>> Simo. > >>> > >> > >> Just checking - are we ok performance wise? If we for example add one > >> additional LDAP search for every Kerberos authentication, it may increase the > >> load on our LDAP server. > > One additional LDAP query per S4U2Proxy ticket issuing. It is not much > > and it has to be done because current code does it wrongly for MS-PAC. > > > > It is worth noting that issuing tickets should be relatively rare > > operation -- with sessions in IPA server we don't hit HTTP/->ldap/ > > service ticket granting in S4U2Proxy case more than once. > > 'ipa trust-add' case is a bit more specific but you rarely establish > > trusts every second of the day, aren't you? > > > > For normal operations it wouldn't affect anything beyond statistical > > noise level. > > > > If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the > usual SSSD operations, then I have no concerns here. Yes, this is a relatively rare event for now. But even if it weren't there is no work around for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From amisnyov at redhat.com Wed Feb 26 13:45:04 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 26 Feb 2014 08:45:04 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Too big font in input fields In-Reply-To: <530DED04.6010704@redhat.com> References: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> <530DED04.6010704@redhat.com> Message-ID: <1842114861.2580020.1393422304800.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Vobornik" > To: "Adam Misnyovszki" , freeipa-devel at redhat.com, "Martin Kosek" > Sent: Wednesday, February 26, 2014 2:32:52 PM > Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields > > On 26.2.2014 13:00, Adam Misnyovszki wrote: > > Hi, > > too big font issue in ipa-3-3 and Firefox 27 fixed: > > > > In Firefox 27, default font size has bigger priority than body css, > > text input font size is therefore explicitly set to 1em > > > > https://fedorahosted.org/freeipa/ticket/4180 > > > > Thanks: > > Adam > > > > > > NACK > > The issue is not present only in textboxes but also in comboboxes and > selects. Btw, why the height: 12px? Because somehow the add new textboxes are 12px high, the other ones, where the issue is present, are 13px even with font-size: 1em > > I suggest to use: > > input, select, textarea { > font-size: 1em > } Will do it, ty > > this should set the defaults for the whole UI. > > In other topic Dmitri complained about ugliness of trust UI in 3.3 > because of jammed radios and labels. Martin, can we steal this CSS > ticket and fix it with? > > input[type=radio], input[type=checkbox], > .ui-widget input[type=radio], .ui-widget input[type=checkbox]{ > margin-right: 5px; > position: relative; > top: 2px; > } Will try this also > -- > Petr Vobornik > Thanks Adam From jcholast at redhat.com Wed Feb 26 13:57:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Feb 2014 14:57:30 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530CEE75.1070801@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> Message-ID: <530DF2CA.70506@redhat.com> On 25.2.2014 20:26, Petr Spacek wrote: > On 25.2.2014 19:13, Dmitri Pal wrote: >> On 02/25/2014 08:46 AM, Simo Sorce wrote: >>> On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote: >>>> On 24.2.2014 20:20, Simo Sorce wrote: >>>>> Also can you add some examples on how we would use these classes to >>>>> store DNS keys ? >>>> We need to think about it a bit more. We plan to use PKCS#11 for key >>>> manipulation and data signing so the key itself will be unaware of any >>>> DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary >>>> objectClass. >>>> >>>> I'm discussing this with CZ.NIC guys and they propose to add a >>>> 'layer of >>>> indirection' between DNS zones and keys so one key set can be used >>>> by more DNS >>>> zones. They claim that it is relatively common practice and I trust >>>> them. >>>> >>>> Note that I'm not saying that IPA should use one key for multiple >>>> DNS zones by >>>> default, but the schema should be future-proof and allow that if >>>> necessary. >>> Makes sense. >>> >>>> Let's start with this proposal: >>>> DNS zone: idnsname=dnssec.test, cn=dns, dc=example >>>> There will be multi-valued attribute idnsseckey pointing to DNs of >>>> keys stored >>>> somewhere else. >>>> >>>> Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns >>>> and store >>>> keys there. >>> Ok, do we really want to have zones pointing at keys ? >>> Or do we want keys have a list of zones they are supposed to apply to ? >> >> >> If we plan to store DNS keys in one place and other keys in other >> places in >> the tree (no common key store) then it really does not matter much. >> It should be derived from the LDAP searches that would need to be >> conducted by >> the software. >> >> We need keys for signing, right? >> Any other use case? > In DNSSEC-context no, but the same principle will be re-used for CA > certificates and possibly user-keys (in future, like SSH private keys or > certificated used from Firefox). > >> If for signing we will start with a zone and would need to find keys >> that are >> relevant to this zone. >> It seems that having a generic key class + auxiliary class that would >> keep >> metadata about the key, its expiration and DN it applies to would be a >> way to go. > Yes, this is the plan. > >> So it seems that I agree with Simo that it would make sense to have >> the zone >> the key applies to specified in the key entry rather than in the zone >> entry. > Practically it doesn't matter. You have to do either search to find > zones associated with given key or another search to find keys > associated with given zone. > > Maybe the version with list of zones stored in key is better from ACI's > point of view. Access to list of zones will be controlled with ACI > attached to the key object. > > ... Would it be a problem to have bi-directional link between key and > zone (member-memberOf style)? It would ease processing on the client > side and I think that the price is not that high. We can use existing > member and memberOf attributes if we decide to do that. > >>>> I expect that PKCS#11 module will handle keys scattered over the >>>> LDAP tree >>>> somehow. >>> Sure as long as it can understand what the keys are for. >>> >>>>> Ideally the example would show the LDAP tree and some example data in >>>>> detail, and also what operation we think would be common. > > I was talking about 'layer of indirection' previously. I'm digging into > details and it seems like a good idea to imitate what DNS registrars do > - use concept of key sets. It means that keys are not linked to a zone > one by one but rather a whole set of keys is linked to a zone. > > It eases key rotation because you just need to drop a new key to a key > set and you don't have to add DNs of all zones to the new key (or the > other way around). > > Another thing is that you could have different key rotation policies for > different key sets... we need to think about it carefully. > > For example (without policies for now): > - two DNS zones example.com and example.net contain a pointer to keyset > called 'setA' > - zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns > > - key sets are stored under cn=keysets, cn=sec, cn=dns > > - individual keys are stored under keyid=key1, keysetid=setA, > cn=keysets, cn=sec, cn=dns How will the PKCS#11 module know into which keyset to store a key generated by OpenDNSSEC? Are you suggesting having a separate slot/token for each keyset? I would like to keep the number of tokens low, because there are applications which go slot by slot, token by token when searching for objects (e.g. BIND and OpenSSH) and that might generate a lot of unnecessary traffic if the number of slots/tokens is high. > > See the attached picture. > > Are you okay with that? If so, we need to somehow add key rotation > policy to this mix :-) > > This machinery has to allow algorithm-rollover, keysize-rollover etc. > We can get some inspiration from > https://wiki.opendnssec.org/display/DOCS/kasp.xml . Note that OpenDNSSEC > 1.x can't do algorithm-rollover so we need to be creative with the design. -- Jan Cholasta From jcholast at redhat.com Wed Feb 26 14:04:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Feb 2014 15:04:31 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <1393356125.18299.67.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> Message-ID: <530DF46F.5090409@redhat.com> On 25.2.2014 20:22, Simo Sorce wrote: > On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 25.2.2014 17:36, Ludwig Krispenz wrote: >>>> >>>> On 02/25/2014 05:12 PM, Simo Sorce wrote: >>>>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >>>>>> On 25.2.2014 16:11, Simo Sorce wrote: >>>>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>>>>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>>>>>> because I did't know what is really needed. If you want to have a >>>>>>>>>> pkcs11 >>>>>>>>>> module, which stores data in ldap, I though it should have all the >>>>>>>>>> attributes potentially needed. >>>>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>>>>>> CKA_EXTRACTABLE, >>>>>>>>>> so there is at least one requirement for fine grained attributes. >>>>>>>>> Does OpenDNSSEC store them as separate entities and need access >>>>>>>>> to them >>>>>>>>> independently ? >>>>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP >>>>>>>> schema >>>>>>>> doesn't matter as long as our PKCS#11 module can derive all values >>>>>>>> defined by >>>>>>>> standard. >>>>>>>> >>>>>>>> Honza, you did investigate OpenDNSSEC integration, please add some >>>>>>>> details if >>>>>>>> you can. >>>>>>>> >>>>>>>>> Or is this internal use that can be satisfied by unpacking a blob in >>>>>>>>> OpenDNSSEC ? >>>>>>>>> >>>>>>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>>>>>> Private+public keys stored in files: >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>>>>>> >>>>>>>> >>>>>>>> Private keys stored in HSM and public keys in files: >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>>>>>> >>>>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>>>>>> Ok it seem clear to me we do not need to spell out a lot of values >>>>>>> when >>>>>>> using pkcs#11 as bind doesn't need them in the key files. So I >>>>>>> assume it >>>>>>> can query the pkcs#11 module to find what it needs. >>>>>>> >>>>>>> I would use these key files as a sort of guide to understand what we >>>>>>> need in LDAP. I would try to put in a single blob as much as we can >>>>>>> that >>>>>>> we do not explicitly need by a client querying LDAP directly. >>>>>>> >>>>>>> I think in order to nail down exactly what we need, at this point, we >>>>>>> require some example use cases and queries the various clients would >>>>>>> perform with spelled out what they are looking for to identify or >>>>>>> manipulate keys. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> See "How applications interact with PKCS#11" at >>>>>> . Tl;dr: applications >>>>>> don't search for keys by key data, but by metadata, so like I said in >>>>>> the other thread, key data can be in a single blob, but metadata should >>>>>> be in separate attributes. >>>>> Ah sorry, I hadn't looked at that one yet. >>>>> It helps quite a bit. >>>>> >>>>> So are the class, key_type, id, label, token, 'sign' the only values we >>>>> should really care to split off ? >>> >>> They are all metadata related to PKCS#11 operation. I don't think you >>> can easily encode them in PKCS#8 or certificate blob, so they actually >>> need to be split off. You can find the full list of them in the PKCS#11 >>> spec (link below). >>> >>>>> >>>>> Can you describe what are these values ? >>>>> What is class ? Why is it important, and how does it differ from >>>>> key_type ? >>>>> What is the token ? What is 'sign' ? >>>>> >>>>> Feel free to give references to specific documents to read up about >>>>> these attributes. >>>> I'm a newcomer to this area and am orienting myself at this doc: >>>> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >>>> and looking into opendnssec andsofthsm code. >>> >>> I use mainly >>> , as >>> 2.30 is a draft ATM. >>> >>>> >>>> It explains CKA_SIGN as: >>>> "TheCKA_SIGN attribute of the signature key, whic h indicates whether >>>> the key supports signatures with appendix, must be CK_TRUE." >>>> I cannot tell if this will be needed, just can make up an attribute and >>>> allow it in an objectclass :-) >>> >>> OpenDNSSEC puts it in public key objects it generates, so it's needed at >>> least for the sake of it. >>> >>> Actually, I think we should support all of the metadata attributes, so >>> that our PKCS#11 module is reasonably generic and not tailored to needs >>> of a specific consumer. >> >> We could hardcode some of these values but it will very likely cause >> problems later. It seems simple enough to just define schema for all of >> them and store them, except perhaps in the cases where they are easily >> derived. If we, for example, store the prime numbers and exponents, they >> need to be protected as carefully as the private key. > > This is something I meant to discuss too, how do we protect them ? > Clearly we have ACIs but I am wondering if we want to encrypt them with > keys not immediately or easily available via LDAP ? > > It's kind of catastrofic if they get inadvertently exposed like if > someone does a ldapsearch as "Directory Manager", which is one of the > reasons why we encrypt kerberos key material before storing it into the > db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. > > Simo. > -- Jan Cholasta From lkrispen at redhat.com Wed Feb 26 14:20:17 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 26 Feb 2014 15:20:17 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530DF2CA.70506@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> <530DF2CA.70506@redhat.com> Message-ID: <530DF821.7040607@redhat.com> >> I was talking about 'layer of indirection' previously. I'm digging into >> details and it seems like a good idea to imitate what DNS registrars do >> - use concept of key sets. It means that keys are not linked to a zone >> one by one but rather a whole set of keys is linked to a zone. >> >> It eases key rotation because you just need to drop a new key to a key >> set and you don't have to add DNs of all zones to the new key (or the >> other way around). >> >> Another thing is that you could have different key rotation policies for >> different key sets... we need to think about it carefully. >> >> For example (without policies for now): >> - two DNS zones example.com and example.net contain a pointer to keyset >> called 'setA' >> - zone objects: idnsname=example.net,cn=dns and >> idnsname=example.com,cn=dns >> >> - key sets are stored under cn=keysets, cn=sec, cn=dns >> >> - individual keys are stored under keyid=key1, keysetid=setA, >> cn=keysets, cn=sec, cn=dns > > How will the PKCS#11 module know into which keyset to store a key > generated by OpenDNSSEC? Are you suggesting having a separate > slot/token for each keyset? I would like to keep the number of tokens > low, because there are applications which go slot by slot, token by > token when searching for objects (e.g. BIND and OpenSSH) and that > might generate a lot of unnecessary traffic if the number of > slots/tokens is high. The pkcs11 data stored in ldap should represent pkcs11 objects. Other entries could reference these objects, eg a zone referencing a key. I don't think we should store references to other entries in an pkcs11 object. if you want this we probably need another auxiliary objectclass for these pkcs11 entries. Regarding objectclasses for the pkcs11 objects, what should be the structural objectclass and what the naming attribute ? So far I had defined the publicKey, privateKey, certificate objectclass all as auxiliary, maybe we should have one structural like pkcs11Object containing the required attrs like id, label, ... and a naming attr if it is not one of them From rcritten at redhat.com Wed Feb 26 14:28:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Feb 2014 09:28:44 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530DF46F.5090409@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> Message-ID: <530DFA1C.7070404@redhat.com> Jan Cholasta wrote: > On 25.2.2014 20:22, Simo Sorce wrote: >> On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 25.2.2014 17:36, Ludwig Krispenz wrote: >>>>> >>>>> On 02/25/2014 05:12 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: >>>>>>> On 25.2.2014 16:11, Simo Sorce wrote: >>>>>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: >>>>>>>>> On 25.2.2014 15:11, Simo Sorce wrote: >>>>>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: >>>>>>>>>>>> Any reason why we should follow in detail what softshm does ? >>>>>>>>>>> because I did't know what is really needed. If you want to >>>>>>>>>>> have a >>>>>>>>>>> pkcs11 >>>>>>>>>>> module, which stores data in ldap, I though it should have >>>>>>>>>>> all the >>>>>>>>>>> attributes potentially needed. >>>>>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, >>>>>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, >>>>>>>>>>> CKA_EXTRACTABLE, >>>>>>>>>>> so there is at least one requirement for fine grained >>>>>>>>>>> attributes. >>>>>>>>>> Does OpenDNSSEC store them as separate entities and need access >>>>>>>>>> to them >>>>>>>>>> independently ? >>>>>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP >>>>>>>>> schema >>>>>>>>> doesn't matter as long as our PKCS#11 module can derive all values >>>>>>>>> defined by >>>>>>>>> standard. >>>>>>>>> >>>>>>>>> Honza, you did investigate OpenDNSSEC integration, please add some >>>>>>>>> details if >>>>>>>>> you can. >>>>>>>>> >>>>>>>>>> Or is this internal use that can be satisfied by unpacking a >>>>>>>>>> blob in >>>>>>>>>> OpenDNSSEC ? >>>>>>>>>> >>>>>>>>>> What does bind9 uses ? Petr, can you provide example key files ? >>>>>>>>> Private+public keys stored in files: >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Private keys stored in HSM and public keys in files: >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html >>>>>>>>> >>>>>>>>> >>>>>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) >>>>>>>> Ok it seem clear to me we do not need to spell out a lot of values >>>>>>>> when >>>>>>>> using pkcs#11 as bind doesn't need them in the key files. So I >>>>>>>> assume it >>>>>>>> can query the pkcs#11 module to find what it needs. >>>>>>>> >>>>>>>> I would use these key files as a sort of guide to understand >>>>>>>> what we >>>>>>>> need in LDAP. I would try to put in a single blob as much as we can >>>>>>>> that >>>>>>>> we do not explicitly need by a client querying LDAP directly. >>>>>>>> >>>>>>>> I think in order to nail down exactly what we need, at this >>>>>>>> point, we >>>>>>>> require some example use cases and queries the various clients >>>>>>>> would >>>>>>>> perform with spelled out what they are looking for to identify or >>>>>>>> manipulate keys. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> See "How applications interact with PKCS#11" at >>>>>>> . Tl;dr: applications >>>>>>> don't search for keys by key data, but by metadata, so like I >>>>>>> said in >>>>>>> the other thread, key data can be in a single blob, but metadata >>>>>>> should >>>>>>> be in separate attributes. >>>>>> Ah sorry, I hadn't looked at that one yet. >>>>>> It helps quite a bit. >>>>>> >>>>>> So are the class, key_type, id, label, token, 'sign' the only >>>>>> values we >>>>>> should really care to split off ? >>>> >>>> They are all metadata related to PKCS#11 operation. I don't think you >>>> can easily encode them in PKCS#8 or certificate blob, so they actually >>>> need to be split off. You can find the full list of them in the PKCS#11 >>>> spec (link below). >>>> >>>>>> >>>>>> Can you describe what are these values ? >>>>>> What is class ? Why is it important, and how does it differ from >>>>>> key_type ? >>>>>> What is the token ? What is 'sign' ? >>>>>> >>>>>> Feel free to give references to specific documents to read up about >>>>>> these attributes. >>>>> I'm a newcomer to this area and am orienting myself at this doc: >>>>> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >>>>> and looking into opendnssec andsofthsm code. >>>> >>>> I use mainly >>>> , as >>>> 2.30 is a draft ATM. >>>> >>>>> >>>>> It explains CKA_SIGN as: >>>>> "TheCKA_SIGN attribute of the signature key, whic h indicates whether >>>>> the key supports signatures with appendix, must be CK_TRUE." >>>>> I cannot tell if this will be needed, just can make up an attribute >>>>> and >>>>> allow it in an objectclass :-) >>>> >>>> OpenDNSSEC puts it in public key objects it generates, so it's >>>> needed at >>>> least for the sake of it. >>>> >>>> Actually, I think we should support all of the metadata attributes, so >>>> that our PKCS#11 module is reasonably generic and not tailored to needs >>>> of a specific consumer. >>> >>> We could hardcode some of these values but it will very likely cause >>> problems later. It seems simple enough to just define schema for all of >>> them and store them, except perhaps in the cases where they are easily >>> derived. If we, for example, store the prime numbers and exponents, they >>> need to be protected as carefully as the private key. >> >> This is something I meant to discuss too, how do we protect them ? >> Clearly we have ACIs but I am wondering if we want to encrypt them with >> keys not immediately or easily available via LDAP ? >> >> It's kind of catastrofic if they get inadvertently exposed like if >> someone does a ldapsearch as "Directory Manager", which is one of the >> reasons why we encrypt kerberos key material before storing it into the >> db. > > PKCS#8 allows encryption, I guess we can use that. There needs to be > some metadata on how to decrypt the blob though, so that the PKCS#11 > module can actually decrypt it when necessary. Yes but if you are also storing the primes, modulus and exponents as attributes those will need to be protected as well. I don't think these need to, or should, be stored. They can be derived from the private key which as you point out, can be encrypted. I'll note that the CA-specific design page doesn't call for storing these but the schema in the DNSSEC defines attributes for them. So I don't mean to suggest that you are advocating for storing them. rob From pviktori at redhat.com Wed Feb 26 14:46:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Feb 2014 15:46:55 +0100 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <530DCEFA.2090108@redhat.com> References: <530DCEFA.2090108@redhat.com> Message-ID: <530DFE5F.5020303@redhat.com> On 02/26/2014 12:24 PM, Martin Kosek wrote: > Hello all, > > I would like to discuss a proposal that Simo had on FreeIPA devel meeting. > Given permission/ACI refactoring that Petr3 is working on, people may have > issues with access to their LDAP if they played too much with the default ACIs > or if they expect that some information stays accessible in the new version. It > may not stay accessible we are removing the SUFFIX level all allowing ACIs and > creating custom read ACIs. > > Bottom line is we need to do our best in making our users aware that there are > big changes in this version they need to be aware of. One way is to release a > new major release with appropriate release notes. > > I support that move, I think we have enough big features planned to justify new > major release: > > * Permissions/ACIs > * OTP > * DNSSEC (hopefully) > * CA Certificate Management Tool > * Big Web UI face lift and refactoring > * ... > > If there is no push back against that idea, let's do it. I would then rename > the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. > +1 I guess the http://www.freeipa.org/page/V3 tree will also need some renaming. -- Petr? From simo at redhat.com Wed Feb 26 15:00:20 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Feb 2014 10:00:20 -0500 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530DF46F.5090409@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> Message-ID: <1393426820.18299.163.camel@willson.li.ssimo.org> On Wed, 2014-02-26 at 15:04 +0100, Jan Cholasta wrote: > On 25.2.2014 20:22, Simo Sorce wrote: > > On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote: > >> Jan Cholasta wrote: > >>> On 25.2.2014 17:36, Ludwig Krispenz wrote: > >>>> > >>>> On 02/25/2014 05:12 PM, Simo Sorce wrote: > >>>>> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote: > >>>>>> On 25.2.2014 16:11, Simo Sorce wrote: > >>>>>>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote: > >>>>>>>> On 25.2.2014 15:11, Simo Sorce wrote: > >>>>>>>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote: > >>>>>>>>>>> Any reason why we should follow in detail what softshm does ? > >>>>>>>>>> because I did't know what is really needed. If you want to have a > >>>>>>>>>> pkcs11 > >>>>>>>>>> module, which stores data in ldap, I though it should have all the > >>>>>>>>>> attributes potentially needed. > >>>>>>>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, > >>>>>>>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, > >>>>>>>>>> CKA_EXTRACTABLE, > >>>>>>>>>> so there is at least one requirement for fine grained attributes. > >>>>>>>>> Does OpenDNSSEC store them as separate entities and need access > >>>>>>>>> to them > >>>>>>>>> independently ? > >>>>>>>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP > >>>>>>>> schema > >>>>>>>> doesn't matter as long as our PKCS#11 module can derive all values > >>>>>>>> defined by > >>>>>>>> standard. > >>>>>>>> > >>>>>>>> Honza, you did investigate OpenDNSSEC integration, please add some > >>>>>>>> details if > >>>>>>>> you can. > >>>>>>>> > >>>>>>>>> Or is this internal use that can be satisfied by unpacking a blob in > >>>>>>>>> OpenDNSSEC ? > >>>>>>>>> > >>>>>>>>> What does bind9 uses ? Petr, can you provide example key files ? > >>>>>>>> Private+public keys stored in files: > >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html > >>>>>>>> > >>>>>>>> > >>>>>>>> Private keys stored in HSM and public keys in files: > >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html > >>>>>>>> > >>>>>>>> (I.e. some values in .private file are replaced by PKCS#11 label.) > >>>>>>> Ok it seem clear to me we do not need to spell out a lot of values > >>>>>>> when > >>>>>>> using pkcs#11 as bind doesn't need them in the key files. So I > >>>>>>> assume it > >>>>>>> can query the pkcs#11 module to find what it needs. > >>>>>>> > >>>>>>> I would use these key files as a sort of guide to understand what we > >>>>>>> need in LDAP. I would try to put in a single blob as much as we can > >>>>>>> that > >>>>>>> we do not explicitly need by a client querying LDAP directly. > >>>>>>> > >>>>>>> I think in order to nail down exactly what we need, at this point, we > >>>>>>> require some example use cases and queries the various clients would > >>>>>>> perform with spelled out what they are looking for to identify or > >>>>>>> manipulate keys. > >>>>>>> > >>>>>>> Simo. > >>>>>>> > >>>>>> See "How applications interact with PKCS#11" at > >>>>>> . Tl;dr: applications > >>>>>> don't search for keys by key data, but by metadata, so like I said in > >>>>>> the other thread, key data can be in a single blob, but metadata should > >>>>>> be in separate attributes. > >>>>> Ah sorry, I hadn't looked at that one yet. > >>>>> It helps quite a bit. > >>>>> > >>>>> So are the class, key_type, id, label, token, 'sign' the only values we > >>>>> should really care to split off ? > >>> > >>> They are all metadata related to PKCS#11 operation. I don't think you > >>> can easily encode them in PKCS#8 or certificate blob, so they actually > >>> need to be split off. You can find the full list of them in the PKCS#11 > >>> spec (link below). > >>> > >>>>> > >>>>> Can you describe what are these values ? > >>>>> What is class ? Why is it important, and how does it differ from > >>>>> key_type ? > >>>>> What is the token ? What is 'sign' ? > >>>>> > >>>>> Feel free to give references to specific documents to read up about > >>>>> these attributes. > >>>> I'm a newcomer to this area and am orienting myself at this doc: > >>>> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf > >>>> and looking into opendnssec andsofthsm code. > >>> > >>> I use mainly > >>> , as > >>> 2.30 is a draft ATM. > >>> > >>>> > >>>> It explains CKA_SIGN as: > >>>> "TheCKA_SIGN attribute of the signature key, whic h indicates whether > >>>> the key supports signatures with appendix, must be CK_TRUE." > >>>> I cannot tell if this will be needed, just can make up an attribute and > >>>> allow it in an objectclass :-) > >>> > >>> OpenDNSSEC puts it in public key objects it generates, so it's needed at > >>> least for the sake of it. > >>> > >>> Actually, I think we should support all of the metadata attributes, so > >>> that our PKCS#11 module is reasonably generic and not tailored to needs > >>> of a specific consumer. > >> > >> We could hardcode some of these values but it will very likely cause > >> problems later. It seems simple enough to just define schema for all of > >> them and store them, except perhaps in the cases where they are easily > >> derived. If we, for example, store the prime numbers and exponents, they > >> need to be protected as carefully as the private key. > > > > This is something I meant to discuss too, how do we protect them ? > > Clearly we have ACIs but I am wondering if we want to encrypt them with > > keys not immediately or easily available via LDAP ? > > > > It's kind of catastrofic if they get inadvertently exposed like if > > someone does a ldapsearch as "Directory Manager", which is one of the > > reasons why we encrypt kerberos key material before storing it into the > > db. > > PKCS#8 allows encryption, I guess we can use that. There needs to be > some metadata on how to decrypt the blob though, so that the PKCS#11 > module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Wed Feb 26 15:01:39 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 26 Feb 2014 08:01:39 -0700 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account Message-ID: Hi all, I added a tip in the deleting users section on restoring admin account. Please review. https://fedorahosted.org/freeipa/ticket/2746 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0007-DOC-Document-steps-to-restore-deleted-admin-account.patch Type: application/octet-stream Size: 1640 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 26 15:41:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 16:41:56 +0100 Subject: [Freeipa-devel] [PATCH] Too big font in input fields In-Reply-To: <1842114861.2580020.1393422304800.JavaMail.zimbra@redhat.com> References: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> <530DED04.6010704@redhat.com> <1842114861.2580020.1393422304800.JavaMail.zimbra@redhat.com> Message-ID: <530E0B44.4090105@redhat.com> On 02/26/2014 02:45 PM, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Petr Vobornik" >> To: "Adam Misnyovszki" , freeipa-devel at redhat.com, "Martin Kosek" >> Sent: Wednesday, February 26, 2014 2:32:52 PM >> Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields ... >> this should set the defaults for the whole UI. >> >> In other topic Dmitri complained about ugliness of trust UI in 3.3 >> because of jammed radios and labels. Martin, can we steal this CSS >> ticket and fix it with? Given it is this little change I think you can. >> >> input[type=radio], input[type=checkbox], >> .ui-widget input[type=radio], .ui-widget input[type=checkbox]{ >> margin-right: 5px; >> position: relative; >> top: 2px; >> } > > Will try this also Martin From rmeggins at redhat.com Wed Feb 26 15:45:58 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 08:45:58 -0700 Subject: [Freeipa-devel] Is there RPC documentation? Message-ID: <530E0C36.8080507@redhat.com> I'm working on adding support for freeipa DNS to openstack designate (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to communicate with freeipa. Is there documentation about how to construct and send RPC messages? From mkosek at redhat.com Wed Feb 26 15:48:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Feb 2014 16:48:17 +0100 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified In-Reply-To: <20140225175616.GX16644@redhat.com> References: <20140225175616.GX16644@redhat.com> Message-ID: <530E0CC1.5060708@redhat.com> On 02/25/2014 06:56 PM, Alexander Bokovoy wrote: > Hi, > > Simple patch to fix KeyError as --pkey-only causes no attributes to be > returned and trustdomain_find.post_callback checked them > unconditionally. > > > https://fedorahosted.org/freeipa/ticket/4196 Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.: def post_callback(self, ldap, entries, truncated, *args, **options): if not options.get('pkey_only', False): trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') trust_entry = ldap.get_entry(trust_dn) ... It seems to me that your way we still do one unnecessary LDAP search which is never used. With pkey_only we should not be filling anything in post_callback at all if it is not affecting the pkey. Martin From pviktori at redhat.com Wed Feb 26 15:53:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Feb 2014 16:53:38 +0100 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E0C36.8080507@redhat.com> References: <530E0C36.8080507@redhat.com> Message-ID: <530E0E02.8070505@redhat.com> On 02/26/2014 04:45 PM, Rich Megginson wrote: > I'm working on adding support for freeipa DNS to openstack designate > (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to > communicate with freeipa. Is there documentation about how to construct > and send RPC messages? The JSON-RPC and XML-RPC API is still not "officially supported" (read: documented), though it's extremely unlikely to change. If you need an example, run any ipa command with -vv, this will print out the request & response. API.txt in the source tree lists all the commands and params. This blog post still applies (but be sure to read the update about --cacert): http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ -- Petr? From abokovoy at redhat.com Wed Feb 26 15:54:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 17:54:08 +0200 Subject: [Freeipa-devel] [PATCH] 0143: catch access denial when removing old trust object when using non-privileged AD user to create trust Message-ID: <20140226155408.GI16644@redhat.com> Hi, this patch fixes a case when non-privileged AD user account is used to re-establish trust. We need to catch one specific exception in deleting the old trust and bail out earlier with proper error message. https://fedorahosted.org/freeipa/ticket/4202 -- / Alexander Bokovoy -------------- next part -------------- >From 1ffd12988778fd9fcec3ad5436fd79753087ebfb Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 26 Feb 2014 17:43:34 +0200 Subject: [PATCH 6/6] ipaserver/dcerpc: catch the case of insuffient permissions when establishing trust We attempt to delete the trust that might exist already. If there are not enough privileges to do so, we wouldn't be able to create trust at the next step and it will fail. However, failure to create trust will be due to the name collision as we already had the trust with the same name before. Thus, raise access denied exception here to properly indicate wrong access level instead of returning NT_STATUS_OBJECT_NAME_COLLISION. https://fedorahosted.org/freeipa/ticket/4202 --- ipaserver/dcerpc.py | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index d809c41..5972e62 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -892,8 +892,11 @@ class TrustDomainInstance(object): dname.string = another_domain.info['dns_domain'] res = self._pipe.QueryTrustedDomainInfoByName(self._policy_handle, dname, lsa.LSA_TRUSTED_DOMAIN_INFO_FULL_INFO) self._pipe.DeleteTrustedDomain(self._policy_handle, res.info_ex.sid) - except RuntimeError, e: - pass + except RuntimeError, (num, message): + # Ignore anything but access denied (NT_STATUS_ACCESS_DENIED) + if num == -1073741790: + raise access_denied_error + try: trustdom_handle = self._pipe.CreateTrustedDomainEx2(self._policy_handle, info, self.auth_info, security.SEC_STD_DELETE) except RuntimeError, (num, message): -- 1.8.3.1 From amisnyov at redhat.com Wed Feb 26 15:55:16 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 26 Feb 2014 10:55:16 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog In-Reply-To: <530C9859.7090709@redhat.com> References: <530C9859.7090709@redhat.com> Message-ID: <1583417328.2609623.1393430116585.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Vobornik" > To: "freeipa-devel" > Sent: Tuesday, February 25, 2014 2:19:21 PM > Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog > > Dialog loses focus when the links are clicked making the dialog > uncontrollable by keyboard. This patch focuses the link again after > expanding/collapsing the error list. Thus keeping the focus in a dialog > > https://fedorahosted.org/freeipa/ticket/4097 > -- > Petr Vobornik ACK works fine on FF26, 27, GC33 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Wed Feb 26 16:18:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Feb 2014 17:18:17 +0100 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E0E02.8070505@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> Message-ID: <530E13C9.3040006@redhat.com> On 26.2.2014 16:53, Petr Viktorin wrote: > On 02/26/2014 04:45 PM, Rich Megginson wrote: >> I'm working on adding support for freeipa DNS to openstack designate >> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >> communicate with freeipa. Is there documentation about how to construct >> and send RPC messages? > > The JSON-RPC and XML-RPC API is still not "officially supported" (read: > documented), though it's extremely unlikely to change. > If you need an example, run any ipa command with -vv, this will print > out the request & response. > API.txt in the source tree lists all the commands and params. > This blog post still applies (but be sure to read the update about > --cacert): > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > > Web UI communicates with API through JSON-RPC so you can open browser developer tools (F12) and inspect requests/responses in network tab. -- Petr Vobornik From rmeggins at redhat.com Wed Feb 26 16:26:21 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 09:26:21 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E13C9.3040006@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E13C9.3040006@redhat.com> Message-ID: <530E15AD.2020500@redhat.com> On 02/26/2014 09:18 AM, Petr Vobornik wrote: > On 26.2.2014 16:53, Petr Viktorin wrote: >> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>> I'm working on adding support for freeipa DNS to openstack designate >>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>> communicate with freeipa. Is there documentation about how to >>> construct >>> and send RPC messages? >> >> The JSON-RPC and XML-RPC API is still not "officially supported" (read: >> documented), though it's extremely unlikely to change. >> If you need an example, run any ipa command with -vv, this will print >> out the request & response. >> API.txt in the source tree lists all the commands and params. >> This blog post still applies (but be sure to read the update about >> --cacert): >> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >> >> >> > > Web UI communicates with API through JSON-RPC so you can open browser > developer tools (F12) and inspect requests/responses in network tab. Thanks. Would rather use cli, but that's good to know. From abokovoy at redhat.com Wed Feb 26 16:03:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 18:03:36 +0200 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified In-Reply-To: <530E0CC1.5060708@redhat.com> References: <20140225175616.GX16644@redhat.com> <530E0CC1.5060708@redhat.com> Message-ID: <20140226160336.GJ16644@redhat.com> On Wed, 26 Feb 2014, Martin Kosek wrote: >On 02/25/2014 06:56 PM, Alexander Bokovoy wrote: >> Hi, >> >> Simple patch to fix KeyError as --pkey-only causes no attributes to be >> returned and trustdomain_find.post_callback checked them >> unconditionally. >> >> >> https://fedorahosted.org/freeipa/ticket/4196 > >Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.: > > def post_callback(self, ldap, entries, truncated, *args, **options): > if not options.get('pkey_only', False): > trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') > trust_entry = ldap.get_entry(trust_dn) > ... > >It seems to me that your way we still do one unnecessary LDAP search which is >never used. With pkey_only we should not be filling anything in post_callback >at all if it is not affecting the pkey. Right, new patch attached. -- / Alexander Bokovoy -------------- next part -------------- >From d6cc7f93bffcd6fd2be9f34c0aad0bb06b88c8d7 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 26 Feb 2014 17:59:05 +0200 Subject: [PATCH 7/7] trustdomain_find: make sure we skip short entries when --pkey-only is specified With --pkey-only only primary key is returned. It makes no sense to check and replace boolean values then. https://fedorahosted.org/freeipa/ticket/4196 --- ipalib/plugins/trust.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 0b6db27..353c6c7 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1191,6 +1191,8 @@ class trustdomain_find(LDAPSearch): return (filters, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): + if options.get('pkey_only', False): + return trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') trust_entry = ldap.get_entry(trust_dn) for entry in entries: -- 1.8.3.1 From pspacek at redhat.com Wed Feb 26 16:37:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Feb 2014 17:37:18 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530DF821.7040607@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> <530DF2CA.70506@redhat.com> <530DF821.7040607@redhat.com> Message-ID: <530E183E.7000204@redhat.com> On 26.2.2014 15:20, Ludwig Krispenz wrote: >>> I was talking about 'layer of indirection' previously. I'm digging into >>> details and it seems like a good idea to imitate what DNS registrars do >>> - use concept of key sets. It means that keys are not linked to a zone >>> one by one but rather a whole set of keys is linked to a zone. >>> >>> It eases key rotation because you just need to drop a new key to a key >>> set and you don't have to add DNs of all zones to the new key (or the >>> other way around). >>> >>> Another thing is that you could have different key rotation policies for >>> different key sets... we need to think about it carefully. >>> >>> For example (without policies for now): >>> - two DNS zones example.com and example.net contain a pointer to keyset >>> called 'setA' >>> - zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns >>> >>> - key sets are stored under cn=keysets, cn=sec, cn=dns >>> >>> - individual keys are stored under keyid=key1, keysetid=setA, >>> cn=keysets, cn=sec, cn=dns >> >> How will the PKCS#11 module know into which keyset to store a key generated >> by OpenDNSSEC? Are you suggesting having a separate slot/token for each >> keyset? I would like to keep the number of tokens low, because there are >> applications which go slot by slot, token by token when searching for >> objects (e.g. BIND and OpenSSH) and that might generate a lot of unnecessary >> traffic if the number of slots/tokens is high. Okay, then we can store all DNSSEC keys in one slot and use "key sets" only for administrative purposes (i.e. pairing zone <=> keys in BIND) but it will be invisible for PKCS#11 interface. Key set maintenance has to go over side channel for metadata and not over PKCS#11. > The pkcs11 data stored in ldap should represent pkcs11 objects. Other entries > could reference these objects, eg a zone referencing a key. I don't think we > should store references to other entries in an pkcs11 object. if you want this > we probably need another auxiliary objectclass for these pkcs11 entries. > > Regarding objectclasses for the pkcs11 objects, what should be the structural > objectclass and what the naming attribute ? > So far I had defined the publicKey, privateKey, certificate objectclass all as > auxiliary, maybe we should have one structural like pkcs11Object containing > the required attrs like id, label, ... > and a naming attr if it is not one of them This sounds like a good idea. -- Petr^2 Spacek From amisnyov at redhat.com Wed Feb 26 17:24:56 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Wed, 26 Feb 2014 12:24:56 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 6 webui: Too big font in input fields In-Reply-To: <530DED04.6010704@redhat.com> References: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> <530DED04.6010704@redhat.com> Message-ID: <1741784728.2640723.1393435496026.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Vobornik" > To: "Adam Misnyovszki" , freeipa-devel at redhat.com, "Martin Kosek" > Sent: Wednesday, February 26, 2014 2:32:52 PM > Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields > > On 26.2.2014 13:00, Adam Misnyovszki wrote: > > Hi, > > too big font issue in ipa-3-3 and Firefox 27 fixed: > > > > In Firefox 27, default font size has bigger priority than body css, > > text input font size is therefore explicitly set to 1em > > > > https://fedorahosted.org/freeipa/ticket/4180 > > > > Thanks: > > Adam > > > > > > NACK > > The issue is not present only in textboxes but also in comboboxes and > selects. Btw, why the height: 12px? It was because FF overwritten not only the font-size, but also the font-family. Fixed. > > I suggest to use: > > input, select, textarea { > font-size: 1em > } > > this should set the defaults for the whole UI. Done. > > In other topic Dmitri complained about ugliness of trust UI in 3.3 > because of jammed radios and labels. Martin, can we steal this CSS > ticket and fix it with? > > input[type=radio], input[type=checkbox], > .ui-widget input[type=radio], .ui-widget input[type=checkbox]{ > margin-right: 5px; > position: relative; > top: 2px; > } > -- > Petr Vobornik > Done. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0006-2-Too-big-font-in-input-fields.patch Type: text/x-patch Size: 1117 bytes Desc: not available URL: From rmeggins at redhat.com Wed Feb 26 21:15:40 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 14:15:40 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E0E02.8070505@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> Message-ID: <530E597C.2090901@redhat.com> On 02/26/2014 08:53 AM, Petr Viktorin wrote: > On 02/26/2014 04:45 PM, Rich Megginson wrote: >> I'm working on adding support for freeipa DNS to openstack designate >> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >> communicate with freeipa. Is there documentation about how to construct >> and send RPC messages? > > The JSON-RPC and XML-RPC API is still not "officially supported" > (read: documented), though it's extremely unlikely to change. > If you need an example, run any ipa command with -vv, this will print > out the request & response. > API.txt in the source tree lists all the commands and params. > This blog post still applies (but be sure to read the update about > --cacert): > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > Ok. Next question is - how does one do the equivalent of the curl command in python code? From rcritten at redhat.com Wed Feb 26 21:19:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Feb 2014 16:19:03 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E597C.2090901@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> Message-ID: <530E5A47.9000108@redhat.com> Rich Megginson wrote: > On 02/26/2014 08:53 AM, Petr Viktorin wrote: >> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>> I'm working on adding support for freeipa DNS to openstack designate >>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>> communicate with freeipa. Is there documentation about how to construct >>> and send RPC messages? >> >> The JSON-RPC and XML-RPC API is still not "officially supported" >> (read: documented), though it's extremely unlikely to change. >> If you need an example, run any ipa command with -vv, this will print >> out the request & response. >> API.txt in the source tree lists all the commands and params. >> This blog post still applies (but be sure to read the update about >> --cacert): >> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >> >> > > Ok. Next question is - how does one do the equivalent of the curl > command in python code? Here is a pretty stripped-down way to add a user. Other commands are similar, you just may care more about the output: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') except errors.DuplicateEntry: print "user already exists" else: print "User added" From rmeggins at redhat.com Wed Feb 26 21:23:37 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 14:23:37 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E5A47.9000108@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> Message-ID: <530E5B59.7020904@redhat.com> On 02/26/2014 02:19 PM, Rob Crittenden wrote: > Rich Megginson wrote: >> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>> I'm working on adding support for freeipa DNS to openstack designate >>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>> communicate with freeipa. Is there documentation about how to >>>> construct >>>> and send RPC messages? >>> >>> The JSON-RPC and XML-RPC API is still not "officially supported" >>> (read: documented), though it's extremely unlikely to change. >>> If you need an example, run any ipa command with -vv, this will print >>> out the request & response. >>> API.txt in the source tree lists all the commands and params. >>> This blog post still applies (but be sure to read the update about >>> --cacert): >>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>> >>> >>> >> >> Ok. Next question is - how does one do the equivalent of the curl >> command in python code? > > Here is a pretty stripped-down way to add a user. Other commands are > similar, you just may care more about the output: > > from ipalib import api > from ipalib import errors > > api.bootstrap(context='cli') > api.finalize() > api.Backend.xmlclient.connect() > > try: > api.Command['user_add'](u'testuser', > givenname=u'Test', sn=u'User', > loginshell=u'/bin/sh') > except errors.DuplicateEntry: > print "user already exists" > else: > print "User added" > How would one do this from outside of ipa? If ipalib is not available? From rcritten at redhat.com Wed Feb 26 22:22:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Feb 2014 17:22:44 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E5B59.7020904@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> Message-ID: <530E6934.60601@redhat.com> Rich Megginson wrote: > On 02/26/2014 02:19 PM, Rob Crittenden wrote: >> Rich Megginson wrote: >>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>> I'm working on adding support for freeipa DNS to openstack designate >>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>> communicate with freeipa. Is there documentation about how to >>>>> construct >>>>> and send RPC messages? >>>> >>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>> (read: documented), though it's extremely unlikely to change. >>>> If you need an example, run any ipa command with -vv, this will print >>>> out the request & response. >>>> API.txt in the source tree lists all the commands and params. >>>> This blog post still applies (but be sure to read the update about >>>> --cacert): >>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>> >>>> >>>> >>> >>> Ok. Next question is - how does one do the equivalent of the curl >>> command in python code? >> >> Here is a pretty stripped-down way to add a user. Other commands are >> similar, you just may care more about the output: >> >> from ipalib import api >> from ipalib import errors >> >> api.bootstrap(context='cli') >> api.finalize() >> api.Backend.xmlclient.connect() >> >> try: >> api.Command['user_add'](u'testuser', >> givenname=u'Test', sn=u'User', >> loginshell=u'/bin/sh') >> except errors.DuplicateEntry: >> print "user already exists" >> else: >> print "User added" >> > > How would one do this from outside of ipa? If ipalib is not available? You'd need to go to either /ipa/xml or /ipa/json (depending on what protocol you want to use) and issue one request there. This requires Kerberos authentication. The response will include a cookie which you should either ignore or store safely (like in the kernel keyring). Using the cookie will significantly improve performance. If you store the cookie then you can make future requests to /ipa/session/{xml|json} unless a Kerberos error is raised, in which case things start over again. You'll need to include a Referer header in your request, see the -vv output of the ipa command for samples. rob From rmeggins at redhat.com Wed Feb 26 22:28:58 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 15:28:58 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E6934.60601@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> Message-ID: <530E6AAA.6020805@redhat.com> On 02/26/2014 03:22 PM, Rob Crittenden wrote: > Rich Megginson wrote: >> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>> Rich Megginson wrote: >>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>> I'm working on adding support for freeipa DNS to openstack designate >>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>>> communicate with freeipa. Is there documentation about how to >>>>>> construct >>>>>> and send RPC messages? >>>>> >>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>> (read: documented), though it's extremely unlikely to change. >>>>> If you need an example, run any ipa command with -vv, this will print >>>>> out the request & response. >>>>> API.txt in the source tree lists all the commands and params. >>>>> This blog post still applies (but be sure to read the update about >>>>> --cacert): >>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> Ok. Next question is - how does one do the equivalent of the curl >>>> command in python code? >>> >>> Here is a pretty stripped-down way to add a user. Other commands are >>> similar, you just may care more about the output: >>> >>> from ipalib import api >>> from ipalib import errors >>> >>> api.bootstrap(context='cli') >>> api.finalize() >>> api.Backend.xmlclient.connect() >>> >>> try: >>> api.Command['user_add'](u'testuser', >>> givenname=u'Test', sn=u'User', >>> loginshell=u'/bin/sh') >>> except errors.DuplicateEntry: >>> print "user already exists" >>> else: >>> print "User added" >>> >> >> How would one do this from outside of ipa? If ipalib is not available? > > You'd need to go to either /ipa/xml or /ipa/json (depending on what > protocol you want to use) and issue one request there. This requires > Kerberos authentication. The response will include a cookie which you > should either ignore or store safely (like in the kernel keyring). > Using the cookie will significantly improve performance. This is for the ipa dns backend for designate. I'm assuming I will either be using a keytab, or perhaps the new proxy? At any rate, I have to do everything in python - including the kinit with the keytab. I guess I'm really looking for specifics - I've seen recommendations to use the python libraries "requests" and "json". I don't know if requests supports negotiate/kerberos. If not, is there a recommended library to use? As this particular project will be part of openstack, perhaps there is a more "openstack"-y library, or even something built-in to openstack (oslo?). I think amqp support kerberos, so perhaps there is some oslo.messaging thing that will do the http + kerberos stuff. > > If you store the cookie then you can make future requests to > /ipa/session/{xml|json} unless a Kerberos error is raised, in which > case things start over again. > > You'll need to include a Referer header in your request, see the -vv > output of the ipa command for samples. > > rob From simo at redhat.com Wed Feb 26 22:48:47 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Feb 2014 17:48:47 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E6AAA.6020805@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> Message-ID: <1393454927.18299.205.camel@willson.li.ssimo.org> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: > On 02/26/2014 03:22 PM, Rob Crittenden wrote: > > Rich Megginson wrote: > >> On 02/26/2014 02:19 PM, Rob Crittenden wrote: > >>> Rich Megginson wrote: > >>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: > >>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: > >>>>>> I'm working on adding support for freeipa DNS to openstack designate > >>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to > >>>>>> communicate with freeipa. Is there documentation about how to > >>>>>> construct > >>>>>> and send RPC messages? > >>>>> > >>>>> The JSON-RPC and XML-RPC API is still not "officially supported" > >>>>> (read: documented), though it's extremely unlikely to change. > >>>>> If you need an example, run any ipa command with -vv, this will print > >>>>> out the request & response. > >>>>> API.txt in the source tree lists all the commands and params. > >>>>> This blog post still applies (but be sure to read the update about > >>>>> --cacert): > >>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> Ok. Next question is - how does one do the equivalent of the curl > >>>> command in python code? > >>> > >>> Here is a pretty stripped-down way to add a user. Other commands are > >>> similar, you just may care more about the output: > >>> > >>> from ipalib import api > >>> from ipalib import errors > >>> > >>> api.bootstrap(context='cli') > >>> api.finalize() > >>> api.Backend.xmlclient.connect() > >>> > >>> try: > >>> api.Command['user_add'](u'testuser', > >>> givenname=u'Test', sn=u'User', > >>> loginshell=u'/bin/sh') > >>> except errors.DuplicateEntry: > >>> print "user already exists" > >>> else: > >>> print "User added" > >>> > >> > >> How would one do this from outside of ipa? If ipalib is not available? > > > > You'd need to go to either /ipa/xml or /ipa/json (depending on what > > protocol you want to use) and issue one request there. This requires > > Kerberos authentication. The response will include a cookie which you > > should either ignore or store safely (like in the kernel keyring). > > Using the cookie will significantly improve performance. > > This is for the ipa dns backend for designate. I'm assuming I will > either be using a keytab, or perhaps the new proxy? > > At any rate, I have to do everything in python - including the kinit > with the keytab. Lok at rob's damon but you should *not* do a kinit, you should just use gssapi (see python-kerberos) and do a gss_init_sec_context there, if the environment is configured (KRB5_KTNAME set correctly) then gssapi will automatically kinit for you under the hood. > I guess I'm really looking for specifics - I've seen recommendations to > use the python libraries "requests" and "json". I don't know if > requests supports negotiate/kerberos. If not, is there a recommended > library to use? As this particular project will be part of openstack, > perhaps there is a more "openstack"-y library, or even something > built-in to openstack (oslo?). I think amqp support kerberos, so > perhaps there is some oslo.messaging thing that will do the http + > kerberos stuff. Afaik there is nothing that does kerberos in openstack, you'll have to introduce all that stuff. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Feb 26 22:50:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Feb 2014 17:50:28 -0500 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <530DFE5F.5020303@redhat.com> References: <530DCEFA.2090108@redhat.com> <530DFE5F.5020303@redhat.com> Message-ID: <530E6FB4.8020000@redhat.com> On 02/26/2014 09:46 AM, Petr Viktorin wrote: > On 02/26/2014 12:24 PM, Martin Kosek wrote: >> Hello all, >> >> I would like to discuss a proposal that Simo had on FreeIPA devel >> meeting. >> Given permission/ACI refactoring that Petr3 is working on, people may >> have >> issues with access to their LDAP if they played too much with the >> default ACIs >> or if they expect that some information stays accessible in the new >> version. It >> may not stay accessible we are removing the SUFFIX level all allowing >> ACIs and >> creating custom read ACIs. >> >> Bottom line is we need to do our best in making our users aware that >> there are >> big changes in this version they need to be aware of. One way is to >> release a >> new major release with appropriate release notes. >> >> I support that move, I think we have enough big features planned to >> justify new >> major release: >> >> * Permissions/ACIs >> * OTP >> * DNSSEC (hopefully) >> * CA Certificate Management Tool >> * Big Web UI face lift and refactoring >> * ... >> >> If there is no push back against that idea, let's do it. I would then >> rename >> the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. >> > > +1 > > I guess the http://www.freeipa.org/page/V3 tree will also need some > renaming. > I am concerned that it will do more harm than good but do not have valid arguments against. So +1 from me too. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 26 22:58:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Feb 2014 17:58:29 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <1393454927.18299.205.camel@willson.li.ssimo.org> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> Message-ID: <530E7195.1020908@redhat.com> On 02/26/2014 05:48 PM, Simo Sorce wrote: > On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>> Rich Megginson wrote: >>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>> Rich Megginson wrote: >>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>> I'm working on adding support for freeipa DNS to openstack designate >>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>> construct >>>>>>>> and send RPC messages? >>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>> If you need an example, run any ipa command with -vv, this will print >>>>>>> out the request& response. >>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>> This blog post still applies (but be sure to read the update about >>>>>>> --cacert): >>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>> command in python code? >>>>> Here is a pretty stripped-down way to add a user. Other commands are >>>>> similar, you just may care more about the output: >>>>> >>>>> from ipalib import api >>>>> from ipalib import errors >>>>> >>>>> api.bootstrap(context='cli') >>>>> api.finalize() >>>>> api.Backend.xmlclient.connect() >>>>> >>>>> try: >>>>> api.Command['user_add'](u'testuser', >>>>> givenname=u'Test', sn=u'User', >>>>> loginshell=u'/bin/sh') >>>>> except errors.DuplicateEntry: >>>>> print "user already exists" >>>>> else: >>>>> print "User added" >>>>> >>>> How would one do this from outside of ipa? If ipalib is not available? >>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>> protocol you want to use) and issue one request there. This requires >>> Kerberos authentication. The response will include a cookie which you >>> should either ignore or store safely (like in the kernel keyring). >>> Using the cookie will significantly improve performance. >> This is for the ipa dns backend for designate. I'm assuming I will >> either be using a keytab, or perhaps the new proxy? >> >> At any rate, I have to do everything in python - including the kinit >> with the keytab. > Lok at rob's damon but you should *not* do a kinit, you should just use > gssapi (see python-kerberos) and do a gss_init_sec_context there, if the > environment is configured (KRB5_KTNAME set correctly) then gssapi will > automatically kinit for you under the hood. Yes look at Rob's smart proxy and use a similar approach. > >> I guess I'm really looking for specifics - I've seen recommendations to >> use the python libraries "requests" and "json". I don't know if >> requests supports negotiate/kerberos. If not, is there a recommended >> library to use? As this particular project will be part of openstack, >> perhaps there is a more "openstack"-y library, or even something >> built-in to openstack (oslo?). I think amqp support kerberos, so >> perhaps there is some oslo.messaging thing that will do the http + >> kerberos stuff. > Afaik there is nothing that does kerberos in openstack, you'll have to > introduce all that stuff. > > HTH, > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 26 23:05:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Feb 2014 18:05:25 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530DD6AE.507@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <1393009251.23210.47.camel@localhost.localdomain> <530B1922.7060809@redhat.com> <1393252309.21604.3.camel@localhost.localdomain> <530B5BA3.4070403@redhat.com> <1393255303.21604.12.camel@localhost.localdomain> <530D3B64.7090501@redhat.com> <530DD6AE.507@redhat.com> Message-ID: <530E7335.5060802@redhat.com> On 02/26/2014 06:57 AM, Petr Vobornik wrote: > On 26.2.2014 01:55, Dmitri Pal wrote: >> On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: >>> On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: >>>> On 24.2.2014 15:31, Nathaniel McCallum wrote: >>>>> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: >>>>>> On 21.2.2014 20:00, Nathaniel McCallum wrote: >>>>>>> Is it possible to do something more intelligent for the key and >>>>>>> date >>>>>>> fields in the add-token UI? >>>>>>> >>>>>>> Date fields are currently just a text box. Is there any sort of >>>>>>> calendar >>>>>>> we could use here? If not, I'm still unsure of what the format >>>>>>> should be >>>>>>> for this field. >>>>>> It's the format you chose :), try to fill it in CLI, you will >>>>>> have the >>>>>> same proble. From API level it's just string, from LDAP it's >>>>>> generalized >>>>>> time. >>>>> Is there a better option? I'm open to suggestions. >>>> As I mentioned below, it's being implemented. The datetime patches >>>> will >>>> be send separately. The core OTP UI patches should not be blocked by >>>> them. >>>> >>>>>> I've an UI patch prepared where you can write it in ISO format, >>>>>> with a >>>>>> validator attached to it, so user will be noticed about the format, >>>>>> but >>>>>> it's waiting for: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html >>>>>> >>>>>> >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html >>>>>> >>>>>> >>>>>> >>>>>>> The key field should probably have a note indicating that it is >>>>>>> Base32 >>>>>>> encoding. It would also be nice to restrict the input to Base32 >>>>>>> characters. Maybe even automatic case correction... >>>>>> Actually I think it doesn't help much. Show me a person who can >>>>>> write >>>>>> base32 encoded string.... But I agree that a validator with some >>>>>> regex >>>>>> to limit the chars and a note that it should be base32 string is >>>>>> better. >>>>>> The question is what's the purpose of this field from user >>>>>> perspective. >>>>>> Is a human being suppose to fill it or is it meant to be only >>>>>> filled by >>>>>> some provisioning systems? In UI it's just as a backup? >>>>>> >>>>>> If there is a use case where user is suppose to choose the key, it >>>>>> would >>>>>> be better to fill the key and convert it to base32 string on a >>>>>> server. >>>>> I can't think of any case where a user would use the key field. >>>>> >>>>> However, there are at least two important cases where an admin >>>>> would do >>>>> this: >>>>> 1. Hardware tokens >>>>> 2. Transferring OATH (TOTP/HOTP) tokens from another system >>>>> >>>>> Nathaniel >>>>> >>>> What is the input format for these two cases? Is it base32 so admin >>>> can >>>> enter it into UI or is it plain text so he has to use different >>>> tool to >>>> encode it to base32 and then fill into UI? >>> In both of the above cases, I suspect the predominant use will be >>> scripts written to take a token store and import the tokens. This is >>> mostly a non-UI case. >>> >>> RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide >>> use. >>> This is largely because, with fewer characters and no case-sensitivity, >>> Base32 is easier to type. I don't know of any other encodings in wide >>> use. >>> >>> It would be nice to support both of them, but I'm not sure how this is >>> possible. Suggestions are welcome. >> >> I do not think we should allow typing the key (and other attributes) >> manually. >> We should rather ask user to import a token or tokens from the XML file >> that uses RFC6030. >> There are vendors of the hardware tokens that actually using it to >> distribute the tokens. >> >> Here are the examples >> http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files >> >> Please click around the site for more info. >> > > This is one vendor. Do we have information that the other ones (or > just the major ones) use the XML PSKC schema from RFC6030 as well? If > that's the case, we have enough information for implementing > otp-import (design page says that we don't have enough info). > > Back to UI. The UI might be useful if the admin has the values in > different form than XML data, i.e., printed on a paper. Having the UI > doesn't do any harm, right? > > If vendors mostly use base64 keys, adding only base32 support in our > API doesn't make much sense. IMO it actually adds more work because > you have to convert it first. > > Anyway: NACK for the patch because it shows totp/hotp switch in > selfservice without possibility to define other hotp specifics. I'll > remove it so there will be only totp in self-service (just token > name+description). I think we need to take an inspiration in the LinOTP solution UI. See more details here: http://www.linotp.org/doc/2.6/part-management/managingtokens/import.html It loos like Alladin, SafeNet, Fetian have these tokens in XML. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Feb 26 23:18:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Feb 2014 18:18:56 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E7195.1020908@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7195.1020908@redhat.com> Message-ID: <530E7660.90903@redhat.com> Dmitri Pal wrote: > On 02/26/2014 05:48 PM, Simo Sorce wrote: >> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>>> Rich Megginson wrote: >>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>>> Rich Megginson wrote: >>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>>> I'm working on adding support for freeipa DNS to openstack >>>>>>>>> designate >>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>>> construct >>>>>>>>> and send RPC messages? >>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>>> If you need an example, run any ipa command with -vv, this will >>>>>>>> print >>>>>>>> out the request& response. >>>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>>> This blog post still applies (but be sure to read the update about >>>>>>>> --cacert): >>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>>> command in python code? >>>>>> Here is a pretty stripped-down way to add a user. Other commands are >>>>>> similar, you just may care more about the output: >>>>>> >>>>>> from ipalib import api >>>>>> from ipalib import errors >>>>>> >>>>>> api.bootstrap(context='cli') >>>>>> api.finalize() >>>>>> api.Backend.xmlclient.connect() >>>>>> >>>>>> try: >>>>>> api.Command['user_add'](u'testuser', >>>>>> givenname=u'Test', sn=u'User', >>>>>> loginshell=u'/bin/sh') >>>>>> except errors.DuplicateEntry: >>>>>> print "user already exists" >>>>>> else: >>>>>> print "User added" >>>>>> >>>>> How would one do this from outside of ipa? If ipalib is not >>>>> available? >>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>>> protocol you want to use) and issue one request there. This requires >>>> Kerberos authentication. The response will include a cookie which you >>>> should either ignore or store safely (like in the kernel keyring). >>>> Using the cookie will significantly improve performance. >>> This is for the ipa dns backend for designate. I'm assuming I will >>> either be using a keytab, or perhaps the new proxy? >>> >>> At any rate, I have to do everything in python - including the kinit >>> with the keytab. >> Lok at rob's damon but you should *not* do a kinit, you should just use >> gssapi (see python-kerberos) and do a gss_init_sec_context there, if the >> environment is configured (KRB5_KTNAME set correctly) then gssapi will >> automatically kinit for you under the hood. > > Yes look at Rob's smart proxy and use a similar approach. This is a little different since the smart proxy is directly using ipalib. You'll need to use python-kerberos to do the GSSAPI work. Basically you need to get a service ticket for the remote server using your TGT and pass that in the HTTP Authorization header. There was a patch floating around for python-requests to do Kerberos but I'm not sure if it has been accepted upstream, or if it has if it is generally available. That patch may have been converted into a separate project, I found a repo at https://github.com/requests/requests-kerberos. At a glance it looks like this module does all the work for you. To see how we do it, look in ipalib/rpc.py in the KerbTransport class, specifically in get_host_info(). That shows the calls IPA makes to get the information needed for the header, but this is for httplib. rob From rmeggins at redhat.com Wed Feb 26 23:45:38 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Feb 2014 16:45:38 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <1393454927.18299.205.camel@willson.li.ssimo.org> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> Message-ID: <530E7CA2.5080305@redhat.com> On 02/26/2014 03:48 PM, Simo Sorce wrote: > On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>> Rich Megginson wrote: >>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>> Rich Megginson wrote: >>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>> I'm working on adding support for freeipa DNS to openstack designate >>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>> construct >>>>>>>> and send RPC messages? >>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>> If you need an example, run any ipa command with -vv, this will print >>>>>>> out the request & response. >>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>> This blog post still applies (but be sure to read the update about >>>>>>> --cacert): >>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>> command in python code? >>>>> Here is a pretty stripped-down way to add a user. Other commands are >>>>> similar, you just may care more about the output: >>>>> >>>>> from ipalib import api >>>>> from ipalib import errors >>>>> >>>>> api.bootstrap(context='cli') >>>>> api.finalize() >>>>> api.Backend.xmlclient.connect() >>>>> >>>>> try: >>>>> api.Command['user_add'](u'testuser', >>>>> givenname=u'Test', sn=u'User', >>>>> loginshell=u'/bin/sh') >>>>> except errors.DuplicateEntry: >>>>> print "user already exists" >>>>> else: >>>>> print "User added" >>>>> >>>> How would one do this from outside of ipa? If ipalib is not available? >>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>> protocol you want to use) and issue one request there. This requires >>> Kerberos authentication. The response will include a cookie which you >>> should either ignore or store safely (like in the kernel keyring). >>> Using the cookie will significantly improve performance. >> This is for the ipa dns backend for designate. I'm assuming I will >> either be using a keytab, or perhaps the new proxy? >> >> At any rate, I have to do everything in python - including the kinit >> with the keytab. > Lok at rob's damon but you should *not* do a kinit, you should just use > gssapi (see python-kerberos) and do a gss_init_sec_context there, if the > environment is configured (KRB5_KTNAME set correctly) then gssapi will > automatically kinit for you under the hood. > >> I guess I'm really looking for specifics - I've seen recommendations to >> use the python libraries "requests" and "json". I don't know if >> requests supports negotiate/kerberos. If not, is there a recommended >> library to use? As this particular project will be part of openstack, >> perhaps there is a more "openstack"-y library, or even something >> built-in to openstack (oslo?). I think amqp support kerberos, so >> perhaps there is some oslo.messaging thing that will do the http + >> kerberos stuff. > Afaik there is nothing that does kerberos in openstack, you'll have to > introduce all that stuff. Egads - implementing openstack-wide kerberos client libraries in order to add an ipa dns backend to designate. Rob, need any help with your proxy? > > HTH, > Simo. > From mkosek at redhat.com Thu Feb 27 08:38:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 09:38:45 +0100 Subject: [Freeipa-devel] FreeIPA 3.4 -> 4.0 In-Reply-To: <530E6FB4.8020000@redhat.com> References: <530DCEFA.2090108@redhat.com> <530DFE5F.5020303@redhat.com> <530E6FB4.8020000@redhat.com> Message-ID: <530EF995.5070309@redhat.com> On 02/26/2014 11:50 PM, Dmitri Pal wrote: > On 02/26/2014 09:46 AM, Petr Viktorin wrote: >> On 02/26/2014 12:24 PM, Martin Kosek wrote: >>> Hello all, >>> >>> I would like to discuss a proposal that Simo had on FreeIPA devel meeting. >>> Given permission/ACI refactoring that Petr3 is working on, people may have >>> issues with access to their LDAP if they played too much with the default ACIs >>> or if they expect that some information stays accessible in the new version. It >>> may not stay accessible we are removing the SUFFIX level all allowing ACIs and >>> creating custom read ACIs. >>> >>> Bottom line is we need to do our best in making our users aware that there are >>> big changes in this version they need to be aware of. One way is to release a >>> new major release with appropriate release notes. >>> >>> I support that move, I think we have enough big features planned to justify new >>> major release: >>> >>> * Permissions/ACIs >>> * OTP >>> * DNSSEC (hopefully) >>> * CA Certificate Management Tool >>> * Big Web UI face lift and refactoring >>> * ... >>> >>> If there is no push back against that idea, let's do it. I would then rename >>> the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. >>> >> >> +1 >> >> I guess the http://www.freeipa.org/page/V3 tree will also need some renaming. >> > I am concerned that it will do more harm than good but do not have valid > arguments against. > So +1 from me too. I completed all required changes: * Trac milestones changes * Creating new http://www.freeipa.org/page/V4 tree and renaming of the respective designs * Updating any references to 3.4 or 3.5 in the wiki If I missed anything, please ping me. Thanks, Martin From jcholast at redhat.com Thu Feb 27 09:17:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 10:17:18 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530E183E.7000204@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> <530DF2CA.70506@redhat.com> <530DF821.7040607@redhat.com> <530E183E.7000204@redhat.com> Message-ID: <530F029E.90901@redhat.com> On 26.2.2014 17:37, Petr Spacek wrote: > On 26.2.2014 15:20, Ludwig Krispenz wrote: >>>> I was talking about 'layer of indirection' previously. I'm digging into >>>> details and it seems like a good idea to imitate what DNS registrars do >>>> - use concept of key sets. It means that keys are not linked to a zone >>>> one by one but rather a whole set of keys is linked to a zone. >>>> >>>> It eases key rotation because you just need to drop a new key to a key >>>> set and you don't have to add DNs of all zones to the new key (or the >>>> other way around). >>>> >>>> Another thing is that you could have different key rotation policies >>>> for >>>> different key sets... we need to think about it carefully. >>>> >>>> For example (without policies for now): >>>> - two DNS zones example.com and example.net contain a pointer to keyset >>>> called 'setA' >>>> - zone objects: idnsname=example.net,cn=dns and >>>> idnsname=example.com,cn=dns >>>> >>>> - key sets are stored under cn=keysets, cn=sec, cn=dns >>>> >>>> - individual keys are stored under keyid=key1, keysetid=setA, >>>> cn=keysets, cn=sec, cn=dns >>> >>> How will the PKCS#11 module know into which keyset to store a key >>> generated >>> by OpenDNSSEC? Are you suggesting having a separate slot/token for each >>> keyset? I would like to keep the number of tokens low, because there are >>> applications which go slot by slot, token by token when searching for >>> objects (e.g. BIND and OpenSSH) and that might generate a lot of >>> unnecessary >>> traffic if the number of slots/tokens is high. > Okay, then we can store all DNSSEC keys in one slot and use "key sets" > only for administrative purposes (i.e. pairing zone <=> keys in BIND) > but it will be invisible for PKCS#11 interface. > > Key set maintenance has to go over side channel for metadata and not > over PKCS#11. Yep. > >> The pkcs11 data stored in ldap should represent pkcs11 objects. Other >> entries >> could reference these objects, eg a zone referencing a key. I don't >> think we >> should store references to other entries in an pkcs11 object. if you >> want this >> we probably need another auxiliary objectclass for these pkcs11 entries. >> >> Regarding objectclasses for the pkcs11 objects, what should be the >> structural >> objectclass and what the naming attribute ? >> So far I had defined the publicKey, privateKey, certificate >> objectclass all as >> auxiliary, maybe we should have one structural like pkcs11Object >> containing >> the required attrs like id, label, ... >> and a naming attr if it is not one of them > This sounds like a good idea. > +1, although what we refer to as "object" is referred to as "storage object" in the PKCS#11 spec, so we might name the object class ipaPkcs11storageObject. As for the naming attribute, the only PKCS#11 attribute that can't ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId. -- Jan Cholasta From tbabej at redhat.com Thu Feb 27 09:40:52 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 27 Feb 2014 10:40:52 +0100 Subject: [Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API Message-ID: <530F0824.20807@redhat.com> Hi, Remove a reference to the old deprecated LDAP API invoked by the usage of trust_add method. https://fedorahosted.org/freeipa/ticket/4204 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0156-trusts-Remove-usage-of-deprecated-LDAP-API.patch Type: text/x-patch Size: 1484 bytes Desc: not available URL: From pviktori at redhat.com Thu Feb 27 09:54:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Feb 2014 10:54:31 +0100 Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog In-Reply-To: <1583417328.2609623.1393430116585.JavaMail.zimbra@redhat.com> References: <530C9859.7090709@redhat.com> <1583417328.2609623.1393430116585.JavaMail.zimbra@redhat.com> Message-ID: <530F0B57.6090308@redhat.com> On 02/26/2014 04:55 PM, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Petr Vobornik" >> To: "freeipa-devel" >> Sent: Tuesday, February 25, 2014 2:19:21 PM >> Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog >> >> Dialog loses focus when the links are clicked making the dialog >> uncontrollable by keyboard. This patch focuses the link again after >> expanding/collapsing the error list. Thus keeping the focus in a dialog >> >> https://fedorahosted.org/freeipa/ticket/4097 >> -- >> Petr Vobornik > > ACK > > works fine on FF26, 27, GC33 Pushed to master: 61770269d436daa4152c5bb949499497320b2aee -- Petr? From mkosek at redhat.com Thu Feb 27 09:58:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 10:58:33 +0100 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified In-Reply-To: <20140226160336.GJ16644@redhat.com> References: <20140225175616.GX16644@redhat.com> <530E0CC1.5060708@redhat.com> <20140226160336.GJ16644@redhat.com> Message-ID: <530F0C49.4020208@redhat.com> On 02/26/2014 05:03 PM, Alexander Bokovoy wrote: > On Wed, 26 Feb 2014, Martin Kosek wrote: >> On 02/25/2014 06:56 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> Simple patch to fix KeyError as --pkey-only causes no attributes to be >>> returned and trustdomain_find.post_callback checked them >>> unconditionally. >>> >>> >>> https://fedorahosted.org/freeipa/ticket/4196 >> >> Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.: >> >> def post_callback(self, ldap, entries, truncated, *args, **options): >> if not options.get('pkey_only', False): >> trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') >> trust_entry = ldap.get_entry(trust_dn) >> ... >> >> It seems to me that your way we still do one unnecessary LDAP search which is >> never used. With pkey_only we should not be filling anything in post_callback >> at all if it is not affecting the pkey. > Right, new patch attached. > It still crashes: [Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent call last): [Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479] File "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333, in wsgi_execute [Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result = self.Command[name](*args, **options) [Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479] File "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 447, in __call__ [Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479] self.validate_output(ret) [Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479] File "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 947, in validate_output [Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, o.type, type(value), value) [Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError: trustdomain_find.validate_output(): [Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479] output['truncated']: need ; got You need to "return truncated", not just "return". When this is changed, patch works as expected. Martin From abokovoy at redhat.com Thu Feb 27 10:06:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Feb 2014 12:06:54 +0200 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified In-Reply-To: <530F0C49.4020208@redhat.com> References: <20140225175616.GX16644@redhat.com> <530E0CC1.5060708@redhat.com> <20140226160336.GJ16644@redhat.com> <530F0C49.4020208@redhat.com> Message-ID: <20140227100654.GM16644@redhat.com> On Thu, 27 Feb 2014, Martin Kosek wrote: >On 02/26/2014 05:03 PM, Alexander Bokovoy wrote: >> On Wed, 26 Feb 2014, Martin Kosek wrote: >>> On 02/25/2014 06:56 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> Simple patch to fix KeyError as --pkey-only causes no attributes to be >>>> returned and trustdomain_find.post_callback checked them >>>> unconditionally. >>>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/4196 >>> >>> Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.: >>> >>> def post_callback(self, ldap, entries, truncated, *args, **options): >>> if not options.get('pkey_only', False): >>> trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') >>> trust_entry = ldap.get_entry(trust_dn) >>> ... >>> >>> It seems to me that your way we still do one unnecessary LDAP search which is >>> never used. With pkey_only we should not be filling anything in post_callback >>> at all if it is not affecting the pkey. >> Right, new patch attached. >> > >It still crashes: > >[Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent >call last): >[Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479] File >"/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333, >in wsgi_execute >[Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result = >self.Command[name](*args, **options) >[Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479] File >"/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 447, in __call__ >[Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479] self.validate_output(ret) >[Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479] File >"/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 947, in >validate_output >[Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, o.type, >type(value), value) >[Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError: >trustdomain_find.validate_output(): >[Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479] output['truncated']: >need ; got > > >You need to "return truncated", not just "return". When this is changed, patch >works as expected. Yep, thanks! New patch attached. -- / Alexander Bokovoy -------------- next part -------------- >From 78f01ada3f1cce43df7bfcc3647747e600d39c2f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 26 Feb 2014 17:59:05 +0200 Subject: [PATCH 7/7] trustdomain_find: make sure we skip short entries when --pkey-only is specified With --pkey-only only primary key is returned. It makes no sense to check and replace boolean values then. https://fedorahosted.org/freeipa/ticket/4196 --- ipalib/plugins/trust.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 0b6db27..bd71253 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1191,6 +1191,8 @@ class trustdomain_find(LDAPSearch): return (filters, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): + if options.get('pkey_only', False): + return truncated trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') trust_entry = ldap.get_entry(trust_dn) for entry in entries: -- 1.8.3.1 From lkrispen at redhat.com Thu Feb 27 10:28:13 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 11:28:13 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F029E.90901@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> <530DF2CA.70506@redhat.com> <530DF821.7040607@redhat.com> <530E183E.7000204@redhat.com> <530F029E.90901@redhat.com> Message-ID: <530F133D.4020802@redhat.com> On 02/27/2014 10:17 AM, Jan Cholasta wrote: > On 26.2.2014 17:37, Petr Spacek wrote: >> On 26.2.2014 15:20, Ludwig Krispenz wrote: >>>>> I was talking about 'layer of indirection' previously. I'm digging >>>>> into >>>>> details and it seems like a good idea to imitate what DNS >>>>> registrars do >>>>> - use concept of key sets. It means that keys are not linked to a >>>>> zone >>>>> one by one but rather a whole set of keys is linked to a zone. >>>>> >>>>> It eases key rotation because you just need to drop a new key to a >>>>> key >>>>> set and you don't have to add DNs of all zones to the new key (or the >>>>> other way around). >>>>> >>>>> Another thing is that you could have different key rotation policies >>>>> for >>>>> different key sets... we need to think about it carefully. >>>>> >>>>> For example (without policies for now): >>>>> - two DNS zones example.com and example.net contain a pointer to >>>>> keyset >>>>> called 'setA' >>>>> - zone objects: idnsname=example.net,cn=dns and >>>>> idnsname=example.com,cn=dns >>>>> >>>>> - key sets are stored under cn=keysets, cn=sec, cn=dns >>>>> >>>>> - individual keys are stored under keyid=key1, keysetid=setA, >>>>> cn=keysets, cn=sec, cn=dns >>>> >>>> How will the PKCS#11 module know into which keyset to store a key >>>> generated >>>> by OpenDNSSEC? Are you suggesting having a separate slot/token for >>>> each >>>> keyset? I would like to keep the number of tokens low, because >>>> there are >>>> applications which go slot by slot, token by token when searching for >>>> objects (e.g. BIND and OpenSSH) and that might generate a lot of >>>> unnecessary >>>> traffic if the number of slots/tokens is high. >> Okay, then we can store all DNSSEC keys in one slot and use "key sets" >> only for administrative purposes (i.e. pairing zone <=> keys in BIND) >> but it will be invisible for PKCS#11 interface. >> >> Key set maintenance has to go over side channel for metadata and not >> over PKCS#11. > > Yep. > >> >>> The pkcs11 data stored in ldap should represent pkcs11 objects. Other >>> entries >>> could reference these objects, eg a zone referencing a key. I don't >>> think we >>> should store references to other entries in an pkcs11 object. if you >>> want this >>> we probably need another auxiliary objectclass for these pkcs11 >>> entries. >>> >>> Regarding objectclasses for the pkcs11 objects, what should be the >>> structural >>> objectclass and what the naming attribute ? >>> So far I had defined the publicKey, privateKey, certificate >>> objectclass all as >>> auxiliary, maybe we should have one structural like pkcs11Object >>> containing >>> the required attrs like id, label, ... >>> and a naming attr if it is not one of them >> This sounds like a good idea. >> > > +1, although what we refer to as "object" is referred to as "storage > object" in the PKCS#11 spec, so we might name the object class > ipaPkcs11storageObject. > > As for the naming attribute, the only PKCS#11 attribute that can't > ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId. do you mean to use this attributename or to use its values. I'd prefer to make the schema independent of other definitions if possible, so I thought of something like pkcs11objectId, which can have the same syntax as ipaUniqueid and use the same semantics. From jcholast at redhat.com Thu Feb 27 10:35:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 11:35:28 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F133D.4020802@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C6B94.9030201@redhat.com> <1393335978.18299.10.camel@willson.li.ssimo.org> <530CDD2F.5000209@redhat.com> <530CEE75.1070801@redhat.com> <530DF2CA.70506@redhat.com> <530DF821.7040607@redhat.com> <530E183E.7000204@redhat.com> <530F029E.90901@redhat.com> <530F133D.4020802@redhat.com> Message-ID: <530F14F0.7060204@redhat.com> On 27.2.2014 11:28, Ludwig Krispenz wrote: > > On 02/27/2014 10:17 AM, Jan Cholasta wrote: >> On 26.2.2014 17:37, Petr Spacek wrote: >>> On 26.2.2014 15:20, Ludwig Krispenz wrote: >>>>>> I was talking about 'layer of indirection' previously. I'm digging >>>>>> into >>>>>> details and it seems like a good idea to imitate what DNS >>>>>> registrars do >>>>>> - use concept of key sets. It means that keys are not linked to a >>>>>> zone >>>>>> one by one but rather a whole set of keys is linked to a zone. >>>>>> >>>>>> It eases key rotation because you just need to drop a new key to a >>>>>> key >>>>>> set and you don't have to add DNs of all zones to the new key (or the >>>>>> other way around). >>>>>> >>>>>> Another thing is that you could have different key rotation policies >>>>>> for >>>>>> different key sets... we need to think about it carefully. >>>>>> >>>>>> For example (without policies for now): >>>>>> - two DNS zones example.com and example.net contain a pointer to >>>>>> keyset >>>>>> called 'setA' >>>>>> - zone objects: idnsname=example.net,cn=dns and >>>>>> idnsname=example.com,cn=dns >>>>>> >>>>>> - key sets are stored under cn=keysets, cn=sec, cn=dns >>>>>> >>>>>> - individual keys are stored under keyid=key1, keysetid=setA, >>>>>> cn=keysets, cn=sec, cn=dns >>>>> >>>>> How will the PKCS#11 module know into which keyset to store a key >>>>> generated >>>>> by OpenDNSSEC? Are you suggesting having a separate slot/token for >>>>> each >>>>> keyset? I would like to keep the number of tokens low, because >>>>> there are >>>>> applications which go slot by slot, token by token when searching for >>>>> objects (e.g. BIND and OpenSSH) and that might generate a lot of >>>>> unnecessary >>>>> traffic if the number of slots/tokens is high. >>> Okay, then we can store all DNSSEC keys in one slot and use "key sets" >>> only for administrative purposes (i.e. pairing zone <=> keys in BIND) >>> but it will be invisible for PKCS#11 interface. >>> >>> Key set maintenance has to go over side channel for metadata and not >>> over PKCS#11. >> >> Yep. >> >>> >>>> The pkcs11 data stored in ldap should represent pkcs11 objects. Other >>>> entries >>>> could reference these objects, eg a zone referencing a key. I don't >>>> think we >>>> should store references to other entries in an pkcs11 object. if you >>>> want this >>>> we probably need another auxiliary objectclass for these pkcs11 >>>> entries. >>>> >>>> Regarding objectclasses for the pkcs11 objects, what should be the >>>> structural >>>> objectclass and what the naming attribute ? >>>> So far I had defined the publicKey, privateKey, certificate >>>> objectclass all as >>>> auxiliary, maybe we should have one structural like pkcs11Object >>>> containing >>>> the required attrs like id, label, ... >>>> and a naming attr if it is not one of them >>> This sounds like a good idea. >>> >> >> +1, although what we refer to as "object" is referred to as "storage >> object" in the PKCS#11 spec, so we might name the object class >> ipaPkcs11storageObject. >> >> As for the naming attribute, the only PKCS#11 attribute that can't >> ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId. > do you mean to use this attributename or to use its values. I'd prefer > to make the schema independent of other definitions if possible, so I > thought of something like pkcs11objectId, which can have the same syntax > as ipaUniqueid and use the same semantics. > I meant ipaUniqueId the attribute, but I'm fine with anything else (pkcs11UniqueId perhaps? to avoid confusion with pkcs11Id) -- Jan Cholasta From pvoborni at redhat.com Thu Feb 27 11:33:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Feb 2014 12:33:30 +0100 Subject: [Freeipa-devel] [PATCH] 6 webui: Too big font in input fields In-Reply-To: <1741784728.2640723.1393435496026.JavaMail.zimbra@redhat.com> References: <1808843378.2566077.1393416045007.JavaMail.zimbra@redhat.com> <530DED04.6010704@redhat.com> <1741784728.2640723.1393435496026.JavaMail.zimbra@redhat.com> Message-ID: <530F228A.8070300@redhat.com> On 26.2.2014 18:24, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Petr Vobornik" >> To: "Adam Misnyovszki" , freeipa-devel at redhat.com, "Martin Kosek" >> Sent: Wednesday, February 26, 2014 2:32:52 PM >> Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields >> >> On 26.2.2014 13:00, Adam Misnyovszki wrote: >>> Hi, >>> too big font issue in ipa-3-3 and Firefox 27 fixed: >>> >>> In Firefox 27, default font size has bigger priority than body css, >>> text input font size is therefore explicitly set to 1em >>> >>> https://fedorahosted.org/freeipa/ticket/4180 >>> >>> Thanks: >>> Adam >>> >>> >> >> NACK >> >> The issue is not present only in textboxes but also in comboboxes and >> selects. Btw, why the height: 12px? > > It was because FF overwritten not only the font-size, but also the font-family. Fixed. > >> >> I suggest to use: >> >> input, select, textarea { >> font-size: 1em >> } >> >> this should set the defaults for the whole UI. > > Done. > >> >> In other topic Dmitri complained about ugliness of trust UI in 3.3 >> because of jammed radios and labels. Martin, can we steal this CSS >> ticket and fix it with? >> >> input[type=radio], input[type=checkbox], >> .ui-widget input[type=radio], .ui-widget input[type=checkbox]{ >> margin-right: 5px; >> position: relative; >> top: 2px; >> } >> -- >> Petr Vobornik >> > > Done. > > Thanks > Adam > ACK pushed to ipa-3-3: dceaced929e99d732a3a4d6868ee2bff8fbee168 -- Petr Vobornik From mkosek at redhat.com Thu Feb 27 11:33:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 12:33:34 +0100 Subject: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified In-Reply-To: <20140227100654.GM16644@redhat.com> References: <20140225175616.GX16644@redhat.com> <530E0CC1.5060708@redhat.com> <20140226160336.GJ16644@redhat.com> <530F0C49.4020208@redhat.com> <20140227100654.GM16644@redhat.com> Message-ID: <530F228E.5030600@redhat.com> On 02/27/2014 11:06 AM, Alexander Bokovoy wrote: > On Thu, 27 Feb 2014, Martin Kosek wrote: >> On 02/26/2014 05:03 PM, Alexander Bokovoy wrote: >>> On Wed, 26 Feb 2014, Martin Kosek wrote: >>>> On 02/25/2014 06:56 PM, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> Simple patch to fix KeyError as --pkey-only causes no attributes to be >>>>> returned and trustdomain_find.post_callback checked them >>>>> unconditionally. >>>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4196 >>>> >>>> Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.: >>>> >>>> def post_callback(self, ldap, entries, truncated, *args, **options): >>>> if not options.get('pkey_only', False): >>>> trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') >>>> trust_entry = ldap.get_entry(trust_dn) >>>> ... >>>> >>>> It seems to me that your way we still do one unnecessary LDAP search which is >>>> never used. With pkey_only we should not be filling anything in post_callback >>>> at all if it is not affecting the pkey. >>> Right, new patch attached. >>> >> >> It still crashes: >> >> [Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent >> call last): >> [Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479] File >> "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333, >> in wsgi_execute >> [Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result = >> self.Command[name](*args, **options) >> [Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479] File >> "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 447, in __call__ >> [Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479] >> self.validate_output(ret) >> [Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479] File >> "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 947, in >> validate_output >> [Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, o.type, >> type(value), value) >> [Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError: >> trustdomain_find.validate_output(): >> [Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479] output['truncated']: >> need ; got >> >> >> You need to "return truncated", not just "return". When this is changed, patch >> works as expected. > Yep, thanks! > > New patch attached. > ACK. Pushed to master, ipa-3-3. Martin From pviktori at redhat.com Thu Feb 27 11:44:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Feb 2014 12:44:03 +0100 Subject: [Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata Message-ID: <530F2503.7070107@redhat.com> Hello, This patch exposes object metadata needed for permission WebUI. https://fedorahosted.org/freeipa/ticket/4201 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0478-ipalib.plugins-Expose-LDAPObjects-eligibility-for-pe.patch Type: text/x-patch Size: 916 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 27 11:48:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Feb 2014 13:48:42 +0200 Subject: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust Message-ID: <20140227114842.GN16644@redhat.com> Thanks to Martin for noticing we had been fetching information about subdomains only in case there is algorithmic ID mapping in use. Instead, we should always fetch the subdomains but create new ranges only for algorithmic case. https://fedorahosted.org/freeipa/ticket/4205 -- / Alexander Bokovoy -------------- next part -------------- >From f2cca17e5e9fa601934cc2b1bbae984b81195adb Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 27 Feb 2014 13:43:17 +0200 Subject: [PATCH 8/8] trust: make sure we always discover topology of the forest trust Even though we are creating idranges for subdomains only in case there is algorithmic ID mapping in use, we still need to fetch list of subdomains for all other cases. https://fedorahosted.org/freeipa/ticket/4205 --- ipalib/plugins/trust.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index bd71253..ed91dac 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -458,13 +458,15 @@ sides. result['result'] = entry_to_dict(trusts[0][1], **options) + # Fetch topology of the trust forest -- we need always to do it + # for AD trusts, regardless of the type of idranges associated with it + if options.get('trust_type') == u'ad': + domains = fetch_domains_from_trust(self, self.trustinstance, + result['result'], **options) # For AD trusts with algorithmic mapping, we need to add a separate # range for each subdomain. if (options.get('trust_type') == u'ad' and created_range_type != u'ipa-ad-trust-posix'): - - domains = fetch_domains_from_trust(self, self.trustinstance, - result['result'], **options) if domains and len(domains) > 0: for dom in domains: range_name = dom['cn'][0].upper() + '_id_range' -- 1.8.3.1 From pspacek at redhat.com Thu Feb 27 11:50:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Feb 2014 12:50:14 +0100 Subject: [Freeipa-devel] [PATCH 0230] Remove release tag from BIND dependency Message-ID: <530F2676.2000504@redhat.com> Hello, Remove release tag from BIND dependency. This change should allow to build v3 branch on RHEL/CentOS 6. Pushed to v3 branch 2ec56086e811a2247e7a75b5eb5d4784751cb2a5. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0230-Remove-release-tag-from-BIND-depedency.patch Type: text/x-patch Size: 1144 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 27 11:51:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Feb 2014 13:51:18 +0200 Subject: [Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API In-Reply-To: <530F0824.20807@redhat.com> References: <530F0824.20807@redhat.com> Message-ID: <20140227115118.GO16644@redhat.com> On Thu, 27 Feb 2014, Tomas Babej wrote: >Hi, > >Remove a reference to the old deprecated LDAP API invoked by >the usage of trust_add method. > >https://fedorahosted.org/freeipa/ticket/4204 > >-- >Tomas Babej >Associate Software Engeneer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > > >>From ee59e86f5ee91da97de0484fdcc9b40590844f76 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 27 Feb 2014 10:33:50 +0100 >Subject: [PATCH] trusts: Remove usage of deprecated LDAP API > >Remove a reference to the old deprecated LDAP API invoked by >the usage of trust_add method. > >https://fedorahosted.org/freeipa/ticket/4204 >--- > ipaserver/dcerpc.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py >index 5cc168be4717bf40d5ae31532828488e3a3a819e..c3ae00ef3d089d3617809b4cc81153e0704890b7 100644 >--- a/ipaserver/dcerpc.py >+++ b/ipaserver/dcerpc.py >@@ -1102,9 +1102,9 @@ class TrustDomainJoins(object): > > realm_domains = self.api.Command.realmdomains_show()['result'] > # Use realmdomains' modification timestamp to judge records last update time >- (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) >+ entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) > # Convert the timestamp to Windows 64-bit timestamp format >- trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) >+ trust_timestamp = long(time.mktime(time.strptime(entry['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) > > for dom in realm_domains['associateddomain']: > ftinfo = dict() ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Feb 27 11:52:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Feb 2014 13:52:19 +0200 Subject: [Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata In-Reply-To: <530F2503.7070107@redhat.com> References: <530F2503.7070107@redhat.com> Message-ID: <20140227115219.GP16644@redhat.com> On Thu, 27 Feb 2014, Petr Viktorin wrote: >Hello, >This patch exposes object metadata needed for permission WebUI. > >https://fedorahosted.org/freeipa/ticket/4201 > >-- >Petr? >From cbebd3328715db4ddd4afe9bdbd6c6edf0bf7148 Mon Sep 17 00:00:00 2001 >From: Petr Viktorin >Date: Wed, 26 Feb 2014 16:39:49 +0100 >Subject: [PATCH] ipalib.plugins: Expose LDAPObjects' eligibility for > permission --type in JSON metadata > >https://fedorahosted.org/freeipa/ticket/4201 >--- > ipalib/plugins/baseldap.py | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >index c2aad784df2b2bcd03f4ec0462e74cd6abce594c..c4951eb56c044cfa08b617d546d9b9332adc4cc9 100644 >--- a/ipalib/plugins/baseldap.py >+++ b/ipalib/plugins/baseldap.py >@@ -631,6 +631,8 @@ def __json__(self): > json_dict['aciattrs'] = attrlist > attrlist.sort() > json_dict['methods'] = [m for m in self.methods] >+ json_dict['can_have_permissions'] = bool( >+ self.permission_filter_objectclasses) > return json_dict ACK. -- / Alexander Bokovoy From pviktori at redhat.com Thu Feb 27 11:55:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Feb 2014 12:55:13 +0100 Subject: [Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API In-Reply-To: <20140227115118.GO16644@redhat.com> References: <530F0824.20807@redhat.com> <20140227115118.GO16644@redhat.com> Message-ID: <530F27A1.7040705@redhat.com> On 02/27/2014 12:51 PM, Alexander Bokovoy wrote: > On Thu, 27 Feb 2014, Tomas Babej wrote: >> Hi, >> >> Remove a reference to the old deprecated LDAP API invoked by >> the usage of trust_add method. >> >> https://fedorahosted.org/freeipa/ticket/4204 >> >> -- >> Tomas Babej >> Associate Software Engeneer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> > >>> From ee59e86f5ee91da97de0484fdcc9b40590844f76 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Thu, 27 Feb 2014 10:33:50 +0100 >> Subject: [PATCH] trusts: Remove usage of deprecated LDAP API >> >> Remove a reference to the old deprecated LDAP API invoked by >> the usage of trust_add method. >> >> https://fedorahosted.org/freeipa/ticket/4204 >> --- >> ipaserver/dcerpc.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py >> index >> 5cc168be4717bf40d5ae31532828488e3a3a819e..c3ae00ef3d089d3617809b4cc81153e0704890b7 >> 100644 >> --- a/ipaserver/dcerpc.py >> +++ b/ipaserver/dcerpc.py >> @@ -1102,9 +1102,9 @@ class TrustDomainJoins(object): >> >> realm_domains = self.api.Command.realmdomains_show()['result'] >> # Use realmdomains' modification timestamp to judge records >> last update time >> - (dn, entry_attrs) = >> self.api.Backend.ldap2.get_entry(realm_domains['dn'], >> ['modifyTimestamp']) >> + entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'], >> ['modifyTimestamp']) >> # Convert the timestamp to Windows 64-bit timestamp format >> - trust_timestamp = >> long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], >> "%Y%m%d%H%M%S"))*1e7+116444736000000000) >> + trust_timestamp = >> long(time.mktime(time.strptime(entry['modifytimestamp'][0][:14], >> "%Y%m%d%H%M%S"))*1e7+116444736000000000) >> >> for dom in realm_domains['associateddomain']: >> ftinfo = dict() > ACK. > > Pushed to master: 96f87e548af5107e33f33cdb3af9fd542d0aa413 -- Petr? From pviktori at redhat.com Thu Feb 27 11:55:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Feb 2014 12:55:26 +0100 Subject: [Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata In-Reply-To: <20140227115219.GP16644@redhat.com> References: <530F2503.7070107@redhat.com> <20140227115219.GP16644@redhat.com> Message-ID: <530F27AE.5000103@redhat.com> On 02/27/2014 12:52 PM, Alexander Bokovoy wrote: > On Thu, 27 Feb 2014, Petr Viktorin wrote: >> Hello, >> This patch exposes object metadata needed for permission WebUI. >> >> https://fedorahosted.org/freeipa/ticket/4201 >> >> -- >> Petr? > >> From cbebd3328715db4ddd4afe9bdbd6c6edf0bf7148 Mon Sep 17 00:00:00 2001 >> From: Petr Viktorin >> Date: Wed, 26 Feb 2014 16:39:49 +0100 >> Subject: [PATCH] ipalib.plugins: Expose LDAPObjects' eligibility for >> permission --type in JSON metadata >> >> https://fedorahosted.org/freeipa/ticket/4201 >> --- >> ipalib/plugins/baseldap.py | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >> index >> c2aad784df2b2bcd03f4ec0462e74cd6abce594c..c4951eb56c044cfa08b617d546d9b9332adc4cc9 >> 100644 >> --- a/ipalib/plugins/baseldap.py >> +++ b/ipalib/plugins/baseldap.py >> @@ -631,6 +631,8 @@ def __json__(self): >> json_dict['aciattrs'] = attrlist >> attrlist.sort() >> json_dict['methods'] = [m for m in self.methods] >> + json_dict['can_have_permissions'] = bool( >> + self.permission_filter_objectclasses) >> return json_dict > ACK. > > Pushed to master: 4fda432050e9b12ec9d48c2c80b9fd69faa54480 -- Petr? From mkosek at redhat.com Thu Feb 27 12:33:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 13:33:06 +0100 Subject: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust In-Reply-To: <20140227114842.GN16644@redhat.com> References: <20140227114842.GN16644@redhat.com> Message-ID: <530F3082.8020208@redhat.com> On 02/27/2014 12:48 PM, Alexander Bokovoy wrote: > Thanks to Martin for noticing we had been fetching information about > subdomains only in case there is algorithmic ID mapping in use. Instead, > we should always fetch the subdomains but create new ranges only for > algorithmic case. > > https://fedorahosted.org/freeipa/ticket/4205 > This works fine for the trustdomain part. However, we still create too many ID ranges: # ipa idrange-find ---------------- 3 ranges matched ---------------- Range name: CHILD.TBAD.EXAMPLE.COM_id_range First Posix ID of the range: 161000000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075 Range type: Active Directory domain range Range name: IDM.LAB.BOS.REDHAT.COM_id_range First Posix ID of the range: 1258600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range Range name: TBAD.EXAMPLE.COM_id_range First Posix ID of the range: 10000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 3 ---------------------------- CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX trust. Martin From pvoborni at redhat.com Thu Feb 27 12:35:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Feb 2014 13:35:18 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <53076180.7020103@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> Message-ID: <530F3106.7090505@redhat.com> On 21.2.2014 15:24, Petr Vobornik wrote: > On 10.2.2014 14:12, Petr Vobornik wrote: >> On 13.1.2014 17:09, Petr Vobornik wrote: >>> Hi, >>> >>> these patches implements the OTP Web UI. >>> >>> Last 5 patches is the OTP UI. >>> >>> First 6 patches is a little refactoring/bug fixes needed for them. >>> General password dialog is introduced to avoid another implementation. >>> >>> Self-service UI is implemented to be very simple. Atm user can choose >>> only token name. Admin interface allows to enter all values. >>> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>> Nathaniel for review of the last font package. It will speed things up. >>> >>> Know bugs: >>> - there is clash in id's of checkboxes preventing editation of >>> subsequently displayed ones with the same name. Will be fixed in >>> separate patch. >>> - bugs caused by bugs in API (adding/removal of own tokens in >>> self-service, inability to enter key on token creation - >>> https://fedorahosted.org/freeipa/ticket/4099) >>> - datetime format (widget+validator) will be implemented in separate >>> patch >>> - no support of not reviewed CLI patches (HOTP..) >>> >>> Cgit: >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>> >>> https://fedorahosted.org/freeipa/ticket/3369 >>> >> >> patch 540-1 has been updated >> - QR code is centered >> - QR code correction level was lowered from H to M >> >> All other current patches from sub-threads are attached as well (it was >> getting hard to keep track of them). >> > > Attaching new version of patch 537: 537-4 > > It: > * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter > field in details facet > * removes 'default' radio button in adder dialog in ipatokenotpalgorithm > and ipatokenotpdigits field > > > Btw I've encountered an issue on Web UI login when: > - user is created > - token is created for him > - admin resets user's password and changes auth type to 'otp' > - user tries to login with psw+otp > > The initial login-password call is successful but subsequent change > password fails - it uses the old psw+otp. > > I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 > which is almost implemented. > > > I also plan to hide fields without any value in otp token details page > in self-service mode. This will be done after #3903 because some > prerequisites for #3903 add useful code for that task. > New version of 537 attached: 537-5 It removes token type switch from selfservice page. Therefore default token type (totp) will be always created. Originated from: http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-5-UI-for-OTP-tokens.patch Type: text/x-patch Size: 15982 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 27 12:43:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Feb 2014 14:43:12 +0200 Subject: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust In-Reply-To: <530F3082.8020208@redhat.com> References: <20140227114842.GN16644@redhat.com> <530F3082.8020208@redhat.com> Message-ID: <20140227124312.GQ16644@redhat.com> On Thu, 27 Feb 2014, Martin Kosek wrote: >On 02/27/2014 12:48 PM, Alexander Bokovoy wrote: >> Thanks to Martin for noticing we had been fetching information about >> subdomains only in case there is algorithmic ID mapping in use. Instead, >> we should always fetch the subdomains but create new ranges only for >> algorithmic case. >> >> https://fedorahosted.org/freeipa/ticket/4205 >> > >This works fine for the trustdomain part. However, we still create too many ID >ranges: > > ># ipa idrange-find >---------------- >3 ranges matched >---------------- > Range name: CHILD.TBAD.EXAMPLE.COM_id_range > First Posix ID of the range: 161000000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075 > Range type: Active Directory domain range > > Range name: IDM.LAB.BOS.REDHAT.COM_id_range > First Posix ID of the range: 1258600000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range > > Range name: TBAD.EXAMPLE.COM_id_range > First Posix ID of the range: 10000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 > Range type: Active Directory trust range with POSIX attributes >---------------------------- >Number of entries returned 3 >---------------------------- > >CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX trust. Yes. We tracked this down to a wrong code in fetch_domains_from_trust() where instead of a final value we took a list that contained the value and compared it for inequality with a unicode value. Of course, the comparison always evaluated to true (list is not a unicode object). New patch is attached. It removes duplicated code from the trust-add as the same action (adding idranges for subdomains) is done in fetch_domains_from_trust(). -- / Alexander Bokovoy -------------- next part -------------- >From 538812b7efa90556a6ccbc72fabeddeaca51c27d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 27 Feb 2014 13:43:17 +0200 Subject: [PATCH 8/8] trust: make sure we always discover topology of the forest trust Even though we are creating idranges for subdomains only in case there is algorithmic ID mapping in use, we still need to fetch list of subdomains for all other cases. https://fedorahosted.org/freeipa/ticket/4205 --- ipalib/plugins/trust.py | 37 ++++++------------------------------- 1 file changed, 6 insertions(+), 31 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index bd71253..f2b00a6 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -458,38 +458,13 @@ sides. result['result'] = entry_to_dict(trusts[0][1], **options) - # For AD trusts with algorithmic mapping, we need to add a separate - # range for each subdomain. - if (options.get('trust_type') == u'ad' and - created_range_type != u'ipa-ad-trust-posix'): - + # Fetch topology of the trust forest -- we need always to do it + # for AD trusts, regardless of the type of idranges associated with it + # Note that fetch_domains_from_trust will add needed ranges for + # the algorithmic ID mapping case. + if options.get('trust_type') == u'ad': domains = fetch_domains_from_trust(self, self.trustinstance, result['result'], **options) - if domains and len(domains) > 0: - for dom in domains: - range_name = dom['cn'][0].upper() + '_id_range' - dom_sid = dom['ipanttrusteddomainsid'][0] - - # Enforce the same range type as the range for the root - # level domain. - - # This will skip the detection of the POSIX attributes if - # they are not available, since it has been already - # detected when creating the range for the root level domain - passed_options = options - passed_options.update(range_type=created_range_type) - - # Do not pass the base id to the subdomains since it would - # clash with the root level domain - if 'base_id' in passed_options: - del passed_options['base_id'] - - # Try to add the range for each subdomain - try: - add_range(self, range_name, dom_sid, *keys, - **passed_options) - except errors.DuplicateEntry: - pass # Format the output into human-readable values result['result']['trusttype'] = [trust_type_string( @@ -1270,7 +1245,7 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): # trust range must exist by the time fetch_domains_from_trust is called range_name = trust_name.upper() + '_id_range' old_range = api.Command.idrange_show(range_name, raw=True)['result'] - idrange_type = old_range['iparangetype'] + idrange_type = old_range['iparangetype'][0] for dom in domains: dom['trust_type'] = u'ad' -- 1.8.3.1 From jcholast at redhat.com Thu Feb 27 13:14:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 14:14:54 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <53038820.8060309@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> Message-ID: <530F3A4E.8070400@redhat.com> On 18.2.2014 17:19, Martin Kosek wrote: > On 02/18/2014 04:38 PM, Jan Cholasta wrote: >> On 18.2.2014 16:35, Petr Spacek wrote: >>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>> >>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>> That's what I sometimes get the impression what is wanted. SoftHsm has >>>>>>> one component Softdatabase with an API, which more or less passes sets >>>>>>> of attributes (attributes defined by PKCS#11) and then stores it as >>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>> data. >>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>> pkcs >>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>> attribute for each possible attribute type ? >>>>>> >>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be the most >>>>>> straightforward way of doing this, but I think we can do some >>>>>> optimization for our needs. For example, like you said above, we can >>>>>> use >>>>>> a single attribute containing PKCS#8 encoded private key rather than >>>>>> using one attribute per private key component. >>>>>> >>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>> necessary to represent private key, public key and certificate objects. >>>>>> >>>>>> So, I would say it should be something between high-level and >>>>>> low-level. >>>>> >>>>> There won't be a separate public key, it's represented by the >>>>> certificate. >>>> >>>> I'm not sure if this is the case for DNSSEC. >>> >>> Honzo, >>> >>> we really need the design page with some goal statement, high-level >>> overview etc. There is still some confusion, probably from fact that we >>> want to use the same module for cert distribution and at the same time >>> for DNSSEC key storage. >>> >> >> It's on my TODO list, I'll try to get it out ASAP. >> > > +1, please do. We clearly need some design to start with. > > Martin > I already posted the link in other thread, but here it is anyway: . Some more comments on the schema: I think I may have been too quick to dismiss RFC 4523. There is CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token user", "authority" and "other entity". We could map entries with object class pkiUser to certificate object with CKA_CERTIFICATE_CATEGORY "token user" and entries with object class pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". There are no object classes in RFC 4523 for "unspecified" and "other entity", but we will not be storing any certificates using PKCS#11 anyway, so I think it's OK. Also the above got me thinking, is there any "standard" LDAP schema for private keys? If so, can we use it? I'm going to store NSS trust objects along with CA certificates, so I'm going to need an object class for that. You can find the details on CKO_NSS_TRUST at . If we store multiple related PKCS#11 objects in a single LDAP entry, there is going to be some redundancy. For example, public key value can be extracted from private key value, so we don't need to store both of the values. This can be bypassed by having separate object classes for data and for metadata. For a key pair entry, the object classes would be e.g. privateKey, pkcs11privateKey and pkcs11publicKey, where privateKey is an object class with private key data (without any PKCS#11 bits), pkcs11privateKey is an object class with PKCS#11 private key metadata and pkcs11publicKey is an object class with PKCS#11 public key metadata. In the PKCS#11 module, this entry would be visible as two separate objects (private key object and public key object). Regarding PKCS#11 metadata attributes (i.e. excluding certificate, private key and public key value attributes), I think they all should be single-valued. Comments on specific attributes: * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP attributes for these, for the sake of completeness * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in LDAP are always persistent, so there is no need for pkcs11token * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for pkcs11certificateType * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object classes (see above), we don't need an LDAP attribute for it * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from certificate value, no need for LDAP attributes * CKA_URL - do we want to support certificates with URL instead of value? -- Jan Cholasta From mkosek at redhat.com Thu Feb 27 13:13:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 14:13:17 +0100 Subject: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust In-Reply-To: <20140227124312.GQ16644@redhat.com> References: <20140227114842.GN16644@redhat.com> <530F3082.8020208@redhat.com> <20140227124312.GQ16644@redhat.com> Message-ID: <530F39ED.3040803@redhat.com> On 02/27/2014 01:43 PM, Alexander Bokovoy wrote: > On Thu, 27 Feb 2014, Martin Kosek wrote: >> On 02/27/2014 12:48 PM, Alexander Bokovoy wrote: >>> Thanks to Martin for noticing we had been fetching information about >>> subdomains only in case there is algorithmic ID mapping in use. Instead, >>> we should always fetch the subdomains but create new ranges only for >>> algorithmic case. >>> >>> https://fedorahosted.org/freeipa/ticket/4205 >>> >> >> This works fine for the trustdomain part. However, we still create too many ID >> ranges: >> >> >> # ipa idrange-find >> ---------------- >> 3 ranges matched >> ---------------- >> Range name: CHILD.TBAD.EXAMPLE.COM_id_range >> First Posix ID of the range: 161000000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075 >> Range type: Active Directory domain range >> >> Range name: IDM.LAB.BOS.REDHAT.COM_id_range >> First Posix ID of the range: 1258600000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 1000 >> First RID of the secondary RID range: 100000000 >> Range type: local domain range >> >> Range name: TBAD.EXAMPLE.COM_id_range >> First Posix ID of the range: 10000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 >> Range type: Active Directory trust range with POSIX attributes >> ---------------------------- >> Number of entries returned 3 >> ---------------------------- >> >> CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX trust. > > Yes. We tracked this down to a wrong code in fetch_domains_from_trust() > where instead of a final value we took a list that contained the value > and compared it for inequality with a unicode value. Of course, the > comparison always evaluated to true (list is not a unicode object). > > New patch is attached. It removes duplicated code from the trust-add as > the same action (adding idranges for subdomains) is done in > fetch_domains_from_trust(). Good we have it now just on one place. Worked fine for me, thanks. ACK. Pushed to master, ipa-3-3. Martin From rcritten at redhat.com Thu Feb 27 13:19:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Feb 2014 08:19:24 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530E7CA2.5080305@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7CA2.5080305@redhat.com> Message-ID: <530F3B5C.3080308@redhat.com> Rich Megginson wrote: > On 02/26/2014 03:48 PM, Simo Sorce wrote: >> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>>> Rich Megginson wrote: >>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>>> Rich Megginson wrote: >>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>>> I'm working on adding support for freeipa DNS to openstack >>>>>>>>> designate >>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to >>>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>>> construct >>>>>>>>> and send RPC messages? >>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>>> If you need an example, run any ipa command with -vv, this will >>>>>>>> print >>>>>>>> out the request & response. >>>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>>> This blog post still applies (but be sure to read the update about >>>>>>>> --cacert): >>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>>> command in python code? >>>>>> Here is a pretty stripped-down way to add a user. Other commands are >>>>>> similar, you just may care more about the output: >>>>>> >>>>>> from ipalib import api >>>>>> from ipalib import errors >>>>>> >>>>>> api.bootstrap(context='cli') >>>>>> api.finalize() >>>>>> api.Backend.xmlclient.connect() >>>>>> >>>>>> try: >>>>>> api.Command['user_add'](u'testuser', >>>>>> givenname=u'Test', sn=u'User', >>>>>> loginshell=u'/bin/sh') >>>>>> except errors.DuplicateEntry: >>>>>> print "user already exists" >>>>>> else: >>>>>> print "User added" >>>>>> >>>>> How would one do this from outside of ipa? If ipalib is not >>>>> available? >>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>>> protocol you want to use) and issue one request there. This requires >>>> Kerberos authentication. The response will include a cookie which you >>>> should either ignore or store safely (like in the kernel keyring). >>>> Using the cookie will significantly improve performance. >>> This is for the ipa dns backend for designate. I'm assuming I will >>> either be using a keytab, or perhaps the new proxy? >>> >>> At any rate, I have to do everything in python - including the kinit >>> with the keytab. >> Lok at rob's damon but you should *not* do a kinit, you should just use >> gssapi (see python-kerberos) and do a gss_init_sec_context there, if the >> environment is configured (KRB5_KTNAME set correctly) then gssapi will >> automatically kinit for you under the hood. >> >>> I guess I'm really looking for specifics - I've seen recommendations to >>> use the python libraries "requests" and "json". I don't know if >>> requests supports negotiate/kerberos. If not, is there a recommended >>> library to use? As this particular project will be part of openstack, >>> perhaps there is a more "openstack"-y library, or even something >>> built-in to openstack (oslo?). I think amqp support kerberos, so >>> perhaps there is some oslo.messaging thing that will do the http + >>> kerberos stuff. >> Afaik there is nothing that does kerberos in openstack, you'll have to >> introduce all that stuff. > > Egads - implementing openstack-wide kerberos client libraries in order > to add an ipa dns backend to designate. > > Rob, need any help with your proxy? Well, something occurred to me this morning. You need SSL on top of this too, which means you need the IPA CA. The easiest way to get that is to enroll the designate server as an IPA client. This pulls in the freeipa-python package which gives you ipalib, so no reinventing the wheel required. rob From mkosek at redhat.com Thu Feb 27 13:34:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Feb 2014 14:34:48 +0100 Subject: [Freeipa-devel] [PATCH] 0143: catch access denial when removing old trust object when using non-privileged AD user to create trust In-Reply-To: <20140226155408.GI16644@redhat.com> References: <20140226155408.GI16644@redhat.com> Message-ID: <530F3EF8.5030902@redhat.com> On 02/26/2014 04:54 PM, Alexander Bokovoy wrote: > Hi, > > this patch fixes a case when non-privileged AD user account is used to > re-establish trust. We need to catch one specific exception in deleting > the old trust and bail out earlier with proper error message. > > https://fedorahosted.org/freeipa/ticket/4202 Works fine, ACK. Pushed to: master: 3a7ba6013ffe43176bcff2c716b33552853847ff ipa-3-3: 42108d1c0dc552e5dbc249507bfe59a1ef1d4c8e Martin From lslebodn at redhat.com Thu Feb 27 14:19:38 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 27 Feb 2014 15:19:38 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files Message-ID: <20140227141937.GA32698@mail.corp.redhat.com> ehlo, I did some reviews of bind-dyndb-ldap last week and it was little bit annoying to export special CFLAGS for bind9 header files. It can be automatically detected in configure script using utility isc-config. Attached patch should improve this and CFLAGS needn't be exported. LS -------------- next part -------------- >From 118301596dadc2ef66437e7c6661c5fb84459611 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 25 Feb 2014 10:46:50 +0100 Subject: [PATCH] AUTOCONF: Improve detection of bind9 header files bind9 header files are stored in non-default path (/usr/include/bind9) There is an utility (isc-config) which can provides cflags. --- configure.ac | 30 +++++++++++++++++++++++++++++- contrib/bind-dyndb-ldap.spec | 1 - src/Makefile.am | 3 ++- 3 files changed, 31 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 91739c03d9d6de2a9c07129ff0d71b024953293b..5b860f62208fae01cd3ee4cb9b585bf89416e5cf 100644 --- a/configure.ac +++ b/configure.ac @@ -62,7 +62,35 @@ int main(void) { [AC_MSG_ERROR([Cross compiling is not supported.])] ) -# Older autoconf (2.59, for example) doesn't define docdir +AC_SUBST(BIND9_CFLAGS) +AC_SUBST(BIND9_LIBS) + +AC_PATH_PROG(ISC_CONFIG, [isc-config.sh]) +AC_MSG_CHECKING([for working isc-config]) +if test -x "$ISC_CONFIG"; then + AC_MSG_RESULT([yes]); + + dnl do not override enviroment variables BIND9_CFLAGS BIND9_LIBS + if test -z "$BIND9_CFLAGS"; then + BIND9_CFLAGS=`$ISC_CONFIG --cflags dns` + fi + dnl We do not need all libraries suggested by isc-config.sh + dnl {-lcrypto, -lcap} are useless + dnl BIND9_LIBS=`$ISC_CONFIG --libs dns` +else + AC_MSG_RESULT([no]) + AC_MSG_WARN([ +Could not detect script isc-config.sh. Compilation may fail. +Defining variables BIND9_CFLAGS BIND9_LIBS will fix this problem. +]) +fi + +AC_ARG_VAR([BIND9_CFLAGS], + [C compiler flags for bind9, overriding isc-config.sh]) +AC_ARG_VAR([BIND9_LIBS], + [linker flags for bind9, overriding isc-config.sh]) + +dnl Older autoconf (2.59, for example) doesn't define docdir [[ ! -n "$docdir" ]] && docdir='${datadir}/doc/${PACKAGE_TARNAME}' AC_SUBST([docdir]) diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec index b345b1b5cb6cad99cf2f1c4df7d9f1e2b144548d..12b8004e218a06606a242255ac87b8f2736225ac 100644 --- a/contrib/bind-dyndb-ldap.spec +++ b/contrib/bind-dyndb-ldap.spec @@ -27,7 +27,6 @@ off of your LDAP server. %setup -q -n %{name}-%{VERSION} %build -export CFLAGS="`isc-config.sh --cflags dns` $RPM_OPT_FLAGS" %configure make %{?_smp_mflags} diff --git a/src/Makefile.am b/src/Makefile.am index 6856957f48dbe32750009ab8a32487add05d5c1c..4adf28a2dcdc09223d86c367fad492f7d64a2b13 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -43,6 +43,7 @@ ldap_la_SOURCES = \ zone_manager.c \ zone_register.c -ldap_la_CFLAGS = -Wall -Wextra @WERROR@ -std=gnu99 -O2 +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 +ldap_la_LIBADD = $(BIND9_LIBS) ldap_la_LDFLAGS = -module -avoid-version -Wl,-z,relro,-z,now,-z,noexecstack -- 1.8.5.3 From lkrispen at redhat.com Thu Feb 27 14:23:15 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 15:23:15 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F3A4E.8070400@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> Message-ID: <530F4A53.80309@redhat.com> On 02/27/2014 02:14 PM, Jan Cholasta wrote: > On 18.2.2014 17:19, Martin Kosek wrote: >> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>> On 18.2.2014 16:35, Petr Spacek wrote: >>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>> >>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>> SoftHsm has >>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>> passes sets >>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>> it as >>>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>>> data. >>>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>>> pkcs >>>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>>> attribute for each possible attribute type ? >>>>>>> >>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>> the most >>>>>>> straightforward way of doing this, but I think we can do some >>>>>>> optimization for our needs. For example, like you said above, we >>>>>>> can >>>>>>> use >>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>> than >>>>>>> using one attribute per private key component. >>>>>>> >>>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>>> necessary to represent private key, public key and certificate >>>>>>> objects. >>>>>>> >>>>>>> So, I would say it should be something between high-level and >>>>>>> low-level. >>>>>> >>>>>> There won't be a separate public key, it's represented by the >>>>>> certificate. >>>>> >>>>> I'm not sure if this is the case for DNSSEC. >>>> >>>> Honzo, >>>> >>>> we really need the design page with some goal statement, high-level >>>> overview etc. There is still some confusion, probably from fact >>>> that we >>>> want to use the same module for cert distribution and at the same time >>>> for DNSSEC key storage. >>>> >>> >>> It's on my TODO list, I'll try to get it out ASAP. >>> >> >> +1, please do. We clearly need some design to start with. >> >> Martin >> > > I already posted the link in other thread, but here it is anyway: > . > > Some more comments on the schema: > > I think I may have been too quick to dismiss RFC 4523. There is > CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token > user", "authority" and "other entity". We could map entries with > object class pkiUser to certificate object with > CKA_CERTIFICATE_CATEGORY "token user" and entries with object class > pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". > There are no object classes in RFC 4523 for "unspecified" and "other > entity", but we will not be storing any certificates using PKCS#11 > anyway, so I think it's OK. not sure I understand what exactly you want here. If we don't store certificates using the pkcs#11 schema we don't need to define them, but on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. Do you mean to have a pkcs11 cerificate object with CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes userCertificate and cACertificate to store them ? > > Also the above got me thinking, is there any "standard" LDAP schema > for private keys? If so, can we use it? I didn't find any, the only keys in ldap I found is a definition for sshPublicKey for openssh. > > I'm going to store NSS trust objects along with CA certificates, so > I'm going to need an object class for that. You can find the details > on CKO_NSS_TRUST at > . > > If we store multiple related PKCS#11 objects in a single LDAP entry, > there is going to be some redundancy. For example, public key value > can be extracted from private key value, so we don't need to store > both of the values. This can be bypassed by having separate object > classes for data and for metadata. For a key pair entry, the object > classes would be e.g. privateKey, pkcs11privateKey and > pkcs11publicKey, where privateKey is an object class with private key > data (without any PKCS#11 bits), pkcs11privateKey is an object class > with PKCS#11 private key metadata and pkcs11publicKey is an object > class with PKCS#11 public key metadata. In the PKCS#11 module, this > entry would be visible as two separate objects (private key object and > public key object). I have not yet rewritten the objectcalss definition after the latest discussion, but I think if we have one structural objectclass pkcs11storageObject with only a uniqueid and auxiliary objectclasses for publickey,privatekey, certificate where the attributes (maybe withexception of label, id) are optional there will be no redundancy, store only what is needed. you could use these aux objectclass also in other entries instead of using pkcs11storageObject. > > Regarding PKCS#11 metadata attributes (i.e. excluding certificate, > private key and public key value attributes), I think they all should > be single-valued. Comments on specific attributes: > > * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, > CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, > CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, > CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, > CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP > attributes for these, for the sake of completeness in progress > > * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in > LDAP are always persistent, so there is no need for pkcs11token ok > > * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for > pkcs11certificateType ok > > * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object > classes (see above), we don't need an LDAP attribute for it see above, where do you want to define the mapping. Do we then need cert attrs at all ? > > * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, > CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from > certificate value, no need for LDAP attributes ok > > * CKA_URL - do we want to support certificates with URL instead of > value? don't know, there are just some other attrs required when a URL is used From simo at redhat.com Thu Feb 27 14:38:50 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Feb 2014 09:38:50 -0500 Subject: [Freeipa-devel] Thank you for FreeOTP! In-Reply-To: <20140225173324.GA18282@tesla.redhat.com> References: <20140225173324.GA18282@tesla.redhat.com> Message-ID: <1393511930.18299.216.camel@willson.li.ssimo.org> On Tue, 2014-02-25 at 23:03 +0530, Kashyap Chamarthy wrote: > Heya, > > Just wanted to say thank you for FreeOTP, Nathaniel and co. > > And, of course, more thankful to all the Identity open source/free > software from this awesome team! > > A happy user. > Thanks Kashyap, really appreciated. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Feb 27 14:56:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 15:56:01 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F4A53.80309@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> Message-ID: <530F5201.10303@redhat.com> On 27.2.2014 15:23, Ludwig Krispenz wrote: > > On 02/27/2014 02:14 PM, Jan Cholasta wrote: >> On 18.2.2014 17:19, Martin Kosek wrote: >>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>> >>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>> SoftHsm has >>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>> passes sets >>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>> it as >>>>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>>>> data. >>>>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>>>> pkcs >>>>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>>>> attribute for each possible attribute type ? >>>>>>>> >>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>> the most >>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>> can >>>>>>>> use >>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>> than >>>>>>>> using one attribute per private key component. >>>>>>>> >>>>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>>>> necessary to represent private key, public key and certificate >>>>>>>> objects. >>>>>>>> >>>>>>>> So, I would say it should be something between high-level and >>>>>>>> low-level. >>>>>>> >>>>>>> There won't be a separate public key, it's represented by the >>>>>>> certificate. >>>>>> >>>>>> I'm not sure if this is the case for DNSSEC. >>>>> >>>>> Honzo, >>>>> >>>>> we really need the design page with some goal statement, high-level >>>>> overview etc. There is still some confusion, probably from fact >>>>> that we >>>>> want to use the same module for cert distribution and at the same time >>>>> for DNSSEC key storage. >>>>> >>>> >>>> It's on my TODO list, I'll try to get it out ASAP. >>>> >>> >>> +1, please do. We clearly need some design to start with. >>> >>> Martin >>> >> >> I already posted the link in other thread, but here it is anyway: >> . >> >> Some more comments on the schema: >> >> I think I may have been too quick to dismiss RFC 4523. There is >> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >> user", "authority" and "other entity". We could map entries with >> object class pkiUser to certificate object with >> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >> There are no object classes in RFC 4523 for "unspecified" and "other >> entity", but we will not be storing any certificates using PKCS#11 >> anyway, so I think it's OK. > not sure I understand what exactly you want here. If we don't store > certificates using the pkcs#11 schema we don't need to define them, but > on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. > Do you mean to have a pkcs11 cerificate object with > CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes > userCertificate and cACertificate to store them ? Hopefully an example will better illustrate what I mean. We could map PKCS#11 objects like this: CKA_CLASS: CKO_CERTIFICATE CKA_CERTIFICATE_TYPE: CKC_X_509 CKA_CERTIFICATE_CATEGORY: 1 CKA_VALUE: to LDAP entries like this: dn: pkcs11uniqueId=, objectClass: pkcs11storageObject objectClass: pkiUser pkcs11uniqueId: userCertificate;binary: and PKCS#11 object like this: CKA_CLASS: CKO_CERTIFICATE CKA_CERTIFICATE_TYPE: CKC_X_509 CKA_CERTIFICATE_CATEGORY: 2 CKA_VALUE: to LDAP entries like this: dn: pkcs11uniqueId=, objectClass: pkcs11storageObject objectClass: pkiCA pkcs11uniqueId: caCertificate;binary: In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >> >> Also the above got me thinking, is there any "standard" LDAP schema >> for private keys? If so, can we use it? > I didn't find any, the only keys in ldap I found is a definition for > sshPublicKey for openssh. And even this schema is for public keys only :-) OK, nevermind then. >> >> I'm going to store NSS trust objects along with CA certificates, so >> I'm going to need an object class for that. You can find the details >> on CKO_NSS_TRUST at >> . >> >> >> If we store multiple related PKCS#11 objects in a single LDAP entry, >> there is going to be some redundancy. For example, public key value >> can be extracted from private key value, so we don't need to store >> both of the values. This can be bypassed by having separate object >> classes for data and for metadata. For a key pair entry, the object >> classes would be e.g. privateKey, pkcs11privateKey and >> pkcs11publicKey, where privateKey is an object class with private key >> data (without any PKCS#11 bits), pkcs11privateKey is an object class >> with PKCS#11 private key metadata and pkcs11publicKey is an object >> class with PKCS#11 public key metadata. In the PKCS#11 module, this >> entry would be visible as two separate objects (private key object and >> public key object). > I have not yet rewritten the objectcalss definition after the latest > discussion, but I think if we have one structural objectclass > pkcs11storageObject with only a uniqueid and auxiliary objectclasses for > publickey,privatekey, certificate where the attributes (maybe > withexception of label, id) are optional there will be no redundancy, > store only what is needed. > you could use these aux objectclass also in other entries instead of > using pkcs11storageObject. OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I think they should be optional in LDAP as well. >> >> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >> private key and public key value attributes), I think they all should >> be single-valued. Comments on specific attributes: >> >> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >> attributes for these, for the sake of completeness > in progress >> >> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >> LDAP are always persistent, so there is no need for pkcs11token > ok >> >> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >> pkcs11certificateType > ok >> >> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >> classes (see above), we don't need an LDAP attribute for it > see above, where do you want to define the mapping. Do we then need > cert attrs at all ? If we use userCertificate and cACertificate, we don't need pkcs11certificateValue, if that's what you are asking. >> >> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >> certificate value, no need for LDAP attributes > ok >> >> * CKA_URL - do we want to support certificates with URL instead of >> value? > don't know, there are just some other attrs required when a URL is used If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not required AFAIK, it's just that URL-only certificates do not make much sense without them. -- Jan Cholasta From npmccallum at redhat.com Thu Feb 27 15:38:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 27 Feb 2014 10:38:18 -0500 Subject: [Freeipa-devel] Thank you for FreeOTP! In-Reply-To: <20140225173324.GA18282@tesla.redhat.com> References: <20140225173324.GA18282@tesla.redhat.com> Message-ID: <1393515498.3562.0.camel@localhost.localdomain> On Tue, 2014-02-25 at 23:03 +0530, Kashyap Chamarthy wrote: > Heya, > > Just wanted to say thank you for FreeOTP, Nathaniel and co. > > And, of course, more thankful to all the Identity open source/free > software from this awesome team! > > A happy user. Kashyap, Glad you like it! Thanks for the feedback. Nathaniel From rmeggins at redhat.com Thu Feb 27 15:41:55 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Feb 2014 08:41:55 -0700 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530F3B5C.3080308@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7CA2.5080305@redhat.com> <530F3B5C.3080308@redhat.com> Message-ID: <530F5CC3.6020805@redhat.com> On 02/27/2014 06:19 AM, Rob Crittenden wrote: > Rich Megginson wrote: >> On 02/26/2014 03:48 PM, Simo Sorce wrote: >>> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >>>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>>>> Rich Megginson wrote: >>>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>>>> Rich Megginson wrote: >>>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>>>> I'm working on adding support for freeipa DNS to openstack >>>>>>>>>> designate >>>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? >>>>>>>>>> REST?) to >>>>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>>>> construct >>>>>>>>>> and send RPC messages? >>>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>>>> If you need an example, run any ipa command with -vv, this will >>>>>>>>> print >>>>>>>>> out the request & response. >>>>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>>>> This blog post still applies (but be sure to read the update >>>>>>>>> about >>>>>>>>> --cacert): >>>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>>>> command in python code? >>>>>>> Here is a pretty stripped-down way to add a user. Other commands >>>>>>> are >>>>>>> similar, you just may care more about the output: >>>>>>> >>>>>>> from ipalib import api >>>>>>> from ipalib import errors >>>>>>> >>>>>>> api.bootstrap(context='cli') >>>>>>> api.finalize() >>>>>>> api.Backend.xmlclient.connect() >>>>>>> >>>>>>> try: >>>>>>> api.Command['user_add'](u'testuser', >>>>>>> givenname=u'Test', sn=u'User', >>>>>>> loginshell=u'/bin/sh') >>>>>>> except errors.DuplicateEntry: >>>>>>> print "user already exists" >>>>>>> else: >>>>>>> print "User added" >>>>>>> >>>>>> How would one do this from outside of ipa? If ipalib is not >>>>>> available? >>>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>>>> protocol you want to use) and issue one request there. This requires >>>>> Kerberos authentication. The response will include a cookie which you >>>>> should either ignore or store safely (like in the kernel keyring). >>>>> Using the cookie will significantly improve performance. >>>> This is for the ipa dns backend for designate. I'm assuming I will >>>> either be using a keytab, or perhaps the new proxy? >>>> >>>> At any rate, I have to do everything in python - including the kinit >>>> with the keytab. >>> Lok at rob's damon but you should *not* do a kinit, you should just use >>> gssapi (see python-kerberos) and do a gss_init_sec_context there, if >>> the >>> environment is configured (KRB5_KTNAME set correctly) then gssapi will >>> automatically kinit for you under the hood. >>> >>>> I guess I'm really looking for specifics - I've seen >>>> recommendations to >>>> use the python libraries "requests" and "json". I don't know if >>>> requests supports negotiate/kerberos. If not, is there a recommended >>>> library to use? As this particular project will be part of openstack, >>>> perhaps there is a more "openstack"-y library, or even something >>>> built-in to openstack (oslo?). I think amqp support kerberos, so >>>> perhaps there is some oslo.messaging thing that will do the http + >>>> kerberos stuff. >>> Afaik there is nothing that does kerberos in openstack, you'll have to >>> introduce all that stuff. >> >> Egads - implementing openstack-wide kerberos client libraries in order >> to add an ipa dns backend to designate. >> >> Rob, need any help with your proxy? > > Well, something occurred to me this morning. You need SSL on top of > this too, which means you need the IPA CA. The easiest way to get that > is to enroll the designate server as an IPA client. This pulls in the > freeipa-python package which gives you ipalib, so no reinventing the > wheel required. I'm trying to use python-kerberos to do auth with a keytab (KRB5_KTNAME), without first doing a kinit from the command line. It is not working. Does anyone know how I can do client side kerberos auth with a keytab in python without first doing a kinit? > > rob From tbordaz at redhat.com Thu Feb 27 15:46:12 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 27 Feb 2014 16:46:12 +0100 Subject: [Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553) Message-ID: <530F5DC4.9050909@redhat.com> Hello, Thanks to all your feedbacks, they helped me a lot and raised a severe limitation in the original design. I updated the design following the aci syntax proposed during the discussion. On the implementation side, it is a bit more complex but less than I expected. I have not yet investigated the impact of ger operations. I think a big work will be the test side as the ACI syntax provides many options. http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation Note: I kept for the moment the original design in 'alternative no1'. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Feb 27 15:51:37 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 27 Feb 2014 10:51:37 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530F3106.7090505@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> Message-ID: <1393516297.3562.8.camel@localhost.localdomain> On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote: > On 21.2.2014 15:24, Petr Vobornik wrote: > > On 10.2.2014 14:12, Petr Vobornik wrote: > >> On 13.1.2014 17:09, Petr Vobornik wrote: > >>> Hi, > >>> > >>> these patches implements the OTP Web UI. > >>> > >>> Last 5 patches is the OTP UI. > >>> > >>> First 6 patches is a little refactoring/bug fixes needed for them. > >>> General password dialog is introduced to avoid another implementation. > >>> > >>> Self-service UI is implemented to be very simple. Atm user can choose > >>> only token name. Admin interface allows to enter all values. > >>> > >>> It's based on the RCUE work -> we need to push RCUE first. Thanks > >>> Nathaniel for review of the last font package. It will speed things up. > >>> > >>> Know bugs: > >>> - there is clash in id's of checkboxes preventing editation of > >>> subsequently displayed ones with the same name. Will be fixed in > >>> separate patch. > >>> - bugs caused by bugs in API (adding/removal of own tokens in > >>> self-service, inability to enter key on token creation - > >>> https://fedorahosted.org/freeipa/ticket/4099) > >>> - datetime format (widget+validator) will be implemented in separate > >>> patch > >>> - no support of not reviewed CLI patches (HOTP..) > >>> > >>> Cgit: > >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >>> > >>> https://fedorahosted.org/freeipa/ticket/3369 > >>> > >> > >> patch 540-1 has been updated > >> - QR code is centered > >> - QR code correction level was lowered from H to M > >> > >> All other current patches from sub-threads are attached as well (it was > >> getting hard to keep track of them). > >> > > > > Attaching new version of patch 537: 537-4 > > > > It: > > * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter > > field in details facet > > * removes 'default' radio button in adder dialog in ipatokenotpalgorithm > > and ipatokenotpdigits field > > > > > > Btw I've encountered an issue on Web UI login when: > > - user is created > > - token is created for him > > - admin resets user's password and changes auth type to 'otp' > > - user tries to login with psw+otp > > > > The initial login-password call is successful but subsequent change > > password fails - it uses the old psw+otp. > > > > I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 > > which is almost implemented. > > > > > > I also plan to hide fields without any value in otp token details page > > in self-service mode. This will be done after #3903 because some > > prerequisites for #3903 add useful code for that task. > > > > New version of 537 attached: 537-5 > > It removes token type switch from selfservice page. Therefore default > token type (totp) will be always created. > > Originated from: > http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html I'm not sure I understand the rationale for this (after having read the other email thread). But I agree we should discuss which options should be available on the self-service page. Just to recap the situation: 1. Only token name / description are provided in the self-service UI 2. All options are provided on the CLI I think the main question is: who should get to choose the primary token type in FreeIPA? There are three possibilities: 1. FreeIPA developers 2. Admins 3. Users The case for #1 is that we can't guarantee timely replication of the counter attribute. On this basis, we choose TOTP as default because of structural limitations. This is currently the default. I don't see much use for #3. But I can see an argument for #2. Personally, I lean toward #1. Thoughts? Nathaniel From lkrispen at redhat.com Thu Feb 27 16:24:22 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 17:24:22 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F5201.10303@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> Message-ID: <530F66B6.6000301@redhat.com> On 02/27/2014 03:56 PM, Jan Cholasta wrote: > On 27.2.2014 15:23, Ludwig Krispenz wrote: >> >> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>> On 18.2.2014 17:19, Martin Kosek wrote: >>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>> >>>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>> SoftHsm has >>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>> passes sets >>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>> it as >>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>> blob of >>>>>>>>>> data. >>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>> fingrained the >>>>>>>>>> pkcs >>>>>>>>>> objects/attribute types would have to be mapped to ldap: one >>>>>>>>>> ldap >>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>> >>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>> the most >>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>>> can >>>>>>>>> use >>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>> than >>>>>>>>> using one attribute per private key component. >>>>>>>>> >>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>> PKCS#11 >>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>> attributes >>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>> objects. >>>>>>>>> >>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>> low-level. >>>>>>>> >>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>> certificate. >>>>>>> >>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>> >>>>>> Honzo, >>>>>> >>>>>> we really need the design page with some goal statement, high-level >>>>>> overview etc. There is still some confusion, probably from fact >>>>>> that we >>>>>> want to use the same module for cert distribution and at the same >>>>>> time >>>>>> for DNSSEC key storage. >>>>>> >>>>> >>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>> >>>> >>>> +1, please do. We clearly need some design to start with. >>>> >>>> Martin >>>> >>> >>> I already posted the link in other thread, but here it is anyway: >>> . >>> >>> Some more comments on the schema: >>> >>> I think I may have been too quick to dismiss RFC 4523. There is >>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>> user", "authority" and "other entity". We could map entries with >>> object class pkiUser to certificate object with >>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >>> There are no object classes in RFC 4523 for "unspecified" and "other >>> entity", but we will not be storing any certificates using PKCS#11 >>> anyway, so I think it's OK. >> not sure I understand what exactly you want here. If we don't store >> certificates using the pkcs#11 schema we don't need to define them, but >> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. >> Do you mean to have a pkcs11 cerificate object with >> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >> userCertificate and cACertificate to store them ? > > Hopefully an example will better illustrate what I mean. We could map > PKCS#11 objects like this: > > CKA_CLASS: CKO_CERTIFICATE > CKA_CERTIFICATE_TYPE: CKC_X_509 > CKA_CERTIFICATE_CATEGORY: 1 > CKA_VALUE: > > > to LDAP entries like this: > > dn: pkcs11uniqueId=, > objectClass: pkcs11storageObject > objectClass: pkiUser > pkcs11uniqueId: > userCertificate;binary: > > > and PKCS#11 object like this: > > CKA_CLASS: CKO_CERTIFICATE > CKA_CERTIFICATE_TYPE: CKC_X_509 > CKA_CERTIFICATE_CATEGORY: 2 > CKA_VALUE: > > > to LDAP entries like this: > > dn: pkcs11uniqueId=, > objectClass: pkcs11storageObject > objectClass: pkiCA > pkcs11uniqueId: > caCertificate;binary: > > > In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from > objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" > and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". so you want to directly use the pkiUser|CA objectclass, that would be ok > >>> >>> Also the above got me thinking, is there any "standard" LDAP schema >>> for private keys? If so, can we use it? >> I didn't find any, the only keys in ldap I found is a definition for >> sshPublicKey for openssh. > > And even this schema is for public keys only :-) OK, nevermind then. > >>> >>> I'm going to store NSS trust objects along with CA certificates, so >>> I'm going to need an object class for that. You can find the details >>> on CKO_NSS_TRUST at >>> . >>> so this is a nss extension to pkcs11, not in the standard ? If we add trust objects, should the naming reflect this like pkcs11nss or pkcs11ext ? >>> >>> >>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>> there is going to be some redundancy. For example, public key value >>> can be extracted from private key value, so we don't need to store >>> both of the values. This can be bypassed by having separate object >>> classes for data and for metadata. For a key pair entry, the object >>> classes would be e.g. privateKey, pkcs11privateKey and >>> pkcs11publicKey, where privateKey is an object class with private key >>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>> entry would be visible as two separate objects (private key object and >>> public key object). >> I have not yet rewritten the objectcalss definition after the latest >> discussion, but I think if we have one structural objectclass >> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for >> publickey,privatekey, certificate where the attributes (maybe >> withexception of label, id) are optional there will be no redundancy, >> store only what is needed. >> you could use these aux objectclass also in other entries instead of >> using pkcs11storageObject. > > OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so > I think they should be optional in LDAP as well. > >>> >>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>> private key and public key value attributes), I think they all should >>> be single-valued. Comments on specific attributes: >>> >>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>> attributes for these, for the sake of completeness >> in progress >>> >>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>> LDAP are always persistent, so there is no need for pkcs11token >> ok >>> >>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>> pkcs11certificateType >> ok >>> >>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>> classes (see above), we don't need an LDAP attribute for it >> see above, where do you want to define the mapping. Do we then need >> cert attrs at all ? > > If we use userCertificate and cACertificate, we don't need > pkcs11certificateValue, if that's what you are asking. I was asking if we need the pkcs11certificate objectclass and the certificate metadata since you were using the pkiUser and pkiCA objectclasses to store the cert, but you probably want the startdate, enddate and other attrs at least available > >>> >>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>> certificate value, no need for LDAP attributes >> ok >>> >>> * CKA_URL - do we want to support certificates with URL instead of >>> value? >> don't know, there are just some other attrs required when a URL is used > > If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not > required AFAIK, it's just that URL-only certificates do not make much > sense without them. > yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty if CKA_URL is empty. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Feb 27 16:29:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Feb 2014 17:29:56 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1393516297.3562.8.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> Message-ID: <530F6804.3090507@redhat.com> On 27.2.2014 16:51, Nathaniel McCallum wrote: > On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote: >> On 21.2.2014 15:24, Petr Vobornik wrote: >>> On 10.2.2014 14:12, Petr Vobornik wrote: >>>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>>> Hi, >>>>> >>>>> these patches implements the OTP Web UI. >>>>> >>>>> Last 5 patches is the OTP UI. >>>>> >>>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>>> General password dialog is introduced to avoid another implementation. >>>>> >>>>> Self-service UI is implemented to be very simple. Atm user can choose >>>>> only token name. Admin interface allows to enter all values. >>>>> >>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>>> Nathaniel for review of the last font package. It will speed things up. >>>>> >>>>> Know bugs: >>>>> - there is clash in id's of checkboxes preventing editation of >>>>> subsequently displayed ones with the same name. Will be fixed in >>>>> separate patch. >>>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>>> self-service, inability to enter key on token creation - >>>>> https://fedorahosted.org/freeipa/ticket/4099) >>>>> - datetime format (widget+validator) will be implemented in separate >>>>> patch >>>>> - no support of not reviewed CLI patches (HOTP..) >>>>> >>>>> Cgit: >>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3369 >>>>> >>>> >>>> patch 540-1 has been updated >>>> - QR code is centered >>>> - QR code correction level was lowered from H to M >>>> >>>> All other current patches from sub-threads are attached as well (it was >>>> getting hard to keep track of them). >>>> >>> >>> Attaching new version of patch 537: 537-4 >>> >>> It: >>> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter >>> field in details facet >>> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm >>> and ipatokenotpdigits field >>> >>> >>> Btw I've encountered an issue on Web UI login when: >>> - user is created >>> - token is created for him >>> - admin resets user's password and changes auth type to 'otp' >>> - user tries to login with psw+otp >>> >>> The initial login-password call is successful but subsequent change >>> password fails - it uses the old psw+otp. >>> >>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 >>> which is almost implemented. >>> >>> >>> I also plan to hide fields without any value in otp token details page >>> in self-service mode. This will be done after #3903 because some >>> prerequisites for #3903 add useful code for that task. >>> >> >> New version of 537 attached: 537-5 >> >> It removes token type switch from selfservice page. Therefore default >> token type (totp) will be always created. >> >> Originated from: >> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html > > I'm not sure I understand the rationale for this (after having read the > other email thread). But I agree we should discuss which options should > be available on the self-service page. > > Just to recap the situation: > 1. Only token name / description are provided in the self-service UI > 2. All options are provided on the CLI > > I think the main question is: who should get to choose the primary token > type in FreeIPA? There are three possibilities: > 1. FreeIPA developers > 2. Admins > 3. Users > > The case for #1 is that we can't guarantee timely replication of the > counter attribute. On this basis, we choose TOTP as default because of > structural limitations. This is currently the default. > > I don't see much use for #3. But I can see an argument for #2. > > Personally, I lean toward #1. Thoughts? > > Nathaniel > Sorry, there is no real reason to not have HOTP there, and therefore 537-5 is wrong and 537-4 is OK. Rationale of the mistake: * self-service page has to be simple so it doesn't allow to add hw tokens * My thoughts were fixed to the idea that HOTP has to be hw token - maybe the H confused me. -- Petr Vobornik From rcritten at redhat.com Thu Feb 27 16:32:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Feb 2014 11:32:34 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530F5CC3.6020805@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7CA2.5080305@redhat.com> <530F3B5C.3080308@redhat.com> <530F5CC3.6020805@redhat.com> Message-ID: <530F68A2.4090101@redhat.com> Rich Megginson wrote: > On 02/27/2014 06:19 AM, Rob Crittenden wrote: >> Rich Megginson wrote: >>> On 02/26/2014 03:48 PM, Simo Sorce wrote: >>>> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: >>>>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: >>>>>> Rich Megginson wrote: >>>>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: >>>>>>>> Rich Megginson wrote: >>>>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: >>>>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: >>>>>>>>>>> I'm working on adding support for freeipa DNS to openstack >>>>>>>>>>> designate >>>>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? >>>>>>>>>>> REST?) to >>>>>>>>>>> communicate with freeipa. Is there documentation about how to >>>>>>>>>>> construct >>>>>>>>>>> and send RPC messages? >>>>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" >>>>>>>>>> (read: documented), though it's extremely unlikely to change. >>>>>>>>>> If you need an example, run any ipa command with -vv, this will >>>>>>>>>> print >>>>>>>>>> out the request & response. >>>>>>>>>> API.txt in the source tree lists all the commands and params. >>>>>>>>>> This blog post still applies (but be sure to read the update >>>>>>>>>> about >>>>>>>>>> --cacert): >>>>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Ok. Next question is - how does one do the equivalent of the curl >>>>>>>>> command in python code? >>>>>>>> Here is a pretty stripped-down way to add a user. Other commands >>>>>>>> are >>>>>>>> similar, you just may care more about the output: >>>>>>>> >>>>>>>> from ipalib import api >>>>>>>> from ipalib import errors >>>>>>>> >>>>>>>> api.bootstrap(context='cli') >>>>>>>> api.finalize() >>>>>>>> api.Backend.xmlclient.connect() >>>>>>>> >>>>>>>> try: >>>>>>>> api.Command['user_add'](u'testuser', >>>>>>>> givenname=u'Test', sn=u'User', >>>>>>>> loginshell=u'/bin/sh') >>>>>>>> except errors.DuplicateEntry: >>>>>>>> print "user already exists" >>>>>>>> else: >>>>>>>> print "User added" >>>>>>>> >>>>>>> How would one do this from outside of ipa? If ipalib is not >>>>>>> available? >>>>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what >>>>>> protocol you want to use) and issue one request there. This requires >>>>>> Kerberos authentication. The response will include a cookie which you >>>>>> should either ignore or store safely (like in the kernel keyring). >>>>>> Using the cookie will significantly improve performance. >>>>> This is for the ipa dns backend for designate. I'm assuming I will >>>>> either be using a keytab, or perhaps the new proxy? >>>>> >>>>> At any rate, I have to do everything in python - including the kinit >>>>> with the keytab. >>>> Lok at rob's damon but you should *not* do a kinit, you should just use >>>> gssapi (see python-kerberos) and do a gss_init_sec_context there, if >>>> the >>>> environment is configured (KRB5_KTNAME set correctly) then gssapi will >>>> automatically kinit for you under the hood. >>>> >>>>> I guess I'm really looking for specifics - I've seen >>>>> recommendations to >>>>> use the python libraries "requests" and "json". I don't know if >>>>> requests supports negotiate/kerberos. If not, is there a recommended >>>>> library to use? As this particular project will be part of openstack, >>>>> perhaps there is a more "openstack"-y library, or even something >>>>> built-in to openstack (oslo?). I think amqp support kerberos, so >>>>> perhaps there is some oslo.messaging thing that will do the http + >>>>> kerberos stuff. >>>> Afaik there is nothing that does kerberos in openstack, you'll have to >>>> introduce all that stuff. >>> >>> Egads - implementing openstack-wide kerberos client libraries in order >>> to add an ipa dns backend to designate. >>> >>> Rob, need any help with your proxy? >> >> Well, something occurred to me this morning. You need SSL on top of >> this too, which means you need the IPA CA. The easiest way to get that >> is to enroll the designate server as an IPA client. This pulls in the >> freeipa-python package which gives you ipalib, so no reinventing the >> wheel required. > > I'm trying to use python-kerberos to do auth with a keytab > (KRB5_KTNAME), without first doing a kinit from the command line. It is > not working. > > Does anyone know how I can do client side kerberos auth with a keytab in > python without first doing a kinit? gssproxy. You need at least 0.3.1. Add something like this to the _top_ of /etc/gssproxy/gssproxy.conf: [service/myservice] mechs = krb5 cred_store = client_keytab:/etc/my.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U cred_usage = initiate euid = xx (where xx is the uid of your process) I found running gssproxy directly in debug mode another window to be a handy debugging tool while I got my head wrapped around things. rob From simo at redhat.com Thu Feb 27 16:35:12 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Feb 2014 11:35:12 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530F68A2.4090101@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7CA2.5080305@redhat.com> <530F3B5C.3080308@redhat.com> <530F5CC3.6020805@redhat.com> <530F68A2.4090101@redhat.com> Message-ID: <1393518912.18299.218.camel@willson.li.ssimo.org> On Thu, 2014-02-27 at 11:32 -0500, Rob Crittenden wrote: > Rich Megginson wrote: > > On 02/27/2014 06:19 AM, Rob Crittenden wrote: > >> Rich Megginson wrote: > >>> On 02/26/2014 03:48 PM, Simo Sorce wrote: > >>>> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: > >>>>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: > >>>>>> Rich Megginson wrote: > >>>>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: > >>>>>>>> Rich Megginson wrote: > >>>>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: > >>>>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: > >>>>>>>>>>> I'm working on adding support for freeipa DNS to openstack > >>>>>>>>>>> designate > >>>>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? > >>>>>>>>>>> REST?) to > >>>>>>>>>>> communicate with freeipa. Is there documentation about how to > >>>>>>>>>>> construct > >>>>>>>>>>> and send RPC messages? > >>>>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" > >>>>>>>>>> (read: documented), though it's extremely unlikely to change. > >>>>>>>>>> If you need an example, run any ipa command with -vv, this will > >>>>>>>>>> print > >>>>>>>>>> out the request & response. > >>>>>>>>>> API.txt in the source tree lists all the commands and params. > >>>>>>>>>> This blog post still applies (but be sure to read the update > >>>>>>>>>> about > >>>>>>>>>> --cacert): > >>>>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> Ok. Next question is - how does one do the equivalent of the curl > >>>>>>>>> command in python code? > >>>>>>>> Here is a pretty stripped-down way to add a user. Other commands > >>>>>>>> are > >>>>>>>> similar, you just may care more about the output: > >>>>>>>> > >>>>>>>> from ipalib import api > >>>>>>>> from ipalib import errors > >>>>>>>> > >>>>>>>> api.bootstrap(context='cli') > >>>>>>>> api.finalize() > >>>>>>>> api.Backend.xmlclient.connect() > >>>>>>>> > >>>>>>>> try: > >>>>>>>> api.Command['user_add'](u'testuser', > >>>>>>>> givenname=u'Test', sn=u'User', > >>>>>>>> loginshell=u'/bin/sh') > >>>>>>>> except errors.DuplicateEntry: > >>>>>>>> print "user already exists" > >>>>>>>> else: > >>>>>>>> print "User added" > >>>>>>>> > >>>>>>> How would one do this from outside of ipa? If ipalib is not > >>>>>>> available? > >>>>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what > >>>>>> protocol you want to use) and issue one request there. This requires > >>>>>> Kerberos authentication. The response will include a cookie which you > >>>>>> should either ignore or store safely (like in the kernel keyring). > >>>>>> Using the cookie will significantly improve performance. > >>>>> This is for the ipa dns backend for designate. I'm assuming I will > >>>>> either be using a keytab, or perhaps the new proxy? > >>>>> > >>>>> At any rate, I have to do everything in python - including the kinit > >>>>> with the keytab. > >>>> Lok at rob's damon but you should *not* do a kinit, you should just use > >>>> gssapi (see python-kerberos) and do a gss_init_sec_context there, if > >>>> the > >>>> environment is configured (KRB5_KTNAME set correctly) then gssapi will > >>>> automatically kinit for you under the hood. > >>>> > >>>>> I guess I'm really looking for specifics - I've seen > >>>>> recommendations to > >>>>> use the python libraries "requests" and "json". I don't know if > >>>>> requests supports negotiate/kerberos. If not, is there a recommended > >>>>> library to use? As this particular project will be part of openstack, > >>>>> perhaps there is a more "openstack"-y library, or even something > >>>>> built-in to openstack (oslo?). I think amqp support kerberos, so > >>>>> perhaps there is some oslo.messaging thing that will do the http + > >>>>> kerberos stuff. > >>>> Afaik there is nothing that does kerberos in openstack, you'll have to > >>>> introduce all that stuff. > >>> > >>> Egads - implementing openstack-wide kerberos client libraries in order > >>> to add an ipa dns backend to designate. > >>> > >>> Rob, need any help with your proxy? > >> > >> Well, something occurred to me this morning. You need SSL on top of > >> this too, which means you need the IPA CA. The easiest way to get that > >> is to enroll the designate server as an IPA client. This pulls in the > >> freeipa-python package which gives you ipalib, so no reinventing the > >> wheel required. > > > > I'm trying to use python-kerberos to do auth with a keytab > > (KRB5_KTNAME), without first doing a kinit from the command line. It is > > not working. > > > > Does anyone know how I can do client side kerberos auth with a keytab in > > python without first doing a kinit? > > gssproxy. You need at least 0.3.1. > > Add something like this to the _top_ of /etc/gssproxy/gssproxy.conf: > > [service/myservice] > mechs = krb5 > cred_store = client_keytab:/etc/my.keytab > cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U > cred_usage = initiate > euid = xx (where xx is the uid of your process) > > I found running gssproxy directly in debug mode another window to be a > handy debugging tool while I got my head wrapped around things. Just for keytab initiation, GSS-Proxy should not be needed if you have reasonably recent krb5-libs (>= 1.11 IIRC), we just use gssapi lib in gss-proxy too and don't do explicit kinit in gss-proxy either. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Feb 27 16:35:59 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Feb 2014 11:35:59 -0500 Subject: [Freeipa-devel] Is there RPC documentation? In-Reply-To: <530F5CC3.6020805@redhat.com> References: <530E0C36.8080507@redhat.com> <530E0E02.8070505@redhat.com> <530E597C.2090901@redhat.com> <530E5A47.9000108@redhat.com> <530E5B59.7020904@redhat.com> <530E6934.60601@redhat.com> <530E6AAA.6020805@redhat.com> <1393454927.18299.205.camel@willson.li.ssimo.org> <530E7CA2.5080305@redhat.com> <530F3B5C.3080308@redhat.com> <530F5CC3.6020805@redhat.com> Message-ID: <1393518959.18299.219.camel@willson.li.ssimo.org> On Thu, 2014-02-27 at 08:41 -0700, Rich Megginson wrote: > On 02/27/2014 06:19 AM, Rob Crittenden wrote: > > Rich Megginson wrote: > >> On 02/26/2014 03:48 PM, Simo Sorce wrote: > >>> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: > >>>> On 02/26/2014 03:22 PM, Rob Crittenden wrote: > >>>>> Rich Megginson wrote: > >>>>>> On 02/26/2014 02:19 PM, Rob Crittenden wrote: > >>>>>>> Rich Megginson wrote: > >>>>>>>> On 02/26/2014 08:53 AM, Petr Viktorin wrote: > >>>>>>>>> On 02/26/2014 04:45 PM, Rich Megginson wrote: > >>>>>>>>>> I'm working on adding support for freeipa DNS to openstack > >>>>>>>>>> designate > >>>>>>>>>> (DNSaaS). I am assuming I need to use RPC (XML? JSON? > >>>>>>>>>> REST?) to > >>>>>>>>>> communicate with freeipa. Is there documentation about how to > >>>>>>>>>> construct > >>>>>>>>>> and send RPC messages? > >>>>>>>>> The JSON-RPC and XML-RPC API is still not "officially supported" > >>>>>>>>> (read: documented), though it's extremely unlikely to change. > >>>>>>>>> If you need an example, run any ipa command with -vv, this will > >>>>>>>>> print > >>>>>>>>> out the request & response. > >>>>>>>>> API.txt in the source tree lists all the commands and params. > >>>>>>>>> This blog post still applies (but be sure to read the update > >>>>>>>>> about > >>>>>>>>> --cacert): > >>>>>>>>> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Ok. Next question is - how does one do the equivalent of the curl > >>>>>>>> command in python code? > >>>>>>> Here is a pretty stripped-down way to add a user. Other commands > >>>>>>> are > >>>>>>> similar, you just may care more about the output: > >>>>>>> > >>>>>>> from ipalib import api > >>>>>>> from ipalib import errors > >>>>>>> > >>>>>>> api.bootstrap(context='cli') > >>>>>>> api.finalize() > >>>>>>> api.Backend.xmlclient.connect() > >>>>>>> > >>>>>>> try: > >>>>>>> api.Command['user_add'](u'testuser', > >>>>>>> givenname=u'Test', sn=u'User', > >>>>>>> loginshell=u'/bin/sh') > >>>>>>> except errors.DuplicateEntry: > >>>>>>> print "user already exists" > >>>>>>> else: > >>>>>>> print "User added" > >>>>>>> > >>>>>> How would one do this from outside of ipa? If ipalib is not > >>>>>> available? > >>>>> You'd need to go to either /ipa/xml or /ipa/json (depending on what > >>>>> protocol you want to use) and issue one request there. This requires > >>>>> Kerberos authentication. The response will include a cookie which you > >>>>> should either ignore or store safely (like in the kernel keyring). > >>>>> Using the cookie will significantly improve performance. > >>>> This is for the ipa dns backend for designate. I'm assuming I will > >>>> either be using a keytab, or perhaps the new proxy? > >>>> > >>>> At any rate, I have to do everything in python - including the kinit > >>>> with the keytab. > >>> Lok at rob's damon but you should *not* do a kinit, you should just use > >>> gssapi (see python-kerberos) and do a gss_init_sec_context there, if > >>> the > >>> environment is configured (KRB5_KTNAME set correctly) then gssapi will > >>> automatically kinit for you under the hood. > >>> > >>>> I guess I'm really looking for specifics - I've seen > >>>> recommendations to > >>>> use the python libraries "requests" and "json". I don't know if > >>>> requests supports negotiate/kerberos. If not, is there a recommended > >>>> library to use? As this particular project will be part of openstack, > >>>> perhaps there is a more "openstack"-y library, or even something > >>>> built-in to openstack (oslo?). I think amqp support kerberos, so > >>>> perhaps there is some oslo.messaging thing that will do the http + > >>>> kerberos stuff. > >>> Afaik there is nothing that does kerberos in openstack, you'll have to > >>> introduce all that stuff. > >> > >> Egads - implementing openstack-wide kerberos client libraries in order > >> to add an ipa dns backend to designate. > >> > >> Rob, need any help with your proxy? > > > > Well, something occurred to me this morning. You need SSL on top of > > this too, which means you need the IPA CA. The easiest way to get that > > is to enroll the designate server as an IPA client. This pulls in the > > freeipa-python package which gives you ipalib, so no reinventing the > > wheel required. > > I'm trying to use python-kerberos to do auth with a keytab > (KRB5_KTNAME), without first doing a kinit from the command line. It is > not working. > > Does anyone know how I can do client side kerberos auth with a keytab in > python without first doing a kinit? Ping me privately if you can't make it work and we'll try to debug why. Simo -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu Feb 27 16:36:20 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 17:36:20 +0100 Subject: [Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553) In-Reply-To: <530F5DC4.9050909@redhat.com> References: <530F5DC4.9050909@redhat.com> Message-ID: <530F6984.8050300@redhat.com> Hi, in the replication section you describe the behaviour when replicating to older versions of ds, but this is for n1, how about the new design ? Ludwig On 02/27/2014 04:46 PM, thierry bordaz wrote: > Hello, > > Thanks to all your feedbacks, they helped me a lot and raised a severe > limitation in the original design. > I updated the design following the aci syntax proposed during the > discussion. > On the implementation side, it is a bit more complex but less than I > expected. I have not yet investigated the impact of ger operations. > > I think a big work will be the test side as the ACI syntax provides > many options. > > http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation > > Note: I kept for the moment the original design in 'alternative no1'. > > regards > thierry > > > _______________________________________________ > 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 pspacek at redhat.com Thu Feb 27 16:37:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Feb 2014 17:37:05 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F66B6.6000301@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> Message-ID: <530F69B1.5050408@redhat.com> On 27.2.2014 17:24, Ludwig Krispenz wrote: > > On 02/27/2014 03:56 PM, Jan Cholasta wrote: >> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>> >>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>> >>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>> SoftHsm has >>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>> passes sets >>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>> it as >>>>>>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>>>>>> data. >>>>>>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>>>>>> pkcs >>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>> >>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>> the most >>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>>>> can >>>>>>>>>> use >>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>> than >>>>>>>>>> using one attribute per private key component. >>>>>>>>>> >>>>>>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>> objects. >>>>>>>>>> >>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>> low-level. >>>>>>>>> >>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>> certificate. >>>>>>>> >>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>> >>>>>>> Honzo, >>>>>>> >>>>>>> we really need the design page with some goal statement, high-level >>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>> that we >>>>>>> want to use the same module for cert distribution and at the same time >>>>>>> for DNSSEC key storage. >>>>>>> >>>>>> >>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>> >>>>> >>>>> +1, please do. We clearly need some design to start with. >>>>> >>>>> Martin >>>>> >>>> >>>> I already posted the link in other thread, but here it is anyway: >>>> . >>>> >>>> Some more comments on the schema: >>>> >>>> I think I may have been too quick to dismiss RFC 4523. There is >>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>> user", "authority" and "other entity". We could map entries with >>>> object class pkiUser to certificate object with >>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>> entity", but we will not be storing any certificates using PKCS#11 >>>> anyway, so I think it's OK. >>> not sure I understand what exactly you want here. If we don't store >>> certificates using the pkcs#11 schema we don't need to define them, but >>> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. >>> Do you mean to have a pkcs11 cerificate object with >>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>> userCertificate and cACertificate to store them ? >> >> Hopefully an example will better illustrate what I mean. We could map >> PKCS#11 objects like this: >> >> CKA_CLASS: CKO_CERTIFICATE >> CKA_CERTIFICATE_TYPE: CKC_X_509 >> CKA_CERTIFICATE_CATEGORY: 1 >> CKA_VALUE: >> >> >> to LDAP entries like this: >> >> dn: pkcs11uniqueId=, >> objectClass: pkcs11storageObject >> objectClass: pkiUser >> pkcs11uniqueId: >> userCertificate;binary: >> >> >> and PKCS#11 object like this: >> >> CKA_CLASS: CKO_CERTIFICATE >> CKA_CERTIFICATE_TYPE: CKC_X_509 >> CKA_CERTIFICATE_CATEGORY: 2 >> CKA_VALUE: >> >> >> to LDAP entries like this: >> >> dn: pkcs11uniqueId=, >> objectClass: pkcs11storageObject >> objectClass: pkiCA >> pkcs11uniqueId: >> caCertificate;binary: >> >> >> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and >> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". > so you want to directly use the pkiUser|CA objectclass, that would be ok >> >>>> >>>> Also the above got me thinking, is there any "standard" LDAP schema >>>> for private keys? If so, can we use it? >>> I didn't find any, the only keys in ldap I found is a definition for >>> sshPublicKey for openssh. >> >> And even this schema is for public keys only :-) OK, nevermind then. >> >>>> >>>> I'm going to store NSS trust objects along with CA certificates, so >>>> I'm going to need an object class for that. You can find the details >>>> on CKO_NSS_TRUST at >>>> . >>>> > so this is a nss extension to pkcs11, not in the standard ? If we add trust > objects, should the naming reflect this like pkcs11nss or pkcs11ext ? >>>> >>>> >>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>> there is going to be some redundancy. For example, public key value >>>> can be extracted from private key value, so we don't need to store >>>> both of the values. This can be bypassed by having separate object >>>> classes for data and for metadata. For a key pair entry, the object >>>> classes would be e.g. privateKey, pkcs11privateKey and >>>> pkcs11publicKey, where privateKey is an object class with private key >>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>> entry would be visible as two separate objects (private key object and >>>> public key object). >>> I have not yet rewritten the objectcalss definition after the latest >>> discussion, but I think if we have one structural objectclass >>> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for >>> publickey,privatekey, certificate where the attributes (maybe >>> withexception of label, id) are optional there will be no redundancy, >>> store only what is needed. >>> you could use these aux objectclass also in other entries instead of >>> using pkcs11storageObject. >> >> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I >> think they should be optional in LDAP as well. >> >>>> >>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>> private key and public key value attributes), I think they all should >>>> be single-valued. Comments on specific attributes: >>>> >>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>> attributes for these, for the sake of completeness >>> in progress >>>> >>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>> LDAP are always persistent, so there is no need for pkcs11token >>> ok >>>> >>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>> pkcs11certificateType >>> ok >>>> >>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>> classes (see above), we don't need an LDAP attribute for it >>> see above, where do you want to define the mapping. Do we then need >>> cert attrs at all ? >> >> If we use userCertificate and cACertificate, we don't need >> pkcs11certificateValue, if that's what you are asking. > I was asking if we need the pkcs11certificate objectclass and the certificate > metadata since you were using the pkiUser and pkiCA objectclasses to store the > cert, but you probably want the startdate, enddate and other attrs at least > available >> >>>> >>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>> certificate value, no need for LDAP attributes >>> ok >>>> >>>> * CKA_URL - do we want to support certificates with URL instead of >>>> value? >>> don't know, there are just some other attrs required when a URL is used >> >> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not required >> AFAIK, it's just that URL-only certificates do not make much sense without >> them. >> > yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty if > CKA_URL > is empty. I have a note about naming attribute: - I don't like nsUniqId here because you can't read it in LDAP browser by naked eye - I propose to use -- dn: CKA_CLASS=...+CKA_LABEL=... -- dn: CKA_CLASS=...+CKA_ID=... One of them should be present almost always and the writing 'entity' (effectively PKCS#11 module generating a new key or storing a new certificate) can fall back to uniqueId if there is neither LABEL nor ID. Honza told me that PKCS#11 module/user have to always do a LDAP search so this change should be 'cosmetic'. We are not LDAP experts. Ludwig, what do you think about compound names? Are they okay for general use? -- Petr^2 Spacek From npmccallum at redhat.com Thu Feb 27 16:42:20 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 27 Feb 2014 11:42:20 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530F6804.3090507@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> Message-ID: <1393519340.3562.13.camel@localhost.localdomain> On Thu, 2014-02-27 at 17:29 +0100, Petr Vobornik wrote: > On 27.2.2014 16:51, Nathaniel McCallum wrote: > > On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote: > >> On 21.2.2014 15:24, Petr Vobornik wrote: > >>> On 10.2.2014 14:12, Petr Vobornik wrote: > >>>> On 13.1.2014 17:09, Petr Vobornik wrote: > >>>>> Hi, > >>>>> > >>>>> these patches implements the OTP Web UI. > >>>>> > >>>>> Last 5 patches is the OTP UI. > >>>>> > >>>>> First 6 patches is a little refactoring/bug fixes needed for them. > >>>>> General password dialog is introduced to avoid another implementation. > >>>>> > >>>>> Self-service UI is implemented to be very simple. Atm user can choose > >>>>> only token name. Admin interface allows to enter all values. > >>>>> > >>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks > >>>>> Nathaniel for review of the last font package. It will speed things up. > >>>>> > >>>>> Know bugs: > >>>>> - there is clash in id's of checkboxes preventing editation of > >>>>> subsequently displayed ones with the same name. Will be fixed in > >>>>> separate patch. > >>>>> - bugs caused by bugs in API (adding/removal of own tokens in > >>>>> self-service, inability to enter key on token creation - > >>>>> https://fedorahosted.org/freeipa/ticket/4099) > >>>>> - datetime format (widget+validator) will be implemented in separate > >>>>> patch > >>>>> - no support of not reviewed CLI patches (HOTP..) > >>>>> > >>>>> Cgit: > >>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/3369 > >>>>> > >>>> > >>>> patch 540-1 has been updated > >>>> - QR code is centered > >>>> - QR code correction level was lowered from H to M > >>>> > >>>> All other current patches from sub-threads are attached as well (it was > >>>> getting hard to keep track of them). > >>>> > >>> > >>> Attaching new version of patch 537: 537-4 > >>> > >>> It: > >>> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter > >>> field in details facet > >>> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm > >>> and ipatokenotpdigits field > >>> > >>> > >>> Btw I've encountered an issue on Web UI login when: > >>> - user is created > >>> - token is created for him > >>> - admin resets user's password and changes auth type to 'otp' > >>> - user tries to login with psw+otp > >>> > >>> The initial login-password call is successful but subsequent change > >>> password fails - it uses the old psw+otp. > >>> > >>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 > >>> which is almost implemented. > >>> > >>> > >>> I also plan to hide fields without any value in otp token details page > >>> in self-service mode. This will be done after #3903 because some > >>> prerequisites for #3903 add useful code for that task. > >>> > >> > >> New version of 537 attached: 537-5 > >> > >> It removes token type switch from selfservice page. Therefore default > >> token type (totp) will be always created. > >> > >> Originated from: > >> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html > > > > I'm not sure I understand the rationale for this (after having read the > > other email thread). But I agree we should discuss which options should > > be available on the self-service page. > > > > Just to recap the situation: > > 1. Only token name / description are provided in the self-service UI > > 2. All options are provided on the CLI > > > > I think the main question is: who should get to choose the primary token > > type in FreeIPA? There are three possibilities: > > 1. FreeIPA developers > > 2. Admins > > 3. Users > > > > The case for #1 is that we can't guarantee timely replication of the > > counter attribute. On this basis, we choose TOTP as default because of > > structural limitations. This is currently the default. > > > > I don't see much use for #3. But I can see an argument for #2. > > > > Personally, I lean toward #1. Thoughts? > > > > Nathaniel > > > > Sorry, there is no real reason to not have HOTP there, and therefore > 537-5 is wrong and 537-4 is OK. > > Rationale of the mistake: > * self-service page has to be simple so it doesn't allow to add hw tokens > * My thoughts were fixed to the idea that HOTP has to be hw token - > maybe the H confused me. On a similar note, I've been toying with the idea of a ipatokenRestricted attribute. The idea is that restricted tokens cannot be created or deleted by users and, when the user is deleted, the token is orphaned in stead of deleted. During XML import, the restricted attribute would be set by default. This seems to me the correct behavior. Nathaniel From rmeggins at redhat.com Thu Feb 27 16:46:39 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Feb 2014 09:46:39 -0700 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F69B1.5050408@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F69B1.5050408@redhat.com> Message-ID: <530F6BEF.9080507@redhat.com> On 02/27/2014 09:37 AM, Petr Spacek wrote: > On 27.2.2014 17:24, Ludwig Krispenz wrote: >> >> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>> >>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in >>>>>>>>>>>> softhsm. >>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>> SoftHsm has >>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>> passes sets >>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>> it as >>>>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>>>> blob of >>>>>>>>>>>> data. >>>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>>> fingrained the >>>>>>>>>>>> pkcs >>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: >>>>>>>>>>>> one ldap >>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>> >>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>> the most >>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>> optimization for our needs. For example, like you said >>>>>>>>>>> above, we >>>>>>>>>>> can >>>>>>>>>>> use >>>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>>> than >>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>> >>>>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>>>> PKCS#11 >>>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>>> attributes >>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>> objects. >>>>>>>>>>> >>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>> low-level. >>>>>>>>>> >>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>> certificate. >>>>>>>>> >>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>> >>>>>>>> Honzo, >>>>>>>> >>>>>>>> we really need the design page with some goal statement, >>>>>>>> high-level >>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>> that we >>>>>>>> want to use the same module for cert distribution and at the >>>>>>>> same time >>>>>>>> for DNSSEC key storage. >>>>>>>> >>>>>>> >>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>> >>>>>> >>>>>> +1, please do. We clearly need some design to start with. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I already posted the link in other thread, but here it is anyway: >>>>> . >>>>> >>>>> Some more comments on the schema: >>>>> >>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>> user", "authority" and "other entity". We could map entries with >>>>> object class pkiUser to certificate object with >>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY >>>>> "authority". >>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>> anyway, so I think it's OK. >>>> not sure I understand what exactly you want here. If we don't store >>>> certificates using the pkcs#11 schema we don't need to define them, >>>> but >>>> on the other hand you talk about the usage of >>>> CKA_CERTIFICATE_CATEGORY. >>>> Do you mean to have a pkcs11 cerificate object with >>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>> userCertificate and cACertificate to store them ? >>> >>> Hopefully an example will better illustrate what I mean. We could map >>> PKCS#11 objects like this: >>> >>> CKA_CLASS: CKO_CERTIFICATE >>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>> CKA_CERTIFICATE_CATEGORY: 1 >>> CKA_VALUE: >>> >>> >>> to LDAP entries like this: >>> >>> dn: pkcs11uniqueId=, >>> objectClass: pkcs11storageObject >>> objectClass: pkiUser >>> pkcs11uniqueId: >>> userCertificate;binary: >>> >>> >>> and PKCS#11 object like this: >>> >>> CKA_CLASS: CKO_CERTIFICATE >>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>> CKA_CERTIFICATE_CATEGORY: 2 >>> CKA_VALUE: >>> >>> >>> to LDAP entries like this: >>> >>> dn: pkcs11uniqueId=, >>> objectClass: pkcs11storageObject >>> objectClass: pkiCA >>> pkcs11uniqueId: >>> caCertificate;binary: >>> >>> >>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: >>> pkiUser" and >>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >> so you want to directly use the pkiUser|CA objectclass, that would be ok >>> >>>>> >>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>> for private keys? If so, can we use it? >>>> I didn't find any, the only keys in ldap I found is a definition for >>>> sshPublicKey for openssh. >>> >>> And even this schema is for public keys only :-) OK, nevermind then. >>> >>>>> >>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>> I'm going to need an object class for that. You can find the details >>>>> on CKO_NSS_TRUST at >>>>> . >>>>> >>>>> >> so this is a nss extension to pkcs11, not in the standard ? If we >> add trust >> objects, should the naming reflect this like pkcs11nss or >> pkcs11ext ? >>>>> >>>>> >>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>> there is going to be some redundancy. For example, public key value >>>>> can be extracted from private key value, so we don't need to store >>>>> both of the values. This can be bypassed by having separate object >>>>> classes for data and for metadata. For a key pair entry, the object >>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>> pkcs11publicKey, where privateKey is an object class with private key >>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>> entry would be visible as two separate objects (private key object >>>>> and >>>>> public key object). >>>> I have not yet rewritten the objectcalss definition after the latest >>>> discussion, but I think if we have one structural objectclass >>>> pkcs11storageObject with only a uniqueid and auxiliary >>>> objectclasses for >>>> publickey,privatekey, certificate where the attributes (maybe >>>> withexception of label, id) are optional there will be no redundancy, >>>> store only what is needed. >>>> you could use these aux objectclass also in other entries instead of >>>> using pkcs11storageObject. >>> >>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I >>> think they should be optional in LDAP as well. >>> >>>>> >>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>> private key and public key value attributes), I think they all should >>>>> be single-valued. Comments on specific attributes: >>>>> >>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>>> attributes for these, for the sake of completeness >>>> in progress >>>>> >>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>>> LDAP are always persistent, so there is no need for pkcs11token >>>> ok >>>>> >>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>>> pkcs11certificateType >>>> ok >>>>> >>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>> classes (see above), we don't need an LDAP attribute for it >>>> see above, where do you want to define the mapping. Do we then need >>>> cert attrs at all ? >>> >>> If we use userCertificate and cACertificate, we don't need >>> pkcs11certificateValue, if that's what you are asking. >> I was asking if we need the pkcs11certificate objectclass and the >> certificate >> metadata since you were using the pkiUser and pkiCA objectclasses to >> store the >> cert, but you probably want the startdate, enddate and other attrs at >> least >> available >>> >>>>> >>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>> certificate value, no need for LDAP attributes >>>> ok >>>>> >>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>> value? >>>> don't know, there are just some other attrs required when a URL is >>>> used >>> >>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >>> required >>> AFAIK, it's just that URL-only certificates do not make much sense >>> without >>> them. >>> >> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be >> empty if >> CKA_URL >> >> is empty. > > I have a note about naming attribute: > - I don't like nsUniqId here because you can't read it in LDAP browser > by naked eye > - I propose to use > -- dn: CKA_CLASS=...+CKA_LABEL=... > -- dn: CKA_CLASS=...+CKA_ID=... > One of them should be present almost always and the writing 'entity' > (effectively PKCS#11 module generating a new key or storing a new > certificate) can fall back to uniqueId if there is neither LABEL nor ID. > > Honza told me that PKCS#11 module/user have to always do a LDAP search > so this change should be 'cosmetic'. > > We are not LDAP experts. Ludwig, what do you think about compound > names? Are they okay for general use? They are problematic. I would prefer to avoid having multi-component RDNs. From jcholast at redhat.com Thu Feb 27 16:48:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 17:48:22 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F66B6.6000301@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> Message-ID: <530F6C56.4010404@redhat.com> On 27.2.2014 17:24, Ludwig Krispenz wrote: > > On 02/27/2014 03:56 PM, Jan Cholasta wrote: >> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>> >>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>> >>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>> SoftHsm has >>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>> passes sets >>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>> it as >>>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>>> blob of >>>>>>>>>>> data. >>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>> fingrained the >>>>>>>>>>> pkcs >>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one >>>>>>>>>>> ldap >>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>> >>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>> the most >>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>>>> can >>>>>>>>>> use >>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>> than >>>>>>>>>> using one attribute per private key component. >>>>>>>>>> >>>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>>> PKCS#11 >>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>> attributes >>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>> objects. >>>>>>>>>> >>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>> low-level. >>>>>>>>> >>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>> certificate. >>>>>>>> >>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>> >>>>>>> Honzo, >>>>>>> >>>>>>> we really need the design page with some goal statement, high-level >>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>> that we >>>>>>> want to use the same module for cert distribution and at the same >>>>>>> time >>>>>>> for DNSSEC key storage. >>>>>>> >>>>>> >>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>> >>>>> >>>>> +1, please do. We clearly need some design to start with. >>>>> >>>>> Martin >>>>> >>>> >>>> I already posted the link in other thread, but here it is anyway: >>>> . >>>> >>>> Some more comments on the schema: >>>> >>>> I think I may have been too quick to dismiss RFC 4523. There is >>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>> user", "authority" and "other entity". We could map entries with >>>> object class pkiUser to certificate object with >>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>> entity", but we will not be storing any certificates using PKCS#11 >>>> anyway, so I think it's OK. >>> not sure I understand what exactly you want here. If we don't store >>> certificates using the pkcs#11 schema we don't need to define them, but >>> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. >>> Do you mean to have a pkcs11 cerificate object with >>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>> userCertificate and cACertificate to store them ? >> >> Hopefully an example will better illustrate what I mean. We could map >> PKCS#11 objects like this: >> >> CKA_CLASS: CKO_CERTIFICATE >> CKA_CERTIFICATE_TYPE: CKC_X_509 >> CKA_CERTIFICATE_CATEGORY: 1 >> CKA_VALUE: >> >> >> to LDAP entries like this: >> >> dn: pkcs11uniqueId=, >> objectClass: pkcs11storageObject >> objectClass: pkiUser >> pkcs11uniqueId: >> userCertificate;binary: >> >> >> and PKCS#11 object like this: >> >> CKA_CLASS: CKO_CERTIFICATE >> CKA_CERTIFICATE_TYPE: CKC_X_509 >> CKA_CERTIFICATE_CATEGORY: 2 >> CKA_VALUE: >> >> >> to LDAP entries like this: >> >> dn: pkcs11uniqueId=, >> objectClass: pkcs11storageObject >> objectClass: pkiCA >> pkcs11uniqueId: >> caCertificate;binary: >> >> >> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" >> and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". > so you want to directly use the pkiUser|CA objectclass, that would be ok I think it would make sense after all, if that's OK by the present LDAP gurus :-) >> >>>> >>>> Also the above got me thinking, is there any "standard" LDAP schema >>>> for private keys? If so, can we use it? >>> I didn't find any, the only keys in ldap I found is a definition for >>> sshPublicKey for openssh. >> >> And even this schema is for public keys only :-) OK, nevermind then. >> >>>> >>>> I'm going to store NSS trust objects along with CA certificates, so >>>> I'm going to need an object class for that. You can find the details >>>> on CKO_NSS_TRUST at >>>> . >>>> > so this is a nss extension to pkcs11, not in the standard ? If we add > trust objects, should the naming reflect this like pkcs11nss or > pkcs11ext ? Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss". >>>> >>>> >>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>> there is going to be some redundancy. For example, public key value >>>> can be extracted from private key value, so we don't need to store >>>> both of the values. This can be bypassed by having separate object >>>> classes for data and for metadata. For a key pair entry, the object >>>> classes would be e.g. privateKey, pkcs11privateKey and >>>> pkcs11publicKey, where privateKey is an object class with private key >>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>> entry would be visible as two separate objects (private key object and >>>> public key object). >>> I have not yet rewritten the objectcalss definition after the latest >>> discussion, but I think if we have one structural objectclass >>> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for >>> publickey,privatekey, certificate where the attributes (maybe >>> withexception of label, id) are optional there will be no redundancy, >>> store only what is needed. >>> you could use these aux objectclass also in other entries instead of >>> using pkcs11storageObject. >> >> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so >> I think they should be optional in LDAP as well. >> >>>> >>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>> private key and public key value attributes), I think they all should >>>> be single-valued. Comments on specific attributes: >>>> >>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>> attributes for these, for the sake of completeness >>> in progress >>>> >>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>> LDAP are always persistent, so there is no need for pkcs11token >>> ok >>>> >>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>> pkcs11certificateType >>> ok >>>> >>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>> classes (see above), we don't need an LDAP attribute for it >>> see above, where do you want to define the mapping. Do we then need >>> cert attrs at all ? >> >> If we use userCertificate and cACertificate, we don't need >> pkcs11certificateValue, if that's what you are asking. > I was asking if we need the pkcs11certificate objectclass and the > certificate metadata since you were using the pkiUser and pkiCA > objectclasses to store the cert, but you probably want the startdate, > enddate and other attrs at least available Yes, I don't want to lose any of the metadata, anything but CKA_VALUE should still be available in pkcs11certificate. >> >>>> >>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>> certificate value, no need for LDAP attributes >>> ok >>>> >>>> * CKA_URL - do we want to support certificates with URL instead of >>>> value? >>> don't know, there are just some other attrs required when a URL is used >> >> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >> required AFAIK, it's just that URL-only certificates do not make much >> sense without them. >> > yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty > if CKA_URL > > is empty. > Well, the PKCS#11 spec says: "The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY attributes are used to store the hashes of the public keys of the subject and the issuer. They are particularly important when only the URL is available to be able to correlate a certificate with a private key and when searching for the certificate of the issuer." I can see the word "important", but not the word "required". -- Jan Cholasta From lkrispen at redhat.com Thu Feb 27 16:49:21 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 17:49:21 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F6C56.4010404@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F6C56.4010404@redhat.com> Message-ID: <530F6C91.8010505@redhat.com> On 02/27/2014 05:48 PM, Jan Cholasta wrote: > On 27.2.2014 17:24, Ludwig Krispenz wrote: >> >> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>> >>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in >>>>>>>>>>>> softhsm. >>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>> SoftHsm has >>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>> passes sets >>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>> it as >>>>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>>>> blob of >>>>>>>>>>>> data. >>>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>>> fingrained the >>>>>>>>>>>> pkcs >>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one >>>>>>>>>>>> ldap >>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>> >>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>> the most >>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>> optimization for our needs. For example, like you said >>>>>>>>>>> above, we >>>>>>>>>>> can >>>>>>>>>>> use >>>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>>> than >>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>> >>>>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>>>> PKCS#11 >>>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>>> attributes >>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>> objects. >>>>>>>>>>> >>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>> low-level. >>>>>>>>>> >>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>> certificate. >>>>>>>>> >>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>> >>>>>>>> Honzo, >>>>>>>> >>>>>>>> we really need the design page with some goal statement, >>>>>>>> high-level >>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>> that we >>>>>>>> want to use the same module for cert distribution and at the same >>>>>>>> time >>>>>>>> for DNSSEC key storage. >>>>>>>> >>>>>>> >>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>> >>>>>> >>>>>> +1, please do. We clearly need some design to start with. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I already posted the link in other thread, but here it is anyway: >>>>> . >>>>> >>>>> Some more comments on the schema: >>>>> >>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>> user", "authority" and "other entity". We could map entries with >>>>> object class pkiUser to certificate object with >>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY >>>>> "authority". >>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>> anyway, so I think it's OK. >>>> not sure I understand what exactly you want here. If we don't store >>>> certificates using the pkcs#11 schema we don't need to define them, >>>> but >>>> on the other hand you talk about the usage of >>>> CKA_CERTIFICATE_CATEGORY. >>>> Do you mean to have a pkcs11 cerificate object with >>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>> userCertificate and cACertificate to store them ? >>> >>> Hopefully an example will better illustrate what I mean. We could map >>> PKCS#11 objects like this: >>> >>> CKA_CLASS: CKO_CERTIFICATE >>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>> CKA_CERTIFICATE_CATEGORY: 1 >>> CKA_VALUE: >>> >>> >>> to LDAP entries like this: >>> >>> dn: pkcs11uniqueId=, >>> objectClass: pkcs11storageObject >>> objectClass: pkiUser >>> pkcs11uniqueId: >>> userCertificate;binary: >>> >>> >>> and PKCS#11 object like this: >>> >>> CKA_CLASS: CKO_CERTIFICATE >>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>> CKA_CERTIFICATE_CATEGORY: 2 >>> CKA_VALUE: >>> >>> >>> to LDAP entries like this: >>> >>> dn: pkcs11uniqueId=, >>> objectClass: pkcs11storageObject >>> objectClass: pkiCA >>> pkcs11uniqueId: >>> caCertificate;binary: >>> >>> >>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" >>> and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >> so you want to directly use the pkiUser|CA objectclass, that would be ok > > I think it would make sense after all, if that's OK by the present > LDAP gurus :-) > >>> >>>>> >>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>> for private keys? If so, can we use it? >>>> I didn't find any, the only keys in ldap I found is a definition for >>>> sshPublicKey for openssh. >>> >>> And even this schema is for public keys only :-) OK, nevermind then. >>> >>>>> >>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>> I'm going to need an object class for that. You can find the details >>>>> on CKO_NSS_TRUST at >>>>> . >>>>> >>>>> >> so this is a nss extension to pkcs11, not in the standard ? If we add >> trust objects, should the naming reflect this like pkcs11nss or >> pkcs11ext ? > > Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss". > >>>>> >>>>> >>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>> there is going to be some redundancy. For example, public key value >>>>> can be extracted from private key value, so we don't need to store >>>>> both of the values. This can be bypassed by having separate object >>>>> classes for data and for metadata. For a key pair entry, the object >>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>> pkcs11publicKey, where privateKey is an object class with private key >>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>> entry would be visible as two separate objects (private key object >>>>> and >>>>> public key object). >>>> I have not yet rewritten the objectcalss definition after the latest >>>> discussion, but I think if we have one structural objectclass >>>> pkcs11storageObject with only a uniqueid and auxiliary >>>> objectclasses for >>>> publickey,privatekey, certificate where the attributes (maybe >>>> withexception of label, id) are optional there will be no redundancy, >>>> store only what is needed. >>>> you could use these aux objectclass also in other entries instead of >>>> using pkcs11storageObject. >>> >>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so >>> I think they should be optional in LDAP as well. >>> >>>>> >>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>> private key and public key value attributes), I think they all should >>>>> be single-valued. Comments on specific attributes: >>>>> >>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>>> attributes for these, for the sake of completeness >>>> in progress >>>>> >>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>>> LDAP are always persistent, so there is no need for pkcs11token >>>> ok >>>>> >>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>>> pkcs11certificateType >>>> ok >>>>> >>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>> classes (see above), we don't need an LDAP attribute for it >>>> see above, where do you want to define the mapping. Do we then need >>>> cert attrs at all ? >>> >>> If we use userCertificate and cACertificate, we don't need >>> pkcs11certificateValue, if that's what you are asking. >> I was asking if we need the pkcs11certificate objectclass and the >> certificate metadata since you were using the pkiUser and pkiCA >> objectclasses to store the cert, but you probably want the startdate, >> enddate and other attrs at least available > > Yes, I don't want to lose any of the metadata, anything but CKA_VALUE > should still be available in pkcs11certificate. > >>> >>>>> >>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>> certificate value, no need for LDAP attributes >>>> ok >>>>> >>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>> value? >>>> don't know, there are just some other attrs required when a URL is >>>> used >>> >>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >>> required AFAIK, it's just that URL-only certificates do not make much >>> sense without them. >>> >> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty >> if CKA_URL >> >> is empty. >> > > Well, the PKCS#11 spec says: > > "The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY > attributes are used to store the hashes of the public keys of the > subject and the issuer. They are particularly important when only the > URL is available to be able to correlate a certificate with a private > key and when searching for the certificate of the issuer." > > I can see the word "important", but not the word "required". > I was referring to note-4 in this doc: http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__6__3__X__509__PUBLIC__KEY__CERTIFICATE__OBJECTS.html From jcholast at redhat.com Thu Feb 27 16:53:58 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Feb 2014 17:53:58 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F6C91.8010505@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F6C56.4010404@redhat.com> <530F6C91.8010505@redhat.com> Message-ID: <530F6DA6.4090300@redhat.com> On 27.2.2014 17:49, Ludwig Krispenz wrote: > > On 02/27/2014 05:48 PM, Jan Cholasta wrote: >> On 27.2.2014 17:24, Ludwig Krispenz wrote: >>> >>> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>>> >>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in >>>>>>>>>>>>> softhsm. >>>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>>> SoftHsm has >>>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>>> passes sets >>>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>>> it as >>>>>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>>>>> blob of >>>>>>>>>>>>> data. >>>>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>>>> fingrained the >>>>>>>>>>>>> pkcs >>>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one >>>>>>>>>>>>> ldap >>>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>>> >>>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>>> the most >>>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>>> optimization for our needs. For example, like you said >>>>>>>>>>>> above, we >>>>>>>>>>>> can >>>>>>>>>>>> use >>>>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>>>> than >>>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>>> >>>>>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>>>>> PKCS#11 >>>>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>>>> attributes >>>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>>> objects. >>>>>>>>>>>> >>>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>>> low-level. >>>>>>>>>>> >>>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>>> certificate. >>>>>>>>>> >>>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>>> >>>>>>>>> Honzo, >>>>>>>>> >>>>>>>>> we really need the design page with some goal statement, >>>>>>>>> high-level >>>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>>> that we >>>>>>>>> want to use the same module for cert distribution and at the same >>>>>>>>> time >>>>>>>>> for DNSSEC key storage. >>>>>>>>> >>>>>>>> >>>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>>> >>>>>>> >>>>>>> +1, please do. We clearly need some design to start with. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I already posted the link in other thread, but here it is anyway: >>>>>> . >>>>>> >>>>>> Some more comments on the schema: >>>>>> >>>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>>> user", "authority" and "other entity". We could map entries with >>>>>> object class pkiUser to certificate object with >>>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY >>>>>> "authority". >>>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>>> anyway, so I think it's OK. >>>>> not sure I understand what exactly you want here. If we don't store >>>>> certificates using the pkcs#11 schema we don't need to define them, >>>>> but >>>>> on the other hand you talk about the usage of >>>>> CKA_CERTIFICATE_CATEGORY. >>>>> Do you mean to have a pkcs11 cerificate object with >>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>>> userCertificate and cACertificate to store them ? >>>> >>>> Hopefully an example will better illustrate what I mean. We could map >>>> PKCS#11 objects like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 1 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiUser >>>> pkcs11uniqueId: >>>> userCertificate;binary: >>>> >>>> >>>> and PKCS#11 object like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 2 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiCA >>>> pkcs11uniqueId: >>>> caCertificate;binary: >>>> >>>> >>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" >>>> and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >>> so you want to directly use the pkiUser|CA objectclass, that would be ok >> >> I think it would make sense after all, if that's OK by the present >> LDAP gurus :-) >> >>>> >>>>>> >>>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>>> for private keys? If so, can we use it? >>>>> I didn't find any, the only keys in ldap I found is a definition for >>>>> sshPublicKey for openssh. >>>> >>>> And even this schema is for public keys only :-) OK, nevermind then. >>>> >>>>>> >>>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>>> I'm going to need an object class for that. You can find the details >>>>>> on CKO_NSS_TRUST at >>>>>> . >>>>>> >>>>>> >>> so this is a nss extension to pkcs11, not in the standard ? If we add >>> trust objects, should the naming reflect this like pkcs11nss or >>> pkcs11ext ? >> >> Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss". >> >>>>>> >>>>>> >>>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>>> there is going to be some redundancy. For example, public key value >>>>>> can be extracted from private key value, so we don't need to store >>>>>> both of the values. This can be bypassed by having separate object >>>>>> classes for data and for metadata. For a key pair entry, the object >>>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>>> pkcs11publicKey, where privateKey is an object class with private key >>>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>>> entry would be visible as two separate objects (private key object >>>>>> and >>>>>> public key object). >>>>> I have not yet rewritten the objectcalss definition after the latest >>>>> discussion, but I think if we have one structural objectclass >>>>> pkcs11storageObject with only a uniqueid and auxiliary >>>>> objectclasses for >>>>> publickey,privatekey, certificate where the attributes (maybe >>>>> withexception of label, id) are optional there will be no redundancy, >>>>> store only what is needed. >>>>> you could use these aux objectclass also in other entries instead of >>>>> using pkcs11storageObject. >>>> >>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so >>>> I think they should be optional in LDAP as well. >>>> >>>>>> >>>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>>> private key and public key value attributes), I think they all should >>>>>> be single-valued. Comments on specific attributes: >>>>>> >>>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>>>> attributes for these, for the sake of completeness >>>>> in progress >>>>>> >>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>>>> LDAP are always persistent, so there is no need for pkcs11token >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>>>> pkcs11certificateType >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>>> classes (see above), we don't need an LDAP attribute for it >>>>> see above, where do you want to define the mapping. Do we then need >>>>> cert attrs at all ? >>>> >>>> If we use userCertificate and cACertificate, we don't need >>>> pkcs11certificateValue, if that's what you are asking. >>> I was asking if we need the pkcs11certificate objectclass and the >>> certificate metadata since you were using the pkiUser and pkiCA >>> objectclasses to store the cert, but you probably want the startdate, >>> enddate and other attrs at least available >> >> Yes, I don't want to lose any of the metadata, anything but CKA_VALUE >> should still be available in pkcs11certificate. >> >>>> >>>>>> >>>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>>> certificate value, no need for LDAP attributes >>>>> ok >>>>>> >>>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>>> value? >>>>> don't know, there are just some other attrs required when a URL is >>>>> used >>>> >>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >>>> required AFAIK, it's just that URL-only certificates do not make much >>>> sense without them. >>>> >>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty >>> if CKA_URL >>> >>> is empty. >>> >> >> Well, the PKCS#11 spec says: >> >> "The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY >> attributes are used to store the hashes of the public keys of the >> subject and the issuer. They are particularly important when only the >> URL is available to be able to correlate a certificate with a private >> key and when searching for the certificate of the issuer." >> >> I can see the word "important", but not the word "required". >> > I was referring to note-4 in this doc: > http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__6__3__X__509__PUBLIC__KEY__CERTIFICATE__OBJECTS.html Ah, right, the footnote is in the spec too. Sorry for the fuss then, apparently I need to improve my reading skills. -- Jan Cholasta From lkrispen at redhat.com Thu Feb 27 16:55:19 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 27 Feb 2014 17:55:19 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F6BEF.9080507@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F69B1.5050408@redhat.com> <530F6BEF.9080507@redhat.com> Message-ID: <530F6DF7.6090208@redhat.com> On 02/27/2014 05:46 PM, Rich Megginson wrote: > On 02/27/2014 09:37 AM, Petr Spacek wrote: >> On 27.2.2014 17:24, Ludwig Krispenz wrote: >>> >>> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>>> >>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in >>>>>>>>>>>>> softhsm. >>>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>>> SoftHsm has >>>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>>> passes sets >>>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>>> it as >>>>>>>>>>>>> records in sql where each record has a keytype and opaque >>>>>>>>>>>>> blob of >>>>>>>>>>>>> data. >>>>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>>>> fingrained the >>>>>>>>>>>>> pkcs >>>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: >>>>>>>>>>>>> one ldap >>>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>>> >>>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>>> the most >>>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>>> optimization for our needs. For example, like you said >>>>>>>>>>>> above, we >>>>>>>>>>>> can >>>>>>>>>>>> use >>>>>>>>>>>> a single attribute containing PKCS#8 encoded private key >>>>>>>>>>>> rather >>>>>>>>>>>> than >>>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>>> >>>>>>>>>>>> I don't think we need an LDAP attribute for every possible >>>>>>>>>>>> PKCS#11 >>>>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>>>> attributes >>>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>>> objects. >>>>>>>>>>>> >>>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>>> low-level. >>>>>>>>>>> >>>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>>> certificate. >>>>>>>>>> >>>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>>> >>>>>>>>> Honzo, >>>>>>>>> >>>>>>>>> we really need the design page with some goal statement, >>>>>>>>> high-level >>>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>>> that we >>>>>>>>> want to use the same module for cert distribution and at the >>>>>>>>> same time >>>>>>>>> for DNSSEC key storage. >>>>>>>>> >>>>>>>> >>>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>>> >>>>>>> >>>>>>> +1, please do. We clearly need some design to start with. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I already posted the link in other thread, but here it is anyway: >>>>>> . >>>>>> >>>>>> Some more comments on the schema: >>>>>> >>>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>>> user", "authority" and "other entity". We could map entries with >>>>>> object class pkiUser to certificate object with >>>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY >>>>>> "authority". >>>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>>> anyway, so I think it's OK. >>>>> not sure I understand what exactly you want here. If we don't store >>>>> certificates using the pkcs#11 schema we don't need to define >>>>> them, but >>>>> on the other hand you talk about the usage of >>>>> CKA_CERTIFICATE_CATEGORY. >>>>> Do you mean to have a pkcs11 cerificate object with >>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>>> userCertificate and cACertificate to store them ? >>>> >>>> Hopefully an example will better illustrate what I mean. We could map >>>> PKCS#11 objects like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 1 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiUser >>>> pkcs11uniqueId: >>>> userCertificate;binary: >>>> >>>> >>>> and PKCS#11 object like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 2 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiCA >>>> pkcs11uniqueId: >>>> caCertificate;binary: >>>> >>>> >>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: >>>> pkiUser" and >>>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >>> so you want to directly use the pkiUser|CA objectclass, that would >>> be ok >>>> >>>>>> >>>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>>> for private keys? If so, can we use it? >>>>> I didn't find any, the only keys in ldap I found is a definition for >>>>> sshPublicKey for openssh. >>>> >>>> And even this schema is for public keys only :-) OK, nevermind then. >>>> >>>>>> >>>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>>> I'm going to need an object class for that. You can find the details >>>>>> on CKO_NSS_TRUST at >>>>>> . >>>>>> >>>>>> >>> so this is a nss extension to pkcs11, not in the standard ? If we >>> add trust >>> objects, should the naming reflect this like pkcs11nss or >>> pkcs11ext ? >>>>>> >>>>>> >>>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>>> there is going to be some redundancy. For example, public key value >>>>>> can be extracted from private key value, so we don't need to store >>>>>> both of the values. This can be bypassed by having separate object >>>>>> classes for data and for metadata. For a key pair entry, the object >>>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>>> pkcs11publicKey, where privateKey is an object class with private >>>>>> key >>>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>>> entry would be visible as two separate objects (private key >>>>>> object and >>>>>> public key object). >>>>> I have not yet rewritten the objectcalss definition after the latest >>>>> discussion, but I think if we have one structural objectclass >>>>> pkcs11storageObject with only a uniqueid and auxiliary >>>>> objectclasses for >>>>> publickey,privatekey, certificate where the attributes (maybe >>>>> withexception of label, id) are optional there will be no redundancy, >>>>> store only what is needed. >>>>> you could use these aux objectclass also in other entries instead of >>>>> using pkcs11storageObject. >>>> >>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, >>>> so I >>>> think they should be optional in LDAP as well. >>>> >>>>>> >>>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>>> private key and public key value attributes), I think they all >>>>>> should >>>>>> be single-valued. Comments on specific attributes: >>>>>> >>>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be >>>>>> LDAP >>>>>> attributes for these, for the sake of completeness >>>>> in progress >>>>>> >>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and >>>>>> objects in >>>>>> LDAP are always persistent, so there is no need for pkcs11token >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need >>>>>> for >>>>>> pkcs11certificateType >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>>> classes (see above), we don't need an LDAP attribute for it >>>>> see above, where do you want to define the mapping. Do we then need >>>>> cert attrs at all ? >>>> >>>> If we use userCertificate and cACertificate, we don't need >>>> pkcs11certificateValue, if that's what you are asking. >>> I was asking if we need the pkcs11certificate objectclass and the >>> certificate >>> metadata since you were using the pkiUser and pkiCA objectclasses to >>> store the >>> cert, but you probably want the startdate, enddate and other attrs >>> at least >>> available >>>> >>>>>> >>>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>>> certificate value, no need for LDAP attributes >>>>> ok >>>>>> >>>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>>> value? >>>>> don't know, there are just some other attrs required when a URL is >>>>> used >>>> >>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >>>> required >>>> AFAIK, it's just that URL-only certificates do not make much sense >>>> without >>>> them. >>>> >>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be >>> empty if >>> CKA_URL >>> >>> is empty. >> >> I have a note about naming attribute: >> - I don't like nsUniqId here because you can't read it in LDAP >> browser by naked eye >> - I propose to use >> -- dn: CKA_CLASS=...+CKA_LABEL=... >> -- dn: CKA_CLASS=...+CKA_ID=... >> One of them should be present almost always and the writing 'entity' >> (effectively PKCS#11 module generating a new key or storing a new >> certificate) can fall back to uniqueId if there is neither LABEL nor ID. >> >> Honza told me that PKCS#11 module/user have to always do a LDAP >> search so this change should be 'cosmetic'. >> >> We are not LDAP experts. Ludwig, what do you think about compound >> names? Are they okay for general use? > > They are problematic. I would prefer to avoid having multi-component > RDNs. agreed, they are not very common. You can make any allowed attribute the naming attribute, so you have the choice eg "dn: pkcs11label=....., ". It should be some attr available in all the objects. You can also use the suggested attribute pkcs11uniqueid and do not use the ipaUniqueid strings, but soemthing readable. We can als define an other attr which does not sound like uniqueid eg pkcs11object[id|name|..] > > > From pspacek at redhat.com Thu Feb 27 20:10:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Feb 2014 21:10:03 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F6DF7.6090208@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F69B1.5050408@redhat.com> <530F6BEF.9080507@redhat.com> <530F6DF7.6090208@redhat.com> Message-ID: <530F9B9B.3090400@redhat.com> On 27.2.2014 17:55, Ludwig Krispenz wrote: > > On 02/27/2014 05:46 PM, Rich Megginson wrote: >> On 02/27/2014 09:37 AM, Petr Spacek wrote: >>> On 27.2.2014 17:24, Ludwig Krispenz wrote: >>>> >>>> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>>>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>>>> >>>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>>>> SoftHsm has >>>>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>>>> passes sets >>>>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>>>> it as >>>>>>>>>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>>>>>>>>> data. >>>>>>>>>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>>>>>>>>> pkcs >>>>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>>>> >>>>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>>>> the most >>>>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>>>>>>> can >>>>>>>>>>>>> use >>>>>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>>>>> than >>>>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>>>>>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>>>> objects. >>>>>>>>>>>>> >>>>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>>>> low-level. >>>>>>>>>>>> >>>>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>>>> certificate. >>>>>>>>>>> >>>>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>>>> >>>>>>>>>> Honzo, >>>>>>>>>> >>>>>>>>>> we really need the design page with some goal statement, high-level >>>>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>>>> that we >>>>>>>>>> want to use the same module for cert distribution and at the same time >>>>>>>>>> for DNSSEC key storage. >>>>>>>>>> >>>>>>>>> >>>>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>>>> >>>>>>>> >>>>>>>> +1, please do. We clearly need some design to start with. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> I already posted the link in other thread, but here it is anyway: >>>>>>> . >>>>>>> >>>>>>> Some more comments on the schema: >>>>>>> >>>>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>>>> user", "authority" and "other entity". We could map entries with >>>>>>> object class pkiUser to certificate object with >>>>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >>>>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>>>> anyway, so I think it's OK. >>>>>> not sure I understand what exactly you want here. If we don't store >>>>>> certificates using the pkcs#11 schema we don't need to define them, but >>>>>> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. >>>>>> Do you mean to have a pkcs11 cerificate object with >>>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>>>> userCertificate and cACertificate to store them ? >>>>> >>>>> Hopefully an example will better illustrate what I mean. We could map >>>>> PKCS#11 objects like this: >>>>> >>>>> CKA_CLASS: CKO_CERTIFICATE >>>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>>> CKA_CERTIFICATE_CATEGORY: 1 >>>>> CKA_VALUE: >>>>> >>>>> >>>>> to LDAP entries like this: >>>>> >>>>> dn: pkcs11uniqueId=, >>>>> objectClass: pkcs11storageObject >>>>> objectClass: pkiUser >>>>> pkcs11uniqueId: >>>>> userCertificate;binary: >>>>> >>>>> >>>>> and PKCS#11 object like this: >>>>> >>>>> CKA_CLASS: CKO_CERTIFICATE >>>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>>> CKA_CERTIFICATE_CATEGORY: 2 >>>>> CKA_VALUE: >>>>> >>>>> >>>>> to LDAP entries like this: >>>>> >>>>> dn: pkcs11uniqueId=, >>>>> objectClass: pkcs11storageObject >>>>> objectClass: pkiCA >>>>> pkcs11uniqueId: >>>>> caCertificate;binary: >>>>> >>>>> >>>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and >>>>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >>>> so you want to directly use the pkiUser|CA objectclass, that would be ok >>>>> >>>>>>> >>>>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>>>> for private keys? If so, can we use it? >>>>>> I didn't find any, the only keys in ldap I found is a definition for >>>>>> sshPublicKey for openssh. >>>>> >>>>> And even this schema is for public keys only :-) OK, nevermind then. >>>>> >>>>>>> >>>>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>>>> I'm going to need an object class for that. You can find the details >>>>>>> on CKO_NSS_TRUST at >>>>>>> . >>>>>>> >>>>>>> >>>> so this is a nss extension to pkcs11, not in the standard ? If we add trust >>>> objects, should the naming reflect this like pkcs11nss or >>>> pkcs11ext ? >>>>>>> >>>>>>> >>>>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>>>> there is going to be some redundancy. For example, public key value >>>>>>> can be extracted from private key value, so we don't need to store >>>>>>> both of the values. This can be bypassed by having separate object >>>>>>> classes for data and for metadata. For a key pair entry, the object >>>>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>>>> pkcs11publicKey, where privateKey is an object class with private key >>>>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>>>> entry would be visible as two separate objects (private key object and >>>>>>> public key object). >>>>>> I have not yet rewritten the objectcalss definition after the latest >>>>>> discussion, but I think if we have one structural objectclass >>>>>> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for >>>>>> publickey,privatekey, certificate where the attributes (maybe >>>>>> withexception of label, id) are optional there will be no redundancy, >>>>>> store only what is needed. >>>>>> you could use these aux objectclass also in other entries instead of >>>>>> using pkcs11storageObject. >>>>> >>>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I >>>>> think they should be optional in LDAP as well. >>>>> >>>>>>> >>>>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>>>> private key and public key value attributes), I think they all should >>>>>>> be single-valued. Comments on specific attributes: >>>>>>> >>>>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>>>>> attributes for these, for the sake of completeness >>>>>> in progress >>>>>>> >>>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>>>>> LDAP are always persistent, so there is no need for pkcs11token >>>>>> ok >>>>>>> >>>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>>>>> pkcs11certificateType >>>>>> ok >>>>>>> >>>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>>>> classes (see above), we don't need an LDAP attribute for it >>>>>> see above, where do you want to define the mapping. Do we then need >>>>>> cert attrs at all ? >>>>> >>>>> If we use userCertificate and cACertificate, we don't need >>>>> pkcs11certificateValue, if that's what you are asking. >>>> I was asking if we need the pkcs11certificate objectclass and the certificate >>>> metadata since you were using the pkiUser and pkiCA objectclasses to store >>>> the >>>> cert, but you probably want the startdate, enddate and other attrs at least >>>> available >>>>> >>>>>>> >>>>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>>>> certificate value, no need for LDAP attributes >>>>>> ok >>>>>>> >>>>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>>>> value? >>>>>> don't know, there are just some other attrs required when a URL is used >>>>> >>>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not required >>>>> AFAIK, it's just that URL-only certificates do not make much sense without >>>>> them. >>>>> >>>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty if >>>> CKA_URL >>>> >>>> is empty. >>> >>> I have a note about naming attribute: >>> - I don't like nsUniqId here because you can't read it in LDAP browser by >>> naked eye >>> - I propose to use >>> -- dn: CKA_CLASS=...+CKA_LABEL=... >>> -- dn: CKA_CLASS=...+CKA_ID=... >>> One of them should be present almost always and the writing 'entity' >>> (effectively PKCS#11 module generating a new key or storing a new >>> certificate) can fall back to uniqueId if there is neither LABEL nor ID. >>> >>> Honza told me that PKCS#11 module/user have to always do a LDAP search so >>> this change should be 'cosmetic'. >>> >>> We are not LDAP experts. Ludwig, what do you think about compound names? >>> Are they okay for general use? >> >> They are problematic. I would prefer to avoid having multi-component RDNs. > agreed, they are not very common. You can make any allowed attribute the > naming attribute, so you have the choice eg "dn: pkcs11label=....., ". It > should be some attr available in all the objects. You can also use the > suggested attribute pkcs11uniqueid and do not use the ipaUniqueid strings, but > soemthing readable. > We can als define an other attr which does not sound like uniqueid eg > pkcs11object[id|name|..] Okay. I have talked again with Honza about that and the current schema proposal combines public and private keys to one object so collision on LABEL or ID-level should not happen. Is it okay to mix objects with DNs like: pkcs11label=... pkcs11id=... pkcs11uniqid=... in one sub-tree? (Assuming that our client can handle that.) -- Petr^2 Spacek From rmeggins at redhat.com Thu Feb 27 21:15:45 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Feb 2014 14:15:45 -0700 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F9B9B.3090400@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F69B1.5050408@redhat.com> <530F6BEF.9080507@redhat.com> <530F6DF7.6090208@redhat.com> <530F9B9B.3090400@redhat.com> Message-ID: <530FAB01.4020408@redhat.com> On 02/27/2014 01:10 PM, Petr Spacek wrote: > On 27.2.2014 17:55, Ludwig Krispenz wrote: >> >> On 02/27/2014 05:46 PM, Rich Megginson wrote: >>> On 02/27/2014 09:37 AM, Petr Spacek wrote: >>>> On 27.2.2014 17:24, Ludwig Krispenz wrote: >>>>> >>>>> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>>>>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>>>>> >>>>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in >>>>>>>>>>>>>>> softhsm. >>>>>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>>>>> SoftHsm has >>>>>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>>>>> passes sets >>>>>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then >>>>>>>>>>>>>>> stores >>>>>>>>>>>>>>> it as >>>>>>>>>>>>>>> records in sql where each record has a keytype and >>>>>>>>>>>>>>> opaque blob of >>>>>>>>>>>>>>> data. >>>>>>>>>>>>>>> If that is what is wanted the decision would be how >>>>>>>>>>>>>>> fingrained the >>>>>>>>>>>>>>> pkcs >>>>>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: >>>>>>>>>>>>>>> one ldap >>>>>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP >>>>>>>>>>>>>> would be >>>>>>>>>>>>>> the most >>>>>>>>>>>>>> straightforward way of doing this, but I think we can do >>>>>>>>>>>>>> some >>>>>>>>>>>>>> optimization for our needs. For example, like you said >>>>>>>>>>>>>> above, we >>>>>>>>>>>>>> can >>>>>>>>>>>>>> use >>>>>>>>>>>>>> a single attribute containing PKCS#8 encoded private key >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> than >>>>>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think we need an LDAP attribute for every >>>>>>>>>>>>>> possible PKCS#11 >>>>>>>>>>>>>> attribute, ATM it would be sufficient to have just these >>>>>>>>>>>>>> attributes >>>>>>>>>>>>>> necessary to represent private key, public key and >>>>>>>>>>>>>> certificate >>>>>>>>>>>>>> objects. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, I would say it should be something between high-level >>>>>>>>>>>>>> and >>>>>>>>>>>>>> low-level. >>>>>>>>>>>>> >>>>>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>>>>> certificate. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>>>>> >>>>>>>>>>> Honzo, >>>>>>>>>>> >>>>>>>>>>> we really need the design page with some goal statement, >>>>>>>>>>> high-level >>>>>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>>>>> that we >>>>>>>>>>> want to use the same module for cert distribution and at the >>>>>>>>>>> same time >>>>>>>>>>> for DNSSEC key storage. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1, please do. We clearly need some design to start with. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> I already posted the link in other thread, but here it is anyway: >>>>>>>> . >>>>>>>> >>>>>>>> Some more comments on the schema: >>>>>>>> >>>>>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", >>>>>>>> "token >>>>>>>> user", "authority" and "other entity". We could map entries with >>>>>>>> object class pkiUser to certificate object with >>>>>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object >>>>>>>> class >>>>>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY >>>>>>>> "authority". >>>>>>>> There are no object classes in RFC 4523 for "unspecified" and >>>>>>>> "other >>>>>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>>>>> anyway, so I think it's OK. >>>>>>> not sure I understand what exactly you want here. If we don't store >>>>>>> certificates using the pkcs#11 schema we don't need to define >>>>>>> them, but >>>>>>> on the other hand you talk about the usage of >>>>>>> CKA_CERTIFICATE_CATEGORY. >>>>>>> Do you mean to have a pkcs11 cerificate object with >>>>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>>>>> userCertificate and cACertificate to store them ? >>>>>> >>>>>> Hopefully an example will better illustrate what I mean. We could >>>>>> map >>>>>> PKCS#11 objects like this: >>>>>> >>>>>> CKA_CLASS: CKO_CERTIFICATE >>>>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>>>> CKA_CERTIFICATE_CATEGORY: 1 >>>>>> CKA_VALUE: >>>>>> >>>>>> >>>>>> to LDAP entries like this: >>>>>> >>>>>> dn: pkcs11uniqueId=, >>>>>> objectClass: pkcs11storageObject >>>>>> objectClass: pkiUser >>>>>> pkcs11uniqueId: >>>>>> userCertificate;binary: >>>>>> >>>>>> >>>>>> and PKCS#11 object like this: >>>>>> >>>>>> CKA_CLASS: CKO_CERTIFICATE >>>>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>>>> CKA_CERTIFICATE_CATEGORY: 2 >>>>>> CKA_VALUE: >>>>>> >>>>>> >>>>>> to LDAP entries like this: >>>>>> >>>>>> dn: pkcs11uniqueId=, >>>>>> objectClass: pkcs11storageObject >>>>>> objectClass: pkiCA >>>>>> pkcs11uniqueId: >>>>>> caCertificate;binary: >>>>>> >>>>>> >>>>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied >>>>>> from >>>>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: >>>>>> pkiUser" and >>>>>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >>>>> so you want to directly use the pkiUser|CA objectclass, that would >>>>> be ok >>>>>> >>>>>>>> >>>>>>>> Also the above got me thinking, is there any "standard" LDAP >>>>>>>> schema >>>>>>>> for private keys? If so, can we use it? >>>>>>> I didn't find any, the only keys in ldap I found is a definition >>>>>>> for >>>>>>> sshPublicKey for openssh. >>>>>> >>>>>> And even this schema is for public keys only :-) OK, nevermind then. >>>>>> >>>>>>>> >>>>>>>> I'm going to store NSS trust objects along with CA >>>>>>>> certificates, so >>>>>>>> I'm going to need an object class for that. You can find the >>>>>>>> details >>>>>>>> on CKO_NSS_TRUST at >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>> so this is a nss extension to pkcs11, not in the standard ? If we >>>>> add trust >>>>> objects, should the naming reflect this like pkcs11nss or >>>>> pkcs11ext ? >>>>>>>> >>>>>>>> >>>>>>>> If we store multiple related PKCS#11 objects in a single LDAP >>>>>>>> entry, >>>>>>>> there is going to be some redundancy. For example, public key >>>>>>>> value >>>>>>>> can be extracted from private key value, so we don't need to store >>>>>>>> both of the values. This can be bypassed by having separate object >>>>>>>> classes for data and for metadata. For a key pair entry, the >>>>>>>> object >>>>>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>>>>> pkcs11publicKey, where privateKey is an object class with >>>>>>>> private key >>>>>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object >>>>>>>> class >>>>>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, >>>>>>>> this >>>>>>>> entry would be visible as two separate objects (private key >>>>>>>> object and >>>>>>>> public key object). >>>>>>> I have not yet rewritten the objectcalss definition after the >>>>>>> latest >>>>>>> discussion, but I think if we have one structural objectclass >>>>>>> pkcs11storageObject with only a uniqueid and auxiliary >>>>>>> objectclasses for >>>>>>> publickey,privatekey, certificate where the attributes (maybe >>>>>>> withexception of label, id) are optional there will be no >>>>>>> redundancy, >>>>>>> store only what is needed. >>>>>>> you could use these aux objectclass also in other entries >>>>>>> instead of >>>>>>> using pkcs11storageObject. >>>>>> >>>>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in >>>>>> PKCS#11, so I >>>>>> think they should be optional in LDAP as well. >>>>>> >>>>>>>> >>>>>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>>>>> private key and public key value attributes), I think they all >>>>>>>> should >>>>>>>> be single-valued. Comments on specific attributes: >>>>>>>> >>>>>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should >>>>>>>> be LDAP >>>>>>>> attributes for these, for the sake of completeness >>>>>>> in progress >>>>>>>> >>>>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and >>>>>>>> objects in >>>>>>>> LDAP are always persistent, so there is no need for pkcs11token >>>>>>> ok >>>>>>>> >>>>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no >>>>>>>> need for >>>>>>>> pkcs11certificateType >>>>>>> ok >>>>>>>> >>>>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 >>>>>>>> object >>>>>>>> classes (see above), we don't need an LDAP attribute for it >>>>>>> see above, where do you want to define the mapping. Do we then need >>>>>>> cert attrs at all ? >>>>>> >>>>>> If we use userCertificate and cACertificate, we don't need >>>>>> pkcs11certificateValue, if that's what you are asking. >>>>> I was asking if we need the pkcs11certificate objectclass and the >>>>> certificate >>>>> metadata since you were using the pkiUser and pkiCA objectclasses >>>>> to store >>>>> the >>>>> cert, but you probably want the startdate, enddate and other attrs >>>>> at least >>>>> available >>>>>> >>>>>>>> >>>>>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>>>>> certificate value, no need for LDAP attributes >>>>>>> ok >>>>>>>> >>>>>>>> * CKA_URL - do we want to support certificates with URL >>>>>>>> instead of >>>>>>>> value? >>>>>>> don't know, there are just some other attrs required when a URL >>>>>>> is used >>>>>> >>>>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not >>>>>> required >>>>>> AFAIK, it's just that URL-only certificates do not make much >>>>>> sense without >>>>>> them. >>>>>> >>>>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be >>>>> empty if >>>>> CKA_URL >>>>> >>>>> >>>>> is empty. >>>> >>>> I have a note about naming attribute: >>>> - I don't like nsUniqId here because you can't read it in LDAP >>>> browser by >>>> naked eye >>>> - I propose to use >>>> -- dn: CKA_CLASS=...+CKA_LABEL=... >>>> -- dn: CKA_CLASS=...+CKA_ID=... >>>> One of them should be present almost always and the writing 'entity' >>>> (effectively PKCS#11 module generating a new key or storing a new >>>> certificate) can fall back to uniqueId if there is neither LABEL >>>> nor ID. >>>> >>>> Honza told me that PKCS#11 module/user have to always do a LDAP >>>> search so >>>> this change should be 'cosmetic'. >>>> >>>> We are not LDAP experts. Ludwig, what do you think about compound >>>> names? >>>> Are they okay for general use? >>> >>> They are problematic. I would prefer to avoid having >>> multi-component RDNs. >> agreed, they are not very common. You can make any allowed attribute the >> naming attribute, so you have the choice eg "dn: pkcs11label=....., >> ". It >> should be some attr available in all the objects. You can also use the >> suggested attribute pkcs11uniqueid and do not use the ipaUniqueid >> strings, but >> soemthing readable. >> We can als define an other attr which does not sound like uniqueid eg >> pkcs11object[id|name|..] > > Okay. I have talked again with Honza about that and the current schema > proposal combines public and private keys to one object so collision > on LABEL or ID-level should not happen. > > Is it okay to mix objects with DNs like: > pkcs11label=... > pkcs11id=... > pkcs11uniqid=... > in one sub-tree? (Assuming that our client can handle that.) > That's fine. From rcritten at redhat.com Thu Feb 27 21:18:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Feb 2014 16:18:56 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530772AB.2060409@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> Message-ID: <530FABC0.3060601@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>> things >>>>>>>>>> now, >>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>> Foreman. >>>>>>>>>> >>>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>>> specific to >>>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>>> cases. If >>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>> similar. >>>>>>>>>> >>>>>>>>>> If general, we can go with >>>>>>>>>> >>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>> >>>>>>>>>> The proxies may share the framework and only expose the requested >>>>>>>>>> part of the >>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>> separation, as >>>>>>>>>> compared >>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>> >>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>> different servers, each providing a unique service? Or one service >>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>> envision >>>>>>>>> this as 3 separate subpackages? >>>>>>>>> >>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>> server >>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>> layers. >>>>>>>> >>>>>>>> >>>>>>>> Then it seems to make sense to have 3 different packages that >>>>>>>> can be >>>>>>>> optionally coninstalled and would probably share the same >>>>>>>> principal, >>>>>>>> keytab and local REST API socket/port. >>>>>>>> >>>>>>> >>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>> What >>>>>>> I designed is a quick-and-dirty get something up quickly. We need to >>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>> rework, though it will potentially pay dividends in the future. >>>>>> >>>>>> I think that we can start where you are but drive towards this >>>>>> architecture via refactoring. But we need to pick the right name now. >>>>>> Even if the architecture is not there yet we should name the >>>>>> package in >>>>>> such way that it does not preclude us from moving towards a clean >>>>>> architecture I described during the next iteration. >>>>> >>>>> Just having a hard time seeing the value. This would be like making >>>>> each of the IPA plugins a separate package and somehow installing them >>>>> individually. >>>>> >>>>> To do this you'd need at least 2 packages, a high level one with the >>>>> "framework" and then a separate one for each data type. >>>>> >>>>> This could also be achieved, and likely more cleanly, without all >>>>> these extra packages, as a simple configuration file. Once a package, >>>>> always a package. >>>>> >>>>> Maybe I'm too close to the problem, but to me this is a >>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>> don't know that anything else is using it. If you want a RESTful >>>>> server, then we enable REST in IPA directly, but selectively enabling >>>>> and disabling APIs is not something we've done before. It has been >>>>> controlled by ACIs instead. >>>>> >>>>> rob >>>>> >>>> >>>> We are trying to predict future here. Say we release it as you suggest. >>>> Tomorrow we point someone upstream who wants to add users to IPA from a >>>> similar proxy to this implementation and say use this as a model. >>>> And then Rich needs the same but for DNS for Designate. >>>> >>>> What would be the best? Rob if you knew that tomorrow two other >>>> developers will create similar proxies for users and DNS would you >>>> change anything? Would you provide some guidelines to them? >>>> If you are close to the problem you should be able to at least tell >>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>> If your recommendation is copy and paste then I suspect there will be >>>> challenges of running these proxies on the same machine - they will >>>> collide on ports and sockets. If we say "extend" shouldn't we use a >>>> more >>>> generic name? >>>> >>> >>> I'd say "use the existing IPA API". The only reason we have to write >>> the smartproxy at all is to interoperate with another service that >>> already has a well-defined remote server API which uses REST. >>> >>> rob >> OK, so you think that proxy is one off. OK I am fine with it. >> I was under assumption that it would be a beginning of a trend but I >> might be wrong as I do not have valid arguments to prove or disprove one >> way or another. >> I guess time would show. >> >> Any objections to Rob's approach? >> > > Ok, so try to summarize this long-running thread, I'll rename the > subpackage to freeipa-server-foreman-smartproxy to make it clearer what > it is/does. Right now it requires manual configuration so having the > package installed should have no negative impacts (other than > potentially pulling in additional dependencies). > > I'll leave it in smartproxy for now, it's just cleaner and better > integrates with ipatests IMHO. > > Foreman supports SSL client auth which is great, by cherrypy does not > yet. There is a pull request to add this, > https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity > . Foreman otherwise supports no other authentication method, so we're > blocked with this. The certs for this would initially come out of > Foreman/puppet. > > I'll submit a new patch with an updated spec but I think otherwise I've > addressed the isuses Petr has raised. This thread has taken a lot of > turns so it is very possible I missed something though :-) Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-6-rest.patch Type: text/x-patch Size: 47452 bytes Desc: not available URL: From npmccallum at redhat.com Thu Feb 27 22:44:32 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 27 Feb 2014 17:44:32 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework Message-ID: <1393541072.3562.19.camel@localhost.localdomain> So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? Nathaniel From npmccallum at redhat.com Thu Feb 27 22:56:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 27 Feb 2014 17:56:09 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393541072.3562.19.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> Message-ID: <1393541769.3562.20.camel@localhost.localdomain> On Thu, 2014-02-27 at 17:44 -0500, Nathaniel McCallum wrote: > So the recent discussion on importing tokens led me to write a script to > parse RFC 6030 xml files into IPA token data. This all works well. But > now I need to integrate it into the IPA framework. > > This command will parse one or more xml files, creating a set of tokens > to be added. Given that we already have otptoken-add on the server-side, > it seems to me that all work needs to be done on the client-side. How do > I create a new client-side command that calls existing server-side API? Also, would it be better to send the whole file to the server and do the parsing on the server side? Would this simplify UI implementation? Would we run into trouble with large files? Nathaniel From abokovoy at redhat.com Thu Feb 27 22:59:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 00:59:35 +0200 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393541072.3562.19.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> Message-ID: <20140227225935.GZ16644@redhat.com> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >So the recent discussion on importing tokens led me to write a script to >parse RFC 6030 xml files into IPA token data. This all works well. But >now I need to integrate it into the IPA framework. > >This command will parse one or more xml files, creating a set of tokens >to be added. Given that we already have otptoken-add on the server-side, >it seems to me that all work needs to be done on the client-side. How do >I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. -- / Alexander Bokovoy From rmeggins at redhat.com Thu Feb 27 23:29:56 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Feb 2014 16:29:56 -0700 Subject: [Freeipa-devel] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past In-Reply-To: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> References: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> Message-ID: <530FCA74.9040606@redhat.com> On 02/03/2014 10:37 PM, JR Aquino wrote: > If you are seeing clock skew errors in > /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you > will need to verify the time/date of the server to make sure NTP isn't > freaked out. If the system date is correct, it is possible that the > change number generator has skewed. Thanks much JR! I have wiki-fied this email http://port389.org/wiki/Howto:Fix_and_Reset_Time_Skew I would like to credit you on the page - how would you like to be attributed? > > [01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 > repl="dc=example,dc=com": Excessive clock skew from supplier RUV > [01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit > exceeded; value - 1448518, limit - 86400 > [01/Feb/2014:14:42:06 -0800] - CSN generator's state: > [01/Feb/2014:14:42:06 -0800] - replica id: 115 > [01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526 > [01/Feb/2014:14:42:06 -0800] - local offset: 0 > [01/Feb/2014:14:42:06 -0800] - remote offset: 0 > [01/Feb/2014:14:42:06 -0800] - sequence number: 55067 > > The following NsState_Script should be used to determine whether the > change number generator has jumped significantly from the real time/date. > https://github.com/richm/scripts/blob/master/readNsState.py > > > The usage for the script works like this: > > [root at ipaserver.ops jaquino]# ./readNsState.py > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > nsState is cwAAAAAAAABGPfBSAAAAAAAAAAAAAAAAAQAAAAAAAAACAAAAAAAAAA== > Little Endian > For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config > fmtstr=[H6x3QH6x] > size=40 > len of nsstate is 40 > CSN generator state: > Replica ID : 115 > Sampled Time : 1391476038 > Gen as csn : 52f03d46000201150000 > Time as str : Mon Feb 3 17:07:18 2014 > Local Offset : 0 > Remote Offset : 1 > Seq. num : 2 > System time : Mon Feb 3 17:09:11 2014 > Diff in sec. : 113 > Day:sec diff : 0:113 > > If the output from the above command is over a day or more out of > sync, then the reason is because the CSN generator has become grossly > skewed. It will be necessary to perform the following steps to recover. > > -------------------------------------------- > How to resolve this issue > > ? 1: Select an ipa server to be authoritative and write the contents > of its database to an ldif file > On the master supplier: > /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory > Manager' -w - -n userRoot -a /tmp/master-389.ldif > Note that without the -r option it is deliberately ommiting the > tainted replication data which contains the bad CSNs > > ? 2: On the ipa server, shutdown its dirsrv daemon down so that you > can reset the attribute responsible for the serial generation, and so > that you can re-initialize its db from the known good ldif > On the master supplier: > ipactl stop > > > ? 3: Sanitize the dse.ldif Configuration File > On the master supplier: > edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the > nsState attribute from the replica config entry > You DO NOT want to remove the nsState from: dn: cn=uniqueid > generator,cn=config > > The stanza you want to remove the value from is: dn: > cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > The attribute will look like this: nsState:: > cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== > Delete the entire line > > ? 3.1: Remove traces of stale CSN tracking in the Replica Agreements > themeselves > File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; > d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif > backup the old dse.ldif and replace it with the new one: > # mv dse.ldif dse.saved.ldif > # mv new.dse.ldif dse.ldif > > ? 4: Import the data from the known good ldif. This will mark all the > changes with CSNs that match the current time/date stamps > On the master supplier: > chmod 644 /tmp/master-389.ldif > /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i > /tmp/master-389.ldif > > ? 5: Restart the ipa daemons on the master supplier > #ipactl start > > ? 6: When the daemon starts, it will see that it does not have an > nsState and will write new CSN's to -all- of the newly imported good > data with today's timetamp, we need to take that data and write -it- > out to an ldif file > On the master supplier: > /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory > Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif > ^ the -r tells it to include all replica data which includes the > newly blessed CSN data > transfer the file to all of the ipa servers in the fleet > > ? 7: Now we must re-initialize _every other_ ipa consumer server in > the fleet with the new good data. > Steps 7-10 need to be done 1 at a time on each ipa consumer server > ipactl stop > > ? 8: Sanitize the dse.ldif Configuration File > On the ipa server: > edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the > nsState attribute from the replica config entry > You DO NOT want to remove the nsState from: dn: cn=uniqueid > generator,cn=config > The stanza you want to remove the value from is: dn: > cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > The attribute will look like this: nsState:: > cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== > Delete the entire line > > ? 8.1: Remove traces of stale CSN tracking in the Replica Agreements > themeselves > File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; > d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif > backup the old dse.ldif and replace it with the new one > # mv dse.ldif dse.saved.ldif > # mv new.dse.ldif dse.ldif > > ? 9: Import the data from the known good ldif. This will mark all the > changes with CSNs that match the current time/date stamps > On the auth server: > chmod 644 /tmp/replication-master-389.ldif > /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i > /tmp/replication-master-389.ldif > > ? 10: Restart the ipa daemons on the ipa server > On the ipa server: > ipactl start > > > -------------------------------- > > From Rich Megginson: > Further reading for those interested in the particulars of CSN > tracking or the MultiMaster Replication algorithm, you can read up > about it here: > > It all starts with the Leslie Lamport paper: > http://www.stanford.edu/class/cs240/readings/lamport.pdf > "Time, Clocks, and the Ordering of Events in a Distributed System" > > The next big impact on MMR protocols was the work done at Xerox PARC > on the Bayou project. > > These and other sources formed the basis of the IETF LDUP working > group. Much of the MMR protocol is based on the LDUP work. > > > The tl;dr version is this: > > The MMR protocol is based on ordering operations by time so that when > you have two updates to the same attribute, the "last one wins" > So how do you guarantee some sort of consistent ordering throughout > many systems that do not have clocks in sync down to the millisecond? > If you say "ntp" then you lose... > The protocol itself has to have some notion of time differences among > servers > The ordering is done by CSN (Change Sequence Number) > The first part of the CSN is the timestamp of the operation in unix > time_t (number of seconds since the epoch). > In order to guarantee ordering, the MMR protocol has a major constraint > You must never, never, issue a CSN that is the same or less than > another CSN > In order to guarantee that, the MMR protocol keeps track of the time > differences among _all_ of the servers that it knows about. > When it generates CSNs, it uses the largest time difference among all > servers that it knows about. > > So how does the time skew grow at all? > Due to timing differences, network latency, etc. the directory server > cannot always generate the absolute exact system time. There will > always be 1 or 2 second differences in some replication sessions. > These 1 to 2 second differences accumulate over time. > > However, there are things which can introduce really large differences > 1) buggy ntp implementations > 2) bad sysadmin screws up the system clock > 3) vms which are notorious for having laggy system clocks, etc. > > > How can you monitor for this in the future? > The readnsState.py script supplied in this email can be used to output > the effective skew of the system date vs the CSN generator. > You can set a crontab to run this script and monitor its output to > catch any future severe drifts. > > Ticket information for some of the fixes that have been implimented > because of this work so far: > https://fedorahosted.org/389/ticket/47516 > > > > "You cannot hope to secure that which you do not first understand" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > JR Aquino > > Senior Information Security Specialist, Technical Operations > T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 > GIAC Certified Exploit Researcher and Advanced Penetration Tester | > GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler > JR.Aquino at citrix.com > > > > Powering mobile workstyles and cloud services -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 15835 bytes Desc: not available URL: From rcritten at redhat.com Fri Feb 28 03:02:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Feb 2014 22:02:57 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <20140227225935.GZ16644@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> Message-ID: <530FFC61.9060001@redhat.com> Alexander Bokovoy wrote: > On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >> So the recent discussion on importing tokens led me to write a script to >> parse RFC 6030 xml files into IPA token data. This all works well. But >> now I need to integrate it into the IPA framework. >> >> This command will parse one or more xml files, creating a set of tokens >> to be added. Given that we already have otptoken-add on the server-side, >> it seems to me that all work needs to be done on the client-side. How do >> I create a new client-side command that calls existing server-side API? > subclass from frontend.Local, override run() or forward() method and > perform batch > operation of otptoken_add from there. > > See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob From mkosek at redhat.com Fri Feb 28 07:28:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Feb 2014 08:28:30 +0100 Subject: [Freeipa-devel] DNSSEC design page In-Reply-To: <530F6BEF.9080507@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <53037AEF.7060101@redhat.com> <53037CB8.3080703@redhat.com> <53037DB6.80406@redhat.com> <53037E6D.1070701@redhat.com> <53038820.8060309@redhat.com> <530F3A4E.8070400@redhat.com> <530F4A53.80309@redhat.com> <530F5201.10303@redhat.com> <530F66B6.6000301@redhat.com> <530F69B1.5050408@redhat.com> <530F6BEF.9080507@redhat.com> Message-ID: <53103A9E.1030308@redhat.com> On 02/27/2014 05:46 PM, Rich Megginson wrote: > On 02/27/2014 09:37 AM, Petr Spacek wrote: >> On 27.2.2014 17:24, Ludwig Krispenz wrote: >>> >>> On 02/27/2014 03:56 PM, Jan Cholasta wrote: >>>> On 27.2.2014 15:23, Ludwig Krispenz wrote: >>>>> >>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote: >>>>>> On 18.2.2014 17:19, Martin Kosek wrote: >>>>>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote: >>>>>>>> On 18.2.2014 16:35, Petr Spacek wrote: >>>>>>>>> On 18.2.2014 16:31, Jan Cholasta wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2] low level replacement for eg the sqlite3 database in softhsm. >>>>>>>>>>>>> That's what I sometimes get the impression what is wanted. >>>>>>>>>>>>> SoftHsm has >>>>>>>>>>>>> one component Softdatabase with an API, which more or less >>>>>>>>>>>>> passes sets >>>>>>>>>>>>> of attributes (attributes defined by PKCS#11) and then stores >>>>>>>>>>>>> it as >>>>>>>>>>>>> records in sql where each record has a keytype and opaque blob of >>>>>>>>>>>>> data. >>>>>>>>>>>>> If that is what is wanted the decision would be how fingrained the >>>>>>>>>>>>> pkcs >>>>>>>>>>>>> objects/attribute types would have to be mapped to ldap: one ldap >>>>>>>>>>>>> attribute for each possible attribute type ? >>>>>>>>>>>> >>>>>>>>>>>> One-to-one mapping of attributes from PKCS#11 to LDAP would be >>>>>>>>>>>> the most >>>>>>>>>>>> straightforward way of doing this, but I think we can do some >>>>>>>>>>>> optimization for our needs. For example, like you said above, we >>>>>>>>>>>> can >>>>>>>>>>>> use >>>>>>>>>>>> a single attribute containing PKCS#8 encoded private key rather >>>>>>>>>>>> than >>>>>>>>>>>> using one attribute per private key component. >>>>>>>>>>>> >>>>>>>>>>>> I don't think we need an LDAP attribute for every possible PKCS#11 >>>>>>>>>>>> attribute, ATM it would be sufficient to have just these attributes >>>>>>>>>>>> necessary to represent private key, public key and certificate >>>>>>>>>>>> objects. >>>>>>>>>>>> >>>>>>>>>>>> So, I would say it should be something between high-level and >>>>>>>>>>>> low-level. >>>>>>>>>>> >>>>>>>>>>> There won't be a separate public key, it's represented by the >>>>>>>>>>> certificate. >>>>>>>>>> >>>>>>>>>> I'm not sure if this is the case for DNSSEC. >>>>>>>>> >>>>>>>>> Honzo, >>>>>>>>> >>>>>>>>> we really need the design page with some goal statement, high-level >>>>>>>>> overview etc. There is still some confusion, probably from fact >>>>>>>>> that we >>>>>>>>> want to use the same module for cert distribution and at the same time >>>>>>>>> for DNSSEC key storage. >>>>>>>>> >>>>>>>> >>>>>>>> It's on my TODO list, I'll try to get it out ASAP. >>>>>>>> >>>>>>> >>>>>>> +1, please do. We clearly need some design to start with. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I already posted the link in other thread, but here it is anyway: >>>>>> . >>>>>> >>>>>> Some more comments on the schema: >>>>>> >>>>>> I think I may have been too quick to dismiss RFC 4523. There is >>>>>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token >>>>>> user", "authority" and "other entity". We could map entries with >>>>>> object class pkiUser to certificate object with >>>>>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class >>>>>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". >>>>>> There are no object classes in RFC 4523 for "unspecified" and "other >>>>>> entity", but we will not be storing any certificates using PKCS#11 >>>>>> anyway, so I think it's OK. >>>>> not sure I understand what exactly you want here. If we don't store >>>>> certificates using the pkcs#11 schema we don't need to define them, but >>>>> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. >>>>> Do you mean to have a pkcs11 cerificate object with >>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes >>>>> userCertificate and cACertificate to store them ? >>>> >>>> Hopefully an example will better illustrate what I mean. We could map >>>> PKCS#11 objects like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 1 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiUser >>>> pkcs11uniqueId: >>>> userCertificate;binary: >>>> >>>> >>>> and PKCS#11 object like this: >>>> >>>> CKA_CLASS: CKO_CERTIFICATE >>>> CKA_CERTIFICATE_TYPE: CKC_X_509 >>>> CKA_CERTIFICATE_CATEGORY: 2 >>>> CKA_VALUE: >>>> >>>> >>>> to LDAP entries like this: >>>> >>>> dn: pkcs11uniqueId=, >>>> objectClass: pkcs11storageObject >>>> objectClass: pkiCA >>>> pkcs11uniqueId: >>>> caCertificate;binary: >>>> >>>> >>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from >>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and >>>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA". >>> so you want to directly use the pkiUser|CA objectclass, that would be ok >>>> >>>>>> >>>>>> Also the above got me thinking, is there any "standard" LDAP schema >>>>>> for private keys? If so, can we use it? >>>>> I didn't find any, the only keys in ldap I found is a definition for >>>>> sshPublicKey for openssh. >>>> >>>> And even this schema is for public keys only :-) OK, nevermind then. >>>> >>>>>> >>>>>> I'm going to store NSS trust objects along with CA certificates, so >>>>>> I'm going to need an object class for that. You can find the details >>>>>> on CKO_NSS_TRUST at >>>>>> . >>>>>> >>>>>> >>> so this is a nss extension to pkcs11, not in the standard ? If we add trust >>> objects, should the naming reflect this like pkcs11nss or >>> pkcs11ext ? >>>>>> >>>>>> >>>>>> If we store multiple related PKCS#11 objects in a single LDAP entry, >>>>>> there is going to be some redundancy. For example, public key value >>>>>> can be extracted from private key value, so we don't need to store >>>>>> both of the values. This can be bypassed by having separate object >>>>>> classes for data and for metadata. For a key pair entry, the object >>>>>> classes would be e.g. privateKey, pkcs11privateKey and >>>>>> pkcs11publicKey, where privateKey is an object class with private key >>>>>> data (without any PKCS#11 bits), pkcs11privateKey is an object class >>>>>> with PKCS#11 private key metadata and pkcs11publicKey is an object >>>>>> class with PKCS#11 public key metadata. In the PKCS#11 module, this >>>>>> entry would be visible as two separate objects (private key object and >>>>>> public key object). >>>>> I have not yet rewritten the objectcalss definition after the latest >>>>> discussion, but I think if we have one structural objectclass >>>>> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for >>>>> publickey,privatekey, certificate where the attributes (maybe >>>>> withexception of label, id) are optional there will be no redundancy, >>>>> store only what is needed. >>>>> you could use these aux objectclass also in other entries instead of >>>>> using pkcs11storageObject. >>>> >>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I >>>> think they should be optional in LDAP as well. >>>> >>>>>> >>>>>> Regarding PKCS#11 metadata attributes (i.e. excluding certificate, >>>>>> private key and public key value attributes), I think they all should >>>>>> be single-valued. Comments on specific attributes: >>>>>> >>>>>> * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, >>>>>> CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, >>>>>> CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, >>>>>> CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, >>>>>> CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP >>>>>> attributes for these, for the sake of completeness >>>>> in progress >>>>>> >>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in >>>>>> LDAP are always persistent, so there is no need for pkcs11token >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for >>>>>> pkcs11certificateType >>>>> ok >>>>>> >>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object >>>>>> classes (see above), we don't need an LDAP attribute for it >>>>> see above, where do you want to define the mapping. Do we then need >>>>> cert attrs at all ? >>>> >>>> If we use userCertificate and cACertificate, we don't need >>>> pkcs11certificateValue, if that's what you are asking. >>> I was asking if we need the pkcs11certificate objectclass and the certificate >>> metadata since you were using the pkiUser and pkiCA objectclasses to store the >>> cert, but you probably want the startdate, enddate and other attrs at least >>> available >>>> >>>>>> >>>>>> * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, >>>>>> CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from >>>>>> certificate value, no need for LDAP attributes >>>>> ok >>>>>> >>>>>> * CKA_URL - do we want to support certificates with URL instead of >>>>>> value? >>>>> don't know, there are just some other attrs required when a URL is used >>>> >>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not required >>>> AFAIK, it's just that URL-only certificates do not make much sense without >>>> them. >>>> >>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty if >>> CKA_URL >>> is empty. >> >> I have a note about naming attribute: >> - I don't like nsUniqId here because you can't read it in LDAP browser by >> naked eye >> - I propose to use >> -- dn: CKA_CLASS=...+CKA_LABEL=... >> -- dn: CKA_CLASS=...+CKA_ID=... >> One of them should be present almost always and the writing 'entity' >> (effectively PKCS#11 module generating a new key or storing a new >> certificate) can fall back to uniqueId if there is neither LABEL nor ID. >> >> Honza told me that PKCS#11 module/user have to always do a LDAP search so >> this change should be 'cosmetic'. >> >> We are not LDAP experts. Ludwig, what do you think about compound names? Are >> they okay for general use? > > They are problematic. I would prefer to avoid having multi-component RDNs. +1, I would prefer that as well if possible - it seems to me as very unusual and hard-to-grasp way of making a DN. I am also thinking we might not have a support of multi-component RDNs in FreeIPA framework either, making it even more difficult to prepare a support for it. Martin From mkosek at redhat.com Fri Feb 28 08:51:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Feb 2014 09:51:56 +0100 Subject: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall In-Reply-To: <20140226114000.GE16644@redhat.com> References: <530C8ADD.9030803@redhat.com> <20140225181503.GY16644@redhat.com> <530DD055.3000809@redhat.com> <20140226114000.GE16644@redhat.com> Message-ID: <53104E2C.6060606@redhat.com> On 02/26/2014 12:40 PM, Alexander Bokovoy wrote: > On Wed, 26 Feb 2014, Martin Kosek wrote: >> On 02/25/2014 07:15 PM, Alexander Bokovoy wrote: >>> On Tue, 25 Feb 2014, Tomas Babej wrote: >>>> Hi, >>>> >>>> As a part of a better cleanup procedure in the integration tests, >>>> make sure that winbindd is not running after uninstalling the IPA >>>> server. >>> Better patch 0140 attached. We simply need to stop and disable winbind in >>> adtrustinstance.uninstall() >> >> Looks good to me (and a better approach than Tomas' 155 it seems). Since you >> are touching this section anyway, can you please also replace bare except with >> "except Exception:"? >> >> It will allow admin to CTRL+C the stopping process when needed. > Sure, new patch is attached. There are two potentially long external > processes executed in the uninstall() so I changed to 'except > Exception:' in both. > This is fine - ACK. I just removed the note about superseded Tomas' patch from your commit log, we do not need that note from git log history perspective. Pushed to master: e99fa380af7f257a319cbe6f8867bf258ab04e41 Martin From pspacek at redhat.com Fri Feb 28 09:11:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Feb 2014 10:11:00 +0100 Subject: [Freeipa-devel] Fwd: access control in PCSC - does it apply to PKCS#11? In-Reply-To: <2173047.YH2nb9NOWo@rezza-2ng> References: <2173047.YH2nb9NOWo@rezza-2ng> Message-ID: <531052A4.8030207@redhat.com> Hello list, Proposal for access control related to PC/SC smart cards follows. I have no idea if it applies to PKCS#11 or not but I think somebody knowledgeable in this area should look into it ... I'm sorry Honza :-) Petr^2 Spacek -------- Original Message -------- Subject: F21 System Wide Change: Access control in PCSC Date: Thu, 27 Feb 2014 16:59:14 +0100 From: Jaroslav Reznik Reply-To: devel at lists.fedoraproject.org Organization: Red Hat, Inc. To: devel-announce at lists.fedoraproject.org = Proposed System Wide Change: Access control in PCSC = https://fedoraproject.org/wiki/Changes/PcscAccessControl Change owner(s): Nikos Mavrogiannopoulos Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware. == Detailed Description == Add access control to PC/SC smart cards available in the system. Currently smart cards may provide their own access control for certain elements of a card such as a private key. Their access control method is typically a PIN, but can also be a biometric based one. That however, is not sufficient to prevent certain actions on the non-PIN protected elements. For example cards that provide a PKCS #15 filesystem can be modified by anyone that has access in the system (e.g., erased using pkcs15-init -E). The default settings allowed should be similar to the default settings for hard disks, i.e., root and the user in console should be able to access the smart card. Adding access control would * prevent unauthorized processes/users from reading data on a smart card * prevent unauthorized processes/users from erasing a smart card * prevent unauthorized processes/users from talking to the smart card firmware The way access control will be implemented is using polkit which is already being used to control access to hard disks. As smart cards share a lot with hard disks (e.g., a filesystem, and are inserted by the console user), sharing the same access control method is beneficial. == Scope == polkit support has to be added to PC/SC daemon. An initial version has already been developed and communicated upstream * Proposal owners: The polkit support has to be merged with the Fedora package. That requires changes to the pcsc daemon only, but indirectly all packages that potentially may use smart cards are affected (opensc, firefox, ...). * Other developers: Packages that use PC/SC smart cards must be checked that they work as expected after the access control change. * Release engineering: No coordination is required. * Policies and guidelines: If there is any security policy documentation should be updated to include the new policies on smart cards (I couldn't find any such documentation though) From pviktori at redhat.com Fri Feb 28 09:42:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 10:42:15 +0100 Subject: [Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof Message-ID: <531059F7.30009@redhat.com> Hello, Here is an additional part for the multivalued target filters: making --memberof also multivalued. http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions https://fedorahosted.org/freeipa/ticket/4074 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0479-permission-plugin-Allow-multiple-values-for-memberof.patch Type: text/x-patch Size: 8793 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 28 09:47:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 10:47:15 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530FABC0.3060601@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> Message-ID: <53105B23.7060801@redhat.com> On 02/27/2014 10:18 PM, Rob Crittenden wrote: > Rob Crittenden wrote: [...] >> Ok, so try to summarize this long-running thread, I'll rename the >> subpackage to freeipa-server-foreman-smartproxy to make it clearer what >> it is/does. Right now it requires manual configuration so having the >> package installed should have no negative impacts (other than >> potentially pulling in additional dependencies). >> >> I'll leave it in smartproxy for now, it's just cleaner and better >> integrates with ipatests IMHO. >> >> Foreman supports SSL client auth which is great, by cherrypy does not >> yet. There is a pull request to add this, >> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >> >> . Foreman otherwise supports no other authentication method, so we're >> blocked with this. The certs for this would initially come out of >> Foreman/puppet. >> >> I'll submit a new patch with an updated spec but I think otherwise I've >> addressed the isuses Petr has raised. This thread has taken a lot of >> turns so it is very possible I missed something though :-) > > Updated patch based on feedback from Foreman team. I added a new URI, > /features, which Foreman uses to determine what capabilities a proxy has. > > rob My review is blocked because 389-ds doesn't install on Rawhide due to https://fedorahosted.org/389/ticket/47700 Noriko, do you know of a Rawhide build that includes your fix? -- Petr? From pvoborni at redhat.com Fri Feb 28 09:47:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 28 Feb 2014 10:47:19 +0100 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <530FFC61.9060001@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> Message-ID: <53105B27.4070003@redhat.com> On 28.2.2014 04:02, Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>> So the recent discussion on importing tokens led me to write a script to >>> parse RFC 6030 xml files into IPA token data. This all works well. But >>> now I need to integrate it into the IPA framework. >>> >>> This command will parse one or more xml files, creating a set of tokens >>> to be added. Given that we already have otptoken-add on the server-side, >>> it seems to me that all work needs to be done on the client-side. How do >>> I create a new client-side command that calls existing server-side API? >> subclass from frontend.Local, override run() or forward() method and >> perform batch >> operation of otptoken_add from there. >> >> See cli.help, for example. > > If you do an override, do forward() for cli-specific work. > > But you should do as little as possible for reasons you already stated: > the UI. Anything you do in forward Petr will need to implement in the UI. > > Unfortunately we don't yet have a nice way to handle files. We have > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > https://fedorahosted.org/freeipa/ticket/2933 > > If this file is something that would be pasted into a big text field > then you can probably handle it in a similarly clumsy way that we do > CSRs in the cert plugin. > > rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. -- Petr Vobornik From jcholast at redhat.com Fri Feb 28 10:09:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 28 Feb 2014 11:09:07 +0100 Subject: [Freeipa-devel] Fwd: access control in PCSC - does it apply to PKCS#11? In-Reply-To: <531052A4.8030207@redhat.com> References: <2173047.YH2nb9NOWo@rezza-2ng> <531052A4.8030207@redhat.com> Message-ID: <53106043.1050509@redhat.com> Hi, On 28.2.2014 10:11, Petr Spacek wrote: > Hello list, > > Proposal for access control related to PC/SC smart cards follows. > > I have no idea if it applies to PKCS#11 or not but I think somebody > knowledgeable in this area should look into it ... > > I'm sorry Honza :-) Don't be, this seems to be related to PKCS#15 and PC/SC daemon only, neither of which are we going to interact with whatsoever (correct me if I'm wrong). > > Petr^2 Spacek > > -------- Original Message -------- > Subject: F21 System Wide Change: Access control in PCSC > Date: Thu, 27 Feb 2014 16:59:14 +0100 > From: Jaroslav Reznik > Reply-To: devel at lists.fedoraproject.org > Organization: Red Hat, Inc. > To: devel-announce at lists.fedoraproject.org > > = Proposed System Wide Change: Access control in PCSC = > https://fedoraproject.org/wiki/Changes/PcscAccessControl > > Change owner(s): Nikos Mavrogiannopoulos > > Add access control to PC/SC smart cards available in the system. Adding > access > control would (a) prevent unauthorized processes/users from reading data > on a > smart card, (b) prevent unauthorized processes/users from erasing a smart > card, (c) prevent unauthorized processes/users from talking to the smart > card > firmware. > > == Detailed Description == > Add access control to PC/SC smart cards available in the system. Currently > smart cards may provide their own access control for certain elements of a > card such as a private key. Their access control method is typically a PIN, > but can also be a biometric based one. That however, is not sufficient to > prevent certain actions on the non-PIN protected elements. For example > cards > that provide a PKCS #15 filesystem can be modified by anyone that has > access in > the system (e.g., erased using pkcs15-init -E). > > The default settings allowed should be similar to the default settings for > hard disks, i.e., root and the user in console should be able to access the > smart card. > > Adding access control would > * prevent unauthorized processes/users from reading data on a smart card > * prevent unauthorized processes/users from erasing a smart card > * prevent unauthorized processes/users from talking to the smart card > firmware > > The way access control will be implemented is using polkit which is already > being used to control access to hard disks. As smart cards share a lot with > hard disks (e.g., a filesystem, and are inserted by the console user), > sharing > the same access control method is beneficial. > > == Scope == > polkit support has to be added to PC/SC daemon. An initial version has > already > been developed and communicated upstream > > * Proposal owners: The polkit support has to be merged with the Fedora > package. That requires changes to the pcsc daemon only, but indirectly all > packages that potentially may use smart cards are affected (opensc, > firefox, > ...). > > * Other developers: Packages that use PC/SC smart cards must be checked > that > they work as expected after the access control change. > > * Release engineering: No coordination is required. > > * Policies and guidelines: If there is any security policy documentation > should be updated to include the new policies on smart cards (I couldn't > find > any such documentation though) -- Jan Cholasta From tbordaz at redhat.com Fri Feb 28 10:37:59 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 28 Feb 2014 11:37:59 +0100 Subject: [Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553) In-Reply-To: <530F6984.8050300@redhat.com> References: <530F5DC4.9050909@redhat.com> <530F6984.8050300@redhat.com> Message-ID: <53106707.6040708@redhat.com> HI Ludwig, Thanks for catching that, I will update the doc. When the legacy server receives an aci with that new syntax, it does not recognize the new keywords (moddn, target_to, target_from) so the parser fails and the aci is simply ignored. In the implementation (__aclp__parse_ac) , 'target_to' and 'target_from' should be tested before 'target' because the way it is coded 'target_to'/'target_from' could be interpreted as 'target' keyword. regards thierry On 02/27/2014 05:36 PM, Ludwig Krispenz wrote: > Hi, > > in the replication section you describe the behaviour when replicating > to older versions of ds, but this is for n1, how about the new design ? > > Ludwig > On 02/27/2014 04:46 PM, thierry bordaz wrote: >> Hello, >> >> Thanks to all your feedbacks, they helped me a lot and raised a >> severe limitation in the original design. >> I updated the design following the aci syntax proposed during the >> discussion. >> On the implementation side, it is a bit more complex but less than I >> expected. I have not yet investigated the impact of ger operations. >> >> I think a big work will be the test side as the ACI syntax provides >> many options. >> >> http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation >> >> Note: I kept for the moment the original design in 'alternative no1'. >> >> regards >> thierry >> >> >> _______________________________________________ >> 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 sbose at redhat.com Fri Feb 28 10:53:53 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 28 Feb 2014 11:53:53 +0100 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed Message-ID: <20140228105353.GH2710@localhost.localdomain> Hi, I just tried to install FreeIPA on a fresh F20 VM and 'ipa-server-install --setup-dns' failed to start FreeIPA finally after everything was configured. The reason was that starting named timed out because generate-rndc-key.sh was basically blocking because there was no entropy for /dev/random left to generate a proper key. I wonder if it would make sense to call generate-rndc-key.sh during ipa-server-install if --setup-dns is given to avoid this. bye, Sumit From pspacek at redhat.com Fri Feb 28 10:59:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Feb 2014 11:59:57 +0100 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <20140228105353.GH2710@localhost.localdomain> References: <20140228105353.GH2710@localhost.localdomain> Message-ID: <53106C2D.2070502@redhat.com> On 28.2.2014 11:53, Sumit Bose wrote: > Hi, > > I just tried to install FreeIPA on a fresh F20 VM and > 'ipa-server-install --setup-dns' failed to start FreeIPA finally after > everything was configured. > > The reason was that starting named timed out because > generate-rndc-key.sh was basically blocking because there was no entropy > for /dev/random left to generate a proper key. I wonder if it would make > sense to call generate-rndc-key.sh during ipa-server-install if > --setup-dns is given to avoid this. We can do it but it will only shift the problem to different place. In the past the key was generated in RPM posttrans but it was removed from there because sometimes it blocked RPM for very very long time. -- Petr^2 Spacek From abokovoy at redhat.com Fri Feb 28 11:09:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 13:09:23 +0200 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <20140228105353.GH2710@localhost.localdomain> References: <20140228105353.GH2710@localhost.localdomain> Message-ID: <20140228110923.GB16644@redhat.com> On Fri, 28 Feb 2014, Sumit Bose wrote: >Hi, > >I just tried to install FreeIPA on a fresh F20 VM and >'ipa-server-install --setup-dns' failed to start FreeIPA finally after >everything was configured. > >The reason was that starting named timed out because >generate-rndc-key.sh was basically blocking because there was no entropy >for /dev/random left to generate a proper key. I wonder if it would make >sense to call generate-rndc-key.sh during ipa-server-install if >--setup-dns is given to avoid this. Let the administrators solve this problem for their VMs. Qemu provides virtualization for RNG already that allows you to push entropy from the host system where you can use hardware generators like in new Intel systems. For example, I'm using following hook in oVirt to provide entropy for my virtual machines: $ cat /usr/libexec/vdsm/hooks/before_vm_start/99_hwrng #!/usr/bin/python import os import sys import traceback import hooking if True: try: domxml = hooking.read_domxml() domain = domxml.getElementsByTagName('devices')[0] # Add hugepages to libvirt xml hwrng = domxml.createElement('rng') hwrng.setAttribute('model', 'virtio') rate = domxml.createElement('rate') rate.setAttribute('period', '8192') rate.setAttribute('bytes', '8192') hwrng.appendChild(rate) backend = domxml.createElement('backend') backend.setAttribute('model', 'random') hwrng.appendChild(backend) domain.appendChild(hwrng) hooking.write_domxml(domxml) except: sys.stderr.write('rng: [unexpected error]: %s\n' % traceback.format_exc()) sys.exit(2) See http://wiki.qemu-project.org/Features/VirtIORNG and http://libvirt.org/formatdomain.html#elementsRng -- / Alexander Bokovoy From sbose at redhat.com Fri Feb 28 11:10:21 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 28 Feb 2014 12:10:21 +0100 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <53106C2D.2070502@redhat.com> References: <20140228105353.GH2710@localhost.localdomain> <53106C2D.2070502@redhat.com> Message-ID: <20140228111021.GJ2710@localhost.localdomain> On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: > On 28.2.2014 11:53, Sumit Bose wrote: > >Hi, > > > >I just tried to install FreeIPA on a fresh F20 VM and > >'ipa-server-install --setup-dns' failed to start FreeIPA finally after > >everything was configured. > > > >The reason was that starting named timed out because > >generate-rndc-key.sh was basically blocking because there was no entropy > >for /dev/random left to generate a proper key. I wonder if it would make > >sense to call generate-rndc-key.sh during ipa-server-install if > >--setup-dns is given to avoid this. > > We can do it but it will only shift the problem to different place. yes, but if we do it during ipa-server-install we have it under control and can give a hint that this step needs entropy, might need a long time and the user might help by producing additional network or disk I/O. bye, Sumit > In the past the key was generated in RPM posttrans but it was > removed from there because sometimes it blocked RPM for very very > long time. > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Fri Feb 28 11:41:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Feb 2014 12:41:59 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53105B23.7060801@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> Message-ID: <53107607.1010403@redhat.com> On 02/28/2014 10:47 AM, Petr Viktorin wrote: > On 02/27/2014 10:18 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: > [...] >>> Ok, so try to summarize this long-running thread, I'll rename the >>> subpackage to freeipa-server-foreman-smartproxy to make it clearer what >>> it is/does. Right now it requires manual configuration so having the >>> package installed should have no negative impacts (other than >>> potentially pulling in additional dependencies). >>> >>> I'll leave it in smartproxy for now, it's just cleaner and better >>> integrates with ipatests IMHO. >>> >>> Foreman supports SSL client auth which is great, by cherrypy does not >>> yet. There is a pull request to add this, >>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>> >>> >>> . Foreman otherwise supports no other authentication method, so we're >>> blocked with this. The certs for this would initially come out of >>> Foreman/puppet. >>> >>> I'll submit a new patch with an updated spec but I think otherwise I've >>> addressed the isuses Petr has raised. This thread has taken a lot of >>> turns so it is very possible I missed something though :-) >> >> Updated patch based on feedback from Foreman team. I added a new URI, >> /features, which Foreman uses to determine what capabilities a proxy has. >> >> rob > > My review is blocked because 389-ds doesn't install on Rawhide due to > https://fedorahosted.org/389/ticket/47700 > > Noriko, do you know of a Rawhide build that includes your fix? Guys, if this patch still makes our master branch incompatible with F20, then it is a NACK from me. All developers run on F20, our CI runs on F20 and I do not think we can afford loosing that and forcing everyone to permanently switch to rawhide - it is too unstable. IMO the Requires and BuildRequires most be set so that RPMs are buildable and installable on F20. The only acceptable exception is when only freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise everything else need to work. Thanks, Martin From pviktori at redhat.com Fri Feb 28 11:59:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 12:59:57 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53107607.1010403@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> <53107607.1010403@redhat.com> Message-ID: <53107A3D.6010200@redhat.com> On 02/28/2014 12:41 PM, Martin Kosek wrote: > On 02/28/2014 10:47 AM, Petr Viktorin wrote: >> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >> [...] >>>> Ok, so try to summarize this long-running thread, I'll rename the >>>> subpackage to freeipa-server-foreman-smartproxy to make it clearer what >>>> it is/does. Right now it requires manual configuration so having the >>>> package installed should have no negative impacts (other than >>>> potentially pulling in additional dependencies). >>>> >>>> I'll leave it in smartproxy for now, it's just cleaner and better >>>> integrates with ipatests IMHO. >>>> >>>> Foreman supports SSL client auth which is great, by cherrypy does not >>>> yet. There is a pull request to add this, >>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>>> >>>> >>>> . Foreman otherwise supports no other authentication method, so we're >>>> blocked with this. The certs for this would initially come out of >>>> Foreman/puppet. >>>> >>>> I'll submit a new patch with an updated spec but I think otherwise I've >>>> addressed the isuses Petr has raised. This thread has taken a lot of >>>> turns so it is very possible I missed something though :-) >>> >>> Updated patch based on feedback from Foreman team. I added a new URI, >>> /features, which Foreman uses to determine what capabilities a proxy has. >>> >>> rob >> >> My review is blocked because 389-ds doesn't install on Rawhide due to >> https://fedorahosted.org/389/ticket/47700 >> >> Noriko, do you know of a Rawhide build that includes your fix? > > Guys, if this patch still makes our master branch incompatible with F20, then > it is a NACK from me. All developers run on F20, our CI runs on F20 and I do > not think we can afford loosing that and forcing everyone to permanently switch > to rawhide - it is too unstable. > > IMO the Requires and BuildRequires most be set so that RPMs are buildable and > installable on F20. The only acceptable exception is when only > freeipa-server-foreman-smartprox cannot be installed on F20, but otherwise > everything else need to work. > > Thanks, > Martin > Okay, it's not a BuildRequires; IPA doesn't build because of a lint failure: ipalib/util.py - Module 'kerberos' has no 'authGSSClientInquireCred' member I guess the new get_current_principal needs to be kept out of ipalib until we move to f21. Until then we can have a lint exception; after then we need to remove it, and add BuildRequires so lint passes. -- Petr? From pviktori at redhat.com Fri Feb 28 12:11:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 13:11:20 +0100 Subject: [Freeipa-devel] [PATCH] 0480 Message-ID: <53107CE8.1060403@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/4206 Apply on top of my patch 0479, to avoid a conflict in tests. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0480-permissions-plugin-Don-t-crash-with-empty-targetfilt.patch Type: text/x-patch Size: 3391 bytes Desc: not available URL: From pviktori at redhat.com Fri Feb 28 12:13:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 13:13:13 +0100 Subject: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter In-Reply-To: <53107CE8.1060403@redhat.com> References: <53107CE8.1060403@redhat.com> Message-ID: <53107D59.3020109@redhat.com> Fixing the subject On 02/28/2014 01:11 PM, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/4206 > > Apply on top of my patch 0479, to avoid a conflict in tests. -- Petr? From pspacek at redhat.com Fri Feb 28 12:14:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Feb 2014 13:14:58 +0100 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <20140228111021.GJ2710@localhost.localdomain> References: <20140228105353.GH2710@localhost.localdomain> <53106C2D.2070502@redhat.com> <20140228111021.GJ2710@localhost.localdomain> Message-ID: <53107DC2.1000000@redhat.com> On 28.2.2014 12:10, Sumit Bose wrote: > On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: >> On 28.2.2014 11:53, Sumit Bose wrote: >>> I just tried to install FreeIPA on a fresh F20 VM and >>> 'ipa-server-install --setup-dns' failed to start FreeIPA finally after >>> everything was configured. >>> >>> The reason was that starting named timed out because >>> generate-rndc-key.sh was basically blocking because there was no entropy >>> for /dev/random left to generate a proper key. I wonder if it would make >>> sense to call generate-rndc-key.sh during ipa-server-install if >>> --setup-dns is given to avoid this. >> >> We can do it but it will only shift the problem to different place. > > yes, but if we do it during ipa-server-install we have it under control > and can give a hint that this step needs entropy, might need a long > time and the user might help by producing additional network or disk > I/O. That sounds reasonable. Please open a ticket or send a patch :-) -- Petr^2 Spacek From sbose at redhat.com Fri Feb 28 12:52:57 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 28 Feb 2014 13:52:57 +0100 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <53107DC2.1000000@redhat.com> References: <20140228105353.GH2710@localhost.localdomain> <53106C2D.2070502@redhat.com> <20140228111021.GJ2710@localhost.localdomain> <53107DC2.1000000@redhat.com> Message-ID: <20140228125257.GL2710@localhost.localdomain> On Fri, Feb 28, 2014 at 01:14:58PM +0100, Petr Spacek wrote: > On 28.2.2014 12:10, Sumit Bose wrote: > >On Fri, Feb 28, 2014 at 11:59:57AM +0100, Petr Spacek wrote: > >>On 28.2.2014 11:53, Sumit Bose wrote: > >>>I just tried to install FreeIPA on a fresh F20 VM and > >>>'ipa-server-install --setup-dns' failed to start FreeIPA finally after > >>>everything was configured. > >>> > >>>The reason was that starting named timed out because > >>>generate-rndc-key.sh was basically blocking because there was no entropy > >>>for /dev/random left to generate a proper key. I wonder if it would make > >>>sense to call generate-rndc-key.sh during ipa-server-install if > >>>--setup-dns is given to avoid this. > >> > >>We can do it but it will only shift the problem to different place. > > > >yes, but if we do it during ipa-server-install we have it under control > >and can give a hint that this step needs entropy, might need a long > >time and the user might help by producing additional network or disk > >I/O. > > That sounds reasonable. Please open a ticket or send a patch :-) ok, I've opened https://fedorahosted.org/freeipa/ticket/4210 for the time being. bye, Sumit > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Fri Feb 28 12:54:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 13:54:53 +0100 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: References: Message-ID: <5310871D.7050702@redhat.com> On 02/26/2014 04:01 PM, Gabe Alford wrote: > Hi all, > > I added a tip in the deleting users section on restoring admin account. > Please review. > > https://fedorahosted.org/freeipa/ticket/2746 Hello, The new tip is added right under a Note about the same thing (or a very similar thing, from the user's POV). Would it be possible to merge those two into a single Note? Nowadays[0], ipa user-del and ipa group-remove-member will refuse to delete the last admin. I think this information should be added to the main docs. (Also, this reduces the importance of the recovery instructions.) [0] https://fedorahosted.org/freeipa/ticket/2564 -- Petr? From mkosek at redhat.com Fri Feb 28 13:12:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Feb 2014 14:12:33 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 In-Reply-To: <530DB78A.4040003@redhat.com> References: <530DB78A.4040003@redhat.com> Message-ID: <53108B41.50700@redhat.com> On 02/26/2014 10:44 AM, Petr Viktorin wrote: > Hello, > Here are a few fixes/improvements, and the first part of a managed permission > updater. > > The patches should go in this order but don't need to be ACKed/pushed all at once. > > > Design: > http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater > Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 > > > This part is a "preview" of sorts, to get the basic mechanism and the metadata > format reviewed before I add all of the default read permissions. > It implements the first section of "Default Permission Updater" in the design; > "Replacing legacy default permissions" and "Removing the global anonymous read > ACI" is left for later. > Metadata is added for the netgroup plugin* for starters, so installing this > will give you two shiny new read permissions: > > $ ipa permission-find ipa: --all > --------------------- > 2 permissions matched > --------------------- > dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX > Permission name: ipa:Read Netgroup Membership > Permissions: read, compare, search > Effective attributes: externalhost, member, memberof, memberuser > Default attributes: member, memberof, memberuser, externalhost > Bind rule type: all > Subtree: cn=ng,cn=alt,$SUFFIX > Target filter: (objectclass=ipanisnetgroup) > Type: netgroup > ipapermissiontype: V2, MANAGED, SYSTEM > objectclass: ipapermission, groupofnames, top, ipapermissionv2 > > dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX > Permission name: ipa:Read Netgroups > Permissions: read, compare, search > Effective attributes: cn, description, hostcategory, ipaenabledflag, > ipauniqueid, nisdomainname, usercategory > Default attributes: cn, usercategory, hostcategory, ipauniqueid, > ipaenabledflag, nisdomainname, description > Bind rule type: all > Subtree: cn=ng,cn=alt,$SUFFIX > Target filter: (objectclass=ipanisnetgroup) > Type: netgroup > ipapermissiontype: V2, MANAGED, SYSTEM > objectclass: ipapermission, groupofnames, top, ipapermissionv2 > ---------------------------- > Number of entries returned 2 > ---------------------------- > > with corresponding ACIs at cn=ng,cn=alt,$SUFFIX: > > (targetattr = "externalhost || member || memberof || memberuser")(targetfilter > = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read Netgroup > Membership";allow (read,compare,search) userdn = "ldap:///all";) > (targetattr = "cn || description || hostcategory || ipaenabledflag || > ipauniqueid || nisdomainname || usercategory")(targetfilter = > "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read > Netgroups";allow (read,compare,search) userdn = "ldap:///all";) > > > > Patches: > > 0473: Enables refactoring that will make it more clear (to humans and machines) > what plugins code depends on. > https://fedorahosted.org/freeipa/ticket/4185 > > 0474: Fix handling of the search term for legacy permissions > My code that's in master now handles the search term incorrectly. This does a > better job. > > 0475: Fix tests that relied on some assumptions I'll be breaking > > 0476: Allow modifying (but not creating) permissions with ":" in the name > > 0477: Permission updater & sample metadata > 1) 476: Typo in test name: + desc='Search fo rnonexisting permission with ":" in the name', 2) 477: do we want to log anything when permission is up to date? + try: + ldap.update_entry(entry) + except errors.EmptyModlist: + return 3) I am not sure if this was initiated by this patch, but when I checked access log for a "permission-find --name ipa" operation, it produced over 170 LDAP operations, most of them asking for the same information many times. See attached access log excerpt. 4) I have been quite resilient to the prefixes for the permissions, but it seems it is the easier possible approach to fix conflicts with user permissions without having to check that later for every upgrade or doing more complex stuff like multiple RDNs or different container for system and user permissions. I am now just thinking about the prefixing. Now you use this name: ipa:Read Netgroups Would it be "nicer" to use: IPA:Read Netgroups or IPA: Read Netgroups or even [IPA] Read Netgroups ? :-) 5) Are we sure we want to make our code Python 2.7 dependent? + 'ipapermright': {'read', 'search', 'compare'}, I did not test if we do not require some python 2.7 feature elsewhere already, but this construct raised a warning for me. Otherwise the patches seemed to work fine. I also tried to play with the global ACI blacklist blacklisting and it worked as well, when I for example added userpassword to netgroup managed_permissions. Martin -------------- next part -------------- [28/Feb/2014:10:55:29 +0100] conn=24 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [28/Feb/2014:10:55:29 +0100] conn=4 op=135 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:29 +0100] conn=24 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [28/Feb/2014:10:55:30 +0100] conn=24 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [28/Feb/2014:10:55:30 +0100] conn=24 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [28/Feb/2014:10:55:30 +0100] conn=24 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [28/Feb/2014:10:55:30 +0100] conn=24 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [28/Feb/2014:10:55:30 +0100] conn=24 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" [28/Feb/2014:10:55:30 +0100] conn=24 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:30 +0100] conn=24 op=4 SRCH base="cn=permissions,cn=pbac,dc=example,dc=com" scope=1 filter="(&(|(ipaPermRight=*ipa:*)(ipaPermTargetFilter=*ipa:*)(ipaPermBindRuleType=*ipa:*)(ipaPermissionType=*ipa:*)(cn=*ipa:*)(objectClass=*ipa:*)(memberOf=*ipa:*)(member=*ipa:*)(ipaPermTarget=*ipa:*)(memberindirect=*ipa:*)(ipaPermDefaultAttr=*ipa:*)(ipaPermLocation=*ipa:*)(ipaPermIncludedAttr=*ipa:*)(ipaPermExcludedAttr=*ipa:*))(&(objectClass=groupofnames)(objectClass=ipapermission)(objectClass=ipapermissionv2)))" attrs="ipaPermRight ipaPermTargetFilter ipaPermBindRuleType ipaPermissionType cn objectClass memberOf member ipaPermTarget ipaPermDefaultAttr ipaPermLocation ipaPermIncludedAttr ipaPermExcludedAttr" [28/Feb/2014:10:55:30 +0100] conn=24 op=4 RESULT err=0 tag=101 nentries=2 etime=0 notes=U [28/Feb/2014:10:55:30 +0100] conn=24 op=5 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=5 RESULT err=0 tag=101 nentries=0 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=6 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=ipa:Read Netgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=6 RESULT err=0 tag=101 nentries=0 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=7 SRCH base="cn=permissions,cn=pbac,dc=example,dc=com" scope=2 filter="(&(objectClass=ipaPermission)(!(ipaPermissionType=V2)))" attrs="ipaPermRight ipaPermTargetFilter ipaPermBindRuleType ipaPermissionType cn objectClass memberOf member ipaPermTarget memberindirect ipaPermDefaultAttr ipaPermLocation ipaPermIncludedAttr ipaPermExcludedAttr" [28/Feb/2014:10:55:30 +0100] conn=24 op=7 RESULT err=0 tag=101 nentries=85 etime=0 notes=U [28/Feb/2014:10:55:30 +0100] conn=24 op=8 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Users,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=8 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=9 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Change a user password,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=9 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=10 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add user to default group,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=10 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=11 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Unlock user accounts,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=11 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=12 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Users,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=12 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=13 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Users,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=13 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=14 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage User SSH Public Keys,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=14 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=15 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Groups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=15 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=16 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Groups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=16 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=17 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Groups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=17 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=18 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Group membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=18 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=19 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Hosts,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=19 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=20 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Hosts,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=20 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=21 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Hosts,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=21 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=22 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=22 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=23 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Hostgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=23 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=24 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Hostgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=24 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=25 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Hostgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=25 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=26 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Hostgroup membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=26 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=27 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Services,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=27 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=28 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Services,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=28 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=29 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Services,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=29 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=30 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Roles,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=30 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=31 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Roles,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=31 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=32 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Roles,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=32 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=33 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Role membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=33 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=34 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify privilege membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=34 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=35 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Automount maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=35 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=36 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Automount maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=36 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=37 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Automount maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=37 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=38 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Automount keys,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=38 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=39 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Automount keys,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=39 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=40 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Automount keys,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=40 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=41 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add netgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=41 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=42 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove netgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=42 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=43 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify netgroups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=43 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=44 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify netgroup membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=44 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=45 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage host keytab,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=45 RESULT err=0 tag=101 nentries=5 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=46 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage service keytab,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=46 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=47 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Enroll a host,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=47 RESULT err=0 tag=101 nentries=5 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=48 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=48 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=49 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=49 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=50 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=50 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=51 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify DNA Range,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=51 RESULT err=0 tag=101 nentries=4 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=52 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Retrieve Certificates from the CA,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=52 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:30 +0100] conn=24 op=53 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Request Certificate,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:30 +0100] conn=24 op=53 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=54 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Request Certificates from a different host,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=54 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=55 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Get Certificates status from the CA,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=55 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=56 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Revoke Certificate,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=56 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=57 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Certificate Remove Hold,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=57 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=58 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=58 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=59 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Group Password Policy costemplate,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=59 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=60 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage HBAC service group membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=60 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=61 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete HBAC services,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=61 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=62 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Group Password Policy,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=62 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=63 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Sudo rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=63 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=64 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Write IPA Configuration,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=64 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=65 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete Group Password Policy,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=65 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=66 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Group Password Policy,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=66 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=67 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add SELinux User Maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=67 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=68 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete HBAC service groups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=68 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=69 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Sudo command,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=69 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=70 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Sudo command group,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=70 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=71 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Automember Rebuild Membership Task,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=71 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=72 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete HBAC rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=72 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=73 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage Sudo command group membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=73 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=74 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Sudo command,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=74 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=75 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Manage HBAC rule membership,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=75 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=76 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=76 RESULT err=0 tag=101 nentries=5 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=77 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add HBAC rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=77 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=78 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify SELinux User Maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=78 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=79 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add HBAC service groups,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=79 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=80 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete Sudo rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=80 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=81 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Modify Group Password Policy costemplate,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=81 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=82 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete Sudo command group,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=82 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=83 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete Group Password Policy costemplate,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=83 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=84 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add Sudo rule,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=84 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=85 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Add HBAC services,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=85 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=86 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Delete Sudo command,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=86 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=87 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Remove SELinux User Maps,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=87 RESULT err=0 tag=101 nentries=1 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=88 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=add dns entries,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=88 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=89 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=remove dns entries,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=89 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=90 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=update dns entries,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=90 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=91 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=91 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=92 SRCH base="dc=example,dc=com" scope=2 filter="(memberOf=cn=Write DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=com)" attrs="member" [28/Feb/2014:10:55:31 +0100] conn=24 op=92 RESULT err=0 tag=101 nentries=3 etime=0 notes=P [28/Feb/2014:10:55:31 +0100] conn=24 op=93 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=93 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=94 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=94 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=95 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=95 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=96 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=96 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=97 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=97 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=98 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=98 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=99 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=99 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=100 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=100 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=101 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=101 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=102 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=102 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=103 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=103 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=104 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=104 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=105 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=105 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=106 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=106 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=107 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=107 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=108 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=108 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=109 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=109 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=110 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=110 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=111 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=111 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=112 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=112 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=113 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=113 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=114 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=114 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=115 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=115 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=116 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=116 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=117 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=117 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=118 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=118 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=119 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=119 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=120 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=120 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=121 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=121 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=122 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=122 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=123 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=123 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=124 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=124 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=125 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=125 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:31 +0100] conn=24 op=126 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:31 +0100] conn=24 op=126 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=127 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=127 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=128 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=128 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=129 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=129 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=130 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=130 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=131 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=131 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=132 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=132 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=133 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=133 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=134 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=134 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=135 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=135 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=136 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=136 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=137 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=137 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=138 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=138 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=139 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=139 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=140 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=140 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=141 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=141 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=142 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=142 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=143 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=143 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=144 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=144 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=145 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=145 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=146 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=146 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=147 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=147 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=148 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=148 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=149 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=149 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=150 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=150 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=151 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=151 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=152 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=152 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=153 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=153 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=154 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=154 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=155 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=155 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=156 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=156 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=157 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=157 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=158 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=158 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=159 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=159 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=160 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=160 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=161 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=161 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=162 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=162 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=163 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=163 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=164 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=164 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=165 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=165 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:32 +0100] conn=24 op=166 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:32 +0100] conn=24 op=166 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=167 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:33 +0100] conn=24 op=167 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=168 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:33 +0100] conn=24 op=168 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=169 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:33 +0100] conn=24 op=169 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=170 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:33 +0100] conn=24 op=170 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=171 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="aci" [28/Feb/2014:10:55:33 +0100] conn=24 op=171 RESULT err=0 tag=101 nentries=1 etime=0 [28/Feb/2014:10:55:33 +0100] conn=24 op=172 UNBIND [28/Feb/2014:10:55:33 +0100] conn=24 op=172 fd=78 closed - U1 From pviktori at redhat.com Fri Feb 28 13:47:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 14:47:28 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 In-Reply-To: <53108B41.50700@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> Message-ID: <53109370.7010905@redhat.com> On 02/28/2014 02:12 PM, Martin Kosek wrote: > On 02/26/2014 10:44 AM, Petr Viktorin wrote: >> Hello, >> Here are a few fixes/improvements, and the first part of a managed permission >> updater. >> >> The patches should go in this order but don't need to be ACKed/pushed all at once. >> >> >> Design: >> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >> >> >> This part is a "preview" of sorts, to get the basic mechanism and the metadata >> format reviewed before I add all of the default read permissions. >> It implements the first section of "Default Permission Updater" in the design; >> "Replacing legacy default permissions" and "Removing the global anonymous read >> ACI" is left for later. >> Metadata is added for the netgroup plugin* for starters, so installing this >> will give you two shiny new read permissions: >> >> $ ipa permission-find ipa: --all >> --------------------- >> 2 permissions matched >> --------------------- >> dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX >> Permission name: ipa:Read Netgroup Membership >> Permissions: read, compare, search >> Effective attributes: externalhost, member, memberof, memberuser >> Default attributes: member, memberof, memberuser, externalhost >> Bind rule type: all >> Subtree: cn=ng,cn=alt,$SUFFIX >> Target filter: (objectclass=ipanisnetgroup) >> Type: netgroup >> ipapermissiontype: V2, MANAGED, SYSTEM >> objectclass: ipapermission, groupofnames, top, ipapermissionv2 >> >> dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX >> Permission name: ipa:Read Netgroups >> Permissions: read, compare, search >> Effective attributes: cn, description, hostcategory, ipaenabledflag, >> ipauniqueid, nisdomainname, usercategory >> Default attributes: cn, usercategory, hostcategory, ipauniqueid, >> ipaenabledflag, nisdomainname, description >> Bind rule type: all >> Subtree: cn=ng,cn=alt,$SUFFIX >> Target filter: (objectclass=ipanisnetgroup) >> Type: netgroup >> ipapermissiontype: V2, MANAGED, SYSTEM >> objectclass: ipapermission, groupofnames, top, ipapermissionv2 >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> with corresponding ACIs at cn=ng,cn=alt,$SUFFIX: >> >> (targetattr = "externalhost || member || memberof || memberuser")(targetfilter >> = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read Netgroup >> Membership";allow (read,compare,search) userdn = "ldap:///all";) >> (targetattr = "cn || description || hostcategory || ipaenabledflag || >> ipauniqueid || nisdomainname || usercategory")(targetfilter = >> "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read >> Netgroups";allow (read,compare,search) userdn = "ldap:///all";) >> >> >> >> Patches: >> >> 0473: Enables refactoring that will make it more clear (to humans and machines) >> what plugins code depends on. >> https://fedorahosted.org/freeipa/ticket/4185 >> >> 0474: Fix handling of the search term for legacy permissions >> My code that's in master now handles the search term incorrectly. This does a >> better job. >> >> 0475: Fix tests that relied on some assumptions I'll be breaking >> >> 0476: Allow modifying (but not creating) permissions with ":" in the name >> >> 0477: Permission updater & sample metadata >> > > 1) 476: Typo in test name: > > + desc='Search fo rnonexisting permission with ":" in the name', Will fix. > 2) 477: do we want to log anything when permission is up to date? > > + try: > + ldap.update_entry(entry) > + except errors.EmptyModlist: > + return I don't think that's needed, after all that's the expected behavior in all but the first upgrade. But I'll be happy to add it if you think it would be better. > 3) I am not sure if this was initiated by this patch, but when I checked access > log for a "permission-find --name ipa" operation, it produced over 170 LDAP > operations, most of them asking for the same information many times. See > attached access log excerpt. It's unrelated to this patch. I've started optimizing permission-find with many legacy permissions, expect a patch soon. > 4) I have been quite resilient to the prefixes for the permissions, but it > seems it is the easier possible approach to fix conflicts with user permissions > without having to check that later for every upgrade or doing more complex > stuff like multiple RDNs or different container for system and user permissions. > > I am now just thinking about the prefixing. Now you use this name: > > ipa:Read Netgroups > > Would it be "nicer" to use: > > IPA:Read Netgroups > or > IPA: Read Netgroups > or even > [IPA] Read Netgroups > ? :-) Bikeshedding time! Everyone on the list, please chime in! I don't really have a preference. > 5) Are we sure we want to make our code Python 2.7 dependent? > > + 'ipapermright': {'read', 'search', 'compare'}, > > I did not test if we do not require some python 2.7 feature elsewhere already, > but this construct raised a warning for me. That ship has sailed already. Recently there was commit a8ba5e0 which explicitly mentions set literals (and which, coincidentally, you acked...), but I'm pretty sure IPA needed Python 2.7+ before that. After all we don't test on Python 2.6 and don't support any OS with Python 2.6. > Otherwise the patches seemed to work fine. I also tried to play with the global > ACI blacklist blacklisting and it worked as well, when I for example added > userpassword to netgroup managed_permissions. -- Petr? From rcritten at redhat.com Fri Feb 28 14:03:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 09:03:39 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53107A3D.6010200@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> <53107607.1010403@redhat.com> <53107A3D.6010200@redhat.com> Message-ID: <5310973B.4050108@redhat.com> Petr Viktorin wrote: > On 02/28/2014 12:41 PM, Martin Kosek wrote: >> On 02/28/2014 10:47 AM, Petr Viktorin wrote: >>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>> [...] >>>>> Ok, so try to summarize this long-running thread, I'll rename the >>>>> subpackage to freeipa-server-foreman-smartproxy to make it clearer >>>>> what >>>>> it is/does. Right now it requires manual configuration so having the >>>>> package installed should have no negative impacts (other than >>>>> potentially pulling in additional dependencies). >>>>> >>>>> I'll leave it in smartproxy for now, it's just cleaner and better >>>>> integrates with ipatests IMHO. >>>>> >>>>> Foreman supports SSL client auth which is great, by cherrypy does not >>>>> yet. There is a pull request to add this, >>>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>>>> >>>>> >>>>> >>>>> . Foreman otherwise supports no other authentication method, so we're >>>>> blocked with this. The certs for this would initially come out of >>>>> Foreman/puppet. >>>>> >>>>> I'll submit a new patch with an updated spec but I think otherwise >>>>> I've >>>>> addressed the isuses Petr has raised. This thread has taken a lot of >>>>> turns so it is very possible I missed something though :-) >>>> >>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>> /features, which Foreman uses to determine what capabilities a proxy >>>> has. >>>> >>>> rob >>> >>> My review is blocked because 389-ds doesn't install on Rawhide due to >>> https://fedorahosted.org/389/ticket/47700 >>> >>> Noriko, do you know of a Rawhide build that includes your fix? >> >> Guys, if this patch still makes our master branch incompatible with >> F20, then >> it is a NACK from me. All developers run on F20, our CI runs on F20 >> and I do >> not think we can afford loosing that and forcing everyone to >> permanently switch >> to rawhide - it is too unstable. >> >> IMO the Requires and BuildRequires most be set so that RPMs are >> buildable and >> installable on F20. The only acceptable exception is when only >> freeipa-server-foreman-smartprox cannot be installed on F20, but >> otherwise >> everything else need to work. >> >> Thanks, >> Martin >> > > Okay, it's not a BuildRequires; IPA doesn't build because of a lint > failure: ipalib/util.py - Module 'kerberos' has no > 'authGSSClientInquireCred' member > > I guess the new get_current_principal needs to be kept out of ipalib > until we move to f21. Until then we can have a lint exception; after > then we need to remove it, and add BuildRequires so lint passes. > The other option is to locally rebuild python-kerberos from rawhide in F-20. Simo was a bit reluctant to put it into F-20 with the patch I added for authenticate_gss_client_inquire_cred(). We can also work on convincing him it is low risk. rob From npmccallum at redhat.com Fri Feb 28 14:25:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 28 Feb 2014 09:25:39 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <53105B27.4070003@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> Message-ID: <1393597539.3562.21.camel@localhost.localdomain> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: > On 28.2.2014 04:02, Rob Crittenden wrote: > > Alexander Bokovoy wrote: > >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: > >>> So the recent discussion on importing tokens led me to write a script to > >>> parse RFC 6030 xml files into IPA token data. This all works well. But > >>> now I need to integrate it into the IPA framework. > >>> > >>> This command will parse one or more xml files, creating a set of tokens > >>> to be added. Given that we already have otptoken-add on the server-side, > >>> it seems to me that all work needs to be done on the client-side. How do > >>> I create a new client-side command that calls existing server-side API? > >> subclass from frontend.Local, override run() or forward() method and > >> perform batch > >> operation of otptoken_add from there. > >> > >> See cli.help, for example. > > > > If you do an override, do forward() for cli-specific work. > > > > But you should do as little as possible for reasons you already stated: > > the UI. Anything you do in forward Petr will need to implement in the UI. > > > > Unfortunately we don't yet have a nice way to handle files. We have > > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > > https://fedorahosted.org/freeipa/ticket/2933 > > > > If this file is something that would be pasted into a big text field > > then you can probably handle it in a similarly clumsy way that we do > > CSRs in the cert plugin. > > > > rob > > +1 for parsing it on server. Otherwise every client, not just CLI or Web > UI, would have to reimplement the same logic - having it on server will > support better integration with third party products. > > Parsing on client would be understandable if there was some middle step > which would require some action from user, i.e, pick only some tokens to > import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Nathaniel From simo at redhat.com Fri Feb 28 14:27:57 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 28 Feb 2014 09:27:57 -0500 Subject: [Freeipa-devel] Entropy aka ipa-server-install failed In-Reply-To: <20140228105353.GH2710@localhost.localdomain> References: <20140228105353.GH2710@localhost.localdomain> Message-ID: <1393597677.22047.4.camel@willson.li.ssimo.org> On Fri, 2014-02-28 at 11:53 +0100, Sumit Bose wrote: > Hi, > > I just tried to install FreeIPA on a fresh F20 VM and > 'ipa-server-install --setup-dns' failed to start FreeIPA finally after > everything was configured. > > The reason was that starting named timed out because > generate-rndc-key.sh was basically blocking because there was no entropy > for /dev/random left to generate a proper key. I wonder if it would make > sense to call generate-rndc-key.sh during ipa-server-install if > --setup-dns is given to avoid this. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Feb 28 14:29:51 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 28 Feb 2014 09:29:51 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5310973B.4050108@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> <53107607.1010403@redhat.com> <53107A3D.6010200@redhat.com> <5310973B.4050108@redhat.com> Message-ID: <1393597791.22047.5.camel@willson.li.ssimo.org> On Fri, 2014-02-28 at 09:03 -0500, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 02/28/2014 12:41 PM, Martin Kosek wrote: > >> On 02/28/2014 10:47 AM, Petr Viktorin wrote: > >>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: > >>>> Rob Crittenden wrote: > >>> [...] > >>>>> Ok, so try to summarize this long-running thread, I'll rename the > >>>>> subpackage to freeipa-server-foreman-smartproxy to make it clearer > >>>>> what > >>>>> it is/does. Right now it requires manual configuration so having the > >>>>> package installed should have no negative impacts (other than > >>>>> potentially pulling in additional dependencies). > >>>>> > >>>>> I'll leave it in smartproxy for now, it's just cleaner and better > >>>>> integrates with ipatests IMHO. > >>>>> > >>>>> Foreman supports SSL client auth which is great, by cherrypy does not > >>>>> yet. There is a pull request to add this, > >>>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity > >>>>> > >>>>> > >>>>> > >>>>> . Foreman otherwise supports no other authentication method, so we're > >>>>> blocked with this. The certs for this would initially come out of > >>>>> Foreman/puppet. > >>>>> > >>>>> I'll submit a new patch with an updated spec but I think otherwise > >>>>> I've > >>>>> addressed the isuses Petr has raised. This thread has taken a lot of > >>>>> turns so it is very possible I missed something though :-) > >>>> > >>>> Updated patch based on feedback from Foreman team. I added a new URI, > >>>> /features, which Foreman uses to determine what capabilities a proxy > >>>> has. > >>>> > >>>> rob > >>> > >>> My review is blocked because 389-ds doesn't install on Rawhide due to > >>> https://fedorahosted.org/389/ticket/47700 > >>> > >>> Noriko, do you know of a Rawhide build that includes your fix? > >> > >> Guys, if this patch still makes our master branch incompatible with > >> F20, then > >> it is a NACK from me. All developers run on F20, our CI runs on F20 > >> and I do > >> not think we can afford loosing that and forcing everyone to > >> permanently switch > >> to rawhide - it is too unstable. > >> > >> IMO the Requires and BuildRequires most be set so that RPMs are > >> buildable and > >> installable on F20. The only acceptable exception is when only > >> freeipa-server-foreman-smartprox cannot be installed on F20, but > >> otherwise > >> everything else need to work. > >> > >> Thanks, > >> Martin > >> > > > > Okay, it's not a BuildRequires; IPA doesn't build because of a lint > > failure: ipalib/util.py - Module 'kerberos' has no > > 'authGSSClientInquireCred' member > > > > I guess the new get_current_principal needs to be kept out of ipalib > > until we move to f21. Until then we can have a lint exception; after > > then we need to remove it, and add BuildRequires so lint passes. > > > > The other option is to locally rebuild python-kerberos from rawhide in > F-20. Simo was a bit reluctant to put it into F-20 with the patch I > added for authenticate_gss_client_inquire_cred(). We can also work on > convincing him it is low risk. Or you can simply provide a copr repo with the new build for f20 for the time being ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Feb 28 14:32:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Feb 2014 15:32:16 +0100 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393597539.3562.21.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> Message-ID: <53109DF0.2090206@redhat.com> On 28.2.2014 15:25, Nathaniel McCallum wrote: > On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >> On 28.2.2014 04:02, Rob Crittenden wrote: >>> Alexander Bokovoy wrote: >>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>>> So the recent discussion on importing tokens led me to write a script to >>>>> parse RFC 6030 xml files into IPA token data. This all works well. But >>>>> now I need to integrate it into the IPA framework. >>>>> >>>>> This command will parse one or more xml files, creating a set of tokens >>>>> to be added. Given that we already have otptoken-add on the server-side, >>>>> it seems to me that all work needs to be done on the client-side. How do >>>>> I create a new client-side command that calls existing server-side API? >>>> subclass from frontend.Local, override run() or forward() method and >>>> perform batch >>>> operation of otptoken_add from there. >>>> >>>> See cli.help, for example. >>> >>> If you do an override, do forward() for cli-specific work. >>> >>> But you should do as little as possible for reasons you already stated: >>> the UI. Anything you do in forward Petr will need to implement in the UI. >>> >>> Unfortunately we don't yet have a nice way to handle files. We have >>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>> https://fedorahosted.org/freeipa/ticket/2933 >>> >>> If this file is something that would be pasted into a big text field >>> then you can probably handle it in a similarly clumsy way that we do >>> CSRs in the cert plugin. >>> >>> rob >> >> +1 for parsing it on server. Otherwise every client, not just CLI or Web >> UI, would have to reimplement the same logic - having it on server will >> support better integration with third party products. >> >> Parsing on client would be understandable if there was some middle step >> which would require some action from user, i.e, pick only some tokens to >> import. > > If we parse on the server side, how do we handle the long-running > operation? Think of the case of importing hundreds or thousands of > tokens... My experience is that operation on server side can run for (at least) few minutes without a problem. I haven't try longer periods but we can check that. -- Petr^2 Spacek From rcritten at redhat.com Fri Feb 28 14:35:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 09:35:13 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <1393597791.22047.5.camel@willson.li.ssimo.org> References: <52D99F70.3060305@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> <53107607.1010403@redhat.com> <53107A3D.6010200@redhat.com> <5310973B.4050108@redhat.com> <1393597791.22047.5.camel@willson.li.ssi! mo.org> Message-ID: <53109EA1.9050806@redhat.com> Simo Sorce wrote: > On Fri, 2014-02-28 at 09:03 -0500, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/28/2014 12:41 PM, Martin Kosek wrote: >>>> On 02/28/2014 10:47 AM, Petr Viktorin wrote: >>>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>> [...] >>>>>>> Ok, so try to summarize this long-running thread, I'll rename the >>>>>>> subpackage to freeipa-server-foreman-smartproxy to make it clearer >>>>>>> what >>>>>>> it is/does. Right now it requires manual configuration so having the >>>>>>> package installed should have no negative impacts (other than >>>>>>> potentially pulling in additional dependencies). >>>>>>> >>>>>>> I'll leave it in smartproxy for now, it's just cleaner and better >>>>>>> integrates with ipatests IMHO. >>>>>>> >>>>>>> Foreman supports SSL client auth which is great, by cherrypy does not >>>>>>> yet. There is a pull request to add this, >>>>>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>>>>>> >>>>>>> >>>>>>> >>>>>>> . Foreman otherwise supports no other authentication method, so we're >>>>>>> blocked with this. The certs for this would initially come out of >>>>>>> Foreman/puppet. >>>>>>> >>>>>>> I'll submit a new patch with an updated spec but I think otherwise >>>>>>> I've >>>>>>> addressed the isuses Petr has raised. This thread has taken a lot of >>>>>>> turns so it is very possible I missed something though :-) >>>>>> >>>>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>>> has. >>>>>> >>>>>> rob >>>>> >>>>> My review is blocked because 389-ds doesn't install on Rawhide due to >>>>> https://fedorahosted.org/389/ticket/47700 >>>>> >>>>> Noriko, do you know of a Rawhide build that includes your fix? >>>> >>>> Guys, if this patch still makes our master branch incompatible with >>>> F20, then >>>> it is a NACK from me. All developers run on F20, our CI runs on F20 >>>> and I do >>>> not think we can afford loosing that and forcing everyone to >>>> permanently switch >>>> to rawhide - it is too unstable. >>>> >>>> IMO the Requires and BuildRequires most be set so that RPMs are >>>> buildable and >>>> installable on F20. The only acceptable exception is when only >>>> freeipa-server-foreman-smartprox cannot be installed on F20, but >>>> otherwise >>>> everything else need to work. >>>> >>>> Thanks, >>>> Martin >>>> >>> >>> Okay, it's not a BuildRequires; IPA doesn't build because of a lint >>> failure: ipalib/util.py - Module 'kerberos' has no >>> 'authGSSClientInquireCred' member >>> >>> I guess the new get_current_principal needs to be kept out of ipalib >>> until we move to f21. Until then we can have a lint exception; after >>> then we need to remove it, and add BuildRequires so lint passes. >>> >> >> The other option is to locally rebuild python-kerberos from rawhide in >> F-20. Simo was a bit reluctant to put it into F-20 with the patch I >> added for authenticate_gss_client_inquire_cred(). We can also work on >> convincing him it is low risk. > > Or you can simply provide a copr repo with the new build for f20 for the > time being ? That doesn't deal with Martin's requirement that master build in F-20, and I presume by that no asterisks allowed (though we have made exceptions in the past). For a package this small, fetching from copr and rpmbuild are similar amounts of effort, IMHO. rob From abokovoy at redhat.com Fri Feb 28 14:43:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 16:43:51 +0200 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393597539.3562.21.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> Message-ID: <20140228144351.GC16644@redhat.com> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >> On 28.2.2014 04:02, Rob Crittenden wrote: >> > Alexander Bokovoy wrote: >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >> >>> So the recent discussion on importing tokens led me to write a script to >> >>> parse RFC 6030 xml files into IPA token data. This all works well. But >> >>> now I need to integrate it into the IPA framework. >> >>> >> >>> This command will parse one or more xml files, creating a set of tokens >> >>> to be added. Given that we already have otptoken-add on the server-side, >> >>> it seems to me that all work needs to be done on the client-side. How do >> >>> I create a new client-side command that calls existing server-side API? >> >> subclass from frontend.Local, override run() or forward() method and >> >> perform batch >> >> operation of otptoken_add from there. >> >> >> >> See cli.help, for example. >> > >> > If you do an override, do forward() for cli-specific work. >> > >> > But you should do as little as possible for reasons you already stated: >> > the UI. Anything you do in forward Petr will need to implement in the UI. >> > >> > Unfortunately we don't yet have a nice way to handle files. We have >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >> > https://fedorahosted.org/freeipa/ticket/2933 >> > >> > If this file is something that would be pasted into a big text field >> > then you can probably handle it in a similarly clumsy way that we do >> > CSRs in the cert plugin. >> > >> > rob >> >> +1 for parsing it on server. Otherwise every client, not just CLI or Web >> UI, would have to reimplement the same logic - having it on server will >> support better integration with third party products. >> >> Parsing on client would be understandable if there was some middle step >> which would require some action from user, i.e, pick only some tokens to >> import. > >If we parse on the server side, how do we handle the long-running >operation? Think of the case of importing hundreds or thousands of >tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. -- / Alexander Bokovoy From pviktori at redhat.com Fri Feb 28 14:51:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 15:51:05 +0100 Subject: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions Message-ID: <5310A259.9070109@redhat.com> Hello, This reduces LDAP searches in permission-find when there are legacy permissions. The root entry (which contains all legacy permission ACIs) is only looked up once. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0481-permission-find-Cache-the-root-entry-for-legacy-perm.patch Type: text/x-patch Size: 5013 bytes Desc: not available URL: From rcritten at redhat.com Fri Feb 28 14:56:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 09:56:57 -0500 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53109EA1.9050806@redhat.com> References: <52D99F70.3060305@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <53105B23.7060801@redhat.com> <53107607.1010403@redhat.com> <53107A3D.6010200@redhat.com> <5310973B.4050108@redhat.com> <1393597791.22047.5.camel@willson.li.ssi! mo.org> <53109EA1.9050806@red! hat.com> Message-ID: <5310A3B9.2070409@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2014-02-28 at 09:03 -0500, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/28/2014 12:41 PM, Martin Kosek wrote: >>>>> On 02/28/2014 10:47 AM, Petr Viktorin wrote: >>>>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>> [...] >>>>>>>> Ok, so try to summarize this long-running thread, I'll rename the >>>>>>>> subpackage to freeipa-server-foreman-smartproxy to make it clearer >>>>>>>> what >>>>>>>> it is/does. Right now it requires manual configuration so having >>>>>>>> the >>>>>>>> package installed should have no negative impacts (other than >>>>>>>> potentially pulling in additional dependencies). >>>>>>>> >>>>>>>> I'll leave it in smartproxy for now, it's just cleaner and better >>>>>>>> integrates with ipatests IMHO. >>>>>>>> >>>>>>>> Foreman supports SSL client auth which is great, by cherrypy >>>>>>>> does not >>>>>>>> yet. There is a pull request to add this, >>>>>>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> . Foreman otherwise supports no other authentication method, so >>>>>>>> we're >>>>>>>> blocked with this. The certs for this would initially come out of >>>>>>>> Foreman/puppet. >>>>>>>> >>>>>>>> I'll submit a new patch with an updated spec but I think otherwise >>>>>>>> I've >>>>>>>> addressed the isuses Petr has raised. This thread has taken a >>>>>>>> lot of >>>>>>>> turns so it is very possible I missed something though :-) >>>>>>> >>>>>>> Updated patch based on feedback from Foreman team. I added a new >>>>>>> URI, >>>>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>>>> has. >>>>>>> >>>>>>> rob >>>>>> >>>>>> My review is blocked because 389-ds doesn't install on Rawhide due to >>>>>> https://fedorahosted.org/389/ticket/47700 >>>>>> >>>>>> Noriko, do you know of a Rawhide build that includes your fix? >>>>> >>>>> Guys, if this patch still makes our master branch incompatible with >>>>> F20, then >>>>> it is a NACK from me. All developers run on F20, our CI runs on F20 >>>>> and I do >>>>> not think we can afford loosing that and forcing everyone to >>>>> permanently switch >>>>> to rawhide - it is too unstable. >>>>> >>>>> IMO the Requires and BuildRequires most be set so that RPMs are >>>>> buildable and >>>>> installable on F20. The only acceptable exception is when only >>>>> freeipa-server-foreman-smartprox cannot be installed on F20, but >>>>> otherwise >>>>> everything else need to work. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>> >>>> Okay, it's not a BuildRequires; IPA doesn't build because of a lint >>>> failure: ipalib/util.py - Module 'kerberos' has no >>>> 'authGSSClientInquireCred' member >>>> >>>> I guess the new get_current_principal needs to be kept out of ipalib >>>> until we move to f21. Until then we can have a lint exception; after >>>> then we need to remove it, and add BuildRequires so lint passes. >>>> >>> >>> The other option is to locally rebuild python-kerberos from rawhide in >>> F-20. Simo was a bit reluctant to put it into F-20 with the patch I >>> added for authenticate_gss_client_inquire_cred(). We can also work on >>> convincing him it is low risk. >> >> Or you can simply provide a copr repo with the new build for f20 for the >> time being ? > > That doesn't deal with Martin's requirement that master build in F-20, > and I presume by that no asterisks allowed (though we have made > exceptions in the past). > > For a package this small, fetching from copr and rpmbuild are similar > amounts of effort, IMHO. Rather than fight, http://copr.fedoraproject.org/coprs/rcritten/python-kerberos/ rob From rcritten at redhat.com Fri Feb 28 15:01:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 10:01:06 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <53109DF0.2090206@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <53109DF0.2090206@redhat.com> Message-ID: <5310A4B2.9050900@redhat.com> Petr Spacek wrote: > On 28.2.2014 15:25, Nathaniel McCallum wrote: >> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>> On 28.2.2014 04:02, Rob Crittenden wrote: >>>> Alexander Bokovoy wrote: >>>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>>>> So the recent discussion on importing tokens led me to write a >>>>>> script to >>>>>> parse RFC 6030 xml files into IPA token data. This all works well. >>>>>> But >>>>>> now I need to integrate it into the IPA framework. >>>>>> >>>>>> This command will parse one or more xml files, creating a set of >>>>>> tokens >>>>>> to be added. Given that we already have otptoken-add on the >>>>>> server-side, >>>>>> it seems to me that all work needs to be done on the client-side. >>>>>> How do >>>>>> I create a new client-side command that calls existing server-side >>>>>> API? >>>>> subclass from frontend.Local, override run() or forward() method and >>>>> perform batch >>>>> operation of otptoken_add from there. >>>>> >>>>> See cli.help, for example. >>>> >>>> If you do an override, do forward() for cli-specific work. >>>> >>>> But you should do as little as possible for reasons you already stated: >>>> the UI. Anything you do in forward Petr will need to implement in >>>> the UI. >>>> >>>> Unfortunately we don't yet have a nice way to handle files. We have >>>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>>> https://fedorahosted.org/freeipa/ticket/2933 >>>> >>>> If this file is something that would be pasted into a big text field >>>> then you can probably handle it in a similarly clumsy way that we do >>>> CSRs in the cert plugin. >>>> >>>> rob >>> >>> +1 for parsing it on server. Otherwise every client, not just CLI or Web >>> UI, would have to reimplement the same logic - having it on server will >>> support better integration with third party products. >>> >>> Parsing on client would be understandable if there was some middle step >>> which would require some action from user, i.e, pick only some tokens to >>> import. >> >> If we parse on the server side, how do we handle the long-running >> operation? Think of the case of importing hundreds or thousands of >> tokens... > > My experience is that operation on server side can run for (at least) > few minutes without a problem. I haven't try longer periods but we can > check that. It can run for hours. Migration performance in IPA used to be rather pitiful and migrating several thousand users could easily take 5+ hours. IIRC sometimes the client would time out but the server side would still complete, you just got no feedback. rob From npmccallum at redhat.com Fri Feb 28 15:02:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 28 Feb 2014 10:02:25 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <20140228144351.GC16644@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> Message-ID: <1393599745.3562.23.camel@localhost.localdomain> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: > On Fri, 28 Feb 2014, Nathaniel McCallum wrote: > >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: > >> On 28.2.2014 04:02, Rob Crittenden wrote: > >> > Alexander Bokovoy wrote: > >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: > >> >>> So the recent discussion on importing tokens led me to write a script to > >> >>> parse RFC 6030 xml files into IPA token data. This all works well. But > >> >>> now I need to integrate it into the IPA framework. > >> >>> > >> >>> This command will parse one or more xml files, creating a set of tokens > >> >>> to be added. Given that we already have otptoken-add on the server-side, > >> >>> it seems to me that all work needs to be done on the client-side. How do > >> >>> I create a new client-side command that calls existing server-side API? > >> >> subclass from frontend.Local, override run() or forward() method and > >> >> perform batch > >> >> operation of otptoken_add from there. > >> >> > >> >> See cli.help, for example. > >> > > >> > If you do an override, do forward() for cli-specific work. > >> > > >> > But you should do as little as possible for reasons you already stated: > >> > the UI. Anything you do in forward Petr will need to implement in the UI. > >> > > >> > Unfortunately we don't yet have a nice way to handle files. We have > >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > >> > https://fedorahosted.org/freeipa/ticket/2933 > >> > > >> > If this file is something that would be pasted into a big text field > >> > then you can probably handle it in a similarly clumsy way that we do > >> > CSRs in the cert plugin. > >> > > >> > rob > >> > >> +1 for parsing it on server. Otherwise every client, not just CLI or Web > >> UI, would have to reimplement the same logic - having it on server will > >> support better integration with third party products. > >> > >> Parsing on client would be understandable if there was some middle step > >> which would require some action from user, i.e, pick only some tokens to > >> import. > > > >If we parse on the server side, how do we handle the long-running > >operation? Think of the case of importing hundreds or thousands of > >tokens... > Why then to do it as a IPA CLI command at all? > This is an administrative task which can be done with a separate > ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? 2. How can I use the ipalib API? Specifically, I'd like to call otptoken-add and pass the --key parameter with a value (not possible from the command line). Nathaniel From pviktori at redhat.com Fri Feb 28 15:12:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 16:12:46 +0100 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393599745.3562.23.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> Message-ID: <5310A76E.1000509@redhat.com> On 02/28/2014 04:02 PM, Nathaniel McCallum wrote: > On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: [...] >> Why then to do it as a IPA CLI command at all? >> This is an administrative task which can be done with a separate >> ipa-otp-import command, designated to run on IPA masters. > > Agreed. > > 1. Is there a framework for this? Or should it just be an independent > script? There is: ipapython.admintool. Look at ipa-server-certinstall for a simple-ish example, ask if you have any questions. > 2. How can I use the ipalib API? Specifically, I'd like to call > otptoken-add and pass the --key parameter with a value (not possible > from the command line). Finalize the API (see ipaserver.install.ServerCertInstall.run), and then call api.Command['otptoken-add'](key=...) Or you might think about moving the otptoken-add functionality into a function that you can call directly. -- Petr? From abokovoy at redhat.com Fri Feb 28 15:15:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 17:15:36 +0200 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393599745.3562.23.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> Message-ID: <20140228151536.GD16644@redhat.com> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >> >> On 28.2.2014 04:02, Rob Crittenden wrote: >> >> > Alexander Bokovoy wrote: >> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >> >> >>> So the recent discussion on importing tokens led me to write a script to >> >> >>> parse RFC 6030 xml files into IPA token data. This all works well. But >> >> >>> now I need to integrate it into the IPA framework. >> >> >>> >> >> >>> This command will parse one or more xml files, creating a set of tokens >> >> >>> to be added. Given that we already have otptoken-add on the server-side, >> >> >>> it seems to me that all work needs to be done on the client-side. How do >> >> >>> I create a new client-side command that calls existing server-side API? >> >> >> subclass from frontend.Local, override run() or forward() method and >> >> >> perform batch >> >> >> operation of otptoken_add from there. >> >> >> >> >> >> See cli.help, for example. >> >> > >> >> > If you do an override, do forward() for cli-specific work. >> >> > >> >> > But you should do as little as possible for reasons you already stated: >> >> > the UI. Anything you do in forward Petr will need to implement in the UI. >> >> > >> >> > Unfortunately we don't yet have a nice way to handle files. We have >> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >> >> > https://fedorahosted.org/freeipa/ticket/2933 >> >> > >> >> > If this file is something that would be pasted into a big text field >> >> > then you can probably handle it in a similarly clumsy way that we do >> >> > CSRs in the cert plugin. >> >> > >> >> > rob >> >> >> >> +1 for parsing it on server. Otherwise every client, not just CLI or Web >> >> UI, would have to reimplement the same logic - having it on server will >> >> support better integration with third party products. >> >> >> >> Parsing on client would be understandable if there was some middle step >> >> which would require some action from user, i.e, pick only some tokens to >> >> import. >> > >> >If we parse on the server side, how do we handle the long-running >> >operation? Think of the case of importing hundreds or thousands of >> >tokens... >> Why then to do it as a IPA CLI command at all? >> This is an administrative task which can be done with a separate >> ipa-otp-import command, designated to run on IPA masters. > >Agreed. > >1. Is there a framework for this? Or should it just be an independent >script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) >2. How can I use the ipalib API? Specifically, I'd like to call >otptoken-add and pass the --key parameter with a value (not possible >from the command line). Look in ipa-adtrust-install's main(): # Initialize the ipalib api cfg = dict( in_server=True, debug=options.debug, ) api.bootstrap(**cfg) api.finalize() ....... try: ctx = krbV.default_context() ccache = ctx.default_ccache() principal = ccache.principal() except krbV.Krb5Error, e: sys.exit("Must have Kerberos credentials to setup AD trusts on server") try: api.Backend.ldap2.connect(ccache) except errors.ACIError, e: sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") except errors.DatabaseError, e: sys.exit("Cannot connect to the LDAP database. Please check if IPA is running") try: user = api.Command.user_show(unicode(principal[0]))['result'] group = api.Command.group_show(u'admins')['result'] if not (user['uid'][0] in group['member_user'] and group['cn'][0] in user['memberof_group']): raise errors.RequirementError(name='admins group membership') except errors.RequirementError, e: sys.exit("Must have administrative privileges to setup AD trusts on server") except Exception, e: sys.exit("Unrecognized error during check of admin rights: %s" % (str(e))) and so on. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Feb 28 15:19:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 17:19:38 +0200 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <5310A76E.1000509@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <5310A76E.1000509@redhat.com> Message-ID: <20140228151938.GE16644@redhat.com> On Fri, 28 Feb 2014, Petr Viktorin wrote: >On 02/28/2014 04:02 PM, Nathaniel McCallum wrote: >>On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >[...] >>>Why then to do it as a IPA CLI command at all? >>>This is an administrative task which can be done with a separate >>>ipa-otp-import command, designated to run on IPA masters. >> >>Agreed. >> >>1. Is there a framework for this? Or should it just be an independent >>script? > >There is: ipapython.admintool. Look at ipa-server-certinstall for a >simple-ish example, ask if you have any questions. Right, forgot about that one. >>2. How can I use the ipalib API? Specifically, I'd like to call >>otptoken-add and pass the --key parameter with a value (not possible >>from the command line). > >Finalize the API (see ipaserver.install.ServerCertInstall.run), and >then call api.Command['otptoken-add'](key=...) >Or you might think about moving the otptoken-add functionality into a >function that you can call directly. I'd still prefer to do token addition through the common interface, i.e. not directly talking to ldap but rather using the CLI commands, maybe batched. -- / Alexander Bokovoy From pviktori at redhat.com Fri Feb 28 15:21:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 16:21:39 +0100 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <20140228151536.GD16644@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> Message-ID: <5310A983.50409@redhat.com> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: > On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>> >> On 28.2.2014 04:02, Rob Crittenden wrote: >>> >> > Alexander Bokovoy wrote: >>> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>> >> >>> So the recent discussion on importing tokens led me to write a >>> script to >>> >> >>> parse RFC 6030 xml files into IPA token data. This all works >>> well. But >>> >> >>> now I need to integrate it into the IPA framework. >>> >> >>> >>> >> >>> This command will parse one or more xml files, creating a set >>> of tokens >>> >> >>> to be added. Given that we already have otptoken-add on the >>> server-side, >>> >> >>> it seems to me that all work needs to be done on the >>> client-side. How do >>> >> >>> I create a new client-side command that calls existing >>> server-side API? >>> >> >> subclass from frontend.Local, override run() or forward() >>> method and >>> >> >> perform batch >>> >> >> operation of otptoken_add from there. >>> >> >> >>> >> >> See cli.help, for example. >>> >> > >>> >> > If you do an override, do forward() for cli-specific work. >>> >> > >>> >> > But you should do as little as possible for reasons you already >>> stated: >>> >> > the UI. Anything you do in forward Petr will need to implement >>> in the UI. >>> >> > >>> >> > Unfortunately we don't yet have a nice way to handle files. We have >>> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>> >> > https://fedorahosted.org/freeipa/ticket/2933 >>> >> > >>> >> > If this file is something that would be pasted into a big text >>> field >>> >> > then you can probably handle it in a similarly clumsy way that >>> we do >>> >> > CSRs in the cert plugin. >>> >> > >>> >> > rob >>> >> >>> >> +1 for parsing it on server. Otherwise every client, not just CLI >>> or Web >>> >> UI, would have to reimplement the same logic - having it on server >>> will >>> >> support better integration with third party products. >>> >> >>> >> Parsing on client would be understandable if there was some middle >>> step >>> >> which would require some action from user, i.e, pick only some >>> tokens to >>> >> import. >>> > >>> >If we parse on the server side, how do we handle the long-running >>> >operation? Think of the case of importing hundreds or thousands of >>> >tokens... >>> Why then to do it as a IPA CLI command at all? >>> This is an administrative task which can be done with a separate >>> ipa-otp-import command, designated to run on IPA masters. >> >> Agreed. >> >> 1. Is there a framework for this? Or should it just be an independent >> script? > We don't really have a framework for administrative tools. You may start > with install/tools/ipa-adtrust-install, it is main part is relatively > independent of the task (which is in ipaserver/install/adtrustinstance.py) > The framework is there, new tools use it, and there's a ticket to convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's low priority in Future Releases, so not much progress is there...) Also see http://www.freeipa.org/page/V3/Logging_and_output -- Petr? From pviktori at redhat.com Fri Feb 28 15:29:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 16:29:14 +0100 Subject: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods In-Reply-To: <52F0F2CA.9070701@redhat.com> References: <52F0F2CA.9070701@redhat.com> Message-ID: <5310AB4A.3050800@redhat.com> On 02/04/2014 03:01 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Thanks, ACK. Here are some tests for this, do they look good? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0482-Test-fixed-modlist-generation-code.patch Type: text/x-patch Size: 2370 bytes Desc: not available URL: From redhatrises at gmail.com Fri Feb 28 15:39:41 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 28 Feb 2014 08:39:41 -0700 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: <5310871D.7050702@redhat.com> References: <5310871D.7050702@redhat.com> Message-ID: That does make more sense to merge them under the same note. I can also include a little blurb about ipa user-del and ipa group-remove-member. On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin wrote: > On 02/26/2014 04:01 PM, Gabe Alford wrote: > >> Hi all, >> >> I added a tip in the deleting users section on restoring admin account. >> Please review. >> >> https://fedorahosted.org/freeipa/ticket/2746 >> > > > Hello, > > The new tip is added right under a Note about the same thing (or a very > similar thing, from the user's POV). Would it be possible to merge those > two into a single Note? > > Nowadays[0], ipa user-del and ipa group-remove-member will refuse to > delete the last admin. I think this information should be added to the main > docs. (Also, this reduces the importance of the recovery instructions.) > > [0] https://fedorahosted.org/freeipa/ticket/2564 > > -- > Petr? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Feb 28 16:49:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Feb 2014 17:49:01 +0100 Subject: [Freeipa-devel] [PATCHES] 0483-0485 Move ipalib.text to ipapython Message-ID: <5310BDFD.5060003@redhat.com> Hello! This moves ipalib.text to ipapython. Why do we want this? Firstly, it's a step towards breaking the ipapython dependency on ipalib, which is something we vaguely want to do in the long run for the sake of clean code and potential reuse. But there's another reason: The DNS plugin defines some validators that are used elsewhere. I'd like to eventually move them to ipapython, so the DNS plugin can be made optional (https://fedorahosted.org/freeipa/ticket/4058). The validators use on ipalib.text, so that has to be moved to ipapython (where I think it belongs). The gettext wrappers in turn depend on the context, which I'd rather see in ipalib, but it's literally one line of code so it's not a big burden to have in ipapython. In the future we can think about somehow extracting it and moving it back, if needed. (And the first patch is just some general cleanup.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0483-ipalib.util-Remove-unused-function-validate_rdn_para.patch Type: text/x-patch Size: 941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0484-Move-request.context-to-ipapython.patch Type: text/x-patch Size: 2331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0485-Move-ipalib.text-to-ipapython.text.patch Type: text/x-patch Size: 79555 bytes Desc: not available URL: From npmccallum at redhat.com Fri Feb 28 19:36:12 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 28 Feb 2014 14:36:12 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <5310A4B2.9050900@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <53109DF0.2090206@redhat.com> <5310A4B2.9050900@redhat.com> Message-ID: <1393616172.3562.25.camel@localhost.localdomain> On Fri, 2014-02-28 at 10:01 -0500, Rob Crittenden wrote: > Petr Spacek wrote: > > On 28.2.2014 15:25, Nathaniel McCallum wrote: > >> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: > >>> On 28.2.2014 04:02, Rob Crittenden wrote: > >>>> Alexander Bokovoy wrote: > >>>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: > >>>>>> So the recent discussion on importing tokens led me to write a > >>>>>> script to > >>>>>> parse RFC 6030 xml files into IPA token data. This all works well. > >>>>>> But > >>>>>> now I need to integrate it into the IPA framework. > >>>>>> > >>>>>> This command will parse one or more xml files, creating a set of > >>>>>> tokens > >>>>>> to be added. Given that we already have otptoken-add on the > >>>>>> server-side, > >>>>>> it seems to me that all work needs to be done on the client-side. > >>>>>> How do > >>>>>> I create a new client-side command that calls existing server-side > >>>>>> API? > >>>>> subclass from frontend.Local, override run() or forward() method and > >>>>> perform batch > >>>>> operation of otptoken_add from there. > >>>>> > >>>>> See cli.help, for example. > >>>> > >>>> If you do an override, do forward() for cli-specific work. > >>>> > >>>> But you should do as little as possible for reasons you already stated: > >>>> the UI. Anything you do in forward Petr will need to implement in > >>>> the UI. > >>>> > >>>> Unfortunately we don't yet have a nice way to handle files. We have > >>>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > >>>> https://fedorahosted.org/freeipa/ticket/2933 > >>>> > >>>> If this file is something that would be pasted into a big text field > >>>> then you can probably handle it in a similarly clumsy way that we do > >>>> CSRs in the cert plugin. > >>>> > >>>> rob > >>> > >>> +1 for parsing it on server. Otherwise every client, not just CLI or Web > >>> UI, would have to reimplement the same logic - having it on server will > >>> support better integration with third party products. > >>> > >>> Parsing on client would be understandable if there was some middle step > >>> which would require some action from user, i.e, pick only some tokens to > >>> import. > >> > >> If we parse on the server side, how do we handle the long-running > >> operation? Think of the case of importing hundreds or thousands of > >> tokens... > > > > My experience is that operation on server side can run for (at least) > > few minutes without a problem. I haven't try longer periods but we can > > check that. > > It can run for hours. Migration performance in IPA used to be rather > pitiful and migrating several thousand users could easily take 5+ hours. > IIRC sometimes the client would time out but the server side would still > complete, you just got no feedback. In this case, feedback is pretty crucial. We will validate all the tokens before writing any of them, so this feedback could be pretty quick. However, if an error occurs during writing, we need to continue adding all the tokens and give an error report at the end of all the tokens that weren't added. Ideally, this report should be in the same import xml format that was provided. Nathaniel From rcritten at redhat.com Fri Feb 28 20:48:43 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 15:48:43 -0500 Subject: [Freeipa-devel] server install failing in F-20? Message-ID: <5310F62B.5030206@redhat.com> I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. rob From abokovoy at redhat.com Fri Feb 28 22:05:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 1 Mar 2014 00:05:37 +0200 Subject: [Freeipa-devel] server install failing in F-20? In-Reply-To: <5310F62B.5030206@redhat.com> References: <5310F62B.5030206@redhat.com> Message-ID: <20140228220537.GB3638@redhat.com> On Fri, 28 Feb 2014, Rob Crittenden wrote: >I'm seeing what looks like >https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I >stood up. I finally threw my hands up and configured system to use an >environment file to work around it. > >Not sure if anyone else is seeing this. One difference on F20 is that you are not supposed to see ccaches in /tmp -- they are in the kernel keyring. -- / Alexander Bokovoy