Re: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges
On 10/17/2012 08:12 PM, Sumit Bose wrote: On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: On 10/17/2012 02:34 PM, Sumit Bose wrote: On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: On 10/17/2012 11:14 AM, Sumit Bose wrote: On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: Hi, commands ipa idrange-add / idrange-mod no longer allows the user to enter primary or secondary rid range such that has non-zero intersection with primary or secondary rid range of another existing id range, as this could cause collision. Unit tests added to test_range_plugin.py https://fedorahosted.org/freeipa/ticket/3086 Tomas Thank you for the patch, comments are in-line. bye, Sumit Thank you for your suggestions. New version of the patch attached. Tomas Thank you for addressing my comments. I just realized that the check is too strict. The ranges of the Posix IDs [base_id - base_id+id_range_size) may not overlap for any existing range because those IDs belong to the single Posix ID namespace of the IPA domain. I.e each user, local or from a trusted domain, must have a unique Posix ID. The RID ranges [base_rid, base_rid+id_range_size) and [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap with RID ranges from the same domain. So the RID ranges for the local domain may not overlap and the RID ranges for any specific trusted domain may not overlap. It is allowed that there is a range form the local domain may have base_rid=1000 and a range from a trusted domain as well. This is ok because the RID is only part of the identifier, each domain has a unique domain SID which is used together with the RID to identify e.g. a user. I would suggest to look for the ipaNTTrustedDomainSID attribute in slapi_entry_to_range_info() too and add it to struct range_info. In ranges_overlap() you can then check the Posix ID range for all ranges but do the RID checks only when the domain identifiers are either both NULL (local IPA domain) or are the same strings. Sorry for not seeing this earlier. bye, Sumit Thanks for catching this issue. It is solved in the newest revision of the patch. Tomas sorry, found another one ... ... +static int ranges_overlap(struct range_info *r1, struct range_info *r2) +{ +if (r1-name != NULL r2-name != NULL +strcasecmp(r1-name, r2-name) == 0) { +return 0; +} + +/* check if base range overlaps with existing base range */ +if (intervals_overlap(r1-base_id, r2-base_id, +r1-id_range_size, r2-id_range_size)){ +return 1; +} + +/* if both base_rid and secondary_base_rid = 0, the rid range is not set */ +bool rid_ranges_set = (r1-base_rid != 0 || r1-secondary_base_rid != 0) + (r2-base_rid != 0 || r2-secondary_base_rid != 0); + +bool ranges_from_same_domain = + (r1-domain_id == NULL r2-domain_id == NULL) || + (strcasecmp(r1-domain_id, r2-domain_id) == 0); + you have to check that both domain_id are not NULL before calling strcasecmp. bye, Sumit Null pointer check added. Tomas From 2a90a4f2f3958575ecd7cf69034d4e381930f6c5 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Mon, 15 Oct 2012 06:28:16 -0400 Subject: [PATCH] Forbid overlapping primary and secondary rid ranges Commands ipa idrange-add / idrange-mod no longer allows the user to enter primary or secondary rid range such that has non-zero intersection with primary or secondary rid range of another existing id range, as this could cause collision. Unit tests added to test_range_plugin.py https://fedorahosted.org/freeipa/ticket/3086 --- .../ipa-range-check/ipa_range_check.c | 115 +--- tests/test_xmlrpc/test_range_plugin.py | 120 +++-- 2 files changed, 213 insertions(+), 22 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c index 499e54a9c4a4c9134a231c0cd09e700390565a14..290dc5a52080d6b7d1587fa2af6102f022ccb30a 100644 --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c @@ -49,6 +49,7 @@ #define IPA_ID_RANGE_SIZE ipaIDRangeSize #define IPA_BASE_RID ipaBaseRID #define IPA_SECONDARY_BASE_RID ipaSecondaryBaseRID +#define IPA_DOMAIN_ID ipaNTTrustedDomainSID #define RANGES_FILTER objectclass=ipaIDRange #define IPA_PLUGIN_NAME ipa-range-check @@ -70,6 +71,7 @@ struct ipa_range_check_ctx { struct range_info { char *name; +char *domain_id; uint32_t base_id; uint32_t id_range_size; uint32_t base_rid; @@ -93,6 +95,8 @@ static int slapi_entry_to_range_info(struct slapi_entry *entry, return EINVAL; } +range-domain_id = slapi_entry_attr_get_charptr(entry, IPA_DOMAIN_ID); + ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); if (ul_val == 0 || ul_val = UINT32_MAX) {
Re: [Freeipa-devel] Unit tests failing on F18
On 10/18/2012 12:04 AM, Rob Crittenden wrote: Martin Kosek wrote: Hello, I was investigating global unit test failure on Fedora 18 for most of today, I would like to share results I found so far. Unit test and its related scripts on F18 now reports NSS BUSY exception, just like this one: # ./make-testcert Traceback (most recent call last): File ./make-testcert, line 134, in module sys.exit(makecert(reqdir)) File ./make-testcert, line 111, in makecert add=True) File ./make-testcert, line 68, in run result = self.execute(method, *args, **options) File /root/freeipa-master2/ipalib/backend.py, line 146, in execute raise error #pylint: disable=E0702 ipalib.errors.NetworkError: cannot connect to 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. Something In F18 must have changed, this worked before... But leaked NSSConnection objects without proper close() now ends with the exception above. In case of make-testcert script, the exception is raised because the script does the following procedure: 1) connect, do one command 2) disconnect 3) connect, do second command However, during disconnect, NSSConnection is leaked which makes NSS very uncomfortable during second connection atempt (and nss_shutdown()). I managed to fix this issue with attached patch. ./make-testcert or ./make-test tests/test_xmlrpc/test_group_plugin.py works fine now. But global ./make-test still fails, I think there is some remaining NSSConnection leak, I suspect there is something wrong with how we use our context (threading.local object). It looses a connection or some other thread invoked in ldap2 module may be kicking in, here is my debug output: CONTEXT[xmlclient] = ipalib.request.Connection object at 0x9a1f5ec Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in /root/.ipa/.dmpw Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT 150714476: GET languages CONTEXT[xmlclient] = None The connection is in the context, but then something happens and it is gone. Then, unit tests try to connect again and NSS fails. I would be really glad if somebody with a knowledge of NSS or how threads in Python/IPA work could give me some advice... Thanks! Martin I built upon your patch and have something that seems to work at least somewhat. I'm getting some unexpected test failures when running the entire suite but no NSS shutdown errors. I haven't had a chance to really investigate everything yet, sending this out as a work-in-progress in case you want to take a look. rob Yeah, this is great! I tested a fresh build+install on Fedora 18 with your patch and all tests succeeded. So as for F18, I am inclined to ACK the patch as is. I am just not sure that this will work on platforms with Python version 2.7, xmlrpclib is different there. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 87 extdom: handle INP_POSIX_UID and INP_POSIX_GID requests
On 10/17/2012 02:15 PM, Alexander Bokovoy wrote: On Thu, 11 Oct 2012, Sumit Bose wrote: Hi, I found this issue while working on a related sssd bug https://fedorahosted.org/sssd/ticket/1561 . This patch allows the clients to send a request map a UID or GID for a trusted user to the name of the user. To achieve this the Posix ID is mapped to the corresponding SID and then the SID is looked up. FreeIPA ticket is https://fedorahosted.org/freeipa/ticket/3166 . ACK. Pushed to master, ipa-3-0. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 75] log dogtag errors
On 10/17/2012 08:23 PM, John Dennis wrote: On 10/12/2012 04:35 AM, Petr Viktorin wrote: On 10/11/2012 06:53 PM, John Dennis wrote: On 04/28/2012 09:50 AM, John Dennis wrote: On 04/27/2012 04:45 AM, Petr Viktorin wrote: On 04/20/2012 08:07 PM, John Dennis wrote: Ticket #2622 If we get an error from dogtag we always did raise a CertificateOperationError exception with a message describing the problem. Unfortuanately that error message did not go into the log, just sent back to the caller. The fix is to format the error message and send the same message to both the log and use it to initialize the CertificateOperationError exception. The patch contains five hunks with almost exactly the same code, applying the same changes in each case. Wouldn't it make sense to move the _sslget call, parsing, and error handling to a common method? Yes it would and ordinarily I would have taken that approach. However on IRC (or phone?) with Rob we decided not to perturb the code too much for this particular issue because we intend to refactor the code later. This was one of the last patches destined for 2.2 which is why we took the more conservative approach. I went back and looked at this. It's not practical to collapse everything into a common subroutine unless you paramaterize the heck out of a common subroutine. That's because all the patched locations have subtly different things going on, different parameters to sslget followed by different result parsing and handling. In retrospect I think it's clearer to keep things separate rather than one subroutine that needs a lot of parameters and/or convoluted logic to handle each unique case. I don't agree that it's clearer, but I guess that's debatable. Part of the problem is the dogtag interface. Every command has the potential to behave differently making it difficult to work with. I wrote this code originally and got it reduced to as many common parts as I could. At some point soon we'll be switching to a new dogtag REST interface which hopefully will allow for greater commonality due to interface consistency. In summary: I still stand by the original patch. However, I see no reason to not use a method such as: def raise_certop_error(self, method_name, error=None, detail=None): Log and raise a CertificateOperationError :param method_name: Name of the method in which the error occured :param error: Error string. If None, Unable to communicate with CMS is used. :param detail: Detailed or low-level information. Will be put in parentheses. to at least get rid of the repetition this patch is adding - almost the same format+log+raise sequence is used twice in each of the five hunks. Added a utility function as suggested. Revised patch attached. This looks much better. I found one more issue, though. diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index baa41ad..66fef57 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1233,6 +1233,27 @@ class ra(rabase.rabase): self.password = '' super(ra, self).__init__() +def raise_certificate_operation_error(self, func_name, err_msg=None, detail=None): + +:param func_name: function name where error occurred + +:param err_msg: diagnostic error message, if not supplied it will be + 'Unable to communicate with CMS' +:param detail:extra information that will be appended to err_msg + inside a parenthesis + +Raise a CertificateOperationError and log the error message. + + +if err_msg is None: +err_msg = _('Unable to communicate with CMS') + +if detail is not None: +err_msg += ' (%s)' % detail Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and 'unicode'. Until our Gettext class supports addition (part of #3188), please use `err_msg = u'%s (%s)' % (err_msg, detail)` instead. -- PetrĀ³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent
On 10/11/2012 05:11 PM, Tomas Babej wrote: On 10/11/2012 12:32 PM, Martin Kosek wrote: On 10/11/2012 12:26 PM, Tomas Babej wrote: Hi, This patch forces more consistency into ipa-server-install output. All descriptions of services that are not instances of SimpleServiceInstance are now in the following format: Description (Service Name) Furthermore, start_creation method has been modified to support custom start and end messages. Sample output produced by this patch attached. https://fedorahosted.org/freeipa/ticket/3059 Tomas Just based on reading the patch, this does not look right: -self.start_creation(Configuring certificate server, 210) +self.start_creation(Configuring directory server for the CA, +end_message=Done configuring directory server for the CA, +show_service_name=True, runtime=210) Martin Thanks, glitch fixed. Tomas Ok, I managed to get the patch a proper review. I like the result, in the console, but I still not entirely satisfied with the patch, looks over-engineered to me + there is a lot of duplication with Configuring %(service)s and Done configuring %(service)s messages. These messages could be easily generated only based on name of a service (self.service_name, we got that) and a new friendly service name or description. If we add description this way: class KrbInstance(service.Service): def __init__(self, fstore=None): service.Service.__init__(self, krb5kdc, description=Kerberos KDC) ... the start_creation could be very simple: ... self.start_creation(runtime=30) ... All messages could be simply generated by the Service class just based on self.service_name and self.description with having the same output as you do now. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts
Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 -- Martin Kosek mko...@redhat.com Senior Software Engineer - Identity Management Team Red Hat Inc. From 660717208270cea523cf9d2be655542b38782aad Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Thu, 18 Oct 2012 14:06:06 +0200 Subject: [PATCH] Add fallback for httpd restarts httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 --- ipapython/platform/redhat.py | 17 + ipaserver/install/httpinstance.py | 13 + 2 files changed, 30 insertions(+) diff --git a/ipapython/platform/redhat.py b/ipapython/platform/redhat.py index 3f35cfcc9607bd0c9a05659d936a9903ec198f1b..3551c28410ceeabfc1064ac79e86dc7ee40dd8c3 100644 --- a/ipapython/platform/redhat.py +++ b/ipapython/platform/redhat.py @@ -25,9 +25,11 @@ import stat import sys import socket import stat +import time from ipapython import ipautil from ipapython.platform import base +from ipapython.ipa_log_manager import root_logger from ipalib import api # All what we allow exporting directly from this module @@ -115,6 +117,19 @@ class RedHatSSHService(RedHatService): def get_config_dir(self, instance_name=): return '/etc/ssh' +class RedHatHTTPDService(RedHatService): +def restart(self, instance_name=, capture_output=True, wait=True): +try: +super(RedHatHTTPDService, self).restart(instance_name, capture_output, wait) +except ipautil.CalledProcessError: +# http may have issues with binding to ports, try to fallback +# https://bugzilla.redhat.com/show_bug.cgi?id=845405 +root_logger.debug(%s restart failed, try to stopstart again, self.service_name) +time.sleep(5) +self.stop(instance_name, capture_output) +time.sleep(5) +self.start(instance_name, capture_output, wait) + class RedHatAuthConfig(base.AuthConfig): AuthConfig class implements system-independent interface to configure @@ -145,6 +160,8 @@ class RedHatAuthConfig(base.AuthConfig): def redhat_service(name): if name == 'sshd': return RedHatSSHService(name) +elif name == 'httpd': +return RedHatHTTPDService(name) return RedHatService(name) class RedHatServices(base.KnownServices): diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py index 29077367dc17b6df0618c4740fad445edc43e790..6d9c76da9900972aba2ed5c5ae85710566ed3509 100644 --- a/ipaserver/install/httpinstance.py +++ b/ipaserver/install/httpinstance.py @@ -23,6 +23,7 @@ import tempfile from ipapython.ipa_log_manager import * import pwd import shutil +import time import service import certs @@ -393,3 +394,15 @@ class HTTPInstance(service.Service): if not running is None and running: self.start() + +def restart(self, instance_name=, capture_output=True, wait=True): +try: +super(HTTPInstance, self).restart(instance_name, capture_output, wait) +except ipautil.CalledProcessError: +# http may have issues with binding to ports, try to fallback +# https://bugzilla.redhat.com/show_bug.cgi?id=845405 +root_logger.debug(%s restart failed, try to stopstart again, self.service_name) +time.sleep(5) +self.stop(instance_name, capture_output) +time.sleep(5) +self.start(instance_name, capture_output, wait) -- 1.7.11.7 #!/usr/bin/python import ipaserver.install.dsinstance import ipaserver.install.httpinstance from ipapython.ipa_log_manager import * from ipapython import services as ipaservices import time standard_logging_setup(debug=True, console_format='%(levelname)s: %(message)s') print print *** Test HTTPInstance restart print http = ipaserver.install.httpinstance.HTTPInstance() for x in xrange(2): http.restart() # wait before next test time.sleep(3) print
Re: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts
Martin Kosek wrote: Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 Should we attempt to retrieve a file to ensure that the service is up? The ipa.crt would be a candidate for this. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts
On 10/18/2012 02:47 PM, Rob Crittenden wrote: Martin Kosek wrote: Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 Should we attempt to retrieve a file to ensure that the service is up? The ipa.crt would be a candidate for this. rob Hm, this looks over-engineered from my POV. We already check that ports are open, right? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts
Martin Kosek wrote: On 10/18/2012 02:47 PM, Rob Crittenden wrote: Martin Kosek wrote: Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 Should we attempt to retrieve a file to ensure that the service is up? The ipa.crt would be a candidate for this. rob Hm, this looks over-engineered from my POV. We already check that ports are open, right? Well, this is assuming that sysV is going to return an error when httpd doesn't start. It should at least call service status to make sure the service is operational. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts
On 10/18/2012 04:36 PM, Rob Crittenden wrote: Martin Kosek wrote: On 10/18/2012 02:47 PM, Rob Crittenden wrote: Martin Kosek wrote: Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 Should we attempt to retrieve a file to ensure that the service is up? The ipa.crt would be a candidate for this. rob Hm, this looks over-engineered from my POV. We already check that ports are open, right? Well, this is assuming that sysV is going to return an error when httpd doesn't start. It should at least call service status to make sure the service is operational. rob Actually, we generally already do that as a part of start() process, you will see it when running my test script: DEBUG: stderr= DEBUG: args=/sbin/service httpd restart DEBUG: stdout=Stopping httpd: [FAILED] Starting httpd:[FAILED] DEBUG: stderr=(98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs DEBUG: httpd restart failed, try to stopstart again DEBUG: args=/sbin/service httpd stop DEBUG: stdout=Stopping httpd: [ OK ] DEBUG: stderr= DEBUG: args=/sbin/service httpd start DEBUG: stdout=Starting httpd: [ OK ] DEBUG: stderr= DEBUG: args=/sbin/service httpd status DEBUG: stdout=httpd dead but subsys locked But I just realized, that my change in httpinstance.py is redundant, it uses platform service to do the restart which has the fallback already, i.e. modification there is enough. Updated patch attached. Martin From 4275126bf5fd3422da9fb0536725b809fae9a6bd Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Thu, 18 Oct 2012 16:50:08 +0200 Subject: [PATCH] Add fallback for httpd restarts on sysV platforms httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 --- ipapython/platform/redhat.py | 17 + 1 file changed, 17 insertions(+) diff --git a/ipapython/platform/redhat.py b/ipapython/platform/redhat.py index 3f35cfcc9607bd0c9a05659d936a9903ec198f1b..3551c28410ceeabfc1064ac79e86dc7ee40dd8c3 100644 --- a/ipapython/platform/redhat.py +++ b/ipapython/platform/redhat.py @@ -25,9 +25,11 @@ import stat import sys import socket import stat +import time from ipapython import ipautil from ipapython.platform import base +from ipapython.ipa_log_manager import root_logger from ipalib import api # All what we allow exporting directly from this module @@ -115,6 +117,19 @@ class RedHatSSHService(RedHatService): def get_config_dir(self, instance_name=): return '/etc/ssh' +class RedHatHTTPDService(RedHatService): +def restart(self, instance_name=, capture_output=True, wait=True): +try: +super(RedHatHTTPDService, self).restart(instance_name, capture_output, wait) +except ipautil.CalledProcessError: +# http may have issues with binding to ports, try to fallback +# https://bugzilla.redhat.com/show_bug.cgi?id=845405 +root_logger.debug(%s restart failed, try to stopstart again, self.service_name) +time.sleep(5) +self.stop(instance_name, capture_output) +time.sleep(5) +self.start(instance_name, capture_output, wait) + class RedHatAuthConfig(base.AuthConfig): AuthConfig class implements system-independent interface to configure @@ -145,6 +160,8 @@ class RedHatAuthConfig(base.AuthConfig): def redhat_service(name): if name == 'sshd': return RedHatSSHService(name) +elif name == 'httpd': +return RedHatHTTPDService(name) return RedHatService(name) class RedHatServices(base.KnownServices): -- 1.7.11.7
Re: [Freeipa-devel] [PATCH 0020] Refactoring of default.conf man page
Tomas Babej wrote: Hi, Description for the 'server' and 'wait_for_attr' option has been added. Option 'server' has been marked as deprecated, as it is not used anywhere in IPA code. All the options have been sorted lexicographically. Please provide feedback for added descriptions: +.TP +.B server hostname +Specifies the IPA Server hostname. This option is deprecated. +.TP +.B wait_for_attr boolean +Debug option. Waits for asynchronous execution of 389-ds postoperation plugins before returning data to the client, therefore data added by postoperation plugins is included in the result. Increases execution time. The rest of the patch is just sorting options lexicographically. Tomas Can you add startup_timeout as well? This controls the amount of time we wait when starting a service. The default is 2 minutes. And dogtag_version? The changes you made look good. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade
Martin Kosek wrote: Report errors just like with ipa-ldap-updater. These messages should warn user that some parts of the upgrades may have not been successful and he should follow up on them. Otherwise, user may not notice them at all. ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater logging - only error level or higher severity log messages are printed to stderr, with the same console format. A new debug log that an upgrade script has started was added to make log investigation easier. https://fedorahosted.org/freeipa/ticket/3157 --- Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update will report errors to user: # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* Preparing...### [100%] 1:freeipa-python ### [ 14%] 2:freeipa-client ### [ 29%] 3:freeipa-admintools ### [ 43%] 4:freeipa-server ### [ 57%] ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission denied: '/etc/named.conf' 5:freeipa-server-selinux ### [ 71%] 6:freeipa-server-trust-ad### [ 86%] 7:freeipa-debuginfo ### [100%] Martin Can you add an option to run in info mode (the equivalent of verbose=True)? Otherwise running from the cli returns nothing unless there is an error, I like some amount of output myself. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 223 Simpler instructions to generate certificate
Petr Vobornik wrote: Instructions to generate certificate were simplified. New instructions: 1) Create a certificate database or use an existing one. To create a new database: # certutil -N -d database path 2) Create a CSR with subject CN=hostname,O=realm, for example: # certutil -R -d database path -a -g key size -s 'CN=dev.example.com,O=DEV.EXAMPLE.COM' 3) Copy and paste the CSR (from -BEGIN NEW CERTIFICATE REQUEST- to -END NEW CERTIFICATE REQUEST-) into the text area below: https://fedorahosted.org/freeipa/ticket/3056 ACK, looks good to me. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade
On 10/18/2012 05:22 PM, Rob Crittenden wrote: Martin Kosek wrote: Report errors just like with ipa-ldap-updater. These messages should warn user that some parts of the upgrades may have not been successful and he should follow up on them. Otherwise, user may not notice them at all. ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater logging - only error level or higher severity log messages are printed to stderr, with the same console format. A new debug log that an upgrade script has started was added to make log investigation easier. https://fedorahosted.org/freeipa/ticket/3157 --- Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update will report errors to user: # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* Preparing...### [100%] 1:freeipa-python ### [ 14%] 2:freeipa-client ### [ 29%] 3:freeipa-admintools ### [ 43%] 4:freeipa-server ### [ 57%] ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission denied: '/etc/named.conf' 5:freeipa-server-selinux ### [ 71%] 6:freeipa-server-trust-ad### [ 86%] 7:freeipa-debuginfo ### [100%] Martin Can you add an option to run in info mode (the equivalent of verbose=True)? Otherwise running from the cli returns nothing unless there is an error, I like some amount of output myself. rob ipa-upgradeconfig has a --debug option. I doubt that the output can be more verbose :-) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd
Simo Sorce wrote: Also improve shutdown reliability and restart behavior so we always kill all the processes we started even if the list of processes to handle changed in LDAP. Fixes: https://fedorahosted.org/freeipa/ticket/2302 Should this list be updated if we do a post-install of DNS or the CA? It isn't now which would leave some services running. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command
Jan Cholasta wrote: On 16.10.2012 17:26, Petr Viktorin wrote: On 10/16/2012 04:53 PM, Jan Cholasta wrote: On 16.10.2012 16:27, Petr Viktorin wrote: On 10/16/2012 04:02 PM, Jan Cholasta wrote: Hi, On 15.10.2012 14:45, Petr Viktorin wrote: As I was debugging code that calls long-running or failing commands, I got tired of the invocation being logged after the command is done. This patch should improve the logging. https://fedorahosted.org/freeipa/ticket/3174 --- PetrĀ³ +except: +root_logger.debug('Process failed') +raise Why do you use blank except here? Can you print the reason why the process has failed or the exit code here? Honza I re-raise command afterwards, so the error is not really handled or ignored. It's one of the few situations where a bare except is justified :) OK, makes sense. Since the error is re-raised, it should be handled by the caller. Printing additional info here should be redundant. The exception can happen before the Popen object is created, so the return code might not be available. Anyway bad return code is handled later, here we'd get errors like command not found, fork() failure etc. Right. Anyway, I think logging the return code might come handy in some situations. Can you please add it? You're right. Added. I see that the wording could be better, attaching new patch: s/Process failed/Process execution failed/ s/Process successful/Process finished/ Honza Thanks. ACK. Honza pushed to ipa-3-0 and master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd
Simo Sorce wrote: On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: Simo Sorce wrote: Also improve shutdown reliability and restart behavior so we always kill all the processes we started even if the list of processes to handle changed in LDAP. Fixes: https://fedorahosted.org/freeipa/ticket/2302 Should this list be updated if we do a post-install of DNS or the CA? It isn't now which would leave some services running. Yes we probably should, but I think it should be done as a separate ticket. Simo. What's the impact if we don't do this now? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade
Martin Kosek wrote: On 10/18/2012 05:22 PM, Rob Crittenden wrote: Martin Kosek wrote: Report errors just like with ipa-ldap-updater. These messages should warn user that some parts of the upgrades may have not been successful and he should follow up on them. Otherwise, user may not notice them at all. ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater logging - only error level or higher severity log messages are printed to stderr, with the same console format. A new debug log that an upgrade script has started was added to make log investigation easier. https://fedorahosted.org/freeipa/ticket/3157 --- Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update will report errors to user: # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* Preparing...### [100%] 1:freeipa-python ### [ 14%] 2:freeipa-client ### [ 29%] 3:freeipa-admintools ### [ 43%] 4:freeipa-server ### [ 57%] ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission denied: '/etc/named.conf' 5:freeipa-server-selinux ### [ 71%] 6:freeipa-server-trust-ad### [ 86%] 7:freeipa-debuginfo ### [100%] Martin Can you add an option to run in info mode (the equivalent of verbose=True)? Otherwise running from the cli returns nothing unless there is an error, I like some amount of output myself. rob ipa-upgradeconfig has a --debug option. I doubt that the output can be more verbose :-) Martin Yeah, but there is no middle ground. You either get everything or nothing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd
On Thu, 2012-10-18 at 11:51 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: Simo Sorce wrote: Also improve shutdown reliability and restart behavior so we always kill all the processes we started even if the list of processes to handle changed in LDAP. Fixes: https://fedorahosted.org/freeipa/ticket/2302 Should this list be updated if we do a post-install of DNS or the CA? It isn't now which would leave some services running. Yes we probably should, but I think it should be done as a separate ticket. Simo. What's the impact if we don't do this now? some services will not be turned off by ipactl, however this shouldn't impact much at shutdown, as systemd will shutdown left over stuff as it keeps track of all processes. uhmm however if someone does a ipactl restart those services will not be restarted the first time it is run (we will tell systemd to start them but it will do likely nothing as they are already started), after that they will be handled as they fact they are enabled will be stored in the file. 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 75] log dogtag errors
On 10/18/2012 05:06 AM, Petr Viktorin wrote: This looks much better. I found one more issue, though. +if detail is not None: +err_msg += ' (%s)' % detail Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and 'unicode'. Until our Gettext class supports addition (part of #3188), please use `err_msg = u'%s (%s)' % (err_msg, detail)` instead. Good catch, fixed. New patch attached. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From 503e1e5939bb4fd9af8ecfab2e5a07accf03c3fa Mon Sep 17 00:00:00 2001 From: John Dennis jden...@redhat.com Date: Wed, 17 Oct 2012 13:29:13 -0400 Subject: [PATCH 75-2] log dogtag errors Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit If we get an error from dogtag we always did raise a CertificateOperationError exception with a message describing the problem. Unfortuanately that error message did not go into the log, just sent back to the caller. The fix is to format the error message and send the same message to both the log and use it to initialize the CertificateOperationError exception. This is done in the utility method raise_certificate_operation_error(). https://fedorahosted.org/freeipa/ticket/2622 --- ipaserver/plugins/dogtag.py | 68 - 1 file changed, 48 insertions(+), 20 deletions(-) diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index baa41ad..d52bb7e 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1233,6 +1233,27 @@ class ra(rabase.rabase): self.password = '' super(ra, self).__init__() +def raise_certificate_operation_error(self, func_name, err_msg=None, detail=None): + +:param func_name: function name where error occurred + +:param err_msg: diagnostic error message, if not supplied it will be + 'Unable to communicate with CMS' +:param detail:extra information that will be appended to err_msg + inside a parenthesis + +Raise a CertificateOperationError and log the error message. + + +if err_msg is None: +err_msg = _('Unable to communicate with CMS') + +if detail is not None: +err_msg = u'%s (%s)' % (err_msg, detail) + +self.error('%s.%s(): %s', self.fullname, func_name, err_msg) +raise CertificateOperationError(error=err_msg) + def _host_has_service(self, host, service='CA'): :param host: A host which might be a master for a service. @@ -1376,14 +1397,15 @@ class ra(rabase.rabase): # Parse and handle errors if (http_status != 200): -raise CertificateOperationError(error=_('Unable to communicate with CMS (%s)') % \ - http_reason_phrase) +self.raise_certificate_operation_error('check_request_status', + detail=http_reason_phrase) parse_result = self.get_parse_result_xml(http_body, parse_check_request_result_xml) request_status = parse_result['request_status'] if request_status != CMS_STATUS_SUCCESS: -raise CertificateOperationError(error='%s (%s)' % \ - (cms_request_status_to_string(request_status), parse_result.get('error_string'))) +self.raise_certificate_operation_error('check_request_status', + cms_request_status_to_string(request_status), + parse_result.get('error_string')) # Return command result cmd_result = {} @@ -1461,14 +1483,15 @@ class ra(rabase.rabase): # Parse and handle errors if (http_status != 200): -raise CertificateOperationError(error=_('Unable to communicate with CMS (%s)') % \ - http_reason_phrase) +self.raise_certificate_operation_error('get_certificate', + detail=http_reason_phrase) parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) request_status = parse_result['request_status'] if request_status != CMS_STATUS_SUCCESS: -raise CertificateOperationError(error='%s (%s)' % \ - (cms_request_status_to_string(request_status), parse_result.get('error_string'))) +self.raise_certificate_operation_error('get_certificate', + cms_request_status_to_string(request_status), + parse_result.get('error_string')) # Return command result cmd_result = {} @@ -1527,15 +1550,17 @@ class ra(rabase.rabase): xml='true') # Parse and handle errors if (http_status != 200): -
Re: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage
Tomas Babej wrote: On 10/02/2012 03:55 PM, Rob Crittenden wrote: Tomas Babej wrote: Hi, When executing ipa-replica-manage connect to an unknown or irrelevant master, we now print a sensible error message informing the user about this possiblity as well. https://fedorahosted.org/freeipa/ticket/3105 Tomas I put a whole bunch of code into a try/except and this may be catching errors in unexpected ways. I'm not entirely sure right now what we should do, but looking at the code in the try: repl1.conn.getEntry(master1_dn, ldap.SCOPE_BASE) repl1.conn.getEntry(master2_dn, ldap.SCOPE_BASE) We take in replica1 and replica1 as arguments (the default for replica1 is the current host). If either of these raise a NotFound it means there there is no master of that name. Does that mean that the master was deleted? Well, clearly not. A lot has changed since I did this, I may have been relying on a side-effect, or just hadn't tested well-enough. I wonder if we need that message at all. Is foo is not an IPA server good enough? It still might be confusing if someone didn't know that foo was deleted and it was still running. We could probably verify that it is at least an IPA server by doing similar checking in the client, it all depends on how far we want to take it. rob I modified the patch. Now if the NotFound error is encountered, we try to investigate whether we're trying to connect to an IPA server at all. Please see if you have any suggestions. Tomas Getting there, the errors are a lot better. Can you modify the 'Connection unsuccessful' message to include the server we failed to connect to? The logger isn't so nice either, I think I'd prefer it if we could exclude the severity: ipa: ERROR: LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. Connection unsuccessful. So drop the 'ipa: ERROR: ' part for consistency. TI don't believe we configure the root logger at all in this tool so it is using the defaults. I'd also replace the test for -4 with the constant ipadiscovery.NOT_IPA_SERVER rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Search global catalog for trusted domain SIDs
Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} Note that ccache is successfully created and populated and is usable from command line via ldapsearch: # klist -c /tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN Ticket cache: FILE:/tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN Default principal: IPATEAM$@AD.LOCAL Valid starting ExpiresService principal 10/18/12 21:42:06 10/19/12 07:42:06 krbtgt/AD.LOCAL@AD.LOCAL renew until 10/19/12 21:42:08 10/18/12 21:42:06 10/19/12 07:42:06 ldap/winda.ad.local@AD.LOCAL renew until 10/19/12 21:42:08 # KRB5CCNAME=/tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN ldapsearch -Y GSSAPI -H ldap://winda.ad.local:3268 -b dc=ad,dc=local '((sAMAccountName=ipateam$)(objectClass=*))' SASL/GSSAPI authentication started SASL username: IPATEAM$@AD.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base dc=ad,dc=local with scope subtree # filter: ((sAMAccountName=ipateam$)(objectClass=*)) # requesting: ALL # # IPATEAM$, Users, ad.local dn: CN=IPATEAM$,CN=Users,DC=ad,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IPATEAM$ distinguishedName: CN=IPATEAM$,CN=Users,DC=ad,DC=local instanceType: 4 whenCreated: 20121018132513.0Z whenChanged: 20121018174020.0Z uSNCreated: 209080 uSNChanged: 209106 name: IPATEAM$ objectGUID:: 43oH5Pepm0CCvJ8VGxLEnA== userAccountControl: 2080 primaryGroupID: 513 objectSid:: AQUAAAUVze8BAQQy1QhmzheAyAUAAA== sAMAccountName: IPATEAM$ sAMAccountType: 805306370 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=local dSCorePropagationData: 1601010100.0Z lastLogonTimestamp: 129950556201332000 # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 -- / Alexander Bokovoy From 960277985935169490ca1c550bb8e0e3cd382001 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Thu, 18 Oct 2012 21:46:35 +0300 Subject: [PATCH 4/4] WIP: Resolve external members from trusted domain via Global Catalog A sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace external member name by SID --- ipalib/plugins/group.py | 6 +- ipaserver/dcerpc.py | 162 +++- 2 files changed, 164 insertions(+), 4 deletions(-) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index a174ba62cc32a7fb83474f52e2621521553889af..c4ecd6299d6111a389565e53f3a3e09a5c3f2f89 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -382,7 +382,11 @@ class group_add_member(LDAPAddMember): if domain_validator.is_trusted_sid_valid(sid): sids.append(sid) else: -failed_sids.append((sid, 'Not a trusted domain SID')) +actual_sid = domain_validator.get_sid_trusted_domain_object(sid) +if actual_sid: +sids.append(actual_sid) +else: +failed_sids.append((sid, 'Not a trusted domain SID')) if len(sids) == 0: raise errors.ValidationError(name=_('external member'), error=_('values are not recognized as valid SIDs from trusted domain')) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 80e6b7c87511e1d206df4d1de28574cc7b8410f7..1b5b77661aec20366f37f3a3d1f5e6e48de0cbff 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -29,6 +29,7 @@ from ipalib import
Re: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd
On Thu, 18 Oct 2012, Rob Crittenden wrote: Simo Sorce wrote: Also improve shutdown reliability and restart behavior so we always kill all the processes we started even if the list of processes to handle changed in LDAP. Fixes: https://fedorahosted.org/freeipa/ticket/2302 Should this list be updated if we do a post-install of DNS or the CA? It isn't now which would leave some services running. Same for ipa-adtrust-install. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Search global catalog for trusted domain SIDs
On Thu, 2012-10-18 at 22:00 +0300, Alexander Bokovoy wrote: Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} I do not see anything clearly wrong in the patch, I guess wireshark may help to understand if there is a difference between your code and ldapsearch ? 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] Unit tests failing on F18
Martin Kosek wrote: On 10/18/2012 12:04 AM, Rob Crittenden wrote: Martin Kosek wrote: Hello, I was investigating global unit test failure on Fedora 18 for most of today, I would like to share results I found so far. Unit test and its related scripts on F18 now reports NSS BUSY exception, just like this one: # ./make-testcert Traceback (most recent call last): File ./make-testcert, line 134, in module sys.exit(makecert(reqdir)) File ./make-testcert, line 111, in makecert add=True) File ./make-testcert, line 68, in run result = self.execute(method, *args, **options) File /root/freeipa-master2/ipalib/backend.py, line 146, in execute raise error #pylint: disable=E0702 ipalib.errors.NetworkError: cannot connect to 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. Something In F18 must have changed, this worked before... But leaked NSSConnection objects without proper close() now ends with the exception above. In case of make-testcert script, the exception is raised because the script does the following procedure: 1) connect, do one command 2) disconnect 3) connect, do second command However, during disconnect, NSSConnection is leaked which makes NSS very uncomfortable during second connection atempt (and nss_shutdown()). I managed to fix this issue with attached patch. ./make-testcert or ./make-test tests/test_xmlrpc/test_group_plugin.py works fine now. But global ./make-test still fails, I think there is some remaining NSSConnection leak, I suspect there is something wrong with how we use our context (threading.local object). It looses a connection or some other thread invoked in ldap2 module may be kicking in, here is my debug output: CONTEXT[xmlclient] = ipalib.request.Connection object at 0x9a1f5ec Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in /root/.ipa/.dmpw Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT 150714476: GET languages CONTEXT[xmlclient] = None The connection is in the context, but then something happens and it is gone. Then, unit tests try to connect again and NSS fails. I would be really glad if somebody with a knowledge of NSS or how threads in Python/IPA work could give me some advice... Thanks! Martin I built upon your patch and have something that seems to work at least somewhat. I'm getting some unexpected test failures when running the entire suite but no NSS shutdown errors. I haven't had a chance to really investigate everything yet, sending this out as a work-in-progress in case you want to take a look. rob Yeah, this is great! I tested a fresh build+install on Fedora 18 with your patch and all tests succeeded. So as for F18, I am inclined to ACK the patch as is. I am just not sure that this will work on platforms with Python version 2.7, xmlrpclib is different there. Martin Here is my first crack at fixing that too. It requires a bunch of run time juggling though. rob From c53e283986f2b00db53e28009829ba09d62930aa Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Wed, 17 Oct 2012 16:58:54 -0400 Subject: [PATCH] Close connection after each request, avoid NSS shutdown problem. The unit tests were failing when executed against an Apache server in F-18 due to dangling references causing NSS shutdown to fail. --- ipalib/rpc.py | 30 +- ipapython/nsslib.py | 6 ++ 2 files changed, 31 insertions(+), 5 deletions(-) diff --git a/ipalib/rpc.py b/ipalib/rpc.py index e97536d9de5c455d3ff58c081fca37f16d087370..8389396e0e23623b5edb60d634041949f95711ce 100644 --- a/ipalib/rpc.py +++ b/ipalib/rpc.py @@ -257,16 +257,24 @@ class SSLTransport(LanguageAwareTransport): # If we an existing connection exists using the same NSS database # there is no need to re-initialize. Pass thsi into the NSS # connection creator. +if sys.version_info (2, 6): +if self._connection and host == self._connection[0]: +return self._connection[1] + dbdir = '/etc/pki/nssdb' no_init = self.__nss_initialized(dbdir) -(major, minor, micro, releaselevel, serial) = sys.version_info -if major == 2 and minor 7: +if sys.version_info (2, 7): conn = NSSHTTPS(host, 443, dbdir=dbdir, no_init=no_init) else: conn = NSSConnection(host, 443, dbdir=dbdir, no_init=no_init) self.dbdir=dbdir + conn.connect() -return conn +if sys.version_info (2, 7): +return conn +else: +self._connection = host, conn +return self._connection[1] class KerbTransport(SSLTransport): @@ -331,6 +339,13 @@ class KerbTransport(SSLTransport): return (host, extra_headers, x509) + +def
[Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
We were seeing a unicode failure when trying to request a certificate with subject alt names. This one-liner should fix it. rob From 80e54a8efe98326f03a331bae4564727df4ca9d7 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Wed, 17 Oct 2012 13:44:45 -0400 Subject: [PATCH] Fix requesting certificates that contain subject altnames. https://fedorahosted.org/freeipa/ticket/3184 --- ipalib/plugins/cert.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 781eeb037b7bb390979798c41471c1f142f73415..c4bbf8215341d1fdbf8b84cf70ee7ebd8e2b96c4 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -336,6 +336,7 @@ class cert_request(VirtualCommand): subjectaltname = pkcs10.get_subjectaltname(request) if subjectaltname is not None: for name in subjectaltname: +name = unicode(name) try: hostentry = api.Command['host_show'](name, all=True, raw=True)['result'] hostdn = hostentry['dn'] -- 1.7.12.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges
On Thu, Oct 18, 2012 at 08:31:50AM +0200, Tomas Babej wrote: On 10/17/2012 08:12 PM, Sumit Bose wrote: On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: On 10/17/2012 02:34 PM, Sumit Bose wrote: On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: On 10/17/2012 11:14 AM, Sumit Bose wrote: On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: Hi, commands ipa idrange-add / idrange-mod no longer allows the user to enter primary or secondary rid range such that has non-zero intersection with primary or secondary rid range of another existing id range, as this could cause collision. Unit tests added to test_range_plugin.py https://fedorahosted.org/freeipa/ticket/3086 Tomas Thank you for the patch, comments are in-line. bye, Sumit Thank you for your suggestions. New version of the patch attached. Tomas Thank you for addressing my comments. I just realized that the check is too strict. The ranges of the Posix IDs [base_id - base_id+id_range_size) may not overlap for any existing range because those IDs belong to the single Posix ID namespace of the IPA domain. I.e each user, local or from a trusted domain, must have a unique Posix ID. The RID ranges [base_rid, base_rid+id_range_size) and [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap with RID ranges from the same domain. So the RID ranges for the local domain may not overlap and the RID ranges for any specific trusted domain may not overlap. It is allowed that there is a range form the local domain may have base_rid=1000 and a range from a trusted domain as well. This is ok because the RID is only part of the identifier, each domain has a unique domain SID which is used together with the RID to identify e.g. a user. I would suggest to look for the ipaNTTrustedDomainSID attribute in slapi_entry_to_range_info() too and add it to struct range_info. In ranges_overlap() you can then check the Posix ID range for all ranges but do the RID checks only when the domain identifiers are either both NULL (local IPA domain) or are the same strings. Sorry for not seeing this earlier. bye, Sumit Thanks for catching this issue. It is solved in the newest revision of the patch. Tomas sorry, found another one ... ... +static int ranges_overlap(struct range_info *r1, struct range_info *r2) +{ +if (r1-name != NULL r2-name != NULL +strcasecmp(r1-name, r2-name) == 0) { +return 0; +} + +/* check if base range overlaps with existing base range */ +if (intervals_overlap(r1-base_id, r2-base_id, +r1-id_range_size, r2-id_range_size)){ +return 1; +} + +/* if both base_rid and secondary_base_rid = 0, the rid range is not set */ +bool rid_ranges_set = (r1-base_rid != 0 || r1-secondary_base_rid != 0) + (r2-base_rid != 0 || r2-secondary_base_rid != 0); + +bool ranges_from_same_domain = + (r1-domain_id == NULL r2-domain_id == NULL) || + (strcasecmp(r1-domain_id, r2-domain_id) == 0); + you have to check that both domain_id are not NULL before calling strcasecmp. bye, Sumit Null pointer check added. Thank you. ACK bye, Sumit Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Search global catalog for trusted domain SIDs
On Thu, 18 Oct 2012, Sumit Bose wrote: On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} Note that ccache is successfully created and populated and is usable from command line via ldapsearch: ... + +def __resolve_against_gc(self, info, name): +conn = IPAdmin(host=info['dc'], port=3268) +auth = self.__extract_trusted_auth(info) +if auth: +(ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) +if ccache_name: +cb_info = dict() +(CB_USER, CB_GETREALM) = (0x4001, 0x4008) +cb_info[CB_USER] = principal +cb_info[CB_GETREALM] = info['dns_domain'].upper() +sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') +old_ccache = os.environ.get('KRB5CCNAME') +os.environ[KRB5CCNAME] = ccache_name +conn.sasl_interactive_bind_s(None, sasl_auth) +os.environ[KRB5CCNAME] = old_ccache Are you sure the bind is already finished here? I haven't looked at the implementation, but if it does a lazy bind, i.e. only bind when the first request is made, it will see the wrong ccache. Can you try to set KRB5CCNAME to the old value after calling conn.getEntry()? Yes, I'm sure because it raises exception from within sasl_interactive_bind_s() call, it never ever gets to the next line. [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py, line 556, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 229, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 99, in _ldap_call [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Search global catalog for trusted domain SIDs
On Thu, Oct 18, 2012 at 11:42:34PM +0300, Alexander Bokovoy wrote: On Thu, 18 Oct 2012, Sumit Bose wrote: On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} Note that ccache is successfully created and populated and is usable from command line via ldapsearch: ... + +def __resolve_against_gc(self, info, name): +conn = IPAdmin(host=info['dc'], port=3268) +auth = self.__extract_trusted_auth(info) +if auth: +(ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) +if ccache_name: +cb_info = dict() +(CB_USER, CB_GETREALM) = (0x4001, 0x4008) +cb_info[CB_USER] = principal +cb_info[CB_GETREALM] = info['dns_domain'].upper() +sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') +old_ccache = os.environ.get('KRB5CCNAME') +os.environ[KRB5CCNAME] = ccache_name +conn.sasl_interactive_bind_s(None, sasl_auth) +os.environ[KRB5CCNAME] = old_ccache Are you sure the bind is already finished here? I haven't looked at the implementation, but if it does a lazy bind, i.e. only bind when the first request is made, it will see the wrong ccache. Can you try to set KRB5CCNAME to the old value after calling conn.getEntry()? Yes, I'm sure because it raises exception from within sasl_interactive_bind_s() call, it never ever gets to the next line. [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py, line 556, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 229, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 99, in _ldap_call [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} ok another guess. In the python docs it is said the Such changes to the environment affect subprocesses started with os.system(), popen() or fork() and execv(). So I guess os.environ[KRB5CCNAME]=something does not change the environment of the running process, but only python data. If I try to set a new env var in the python interpreter and look at /proc/PID/environ from a different shell, I see no changes. bye, Sumit -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Search global catalog for trusted domain SIDs
On Thu, 18 Oct 2012, Sumit Bose wrote: On Thu, Oct 18, 2012 at 11:42:34PM +0300, Alexander Bokovoy wrote: On Thu, 18 Oct 2012, Sumit Bose wrote: On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} Note that ccache is successfully created and populated and is usable from command line via ldapsearch: ... + +def __resolve_against_gc(self, info, name): +conn = IPAdmin(host=info['dc'], port=3268) +auth = self.__extract_trusted_auth(info) +if auth: +(ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) +if ccache_name: +cb_info = dict() +(CB_USER, CB_GETREALM) = (0x4001, 0x4008) +cb_info[CB_USER] = principal +cb_info[CB_GETREALM] = info['dns_domain'].upper() +sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') +old_ccache = os.environ.get('KRB5CCNAME') +os.environ[KRB5CCNAME] = ccache_name +conn.sasl_interactive_bind_s(None, sasl_auth) +os.environ[KRB5CCNAME] = old_ccache Are you sure the bind is already finished here? I haven't looked at the implementation, but if it does a lazy bind, i.e. only bind when the first request is made, it will see the wrong ccache. Can you try to set KRB5CCNAME to the old value after calling conn.getEntry()? Yes, I'm sure because it raises exception from within sasl_interactive_bind_s() call, it never ever gets to the next line. [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py, line 556, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 229, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File /usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 99, in _ldap_call [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} ok another guess. In the python docs it is said the Such changes to the environment affect subprocesses started with os.system(), popen() or fork() and execv(). So I guess os.environ[KRB5CCNAME]=something does not change the environment of the running process, but only python data. If I try to set a new env var in the python interpreter and look at /proc/PID/environ from a different shell, I see no changes. No, this does not matter. I'm reproducing the same error with a standalone app that does not modify environment: http://cpaste.org/1370/raw/ We do modify environment in the framework code (ipaserver/rpcserver.py) already and it works just fine. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel