Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/16/2012 05:41 AM, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: .. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1/14]: creating certificate server user [2/14]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Root cause: ... File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 625, in __spawn_instance /root/cacert.p12) ... I need to look into this. I had fixed ipa-replica-install, rather than ipa-ca-install to create replicas. I didn't know ipa-ca-install existed! Should not be too bad to fix though - most likely just need to move files to the right place. Ok, thanks! Btw. CA on replica can be either installed during ipa-replica-install time (when --setup-ca option is passed, you probably used that one) and the aforementioned ipa-ca-install run after ipa-replica-install. I will be testing this out again. As ipa-ca-install uses the same code as ipa-replica-install, I would have expected it to work. Did you try it with selinux in permissive mode? I had SELinux en enforcing mode. ipa-server-install with SELinux worked fine, so I thought that replica installation will work fine too. I will re-test with SELinux turned off. ... 7) pki-deploy package does not require any other pki-* package, this does not look ok. This way I was able to have pki-ca-9.* and pki-deploy-10.* installed at one time. I doubt it would work that way. We have opened a dogtag ticket to address this. Some kind of dependency will be added so that pki-deploy and pki-common-10 are co-dependencies. 8) Did you test upgrade from installed IPA+dogtag9 to patchedIPA+dogtag10? I did that on Fedora 17 and pki-ca did not start after upgrade. Attaching logs my VM after I tried to (re)start pki-ca. I did test this. From the logs though, this looks very much like it is not starting because of selinux. Can you try to restart with selinux permissive? I fully expect there to be selinux issues here as some changes are required in the base policy where the default ports are defined. Ok then. I will test it with permissive SELinux as well. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would be created using dogtag 10. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install
Re: [Freeipa-devel] [PATCH 0046] Separate RR data parsing from LDAP connections
On Wed, Aug 15, 2012 at 04:04:26PM +0200, Petr Spacek wrote: On 08/15/2012 03:31 PM, Adam Tkac wrote: On Wed, Aug 01, 2012 at 04:19:11PM +0200, Petr Spacek wrote: Hello, this patch finishes LDAP connection vs. LDAP result separation. It is first step necessary for: https://fedorahosted.org/bind-dyndb-ldap/ticket/68 Avoid manual connection management outside ldap_query() It should prevent deadlocks in future. Petr^2 Spacek ... I recommend to use ZERO_PTR(ldap_qresult) instead of many = NULL assignments. It's safer and used in other *_create functions. Amended patch is attached. Ack -- Adam Tkac, Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0046] Separate RR data parsing from LDAP connections
On 08/16/2012 11:01 AM, Adam Tkac wrote: On Wed, Aug 15, 2012 at 04:04:26PM +0200, Petr Spacek wrote: On 08/15/2012 03:31 PM, Adam Tkac wrote: On Wed, Aug 01, 2012 at 04:19:11PM +0200, Petr Spacek wrote: Hello, this patch finishes LDAP connection vs. LDAP result separation. It is first step necessary for: https://fedorahosted.org/bind-dyndb-ldap/ticket/68 Avoid manual connection management outside ldap_query() It should prevent deadlocks in future. Petr^2 Spacek ... I recommend to use ZERO_PTR(ldap_qresult) instead of many = NULL assignments. It's safer and used in other *_create functions. Amended patch is attached. Ack Pushed to master: https://fedorahosted.org/bind-dyndb-ldap/changeset/ce547f03a86fbbcdb2db0629da615f04a35579b8 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1044 DN ldap syntax exception
On 08/15/2012 10:31 PM, Rob Crittenden wrote: Raise the proper IPA exception when a value isn't a valid DN. rob Works fine. ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1043 fix ipa-replica-manage connect
On 08/15/2012 07:59 PM, Rob Crittenden wrote: A dn needed to be converted to a DN object. rob Good catch, I re-tested all ipa-replica-manage actions and they worked fine. ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1045 selinuxusermap fixes
On 08/15/2012 11:23 PM, Rob Crittenden wrote: Fix setting the user in a rule using setattr. We weren't verifying that it was in the ordered list. I also noticed that no mls was allowed when it shouldn't be. Made that required. rob ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 77] Ticket #2584 - Installation fails when CN is set in, certificate subject base
On 08/16/2012 03:53 AM, John Dennis wrote: From 32cf59ac8963982d2de59562f3f1570e67e92a3e Mon Sep 17 00:00:00 2001 From: John Dennis jden...@redhat.com Date: Wed, 15 Aug 2012 21:33:15 -0400 Subject: [PATCH 77] Ticket #2584 - Installation fails when CN is set in certificate subject base ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new
Re: [Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection
On Wed, Aug 15, 2012 at 03:55:01PM +0200, Petr Spacek wrote:
On 08/15/2012 03:11 PM, Adam Tkac wrote:
On Fri, Jul 27, 2012 at 12:16:07PM +0200, Petr Spacek wrote:
Hello,
this patch implements Flush zones and RRs cache when handling
persistent search reconnection behaviour as requested
in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/44 .
Petr^2 Spacek
+isc_result_t
+flush_ldap_cache(ldap_cache_t *cache)
+{
+ isc_result_t result;
+
+ REQUIRE(cache != NULL);
+
+ LOCK(cache-mutex);
+ if (!ldap_cache_enabled(cache)) {
+ result = ISC_R_SUCCESS;
+ } else {
+ dns_rbt_destroy(cache-rbt);
+ CHECK(dns_rbt_create(cache-mctx, cache_node_deleter, NULL,
+ cache-rbt));
In my opinion usage of dns_rbt_deletename(cache-rbt, dns_rootname,
ISC_TRUE) is
better, isn't it?
I looked into implementation of both functions. dns_rbt_deletenode()
does horribly complicated magic for simple task as delete whole
tree is.
For this reason I called dns_rbt_destroy() - it is much simpler and
should be faster (it doesn't try to maintain RBT invariants during
whole process).
Sounds fine, ack for the patch as is.
A
Otherwise OK.
+ }
+
+cleanup:
+ if (result != ISC_R_SUCCESS)
+ log_error_r(cache flush failed);
+ UNLOCK(cache-mutex);
+ return result;
+}
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably
Re: [Freeipa-devel] [PATCH] trust CLI: add ID range for new trusted domain
On Tue, 14 Aug 2012, Sumit Bose wrote: Hi, currently only a default ID range was used for users from trusted domains. With these two patches an individual range is created during ipa trust-add and it will be used by the extdom plugin to calculate the Poisx UID for the users from the trusted domain. 'ipa trust-add' is getting two new options, --base-id and --range-size to specify the first Posix ID of the range and the size of the range respectively. If --range-size is not given the default will be 20 and if --base-id is not given it will be calculated with the help of a hash of the domain SID. To be compatible with the AD provider of SSSD murmurhash3 is used here. The python binding for the hash will be provided by SSSD, the patch is currently under review. But since it is not required to have murmurhash3, an error message will be send if it is not installed on the server, I think this patch can be pushed independently of the SSSD patch. ACK with one fix (attached): ignore missing murmurhash python module and samba4/server code. This will be required if building client-side only since ipalib/plugins/trust.py will be included into the client tarball. -- / Alexander Bokovoy From 86a336823c8de7ccba4edfbe7bd5ccf88f0f3d7c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Thu, 16 Aug 2012 19:57:30 +0300 Subject: [PATCH 4/5] Ignore lint errors if pysssd_murmur and samba4 support not installed when building client code. Since ipalib.plugins.trust has both client-side and server-side code, this is the only way to properly handle linting errors. --- ipalib/plugins/trust.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 1064a06783892f27c56f0310046216881db5b42a..f19a0a874057860d0ae32f1cc2336bdc3accf6e5 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -25,14 +25,14 @@ from ipalib import errors from ipapython import ipautil from ipalib import util try: -import pysss_murmur +import pysss_murmur #pylint: disable=F0401 _murmur_installed = True except Exception, e: _murmur_installed = False if api.env.in_server and api.env.context in ['lite', 'server']: try: -import ipaserver.dcerpc +import ipaserver.dcerpc #pylint: disable=F0401 _bindings_installed = True except Exception, e: _bindings_installed = False -- 1.7.11.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] trust CLI: add ID range for new trusted domain
Alexander Bokovoy wrote: On Tue, 14 Aug 2012, Sumit Bose wrote: Hi, currently only a default ID range was used for users from trusted domains. With these two patches an individual range is created during ipa trust-add and it will be used by the extdom plugin to calculate the Poisx UID for the users from the trusted domain. 'ipa trust-add' is getting two new options, --base-id and --range-size to specify the first Posix ID of the range and the size of the range respectively. If --range-size is not given the default will be 20 and if --base-id is not given it will be calculated with the help of a hash of the domain SID. To be compatible with the AD provider of SSSD murmurhash3 is used here. The python binding for the hash will be provided by SSSD, the patch is currently under review. But since it is not required to have murmurhash3, an error message will be send if it is not installed on the server, I think this patch can be pushed independently of the SSSD patch. ACK with one fix (attached): ignore missing murmurhash python module and samba4/server code. This will be required if building client-side only since ipalib/plugins/trust.py will be included into the client tarball. Pushed all three to master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 78] Ticket #2979 - prevent last admin from being disabled
--
John Dennis jden...@redhat.com
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
From c47109c63530e188db76986fdda48c76bf681d10 Mon Sep 17 00:00:00 2001
From: John Dennis jden...@redhat.com
Date: Thu, 16 Aug 2012 20:28:44 -0400
Subject: [PATCH 78] Ticket #2979 - prevent last admin from being disabled
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
We prevent the last member of the admin group from being deleted. The
same check needs to be performed when disabling a user.
Moved the code in del_user to a common subroutine and call it from
both user_del and user_disable. Note, unlike user_del user_disable
does not have a 'pre' callback therefore the check function is called
in user_disable's execute routine.
---
ipalib/plugins/user.py | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 529699f..3cc667b 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -166,6 +166,17 @@ def normalize_principal(principal):
return unicode('%s@%s' % (user, realm))
+def check_protected_member(user, protected_group_name=u'admins'):
+'''
+Ensure the last member of a protected group cannot be deleted or
+disabled by raising LastMemberError.
+'''
+
+result = api.Command.group_show(protected_group_name)
+if result['result'].get('member_user', []) == [user]:
+raise errors.LastMemberError(key=user, label=_(u'group'),
+container=protected_group_name)
+
class user(LDAPObject):
User object.
@@ -550,11 +561,7 @@ class user_del(LDAPDelete):
def pre_callback(self, ldap, dn, *keys, **options):
assert isinstance(dn, DN)
-protected_group_name = u'admins'
-result = api.Command.group_show(protected_group_name)
-if result['result'].get('member_user', []) == [keys[-1]]:
-raise errors.LastMemberError(key=keys[-1], label=_(u'group'),
-container=protected_group_name)
+check_protected_member(keys[-1])
return dn
api.register(user_del)
@@ -679,8 +686,9 @@ class user_disable(LDAPQuery):
def execute(self, *keys, **options):
ldap = self.obj.backend
-dn = self.obj.get_dn(*keys, **options)
+check_protected_member(keys[-1])
+dn = self.obj.get_dn(*keys, **options)
ldap.deactivate_entry(dn)
return dict(
--
1.7.11.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 293 Bump bind-dyndb-ldap version in spec file
The updated version of the BIND LDAP plugin includes completed
support of DNS zone transfers. With the new version, users will be
able to configure slave DNS servers for IPA master DNS server.
From 138a488e79f74c32aeff7ccc40989c7af62d00ca Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Fri, 17 Aug 2012 07:32:14 +0200
Subject: [PATCH] Bump bind-dyndb-ldap version in spec file
The updated version of the BIND LDAP plugin includes completed
support of DNS zone transfers. With the new version, users will be
able to configure slave DNS servers for IPA master DNS server.
---
freeipa.spec.in | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 84aaa0dfe5d553ab2fa57779ac019529a3953cc4..a7b9fa1b6adcc36c2aa2f908815391dd714beb93 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -176,7 +176,7 @@ Requires: keyutils
# IPA but if it is configured we need a way to require versions
# that work for us.
%if 0%{?fedora} = 18
-Conflicts: bind-dyndb-ldap 1.1.0-0.15.rc1
+Conflicts: bind-dyndb-ldap 1.1.0-0.16.rc1
%else
Conflicts: bind-dyndb-ldap 1.1.0-0.12.rc1
%endif
@@ -751,6 +751,10 @@ fi
%ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt
%changelog
+* Thu Aug 17 2012 Martin Kosek mko...@redhat.com - 2.99.0-41
+- Set min for bind-dyndb-ldap to 1.1.0-0.16.rc1 to pick up complete zone transfer
+ support
+
* Thu Aug 2 2012 Martin Kosek mko...@redhat.com - 2.99.0-40
- Set min for bind-dyndb-ldap to 1.1.0-0.15.rc1 to pick up SOA serial autoincrement
feature
--
1.7.11.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
