Re: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges

2012-10-18 Thread Tomas Babej

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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Petr Viktorin

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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Martin Kosek
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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Simo Sorce
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

2012-10-18 Thread John Dennis

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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Alexander Bokovoy

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

2012-10-18 Thread Alexander Bokovoy

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

2012-10-18 Thread Simo Sorce
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

2012-10-18 Thread Rob Crittenden

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

2012-10-18 Thread Rob Crittenden
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

2012-10-18 Thread Sumit Bose
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

2012-10-18 Thread Alexander Bokovoy

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

2012-10-18 Thread Sumit Bose
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

2012-10-18 Thread Alexander Bokovoy

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