Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. #3670 [RFE] tool to create configurations for old legacy clients for trusts https://fedorahosted.org/freeipa/ticket/3670 #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3671 #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3672 ipa-advise-client tool would look up existing IPA server configuration and decide how should look sample configuration for the specified case. It will generate a script that will output needed configuration files (or their snippets) or commands that should be executed on the client side. The reason for this indirection is to allow greater flexibility in future, like being able to check PAM configuration at the client side before recommending changes (or run authconfig). -- / Alexander Bokovoy
Re: [Freeipa-devel] [PATCH] 0032 Ignore files generated by build
On 05/30/2013 03:07 PM, Tomas Babej wrote: On 05/30/2013 02:41 PM, Ana Krivokapic wrote: Hello, This patch adds some additional files to .gitignore. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas Pushed to master: 64738ba94ed83397a66d577482039778b261536d -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On 05/30/2013 04:35 PM, Tomas Babej wrote: On 05/29/2013 12:25 PM, Martin Kosek wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Tomas Babej wrote: On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Mon, 27 May 2013, Tomas Babej wrote: We got rid of openldap utilities now. While using python.ldap module, I also made the tests much more robust and added a new test case. In general patches look fine, there is one small nitpick. I'll run tests on Monday and then will provide final ACK. --- a/tests/test_xmlrpc/test_range_plugin.py +++ b/tests/test_xmlrpc/test_range_plugin.py @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. from ipalib import api, errors, _ +from ipapython.ipautil import run This import is unused, can be removed. Fixed, thanks for catching that. Updated patch attached. So I tried to run this test on a machine where there is already trust established and I think there should be done some changes. I perused the log. Seems that the failures you're experiencing are not relevant to the patch itself, since the newly added tests passed. This is problem with test_range_plugin.py tests that has been there for quite a while, the parameters of the ranges such as size, and base ID/RID/secondary RID are hardcoded in the test case. Yep. Probably it would be wise to add pre-start procedure to pull existing ranges and define constants for the ranges so that they don't overlap with existing ones. Perhaps selecting something from a top of the range space... Attached is the log I agree. This has not been relevant until now, since we did not do much testing on IPA instances with trusts set up, and even then there's random factor in having the overlap with the already created trust range. I'd propose fixing this in a separate effort as a part of continouous integration improvements. I see it as a separate issue of its own. What do you think? Please file a separate ticket then. ACK for this one. May-be-NACK. Would it make sense to replace the error with DependentEntry error? We use in cases like this elsewhere and I think it makes more sense in this case too. Martin Sure, I changed the error class in idrange.py and tests accordingly. I ran the unit tests again to verify the changes. Here is the updated patch. Tomas ACK. Pushed to master, ipa-3-2. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 80c5f958a326679c67fac16b13bcfdbd0532d17d Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Fri, 31 May 2013 12:01:23 +0200
Subject: [PATCH] Fail when adding a trust with a different range
When adding a trust, if an id range already exists for this trust,
and options --base-id/--range-size are provided with the trust-add command,
trust-add should fail.
https://fedorahosted.org/freeipa/ticket/3635
---
ipalib/plugins/trust.py | 48
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 3cb0ed98005ae5bd11b39f8ae01c9470d1bfc9c4..cfa4f3fe2ab289f71ba692014d007ccbbc688100 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -155,6 +155,8 @@
autofill=True,
)
+DEFAULT_RANGE_SIZE = 20
+
def trust_type_string(level):
Returns a string representing a type of the trust. The original field is an enum:
@@ -287,7 +289,7 @@ class trust_add(LDAPCreate):
Int('range_size?',
cli_name='range_size',
label=_('Size of the ID range reserved for the trusted domain'),
-default=20,
+default=DEFAULT_RANGE_SIZE,
autofill=True
),
)
@@ -301,14 +303,26 @@ def execute(self, *keys, **options):
error=_('pysss_murmur is not available on the server ' \
'and no base-id is given.'))
-if 'trust_type' in options:
-if options['trust_type'] == u'ad':
-result = self.execute_ad(*keys, **options)
-else:
-raise errors.ValidationError(name=_('trust type'), error=_('only ad is supported'))
-else:
+if 'trust_type' not in options:
raise errors.RequirementError(name=_('trust type'))
+if options['trust_type'] != u'ad':
+raise errors.ValidationError(
+name=_('trust type'),
+error=_('only ad is supported')
+)
+
+if not self.validate_range(*keys, **options):
+raise errors.ValidationError(
+name=_('id range'),
+error=_(
+'An id range already exists for this trust. '
+'You should either delete the old range, or '
+'exclude --base-id/--range-size options from the command.'
+)
+)
+
+result = self.execute_ad(*keys, **options)
self.add_range(*keys, **options)
trust_filter = cn=%s % result['value']
@@ -325,6 +339,24 @@ def execute(self, *keys, **options):
return result
+def validate_range(self, *keys, **options):
+
+If a range for this trusted domain already exists,
+'--base-id' or '--range-size' options should not be specified.
+
+range_name = keys[-1].upper()+'_id_range'
+
+range_exists = True
+try:
+api.Command['idrange_show'](range_name)
+except errors.NotFound:
+range_exists = False
+
+base_id = options.get('base_id')
+range_size = options.get('range_size') != DEFAULT_RANGE_SIZE
+
+return not(range_exists and (base_id or range_size))
+
def add_range(self, *keys, **options):
new_obj = api.Command['trust_show'](keys[-1])
dom_sid = new_obj['result']['ipanttrusteddomainsid'][0];
@@ -350,7 +382,7 @@ def add_range(self, *keys, **options):
if 'base_id' in options:
base_id = options['base_id']
else:
-base_id = 20 + (pysss_murmur.murmurhash3(dom_sid, len(dom_sid), 0xdeadbeef) % 1) * 20
+base_id = DEFAULT_RANGE_SIZE + (pysss_murmur.murmurhash3(dom_sid, len(dom_sid), 0xdeadbeef) % 1) * DEFAULT_RANGE_SIZE
# Add new ID range
api.Command['idrange_add'](range_name,
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa
On 05/30/2013 02:17 PM, Ana Krivokapic wrote:
On 05/13/2013 05:42 PM, Tomas Babej wrote:
On 05/10/2013 04:39 PM, Tomas Babej wrote:
Hi,
this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602
See commit messages for details.
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
I noticed during further development that logic in
interactive_prompt_callback did not follow the pre_callback logic
precisely.
Fixed patches attached.
Tomas
Hi,
Patches work fine.
I would suggest incorporating a fix for ticket
https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The
issue from ticket #3634 is closely connected to this one, and with the
introduction of prompt_param() functionality, including a fix for it
would require minimal effort. You can look at my patch
(https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html)
and if you think the approach is right, adjust accordingly and
incorporate it in your patchset.
Other (minor) comments:
* The last change in ipalib/plugins/idrange.py seems like you wanted
to fix the fact that the lines weren't properly indented (they weren't
multiples of 4). However, you also need to fix the previous line
(raise ...).
* There are a lot of unused imports in ipalib/frontend.py. Since you
are already touching imports in your patch, could you clean up the
unused imports as well.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
I addressed the minor issues. Updated patches are attached.
Regarding your patch, I agree. I sent a reply to its thread.
Tomas
From cfe01bb1984ac838237c1a3d63e492b8e0628d94 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 9 May 2013 14:47:29 +0200
Subject: [PATCH 55/55] Incorporate interactive prompts in idrange-add
In idrange-add command, ensure that RID base is prompted for
in the interactive mode if domain SID or domain name was
specified.
If domain name nor SID was specified, make sure rid base is
prompted for if secondary rid base was specified and vice versa.
https://fedorahosted.org/freeipa/ticket/3602
---
ipalib/plugins/idrange.py | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index d548794428fbbc7981112d6c441c980fd9e06157..2a5415d077151d8b76ba869460915a5fcae8b89a 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -361,6 +361,41 @@ class idrange_add(LDAPCreate):
msg_summary = _('Added ID range %(value)s')
+def interactive_prompt_callback(self, kw):
+
+Ensure that rid-base is prompted for when dom-sid is specified.
+
+Also ensure that secondary-rid-base is prompted for when rid-base is
+specified and vice versa, in case that dom-sid was not specified.
+
+
+# dom-sid can be specified using dom-sid or dom-name options
+
+# it can be also set using --setattr or --addattr, in these cases
+# we will not prompt, but raise an ValidationError later
+
+dom_sid_set = any(dom_id in kw for dom_id in
+ ('ipanttrusteddomainname', 'ipanttrusteddomainsid'))
+
+rid_base_set = 'ipabaserid' in kw
+secondary_rid_base_set = 'ipasecondarybaserid' in kw
+
+# Prompt for RID base if domain SID / name was given
+if dom_sid_set and not rid_base_set:
+value = self.prompt_param(self.params['ipabaserid'])
+kw.update(dict(ipabaserid=value))
+
+if not dom_sid_set:
+# Prompt for secondary RID base if RID base was given
+if rid_base_set and not secondary_rid_base_set:
+value = self.prompt_param(self.params['ipasecondarybaserid'])
+kw.update(dict(ipasecondarybaserid=value))
+
+# Symetrically, prompt for RID base if secondary RID base was given
+if not rid_base_set and secondary_rid_base_set:
+value = self.prompt_param(self.params['ipabaserid'])
+kw.update(dict(ipabaserid=value))
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
assert isinstance(dn, DN)
@@ -414,9 +449,9 @@ class idrange_add(LDAPCreate):
entry_attrs['ipabaserid'],
entry_attrs['ipasecondarybaserid'],
entry_attrs['ipaidrangesize']):
- raise errors.ValidationError(name='ID Range setup',
- error=_(Primary RID range and secondary RID range
-cannot overlap))
+raise errors.ValidationError(name='ID Range setup',
+
Re: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod
On 05/29/2013 03:24 PM, Ana Krivokapic wrote:
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
I edited your patch to use newly introduced prompt_param method as
agreed in my patches 53-55 thread.
The functional part itself looks good, the tests though, are dependent
on the environment. The particular
code branch of tests that is being executed depends on the fact whether
any trust is estabilished on that
particular FreeIPA instance the test suite is being run on.
I suggest you create a mock trust LDAP entry as in my patch 57 that has
been just pushed to master,
and test both cases (whether the interactive prompt behaves correctly
both with the trust estabilished
and without it).
Maybe we should move the setUpClass/tearDownClass logic to tests/util.py
to avoid code duplication.
Attaching the updated patch (apply on top of tbabej-55-3).
Tomas
From f8e4546fac4d785c151a0ce07745741287b63cbc Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Tue, 28 May 2013 16:42:03 +0200
Subject: [PATCH] Require rid-base and secondary-rid-base options in
idrange-add when trust exists
https://fedorahosted.org/freeipa/ticket/3634
---
ipalib/plugins/idrange.py | 34 +++-
tests/test_cmdline/test_cli.py | 50 ++
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index f83ced32888bc984d02fdbd8ab5ff4c512c3ec06..e85df3f69f6496f64cade98dd4448f19dec55b3b 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -342,7 +342,7 @@ class idrange_add(LDAPCreate):
may be given for a new ID range for the local domain while
---rid-bas
+--rid-base
--dom-sid
must be given to add a new range for a trusted AD domain.
@@ -367,6 +367,9 @@ class idrange_add(LDAPCreate):
Also ensure that secondary-rid-base is prompted for when rid-base is
specified and vice versa, in case that dom-sid was not specified.
+
+Interactive mode should prompt for rid-base and secondary-rid-base
+if a trust is established.
# dom-sid can be specified using dom-sid or dom-name options
@@ -396,6 +399,21 @@ class idrange_add(LDAPCreate):
value = self.prompt_param(self.params['ipabaserid'])
kw.update(dict(ipabaserid=value))
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists:
+
+rid_base = kw.get('ipabaserid', None)
+secondary_rid_base = kw.get('ipasecondarybaserid', None)
+
+if rid_base is None:
+value = self.prompt_param(self.params['ipabaserid'])
+kw.update(dict(ipabaserid=value))
+
+if secondary_rid_base is None:
+value = self.prompt_param(self.params['ipasecondarybaserid'])
+kw.update(dict(ipasecondarybaserid=value))
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
assert isinstance(dn, DN)
@@ -453,6 +471,20 @@ class idrange_add(LDAPCreate):
error=_(Primary RID range and secondary RID range
cannot overlap))
+# If a trust is established, base rid and secondary base rid
+# must be specified for local id range
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists and not (
+is_set('ipabaserid') and is_set('ipasecondarybaserid')):
+raise errors.ValidationError(
+name='ID Range setup',
+error=_('You must specify both rid-base and '
+'secondary-rid-base options, because a trust is '
+'established.'
+)
+)
+
entry_attrs['objectclass'].append('ipadomainidrange')
return dn
diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py
index bd1281e1d682b055ede9685a10a9cec91a3c76fd..7137ff4573f7de7699b0ff0b6ec86b305af49e00 100644
--- a/tests/test_cmdline/test_cli.py
+++ b/tests/test_cmdline/test_cli.py
@@ -325,3 +325,53 @@ class TestCLIParsing(object):
force=False,
version=API_VERSION
)
+
+def test_idrange_add(self):
+
+Test idrange-add with interative prompt
+
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists:
+# Pass rid-base and secondary-rid-base interactively
+with self.fake_stdin('5\n50\n'):
+self.check_command(
+'idrange_add range1 --base-id=1 --range-size=1',
+
Re: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod
On 05/31/2013 12:25 PM, Tomas Babej wrote: On 05/29/2013 03:24 PM, Ana Krivokapic wrote: Hello, This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3636 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I edited your patch to use newly introduced prompt_param method as agreed in my patches 53-55 thread. The functional part itself looks good, the tests though, are dependent on the environment. The particular code branch of tests that is being executed depends on the fact whether any trust is estabilished on that particular FreeIPA instance the test suite is being run on. I suggest you create a mock trust LDAP entry as in my patch 57 that has been just pushed to master, and test both cases (whether the interactive prompt behaves correctly both with the trust estabilished and without it). Maybe we should move the setUpClass/tearDownClass logic to tests/util.py to avoid code duplication. Attaching the updated patch (apply on top of tbabej-55-3). Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Wrong thread, sorry. This applies to patch 30. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod
On 05/31/2013 12:51 PM, Tomas Babej wrote: On 05/31/2013 12:25 PM, Tomas Babej wrote: On 05/29/2013 03:24 PM, Ana Krivokapic wrote: Hello, This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3636 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I edited your patch to use newly introduced prompt_param method as agreed in my patches 53-55 thread. The functional part itself looks good, the tests though, are dependent on the environment. The particular code branch of tests that is being executed depends on the fact whether any trust is estabilished on that particular FreeIPA instance the test suite is being run on. I suggest you create a mock trust LDAP entry as in my patch 57 that has been just pushed to master, and test both cases (whether the interactive prompt behaves correctly both with the trust estabilished and without it). Maybe we should move the setUpClass/tearDownClass logic to tests/util.py to avoid code duplication. Attaching the updated patch (apply on top of tbabej-55-3). Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Wrong thread, sorry. This applies to patch 30. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I tested the *patch 31*, both with new and old client, works fine. ACK Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0160] Fix crash triggered by missing sasl_user parameter
ACK Works as expected. Regards, Tomas Hozza - Original Message - Hello, Fix crash triggered by missing sasl_user parameter. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod
On 05/31/2013 01:56 PM, Tomas Babej wrote: On 05/31/2013 12:51 PM, Tomas Babej wrote: On 05/31/2013 12:25 PM, Tomas Babej wrote: On 05/29/2013 03:24 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I edited your patch to use newly introduced prompt_param method as agreed in my patches 53-55 thread. The functional part itself looks good, the tests though, are dependent on the environment. The particular code branch of tests that is being executed depends on the fact whether any trust is estabilished on that particular FreeIPA instance the test suite is being run on. I suggest you create a mock trust LDAP entry as in my patch 57 that has been just pushed to master, and test both cases (whether the interactive prompt behaves correctly both with the trust estabilished and without it). Maybe we should move the setUpClass/tearDownClass logic to tests/util.py to avoid code duplication. Attaching the updated patch (apply on top of tbabej-55-3). Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Wrong thread, sorry. This applies to patch 30. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I tested the *patch 31*, both with new and old client, works fine. ACK Tomas Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0161] Validate authentication settings strictly
ACK. Works OK. Regards, Tomas Hozza - Original Message - Hello, Validate authentication settings strictly. - auth_method 'SASL' do not accept bind_dn and password options - auth_method 'simple' do not accept sasl_* and krb5_* options - auth_method 'none' do not accept any of options above -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Simo. #3670 [RFE] tool to create configurations for old legacy clients for trusts https://fedorahosted.org/freeipa/ticket/3670 #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3671 #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3672 ipa-advise-client tool would look up existing IPA server configuration and decide how should
Re: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa
On 05/31/2013 12:25 PM, Tomas Babej wrote: On 05/30/2013 02:17 PM, Ana Krivokapic wrote: On 05/13/2013 05:42 PM, Tomas Babej wrote: On 05/10/2013 04:39 PM, Tomas Babej wrote: Hi, this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 See commit messages for details. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I noticed during further development that logic in interactive_prompt_callback did not follow the pre_callback logic precisely. Fixed patches attached. Tomas Hi, Patches work fine. I would suggest incorporating a fix for ticket https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The issue from ticket #3634 is closely connected to this one, and with the introduction of prompt_param() functionality, including a fix for it would require minimal effort. You can look at my patch (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) and if you think the approach is right, adjust accordingly and incorporate it in your patchset. Other (minor) comments: * The last change in ipalib/plugins/idrange.py seems like you wanted to fix the fact that the lines weren't properly indented (they weren't multiples of 4). However, you also need to fix the previous line (raise ...). * There are a lot of unused imports in ipalib/frontend.py. Since you are already touching imports in your patch, could you clean up the unused imports as well. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I addressed the minor issues. Updated patches are attached. Regarding your patch, I agree. I sent a reply to its thread. Tomas ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the answer depends on specific setup -- if all your users in AD, you'd like to look at them first. -- / Alexander Bokovoy ___ Freeipa-devel mailing list
Re: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search
ACK. Looks good. Regards, Tomas Hozza - Original Message - On 28.5.2013 15:55, Petr Spacek wrote: Hello, Deprecate configuration without persistent search. https://fedorahosted.org/bind-dyndb-ldap/ticket/120 This version of the patch adds notice to the README. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
Simo Sorce wrote: On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the answer depends on specific setup -- if all your users in AD, you'd like to look at them first. If we cache stuff in memory I am not sure it matters much. Note that
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action | -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed | | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In
Re: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa
On 05/31/2013 03:35 PM, Ana Krivokapic wrote: On 05/31/2013 12:25 PM, Tomas Babej wrote: On 05/30/2013 02:17 PM, Ana Krivokapic wrote: On 05/13/2013 05:42 PM, Tomas Babej wrote: On 05/10/2013 04:39 PM, Tomas Babej wrote: Hi, this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 See commit messages for details. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I noticed during further development that logic in interactive_prompt_callback did not follow the pre_callback logic precisely. Fixed patches attached. Tomas Hi, Patches work fine. I would suggest incorporating a fix for ticket https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The issue from ticket #3634 is closely connected to this one, and with the introduction of prompt_param() functionality, including a fix for it would require minimal effort. You can look at my patch (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) and if you think the approach is right, adjust accordingly and incorporate it in your patchset. Other (minor) comments: * The last change in ipalib/plugins/idrange.py seems like you wanted to fix the fact that the lines weren't properly indented (they weren't multiples of 4). However, you also need to fix the previous line (raise ...). * There are a lot of unused imports in ipalib/frontend.py. Since you are already touching imports in your patch, could you clean up the unused imports as well. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I addressed the minor issues. Updated patches are attached. Regarding your patch, I agree. I sent a reply to its thread. Tomas ACK After a second look, you seem to have removed to many imports from ipalib/frontend.py and now the doctests are failing. The import of `Password` from `parameters` should be put back in. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists
On 05/28/2013 04:49 PM, Ana Krivokapic wrote:
Hello,
This patch addresses https://fedorahosted.org/freeipa/ticket/3634
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
This updated patch applies on top of tbabej's patches 0053-0055.
As suggested by Tomás(
(https://www.redhat.com/archives/freeipa-devel/2013-May/msg00352.html), I
refactored support of mock LDAP objects to tests/util, and modified
test_range_plugin and test_cli to use it.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 9b18dcd752940df00e7bce429c9eb572434da1c6 Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Tue, 28 May 2013 16:42:03 +0200
Subject: [PATCH] Require rid-base and secondary-rid-base options in
idrange-add when trust exists
https://fedorahosted.org/freeipa/ticket/3634
---
ipalib/plugins/idrange.py | 34 +-
tests/test_cmdline/test_cli.py | 68 +++
tests/test_xmlrpc/test_range_plugin.py | 85 ++
tests/util.py | 37 ---
4 files changed, 156 insertions(+), 68 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 73628795aaa069b436371be3d9c989e97916f1f6..0cfa7c28516f6920e277d19a993d51339cf85756 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -340,7 +340,7 @@ class idrange_add(LDAPCreate):
may be given for a new ID range for the local domain while
---rid-bas
+--rid-base
--dom-sid
must be given to add a new range for a trusted AD domain.
@@ -365,6 +365,9 @@ def interactive_prompt_callback(self, kw):
Also ensure that secondary-rid-base is prompted for when rid-base is
specified and vice versa, in case that dom-sid was not specified.
+
+Interactive mode should prompt for rid-base and secondary-rid-base
+if a trust is established.
# dom-sid can be specified using dom-sid or dom-name options
@@ -394,6 +397,21 @@ def interactive_prompt_callback(self, kw):
value = self.prompt_param(self.params['ipabaserid'])
kw.update(dict(ipabaserid=value))
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists:
+
+rid_base = kw.get('ipabaserid', None)
+secondary_rid_base = kw.get('ipasecondarybaserid', None)
+
+if rid_base is None:
+value = self.prompt_param(self.params['ipabaserid'])
+kw.update(dict(ipabaserid=value))
+
+if secondary_rid_base is None:
+value = self.prompt_param(self.params['ipasecondarybaserid'])
+kw.update(dict(ipasecondarybaserid=value))
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
assert isinstance(dn, DN)
@@ -451,6 +469,20 @@ def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
error=_(Primary RID range and secondary RID range
cannot overlap))
+# If a trust is established, base rid and secondary base rid
+# must be specified for local id range
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists and not (
+is_set('ipabaserid') and is_set('ipasecondarybaserid')):
+raise errors.ValidationError(
+name='ID Range setup',
+error=_('You must specify both rid-base and '
+'secondary-rid-base options, because a trust is '
+'established.'
+)
+)
+
entry_attrs['objectclass'].append('ipadomainidrange')
return dn
diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py
index bd1281e1d682b055ede9685a10a9cec91a3c76fd..d01d9455b8d851a03fabd824f2b84224e918bdde 100644
--- a/tests/test_cmdline/test_cli.py
+++ b/tests/test_cmdline/test_cli.py
@@ -6,6 +6,7 @@
import nose
from tests import util
+from tests.test_xmlrpc.test_range_plugin import testtrust_dn, testtrust_add
from ipalib import api, errors
from ipapython.version import API_VERSION
@@ -325,3 +326,70 @@ def test_dnszone_add(self):
force=False,
version=API_VERSION
)
+
+def test_idrange_add(self):
+
+Test idrange-add with interative prompt
+
+def test_with_interactive_input():
+with self.fake_stdin('5\n50\n'):
+self.check_command(
+'idrange_add range1 --base-id=1 --range-size=1',
+'idrange_add',
+cn=u'range1',
+ipabaseid=u'1',
+
[Freeipa-devel] IPAv3.1 and Redhat 6.4
Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors surrounding release dates? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPAv3.1 and Redhat 6.4
On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors surrounding release dates? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel 6.4 has SSSD 1.9 and IPA 3.0 There are no plans to port 3.1+ server versions to RHEL6.x. There are considerations to backport SSSD and ipa-client to 6.x. Version is yet TBD but for 6.5 we are focusing on porting selcted fixes for SSSD 1.9 and IPA 3.0. What functionality you are looking for? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio 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] IPAv3.1 and Redhat 6.4
On Fri, May 31, 2013 at 2:13 PM, Dmitri Pal d...@redhat.com wrote: On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors surrounding release dates? ___ Freeipa-devel mailing listFreeipa-devel@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel 6.4 has SSSD 1.9 and IPA 3.0 There are no plans to port 3.1+ server versions to RHEL6.x. There are considerations to backport SSSD and ipa-client to 6.x. Version is yet TBD but for 6.5 we are focusing on porting selcted fixes for SSSD 1.9 and IPA 3.0. With this being the case, will there be an upgrade path to RHEL 7.x and IPA 3.2.x? Since upgrade from RHEL 6.x to 7.x will probably not work, would replication to a higher version work or maybe the backup that Rob was working on? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
