[Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly
Hello,
this patch fixes annoying bug from ticket #55: BIND cannot be shutdown
correctly, if psearch is enabled and LDAP connect fails
Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55
It's trivial three line patch, so Adam ACKed it on IRC.
Patch is already in master:
https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4
I think it's annoying and fix is trivial, so I opened BZ ticket for
RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375
--
Petr^2 Spacek
From 55d2886bb016adf3081a25eea616ce40f17d03e4 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Mon, 12 Mar 2012 13:01:25 +0100
Subject: [PATCH] Fix ticket #55: BIND cannot be shutdown correctly, if
psearch is enabled and LDAP connect fails Signed-off-by:
Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index eff7b3d..0f01ec2 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -3063,6 +3063,9 @@ ldap_psearch_watcher(isc_threadarg_t arg)
/* Try to connect. */
while (conn-handle == NULL) {
+ if (inst-exiting)
+goto cleanup;
+
log_error(ldap_psearch_watcher handle is NULL.
Next try in %ds, inst-reconnect_interval);
sleep(inst-reconnect_interval);
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] 0025-26 Test improvements
Patch 25 fixes errors I found by running pylint on the testsuite. They
were in code that was unused, either by error or because it only runs on
errors.
Patch 26 adds a test for the batch plugin.
--
Petr³
From ac65557938bcfe21032e04b30db9c8d65224b844 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 9 Mar 2012 11:48:32 -0500
Subject: [PATCH 25/26] Fix little test errors
Two test methods in test_rpcserver had the same name; the first didn't get
to run.
Another duplicate pair was in test_hbac_plugin with the same name; the ignored
test had small error in it.
check_TypeError used a wrong constant name
An error reporting function in test.util used uninitialized argument names.
This patch fixes these problems.
---
tests/test_ipaserver/test_rpcserver.py |5 ++---
tests/test_xmlrpc/test_hbac_plugin.py |6 +++---
tests/util.py |4 ++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/tests/test_ipaserver/test_rpcserver.py b/tests/test_ipaserver/test_rpcserver.py
index 97632b05d454b0ece60181ceeb6980b95e6909a1..51255b6e7acb3c2efb38a9761a735345e3cd36eb 100644
--- a/tests/test_ipaserver/test_rpcserver.py
+++ b/tests/test_ipaserver/test_rpcserver.py
@@ -83,7 +83,7 @@ def test_bad_request():
assert s.headers == [('Content-Type', 'text/html; charset=utf-8')]
-def test_internal_error():
+def test_internal_error_500():
f = rpcserver.HTTP_Status()
t = rpcserver._internal_error_template
s = StartResponse()
@@ -96,7 +96,7 @@ def test_internal_error():
assert s.headers == [('Content-Type', 'text/html; charset=utf-8')]
-def test_internal_error():
+def test_internal_error_401():
f = rpcserver.HTTP_Status()
t = rpcserver._unauthorized_template
s = StartResponse()
@@ -109,7 +109,6 @@ def test_internal_error():
assert s.headers == [('Content-Type', 'text/html; charset=utf-8')]
-
def test_params_2_args_options():
Test the `ipaserver.rpcserver.params_2_args_options` function.
diff --git a/tests/test_xmlrpc/test_hbac_plugin.py b/tests/test_xmlrpc/test_hbac_plugin.py
index 268c8d9d2217de71a936f691e5dc1666e9afb4b1..961db6dce24dddfd2d22682e7bec5571650e7d18 100644
--- a/tests/test_xmlrpc/test_hbac_plugin.py
+++ b/tests/test_xmlrpc/test_hbac_plugin.py
@@ -263,8 +263,8 @@ class test_hbac(XMLRPC_test):
assert 'hostgroup' in failed['memberhost']
assert not failed['memberhost']['hostgroup']
entry = ret['result']
-assert 'memberhost_host' not in res[1]
-assert 'memberhost_hostgroup' not in res[1]
+assert 'memberhost_host' not in entry
+assert 'memberhost_hostgroup' not in entry
def test_a_hbacrule_add_sourcehost(self):
@@ -314,7 +314,7 @@ class test_hbac(XMLRPC_test):
entry = ret['result']
assert 'memberservice service' not in entry
-def test_b_hbacrule_remove_host(self):
+def test_b_hbacrule_remove_sourcehost(self):
Test removing source host and hostgroup from HBAC rule using `xmlrpc.hbacrule_remove_host`.
diff --git a/tests/util.py b/tests/util.py
index 5a365fbcd0e065b2f645b379b554b973d511c791..9bce7c08ca33de50dbc4ee57be61f2aa23dcb8be 100644
--- a/tests/util.py
+++ b/tests/util.py
@@ -446,7 +446,7 @@ def check_TypeError(value, type_, name, callback, *args, **kw):
assert e.type is type_
assert e.name == name
assert type(e.name) is str
-assert str(e) == ipalib.errors.TYPE_FORMAT % (name, type_, value)
+assert str(e) == ipalib.errors.TYPE_ERROR % (name, type_, value)
return e
@@ -592,7 +592,7 @@ class DummyClass(object):
def __process(self, name_, args_, kw_):
if self.__i = len(self.__calls):
raise AssertionError(
-'extra call: %s, %r, %r' % (name, args, kw)
+'extra call: %s, %r, %r' % (name_, args_, kw_)
)
(name, args, kw, result) = self.__calls[self.__i]
self.__i += 1
--
1.7.7.6
From 14bd9132fc427c3fe0f4a4af88bfb5148f3ea777 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 12 Mar 2012 05:58:44 -0400
Subject: [PATCH 26/26] Test the batch plugin
This adds tests for the batch plugin, and changes its output
declaration to allow results as tuples (this tripped validation).
The assert_deepequal function ignores the order of items in lists.
Document this in its docstring, and use a custom checker for the
batch plugin results.
---
ipalib/plugins/batch.py| 11 +-
tests/test_xmlrpc/test_batch_plugin.py | 194
tests/util.py |3 +
3 files changed, 201 insertions(+), 7 deletions(-)
create mode 100644 tests/test_xmlrpc/test_batch_plugin.py
diff --git a/ipalib/plugins/batch.py b/ipalib/plugins/batch.py
index 4c5a6bd1e1b7ddb834f34e592837de5e233f7bcf..8abad5e1eeab5eeed46c5dc09f17bda1857f9562 100644
--- a/ipalib/plugins/batch.py
+++
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands
On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly
On 03/12/2012 08:15 AM, Petr Spacek wrote: Hello, this patch fixes annoying bug from ticket #55: BIND cannot be shutdown correctly, if psearch is enabled and LDAP connect fails Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 It's trivial three line patch, so Adam ACKed it on IRC. Patch is already in master: https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 I think it's annoying and fix is trivial, so I opened BZ ticket for RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel It seems that code has tabs which violates our coding standards. At least the indentation looks wrong. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups
On Tue, 2012-03-06 at 13:55 +0100, Petr Viktorin wrote: On 03/05/2012 04:10 PM, Petr Viktorin wrote: This patch fixes DN handling when removing LDAP entries from groups. Because they deal with commas and backslashes in a CSV param, the tests here rely on my patch 0015. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Here is the same patch with CSV-stuff-dependent tests removed. Thanks, this patch looks and works fine, so ACK. Before we push it, can you please update the tests in this patch or even better send an updated version of your patch 22 where RDN is changed to ipaUniqueID? Otherwise, if we push both these patches, we would get test failures with DN mismatches. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly
On Mon, 2012-03-12 at 08:46 -0400, Dmitri Pal wrote: On 03/12/2012 08:15 AM, Petr Spacek wrote: Hello, this patch fixes annoying bug from ticket #55: BIND cannot be shutdown correctly, if psearch is enabled and LDAP connect fails Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 It's trivial three line patch, so Adam ACKed it on IRC. Patch is already in master: https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 I think it's annoying and fix is trivial, so I opened BZ ticket for RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel It seems that code has tabs which violates our coding standards. At least the indentation looks wrong. The whole bind-dyndb-ldap plugin use tabs for indentation, I would keep that unless we want to create mixed tab-space environment. I just see that Petr indented the statement with 2 tabs instead of one. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased)
On 03/12/2012 01:26 PM, Martin Kosek wrote:
On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote:
Since sudo commands are case-sensitive, we can't use the CN as the RDN.
With this patch, the UUID is used instead.
It seems like a too easy fix. What am I missing?
As far as I understand, the fact that the DN has a different structure
now shouldn't cause problems, even if there still are commands created
by old IPA versions.
For testing, use an unpatched version to create a few of these.
The sudo commands are no longer sorted in sudocmd-find output. Doing
that would require the ability to use an arbitrary attribute as sort
key. Should I file an issue for that?
I don't think that's necessary. We sort by LDAP object's primary key and
since new SUDO commands still have sudocmd as its primary key, the
sorting should just work (at least it does for me).
Right, sorry for the noise.
Tests for the case sensitivity are included.
https://fedorahosted.org/freeipa/ticket/2482
This works pretty fine. Both my old client tests and sudoers compat tree
tests looks good. So, cautious ACK from me.
Martin
The attached version is rebased against my patch 20.
--
Petr³
From bad3dc3722720369ec95f3c6b7029db72c223c3f Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 8 Mar 2012 07:55:00 -0500
Subject: [PATCH] Use ipauniqueid for the RDN of sudo commands
Since sudo commands are case-sensitive, we can't use the CN
as the RDN.
Tests for case-sensitive behavior included
https://fedorahosted.org/freeipa/ticket/2482
---
ipalib/plugins/sudocmd.py |1 +
tests/test_xmlrpc/test_sudocmd_plugin.py | 82
tests/test_xmlrpc/test_sudocmdgroup_plugin.py | 86 +
tests/test_xmlrpc/xmlrpc_test.py | 13 +++-
4 files changed, 151 insertions(+), 31 deletions(-)
diff --git a/ipalib/plugins/sudocmd.py b/ipalib/plugins/sudocmd.py
index 42068edea3c51804be9ee5919934462afbee578f..f27a58cadd6e6abc16611621387f26125737bf78 100644
--- a/ipalib/plugins/sudocmd.py
+++ b/ipalib/plugins/sudocmd.py
@@ -62,6 +62,7 @@ class sudocmd(LDAPObject):
'memberof': ['sudocmdgroup'],
}
uuid_attribute = 'ipauniqueid'
+rdn_attribute = 'ipauniqueid'
label = _('Sudo Commands')
label_singular = _('Sudo Command')
diff --git a/tests/test_xmlrpc/test_sudocmd_plugin.py b/tests/test_xmlrpc/test_sudocmd_plugin.py
index cbbd26cd7061ee73c44f691692072daaf6f84f50..a9f118460432e9c33f665db05df0340d73da885d 100644
--- a/tests/test_xmlrpc/test_sudocmd_plugin.py
+++ b/tests/test_xmlrpc/test_sudocmd_plugin.py
@@ -22,17 +22,20 @@ Test the `ipalib/plugins/sudocmd.py` module.
from ipalib import api, errors
-from tests.test_xmlrpc.xmlrpc_test import Declarative, fuzzy_uuid
+from tests.test_xmlrpc.xmlrpc_test import (Declarative, fuzzy_sudocmddn,
+fuzzy_uuid)
from tests.test_xmlrpc import objectclasses
from ipalib.dn import *
sudocmd1 = u'/usr/bin/sudotestcmd1'
+sudocmd1_camelcase = u'/usr/bin/sudoTestCmd1'
class test_sudocmd(Declarative):
cleanup_commands = [
('sudocmd_del', [sudocmd1], {}),
+('sudocmd_del', [sudocmd1_camelcase], {}),
]
tests = [
@@ -69,9 +72,7 @@ class test_sudocmd(Declarative):
value=sudocmd1,
summary=u'Added Sudo Command %s' % sudocmd1,
result=dict(
-dn=lambda x: DN(x) == \
-DN(('sudocmd',sudocmd1),('cn','sudocmds'),('cn','sudo'),
- api.env.basedn),
+dn=fuzzy_sudocmddn,
sudocmd=[sudocmd1],
description=[u'Test sudo command 1'],
objectclass=objectclasses.sudocmd,
@@ -80,6 +81,26 @@ class test_sudocmd(Declarative):
),
),
+dict(
+desc='Create %r' % sudocmd1_camelcase,
+command=('sudocmd_add', [sudocmd1_camelcase],
+dict(
+description=u'Test sudo command 2',
+),
+),
+expected=dict(
+value=sudocmd1_camelcase,
+summary=u'Added Sudo Command %s' % sudocmd1_camelcase,
+result=dict(
+dn=fuzzy_sudocmddn,
+sudocmd=[sudocmd1_camelcase],
+description=[u'Test sudo command 2'],
+objectclass=objectclasses.sudocmd,
+ipauniqueid=[fuzzy_uuid],
+),
+),
+),
+
dict(
desc='Try to create duplicate %r' % sudocmd1,
@@ -91,6 +112,16 @@ class test_sudocmd(Declarative):
expected=errors.DuplicateEntry(),
),
+dict(
+desc='Try to create duplicate %r' % sudocmd1_camelcase,
+command=('sudocmd_add', [sudocmd1_camelcase],
+dict(
+description=u'Test sudo command 2',
+
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased)
On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: On 03/12/2012 01:26 PM, Martin Kosek wrote: On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). Right, sorry for the noise. Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin The attached version is rebased against my patch 20. Ah, I found an issue with the changed RDN attribute. We crash when I delete sudocmd that sudorule has enrolled as a member: # ipa sudocmd-add bar1 # ipa sudocmd-add bar2 # ipa sudorule-add foo # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 # ipa sudocmd-del bar2 # ipa sudorule-find ipa: ERROR: an internal error has occurred /var/log/httpd/error_log: [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 315, in wsgi_execute [Mon Mar 12 10:41:24 2012] [error] result = self.Command[name](*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 1866, in execute [Mon Mar 12 10:41:24 2012] [error] self.obj.convert_attribute_members(e[1], *args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 518, in convert_attribute_members [Mon Mar 12 10:41:24 2012] [error] ldap_obj.get_primary_key_from_dn(member) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 490, in get_primary_key_from_dn [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/dn.py, line 1137, in __getitem__ [Mon Mar 12 10:41:24 2012] [error] raise KeyError(\\%s\\ not found in %s % (key, self. __str__())) The problem is in this function: def get_primary_key_from_dn(self, dn): try: if self.rdn_attribute: (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) try: return entry_attrs[self.primary_key.name][0] except (KeyError, IndexError): return '' except errors.NotFound: pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) return dn[self.primary_key.name] Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups
On Mon, 2012-03-12 at 14:05 +0100, Martin Kosek wrote: On Tue, 2012-03-06 at 13:55 +0100, Petr Viktorin wrote: On 03/05/2012 04:10 PM, Petr Viktorin wrote: This patch fixes DN handling when removing LDAP entries from groups. Because they deal with commas and backslashes in a CSV param, the tests here rely on my patch 0015. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Here is the same patch with CSV-stuff-dependent tests removed. Thanks, this patch looks and works fine, so ACK. Before we push it, can you please update the tests in this patch or even better send an updated version of your patch 22 where RDN is changed to ipaUniqueID? Otherwise, if we push both these patches, we would get test failures with DN mismatches. Martin Pushed to master, ipa-2-2. Updated test are being dealt with in a scope of patch 0022. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa
Alexander Bokovoy wrote: On Wed, 07 Mar 2012, Rob Crittenden wrote: Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in enforcing mode. This is being done in the HTTP instance so we can set both booleans in one step and save a bit of time (it is still slow). I would prefer all platform-specific manipulations of security policies to be moved to platform-specific module. Make a HTTP class there (like I did dirsrv class in systemd backend) and perform manipulations on service enable. This way main code will stay clear of platform-specific code. Sorry for not looking into the issue before. I'd prefer to keep the change simple for now and do the big move post 2.2. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa
On Mon, 12 Mar 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Wed, 07 Mar 2012, Rob Crittenden wrote: Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in enforcing mode. This is being done in the HTTP instance so we can set both booleans in one step and save a bit of time (it is still slow). I would prefer all platform-specific manipulations of security policies to be moved to platform-specific module. Make a HTTP class there (like I did dirsrv class in systemd backend) and perform manipulations on service enable. This way main code will stay clear of platform-specific code. Sorry for not looking into the issue before. I'd prefer to keep the change simple for now and do the big move post 2.2. ACK on condition you'd file a ticket for the post 2.2 work. :) -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install
Martin Kosek wrote: On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: https://fedorahosted.org/freeipa/ticket/2415 https://fedorahosted.org/freeipa/ticket/1995 Added exception handler to certutil operation of adding CA to the default NSS database. If operation fails, installation is aborted and changes are rolled back. #2415 If obtaining host TGT fails, the installation is aborted and changes are rolled back. #1995 ACK. Pushed to master, ipa-2-2. Martin I wonder if we need to add an escape for --force here. The kinit is just to do things like nsupdate and add the SSH host keys. One might deem those not critical. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install
On Mon, 2012-03-12 at 11:17 -0400, Rob Crittenden wrote: Martin Kosek wrote: On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: https://fedorahosted.org/freeipa/ticket/2415 https://fedorahosted.org/freeipa/ticket/1995 Added exception handler to certutil operation of adding CA to the default NSS database. If operation fails, installation is aborted and changes are rolled back. #2415 If obtaining host TGT fails, the installation is aborted and changes are rolled back. #1995 ACK. Pushed to master, ipa-2-2. Martin I wonder if we need to add an escape for --force here. The kinit is just to do things like nsupdate and add the SSH host keys. One might deem those not critical. rob This was a keytab kinit, as original ticket says a failure to get a correct keytab will make it impossible to login anyway as ldap binds from sssd will fail and auth verification will fail. This sounds pretty critical to me... Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased)
On Mon, 2012-03-12 at 16:01 +0100, Martin Kosek wrote: On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: On 03/12/2012 01:26 PM, Martin Kosek wrote: On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). Right, sorry for the noise. Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin The attached version is rebased against my patch 20. Ah, I found an issue with the changed RDN attribute. We crash when I delete sudocmd that sudorule has enrolled as a member: # ipa sudocmd-add bar1 # ipa sudocmd-add bar2 # ipa sudorule-add foo # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 # ipa sudocmd-del bar2 # ipa sudorule-find ipa: ERROR: an internal error has occurred /var/log/httpd/error_log: [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 315, in wsgi_execute [Mon Mar 12 10:41:24 2012] [error] result = self.Command[name](*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 1866, in execute [Mon Mar 12 10:41:24 2012] [error] self.obj.convert_attribute_members(e[1], *args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 518, in convert_attribute_members [Mon Mar 12 10:41:24 2012] [error] ldap_obj.get_primary_key_from_dn(member) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 490, in get_primary_key_from_dn [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/dn.py, line 1137, in __getitem__ [Mon Mar 12 10:41:24 2012] [error] raise KeyError(\\%s\\ not found in %s % (key, self. __str__())) The problem is in this function: def get_primary_key_from_dn(self, dn): try: if self.rdn_attribute: (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) try: return entry_attrs[self.primary_key.name][0] except (KeyError, IndexError): return '' except errors.NotFound: pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) return dn[self.primary_key.name] Martin I found one more issue, this one is more serious (I am glad my hunch was not malfunctioning). This patch breaks ACIs for sudocmd, user with appropriate privilege will no longer be able to add/modify/delete sudo commands: # kinit fbar Password for f...@idm.lab.bos.redhat.com: # ipa sudorule-add fbar -- Added Sudo Rule fbar -- Rule name: fbar Enabled: TRUE # ipa sudorule-del fbar Deleted Sudo Rule fbar # ipa sudocmd-add fbar1 ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 'ipaUniqueID=c68b98ae-6c58-11e1-be75-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. # ipa sudocmd-del sudocmd1 ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'ipaUniqueID=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. # ipa sudocmd-mod sudocmd1 --desc=foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased)
On 03/12/2012 04:01 PM, Martin Kosek wrote: On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: On 03/12/2012 01:26 PM, Martin Kosek wrote: On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). Right, sorry for the noise. Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin The attached version is rebased against my patch 20. Ah, I found an issue with the changed RDN attribute. We crash when I delete sudocmd that sudorule has enrolled as a member: # ipa sudocmd-add bar1 # ipa sudocmd-add bar2 # ipa sudorule-add foo # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 # ipa sudocmd-del bar2 # ipa sudorule-find ipa: ERROR: an internal error has occurred /var/log/httpd/error_log: [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 315, in wsgi_execute [Mon Mar 12 10:41:24 2012] [error] result = self.Command[name](*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 1866, in execute [Mon Mar 12 10:41:24 2012] [error] self.obj.convert_attribute_members(e[1], *args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 518, in convert_attribute_members [Mon Mar 12 10:41:24 2012] [error] ldap_obj.get_primary_key_from_dn(member) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 490, in get_primary_key_from_dn [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/dn.py, line 1137, in __getitem__ [Mon Mar 12 10:41:24 2012] [error] raise KeyError(\\%s\\ not found in %s % (key, self. __str__())) The problem is in this function: def get_primary_key_from_dn(self, dn): try: if self.rdn_attribute: (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) try: return entry_attrs[self.primary_key.name][0] except (KeyError, IndexError): return '' except errors.NotFound: pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) return dn[self.primary_key.name] Martin Should sudocmd-del should also delete the command from any rules the command is in? That function needs to be fixed either way. But I'm not sure what it should do if the entry doesn't exist. Return the full DN instead? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0012-13 Don't allow deleting required config options
On Fri, 2012-03-02 at 10:07 +0100, Petr Viktorin wrote: On 02/29/2012 04:09 PM, Petr Viktorin wrote: On 02/29/2012 03:53 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/29/2012 11:14 AM, Jan Cholasta wrote: On 29.2.2012 11:09, Petr Viktorin wrote: On 02/28/2012 03:19 PM, Jan Cholasta wrote: On 28.2.2012 11:54, Petr Viktorin wrote: On 02/27/2012 10:44 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/20/2012 08:51 PM, Rob Crittenden wrote: Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/2159 says various config options are not marked Required, so entering an empty value for it will pass validation (and IPA will blow up later when it expects a string,not None). Forexample the following: $ ipa config-mod --groupsearch= fails with AttributeError: 'NoneType' object has no attribute 'split' There is a more general problem behind this, though: even if the attributes *are* marked as Required, an empty string will pass validation. This is because `None` is used in `Param.validate` to mean both No value supplied and Empty value supplied. The method currently assumes the former, and skips validation entirely for `None` values to optional parameters. For example, the following will delete membergroup, even though it's a required attribute : $ ipa delegation-add --attrs=street --group=editors \ --membergroup=admins td1 $ ipa delegation-mod --membergroup= td1 Note that some LDAPObjects handle this with a _check_empty_attrs function, so they aren't affected. That function is specific to LADP objects, though. So I needed to tackle this on a lower level. This patch solves the problem by * adding a 'nonempty' flag when a required parameter of a CRUD Update object is auto-converted to a non-required parameter * making the`validate` method aware of whether the parameter was supplied; and if it was, honor the nonempty flag. The second patch fixes https://fedorahosted.org/freeipa/ticket/2159 by marking required config options as required. This looks good but I think there are other things to protect in config as well such as the default e-mail domain. It is probably safe to say that everything in there is required. rob Let me just double-check this with you. According to code in the user plugin (around line 330), if the default e-mail domain is not set, users don't get an address auto-assigned. Do we really want to require user e-mails? ipaconfigstring (the password plugin flags) are a set (multivalue, not required). The rest of the values I left as not required are for optional features or limits: search results time limit, max. username length, password expiry notification. Currently if these are missing, the feature/limit is disabled (well, except for the time limit). But, there are also special values (0 or -1) that have the same effect as a missing value. Sometimes they're documented. So we want to enforce that users use these special values instead of removing the config entry? I think we want to enforce that these are defined. It will be confusing for users if these are not there at all. I don't think we need to show the special options, just declare that the attribute is required. rob Attaching updated patch 13. Only the default e-mail domain (https://fedorahosted.org/freeipa/ticket/2409) and ipaconfigstring are still optional. You have removed all the config-related defensive code in the patch, is this a good idea? What will happen if someone e.g. deletes a required config attribute directly from LDAP? Then IPA crashes. The defensive code wasn't there for all cases anyway, as ticket #2159 shows. If we want to protect against this it would probably be better to make the config class itself give the default when a required value is missing. This, and raise an error in cases where no default is available (the check should probably be done in ldap.get_ipa_config). Honza Would a better approach be to modify the LDAP schema to require these values? I think that may be a longer-term fix. I propose we keep the defensive code in for now and correct it in the future. rob Here is an updated patch 13 that does that. And here is patch 12 rebased against current master. ACK for 0012-02 and 0013-03. I think this is a good compromise for now. Pushed to master, ipa-2-2. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with Failed password error
On Fri, Mar 09, 2012 at 04:06:33PM -0500, Dmitri Pal wrote:
As far as I understand underlying DS can also be configured to create
weak hashes needed for NIS but it is not recommended. But this is
something that gurus should confirm.
The NIS server will serve up password hashes which are compatible with
traditional crypt() if any are found in an entry's userPassword
attribute. By default, the directory server doesn't create them in this
form (it prefers SSHA, or SSHA256, I guess), but this can be changed by
setting passwordStorageScheme: CRYPT in its cn=config entry.
Two things to watch out for, though.
The first is that when you make the change, the directory server starts
generating userPassword values which begin with {crypt}, but the
default configuration for the NIS server told it to look for values
which began with {CRYPT}, in a case-sensitive manner, so it wouldn't
match them. This was corrected in slapi-nis 0.29. You'll want to
either grab a newer package to pick up the new defaults, or override the
run-time configuration of your copy to match the defaults from later
versions.
The second is that changing your passwordStorageScheme only affects how
the server hashes passwords that will be set after you make the change,
so if you're going to do it, it's better done sooner rather than later.
HTH,
Nalin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly
On 03/12/2012 02:14 PM, Martin Kosek wrote: On Mon, 2012-03-12 at 08:46 -0400, Dmitri Pal wrote: On 03/12/2012 08:15 AM, Petr Spacek wrote: Hello, this patch fixes annoying bug from ticket #55: BIND cannot be shutdown correctly, if psearch is enabled and LDAP connect fails Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 It's trivial three line patch, so Adam ACKed it on IRC. Patch is already in master: https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 I think it's annoying and fix is trivial, so I opened BZ ticket for RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel It seems that code has tabs which violates our coding standards. At least the indentation looks wrong. The whole bind-dyndb-ldap plugin use tabs for indentation, I would keep that unless we want to create mixed tab-space environment. I just see that Petr indented the statement with 2 tabs instead of one. Martin Thanks for review, I missed double-tab. I agree with Martin, whole plugin and BIND actually use tabs for indentation. Double-tab fixed: https://fedorahosted.org/bind-dyndb-ldap/changeset/284ee38e4cb55766317822a6db0ac2a776435fa5 Sorry for my mistake. Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased)
On Mon, 2012-03-12 at 17:12 +0100, Petr Viktorin wrote: On 03/12/2012 04:01 PM, Martin Kosek wrote: On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: On 03/12/2012 01:26 PM, Martin Kosek wrote: On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). Right, sorry for the noise. Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin The attached version is rebased against my patch 20. Ah, I found an issue with the changed RDN attribute. We crash when I delete sudocmd that sudorule has enrolled as a member: # ipa sudocmd-add bar1 # ipa sudocmd-add bar2 # ipa sudorule-add foo # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 # ipa sudocmd-del bar2 # ipa sudorule-find ipa: ERROR: an internal error has occurred /var/log/httpd/error_log: [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 315, in wsgi_execute [Mon Mar 12 10:41:24 2012] [error] result = self.Command[name](*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 438, in __call__ [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 696, in run [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 1866, in execute [Mon Mar 12 10:41:24 2012] [error] self.obj.convert_attribute_members(e[1], *args, **options) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 518, in convert_attribute_members [Mon Mar 12 10:41:24 2012] [error] ldap_obj.get_primary_key_from_dn(member) [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py, line 490, in get_primary_key_from_dn [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] [Mon Mar 12 10:41:24 2012] [error] File /usr/lib/python2.7/site-packages/ipalib/dn.py, line 1137, in __getitem__ [Mon Mar 12 10:41:24 2012] [error] raise KeyError(\\%s\\ not found in %s % (key, self. __str__())) The problem is in this function: def get_primary_key_from_dn(self, dn): try: if self.rdn_attribute: (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) try: return entry_attrs[self.primary_key.name][0] except (KeyError, IndexError): return '' except errors.NotFound: pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) return dn[self.primary_key.name] Martin Should sudocmd-del should also delete the command from any rules the command is in? I would rather prevent deleting it when it is any sudorule to avoid unpleasant user surprises. That function needs to be fixed either way. But I'm not sure what it should do if the entry doesn't exist. Return the full DN instead? Probably, as this is the only value we know at the moment - it certainly should not crash. Although DN with ipaUniqueID won't be very helpful. A precaution I suggested above should prevent that. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap
Martin Kosek wrote: On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: These 2 patches changes the DNS API to support the last missing bits in new bind-dyndb-ldap: 1) Both global and per-zone forwarders now support a conditional custom port (with format IP_ADDRESS PORT) 2) Missing global configuration options have been added: * idnsforwardpolicy: Default policy for conditional forwarding * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic updates * idnszonerefresh: Default interval between regular polls of the name server for new DNS zones Before these patches are pushed, I will just have to update the minimal bind-dyndb-ldap version (it has not been built yet) which have a full support for these. Martin New version of bind-dyndb-ldap has been released, attaching a rebased patch with fixed bind-dyndb-ldap version in spec file. I also fixed the forwarder format, it should be $IP port $PORT, not $IP $PORT as it was in a previous version of the patch. I tested this new format with bind-dyndb-ldap it forwards the queries properly. Unfortunately, fixed version of bind have not been released yet, i.e. bind will crash if forwarders are defined both in named.conf and LDAP global configuration (dnsconfig-mod). Martin The patch itself looks ok, just a couple of general concerns: 1. By default dnsconfig-show displays nothing. This is a little disconcerting. I don't believe we show empty attributes anywhere else, not sure if we should make an exception here or show some other message, perhaps a varying summary? 2. I don't think there is a lot we can do but this still conflicts with the file-based configuration. For example, someone can add a forwarder and caused named to not restart the next time because there is also one defined in named.conf. I'd almost prefer that one win rather than the daemon not start at all. But for our purposes people may get confused because they don't see the forwarders they configured at install time and merely managing this list can break your name server at some undetermined future point. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa
Alexander Bokovoy wrote: On Mon, 12 Mar 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Wed, 07 Mar 2012, Rob Crittenden wrote: Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in enforcing mode. This is being done in the HTTP instance so we can set both booleans in one step and save a bit of time (it is still slow). I would prefer all platform-specific manipulations of security policies to be moved to platform-specific module. Make a HTTP class there (like I did dirsrv class in systemd backend) and perform manipulations on service enable. This way main code will stay clear of platform-specific code. Sorry for not looking into the issue before. I'd prefer to keep the change simple for now and do the big move post 2.2. ACK on condition you'd file a ticket for the post 2.2 work. :) Filed this https://fedorahosted.org/freeipa/ticket/2519 I found an issue with this patch that I need to address, will submit a replacement. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 230 Refresh resolvers after DNS install
Martin Kosek wrote: The testing instructions are attached to the ticket. --- Server framework calls acutil.res_send() to send DNS queries used for various DNS tests. However, once acutil is imported it does not change its list of configured resolvers even when /etc/resolv.conf is changed. This may lead to unexpected resolution issues. We should at least reload httpd when we change /etc/resolv.conf to point to FreeIPA nameserver to force a new import of acutil and thus workaround this bug until it is resolved in authconfig. https://fedorahosted.org/freeipa/ticket/2481 ACK, pushed to master and ipa-2-2. The explicit test made verifying this easy, thanks. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] More types of replica in FreeIPA
On 03/08/2012 04:54 PM, Dmitri Pal wrote: On 03/06/2012 01:30 PM, Ondrej Hamada wrote: On 03/06/2012 05:47 PM, Dmitri Pal wrote: On 03/06/2012 10:59 AM, Simo Sorce wrote: On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: [...] For a read-only KDC we need to investigate what's the better solution. There are many ways we can handle the issue, one of the simplest is probably to allow the RO KDC to use a special LDAP Extended operation against a full R/W server to get the user keys to sign, authenticating with a special R/O KDC principal. We can also investigate how MS does internal forwarding and do something similar as I suspect that's something samba4-RODC will want to implement too, so we could share some of the development burden there. Simo. I do not think it is a good idea for the remote RO KDC to go back to the main datacenter on every authentication without some sort of caching. This is why I think that some kind of SSSD integration might be due. If RO KDC would just pass the authentication to SSSD in some way and SSSD would do the caching in case the office gets offline. I understand that authhub as is will not work as the client sends time stamp encrypted with password and SSSD needs plain text password as credential. I do not know if there is a way to solve this without actually sending the password in the tunnel. IMO it is more important to make sure that remote office can have uninterrupted operation than to worry about the password being sent inside the encrypted tunnel. It is something that deployment should decide and weight risks against convenience. This is why MS does partial replication, ie allows the RODC to have data about the office users. It's complex and there are many ways to handle it. We need to look at various options and see how they would work against uses cases we want to support. Simo. Then may be Ondrej should start with formulating use cases and requirements based on this discussion. I see three possible use cases here, but only two should be considered when speaking about consumer node: 1) The office that should rely on that replica is quite a big one (hundreds of employees) or many different users are authenticating against its replica or there are located admins, who need to do a lot of write-operations. -- In this case I suppose the best solution is to deploy master replica there. 2) Office that doesn't fulfil the conditions in 1) - not a desperate need for write-operations on ipa-server, but the priority is to allow (some) clients to authenticate and use available services even when the network is down. -- We need a consumer with credentials caching, authentication requests for non-cached users or write operations must be forwarded to master. 3) Office that doesn't fulfil the conditions in 1), but the priority is security, so that the consumer is not allowed to store or cache any confidential data. -- We need a consumer, authentications and write operations must be forwarded to master. If we choose the second use case, both the caching and request forwarding must be implemented. I suppose that there shouldn't be big problem to decide during the installation to turn the caching off by some option like '-no-chaching' so that the consumer could be used for the third use case as well. Can you please now create a set usage scenarios for the 2) and 3). User logs in and he is in cache, he is not in cache, he is redirected and data is cached, he failed and account lockout data is updated locally or on the other server? Admin tries to perform and IPA command or ldapmodify command - what happens? Can those work flows be spelled out in details for caching and non use cases? I'll start with usage scenario for 3), it's shorter: All write operations and authentication requests are forwarded to the master Operations when connection is OK: -- read -- local write-forwarding to master authentication-forwarding to master Operations when connection is BROKEN: - read-local (only until ticket expires) write-not available authentication-not available Usage scenario for 2): USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials USER'S operations when connection is BROKEN: -- read data - local write data - not available authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, on lock-down lock account locally and update
Re: [Freeipa-devel] [PATCH] 974 minimum selinux-policy for F-17
Martin Kosek wrote: On Tue, 2012-03-06 at 16:18 -0500, Rob Crittenden wrote: Rob Crittenden wrote: Update the minimum selinux-policy for F-17. This will enable ipa_memcached to run in Enforcing mode. Still waiting on this to be backported to at least F-16. You have to manually enable the boolean. rob F-16 package is in updates-testing, patch updated. rob ACK. New selinux-policy looks OK. I was able to install IPA server with enforcing. Of course, httpd_manage_ipa need to be ON. Martin pushed to master and ipa-2-2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] More types of replica in FreeIPA
On 03/12/2012 03:38 PM, Ondrej Hamada wrote: On 03/08/2012 04:54 PM, Dmitri Pal wrote: On 03/06/2012 01:30 PM, Ondrej Hamada wrote: On 03/06/2012 05:47 PM, Dmitri Pal wrote: On 03/06/2012 10:59 AM, Simo Sorce wrote: On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: [...] For a read-only KDC we need to investigate what's the better solution. There are many ways we can handle the issue, one of the simplest is probably to allow the RO KDC to use a special LDAP Extended operation against a full R/W server to get the user keys to sign, authenticating with a special R/O KDC principal. We can also investigate how MS does internal forwarding and do something similar as I suspect that's something samba4-RODC will want to implement too, so we could share some of the development burden there. Simo. I do not think it is a good idea for the remote RO KDC to go back to the main datacenter on every authentication without some sort of caching. This is why I think that some kind of SSSD integration might be due. If RO KDC would just pass the authentication to SSSD in some way and SSSD would do the caching in case the office gets offline. I understand that authhub as is will not work as the client sends time stamp encrypted with password and SSSD needs plain text password as credential. I do not know if there is a way to solve this without actually sending the password in the tunnel. IMO it is more important to make sure that remote office can have uninterrupted operation than to worry about the password being sent inside the encrypted tunnel. It is something that deployment should decide and weight risks against convenience. This is why MS does partial replication, ie allows the RODC to have data about the office users. It's complex and there are many ways to handle it. We need to look at various options and see how they would work against uses cases we want to support. Simo. Then may be Ondrej should start with formulating use cases and requirements based on this discussion. I see three possible use cases here, but only two should be considered when speaking about consumer node: 1) The office that should rely on that replica is quite a big one (hundreds of employees) or many different users are authenticating against its replica or there are located admins, who need to do a lot of write-operations. -- In this case I suppose the best solution is to deploy master replica there. 2) Office that doesn't fulfil the conditions in 1) - not a desperate need for write-operations on ipa-server, but the priority is to allow (some) clients to authenticate and use available services even when the network is down. -- We need a consumer with credentials caching, authentication requests for non-cached users or write operations must be forwarded to master. 3) Office that doesn't fulfil the conditions in 1), but the priority is security, so that the consumer is not allowed to store or cache any confidential data. -- We need a consumer, authentications and write operations must be forwarded to master. If we choose the second use case, both the caching and request forwarding must be implemented. I suppose that there shouldn't be big problem to decide during the installation to turn the caching off by some option like '-no-chaching' so that the consumer could be used for the third use case as well. Can you please now create a set usage scenarios for the 2) and 3). User logs in and he is in cache, he is not in cache, he is redirected and data is cached, he failed and account lockout data is updated locally or on the other server? Admin tries to perform and IPA command or ldapmodify command - what happens? Can those work flows be spelled out in details for caching and non use cases? I'll start with usage scenario for 3), it's shorter: All write operations and authentication requests are forwarded to the master Operations when connection is OK: -- read -- local write-forwarding to master authentication-forwarding to master Operations when connection is BROKEN: - read-local (only until ticket expires) write-not available authentication-not available Usage scenario for 2): USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account I am not sure is this is always right. IMO we should make it configurable and allow the admin to decide if in this case the authentication should be performed against central server and then cached credentials rather than always going to the cache first. -credentials not cached -- forward request to master, on success cache
Re: [Freeipa-devel] More types of replica in FreeIPA
On 03/12/2012 01:51 PM, Dmitri Pal wrote: On 03/12/2012 03:38 PM, Ondrej Hamada wrote: On 03/08/2012 04:54 PM, Dmitri Pal wrote: On 03/06/2012 01:30 PM, Ondrej Hamada wrote: On 03/06/2012 05:47 PM, Dmitri Pal wrote: On 03/06/2012 10:59 AM, Simo Sorce wrote: On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: [...] For a read-only KDC we need to investigate what's the better solution. There are many ways we can handle the issue, one of the simplest is probably to allow the RO KDC to use a special LDAP Extended operation against a full R/W server to get the user keys to sign, authenticating with a special R/O KDC principal. We can also investigate how MS does internal forwarding and do something similar as I suspect that's something samba4-RODC will want to implement too, so we could share some of the development burden there. Simo. I do not think it is a good idea for the remote RO KDC to go back to the main datacenter on every authentication without some sort of caching. This is why I think that some kind of SSSD integration might be due. If RO KDC would just pass the authentication to SSSD in some way and SSSD would do the caching in case the office gets offline. I understand that authhub as is will not work as the client sends time stamp encrypted with password and SSSD needs plain text password as credential. I do not know if there is a way to solve this without actually sending the password in the tunnel. IMO it is more important to make sure that remote office can have uninterrupted operation than to worry about the password being sent inside the encrypted tunnel. It is something that deployment should decide and weight risks against convenience. This is why MS does partial replication, ie allows the RODC to have data about the office users. It's complex and there are many ways to handle it. We need to look at various options and see how they would work against uses cases we want to support. Simo. Then may be Ondrej should start with formulating use cases and requirements based on this discussion. I see three possible use cases here, but only two should be considered when speaking about consumer node: 1) The office that should rely on that replica is quite a big one (hundreds of employees) or many different users are authenticating against its replica or there are located admins, who need to do a lot of write-operations. -- In this case I suppose the best solution is to deploy master replica there. 2) Office that doesn't fulfil the conditions in 1) - not a desperate need for write-operations on ipa-server, but the priority is to allow (some) clients to authenticate and use available services even when the network is down. -- We need a consumer with credentials caching, authentication requests for non-cached users or write operations must be forwarded to master. 3) Office that doesn't fulfil the conditions in 1), but the priority is security, so that the consumer is not allowed to store or cache any confidential data. -- We need a consumer, authentications and write operations must be forwarded to master. If we choose the second use case, both the caching and request forwarding must be implemented. I suppose that there shouldn't be big problem to decide during the installation to turn the caching off by some option like '-no-chaching' so that the consumer could be used for the third use case as well. Can you please now create a set usage scenarios for the 2) and 3). User logs in and he is in cache, he is not in cache, he is redirected and data is cached, he failed and account lockout data is updated locally or on the other server? Admin tries to perform and IPA command or ldapmodify command - what happens? Can those work flows be spelled out in details for caching and non use cases? I'll start with usage scenario for 3), it's shorter: All write operations and authentication requests are forwarded to the master Operations when connection is OK: -- read -- local write-forwarding to master authentication-forwarding to master Operations when connection is BROKEN: - read-local (only until ticket expires) write-not available authentication-not available Usage scenario for 2): USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account I am not sure is this is always right. IMO we should make it configurable and allow the admin to decide if in this case the authentication should be performed against central server and then cached credentials rather than always going to the cache first. -credentials not cached -- forward request to master, on success cache the
Re: [Freeipa-devel] More types of replica in FreeIPA
On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials This scheme doesn't work with Kerberos. Either you have a copy of the user's keys locally or you don't, there is nothing you can really cache if you don't. 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] 0021 Add CLI tests
Petr Viktorin wrote: Most of the tests we have check if the server does the right thing with XML-RPC calls. How the commandline is converted to command arguments, including interactive prompting, is untested. This patch adds some tests in this area. To do that I had to break up cli.run into more manageable pieces, and initialize the CLI plugins in test mode. Also I added nose's --nocapture option to the make-test script. With this it's possible to use pdb.set_trace() to drop into a debugger while running the tests. I went ahead and added a test for ticket 2484, fixed in Martin's patch 231 (Ignore case in yes/no prompts). John had done similar work with --nocapture a while back but it is still pending. Perhaps we can merge his changes in with yours, they look largely overlapping. His patch is [PATCH 54/54] ticet 2135 - enhance make-test for debugging rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 235 Fix migration plugin compat check
Martin Kosek wrote: Ticket #2274 implements a check for compat plugin and warns user if it is enabled. However, there are 2 issues connected with the plugin: 1) The check is performed against the remote (migrated) LDAP server and not the local LDAP server, which does not make much sense 2) When the compat plugin is missing in cn=plugins,cn=config, it raises an error and thus breaks the migration This patch fixes both issues. https://fedorahosted.org/freeipa/ticket/2508 ACK, pushed to master and ipa-2-2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install
Martin Kosek wrote: On Mon, 2012-03-12 at 11:17 -0400, Rob Crittenden wrote: Martin Kosek wrote: On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: https://fedorahosted.org/freeipa/ticket/2415 https://fedorahosted.org/freeipa/ticket/1995 Added exception handler to certutil operation of adding CA to the default NSS database. If operation fails, installation is aborted and changes are rolled back. #2415 If obtaining host TGT fails, the installation is aborted and changes are rolled back. #1995 ACK. Pushed to master, ipa-2-2. Martin I wonder if we need to add an escape for --force here. The kinit is just to do things like nsupdate and add the SSH host keys. One might deem those not critical. rob This was a keytab kinit, as original ticket says a failure to get a correct keytab will make it impossible to login anyway as ldap binds from sssd will fail and auth verification will fail. This sounds pretty critical to me... Martin Right, but we're not failing because kinit failed but because the connection we're trying to make using that keytab failed. That can happen for other reasons, like the NSS shutdown bug we addressed. I won't press this, it is probably fine. Time will tell. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] More types of replica in FreeIPA
On 03/12/2012 04:16 PM, Simo Sorce wrote: On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials This scheme doesn't work with Kerberos. Either you have a copy of the user's keys locally or you don't, there is nothing you can really cache if you don't. Simo. Yes this is what we are talking about here - the cache would have to contain user Kerberos key but there should be some expiration on the cache so that fetched and stored keys periodically cleaned following the policy an admin has defined. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa
Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Mon, 12 Mar 2012, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Wed, 07 Mar 2012, Rob Crittenden wrote:
Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in
enforcing mode.
This is being done in the HTTP instance so we can set both booleans
in one step and save a bit of time (it is still slow).
I would prefer all platform-specific manipulations of security
policies to be moved to platform-specific module.
Make a HTTP class there (like I did dirsrv class in systemd
backend) and perform manipulations on service enable.
This way main code will stay clear of platform-specific code.
Sorry for not looking into the issue before.
I'd prefer to keep the change simple for now and do the big move post
2.2.
ACK on condition you'd file a ticket for the post 2.2 work.
:)
Filed this https://fedorahosted.org/freeipa/ticket/2519
I found an issue with this patch that I need to address, will submit a
replacement.
rob
Handle things better if a boolean doesn't exist.
rob
From 6e2b7a99123f34660de97639dd78e7b9b172dccc Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 7 Mar 2012 09:29:52 -0500
Subject: [PATCH] Set SELinux boolean httpd_manage_ipa so ipa_memcached will
work.
This is being done in the HTTP instance so we can set both
booleans in one step and save a bit of time (it is still slow).
https://fedorahosted.org/freeipa/ticket/2432
---
ipaserver/install/httpinstance.py | 59
1 files changed, 33 insertions(+), 26 deletions(-)
diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py
index a23204b..60d5604 100644
--- a/ipaserver/install/httpinstance.py
+++ b/ipaserver/install/httpinstance.py
@@ -37,10 +37,11 @@ HTTPD_DIR = /etc/httpd
SSL_CONF = HTTPD_DIR + /conf.d/ssl.conf
NSS_CONF = HTTPD_DIR + /conf.d/nss.conf
-selinux_warning = WARNING: could not set selinux boolean httpd_can_network_connect to true.
-The web interface may not function correctly until this boolean is
-successfully change with the command:
- /usr/sbin/setsebool -P httpd_can_network_connect true
+selinux_warning =
+WARNING: could not set selinux boolean(s) %(var)s to true. The web
+interface may not function correctly until this boolean is successfully
+change with the command:
+ /usr/sbin/setsebool -P %(var)s true
Try updating the policycoreutils and selinux-policy packages.
@@ -103,30 +104,35 @@ class HTTPInstance(service.Service):
self.ldap_enable('HTTP', self.fqdn, self.dm_password, self.suffix)
def __selinux_config(self):
-selinux=0
+selinux = False
try:
if (os.path.exists('/usr/sbin/selinuxenabled')):
ipautil.run([/usr/sbin/selinuxenabled])
-selinux=1
+selinux = True
except ipautil.CalledProcessError:
# selinuxenabled returns 1 if not enabled
pass
if selinux:
-try:
-# returns e.g. httpd_can_network_connect -- off
-(stdout, stderr, returncode) = ipautil.run([/usr/sbin/getsebool,
-httpd_can_network_connect])
-self.backup_state(httpd_can_network_connect, stdout.split()[2])
-except:
-pass
-
-# Allow apache to connect to the turbogears web gui
-# This can still fail even if selinux is enabled
-try:
-ipautil.run([/usr/sbin/setsebool, -P, httpd_can_network_connect, true])
-except:
-self.print_msg(selinux_warning)
+# Don't assume all vars are available
+vars = []
+for var in [httpd_can_network_connect, httpd_manage_ipa]:
+try:
+(stdout, stderr, returncode) = ipautil.run([/usr/sbin/getsebool, var])
+self.backup_state(var, stdout.split()[2])
+vars.append(var)
+except:
+pass
+
+# Allow apache to connect to the dogtag UI and the session cache
+# This can still fail even if selinux is enabled. Execute these
+# together so it is speedier.
+if vars:
+bools = [var + =true for var in vars]
+try:
+ipautil.run([/usr/sbin/setsebool, -P, ' '.join(bools)])
+except:
+self.print_msg(selinux_warning % dict(var=','.join(vars)))
def __create_http_keytab(self):
installutils.kadmin_addprinc(self.principal)
@@ -293,12 +299,13 @@ class HTTPInstance(service.Service):
installutils.remove_file(/etc/httpd/conf.d/ipa.conf)
installutils.remove_file(/etc/httpd/conf.d/ipa-pki-proxy.conf)
-sebool_state = self.restore_state(httpd_can_network_connect)
-if not sebool_state is None:
-try:
-
Re: [Freeipa-devel] [PATCH] 984 fix anonlimits dn
Martin Kosek wrote: On Wed, 2012-03-07 at 18:02 -0500, Rob Crittenden wrote: The value of nsslapd-anonlimitsdn wasn't being set properly because it wasn't quoted. This will fix it, replacing whatever is there with a correct value. rob The IPA anonlimits DN is now set correctly. However anonlimits in cn=anonymous-limits,cn=etc,SUFFIX are still empty (nsSizeLimit and nsLookThroughLimit values defined in 10-config.update are not set). Martin These are operational attributes, did you have them in the attribute list of your query? $ ldapsearch -LLL -x -b cn=anonymous-limits,cn=etc,dc=example,dc=com nssizelimit nslookthroughlimit dn: cn=anonymous-limits,cn=etc,dc=example,dc=com nssizelimit: 5000 nslookthroughlimit: 5000 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa
On Mon, 12 Mar 2012, Rob Crittenden wrote: Rob Crittenden wrote: Alexander Bokovoy wrote: On Mon, 12 Mar 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Wed, 07 Mar 2012, Rob Crittenden wrote: Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in enforcing mode. This is being done in the HTTP instance so we can set both booleans in one step and save a bit of time (it is still slow). I would prefer all platform-specific manipulations of security policies to be moved to platform-specific module. Make a HTTP class there (like I did dirsrv class in systemd backend) and perform manipulations on service enable. This way main code will stay clear of platform-specific code. Sorry for not looking into the issue before. I'd prefer to keep the change simple for now and do the big move post 2.2. ACK on condition you'd file a ticket for the post 2.2 work. :) Filed this https://fedorahosted.org/freeipa/ticket/2519 I found an issue with this patch that I need to address, will submit a replacement. rob Handle things better if a boolean doesn't exist. Lucky that setsebool takes multiple booleans at the same time... Maybe it would make sense to merge bools upon recover? Otherwise ACK. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] More types of replica in FreeIPA
On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote: On 03/12/2012 04:16 PM, Simo Sorce wrote: On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials This scheme doesn't work with Kerberos. Either you have a copy of the user's keys locally or you don't, there is nothing you can really cache if you don't. Simo. Yes this is what we are talking about here - the cache would have to contain user Kerberos key but there should be some expiration on the cache so that fetched and stored keys periodically cleaned following the policy an admin has defined. We would need a mechanism to transfer Kerberos keys, but that would not be sufficient, you'd have to give read-only servers also the realm krbtgt in order to be able to do anything with those keys. The way MS solves hits (I think) is by giving a special RODC krbtgt to each RODC, and then replicating all RODC krbtgt's with full domain controllers. Full domain controllers have logic to use RODC's krbtgt keys instead of the normal krbtgt to perform operations when user's krbtgt are presented to a different server. This is a lot of work and changes in the KDC, not something we can implement easily. As a first implementation I would restrict read-only replicas to not do Kerberos at all, only LDAP for all the lookup stuff necessary. to add a RO KDC we will need to plan a lot of changes in the KDC. We will also need intelligent partial replication where the rules about which object (and which attributes in the object) need/can be replicated are established based on some grouping+filter mechanism. This also is a pretty important change to 389ds. 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] More types of replica in FreeIPA
On 03/12/2012 06:10 PM, Simo Sorce wrote: On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote: On 03/12/2012 04:16 PM, Simo Sorce wrote: On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: USER'S operations when connection is OK: --- read data - local write data - forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials This scheme doesn't work with Kerberos. Either you have a copy of the user's keys locally or you don't, there is nothing you can really cache if you don't. Simo. Yes this is what we are talking about here - the cache would have to contain user Kerberos key but there should be some expiration on the cache so that fetched and stored keys periodically cleaned following the policy an admin has defined. We would need a mechanism to transfer Kerberos keys, but that would not be sufficient, you'd have to give read-only servers also the realm krbtgt in order to be able to do anything with those keys. The way MS solves hits (I think) is by giving a special RODC krbtgt to each RODC, and then replicating all RODC krbtgt's with full domain controllers. Full domain controllers have logic to use RODC's krbtgt keys instead of the normal krbtgt to perform operations when user's krbtgt are presented to a different server. This is a lot of work and changes in the KDC, not something we can implement easily. As a first implementation I would restrict read-only replicas to not do Kerberos at all, only LDAP for all the lookup stuff necessary. to add a RO KDC we will need to plan a lot of changes in the KDC. We will also need intelligent partial replication where the rules about which object (and which attributes in the object) need/can be replicated are established based on some grouping+filter mechanism. This also is a pretty important change to 389ds. Simo. I agree. I am just trying to structure the discussion a bit so that all what you are saying can be captured in the design document and then we can pick a subset of what Ondrej will actually implement. So let us capture all the complexity and then do a POC for just LDAP part. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
