Re: [Freeipa-devel] [PATCH] test speedup patch
On 01/19/2011 04:17 AM, Rob Crittenden wrote: Rob Crittenden wrote: Rob Crittenden wrote: Attached is a rough cut of a patch to try to speed up the cli a little bit. Basically in production mode it will skip some things during initialization. My concept is that we develop in mode != production and release in mode == production. I managed to knock a second or so off time to do a user-show on average. There may be some other things we can do to speed things up, I'm still looking. Some feedback on the approach would be appreciated. Note that I've completely ruled out SSL/Negotiate. I did my testing on lite-server which doesn't use SSL or Negotiate and it was STILL taking on average 3-4+ seconds per command. The server side was consistently taking 1 second to complete. rob oh, and the patch. I ran a couple of moderate tests this evening that executed 42 separate operations like add, delete, and managing group membership. I ran this 10 times each on 2 identical VMs, one with a bit older code and one with this patch then averaged the times. With the patch the average was 1.3 seconds per operation, without 2.6. A 50% improvement is more than I expected, I saw a 33% improvement on individual runs. I'll keep at it but this seems promising. I was also a bit surprised that the average time without the patch was so low, I was expecting something over 3 seconds. Specifically what this patch does is it avoids doing some self-validation. There is some amount of risk that the framework could blow up but in a deployed situation I think the risk is rather low. A side-effect of the API tester makeapi is that it loads the framework. We can force it to be run in production mode so the product shouldn't be buildable if it has inconsistencies. rob I find it hard to believe this patch causes such a big improvement in performance. Especially the parts skipping asserts, that shouldn't be significantly slower than your average ifs. Instance locking shouldn't be a time consuming operation either. Bypassing check routines for parameter namespaces might provide a performance boost as it is called for every single plugin we have (~250). On the other hand, it is only used for positional arguments and most plugins only have 1 or 2 of those. Personally, I would do some more tests on a single machine, because there's no guarantee, that two VMs with an identical image have the same performance. If it really provides a significant improvement, than it's awesome, because I like the philosophy of this patch. It removes self-checking and instance locking, that is completely useless in a production environment and kind of limiting in non-production. I think there's more places likes this in the framework. Long story short: It's improbable, but not impossible, for the changes introduced by this patch to cause such a big performance improvement. Even if it doesn't, the patch is still good. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 680 ldap lockout
Rob Crittenden rcrit...@redhat.com wrote: Rob Crittenden wrote: Jan Zeleny wrote: Rob Crittendenrcrit...@redhat.com wrote: Update kerberos password policy values on LDAP binds. This is so locked-out accounts in kerberos don't try things using LDAP instead. On a failed bind this will update krbLoginFailedCount and krbLastFailedAuth and will potentially fail the bind altogether. On a successful bind it will zero krbLoginFailedCount and set krbLastSuccessfulAuth. This will also enforce locked-out accounts. See http://k5wiki.kerberos.org/wiki/Projects/Lockout for details on kerberos lockout. ticket 343 Ack, good job Jan Simo and Nathan pointed out that the update model I'm using is vulnerable to multi-threaded attack and suggested that rather than using REPLACE I do a DELETE/ADD to be sure that I'm updating the counter appropriately. I've got the basics done, need to re-run through valgrind. Will submit another patch shortly. rob Updated patch attached. Be more careful when updating the failed count. rob The patch looks good and it works fine, if Simo doesn't have any more security comments: ACK. Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 680 ldap lockout
On Wed, 19 Jan 2011 14:15:05 +0100 Jan Zelený jzel...@redhat.com wrote: Rob Crittenden rcrit...@redhat.com wrote: Rob Crittenden wrote: Jan Zeleny wrote: Rob Crittendenrcrit...@redhat.com wrote: Update kerberos password policy values on LDAP binds. This is so locked-out accounts in kerberos don't try things using LDAP instead. On a failed bind this will update krbLoginFailedCount and krbLastFailedAuth and will potentially fail the bind altogether. On a successful bind it will zero krbLoginFailedCount and set krbLastSuccessfulAuth. This will also enforce locked-out accounts. See http://k5wiki.kerberos.org/wiki/Projects/Lockout for details on kerberos lockout. ticket 343 Ack, good job Jan Simo and Nathan pointed out that the update model I'm using is vulnerable to multi-threaded attack and suggested that rather than using REPLACE I do a DELETE/ADD to be sure that I'm updating the counter appropriately. I've got the basics done, need to re-run through valgrind. Will submit another patch shortly. rob Updated patch attached. Be more careful when updating the failed count. rob The patch looks good and it works fine, if Simo doesn't have any more security comments: ACK. Patch looks good to me. I only wonder if it would make sense to try to cache the entry between the pre-op and the post-op, but given it is just fetched I guess DS caches it in memory anyways, so probably not a big deal in any case. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] test speedup patch
Pavel Zuna wrote: On 01/19/2011 04:17 AM, Rob Crittenden wrote: Rob Crittenden wrote: Rob Crittenden wrote: Attached is a rough cut of a patch to try to speed up the cli a little bit. Basically in production mode it will skip some things during initialization. My concept is that we develop in mode != production and release in mode == production. I managed to knock a second or so off time to do a user-show on average. There may be some other things we can do to speed things up, I'm still looking. Some feedback on the approach would be appreciated. Note that I've completely ruled out SSL/Negotiate. I did my testing on lite-server which doesn't use SSL or Negotiate and it was STILL taking on average 3-4+ seconds per command. The server side was consistently taking 1 second to complete. rob oh, and the patch. I ran a couple of moderate tests this evening that executed 42 separate operations like add, delete, and managing group membership. I ran this 10 times each on 2 identical VMs, one with a bit older code and one with this patch then averaged the times. With the patch the average was 1.3 seconds per operation, without 2.6. A 50% improvement is more than I expected, I saw a 33% improvement on individual runs. I'll keep at it but this seems promising. I was also a bit surprised that the average time without the patch was so low, I was expecting something over 3 seconds. Specifically what this patch does is it avoids doing some self-validation. There is some amount of risk that the framework could blow up but in a deployed situation I think the risk is rather low. A side-effect of the API tester makeapi is that it loads the framework. We can force it to be run in production mode so the product shouldn't be buildable if it has inconsistencies. rob I find it hard to believe this patch causes such a big improvement in performance. Especially the parts skipping asserts, that shouldn't be significantly slower than your average ifs. Instance locking shouldn't be a time consuming operation either. I'm equally unbelieving! In my dev tree I was seeing 3.9 second+ times without the patch. With the patch I was still often seeing 3+ seconds but sometimes it would be significantly lower. This is a VM so who knows what other stuff is going on. I agree that locking shouldn't be that slow but cumulatively it is a bit of a drag. Similarly the assert p.instance.api is self is quite slow. Bypassing check routines for parameter namespaces might provide a performance boost as it is called for every single plugin we have (~250). On the other hand, it is only used for positional arguments and most plugins only have 1 or 2 of those. I believe that bypassing the check routines is where the biggest boost comes from. check_name() is also skipped and that does a regex match. Personally, I would do some more tests on a single machine, because there's no guarantee, that two VMs with an identical image have the same performance. Using 2 machines lets me test code without having to constantly re-install the bits or apply patches. It is easier to track the state so I don't end up with meaningless data :-) I'll stick the meager tests I have into a while loop and let it run for longer than 10 iterations to get a better idea of what is going on. If it really provides a significant improvement, than it's awesome, because I like the philosophy of this patch. It removes self-checking and instance locking, that is completely useless in a production environment and kind of limiting in non-production. I think there's more places likes this in the framework. Long story short: It's improbable, but not impossible, for the changes introduced by this patch to cause such a big performance improvement. Even if it doesn't, the patch is still good. Well, this is why I sent the patch out for a pre-review :-) rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] test speedup patch
Just tested. I do see a performance increase of ~30% Without the Patch time ipa user-find -- 1 user matched -- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Account activation status: False Member of groups: admins Number of entries returned 1 real 0m1.558s user 0m0.810s sys 0m0.165s With the Patch time ipa user-find -- 1 user matched -- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Account disabled: False Member of groups: admins Number of entries returned 1 real 0m1.067s user 0m0.841s sys 0m0.157s On 1/18/11 7:17 PM, Rob Crittenden rcrit...@redhat.com wrote: Rob Crittenden wrote: Rob Crittenden wrote: Attached is a rough cut of a patch to try to speed up the cli a little bit. Basically in production mode it will skip some things during initialization. My concept is that we develop in mode != production and release in mode == production. I managed to knock a second or so off time to do a user-show on average. There may be some other things we can do to speed things up, I'm still looking. Some feedback on the approach would be appreciated. Note that I've completely ruled out SSL/Negotiate. I did my testing on lite-server which doesn't use SSL or Negotiate and it was STILL taking on average 3-4+ seconds per command. The server side was consistently taking 1 second to complete. rob oh, and the patch. I ran a couple of moderate tests this evening that executed 42 separate operations like add, delete, and managing group membership. I ran this 10 times each on 2 identical VMs, one with a bit older code and one with this patch then averaged the times. With the patch the average was 1.3 seconds per operation, without 2.6. A 50% improvement is more than I expected, I saw a 33% improvement on individual runs. I'll keep at it but this seems promising. I was also a bit surprised that the average time without the patch was so low, I was expecting something over 3 seconds. Specifically what this patch does is it avoids doing some self-validation. There is some amount of risk that the framework could blow up but in a deployed situation I think the risk is rather low. A side-effect of the API tester makeapi is that it loads the framework. We can force it to be run in production mode so the product shouldn't be buildable if it has inconsistencies. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] test speedup patch
On 01/19/2011 10:26 AM, JR Aquino wrote: Just tested. I do see a performance increase of ~30% Without the Patch time ipa user-find -- 1 user matched -- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Account activation status: False Member of groups: admins Number of entries returned 1 real 0m1.558s user 0m0.810s sys 0m0.165s With the Patch time ipa user-find -- 1 user matched -- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Account disabled: False Member of groups: admins Number of entries returned 1 real 0m1.067s user 0m0.841s sys 0m0.157s On 1/18/11 7:17 PM, Rob Crittendenrcrit...@redhat.com wrote: Rob Crittenden wrote: Rob Crittenden wrote: Attached is a rough cut of a patch to try to speed up the cli a little bit. Basically in production mode it will skip some things during initialization. My concept is that we develop in mode != production and release in mode == production. I managed to knock a second or so off time to do a user-show on average. There may be some other things we can do to speed things up, I'm still looking. Some feedback on the approach would be appreciated. Note that I've completely ruled out SSL/Negotiate. I did my testing on lite-server which doesn't use SSL or Negotiate and it was STILL taking on average 3-4+ seconds per command. The server side was consistently taking 1 second to complete. rob oh, and the patch. I ran a couple of moderate tests this evening that executed 42 separate operations like add, delete, and managing group membership. I ran this 10 times each on 2 identical VMs, one with a bit older code and one with this patch then averaged the times. With the patch the average was 1.3 seconds per operation, without 2.6. A 50% improvement is more than I expected, I saw a 33% improvement on individual runs. I'll keep at it but this seems promising. I was also a bit surprised that the average time without the patch was so low, I was expecting something over 3 seconds. Specifically what this patch does is it avoids doing some self-validation. There is some amount of risk that the framework could blow up but in a deployed situation I think the risk is rather low. A side-effect of the API tester makeapi is that it loads the framework. We can force it to be run in production mode so the product shouldn't be buildable if it has inconsistencies. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Mapping of CLI attributes to LDAP attributes
Hi, I've been thinking about the concept of mapping CLI attributes to LDAP attributes (ticket #447) and I'd like to get a second opinion. The most simple solution would be to add this functionality to existing help. For the sake of lucidity, it should be hidden by default. To achieve this a new parameter (e.g. --fullhelp) would be created. The question now is if this approach is suitable for WebUI and whether it is even needed for WebUI. Another approach might be to create new command, e.g. mapping-show, which would take one argument - either name of LDAP object for which we want to show all mappings or (better) directly a command. Here are examples how it could be invoked: ipa mapping-show user/ ipa mapping-show user-add ipa mapping-show hbacrule / ipa mapping-show hbacrule-add So these are my ideas. Some questions? Comments? Other ideas? I welcome any input. -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Mapping of CLI attributes to LDAP attributes
On 01/19/2011 10:53 AM, Jan Zelený wrote: Hi, I've been thinking about the concept of mapping CLI attributes to LDAP attributes (ticket #447) and I'd like to get a second opinion. The most simple solution would be to add this functionality to existing help. For the sake of lucidity, it should be hidden by default. To achieve this a new parameter (e.g. --fullhelp) would be created. The question now is if this approach is suitable for WebUI and whether it is even needed for WebUI. Another approach might be to create new command, e.g. mapping-show, which would take one argument - either name of LDAP object for which we want to show all mappings or (better) directly a command. Here are examples how it could be invoked: ipa mapping-show user/ ipa mapping-show user-add ipa mapping-show hbacrule / ipa mapping-show hbacrule-add So these are my ideas. Some questions? Comments? Other ideas? I welcome any input. The second is fairly similar to the metadata call we use for the WebUI ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Rename insta//static to install/ui
I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. I think the order of execution should be the order I listed them above. Feedback? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Use authenticated binds in init scripts
On 1/18/11 4:02 PM, Simo Sorce sso...@redhat.com wrote: We need to use authenticated lda binds in init scripts as otherwise starting components fails when the option to restrict anonymous access to ldap is set. In order to do that we need to also start the KDC unconditionally, so it has been removed form the list of services retrieved from ldap and always started/stopped/restarted explicitly in the script. This is necessary so the script can obtain kerberos credentials to bind to ds using its keytab. Fixes ticket #795 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Rename insta//static to install/ui
On 01/19/2011 11:29 AM, Dmitri Pal wrote: Adam Young wrote: I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. Is this really required. Can we use what is there now? I am not sure I want to spend any cycles on such a major shift at this stage of the project. Can we just polish what we have for migration page for now and address this in 2.1? Step one is not a major change, actually, as git supports renaming. It keeps us from duplicating the assets (ipa.css, images) in both directories) as we can't really develop the migration page without being able to see them. That is the only one needed. Steps two and three are just logical cleanup steps. I think the order of execution should be the order I listed them above. Feedback? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Rename insta//static to install/ui
Adam Young wrote: I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. You just want to rename the directory in the git tree? I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. I'm ok with that, it's just 2 files. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. I think the order of execution should be the order I listed them above. Feedback? I don't understand the need for the third one. The logic is stills server-side it just uses a separate python script. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 682 performance patch
This patch skips some self-testing and locking done by the framework
when in production mode. The assumption is that all development is done
in mode != production so no inconsistencies can sneak in.
While this patch doesn't seem to do much it improved command-line
performance for me somewhere between 30 and 50% (so between 3-4 seconds
per command to 1.5-3, on average, often much better).
I explicitly set mode to production in the installation config files. I
also explicitly set developer mode when running makeapi --validate so we
can know at build time that the framework is consistent.
ticket 751
rob
From 920029a8b5f43b11291b076c670a21f02d932f27 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 19 Jan 2011 11:24:31 -0500
Subject: [PATCH] Don't perform some API self-tests in production mode for performance reasons
The API does a fair number of self tests and locking to assure that the
registered commands are consistent and will work. This does not need
to be done on a production system and adds additional overhead causing
somewhere between a 30 and 50% decrease in performance.
Because makeapi is executed when a build is done ensure that it is
executed in developer mode to ensure that the framework is ok.
ticket 751
---
install/tools/ipa-replica-install |1 +
install/tools/ipa-server-install |1 +
ipalib/config.py |3 +++
ipalib/frontend.py|7 ---
ipalib/plugable.py| 15 ++-
makeapi |1 +
6 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 3c912a7..01e5d38 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -358,6 +358,7 @@ def main():
if ipautil.file_exists(config.dir + /cacert.p12):
fd.write(enable_ra=True\n)
fd.write(ra_plugin=dogtag\n)
+fd.write(mode=production\n)
fd.close()
api.bootstrap(in_server=True)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 173f5c2..754568c 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -680,6 +680,7 @@ def main():
fd.write(enable_ra=True\n)
if not options.selfsign:
fd.write(ra_plugin=dogtag\n)
+fd.write(mode=production\n)
fd.close()
api.bootstrap(**cfg)
diff --git a/ipalib/config.py b/ipalib/config.py
index ec86d9e..888785a 100644
--- a/ipalib/config.py
+++ b/ipalib/config.py
@@ -467,6 +467,9 @@ class Env(object):
else:
self.in_tree = False
+if self.in_tree and 'mode' not in self:
+self.mode = 'developer'
+
# Set dot_ipa:
if 'dot_ipa' not in self:
self.dot_ipa = self._join('home', '.ipa')
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index eeed398..51fa524 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -351,9 +351,10 @@ class HasParam(Plugin):
self._filter_param_by_context(name, env),
sort=False
)
-check = getattr(self, 'check_' + name, None)
-if callable(check):
-check(namespace)
+if self.env.mode != 'production':
+check = getattr(self, 'check_' + name, None)
+if callable(check):
+check(namespace)
setattr(self, name, namespace)
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 264bb68..82bd522 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -207,6 +207,8 @@ class Plugin(ReadOnly):
def finalize(self):
+if self.env.mode == 'production':
+return
lock(self)
def set_api(self, api):
@@ -601,19 +603,22 @@ class API(DictProxy):
namespace = NameSpace(
plugin_iter(base, (magic[k] for k in magic))
)
-assert not (
-name in self.__d or hasattr(self, name)
-)
+ if self.env.mode != 'production':
+assert not (
+name in self.__d or hasattr(self, name)
+)
self.__d[name] = namespace
object.__setattr__(self, name, namespace)
for p in plugins.itervalues():
p.instance.set_api(self)
-assert p.instance.api is self
+if self.env.mode != 'production':
+assert p.instance.api is self
for p in plugins.itervalues():
p.instance.finalize()
-assert islocked(p.instance) is True
+if self.env.mode != 'production':
+assert islocked(p.instance) is True
object.__setattr__(self, '_API__finalized', True)
tuple(PluginInfo(p) for p in plugins.itervalues())
object.__setattr__(self, 'plugins',
diff --git a/makeapi b/makeapi
index 2c7680f..90f3678 100755
--- a/makeapi
+++
Re: [Freeipa-devel] Rename insta//static to install/ui
Rob Crittenden wrote: Adam Young wrote: I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. You just want to rename the directory in the git tree? I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. I'm ok with that, it's just 2 files. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. I think the order of execution should be the order I listed them above. Feedback? I don't understand the need for the third one. The logic is stills server-side it just uses a separate python script. So far I am Ok with 1 2 but do not see need for 3. Please explain. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Rename insta//static to install/ui
On 01/19/2011 12:06 PM, Dmitri Pal wrote: Rob Crittenden wrote: Adam Young wrote: I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. You just want to rename the directory in the git tree? I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. I'm ok with that, it's just 2 files. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. I think the order of execution should be the order I listed them above. Feedback? I don't understand the need for the third one. The logic is stills server-side it just uses a separate python script. So far I am Ok with 1 2 but do not see need for 3. Please explain. I think I can drop 3, as the existing migrate.py will work OK. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Rename insta//static to install/ui
Adam Young wrote: On 01/19/2011 12:06 PM, Dmitri Pal wrote: Rob Crittenden wrote: Adam Young wrote: I've been working with Kyle Baker to implement the cleanup of the migration and the error reporting pages. One thing that is messing us up is the fact that the URL as exposed on the server is different than the file structure. I'd like to propose the folowing changes: First: rename install/static to install/ui. You just want to rename the directory in the git tree? I wanted to use this name from the get go, but there was a conflict with the wsgi based ui. It has been gone for a long enough time now that the rename should cause no conflicts. Second: merge the html directory into the ui directory. I'm ok with that, it's just 2 files. We need them to be separate originally because the UI was getting authentication, but the error messages and so forth were not. NOw, none of the ui gets authenticated, only the JSON RPC. Third: make an RPC url that we can call without authentication. The migration page is the last thing we have that uses server side scripting. I'd like to complete the work of splitting UI from business logic. However, the migration code needs to make an RPC unauthenticated. Right now this is the only page that needs to do so, but we could potentially have others. If we made a parallel structure for xml rpc and json RPC that could be called unauthenticated, we could also perform the migration from the command line or other applications, which would support some new use cases. I think the order of execution should be the order I listed them above. Feedback? I don't understand the need for the third one. The logic is stills server-side it just uses a separate python script. So far I am Ok with 1 2 but do not see need for 3. Please explain. I think I can drop 3, as the existing migrate.py will work OK. You can open a ticket and put it into the deferred bucket for future. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Use authenticated binds in init scripts
On Wed, 19 Jan 2011 16:18:09 + JR Aquino jr.aqu...@citrix.com wrote: On 1/18/11 4:02 PM, Simo Sorce sso...@redhat.com wrote: We need to use authenticated lda binds in init scripts as otherwise starting components fails when the option to restrict anonymous access to ldap is set. In order to do that we need to also start the KDC unconditionally, so it has been removed form the list of services retrieved from ldap and always started/stopped/restarted explicitly in the script. This is necessary so the script can obtain kerberos credentials to bind to ds using its keytab. Fixes ticket #795 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Thanks but Rich pointed me to the docs I couldn't find earlier in order to use SASL/EXTERNL instead of actual credentials. So I'll hold on this patch and try to propose an alternative that does not require SASL/GSSAPI auth. If that will be possible and satisfactorily I will retire this patch an propose a new one, otherwise I'll push this one. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0063 Fix ipa_uuid misbehavior
ipa_uuid was returning an improper error if a modify operation was
performed on an entry that doesn't exists.
This was preventing the dna plugin from working correctly.
Do not error on missing entries, let DS handle the case and report the
proper error code.
Ticket 813
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From be5cbfdb62cd986e4d873773a62ae1490df86da2 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Wed, 19 Jan 2011 14:54:01 -0500
Subject: [PATCH] Fix ipa_uuid to not interfer with proper error reporting
Fixes: https://fedorahosted.org/freeipa/ticket/813
---
daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c
index 83aac77da95df39cb162988e9a58172585b7ab5a..c6353aeed4a68560be45cb3b3779bdef5ff83620 100644
--- a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c
+++ b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c
@@ -819,9 +819,8 @@ static int ipauuid_pre_op(Slapi_PBlock *pb, int modtype)
slapi_sdn_free(tmp_dn);
if (ret) {
-LOG_FATAL(slapi_search_internal_get_entry failed!? Err %d\n,
-ret);
-ret = LDAP_OPERATIONS_ERROR;
+/* ok a client tried to modify an entry that doesn't exist.
+ * Nothing to see here, move along ... */
goto done;
}
--
1.7.3.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
Pavel Zuna wrote: Fix #798 Pavel I don't think this is the right fix. IIRC the idea was that pre-created hosts with a password (either provided or random) would not have a principal. The principal would be added once the host is enrolled. This will fix the plugin as far as adding entries but will cause ipa-join to report a warning that the principal already exists. I realize that this has already been pushed but the ticket should be re-opened and another look taken at this. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0063 Fix ipa_uuid misbehavior
Simo Sorce wrote: ipa_uuid was returning an improper error if a modify operation was performed on an entry that doesn't exists. This was preventing the dna plugin from working correctly. Do not error on missing entries, let DS handle the case and report the proper error code. Ticket 813 Simo. ack ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
Rob Crittenden wrote: Pavel Zuna wrote: Fix #798 Pavel I don't think this is the right fix. IIRC the idea was that pre-created hosts with a password (either provided or random) would not have a principal. The principal would be added once the host is enrolled. I though that enrollment is based only on presence of the keytab. Since the the principal is not something that can be changed why it can't be created when the entry is created? Does the current logic delete the principal when the machine is un-enrolled from CLI or GUI. It seems logical to just check the presence of the keytab. If it is there enrolled. If not then does not. Am I missing something? This will fix the plugin as far as adding entries but will cause ipa-join to report a warning that the principal already exists. I realize that this has already been pushed but the ticket should be re-opened and another look taken at this. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
On Wed, 19 Jan 2011 15:12:03 -0500 Rob Crittenden rcrit...@redhat.com wrote: Pavel Zuna wrote: Fix #798 Pavel I don't think this is the right fix. IIRC the idea was that pre-created hosts with a password (either provided or random) would not have a principal. The principal would be added once the host is enrolled. This will fix the plugin as far as adding entries but will cause ipa-join to report a warning that the principal already exists. I realize that this has already been pushed but the ticket should be re-opened and another look taken at this. Should we revert in the meanwhile ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
On Wed, 19 Jan 2011 15:22:22 -0500 Dmitri Pal d...@redhat.com wrote: I though that enrollment is based only on presence of the keytab. By keytab I guess you mean the krbPrincipalKey attribute. The presence of that attribute is unknown to all users except cn=Directory Manager and uid=kdc, so no user can check for it's presence as our aci prevent any access for reading (and rightly so). I think the krbPrincipalNAme attribute was used to check if kerberos credentials were assigned. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] New Font and I18N
Ben, Since we are going to need Chinese and Japanese support in the font for IPA, I'm thinking that we should 1. Get the translations the site. 2. Identify the Glyphs requires 3. Identify the process for people to submit Glyphs to the font base from the FreeIPA website. I'm assuming that the Browser has the ability to fall back to a known complete Font for missing glyphs, but I haven't tested it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
Simo Sorce wrote: On Wed, 19 Jan 2011 15:22:22 -0500 Dmitri Pald...@redhat.com wrote: I though that enrollment is based only on presence of the keytab. By keytab I guess you mean the krbPrincipalKey attribute. The presence of that attribute is unknown to all users except cn=Directory Manager and uid=kdc, so no user can check for it's presence as our aci prevent any access for reading (and rightly so). I think the krbPrincipalNAme attribute was used to check if kerberos credentials were assigned. Simo. Yes, that's right. We also use krbLastPwdChange for this purpose but the krbPrincipalName work predated this. We might need to revisit what I originally did which is why I think the patch is ok for now. For now, at least as far as I can tell, it just causes a strange message in ipa-join. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix password/random logic in host plugin.
Rob Crittenden wrote: Simo Sorce wrote: On Wed, 19 Jan 2011 15:22:22 -0500 Dmitri Pald...@redhat.com wrote: I though that enrollment is based only on presence of the keytab. By keytab I guess you mean the krbPrincipalKey attribute. The presence of that attribute is unknown to all users except cn=Directory Manager and uid=kdc, so no user can check for it's presence as our aci prevent any access for reading (and rightly so). I think the krbPrincipalNAme attribute was used to check if kerberos credentials were assigned. Simo. Yes, that's right. We also use krbLastPwdChange for this purpose but the krbPrincipalName work predated this. We might need to revisit what I originally did which is why I think the patch is ok for now. For now, at least as far as I can tell, it just causes a strange message in ipa-join. Yes the one that I noticed yesterday stating that principal exists. Ok I am corrected let us reopen the ticket. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 683 block anonymous access to hbac info
Add a couple of acis to block anonymous access to cn=hbac and to member attributes. This is so you can't hunt for what roles, groups, etc. a user might be in (so you can target an attack). ticket 811 rob From b1d9409042946406b0354af17c9345c1bdf9ec0f Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Wed, 19 Jan 2011 17:47:50 -0500 Subject: [PATCH] Block anonymous access to HBAC and member information. Prevents an unauthenticated user from accessing HBAC information as well as member information which could diclose roles, memberships in HBAC, etc. ticket 811 --- install/share/default-aci.ldif |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index ff0e5ae..6264135 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -4,6 +4,7 @@ dn: $SUFFIX changetype: modify add: aci aci: (targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) +aci: (targetattr = member || memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;;) aci: (targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || serverHostName || enrolledBy)(version 3.0; acl Admin can manage any entry; allow (all) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) aci: (targetattr = userpassword || krbprincipalkey || sambalmpassword || sambantpassword)(version 3.0; acl Self can write own password; allow (write) userdn=ldap:///self;;) aci: (targetattr = userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory)(version 3.0; acl Admins can write passwords; allow (add,delete,write) groupdn=ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) @@ -67,3 +68,8 @@ dn: cn=computers,cn=accounts,$SUFFIX changetype: modify add: aci aci: (targetattr = krbPrincipalKey || krbLastPwdChange)(target = ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX;)(version 3.0;acl Admins can manage host keytab;allow (write) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) + +dn: cn=hbac,$SUFFIX +changetype: modify +add: aci +aci: (targetattr = *)(version 3.0; acl No anonymous access to hbac; deny (read,search,compare) userdn != ldap:///all;;) -- 1.7.3.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 683 block anonymous access to hbac info
On Wed, 19 Jan 2011 17:51:56 -0500 Rob Crittenden rcrit...@redhat.com wrote: +aci: (targetattr = member || memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;;) Nack, without 'member', nss_ldap will have no way to determine posixAccount group memberships using anonymous access (the default). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Use authenticated binds in init scripts
On Wed, 19 Jan 2011 12:20:25 -0500 Simo Sorce sso...@redhat.com wrote: On Wed, 19 Jan 2011 16:18:09 + JR Aquino jr.aqu...@citrix.com wrote: On 1/18/11 4:02 PM, Simo Sorce sso...@redhat.com wrote: We need to use authenticated lda binds in init scripts as otherwise starting components fails when the option to restrict anonymous access to ldap is set. In order to do that we need to also start the KDC unconditionally, so it has been removed form the list of services retrieved from ldap and always started/stopped/restarted explicitly in the script. This is necessary so the script can obtain kerberos credentials to bind to ds using its keytab. Fixes ticket #795 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Thanks but Rich pointed me to the docs I couldn't find earlier in order to use SASL/EXTERNL instead of actual credentials. So I'll hold on this patch and try to propose an alternative that does not require SASL/GSSAPI auth. If that will be possible and satisfactorily I will retire this patch an propose a new one, otherwise I'll push this one. Simo. Ok I am retiring this patch and sending an alternative one. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0064 Fix authentication for init scripts
In order for ipactl to function even when anonymous access is disabled
we need to authenticate.
Use sASL/EXTERNAL to let root get access as a very low privileged
special user.
Ticket #795
This patch is a replacement of 0061 where I was using SASL/GSSAPI
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From e15af881c47f6ce837006805b2f6977fa7354ba9 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Wed, 19 Jan 2011 15:17:25 -0500
Subject: [PATCH] Allow SASL/EXTERNAL authentication for the root user
This gives the root user low privileges so that when anonymous searches are
denied the init scripts can still search the directory via ldapi to get the
list of serevices to start.
Fixes: https://fedorahosted.org/freeipa/ticket/795
---
install/share/Makefile.am|1 +
install/share/root-autobind.ldif | 24
install/tools/ipactl |5 -
ipaserver/install/dsinstance.py |5 +
4 files changed, 34 insertions(+), 1 deletions(-)
create mode 100644 install/share/root-autobind.ldif
diff --git a/install/share/Makefile.am b/install/share/Makefile.am
index 0fb5c8961fa787f4686e93b4f073d954f78d08b1..4527a922c3c7408ff2563dac6a5db9a2657ae1ba 100644
--- a/install/share/Makefile.am
+++ b/install/share/Makefile.am
@@ -47,6 +47,7 @@ app_DATA =\
uuid-ipauniqueid.ldif \
modrdn-krbprinc.ldif \
entryusn.ldif \
+ root-autobind.ldif \
$(NULL)
EXTRA_DIST =\
diff --git a/install/share/root-autobind.ldif b/install/share/root-autobind.ldif
new file mode 100644
index ..e7bbc8dbe430a48d53078cbd585cd479388450de
--- /dev/null
+++ b/install/share/root-autobind.ldif
@@ -0,0 +1,24 @@
+# root-autobind, config
+dn: cn=root-autobind,cn=config
+changetype: add
+objectClass: extensibleObject
+objectClass: top
+cn: root-autobind
+uidNumber: 0
+gidNumber: 0
+
+dn: cn=config
+changetype: modify
+replace: nsslapd-ldapiautobind
+nsslapd-ldapiautobind: on
+
+dn: cn=config
+changetype: modify
+replace: nsslapd-ldapimaptoentries
+nsslapd-ldapimaptoentries: on
+
+dn: cn=config
+changetype: modify
+replace: nsslapd-ldapientrysearchbase
+nsslapd-ldapientrysearchbase: cn=config
+
diff --git a/install/tools/ipactl b/install/tools/ipactl
index 0254a2762580fc83503510d387b3e36d67d514de..fc652c9754cf63e8d9d46a3b20866b94df3ab698 100755
--- a/install/tools/ipactl
+++ b/install/tools/ipactl
@@ -26,6 +26,7 @@ try:
from ipalib import api, errors
import logging
import ldap
+import ldap.sasl
import socket
except ImportError:
print sys.stderr, \
@@ -36,6 +37,8 @@ error was:
% sys.exc_value
sys.exit(1)
+SASL_EXTERNAL = ldap.sasl.sasl({}, 'EXTERNAL')
+
def parse_options():
usage = %prog start|stop|restart|status\n
parser = config.IPAOptionParser(usage=usage,
@@ -60,7 +63,7 @@ def get_config():
try:
con = ldap.initialize(api.env.ldap_uri)
-con.simple_bind()
+con.sasl_interactive_bind_s('', SASL_EXTERNAL)
res = con.search_st(base,
ldap.SCOPE_SUBTREE,
filterstr=srcfilter,
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 4fd7a00279c73c5b41e2d7ad5999c1af91eefbf8..5da9d17d4417031920495254ff566ee235234bfb 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -208,6 +208,7 @@ class DsInstance(service.Service):
self.step(creating indices, self.__create_indices)
self.step(configuring ssl for ds instance, self.__enable_ssl)
self.step(configuring certmap.conf, self.__certmap_conf)
+self.step(configure autobind for root, self.__root_autobind)
self.step(restarting directory server, self.__restart_instance)
def __common_post_setup(self):
@@ -729,3 +730,7 @@ class DsInstance(service.Service):
def __tuning(self):
self.tune_nofile(8192)
+
+def __root_autobind(self):
+self._ldap_mod(root-autobind.ldif)
+
--
1.7.3.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0065 Use ldapi with krb5kdc
Long ago we decided to use the ldapi socket to let the KDC access the
ldap data in order to avoid comunication over the network (even if it
is 127.0.0.1).
This patch finally implements that. Although beware that this patch
will need you to either create custom policy or to set selinux in
permissive mode until the new policy lands in fedora land.
Bugs have been opened and I think the policy has already landed in
rawhide.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From 5328b459ae3f55377b9609a796dd05dc026ba791 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Wed, 19 Jan 2011 14:08:48 -0500
Subject: [PATCH] Make krb5kdc use the ldapi socket to talk to dirsrv
Fixes: https://fedorahosted.org/freeipa/ticket/812
---
install/share/krb5.conf.template |2 +-
ipaserver/install/krbinstance.py |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/install/share/krb5.conf.template b/install/share/krb5.conf.template
index ab569714bc7d49370ac65587b63bc23e6bd46ca0..9cf4ee84d5e12bc5ecf524f1544e87b2d787c476 100644
--- a/install/share/krb5.conf.template
+++ b/install/share/krb5.conf.template
@@ -34,7 +34,7 @@
[dbmodules]
$REALM = {
db_library = kldap
-ldap_servers = ldap://127.0.0.1/
+ldap_servers = ldapi://%2fvar%2frun%2fslapd-$SERVER_ID.socket
ldap_kerberos_container_dn = cn=kerberos,$SUFFIX
ldap_kdc_dn = uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX
ldap_kadmind_dn = uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX
diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index e7c1116377a66954ecf4c024510e6d9dd79ba69d..9f706797fcbeb79bf0c58c60294c0fc7f6e5f4b9 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -35,6 +35,7 @@ from ipalib import errors
from ipaserver import ipaldap
from ipaserver.install import replication
+from ipaserver.install.dsinstance import realm_to_serverid
import ldap
from ldap import LDAPError
@@ -255,6 +256,7 @@ class KrbInstance(service.Service):
SUFFIX=self.suffix,
DOMAIN=self.domain,
HOST=self.host,
+ SERVER_ID=realm_to_serverid(self.realm),
REALM=self.realm)
def __configure_sasl_mappings(self):
--
1.7.3.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0063 Fix ipa_uuid misbehavior
On Wed, 19 Jan 2011 15:15:53 -0500 Rob Crittenden rcrit...@redhat.com wrote: Simo Sorce wrote: ipa_uuid was returning an improper error if a modify operation was performed on an entry that doesn't exists. This was preventing the dna plugin from working correctly. Do not error on missing entries, let DS handle the case and report the proper error code. Ticket 813 Simo. ack Thanks, pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0059 Add command to test if DNS is active
On 01/17/2011 01:11 PM, Simo Sorce wrote: This patch implements the feature requested in ticket #600 The internal dns_is_enabled command returns whether the DNS service is enable on at least one of the server in the domain. The UI can use this command to determine whether to show the DNS related configuration options. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, but be sure to rerun the makeapi command, as I think we have added a few new ones since this version was generated. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0059 Add command to test if DNS is active
On Wed, 19 Jan 2011 20:17:56 -0500 Adam Young ayo...@redhat.com wrote: On 01/17/2011 01:11 PM, Simo Sorce wrote: This patch implements the feature requested in ticket #600 The internal dns_is_enabled command returns whether the DNS service is enable on at least one of the server in the domain. The UI can use this command to determine whether to show the DNS related configuration options. ACK, but be sure to rerun the makeapi command, as I think we have added a few new ones since this version was generated. I kept rebasing it on top of master in my tree, I saw no issues. Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
