Re: [Freeipa-devel] Release platforms for 4.0
On 4.7.2014 17:13, Martin Kosek wrote: Given that Fedora 20 is now in stable phase and FreeIPA 4.0 adds a lot of functionality, we agreed that we will not publish FreeIPA 4.0 in stable Fedora 20 updates now. When releasing 4.0, we need to: 1) Prepare a COPR build for Fedora 20 with all dependencies that are not in Fedora 20 yet. AFAIK, it should be just FreeIPA as new bind-dyndb-ldap and 389-ds-base are in updates-testing. 2) Prepare Fedora 21 build. It may not be so simple, there may be issues with other software or dependencies - we may need to patch FreeIPA or file bugs right away. I did some very basic testing on Rawhide: Build installation worked for me without any change to code. Very basic functionality (installation, WebUI, DNS) is working. I didn't test neither OTP nor Trusts. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0617 makeaci: Use the DN where the ACI is stored, not the permission's DN
On Mon, 2014-07-07 at 09:42 +0200, Petr Viktorin wrote: Hello, One last patch I'd like to get in before the fork. I noticed ACI.txt file is not as helpful as it could be because it lists the permission's DN, not the DN where the ACI is. Here's the fix. One-liner (if you don't count ACI.txt), and doesn't touch installed code. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, it works for me -- Martin^2 Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0617 makeaci: Use the DN where the ACI is stored, not the permission's DN
On 07/07/2014 11:55 AM, Martin Basti wrote: On Mon, 2014-07-07 at 09:42 +0200, Petr Viktorin wrote: Hello, One last patch I'd like to get in before the fork. I noticed ACI.txt file is not as helpful as it could be because it lists the permission's DN, not the DN where the ACI is. Here's the fix. One-liner (if you don't count ACI.txt), and doesn't touch installed code. ACK, it works for me Thanks! Pushed to master: afe067b1ab9b224080ca05b906e9dfd50c40c59b -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ready to release?
Hi, On 4.7.2014 17:34, Petr Spacek wrote: On 4.7.2014 17:20, Petr Viktorin wrote: On 07/04/2014 04:57 PM, Martin Kosek wrote: Hello developers! I would like to thank everyone for the hard work during the last weeks, when finishing the FreeIPA 4.0 release, I saw many last stabilization fixes in DNS, OTP, ACIs, upgrade and Web UI areas. The last major work that is still not pushed is the CA management tool. Unfortunately, the final development and review did not go so well and we still do not have final patches. Given that this is a major piece of work (50 patches) and given that the reviewer is on a leave, I am considering moving the feature to next release - FreeIPA 4.1 which is short and would still make it to Fedora 21. I would not like to stall 4.0 any more, I would like to offer all the work we have done for wider testing as soon as possible. Thoughts? Any other last patches you would like to add to add to 4.0 GA? There is still little time, but remember, git tag hammer is ready to fire. I'm testing these two: - mbasti-0098-100, DNS tests - mkosek-478, Spec bump Then there's pvoborni-695 with only a functional ACK The CA management is still up for discussion, but it's more and more likely We have deferred 'full' DNSSEC support already so it is not unprecedented. I have one proposal (valid only if we decide to defer CA management): Maybe we could release 4.1 in few weeks when DNSSEC and CA management are done properly reviewed. That would allow us to follow 'release early, release often' lore. In my opinion, smaller release = safer. Of course, it would mean shifting current version numbers from 4.x to 4.(x+1), sorry Martin! :-) I'm fine with deferring CA management. I could fix the remaining issues in time, but Rob, who is reviewing the patches, is on PTO and IMO the code could use some more testing before releasing it into the wild. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses
On 07/04/2014 04:18 PM, Petr Spacek wrote: On 4.7.2014 16:14, Martin Basti wrote: On Fri, 2014-07-04 at 16:12 +0200, Petr Spacek wrote: On 3.7.2014 15:30, Petr Vobornik wrote: API responses can contain warnings in messages array. This patch also adds support for displaying multiple notifications at the same time in order to show the message and a status of finished operation. Notes: - was implemented because of https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 -- test by modifying Master DNS Zone which has a Zone forwarder set. - I'd like to move the notification code to separate module in a future and then extend it according to PatternFly pattern which is currently under developemnt (should contain history, ...). ACK from functional perspective. It properly displays warnings about DNS zones and DNSSEC. It can be pushed if there is no problem in the code, I can't really check that. Was there any problem with hardcoded '/n' in warning message text? It works for me - the text is wrapped, I don't see any glitch. Pushed to master: d0c12fb0c0a892f61a5a6127069737fdab2c107d -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0618 Update translations
Once again, I have pushed updated translations from Transifex to master. The patch is huge, so I've not attached it. Use your Git client to get it. It's commit 518c8a5f9da906483d63f57908f7a47be9902ea5 Thanks to all translators! install/po/LINGUAS |2 + install/po/bn_IN.po |4 +- install/po/ca.po|4 +- install/po/cs.po|4 +- install/po/de.po|4 +- install/po/es.po|7 +- install/po/eu.po|4 +- install/po/fr.po| 462 +--- install/po/hi.po| 81 +++ install/po/hu.po| 167 + install/po/id.po|4 +- install/po/ipa.pot | 1620 - install/po/ja.po|4 +- install/po/kn.po|4 +- install/po/nl.po|4 +- install/po/pl.po|7 +- install/po/ru.po|4 +- install/po/tg.po|4 +- install/po/uk.po| 986 ++--- install/po/zh_CN.po |4 +- 20 files changed, 1975 insertions(+), 1405 deletions(-) -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade
On 30.6.2014 17:38, Simo Sorce wrote: On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: On 23.6.2014 17:49, Martin Basti wrote: On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: Hello, I have following issues: #1 Upgrading existing replicas to support DNSSEC won't work for current design (replica-file as storage for temporal replica key). Temporal private key needs to be copied to replica, and no encrypted master-key for replica is prepared in LDAP, because user doesn't need to run ipa-replica-prepare. After discussion with Petr2, the solution is: a) Each replica (except first - which generates master-key) generates replica public and private keys. b) Replica uploads public key to LDAP c) Replica with generated master key, use the public key (b) to encrypt master-key and store it to LDAP. Replica with master-key must detect, if there is any new public replica key. d) Replica (b) is now able to get master-key using own private replica key #2 We need to choose only one replica which will generate, (rotate, ...) DNSSEC keys. and generate master key too My proposal is to test during installation/upgrade if any dnssec/master keys are in LDAP. If no key was found, the first server is installed/upgraded and DNSSEC key generator is required. But there is issue with parallel upgrade multiple replicas (or if replication temporarily doesn't work). There is no guarantee if replicas will be able to detect if any replica became DNSSEC key generator. Let me add that we are going to use syncrepl anyway so the overall latency should be minimal (if replication works). Simo what do you think about it, could you tell us your opinion? I think DNSSEC should not be enabled by default, so on upgrade no action should be taken. Activation/upgrade of DNSSEC feature should be manual so that no conflict can arise. I think we can do a compromise. First of all, DNSSEC will not be enabled until admin explicitly decides to do so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see any change if the DNSSEC checkbox is not enabled for at least one DNS zone. IMHO it is reasonable to automatically install dependencies we need during upgrade. I.e. to install softhsm package to every replica by default and also generate replica keys (wrapping keys) by default. I agree that key-master-server election (used in IPA 4.1) can be done manually. I.e. all replica keys will be generated automatically but admin has to run something like ipa-dns-install --dnssec-master on one replica to explicitly mark one replica as key generator. This replica will run OpenDNSSEC daemon responsible for key maintenance. This approach will save us terrible headache from manual dependency installation and situations where DNSSEC-feature-dependencies were installed on some replicas but are not present on all of them etc. Do you agree? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0619 Become IPA 4.0.0
Pushed as 1e58588ec274d5da0f020b2c6af2824313ea0ea7 Tagged as release-4-0-0 -- Petr³ From 1e58588ec274d5da0f020b2c6af2824313ea0ea7 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Mon, 7 Jul 2014 16:46:21 +0200 Subject: [PATCH] Become IPA 4.0.0 --- VERSION | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/VERSION b/VERSION index 78baf5a..2a2789a 100644 --- a/VERSION +++ b/VERSION @@ -18,9 +18,9 @@ # IPA_VERSION_RELEASE=0 # # - 1.0.0 # -IPA_VERSION_MAJOR=3 -IPA_VERSION_MINOR=3 -IPA_VERSION_RELEASE=90 +IPA_VERSION_MAJOR=4 +IPA_VERSION_MINOR=0 +IPA_VERSION_RELEASE=0 # For 'pre' releases the version will be # -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade
On Mon, 2014-07-07 at 16:10 +0200, Petr Spacek wrote: On 30.6.2014 17:38, Simo Sorce wrote: On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: On 23.6.2014 17:49, Martin Basti wrote: On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: Hello, I have following issues: #1 Upgrading existing replicas to support DNSSEC won't work for current design (replica-file as storage for temporal replica key). Temporal private key needs to be copied to replica, and no encrypted master-key for replica is prepared in LDAP, because user doesn't need to run ipa-replica-prepare. After discussion with Petr2, the solution is: a) Each replica (except first - which generates master-key) generates replica public and private keys. b) Replica uploads public key to LDAP c) Replica with generated master key, use the public key (b) to encrypt master-key and store it to LDAP. Replica with master-key must detect, if there is any new public replica key. d) Replica (b) is now able to get master-key using own private replica key #2 We need to choose only one replica which will generate, (rotate, ...) DNSSEC keys. and generate master key too My proposal is to test during installation/upgrade if any dnssec/master keys are in LDAP. If no key was found, the first server is installed/upgraded and DNSSEC key generator is required. But there is issue with parallel upgrade multiple replicas (or if replication temporarily doesn't work). There is no guarantee if replicas will be able to detect if any replica became DNSSEC key generator. Let me add that we are going to use syncrepl anyway so the overall latency should be minimal (if replication works). Simo what do you think about it, could you tell us your opinion? I think DNSSEC should not be enabled by default, so on upgrade no action should be taken. Activation/upgrade of DNSSEC feature should be manual so that no conflict can arise. I think we can do a compromise. First of all, DNSSEC will not be enabled until admin explicitly decides to do so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see any change if the DNSSEC checkbox is not enabled for at least one DNS zone. IMHO it is reasonable to automatically install dependencies we need during upgrade. I.e. to install softhsm package to every replica by default and also generate replica keys (wrapping keys) by default. I agree that key-master-server election (used in IPA 4.1) can be done manually. I.e. all replica keys will be generated automatically but admin has to run something like ipa-dns-install --dnssec-master on one replica to explicitly mark one replica as key generator. This replica will run OpenDNSSEC daemon responsible for key maintenance. This approach will save us terrible headache from manual dependency installation and situations where DNSSEC-feature-dependencies were installed on some replicas but are not present on all of them etc. Do you agree? Sounds reasonable. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] git branching after 4.0
On 07/04/2014 05:26 PM, Martin Kosek wrote: When 4.0 releases, there will be several development trains that we will need to manage in our git: 1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to ipa-4-0 branch ipa-4-0 branched 2) FreeIPA 4.1 small development - 4.1 will be just a short release for the summer focused on Views, full support of DNSSEC, OTP local high watermark, Backup and Restore and other small features (and possibly also CA management tool). ipa-4-1 branched 3) FreeIPA 4.2 big development - this is a longer, more in the future (read Fedora 22 time frame) development with major features going in - Vault, User provisioning, publishing CA certs to clients and many others stuff still being scoped. It will include for example big updates to installers which should not go to more stable 4.1/4.0.x releases. this will be master How to handle that in git repo? Given that we do not do merge commits, I think the easiest way would be to: - When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will leave us with master, ipa-4-1, ipa-4-0 active branches - 4.2 team will commit their work to master only - 4.1 team will commit their work to master, ipa-4-1 - 4.0.x bugfixing team will commit their work to master, ipa-4-1 and ipa-4-0 This may sound complicated, but with Petr's ipatool pushing to multiple branches should be easy. Our CI should guard at least ipa-4-0 and ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to report failures early. I've update the tool to take new milestones into account. If you use the tool, please pull the changes. If there is a better idea, please propose it. But this plan seemed to me as the most straightforward. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ready to release?
On Fri, 2014-07-04 at 17:34 +0200, Petr Spacek wrote: On 4.7.2014 17:20, Petr Viktorin wrote: On 07/04/2014 04:57 PM, Martin Kosek wrote: Hello developers! I would like to thank everyone for the hard work during the last weeks, when finishing the FreeIPA 4.0 release, I saw many last stabilization fixes in DNS, OTP, ACIs, upgrade and Web UI areas. The last major work that is still not pushed is the CA management tool. Unfortunately, the final development and review did not go so well and we still do not have final patches. Given that this is a major piece of work (50 patches) and given that the reviewer is on a leave, I am considering moving the feature to next release - FreeIPA 4.1 which is short and would still make it to Fedora 21. I would not like to stall 4.0 any more, I would like to offer all the work we have done for wider testing as soon as possible. Thoughts? Any other last patches you would like to add to add to 4.0 GA? There is still little time, but remember, git tag hammer is ready to fire. I'm testing these two: - mbasti-0098-100, DNS tests - mkosek-478, Spec bump Then there's pvoborni-695 with only a functional ACK The CA management is still up for discussion, but it's more and more likely We have deferred 'full' DNSSEC support already so it is not unprecedented. I have one proposal (valid only if we decide to defer CA management): Maybe we could release 4.1 in few weeks when DNSSEC and CA management are done properly reviewed. That would allow us to follow 'release early, release often' lore. In my opinion, smaller release = safer. Of course, it would mean shifting current version numbers from 4.x to 4.(x+1), sorry Martin! :-) I like this plan. 4.1 could cover just DNSSEC, CA management and 4.0 fixes. The original plan for 4.1 could become 4.2. I don't think the change in version numbers would imply a change in overall timing. I completely agree that smaller releases are better. :) Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Ready to release
On 07/04/2014 04:57 PM, Martin Kosek wrote: Hello developers! I would like to thank everyone for the hard work during the last weeks, when finishing the FreeIPA 4.0 release, I saw many last stabilization fixes in DNS, OTP, ACIs, upgrade and Web UI areas. [...] Thoughts? Any other last patches you would like to add to add to 4.0 GA? There is still little time, but remember, git tag hammer is ready to fire. The tag hammer came down, FreeIPA 4.0.0 is ready to be released. It's getting late today, and the ARM build looks like it'll need another few hours, so I'll send the announcement and update the remaining Wiki pages tomorrow morning (CET). But you can already go ahead and try 4.0 out or check the release notes. Release notes: http://www.freeipa.org/page/Releases/4.0.0 Download page: http://www.freeipa.org/page/Downloads SHA1: 0021d15a0ec38276916014c85acc0009f3b0e279 MD5: 84ee2352f153074e2ace1d04ba4c2efb Packages for Fedora Rawhide (f21) are waiting for the ARM build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7113930 Fedora 20 COPR repository: https://copr.fedoraproject.org/coprs/pviktori/freeipa/ This is under my name, since COPR is tied to Fedora accounts. If you have git commit rights, I'll be glad to give you build/admin rights for the COPR -- you just need to request them in the Permissions tab. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
