[Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
Hi,
Provides a pluggable framework for generating configuration
scriptlets and instructions for various machine setups.
Creates a new ipa-client-advise command, available to root user
on the IPA server.
Also provides an example configuration plugin.
https://fedorahosted.org/freeipa/ticket/3670
Tomas
From 6cb034b8facf98e45ccad54142ff3e0f9ffb08cb Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 14:43:24 +0200
Subject: [PATCH] Provide ipa-client-advise tool
Provides a pluggable framework for generating configuration
scriptlets and instructions for various machine setups.
Creates a new ipa-client-advise command, available to root user
on the IPA server.
Also provides an example configuration plugin.
https://fedorahosted.org/freeipa/ticket/3670
---
freeipa.spec.in | 4 +
install/tools/Makefile.am | 1 +
install/tools/ipa-client-advise | 23 +
install/tools/man/Makefile.am | 1 +
install/tools/man/ipa-client-advise.1 | 72 ++
ipalib/frontend.py| 19
ipalib/plugable.py| 2 +
ipaserver/advise/__init__.py | 22 +
ipaserver/advise/base.py | 132 ++
ipaserver/advise/plugins/__init__.py | 22 +
ipaserver/advise/plugins/fedora_authconfig.py | 39
setup.py | 2 +
12 files changed, 339 insertions(+)
create mode 100755 install/tools/ipa-client-advise
create mode 100644 install/tools/man/ipa-client-advise.1
create mode 100644 ipaserver/advise/__init__.py
create mode 100644 ipaserver/advise/base.py
create mode 100644 ipaserver/advise/plugins/__init__.py
create mode 100644 ipaserver/advise/plugins/fedora_authconfig.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 4a38e8785903faa5f38295534432a8f679671136..4e37f7f2c4a78cfe295c799efda80342efdc7ba4 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -636,6 +636,7 @@ fi
%{_sbindir}/ipactl
%{_sbindir}/ipa-upgradeconfig
%{_sbindir}/ipa-compliance
+%{_sbindir}/ipa-client-advise
%{_libexecdir}/certmonger/dogtag-ipa-retrieve-agent-submit
%{_libexecdir}/ipa-otpd
%{_sysconfdir}/cron.d/ipa-compliance
@@ -652,6 +653,8 @@ fi
%dir %{python_sitelib}/ipaserver
%dir %{python_sitelib}/ipaserver/install
%dir %{python_sitelib}/ipaserver/install/plugins
+%dir %{python_sitelib}/ipaserver/advise
+%dir %{python_sitelib}/ipaserver/advise/plugins
%dir %{python_sitelib}/ipaserver/plugins
%dir %{_libdir}/ipa/certmonger
%attr(755,root,root) %{_libdir}/ipa/certmonger/*
@@ -770,6 +773,7 @@ fi
%{_mandir}/man1/ipa-compliance.1.gz
%{_mandir}/man1/ipa-backup.1.gz
%{_mandir}/man1/ipa-restore.1.gz
+%{_mandir}/man1/ipa-client-advise.1.gz
%files server-selinux
%defattr(-,root,root,-)
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index 7c553116cdfdce69e594f9d9a36e6bebcab5f692..90d5a5382c23893d55b0297a73e5f01ad312f8d4 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -24,6 +24,7 @@ sbin_SCRIPTS = \
ipa-compliance \
ipa-backup \
ipa-restore \
+ ipa-client-advise \
$(NULL)
EXTRA_DIST = \
diff --git a/install/tools/ipa-client-advise b/install/tools/ipa-client-advise
new file mode 100755
index ..6440503243bd124584eca55cf286b101ec861c16
--- /dev/null
+++ b/install/tools/ipa-client-advise
@@ -0,0 +1,23 @@
+#! /usr/bin/python -E
+# Authors: Tomas Babej
+#
+# Copyright (C) 2013 Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see
Re: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range
On 06/13/2013 12:17 PM, Ana Krivokapic wrote:
On 06/12/2013 12:14 PM, Martin Kosek wrote:
On 06/12/2013 11:40 AM, Tomas Babej wrote:
On 06/12/2013 10:23 AM, Alexander Bokovoy wrote:
On Mon, 10 Jun 2013, Ana Krivokapic wrote:
And once here(added by your patch):
+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.'
I'd suggest we have one common place, say validate_range() function as
we have now,
that contains all the checks (more coming in the future for sure).
That would mean that the whole trust-add command will fail in the case
that "ID range
with the same name but different domain SID already exists", since we
now call validate_range()
within execute() method. I checked with Alexander and we agreed that
this is more desired behaviour.
This would also result to reducement of the number of API calls, which
is a nice benefit.
Tomas
This updated patch completely separates validation logic and object
creation logic of the trust_add command. I added two new methods:
* validate_range(), which ensures that the options and environment
related to idrange is valid, and
* validate_options, which takes care of other general validation
One change introduced in this patch is making the
__populate_remote_domain() method of TrustDomainJoins class public, and
calling it from trust_add. This was necessary in order to enable
discovering details of the trusted domain in validation phase.
Looks good overall but I'd suggest to wrap populate_remote_domain()
calls in join_ad_* methods instead of removing them. If remote domain is
not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)),
then call populate_remote_domain() as it was before.
Fixed.
I tested the patch and it works fine.
There's a lot of refactoring done, but the changes preserve equal state. Aside
from
Alexander's comment up here, I have but one nitpick.
There are few constructs of the form:
try:
value = dictionary['keyword']
except KeyError:
value = None
or
if 'keyword' in dictionary:
value = dictionary['keyword']
else:
value = None
Can you please substitute these with "value = dictionary.get(keyword, None)"?
Not everywhere, but there are places where it can improve readability of the
code.
You can even use just "value = dictionary.get(keyword)" as None is the default
return value:
print {}.get("foo")
Fixed.
None
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Updated patch attached.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
ACK
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Tomas Babej wrote: Hi, Provides a pluggable framework for generating configuration scriptlets and instructions for various machine setups. Creates a new ipa-client-advise command, available to root user on the IPA server. Also provides an example configuration plugin. https://fedorahosted.org/freeipa/ticket/3670 In general looks fine. Manual page is copied from ipa-restore and has its content irrelevant to ipa-client-advise. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests
On 06/11/2013 01:15 PM, Tomas Babej wrote:
On 06/11/2013 12:59 PM, Alexander Bokovoy wrote:
On Tue, 11 Jun 2013, Tomas Babej wrote:
On 06/10/2013 01:13 PM, Tomas Babej wrote:
Hi,
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
Tomas
Patch altered to incorporate minor fixes for recent idrange
objectclass changes.
Tomas
From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 13:08:50 +0200
Subject: [PATCH] Remove hardcoded values from idrange plugin tests
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
---
ipalib/plugins/idrange.py | 2 +-
tests/test_xmlrpc/test_range_plugin.py | 90
++
2 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index
abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363
100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -224,7 +224,7 @@ class idrange(LDAPObject):
if not any((options.get('pkey_only', False),
options.get('raw', False))):
range_type = entry_attrs['iparangetype'][0]
-entry_attrs['iparangetype'] =
self.range_types.get(range_type, None)
+entry_attrs['iparangetype'] =
[self.range_types.get(range_type, None)]
# Remove the objectclass
if not keep_objectclass:
Could you please extract this change into an independent patch? I'm
thinking purely from possible backporting perspective.
Otherwise looks good.
Sure. Patches 0070 and 0071 attached.
I'll link 0071 to the ticket for extending ID range types once it's
pushed, for record's sake.
Tomas
Patches needed rebase.
Tomas
From e9fa638312a3c79c7c6fe6a44796509d76be3360 Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Tue, 11 Jun 2013 13:07:06 +0200
Subject: [PATCH 71/71] Return ipaRangeType as a list in idrange commands
To be consistent with the rest of the LDAP commands, return
ipaRangeType as a list of unicode strings.
Regression caused by https://fedorahosted.org/freeipa/ticket/3647
---
ipalib/plugins/idrange.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -224,7 +224,7 @@ class idrange(LDAPObject):
if not any((options.get('pkey_only', False),
options.get('raw', False))):
range_type = entry_attrs['iparangetype'][0]
-entry_attrs['iparangetype'] = self.range_types.get(range_type, None)
+entry_attrs['iparangetype'] = [self.range_types.get(range_type, None)]
# Remove the objectclass
if not keep_objectclass:
--
1.8.1.4
From b312c64d703fa4012ad28df96823f5ba3c506d32 Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Tue, 11 Jun 2013 13:05:18 +0200
Subject: [PATCH 70/71] Remove hardcoded values from idrange plugin tests
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
---
ipatests/test_xmlrpc/test_range_plugin.py | 90 ---
1 file changed, 59 insertions(+), 31 deletions(-)
diff --git a/ipatests/test_xmlrpc/test_range_plugin.py b/ipatests/test_xmlrpc/test_range_plugin.py
index cbb700e99203fb0ed448f62e6cb7fbeb265ec56b..3292d6a946c8f7c14a3bd276cd6af54a6ccc20a4 100644
--- a/ipatests/test_xmlrpc/test_range_plugin.py
+++ b/ipatests/test_xmlrpc/test_range_plugin.py
@@ -29,62 +29,86 @@ from ipapython.dn import *
import ldap, ldap.sasl, ldap.modlist
+id_shift = 0
+rid_shift = 0
+
+for idrange in api.Command['idrange_find']()['result']:
+size = int(idrange['ipaidrangesize'][0])
+base_id = int(idrange['ipabaseid'][0])
+
+id_end = base_id + size
+rid_end = 0
+
+if 'ipabaserid' in idrange:
+base_rid = int(idrange['ipabaserid'][0])
+rid_end = base_rid + size
+
+if 'ipasecondarybaserid' in idrange:
+s
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
Hi, On 19.6.2013 09:48, Tomas Babej wrote: Hi, Provides a pluggable framework for generating configuration scriptlets and instructions for various machine setups. Creates a new ipa-client-advise command, available to root user on the IPA server. Also provides an example configuration plugin. I don't like how you abuse our object model in this patch. For example, why does Configuration inherit from Method? It does not represent method of any object, it doesn't even represent a runnable command. I see you added an artificial advise object, which uses the ldap2 backend, but doesn't actually use LDAP, this is also ugly. Please inherit from Plugin directly and create a new API namespace for advises instead. And don't call the class Configuration, it's misleading (Advise or Advisory is better IMHO). Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 412 Remove entitlement support
On 06/19/2013 10:13 AM, Martin Kosek wrote: Entitlements code was not tested nor supported upstream since version 3.0. Remove the associated code. https://fedorahosted.org/freeipa/ticket/3739 As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and master branches. Martin ACK on Web UI part. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 19.6.2013 09:48, Tomas Babej wrote: Hi, Provides a pluggable framework for generating configuration scriptlets and instructions for various machine setups. Creates a new ipa-client-advise command, available to root user on the IPA server. Also provides an example configuration plugin. https://fedorahosted.org/freeipa/ticket/3670 BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable and I can imagine that it will be extended to generate/produce various recommendations for clients & servers ... -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 01:31 PM, Petr Spacek wrote: On 19.6.2013 09:48, Tomas Babej wrote: Hi, Provides a pluggable framework for generating configuration scriptlets and instructions for various machine setups. Creates a new ipa-client-advise command, available to root user on the IPA server. Also provides an example configuration plugin. https://fedorahosted.org/freeipa/ticket/3670 BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable and I can imagine that it will be extended to generate/produce various recommendations for clients & servers ... I do not see any objections. Indeed the current name may be somewhat misleading given that it is meant to be run on the server. Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests
On Wed, 19 Jun 2013, Tomas Babej wrote:
On 06/11/2013 01:15 PM, Tomas Babej wrote:
On 06/11/2013 12:59 PM, Alexander Bokovoy wrote:
On Tue, 11 Jun 2013, Tomas Babej wrote:
On 06/10/2013 01:13 PM, Tomas Babej wrote:
Hi,
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
Tomas
Patch altered to incorporate minor fixes for recent idrange
objectclass changes.
Tomas
From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 13:08:50 +0200
Subject: [PATCH] Remove hardcoded values from idrange plugin tests
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
---
ipalib/plugins/idrange.py | 2 +-
tests/test_xmlrpc/test_range_plugin.py | 90
++
2 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363
100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -224,7 +224,7 @@ class idrange(LDAPObject):
if not any((options.get('pkey_only', False),
options.get('raw', False))):
range_type = entry_attrs['iparangetype'][0]
-entry_attrs['iparangetype'] =
self.range_types.get(range_type, None)
+entry_attrs['iparangetype'] =
[self.range_types.get(range_type, None)]
# Remove the objectclass
if not keep_objectclass:
Could you please extract this change into an independent patch? I'm
thinking purely from possible backporting perspective.
Otherwise looks good.
Sure. Patches 0070 and 0071 attached.
I'll link 0071 to the ticket for extending ID range types once
it's pushed, for record's sake.
Tomas
Patches needed rebase.
The tests now pass on a machine with existing trusts.
However, I'm getting following errors in dirsrv's error log:
[19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850]
into an unused SID.
[19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file ipa_sidgen.c, line
149]: Cannot add SID to new entry.
[19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950]
into an unused SID.
[19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file ipa_sidgen.c, line
149]: Cannot add SID to new entry.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c,
line 417]: New primary rid range overlaps with
existing primary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c,
line 417]: New secondary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c,
line 417]: New primary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c,
line 417]: New base range overlaps with existing base
range.
I think we still need to improve RID part of calculating the test range..
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 08:02 AM, Tomas Babej wrote: > On 06/19/2013 01:31 PM, Petr Spacek wrote: >> On 19.6.2013 09:48, Tomas Babej wrote: >>> Hi, >>> >>> Provides a pluggable framework for generating configuration >>> scriptlets and instructions for various machine setups. >>> >>> Creates a new ipa-client-advise command, available to root user >>> on the IPA server. >>> >>> Also provides an example configuration plugin. >>> >>> https://fedorahosted.org/freeipa/ticket/3670 >> >> BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable >> and I can imagine that it will be extended to generate/produce >> various recommendations for clients & servers ... >> > > I do not see any objections. > > Indeed the current name may be somewhat misleading given that it is > meant to be run on the server. > > Do you have something particular in mind? > > Tomas > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? -- 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] [PATCH 0072] Provide ipa-client-advise tool
On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests
On 06/19/2013 02:36 PM, Alexander Bokovoy wrote:
On Wed, 19 Jun 2013, Tomas Babej wrote:
On 06/11/2013 01:15 PM, Tomas Babej wrote:
On 06/11/2013 12:59 PM, Alexander Bokovoy wrote:
On Tue, 11 Jun 2013, Tomas Babej wrote:
On 06/10/2013 01:13 PM, Tomas Babej wrote:
Hi,
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
Tomas
Patch altered to incorporate minor fixes for recent idrange
objectclass changes.
Tomas
From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00
2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 13:08:50 +0200
Subject: [PATCH] Remove hardcoded values from idrange plugin tests
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
---
ipalib/plugins/idrange.py | 2 +-
tests/test_xmlrpc/test_range_plugin.py | 90
++
2 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index
abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363
100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -224,7 +224,7 @@ class idrange(LDAPObject):
if not any((options.get('pkey_only', False),
options.get('raw', False))):
range_type = entry_attrs['iparangetype'][0]
-entry_attrs['iparangetype'] =
self.range_types.get(range_type, None)
+entry_attrs['iparangetype'] =
[self.range_types.get(range_type, None)]
# Remove the objectclass
if not keep_objectclass:
Could you please extract this change into an independent patch? I'm
thinking purely from possible backporting perspective.
Otherwise looks good.
Sure. Patches 0070 and 0071 attached.
I'll link 0071 to the ticket for extending ID range types once it's
pushed, for record's sake.
Tomas
Patches needed rebase.
The tests now pass on a machine with existing trusts.
However, I'm getting following errors in dirsrv's error log:
[19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850]
into an unused SID.
[19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950]
into an unused SID.
[19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New primary rid range overlaps with
existing primary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New secondary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New primary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New base range overlaps with existing base
range.
I think we still need to improve RID part of calculating the test range..
Aren't those logs that were produced by negative tests?
Overlaps are handled by DS plugin, and only then the errors are
propagated back to the IPA framework.
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests
On Wed, 19 Jun 2013, Tomas Babej wrote:
On Wed 19 Jun 2013 02:36:16 PM CEST, Alexander Bokovoy wrote:
On Wed, 19 Jun 2013, Tomas Babej wrote:
On 06/11/2013 01:15 PM, Tomas Babej wrote:
On 06/11/2013 12:59 PM, Alexander Bokovoy wrote:
On Tue, 11 Jun 2013, Tomas Babej wrote:
On 06/10/2013 01:13 PM, Tomas Babej wrote:
Hi,
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
Tomas
Patch altered to incorporate minor fixes for recent idrange
objectclass changes.
Tomas
From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00
2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 13:08:50 +0200
Subject: [PATCH] Remove hardcoded values from idrange plugin tests
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
---
ipalib/plugins/idrange.py | 2 +-
tests/test_xmlrpc/test_range_plugin.py | 90
++
2 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index
abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363
100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -224,7 +224,7 @@ class idrange(LDAPObject):
if not any((options.get('pkey_only', False),
options.get('raw', False))):
range_type = entry_attrs['iparangetype'][0]
-entry_attrs['iparangetype'] =
self.range_types.get(range_type, None)
+entry_attrs['iparangetype'] =
[self.range_types.get(range_type, None)]
# Remove the objectclass
if not keep_objectclass:
Could you please extract this change into an independent patch? I'm
thinking purely from possible backporting perspective.
Otherwise looks good.
Sure. Patches 0070 and 0071 attached.
I'll link 0071 to the ticket for extending ID range types once it's
pushed, for record's sake.
Tomas
Patches needed rebase.
The tests now pass on a machine with existing trusts.
However, I'm getting following errors in dirsrv's error log:
[19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850]
into an unused SID.
[19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950]
into an unused SID.
[19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New primary rid range overlaps with
existing primary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New secondary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New primary rid range overlaps with
existing secondary rid range.
[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
ipa_range_check.c, line 417]: New base range overlaps with existing base
range.
I think we still need to improve RID part of calculating the test range..
Aren't those logs that were produced by negative tests?
Overlaps are handled by DS plugin, and only then the errors are
propagated back to the IPA framework.
Uhm. Right.
ACK then.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests
On 06/19/2013 03:12 PM, Alexander Bokovoy wrote:
> On Wed, 19 Jun 2013, Tomas Babej wrote:
>> On Wed 19 Jun 2013 02:36:16 PM CEST, Alexander Bokovoy wrote:
>>> On Wed, 19 Jun 2013, Tomas Babej wrote:
On 06/11/2013 01:15 PM, Tomas Babej wrote:
> On 06/11/2013 12:59 PM, Alexander Bokovoy wrote:
>> On Tue, 11 Jun 2013, Tomas Babej wrote:
>>> On 06/10/2013 01:13 PM, Tomas Babej wrote:
Hi,
Hardcoded values for range parameters such as base RID or range
size could be the reason the tests produced incorrect results,
as the ranges could get in conflict with already existing ranges
on the server.
Patch dynamically chooses ID and RID range space at the end of
all ranges already present on the server.
https://fedorahosted.org/freeipa/ticket/3662
Tomas
>>>
>>> Patch altered to incorporate minor fixes for recent idrange
>>> objectclass changes.
>>>
>>> Tomas
>>
>>> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00
>>> 2001
>>> From: Tomas Babej
>>> Date: Mon, 10 Jun 2013 13:08:50 +0200
>>> Subject: [PATCH] Remove hardcoded values from idrange plugin tests
>>>
>>> Hardcoded values for range parameters such as base RID or range
>>> size could be the reason the tests produced incorrect results,
>>> as the ranges could get in conflict with already existing ranges
>>> on the server.
>>>
>>> Patch dynamically chooses ID and RID range space at the end of
>>> all ranges already present on the server.
>>>
>>> https://fedorahosted.org/freeipa/ticket/3662
>>> ---
>>> ipalib/plugins/idrange.py | 2 +-
>>> tests/test_xmlrpc/test_range_plugin.py | 90
>>> ++
>>> 2 files changed, 60 insertions(+), 32 deletions(-)
>>>
>>> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
>>> index
>>> abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363
>>>
>>> 100644
>>> --- a/ipalib/plugins/idrange.py
>>> +++ b/ipalib/plugins/idrange.py
>>> @@ -224,7 +224,7 @@ class idrange(LDAPObject):
>>>if not any((options.get('pkey_only', False),
>>>options.get('raw', False))):
>>>range_type = entry_attrs['iparangetype'][0]
>>> -entry_attrs['iparangetype'] =
>>> self.range_types.get(range_type, None)
>>> +entry_attrs['iparangetype'] =
>>> [self.range_types.get(range_type, None)]
>>>
>>># Remove the objectclass
>>>if not keep_objectclass:
>> Could you please extract this change into an independent patch? I'm
>> thinking purely from possible backporting perspective.
>>
>> Otherwise looks good.
>
> Sure. Patches 0070 and 0071 attached.
>
> I'll link 0071 to the ticket for extending ID range types once it's
> pushed, for record's sake.
>
> Tomas
>
Patches needed rebase.
>>> The tests now pass on a machine with existing trusts.
>>>
>>> However, I'm getting following errors in dirsrv's error log:
>>>
>>> [19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file
>>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850]
>>> into an unused SID.
>>> [19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file
>>> ipa_sidgen.c, line 149]: Cannot add SID to new entry.
>>> [19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file
>>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950]
>>> into an unused SID.
>>> [19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file
>>> ipa_sidgen.c, line 149]: Cannot add SID to new entry.
>>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
>>> ipa_range_check.c, line 417]: New primary rid range overlaps with
>>> existing primary rid range.
>>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
>>> ipa_range_check.c, line 417]: New secondary rid range overlaps with
>>> existing secondary rid range.
>>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
>>> ipa_range_check.c, line 417]: New primary rid range overlaps with
>>> existing secondary rid range.
>>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file
>>> ipa_range_check.c, line 417]: New base range overlaps with existing base
>>> range.
>>>
>>> I think we still need to improve RID part of calculating the test range..
>>>
>>
>> Aren't those logs that were produced by negative tests?
>>
>> Overlaps are handled by DS plugin, and only then the errors are propagated
>> back to the IPA framework.
> Uhm. Right.
>
> ACK then.
>
Pushed both to master.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. In the work I have in progress right now, I changed the --setup option to --about, so now it is: # ipa-advise --about fedora-authconfig Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Jan Cholasta wrote: >> On 19.6.2013 14:47, Dmitri Pal wrote: >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> ipa-config-advisor ? >>> >> >> IMO we should stick to a verb in the name, so ipa-config-advise. > Then it is better to be simpler, ipa-advise is a nice name. Isn't that too simple? Are you trying to create an all knowing Siri-like advisor for IPA? If I am a user, I would really not know what "ipa-advise" means and what advise could it give to me. # ipa-advise "what pair of socks should I take for today?" ipa-config-advise was better IMHO. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 19.6.2013 16:09, Tomas Babej wrote: On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. In the work I have in progress right now, I changed the --setup option to --about, so now it is: # ipa-advise --about fedora-authconfig Why is the option necessary? Why not make it just "ipa-advise fedora-authconfig"? -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
- Original Message - > On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > > On Wed, 19 Jun 2013, Jan Cholasta wrote: > >> On 19.6.2013 14:47, Dmitri Pal wrote: > >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: > Do you have something particular in mind? > > Tomas > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > >>> > >>> > >>> ipa-config-advisor ? > >>> > >> > >> IMO we should stick to a verb in the name, so ipa-config-advise. > > Then it is better to be simpler, ipa-advise is a nice name. > > Isn't that too simple? Are you trying to create an all knowing Siri-like > advisor for IPA? If I am a user, I would really not know what "ipa-advise" > means and what advise could it give to me. > > # ipa-advise "what pair of socks should I take for today?" > > ipa-config-advise was better IMHO. then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. As for the actual command line options I do wonder as well why you need a --setup or --about option at all. ipa-advise 'topic' is sufficient imo. options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. 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 0072] Provide ipa-client-advise tool
On 06/19/2013 10:46 AM, Simo Sorce wrote: > - Original Message - >> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>> On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: > On 06/19/2013 08:02 AM, Tomas Babej wrote: >> Do you have something particular in mind? >> >> Tomas >> >> ___ >> Freeipa-devel mailing list >> Freeipa-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ipa-config-advisor ? > IMO we should stick to a verb in the name, so ipa-config-advise. >>> Then it is better to be simpler, ipa-advise is a nice name. >> Isn't that too simple? Are you trying to create an all knowing Siri-like >> advisor for IPA? If I am a user, I would really not know what "ipa-advise" >> means and what advise could it give to me. >> >> # ipa-advise "what pair of socks should I take for today?" >> >> ipa-config-advise was better IMHO. > then as soon as you need to 'advise' on something that is not config related > it becomes akward, also ipa-config-advise is much longer to type and 'config' > doesn't really add much. > > As for the user 'man ipa-advise' will neatly explain what it will advise > about, I think that is sufficient. > Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff > anyway. > > As for the actual command line options I do wonder as well why you need a > --setup or --about option at all. > > ipa-advise 'topic' is sufficient imo. > > options that may make sense are things like --verbose so that you can have a > small excerpt with the short form and a much longer text with --verbose if > necessary. Although maybe we should just reference man pages for longer text > and not try to create a new manpage substitute, we certainly should always > provide all the content in man pages first. > > Simo. > So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 -- 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] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 06:13 PM, Dmitri Pal wrote: On 06/19/2013 10:46 AM, Simo Sorce wrote: - Original Message - On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. Isn't that too simple? Are you trying to create an all knowing Siri-like advisor for IPA? If I am a user, I would really not know what "ipa-advise" means and what advise could it give to me. # ipa-advise "what pair of socks should I take for today?" ipa-config-advise was better IMHO. then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. As for the actual command line options I do wonder as well why you need a --setup or --about option at all. ipa-advise 'topic' is sufficient imo. options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. Simo. So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 The latter. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 12:18 PM, Tomas Babej wrote: > On 06/19/2013 06:13 PM, Dmitri Pal wrote: >> On 06/19/2013 10:46 AM, Simo Sorce wrote: >>> - Original Message - On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Jan Cholasta wrote: >> On 19.6.2013 14:47, Dmitri Pal wrote: >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel >>> ipa-config-advisor ? >>> >> IMO we should stick to a verb in the name, so ipa-config-advise. > Then it is better to be simpler, ipa-advise is a nice name. Isn't that too simple? Are you trying to create an all knowing Siri-like advisor for IPA? If I am a user, I would really not know what "ipa-advise" means and what advise could it give to me. # ipa-advise "what pair of socks should I take for today?" ipa-config-advise was better IMHO. >>> then as soon as you need to 'advise' on something that is not config >>> related it becomes akward, also ipa-config-advise is much longer to >>> type and 'config' doesn't really add much. >>> >>> As for the user 'man ipa-advise' will neatly explain what it will >>> advise about, I think that is sufficient. >>> Nobody will expect 'ipa'-advise to provide info about non-ipa >>> related stuff anyway. >>> >>> As for the actual command line options I do wonder as well why you >>> need a --setup or --about option at all. >>> >>> ipa-advise 'topic' is sufficient imo. >>> >>> options that may make sense are things like --verbose so that you >>> can have a small excerpt with the short form and a much longer text >>> with --verbose if necessary. Although maybe we should just reference >>> man pages for longer text and not try to create a new manpage >>> substitute, we certainly should always provide all the content in >>> man pages first. >>> >>> Simo. >>> >> So if I want an advise about Solaris 11 client configuration would it >> look like this? >> >> ipa-advise config --client --distro=solaris --version=11 >> >> or >> >> ipa-advise client-config-solrais-11 >> >> > > The latter. > > Tomas My point is that if the topics would be long and there will be many of them we should have a naming convention for them. -- 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] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 06:19 PM, Dmitri Pal wrote: On 06/19/2013 12:18 PM, Tomas Babej wrote: On 06/19/2013 06:13 PM, Dmitri Pal wrote: On 06/19/2013 10:46 AM, Simo Sorce wrote: - Original Message - On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: On 06/19/2013 08:02 AM, Tomas Babej wrote: Do you have something particular in mind? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. Isn't that too simple? Are you trying to create an all knowing Siri-like advisor for IPA? If I am a user, I would really not know what "ipa-advise" means and what advise could it give to me. # ipa-advise "what pair of socks should I take for today?" ipa-config-advise was better IMHO. then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. As for the actual command line options I do wonder as well why you need a --setup or --about option at all. ipa-advise 'topic' is sufficient imo. options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. Simo. So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 The latter. Tomas My point is that if the topics would be long and there will be many of them we should have a naming convention for them. Sure, but I am not so certain whether we can come up with anything reasonable, that can capture all the use cases and be simple enough at the same time. E.g., somebody might provide a plugin to generate records for DNS zone delegation (using Petr's idea here). Such a plugin does not really fit into client|server-os-version schema. We can probably start naming plugins in a fairly systematic way, and ensure that we will not create mess in the future via review process. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
(please trim conversations) On Wed, 19 Jun 2013, Tomas Babej wrote: So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 The latter. Tomas My point is that if the topics would be long and there will be many of them we should have a naming convention for them. Sure, but I am not so certain whether we can come up with anything reasonable, that can capture all the use cases and be simple enough at the same time. Making plugins to provide their activities named as -- will make it easy to group and use: ipa-advise config-solaris11-padl config-freebsd7-padl config-aix63-native list help setup-ipa-trust2ad setup-ipa-dnsdelegation and so on. ipa-advise list would show all plugins (filtering itself, i.e. list and help plugin) with their short descriptions. E.g., somebody might provide a plugin to generate records for DNS zone delegation (using Petr's idea here). Such a plugin does not really fit into client|server-os-version schema. We can probably start naming plugins in a fairly systematic way, and ensure that we will not create mess in the future via review process. Sure. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 12:29 PM, Tomas Babej wrote: > On 06/19/2013 06:19 PM, Dmitri Pal wrote: >> On 06/19/2013 12:18 PM, Tomas Babej wrote: >>> On 06/19/2013 06:13 PM, Dmitri Pal wrote: On 06/19/2013 10:46 AM, Simo Sorce wrote: > - Original Message - >> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>> On Wed, 19 Jun 2013, Jan Cholasta wrote: On 19.6.2013 14:47, Dmitri Pal wrote: > On 06/19/2013 08:02 AM, Tomas Babej wrote: >> Do you have something particular in mind? >> >> Tomas >> >> ___ >> Freeipa-devel mailing list >> Freeipa-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ipa-config-advisor ? > IMO we should stick to a verb in the name, so ipa-config-advise. >>> Then it is better to be simpler, ipa-advise is a nice name. >> Isn't that too simple? Are you trying to create an all knowing >> Siri-like >> advisor for IPA? If I am a user, I would really not know what >> "ipa-advise" >> means and what advise could it give to me. >> >> # ipa-advise "what pair of socks should I take for today?" >> >> ipa-config-advise was better IMHO. > then as soon as you need to 'advise' on something that is not config > related it becomes akward, also ipa-config-advise is much longer to > type and 'config' doesn't really add much. > > As for the user 'man ipa-advise' will neatly explain what it will > advise about, I think that is sufficient. > Nobody will expect 'ipa'-advise to provide info about non-ipa > related stuff anyway. > > As for the actual command line options I do wonder as well why you > need a --setup or --about option at all. > > ipa-advise 'topic' is sufficient imo. > > options that may make sense are things like --verbose so that you > can have a small excerpt with the short form and a much longer text > with --verbose if necessary. Although maybe we should just reference > man pages for longer text and not try to create a new manpage > substitute, we certainly should always provide all the content in > man pages first. > > Simo. > So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 >>> The latter. >>> >>> Tomas >> My point is that if the topics would be long and there will be many of >> them we should have a naming convention for them. >> > > Sure, but I am not so certain whether we can come up with anything > reasonable, that can capture all the use > cases and be simple enough at the same time. > > E.g., somebody might provide a plugin to generate records for DNS zone > delegation (using Petr's idea here). Such a plugin does not really fit > into client|server-os-version schema. > > We can probably start naming plugins in a fairly systematic way, and > ensure that we will not create mess in the future via review process. > > Tomas No I am talking about naming conventions regarding : spaces, dashes, capitalization, verb use, noun use etc. So that we do not have "client-config-solrais-11" and "ConfiguringHPUX_11.23withKerberos" -- 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] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 12:46 PM, Alexander Bokovoy wrote: > (please trim conversations) > > On Wed, 19 Jun 2013, Tomas Babej wrote: > So if I want an advise about Solaris 11 client configuration would it > look like this? > > ipa-advise config --client --distro=solaris --version=11 > > or > > ipa-advise client-config-solrais-11 > > The latter. Tomas >>> My point is that if the topics would be long and there will be many of >>> them we should have a naming convention for them. >>> >> >> Sure, but I am not so certain whether we can come up with anything >> reasonable, that can capture all the use >> cases and be simple enough at the same time. > Making plugins to provide their activities named as > > -- > > will make it easy to group and use: > >ipa-advise config-solaris11-padl > config-freebsd7-padl > config-aix63-native > list > help > setup-ipa-trust2ad > setup-ipa-dnsdelegation > > and so on. > >ipa-advise list Yes this is exactly what I was talking about. Should be a part of design page in the naming convention section IMO. > > would show all plugins (filtering itself, i.e. list and help plugin) > with their short descriptions. > >> E.g., somebody might provide a plugin to generate records for DNS >> zone delegation (using Petr's idea here). Such a plugin does not >> really fit into client|server-os-version schema. >> >> We can probably start naming plugins in a fairly systematic way, and >> ensure that we will not create mess in the future via review process. > Sure. > > -- 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] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Dmitri Pal wrote: On 06/19/2013 12:46 PM, Alexander Bokovoy wrote: (please trim conversations) On Wed, 19 Jun 2013, Tomas Babej wrote: So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 The latter. Tomas My point is that if the topics would be long and there will be many of them we should have a naming convention for them. Sure, but I am not so certain whether we can come up with anything reasonable, that can capture all the use cases and be simple enough at the same time. Making plugins to provide their activities named as -- will make it easy to group and use: ipa-advise config-solaris11-padl config-freebsd7-padl config-aix63-native list help setup-ipa-trust2ad setup-ipa-dnsdelegation and so on. ipa-advise list Yes this is exactly what I was talking about. Should be a part of design page in the naming convention section IMO. I've added it there: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
[big snip]
Providing new version which should address mentioned issues:
- advice plugins now inherit directly from Plugin, initial approach
via Method class was abandoned
- new Namespace api.Advice collects all the advice plugins
- tool renamed to ipa-advise to express a more general use case
Additional improvements:
- keywords are now generated out of Advice class's name, where
underscores are replaced by hyphens
- rewritten the example plugin in the docs, and provided more
information there
- instead of --setup option to provide configuration, ipa-advise
takes one positional argument
- renamed to ipa-advise
Concerns:
- man page might need more improvements
I'll craft a design page for plugin authors, might be useful, even if
the info is in the package docs.
---
Here's a little preview:
[tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig
Authconfig instructions for configuring Fedora 18/19 client with IPA
server without use of SSSD.
/sbin/authconfig --enableldap --ldapserver=vm-001.idm.com
--enablerfc2307bis --enablekrb5
[tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig4
invalid 'setup': No instructions are available for 'fedora_authconfig4'.
See the list of available configuration advices using the --list option.
[tbabej@vm-001 ~]$ sudo ipa-advise
-
List of available advices
-
fedora-authconfig : Authconfig instructions for configuring Fedora
18/19 client with IPA server without use of SSSD.
Tomas
Tomas
From 52e3afa05b98caa770534969d2ca5e7b9c2fd584 Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 10 Jun 2013 14:43:24 +0200
Subject: [PATCH] Provide ipa-advise tool
Provides a pluggable framework for generating configuration
scriptlets and instructions for various machine setups and use
cases.
Creates a new ipa-advise command, available to root user
on the IPA server.
Also provides an example configuration plugin,
config-fedora-authconfig.
https://fedorahosted.org/freeipa/ticket/3670
---
freeipa.spec.in | 4 +
install/tools/Makefile.am | 1 +
install/tools/ipa-advise | 23 +
install/tools/man/Makefile.am | 1 +
install/tools/man/ipa-advise.1| 45
ipalib/__init__.py| 7 +-
ipalib/frontend.py| 17 +++
ipalib/plugable.py| 2 +
ipaserver/advise/__init__.py | 22
ipaserver/advise/base.py | 142 ++
ipaserver/advise/plugins/__init__.py | 22
ipaserver/advise/plugins/fedora_authconfig.py | 40
make-lint | 2 +-
setup.py | 2 +
14 files changed, 327 insertions(+), 3 deletions(-)
create mode 100755 install/tools/ipa-advise
create mode 100644 install/tools/man/ipa-advise.1
create mode 100644 ipaserver/advise/__init__.py
create mode 100644 ipaserver/advise/base.py
create mode 100644 ipaserver/advise/plugins/__init__.py
create mode 100644 ipaserver/advise/plugins/fedora_authconfig.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 239811ac26aa84e1928cefb9c3adac58326ad9a7..2bd2ca5558d189e7f64f3e575bae53ba64614a5a 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -598,6 +598,7 @@ fi
%{_sbindir}/ipactl
%{_sbindir}/ipa-upgradeconfig
%{_sbindir}/ipa-compliance
+%{_sbindir}/ipa-advise
%{_libexecdir}/certmonger/dogtag-ipa-retrieve-agent-submit
%{_libexecdir}/ipa-otpd
%{_sysconfdir}/cron.d/ipa-compliance
@@ -614,6 +615,8 @@ fi
%dir %{python_sitelib}/ipaserver
%dir %{python_sitelib}/ipaserver/install
%dir %{python_sitelib}/ipaserver/install/plugins
+%dir %{python_sitelib}/ipaserver/advise
+%dir %{python_sitelib}/ipaserver/advise/plugins
%dir %{python_sitelib}/ipaserver/plugins
%dir %{_libdir}/ipa/certmonger
%attr(755,root,root) %{_libdir}/ipa/certmonger/*
@@ -730,6 +733,7 @@ fi
%{_mandir}/man1/ipa-compliance.1.gz
%{_mandir}/man1/ipa-backup.1.gz
%{_mandir}/man1/ipa-restore.1.gz
+%{_mandir}/man1/ipa-advise.1.gz
%files server-trust-ad
%{_sbindir}/ipa-adtrust-install
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index 7c553116cdfdce69e594f9d9a36e6bebcab5f692..13bf1f78ab159b2f57e72a21cc3a9a036826ba27 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -24,6 +24,7 @@ sbin_SCRIPTS = \
ipa-compliance \
ipa-backup \
ipa-restore \
+ ipa-advise \
$(NULL)
EXTRA_DIST = \
diff --git a/install/tools/ipa-advise b/install/tools/ipa-advise
new file mode 100755
index ..28a1ce101a5d6581395ad563479
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
Tomas Babej wrote: [big snip] Providing new version which should address mentioned issues: - advice plugins now inherit directly from Plugin, initial approach via Method class was abandoned - new Namespace api.Advice collects all the advice plugins - tool renamed to ipa-advise to express a more general use case Additional improvements: - keywords are now generated out of Advice class's name, where underscores are replaced by hyphens - rewritten the example plugin in the docs, and provided more information there - instead of --setup option to provide configuration, ipa-advise takes one positional argument - renamed to ipa-advise Concerns: - man page might need more improvements I'll craft a design page for plugin authors, might be useful, even if the info is in the package docs. --- Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig4 invalid 'setup': No instructions are available for 'fedora_authconfig4'. See the list of available configuration advices using the --list option. [tbabej@vm-001 ~]$ sudo ipa-advise - List of available advices - fedora-authconfig : Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. If it's just providing advise why does it need root access? Or is it expected to provide advise based on current configuration? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/19/2013 08:30 PM, Rob Crittenden wrote: Tomas Babej wrote: [big snip] Providing new version which should address mentioned issues: - advice plugins now inherit directly from Plugin, initial approach via Method class was abandoned - new Namespace api.Advice collects all the advice plugins - tool renamed to ipa-advise to express a more general use case Additional improvements: - keywords are now generated out of Advice class's name, where underscores are replaced by hyphens - rewritten the example plugin in the docs, and provided more information there - instead of --setup option to provide configuration, ipa-advise takes one positional argument - renamed to ipa-advise Concerns: - man page might need more improvements I'll craft a design page for plugin authors, might be useful, even if the info is in the package docs. --- Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig4 invalid 'setup': No instructions are available for 'fedora_authconfig4'. See the list of available configuration advices using the --list option. [tbabej@vm-001 ~]$ sudo ipa-advise - List of available advices - fedora-authconfig : Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. If it's just providing advise why does it need root access? Or is it expected to provide advise based on current configuration? rob Original purpose I had in mind was to provide an option for plugin authors to connect via autobind to the LDAP. Now there's also a option of using our api commands, e.g. to read trust-related information out of the tree. However some parts of the tree are not exposed, so if some plugin needs to access information, about replica topology for example, I guess they would need to use this approach. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Rob Crittenden wrote: Tomas Babej wrote: [big snip] Providing new version which should address mentioned issues: - advice plugins now inherit directly from Plugin, initial approach via Method class was abandoned - new Namespace api.Advice collects all the advice plugins - tool renamed to ipa-advise to express a more general use case Additional improvements: - keywords are now generated out of Advice class's name, where underscores are replaced by hyphens - rewritten the example plugin in the docs, and provided more information there - instead of --setup option to provide configuration, ipa-advise takes one positional argument - renamed to ipa-advise Concerns: - man page might need more improvements I'll craft a design page for plugin authors, might be useful, even if the info is in the package docs. --- Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig4 invalid 'setup': No instructions are available for 'fedora_authconfig4'. See the list of available configuration advices using the --list option. [tbabej@vm-001 ~]$ sudo ipa-advise - List of available advices - fedora-authconfig : Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. If it's just providing advise why does it need root access? Or is it expected to provide advise based on current configuration? Exactly. Getting ranges, configured trusts, etc. Not all of that information may be available under non-privileged account, especially if somebody would decide to plug in advices for backup or CA handling/configuration of advanced features. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Tomas Babej wrote: [big snip] Providing new version which should address mentioned issues: - advice plugins now inherit directly from Plugin, initial approach via Method class was abandoned - new Namespace api.Advice collects all the advice plugins - tool renamed to ipa-advise to express a more general use case Additional improvements: - keywords are now generated out of Advice class's name, where underscores are replaced by hyphens - rewritten the example plugin in the docs, and provided more information there - instead of --setup option to provide configuration, ipa-advise takes one positional argument - renamed to ipa-advise Concerns: - man page might need more improvements I'll craft a design page for plugin authors, might be useful, even if the info is in the package docs. --- Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 As the output is almost usable for cut&paste to run on client machines, may be prefix the description/instructions with #? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
[snip] Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 As the output is almost usable for cut&paste to run on client machines, may be prefix the description/instructions with #? Sure, that's a good idea. Then you could simply do [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig > script.sh [tbabej@vm-001 ~]$ scp script.sh vm-002:script.sh [tbabej@vm-002 ~]$ ./script.sh I'll include that change in the next revision Also, adding this to the wiki page for plugin authors as an convention wouldn't hurt. On the second thought, we run the risk of people mindlessly using the generated scripts without even looking at them though. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On Wed, 19 Jun 2013, Tomas Babej wrote: [snip] Here's a little preview: [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 As the output is almost usable for cut&paste to run on client machines, may be prefix the description/instructions with #? Sure, that's a good idea. Then you could simply do [tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig > script.sh [tbabej@vm-001 ~]$ scp script.sh vm-002:script.sh [tbabej@vm-002 ~]$ ./script.sh I'll include that change in the next revision Also, adding this to the wiki page for plugin authors as an convention wouldn't hurt. On the second thought, we run the risk of people mindlessly using the generated scripts without even looking at them though. Yep, that could happend. We can make those statements echoed on execution rather than put as comments: #!/bin/sh cat << "ADVISE_DESCRIPTION" Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. ADVISE_DESCRIPTION -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] IPA to IPA trusts
Hello, I have a stupid idea. We now have ability to make IPA trust AD and AD trust IPA. IPA pretends that it is AD. I wonder how hard it would be to setup the case when there are two IPA servers that both pretending that they are AD talking to each other. This might be a temp solution for IPA to IPA trusts until we do PADs. It might be a temp solution for use cases like this https://fedorahosted.org/freeipa/ticket/3742 I suspect that SSSD would have to be configured as if it is a member of an AD domain trusting another AD domain for this to work :-) -- 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] IPA to IPA trusts
On Thu, 20 Jun 2013, Dmitri Pal wrote: Hello, I have a stupid idea. We now have ability to make IPA trust AD and AD trust IPA. IPA pretends that it is AD. I wonder how hard it would be to setup the case when there are two IPA servers that both pretending that they are AD talking to each other. This is the plan -- we want to reuse all the work for AD trusts to build up IPA to IPA trusts: SIDs, SSSD providers. However, we are not there yet (see below). This might be a temp solution for IPA to IPA trusts until we do PADs. It might be a temp solution for use cases like this https://fedorahosted.org/freeipa/ticket/3742 We need to implement GC service server side. Additionally, we haven't yet implemented fully part of the trust procedure in smbd according to the spec, we rely on AD performing that part for us. Without real AD right now we'd have to know much more about the other side. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
