Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/13/2013 07:11 PM, Simo Sorce wrote: On Wed, 2013-02-13 at 10:57 -0700, Rich Megginson wrote: Rich, is there potential from deadlocking here due to the new transaction stuff ? Or can we single out this plugin to run before *any* transaction is started ? If you do this in a regular pre-op, not a betxn pre-op, then it should be fine. Ok in this case we should be able to create a regular pre-op plugin to intercept the ldap add call and then use the following flow: client --(LDAP)-- 389DS --(HTTP/json)-- framework --(LDAP)-- add So no deadlocks will happen, the remaining issue is how to make sure we do not loop by mistake in the second add. One way could be to have loop detection so that if more then two (1. original, 2. framework) adds for the same DN come in we just return errors. Another way is to use a special objectclass as I proposed in the thread and make sure the framework explictly blacklists it so that it can never try to send an add with the special oc even by mistake or user misconfiguration. And a third way is a separate LDAP tree. I'm not familiar with what DS plugins can do. Can we craft one that intercepts all read operations on cn=HR tree,$SUFFIX and does them on cn=users,cn=accounts,$SUFFIX instead (using that tree's permissions), and forwards all write operations on cn=HR tree to IPA via JSON? A fourth way is a proxy/gateway, essentially the same but with a separate server. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0030] Add option to specify SID using domain name to idrange-add/mod
On 02/12/2013 06:58 PM, Petr Vobornik wrote: On 02/04/2013 05:23 PM, Tomas Babej wrote: Hi, When adding/modifying an ID range for a trusted domain, the newly added option --dom-name can be used. This looks up SID of the trusted domain in LDAP and therefore the user is not required to write it down in CLI. If the lookup fails, error message asking the user to specify the SID manually is shown. https://fedorahosted.org/freeipa/ticket/3133 Tomas Just wondering: How bad would it be to not introduce new virtual attribute and just use the ipanttrusteddomainsid. On add and mod (when ipanttrusteddomainsid is set) we would check if ipanttrusteddomainsid is SID. If not, it would be treated as domain name and get_trusted_domain_sid_from_name method will be used to get the SID. I'm asking because I don't really like virtual and standard attributes for the same ldap attribute in a mod command. In WEB UI details page we have to display only one field - ipanttrusteddomainsid. So we are left with options: 1) do not use this feature for mod operations in Web UI 2) enter domain name in ipanttrusteddomainsid field, implement the aforementioned check in Web UI and fill the correct option in RPC request 3) add special action into action list which will open new dialog, user will enter domain name, mod command with ipanttrusteddomainname set will be executed on confirmation 4) some other method I don't really like any of the options. If a SID check is an easy operation, we can go with #2, but I would still rather see this logic in server plugin. Just for the record, after a short discussion with Petr we decided to keep the virtual attribute ipatrustedomainname as it is. The idea of having ipatrusteddomainsid do two different things seems rather confusing, and in the end would be probably less user-friendly. In the WebUI, user should be able to enter SID using either domain name or domain SID. The proposal is that user would be able to either modify domain SID or enter domain name (and therefore modify SID). Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 370-371 ipa-kdb: remove memory leaks
On Tue, Feb 12, 2013 at 04:42:52PM +0100, Martin Kosek wrote: On 02/12/2013 04:26 PM, Simo Sorce wrote: On Tue, 2013-02-12 at 16:14 +0100, Martin Kosek wrote: Explained in the commit description - this may not be super-critical, I just followed info in ldap_search_ext() man page: ... Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions. ... OK. This snippet seem to change the logic. Before the condition was !ipadb_need_retry() and no you change it to ipadb_need_retry() so it looks reversed, was this on purpose ? As noted in commit description, this check was wrong and it was causing the function to _always_ retry at least once because ipadb_need_retry returns true when we need to retry and not 0 - thus no ! is needed. I do not like much 'sneaking' this kind of change in the same patch that fixes memory leaks, so if you want to plit in 2 patches it would be nice, but I am of course ok with the change. I agree with that. Lets do it right as we have not pushed it yet. I moved this change to a separate patch (attached). I didn't found any issues while testing, so ACK. When I run kinit in a endless loop I still see a constant increase in the resident memory size, but it looks like it is not related to the ipadb code. I will investigate further. bye, Sumit Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 370-371 ipa-kdb: remove memory leaks
On 02/14/2013 10:07 AM, Sumit Bose wrote: On Tue, Feb 12, 2013 at 04:42:52PM +0100, Martin Kosek wrote: On 02/12/2013 04:26 PM, Simo Sorce wrote: On Tue, 2013-02-12 at 16:14 +0100, Martin Kosek wrote: Explained in the commit description - this may not be super-critical, I just followed info in ldap_search_ext() man page: ... Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions. ... OK. This snippet seem to change the logic. Before the condition was !ipadb_need_retry() and no you change it to ipadb_need_retry() so it looks reversed, was this on purpose ? As noted in commit description, this check was wrong and it was causing the function to _always_ retry at least once because ipadb_need_retry returns true when we need to retry and not 0 - thus no ! is needed. I do not like much 'sneaking' this kind of change in the same patch that fixes memory leaks, so if you want to plit in 2 patches it would be nice, but I am of course ok with the change. I agree with that. Lets do it right as we have not pushed it yet. I moved this change to a separate patch (attached). I didn't found any issues while testing, so ACK. When I run kinit in a endless loop I still see a constant increase in the resident memory size, but it looks like it is not related to the ipadb code. I will investigate further. bye, Sumit Ok, thanks. Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] ipa-kdb: Free talloc autofree context when module is closed
On 02/12/2013 08:52 AM, Martin Kosek wrote: On 02/11/2013 05:00 PM, Sumit Bose wrote: Hi, this patch should fix https://fedorahosted.org/freeipa/ticket/3410 . See commit message for details. bye, Sumit This fixed the ipa-kdb crashes for me, so ACK. Martin Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] More types of replicas in FreeIPA
On 13.2.2013 20:10, Simo Sorce wrote: On Wed, 2013-02-13 at 19:34 +0100, Ondrej Hamada wrote: Dne 13.2.2013 14:36, Simo Sorce napsal(a): On Tue, 2013-02-12 at 19:30 -0500, Dmitri Pal wrote: It looks like thinks are starting to boil down to building a Kerberos proxy. Is this something that fits within your thesis agenda Ondra? I guess that's for Ondrej to say, if it is too much we can simply start working on the LDAP/replication side with rekeying and what not, and deal with the KDC part at a later time. Simo. Working on the LDAP/repl side fits the thesis agenda better, so I would like to go that way. Rekeying - do you mean some sort of plugin for transporting the krb keys from masters to consumers? Besides securing transport of keys what else should be done in ldap? I've only partial replication in my mind - I mean replication of entries selected by some kind of ldap filters. We would need to re-encrypt keys so that we do not need to hand off to remote KDCs the same master key. This way a compromise in a branch office replica would not compromise the central infrastructure, but only affect the remote branch. Generally, this feature could be nice for plain Kerberos. (I mean some re-keying integration with classical kprop mechanism.) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 90 Run interactive_prompt callbacks after CSV values are split
On 01/09/2013 06:13 PM, Jan Cholasta wrote:
Hi,
this patch fixes https://fedorahosted.org/freeipa/ticket/3334.
Honza
This needs a test; here one I used to check it.
Otherwise it works well, ACK if the test is added.
--
Petr³
From 319a6b5ad7df59cf725160b9cb0ace3afdd2c708 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 14 Feb 2013 04:29:56 -0500
Subject: [PATCH] Add a test for interactive_prompt on DNS record with comma
https://fedorahosted.org/freeipa/ticket/3334
---
tests/test_cmdline/test_cli.py | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py
index 06c6124bb1d3ac57add9e44d1754238063039c6d..4d730d582bf4622347e882158d72fef7b7bd6c06 100644
--- a/tests/test_cmdline/test_cli.py
+++ b/tests/test_cmdline/test_cli.py
@@ -237,3 +237,31 @@ class TestCLIParsing(object):
all=False,
force=False,
version=API_VERSION)
+
+def test_dnsrecord_del_comma(self):
+try:
+self.run_command(
+'dnszone_add', idnsname=u'test-example.com',
+idnssoamname=u'ns.test-example.com', force=True)
+except errors.NotFound:
+raise nose.SkipTest('DNS is not configured')
+try:
+self.run_command(
+'dnsrecord_add',
+dnszoneidnsname=u'test-example.com',
+idnsname=u'test',
+txtrecord=u'A pretty little problem, said Holmes.')
+with self.fake_stdin('no\nyes\n'):
+self.check_command(
+'dnsrecord_del test-example.com test',
+'dnsrecord_del',
+dnszoneidnsname=u'test-example.com',
+idnsname=u'test',
+del_all=False,
+txtrecord=[u'A pretty little problem, said Holmes.'],
+structured=False,
+raw=False,
+all=False,
+version=API_VERSION)
+finally:
+self.run_command('dnszone_del', idnsname=u'test-example.com')
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0107-0114 Fix Confusing ipa tool online help organization
On 02/06/2013 11:00 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 02/01/2013 06:06 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/31/2013 07:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 12/14/2012 01:46 AM, Dmitri Pal wrote: On 12/13/2012 10:21 AM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/3060 Here is a collection of smallish fixes to `ipa help` and `ipa something --help`. This should address most of Nikolai's proposal. Additionally, it's now possible to run `ipa command --help` without a Kerberos ticket. And there are some new tests. I've not included the Often used commands in `ipa help`; I think that is material for a manual/tutorial, not a help command. Selecting a topic from `ipa topics` and then choosing a command from `ipa help TOPIC` is a better way to use the help than the verbose `ipa help commands` or proposed incomplete Often used commands. Since the ticket has a bit of discussion and you indicate that you did not to address everything can you please extract what have been addressed and put it into a design page. I know it is not RFE but it would help to validate the changes by testers. Please put the wiki link into the ticket. http://freeipa.org/page/V3/Help What is the purpose of the no-option outfile? Do you anticipate at some point opening this up as a real option or making it easier to log while using the api directly? On incorrect invocation (`ipa`, `ipa TOPIC`), the help command is called internally with outfile=sys.stderr. That's true, but this is a lot of code to abstract writing to sys.stderr. I'm just trying to understand the reasoning. Do you imagine that some time in the future we'd want to control where the output goes? I don't think that would be useful, I can't imagine why someone would want to log help texts, or use them to script something. Do you have another idea of how this should be done? The help for help is a little confusing: - Purpose: Display help for a command or topic. Usage: ipa [global-options] help [TOPIC] [options] Positional arguments: TOPIC The topic or command name. Options: -h, --help show this help message and exit - Should [TOPIC] be [TOPIC | COMMAND] or something else? I'm trying to discourage `ipa help COMMAND` in favor of `ipa COMMAND --help`, that way you get the proper help for ambiguous words like ping (https://fedorahosted.org/freeipa/ticket/3247) I also wanted to keep the help simple and not explain this unimportant detail here. If you have better wording I can of course change it. Your reasoning is sound. Im ok with gently pushing users in that direction but leaving undocumented the old behavior. Should we create a ticket to eventually return an error in that case? Users will expect `ipa help COMMAND` to get them command help, it's pretty standard in tools with subcommands. If it was a part of the API I'd be all for enforcing proper usage, but I think a help command deserves some slack -- it's not that big a deal if you get topic help for ping instead of command help... Hm. Now I see that I should add a notice to the topic help text, to lead users to the right path. Patch attached. We will want to remove `ipa help COMMAND` from the docs, and note that ipa help favors topics. We can turn https://fedorahosted.org/freeipa/ticket/3247 into a doc ticket. On my fresh F-18 install one of the new unit tests fails: == FAIL: Test that `help user-add` `user-add -h` are equivalent and contain doc -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /home/rcrit/redhat/freeipa/tests/test_cmdline/test_help.py, line 111, in test_command_help assert h_ctx.stdout == help_ctx.stdout AssertionError This is weird, it works for me. Could you send me the two outputs so I can get some idea what's wrong? Can you check you didn't leave out patch 111 (Add command summary…)? Yeah, I missed 110 and 111. Tests are passing now. I still don't understand the purpose of outfile. What do we gain by making this configurable and who or what would ever change it? The mechanism in the patch changes it. For `ipa help`, the output goes to stdout. For `ipa` (invalid invocation), there's an error and the help is written to stderr. So the place where the output ends up needs to be configurable. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 146-164 LDAP code refactoring (Part 4)
On 02/11/2013 02:07 PM, Petr Viktorin wrote:
On 02/01/2013 03:38 PM, Petr Viktorin wrote:
On 02/01/2013 10:24 AM, Jan Cholasta wrote:
On 1.2.2013 09:47, Petr Viktorin wrote:
On 01/31/2013 07:01 PM, Jan Cholasta wrote:
On 31.1.2013 11:00, Petr Viktorin wrote:
On 01/30/2013 10:53 AM, Petr Viktorin wrote:
On 01/29/2013 04:39 PM, Petr Viktorin wrote:
On 01/28/2013 04:09 PM, Petr Viktorin wrote:
On 01/28/2013 09:34 AM, Jan Cholasta wrote:
On 25.1.2013 14:54, Petr Viktorin wrote:
On 01/24/2013 03:06 PM, Petr Viktorin wrote:
On 01/24/2013 10:43 AM, Petr Viktorin wrote:
On 01/22/2013 04:04 PM, Petr Viktorin wrote:
On 01/21/2013 06:38 PM, Petr Viktorin wrote:
On 01/17/2013 06:27 PM, Petr Viktorin wrote:
Hello,
This is the first batch of changes aimed to consolidate our
LDAP
code.
Each should be a self-contained change that doesn't break
anything.
[...]
Since this patchset is becoming unwieldy, I've put it in a
public
repo
that I'll keep updated. The following command will fetch it into
your
pviktori-ldap-refactor branch:
git fetch git://github.com/encukou/freeipa
ldap-refactor:pviktori-ldap-refactor
[...]
I would prefer if you used the semantics of .get() for
.get_single() as
well (i.e. when no default value is provided, None is assumed) in
patch
152. Or is there a reason not to?
I think you should always have to write extra code to supress
exceptions
(“Errors should never pass silently”). In Python, the easiest/shortest
getter you can write will typically raise an exception when the
value is
missing (e.g. `d[k]` for dicts, `getattr(a, b)` for objects).
That is true, but I think consistency is more important here - the name
suggests the method behaves the same way .get() does. If you insist on
keeping the current behavior, would you at least consider renaming the
method (perhaps to just single or single_value)?
(This is just a nitpick, so don't worry too much about it.)
Alright, I renamed get_single to single_value().
I also rebased to current master.
Updating patch 115 to take recent changes in replica-manage into account.
Patches 161 167 needed a rebase.
--
Petr³
From 80cccf74af15207fd6eed5e3e46e81350a3b4201 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 23 Jan 2013 10:05:21 -0500
Subject: [PATCH] replace getEntry with get_entry (or get_entries if scope !=
SCOPE_BASE)
Part of the work for: https://fedorahosted.org/freeipa/ticket/2660
---
install/tools/ipa-csreplica-manage |6 ++--
install/tools/ipa-managed-entries|7 +
install/tools/ipa-replica-manage |8 +++---
ipaserver/install/adtrustinstance.py | 25 +---
ipaserver/install/dsinstance.py |2 +-
ipaserver/install/krbinstance.py |8 --
ipaserver/install/ldapupdate.py |2 +-
ipaserver/install/replication.py | 41 +++---
ipaserver/install/service.py |2 +-
ipaserver/ipaldap.py | 21 -
10 files changed, 56 insertions(+), 66 deletions(-)
diff --git a/install/tools/ipa-csreplica-manage b/install/tools/ipa-csreplica-manage
index 5cab8b8642c4fd9113c6eb4a4aeab1b4b502cfb5..3f10c9003482c6f3903f70fd9eb59b8c469b8f42 100755
--- a/install/tools/ipa-csreplica-manage
+++ b/install/tools/ipa-csreplica-manage
@@ -135,7 +135,7 @@ class CSReplicationManager(replication.ReplicationManager):
try:
cn=%sAgreement1-%s-%s % (master, host, instance_name)
dn = DN(('cn', cn), self.replica_dn())
-self.conn.getEntry(dn, ldap.SCOPE_BASE)
+self.conn.get_entry(dn)
return (cn, dn)
except errors.NotFound:
dn = None
@@ -156,7 +156,7 @@ class CSReplicationManager(replication.ReplicationManager):
def has_ipaca(self):
try:
-entry = self.conn.getEntry(self.suffix, ldap.SCOPE_BASE)
+entry = self.conn.get_entry(self.suffix)
except errors.NotFound:
return False
else:
@@ -216,7 +216,7 @@ def list_replicas(realm, host, replica, dirman_passwd, verbose):
for ent in entries:
try:
cadn = DN(('cn', 'CA'), DN(ent.dn))
-entry = conn.getEntry(cadn, ldap.SCOPE_BASE)
+entry = conn.get_entry(cadn)
peers[ent.single_value('cn')] = ['master', '']
except errors.NotFound:
peers[ent.single_value('cn')] = ['CA not configured', '']
diff --git a/install/tools/ipa-managed-entries b/install/tools/ipa-managed-entries
index 11deb63c32ff59a36276bbee063fb55740088343..b7dbdb9d3ed9930bd3eec35bbc117e061bc26300 100755
--- a/install/tools/ipa-managed-entries
+++ b/install/tools/ipa-managed-entries
@@ -143,11 +143,8 @@ def main():
disabled = True
try:
-entry = conn.getEntry(def_dn,
-ldap.SCOPE_BASE,
-
Re: [Freeipa-devel] [PATCH 0030] Add option to specify SID using domain name to idrange-add/mod
On 02/12/2013 06:00 PM, Alexander Bokovoy wrote:
On Fri, 08 Feb 2013, Tomas Babej wrote:
On 02/08/2013 03:25 PM, Alexander Bokovoy wrote:
On Mon, 04 Feb 2013, Tomas Babej wrote:
Hi,
When adding/modifying an ID range for a trusted domain, the newly
added option --dom-name can be used. This looks up SID of the
trusted domain in LDAP and therefore the user is not required
to write it down in CLI. If the lookup fails, error message
asking the user to specify the SID manually is shown.
https://fedorahosted.org/freeipa/ticket/3133
Tomas
From 72f8802953edaaf5b9f7c34a38601fbccd681c8e Mon Sep 17 00:00:00
2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 4 Feb 2013 08:33:53 -0500
Subject: [PATCH] Add option to specify SID using domain name to
idrange-add/mod
When adding/modifying an ID range for a trusted domain, the newly
added option --dom-name can be used. This looks up SID of the
trusted domain in LDAP and therefore the user is not required
to write it down in CLI. If the lookup fails, error message
asking the user to specify the SID manually is shown.
https://fedorahosted.org/freeipa/ticket/3133
---
ipalib/plugins/idrange.py | 78
+--
ipaserver/dcerpc.py | 10 ++
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index
84e1057ac6b59b8ad99882a54e3288897338c978..77a75e4cabc18ca873be7cadcf870427d5b36ea0
100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -197,6 +197,11 @@ class idrange(LDAPObject):
cli_name='dom_sid',
label=_('Domain SID of the trusted domain'),
),
+ Str('ipanttrusteddomainname?',
+ cli_name='dom_name',
+ flags=('no_search', 'virtual_attribute'),
+ label=_('Name of the trusted domain'),
+ ),
New options is added but API.txt wasn't changed. As result, 'make rpms'
does not work.
Could you please fix the patch and re-send it?
Sorry about that.
Updated patch attached.
I have one small question regarding use of dom_sid/dom_name.
If both dom_sid and dom_name were specified, failing to resolve dom_name
would force command to raise exception.
I'm not sure this is right behavior. Probably we should detect that both
dom_sid and dom_name were specified and bail out earlier so that only
one of them is accepted. That would be clearer to users, wouldn't it
Sure, I definitely agree on that point. I added the check to idrange-add and
idrange-mod. Also, the patch needed a rebase to apply on the current master.
Tomas
From 9064bdff83cb21ad9690b2d8b40a9722ecbb3283 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 4 Feb 2013 08:33:53 -0500
Subject: [PATCH] Add option to specify SID using domain name to
idrange-add/mod
When adding/modifying an ID range for a trusted domain, the newly
added option --dom-name can be used. This looks up SID of the
trusted domain in LDAP and therefore the user is not required
to write it down in CLI. If the lookup fails, error message
asking the user to specify the SID manually is shown.
https://fedorahosted.org/freeipa/ticket/3133
---
API.txt | 6 ++--
ipalib/plugins/idrange.py | 90 +--
ipaserver/dcerpc.py | 10 ++
3 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/API.txt b/API.txt
index d1913022b180cd0922f98931ad6030cb0555a6c0..5219c51be62862c43ebe9396147ff220b33605c7 100644
--- a/API.txt
+++ b/API.txt
@@ -1885,13 +1885,14 @@ command: i18n_messages
args: 0,0,1
output: Output('messages', type 'dict', None)
command: idrange_add
-args: 1,11,3
+args: 1,12,3
arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Int('ipabaseid', attribute=True, cli_name='base_id', multivalue=False, required=True)
option: Int('ipabaserid', attribute=True, cli_name='rid_base', multivalue=False, required=False)
option: Int('ipaidrangesize', attribute=True, cli_name='range_size', multivalue=False, required=True)
+option: Str('ipanttrusteddomainname', attribute=False, cli_name='dom_name', multivalue=False, required=False)
option: Str('ipanttrusteddomainsid', attribute=True, cli_name='dom_sid', multivalue=False, required=False)
option: Str('iparangetype', attribute=True, cli_name='iparangetype', multivalue=False, required=False)
option: Int('ipasecondarybaserid', attribute=True, cli_name='secondary_rid_base', multivalue=False, required=False)
@@ -1929,7 +1930,7 @@ output: ListOfEntries('result', (type 'list', type 'tuple'), Gettext('A list
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('truncated', type 'bool', None)
command: idrange_mod
-args: 1,13,3
+args: 1,14,3
arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True)
option:
Re: [Freeipa-devel] [PATCH] 1085 cert-find command
On 02/07/2013 03:08 PM, Rob Crittenden wrote: Petr Vobornik wrote: On 02/06/2013 12:44 AM, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob Should I create Web UI in scope of this ticket or a new one? I was also thinking if it's time to implement #191 'Web UI: specify fields to search on' [1]. Maybe in Pilsner. [1] https://fedorahosted.org/freeipa/ticket/191 I'm going to open a UI ticket once the API is finalized. I didn't want to give you a moving target to work against. rob I see that the search requires to specify options for attributes to search on. There is no general CRITERIA positional argument as in other find commands or am I mistaken? Is it possible to add the CRITERIA argument? Is the no 'OR' search an obstacle for it? If so we would really need to push the ticket #191 because UI doesn't support search by only specifying specific attributes yet. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE
On 02/12/2013 11:15 PM, Endi Sukma Dewata wrote:
On 2/12/2013 10:56 AM, Petr Vobornik wrote:
We were discussing to NACK this approach.
The implementation should be improved because of the mutually exclusive
nature of NONE option with [MS-PAC, PAD] options.
I think we should add spec definition (to Web UI only, or into server
plugin as well) of mutex options. Something like:
mutex_groups: [[['NONE'],['MS-PAC', 'PAD']], [/*another array of
groups*/]];
basically an array of group arrays where group array would contain
arrays of mutually exclusive option. Is it over-complicated? Would one
array or a pair of groups be enough?
That way we can disable and uncheck(should not happen, but to keep data
consistency) checkboxes of options from other groups when user selects a
value of some group.
If they are mutually exclusive, they probably should be separated using
radio buttons like this:
PAC: ( ) None
(o) Type:
[x] MS-PAC
[ ] PAD
You missed one option: nothing selected. It can be solved by adding '(
) Inherited' radio.
Anyway, this design seems more user friendly for more general audience
than mine so I will implement it. The only problem with it is that one
have to come with new label for each group and empty value - can't be
inferred from metadata.
It might be better to use a composite widget of radio buttons and
checkboxes so we can reuse the code. Probably the definition will look
something like this:
{
name: 'ipakrbauthzdata',
type: 'radio',
Not sure if it should be radio, more like something new.
label: ...,
options: [
{
label: ...,
value: 'NONE'
},
{
label: ...,
type: 'checkboxes',
Do you expect to be there something different than checkboxes, or do you
want it to do it this way for possible future customization.
options: [
{
label: ...,
value: 'MS-PAC'
},
{
label: ...,
value: 'PAD'
}
]
}
]
}
The composite widget will handle setting the appropriate widgets when
the value of the field on load. It will handle enabling/disabling the
checkboxes when the radio button is selected. It will also compute the
final value of the field from selected radio button/checkboxes on save.
Or just dim (no disable) and uncheck. That way there would still be
visual distinction and one don't have to uncheck all the options from
one group when he wants to select options of mutex group.
That is also possible, but it changes the normal behavior of checkboxes,
so probably users would have to play around with it to understand the
grouping. They could also get confused, e.g. is dimmed checkbox disabled?
As a separate issue, we might want to fetch the options from metadata,
when we want to show the values and don't care about creating different
labels.
If we use radio buttons like above, new labels are necessary to describe
the different groups of checkboxes. For all radio buttons checkboxes
in general, if we don't want to use labels we probably could simplify
the definition such that we can specify the string values directly
(without nested object):
{
name: 'ipakrbauthzdata',
type: 'radio',
options: [
'NONE',
{
type: 'checkboxes',
options: ['MS-PAC', 'PAD']
}
]
}
+1 for classic checkboxes or radios. Problem with this example is that,
it is missing label for the checkbox group which can't be inferred from
anything.
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 14.2.2013 03:55, Dmitri Pal wrote: On 02/13/2013 09:48 PM, Nathan Kinder wrote: On 02/13/2013 06:18 PM, Dmitri Pal wrote: On 02/13/2013 02:08 PM, Simo Sorce wrote: On Wed, 2013-02-13 at 13:30 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2013-02-13 at 12:59 -0500, John Dennis wrote: On 02/13/2013 12:53 PM, Simo Sorce wrote: If we can solve the looping and potential deadlocking concerns I think we can avoid the json reply and let the framework do the actual final ldap add. Could you elaborate on your looping and deadlock concerns? I don't see where they would arise if what we're watching is entirely independent of our LDAP tree. I do not understand what you are 'watching' ? Simo. I think he means have a persistent search to watch for new entries and then act upon them. I think a 2 step approach is misguided, so I've written it off from the start. Simo. This all thread smells like rewriting winsync by using internal plugin and IPA framework. Is there any chance we can use existing winsync solution to do what we need but sync from staging instance rather than AD? Then the flow will be: HR system - staging DS instance - dirsync - IPA Couple assumptions: a) We are satisfied with the security of the existing winsync solution and authentication used there. I do not see why it should be different here as it is a very similar use case. b) I expect we can sync from 389 to 389 with minor config changes and effectively no code changes This is not the case. Winsync uses the AD Dirsync control, which 389 does not support. The Winsync code also expects the AD schema on the entries coming in from the Dirsync response. Even if 389 supported the Dirsync control, there would be a fair amount of code changes to deal with whatever schema we would need to expect. c) The users created via winsync now are created in a proper way so IPA accepts then as IPA users This solves the problem of add and delete of the users. I know that winsync already supports group add/delete but we never qualified it in IPA. So may be it is time, at least for this use case. I would really think that this might be a lower cost solution than writing yet another custom plugin. Let us try to reuse what we already have. I think a custom plug-in would be easier (though I do have concerns about the performance impact of the JSON approach). I really think that we rather have an external solution and not the one hot wired into the IPA internals via the proposed plugin. Something like an external proxy or gateway rather than the approach Simo proposed even if it would be more work. This work would be reusable. We already have several use cases for the LDAP proxy. This can be one more. A bit more and there will be enough need to build one anyways. The main value is that it is optional and external and acts as an ecosystem level solution that can be developed and tested on a separate schedule rather than being internal to IPA. In my Fedora 17 I found package python-ldaptor. It seems to offer nice support for writing own event-based LDAP servers. For simple LDAP proxy it could be enough. $ yum install python-ldaptor $ python import ldaptor.protocols.ldap.ldapserver help(ldaptor.protocols.ldap.ldapserver) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Wed, 2013-02-13 at 21:55 -0500, Dmitri Pal wrote: On 02/13/2013 09:48 PM, Nathan Kinder wrote: On 02/13/2013 06:18 PM, Dmitri Pal wrote: On 02/13/2013 02:08 PM, Simo Sorce wrote: On Wed, 2013-02-13 at 13:30 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2013-02-13 at 12:59 -0500, John Dennis wrote: On 02/13/2013 12:53 PM, Simo Sorce wrote: If we can solve the looping and potential deadlocking concerns I think we can avoid the json reply and let the framework do the actual final ldap add. Could you elaborate on your looping and deadlock concerns? I don't see where they would arise if what we're watching is entirely independent of our LDAP tree. I do not understand what you are 'watching' ? Simo. I think he means have a persistent search to watch for new entries and then act upon them. I think a 2 step approach is misguided, so I've written it off from the start. Simo. This all thread smells like rewriting winsync by using internal plugin and IPA framework. Is there any chance we can use existing winsync solution to do what we need but sync from staging instance rather than AD? Then the flow will be: HR system - staging DS instance - dirsync - IPA Couple assumptions: a) We are satisfied with the security of the existing winsync solution and authentication used there. I do not see why it should be different here as it is a very similar use case. b) I expect we can sync from 389 to 389 with minor config changes and effectively no code changes This is not the case. Winsync uses the AD Dirsync control, which 389 does not support. The Winsync code also expects the AD schema on the entries coming in from the Dirsync response. Even if 389 supported the Dirsync control, there would be a fair amount of code changes to deal with whatever schema we would need to expect. c) The users created via winsync now are created in a proper way so IPA accepts then as IPA users This solves the problem of add and delete of the users. I know that winsync already supports group add/delete but we never qualified it in IPA. So may be it is time, at least for this use case. I would really think that this might be a lower cost solution than writing yet another custom plugin. Let us try to reuse what we already have. I think a custom plug-in would be easier (though I do have concerns about the performance impact of the JSON approach). I really think that we rather have an external solution and not the one hot wired into the IPA internals via the proposed plugin. Something like an external proxy or gateway rather than the approach Simo proposed even if it would be more work. This work would be reusable. We already have several use cases for the LDAP proxy. This can be one more. A bit more and there will be enough need to build one anyways. The main value is that it is optional and external and acts as an ecosystem level solution that can be developed and tested on a separate schedule rather than being internal to IPA. Penrose. 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] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 00:34 -0500, John Dennis wrote: On 02/14/2013 12:16 AM, Nathan Kinder wrote: On 02/13/2013 08:30 PM, John Dennis wrote: On 02/13/2013 10:40 PM, Nathan Kinder wrote: With the DS plug-in approach that calls into the IPA framework with a 'mock add' to form the resulting entry at the pre-op stage, we could take care of the initial ADD operation of the user entry. We would still need to have a way to trigger the additional write operations that the IPA framework performs. The proposed DS plug-in could do an internal search operation after the add, then it could perform the additional write operations that are needed. This logic would need to be in the DS plug-in, or we would need another way to get the details from the IPA framework via JSON. The approach begins to get a bit messy. Messy is one word for it :-) Herein lies the problem. user-add is actually a simple case where in this particular version of our code we know the LDAP operations that occur and in what order. But there is nothing in our coding guidelines that guarantees this, it just happens to be true today. Pre and post callbacks are free to do as they please. The logic in our ldap module can change (in fact it's undergoing a rewrite as we speak). We've committed to supporting an extension mechanism (plugins) that ties into the framework operations and who knows what might occur in that code. At the moment it's not used, but hopefully it will be. Then comes the question, where do we draw the line? Do we say only user-add with no additional options is supported because we know what occurs during it's processing and hence we feel safe emulating user-add outside the framework? We all know this is a slippery slope, as soon as you support user-add this way we'll be getting requests to support other commands or other options. And after we make framework changes (which we do frequently) are we going to test these out-of-band operations continue to emulate the ever changing framework? It's a slippery slope that can expose us to problems we don't need. Jenny, do you want to test an entirely different mechanism or do you want to limit it to our defined API? We have a defined API, I really think that's the only thing we should support. Backdoor shortcuts that sidestep our framework should be off the table IMHO, it's just inviting too many problems. This is why I think that the most sane approach is to put something in front of 'ipa user-add'. This is not without it's own set of difficulties, but if we need a basic LDAP interface that can be used to create IPA users, it should end up calling into the same code that 'ipa user-add' uses. This would ensure that any extensions (plugins) for the framework are called. I actually see this as very similar to the LDAP migration case. For migration, we basically take entries in LDIF format, extract the relevant data, then feed it into 'ipa user-add', right? That's more or less what we need to do here for HR systems that provision users, but the user addition needs to be pushed to IPA via an LDAP client instead of IPA pulling from an LDAP server. Yes, this is exactly what I'm saying and we concur. So as I proposed we can call ipa user-add from LDAP from a non-transactional pre-op plugin. We just need to be careful about when we allow that to avoid loops, but besides that problem it seem relatively easy and does not require crazy things like playgrounds or even full LDAP proxies. 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] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 14:26 +0100, Petr Spacek wrote: In my Fedora 17 I found package python-ldaptor. It seems to offer nice support for writing own event-based LDAP servers. For simple LDAP proxy it could be enough. $ yum install python-ldaptor $ python import ldaptor.protocols.ldap.ldapserver help(ldaptor.protocols.ldap.ldapserver) No. LDAP proxies are *not* simple. Ask Endi he's worked on a meta-directory for years. 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] 0119 Switch client to JSON-RPC
On 01/15/2013 12:36 PM, Petr Viktorin wrote:
I meant to hold this patch a while longer to let it mature, but from
what Brian Smith asked on the user list it seems it could help him.
Design: http://freeipa.org/page/V3/JSON-RPC
Ticket: https://fedorahosted.org/freeipa/ticket/3299
See the design page for what the patch does.
As much as I've tried to avoid them, the code includes some workarounds:
It extends xmlrpclib to also support JSON. This is rather intrusive, but
to not do that I'd need to write a parallel stack for JSON, without the
help of a standard library.
The registration of either jsonclient or xmlclient as rpcclient in the
API also needs a bit of magic, since the framework requires the class
name to match the attribute.
To prevent backwards compatibility problems, we need to ensure that all
official JSON clients send the API version, so this patch should be
applied after my patches 0104-0106.
Updating to current master.
--
Petr³
From 87bade151fd8865c29a16d817c841074754a0d26 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 19 Dec 2012 04:25:24 -0500
Subject: [PATCH] Switch client to JSON-RPC
Modify ipalib.rpc to support JSON-RPC in addition to XML-RPC.
This is done by subclassing and extending xmlrpclib, because
our existing code relies on xmlrpclib internals.
The URI to use is given in the new jsonrpc_uri env variable. When
it is not given, it is generated from xmlrpc_uri by replacing
/xml with /json.
The rpc_json_uri env variable existed before, but was unused,
undocumented and not set the install scripts.
This patch removes it in favor of jsonrpc_uri (for consistency
with xmlrpc_uri).
Add the rpc_protocol env variable to control the protocol
IPA uses. rpc_protocol defaults to 'jsonrpc', but may be changed
to 'xmlrpc'.
Make backend.Executioner and tests use the backend specified by
rpc_protocol.
For compatibility with unwrap_xml, decoding JSON now gives tuples
instead of lists.
Design: http://freeipa.org/page/V3/JSON-RPC
Ticket: https://fedorahosted.org/freeipa/ticket/3299
---
ipa-client/man/default.conf.5 |8 +-
ipalib/backend.py |2 +-
ipalib/config.py | 21 ++-
ipalib/constants.py |7 +-
ipalib/frontend.py|4 +-
ipalib/plugins/{xmlclient.py = rpcclient.py} | 24 ++-
ipalib/rpc.py | 271 +
ipaserver/rpcserver.py| 113 +-
tests/test_cmdline/test_cli.py|4 +-
tests/test_ipaserver/test_rpcserver.py|4 +-
tests/test_xmlrpc/test_dns_plugin.py |4 +-
tests/test_xmlrpc/test_trust_plugin.py|4 +-
tests/test_xmlrpc/xmlrpc_test.py |8 +-
13 files changed, 312 insertions(+), 162 deletions(-)
rename ipalib/plugins/{xmlclient.py = rpcclient.py} (58%)
diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5
index a0804e39f946b3202acc32cc6a7ccbdb8f2626e6..edaa16ee15cdf74caa19910854e5abcabbd525de 100644
--- a/ipa-client/man/default.conf.5
+++ b/ipa-client/man/default.conf.5
@@ -179,7 +179,13 @@ Used internally in the IPA source package to verify that the API has not changed
When True provides more information. Specifically this sets the global log level to info.
.TP
.B xmlrpc_uri URI
-Specifies the URI of the XML\-RPC server for a client. This is used by IPA and some external tools as well, such as ipa\-getcert. e.g. https://ipa.example.com/ipa/xml
+Specifies the URI of the XML\-RPC server for a client. This may be used by IPA, and is used by some external tools, such as ipa\-getcert. Example: https://ipa.example.com/ipa/xml
+.TP
+.B jsonrpc_uri URI
+Specifies the URI of the JSON server for a client. This is used by IPA. If not given, it is derived from xmlrpc_uri. Example: https://ipa.example.com/ipa/json
+.TP
+.B rpc_protocol URI
+Specifies the type of RPC calls IPA makes: 'jsonrpc' or 'xmlrpc'. Defaults to 'jsonrpc'.
.TP
The following define the containers for the IPA server. Containers define where in the DIT that objects can be found. The full location is the value of container + basedn.
container_accounts: cn=accounts
diff --git a/ipalib/backend.py b/ipalib/backend.py
index 7be38ecc80faf03e735813fb1e2d0eba5c347800..b94264236795b65905ba425ef15e452e7a66625b 100644
--- a/ipalib/backend.py
+++ b/ipalib/backend.py
@@ -113,7 +113,7 @@ class Executioner(Backend):
if self.env.in_server:
self.Backend.ldap2.connect(ccache=ccache)
else:
-self.Backend.xmlclient.connect(verbose=(self.env.verbose = 2),
+self.Backend.rpcclient.connect(verbose=(self.env.verbose = 2),
fallback=self.env.fallback, delegate=self.env.delegate)
if client_ip is not None:
setattr(context, client_ip, client_ip)
diff --git a/ipalib/config.py b/ipalib/config.py
index
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
John Dennis wrote: On 02/14/2013 12:16 AM, Nathan Kinder wrote: On 02/13/2013 08:30 PM, John Dennis wrote: On 02/13/2013 10:40 PM, Nathan Kinder wrote: With the DS plug-in approach that calls into the IPA framework with a 'mock add' to form the resulting entry at the pre-op stage, we could take care of the initial ADD operation of the user entry. We would still need to have a way to trigger the additional write operations that the IPA framework performs. The proposed DS plug-in could do an internal search operation after the add, then it could perform the additional write operations that are needed. This logic would need to be in the DS plug-in, or we would need another way to get the details from the IPA framework via JSON. The approach begins to get a bit messy. Messy is one word for it :-) Herein lies the problem. user-add is actually a simple case where in this particular version of our code we know the LDAP operations that occur and in what order. But there is nothing in our coding guidelines that guarantees this, it just happens to be true today. Pre and post callbacks are free to do as they please. The logic in our ldap module can change (in fact it's undergoing a rewrite as we speak). We've committed to supporting an extension mechanism (plugins) that ties into the framework operations and who knows what might occur in that code. At the moment it's not used, but hopefully it will be. Then comes the question, where do we draw the line? Do we say only user-add with no additional options is supported because we know what occurs during it's processing and hence we feel safe emulating user-add outside the framework? We all know this is a slippery slope, as soon as you support user-add this way we'll be getting requests to support other commands or other options. And after we make framework changes (which we do frequently) are we going to test these out-of-band operations continue to emulate the ever changing framework? It's a slippery slope that can expose us to problems we don't need. Jenny, do you want to test an entirely different mechanism or do you want to limit it to our defined API? We have a defined API, I really think that's the only thing we should support. Backdoor shortcuts that sidestep our framework should be off the table IMHO, it's just inviting too many problems. This is why I think that the most sane approach is to put something in front of 'ipa user-add'. This is not without it's own set of difficulties, but if we need a basic LDAP interface that can be used to create IPA users, it should end up calling into the same code that 'ipa user-add' uses. This would ensure that any extensions (plugins) for the framework are called. I actually see this as very similar to the LDAP migration case. For migration, we basically take entries in LDIF format, extract the relevant data, then feed it into 'ipa user-add', right? That's more or less what we need to do here for HR systems that provision users, but the user addition needs to be pushed to IPA via an LDAP client instead of IPA pulling from an LDAP server. Yes, this is exactly what I'm saying and we concur. In reality we don't actually pass migrated users to user-add for performance reasons. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 09:05 AM, Simo Sorce wrote: So as I proposed we can call ipa user-add from LDAP from a non-transactional pre-op plugin. We just need to be careful about when we allow that to avoid loops, but besides that problem it seem relatively easy and does not require crazy things like playgrounds or even full LDAP proxies. I think I need a clarification because perhaps I didn't fully understand your proposal. Is the idea with a non-transactional pre-op plugin it invokes user-add and then the pre-op returns *without* having modified ldap? In effect it acts as a trigger? That still implies there has to be a separate tree where the foreign entity writes (and the pre-op plugin watches) because otherwise how could the pre-op plugin distinguish between framework writes and foreign writes? If there is a separate tree where is the looping issue? You still haven't explained this. Also, under the scenario that a foreign entity writes something into LDAP (somewhere) and it triggers us to call user-add via some mechanism then what happens when errors occur? The foreign entity will not know we rejected the operation nor why. Also, don't forget they want to delete users, remove group membership, add group membership, add groups, remove groups etc. Some of these operations are dependent upon logic in our framework. I don't see how some of these operations can be reliably managed by a foreign entity simultaneously performing LDAP operations. -- John Dennis jden...@redhat.com 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] 1085 cert-find command
Petr Vobornik wrote: On 02/07/2013 03:08 PM, Rob Crittenden wrote: Petr Vobornik wrote: On 02/06/2013 12:44 AM, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob Should I create Web UI in scope of this ticket or a new one? I was also thinking if it's time to implement #191 'Web UI: specify fields to search on' [1]. Maybe in Pilsner. [1] https://fedorahosted.org/freeipa/ticket/191 I'm going to open a UI ticket once the API is finalized. I didn't want to give you a moving target to work against. rob I see that the search requires to specify options for attributes to search on. There is no general CRITERIA positional argument as in other find commands or am I mistaken? Is it possible to add the CRITERIA argument? Is the no 'OR' search an obstacle for it? If so we would really need to push the ticket #191 because UI doesn't support search by only specifying specific attributes yet. Your analysis is correct. It may be considered a hack but what if I treat subject as the CRITERIA argument? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 09:29 AM, Rob Crittenden wrote: In reality we don't actually pass migrated users to user-add for performance reasons. What parts of user-add are we bypassing? -- John Dennis jden...@redhat.com 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] [RFC] Creating a new plugin to make it simpler to add users via LDAP
John Dennis wrote: On 02/14/2013 09:29 AM, Rob Crittenden wrote: In reality we don't actually pass migrated users to user-add for performance reasons. What parts of user-add are we bypassing? Everything. It doesn't call into it at all. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 09:33 -0500, John Dennis wrote: On 02/14/2013 09:05 AM, Simo Sorce wrote: So as I proposed we can call ipa user-add from LDAP from a non-transactional pre-op plugin. We just need to be careful about when we allow that to avoid loops, but besides that problem it seem relatively easy and does not require crazy things like playgrounds or even full LDAP proxies. I think I need a clarification because perhaps I didn't fully understand your proposal. Is the idea with a non-transactional pre-op plugin it invokes user-add and then the pre-op returns *without* having modified ldap? In effect it acts as a trigger? Yes. That still implies there has to be a separate tree where the foreign entity writes (and the pre-op plugin watches) No. because otherwise how could the pre-op plugin distinguish between framework writes and foreign writes? The idea I flaunted around is that the pluggin triggers only if a special objectclass is used. The framewrok would never try to create a user with this special objectclass so loops are avoided. If there is a separate tree where is the looping issue? You still haven't explained this. No separate tree, the plugin intercepts the Add operations, and calls the framework. The framework does the real user creation and then returns. At that point the pre-op plugin returns immediately with the error code from the framework discarding the actual add operation. Also, under the scenario that a foreign entity writes something into LDAP (somewhere) and it triggers us to call user-add via some mechanism then what happens when errors occur? We return back an error. The foreign entity will not know we rejected the operation nor why. This is the problem if you use a staged approach, and one of the reasons I do not consider it as viable, and therefore reject any proposal that imply staged writes and separate operations. Also, don't forget they want to delete users, remove group membership, add group membership, add groups, remove groups etc. Some of these operations are dependent upon logic in our framework. Which ones. Only user creation is really special. Deleting a user should not depend on the framework, nor adding group members. Adding a user is a special case, and should be limited to that. I don't see how some of these operations can be reliably managed by a foreign entity simultaneously performing LDAP operations. I do not see what your concerns are. 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] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 09:47 -0500, Rob Crittenden wrote: John Dennis wrote: On 02/14/2013 09:05 AM, Simo Sorce wrote: So as I proposed we can call ipa user-add from LDAP from a non-transactional pre-op plugin. We just need to be careful about when we allow that to avoid loops, but besides that problem it seem relatively easy and does not require crazy things like playgrounds or even full LDAP proxies. I think I need a clarification because perhaps I didn't fully understand your proposal. Is the idea with a non-transactional pre-op plugin it invokes user-add and then the pre-op returns *without* having modified ldap? In effect it acts as a trigger? That still implies there has to be a separate tree where the foreign entity writes (and the pre-op plugin watches) because otherwise how could the pre-op plugin distinguish between framework writes and foreign writes? The proposal is that we write a 389-ds plugin that intercepts LDAP ADD operations. I don't think Simo proposed where in the tree this would be written, or whether we would be able to distinguish between a normal ADD and this special case (loop 1). I did, please see my other emails in the thread. For the purposes of modification you probably want it to write into the current user container. It will need to be able to push MOD requests for names, addresses, etc. Most LDAP apps take a single basedn against which to do things. We can't expect to be able to provide one set for adds and one set for mods. We do not intercept mods, period. The only *real* issue is creating users, because the framework adds a lot of stuff to properly format users, but modifications from LDAP clients is fair game. We cannot consider the framework as the only gatekeeper beyond object creation, if this is not clear we need to discuss. And of course this leads into deletes. We want users gone when they leave the company. Feature creep already. Do we do anything special in the framework for user deletes now ? I am not aware of any special ops, and I would be against making a delete operation a special operation. If there is a separate tree where is the looping issue? You still haven't explained this. The looping is in telling whether the add is from the external HR source or a normal ADD from IPA. If we get it wrong, ever, then it will ADD, then call ipa user-add, ADD, call ipa user-add, ADD, ... Yes, this is the only concern, I made one proposal to avoid the issue, there are also other ways, for example the framework could use a special control to tell our server 'I am the framework, do not loop'. We just need to decide what's the best way to do it. For example we already need to avoid any interference with replication, but that is easy to do, as we know if an operation is coming via replication. The other is winsync, but I would argue that winsync maybe should actually use this plugin as it would make it more consistent with the framework. 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] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 01:59 AM, Petr Viktorin wrote: On 02/13/2013 07:11 PM, Simo Sorce wrote: On Wed, 2013-02-13 at 10:57 -0700, Rich Megginson wrote: Rich, is there potential from deadlocking here due to the new transaction stuff ? Or can we single out this plugin to run before *any* transaction is started ? If you do this in a regular pre-op, not a betxn pre-op, then it should be fine. Ok in this case we should be able to create a regular pre-op plugin to intercept the ldap add call and then use the following flow: client --(LDAP)-- 389DS --(HTTP/json)-- framework --(LDAP)-- add So no deadlocks will happen, the remaining issue is how to make sure we do not loop by mistake in the second add. One way could be to have loop detection so that if more then two (1. original, 2. framework) adds for the same DN come in we just return errors. Another way is to use a special objectclass as I proposed in the thread and make sure the framework explictly blacklists it so that it can never try to send an add with the special oc even by mistake or user misconfiguration. And a third way is a separate LDAP tree. I'm not familiar with what DS plugins can do. Can we craft one that intercepts all read operations on cn=HR tree,$SUFFIX and does them on cn=users,cn=accounts,$SUFFIX instead (using that tree's permissions), and forwards all write operations on cn=HR tree to IPA via JSON? Yes. A fourth way is a proxy/gateway, essentially the same but with a separate server. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
Simo Sorce wrote: On Thu, 2013-02-14 at 09:47 -0500, Rob Crittenden wrote: John Dennis wrote: On 02/14/2013 09:05 AM, Simo Sorce wrote: So as I proposed we can call ipa user-add from LDAP from a non-transactional pre-op plugin. We just need to be careful about when we allow that to avoid loops, but besides that problem it seem relatively easy and does not require crazy things like playgrounds or even full LDAP proxies. I think I need a clarification because perhaps I didn't fully understand your proposal. Is the idea with a non-transactional pre-op plugin it invokes user-add and then the pre-op returns *without* having modified ldap? In effect it acts as a trigger? That still implies there has to be a separate tree where the foreign entity writes (and the pre-op plugin watches) because otherwise how could the pre-op plugin distinguish between framework writes and foreign writes? The proposal is that we write a 389-ds plugin that intercepts LDAP ADD operations. I don't think Simo proposed where in the tree this would be written, or whether we would be able to distinguish between a normal ADD and this special case (loop 1). I did, please see my other emails in the thread. For the purposes of modification you probably want it to write into the current user container. It will need to be able to push MOD requests for names, addresses, etc. Most LDAP apps take a single basedn against which to do things. We can't expect to be able to provide one set for adds and one set for mods. We do not intercept mods, period. The only *real* issue is creating users, because the framework adds a lot of stuff to properly format users, but modifications from LDAP clients is fair game. We are in agreement here. My point is that if we try to write to a special part of the tree then move the entry then MODS will always fail. We cannot consider the framework as the only gatekeeper beyond object creation, if this is not clear we need to discuss. That was actually the point of the framework from the beginning. And of course this leads into deletes. We want users gone when they leave the company. Feature creep already. Do we do anything special in the framework for user deletes now ? I am not aware of any special ops, and I would be against making a delete operation a special operation. Any operation can have a pre/post operation. One RFE we have is to add triggers so that shell scripts (or whatever) can be executed at times. This is is the sort of thing that would be missed. If there is a separate tree where is the looping issue? You still haven't explained this. The looping is in telling whether the add is from the external HR source or a normal ADD from IPA. If we get it wrong, ever, then it will ADD, then call ipa user-add, ADD, call ipa user-add, ADD, ... Yes, this is the only concern, I made one proposal to avoid the issue, there are also other ways, for example the framework could use a special control to tell our server 'I am the framework, do not loop'. We just need to decide what's the best way to do it. Right. I don't know enough about how much flexibility these external systems have when creating LDAP objects so they may not be able to add additional objectclasses. A control may be the way to go. For example we already need to avoid any interference with replication, but that is easy to do, as we know if an operation is coming via replication. The other is winsync, but I would argue that winsync maybe should actually use this plugin as it would make it more consistent with the framework. Yes, if we could solve this without too much performance issues that should work. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 04:22 PM, Rich Megginson wrote: On 02/14/2013 01:59 AM, Petr Viktorin wrote: On 02/13/2013 07:11 PM, Simo Sorce wrote: On Wed, 2013-02-13 at 10:57 -0700, Rich Megginson wrote: Rich, is there potential from deadlocking here due to the new transaction stuff ? Or can we single out this plugin to run before *any* transaction is started ? If you do this in a regular pre-op, not a betxn pre-op, then it should be fine. Ok in this case we should be able to create a regular pre-op plugin to intercept the ldap add call and then use the following flow: client --(LDAP)-- 389DS --(HTTP/json)-- framework --(LDAP)-- add So no deadlocks will happen, the remaining issue is how to make sure we do not loop by mistake in the second add. One way could be to have loop detection so that if more then two (1. original, 2. framework) adds for the same DN come in we just return errors. Another way is to use a special objectclass as I proposed in the thread and make sure the framework explictly blacklists it so that it can never try to send an add with the special oc even by mistake or user misconfiguration. And a third way is a separate LDAP tree. I'm not familiar with what DS plugins can do. Can we craft one that intercepts all read operations on cn=HR tree,$SUFFIX and does them on cn=users,cn=accounts,$SUFFIX instead (using that tree's permissions), and forwards all write operations on cn=HR tree to IPA via JSON? Yes. Then I recommend doing this. It avoids problems with delegation (the real tree permissions are used) and looping (plugin and IPA write to separate trees). Other operations (deletes, mods) can be either similarly delegated to the real tree, or passed through IPA if we want to do that in the future. Problems with replication can be solved by just not replicating the separate tree. It also doesn't pollute core IPA with special cases, which is what worries me. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE
On 2/14/2013 6:30 AM, Petr Vobornik wrote:
If they are mutually exclusive, they probably should be separated using
radio buttons like this:
PAC: ( ) None
(o) Type:
[x] MS-PAC
[ ] PAD
You missed one option: nothing selected. It can be solved by adding '(
) Inherited' radio.
I wouldn't have guessed that :) I agree we should add the 'Inherited'
option.
Anyway, this design seems more user friendly for more general audience
than mine so I will implement it. The only problem with it is that one
have to come with new label for each group and empty value - can't be
inferred from metadata.
Is there any issue adding new labels at this point? Worst case we could
hard code the label now and add a translation later.
It might be better to use a composite widget of radio buttons and
checkboxes so we can reuse the code. Probably the definition will look
something like this:
{
name: 'ipakrbauthzdata',
type: 'radio',
Not sure if it should be radio, more like something new.
Right, probably the current radio widget can't do this. So either we
improve the radio widget or create something new.
label: ...,
options: [
{
label: ...,
value: 'NONE'
},
{
label: ...,
type: 'checkboxes',
Do you expect to be there something different than checkboxes, or do you
want it to do it this way for possible future customization.
Ideally it should be generic enough to combine any widgets. This might
be a common scenario somewhere else:
Something: ( ) Option 1
( ) Option 2
(o) Other: [something else ]
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote: Then I recommend doing this. It avoids problems with delegation (the real tree permissions are used) and looping (plugin and IPA write to separate trees). Virtual objects are not free of issues, you are just trading some issues for others here, and I do not think you are properly evaluating the trade here. I am dead set against using staging areas, and I want to see proof they are a good idea, not handwaving 'fears' of using json in the server to forward operations directly to the framework. Other operations (deletes, mods) can be either similarly delegated to the real tree, And *this* is a slippery slope. you are trading delegating one single operation to the framework directly, with proper error propagation back to the client, with now implementing full virtualized operations for mod and delete, and bind ? and search and then ? You are now basically paving the way for a virtual directory in tree. Sorry, but no. or passed through IPA if we want to do that in the future. Problems with replication can be solved by just not replicating the separate tree. More and more hacks, for this supposedly 'cleaner' or 'simpler' solution ... sorry if I don't bite. It also doesn't pollute core IPA with special cases, which is what worries me. What does this mean ? We *have* a special case, and we are discussing how to handle it. The situation here (I do not want to call it a 'problem') is that we decided to put business logic around user creation in the framework because we thought that would be easier to prototype and develop in python code rather than in a plugin. However this special handling *must* be limited. LDAP is our main storage, and we must allow LDAP operations against it. Special cases needs to be limited to things that are really harder done in plugins rather then python code. For example if we need triggers for some operations in LDAP, they *must* be done through a 389ds plugin. Otherwise LDAP quickly becomes a read-only interface and interoperability quickly goes out of the window. I always treated the framework as a *management interface* on top. We can do things that are 'convenient', and 'help' admins avoid mistakes, but we cannot move core functionality in the framework, it would be a grave mistake. User creation *is* a special case, but should remain one of very few special exceptions. This very thread and the need for the interface proposed in this thread is a clear example of why we need to be extremely careful not to be too liberal with what business logic we move in the framework. LDAP keeps us honest, so we need to limit what we do in the framework, otherwise we'll keep taking shortcuts and soon enough it goes out of control and we loose interoperability with anything that is not purpose-built to talk to our framework. This should be an unacceptable scenario because it is like putting ourselves in a getto. We trade greater interoperability and acceptance for small conveniences here and there. We must thread *very* carefully along this line. 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] 1085 cert-find command
On 02/14/2013 03:34 PM, Rob Crittenden wrote: Petr Vobornik wrote: On 02/07/2013 03:08 PM, Rob Crittenden wrote: Petr Vobornik wrote: On 02/06/2013 12:44 AM, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob Should I create Web UI in scope of this ticket or a new one? I was also thinking if it's time to implement #191 'Web UI: specify fields to search on' [1]. Maybe in Pilsner. [1] https://fedorahosted.org/freeipa/ticket/191 I'm going to open a UI ticket once the API is finalized. I didn't want to give you a moving target to work against. rob I see that the search requires to specify options for attributes to search on. There is no general CRITERIA positional argument as in other find commands or am I mistaken? Is it possible to add the CRITERIA argument? Is the no 'OR' search an obstacle for it? If so we would really need to push the ticket #191 because UI doesn't support search by only specifying specific attributes yet. Your analysis is correct. It may be considered a hack but what if I treat subject as the CRITERIA argument? rob Better that than nothing. Just a confirmation: when user does not set any option, it will return all certificates? Or it will return nothing? I see Web UI implementation this way: 1) implement simple search with the hack now 2) if there will be time before release (after the refactoring and other tickets) implement #191 (will require UXD input) to implement this the proper way. We can move #191 to triage to decide it. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 09:01 AM, Simo Sorce wrote: On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote: Then I recommend doing this. It avoids problems with delegation (the real tree permissions are used) and looping (plugin and IPA write to separate trees). Virtual objects are not free of issues, you are just trading some issues for others here, and I do not think you are properly evaluating the trade here. I am dead set against using staging areas, and I want to see proof they are a good idea, not handwaving 'fears' of using json in the server to forward operations directly to the framework. Other operations (deletes, mods) can be either similarly delegated to the real tree, And *this* is a slippery slope. you are trading delegating one single operation to the framework directly, with proper error propagation back to the client, with now implementing full virtualized operations for mod and delete, and bind ? and search and then ? You are now basically paving the way for a virtual directory in tree. Sorry, but no. or passed through IPA if we want to do that in the future. Problems with replication can be solved by just not replicating the separate tree. More and more hacks, for this supposedly 'cleaner' or 'simpler' solution ... sorry if I don't bite. It also doesn't pollute core IPA with special cases, which is what worries me. What does this mean ? We *have* a special case, and we are discussing how to handle it. The situation here (I do not want to call it a 'problem') is that we decided to put business logic around user creation in the framework because we thought that would be easier to prototype and develop in python code rather than in a plugin. However this special handling *must* be limited. LDAP is our main storage, and we must allow LDAP operations against it. Special cases needs to be limited to things that are really harder done in plugins rather then python code. For example if we need triggers for some operations in LDAP, they *must* be done through a 389ds plugin. Otherwise LDAP quickly becomes a read-only interface and interoperability quickly goes out of the window. I always treated the framework as a *management interface* on top. We can do things that are 'convenient', and 'help' admins avoid mistakes, but we cannot move core functionality in the framework, it would be a grave mistake. User creation *is* a special case, but should remain one of very few special exceptions. This very thread and the need for the interface proposed in this thread is a clear example of why we need to be extremely careful not to be too liberal with what business logic we move in the framework. LDAP keeps us honest, so we need to limit what we do in the framework, otherwise we'll keep taking shortcuts and soon enough it goes out of control and we loose interoperability with anything that is not purpose-built to talk to our framework. This should be an unacceptable scenario because it is like putting ourselves in a getto. We trade greater interoperability and acceptance for small conveniences here and there. We must thread *very* carefully along this line. +1 - virtual trees usually end up being rat holes with no end What is the problem we're trying to solve? To be able to call python code in response to an LDAP operation? What if we added a python interpreter to 389, like OpenLDAP back-python? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0030] Add option to specify SID using domain name to idrange-add/mod
On Thu, 14 Feb 2013, Tomas Babej wrote:
+ Str('ipanttrusteddomainname?',
+ cli_name='dom_name',
+ flags=('no_search', 'virtual_attribute'),
+ label=_('Name of the trusted domain'),
+ ),
New options is added but API.txt wasn't changed. As result, 'make rpms'
does not work.
Could you please fix the patch and re-send it?
Sorry about that.
Updated patch attached.
I have one small question regarding use of dom_sid/dom_name.
If both dom_sid and dom_name were specified, failing to resolve dom_name
would force command to raise exception.
I'm not sure this is right behavior. Probably we should detect that both
dom_sid and dom_name were specified and bail out earlier so that only
one of them is accepted. That would be clearer to users, wouldn't it
Sure, I definitely agree on that point. I added the check to idrange-add and
idrange-mod. Also, the patch needed a rebase to apply on the current master.
I tried to play with various scenarious and one thing I noticed is
that we refer dom_sid and dom_name in the error messages as they are
named internally. CLI replaces underscore by hyphen (_ - -) and therefore
this error message becomes wrong -- you cannot specify --dom_sid, this
option is unknown to CLI.
In Web UI this would also mean an error message pointing to non-existing
option. Perhaps it would be reasonable to name options '--name' and
'--sid'? We don't have any clash there:
-
# ipa idrange-mod --help
Usage: ipa [global-options] idrange-mod NAME [options]
Positional arguments:
NAME Range name
Options:
-h, --helpshow this help message and exit
--base-id=INT First Posix ID of the range
--range-size=INT Number of IDs in the range
--rid-base=INTFirst RID of the corresponding RID range
--secondary-rid-base=INT
First RID of the secondary RID range
--dom-sid=STR Domain SID of the trusted domain
--dom-name=STRName of the trusted domain
--setattr=STR Set an attribute to a name/value pair. Format is
attr=value. For multi-valued attributes, the command
replaces the values already present.
--addattr=STR Add an attribute/value pair. Format is
attr=value. The
attribute must be part of the schema.
--delattr=STR Delete an attribute/value pair. The option willbe
evaluated last, after all sets and adds.
--rights Display the access rights of this entry(requires
--all). See ipa man page for details.
--all Retrieve and print all attributes from the server.
Affects command output.
--raw Print entries as stored on the server. Only affects
output format.
-
So, if --name and --sid were used, an error message would become
--
# ipa idrange-mod AD.LAN_id_range --dom-name foo.bar
ipa: ERROR: invalid 'ID Range setup': SID for the specified trusted
domain name could not be found. Please specify the SID directly using
--sid option.
--
Additionally, there is an error when SID for an object within the domain
is specified. Last RID of the SID represents an object within the domain
and we generally need to be careful allowing it in the place where
domain SID is specified:
# ipa idrange-mod AD.LAN_id_range --dom-sid
S-1-5-21-3502988750-125904550-3683905862-1
---
Modified ID range AD.LAN_id_range
---
Range name: AD.LAN_id_range
First Posix ID of the range: 144280
Number of IDs in the range: 20
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-3502988750-125904550-3683905862-1
Range type: Active Directory domain range
Now this range is completely unusable due to the fact that there is no
way to match the domain SID against the range.
I think we need to make the check against established trusts more
strict and only allow exact match.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On Thu, 2013-02-14 at 17:31 +0100, Petr Viktorin wrote: On 02/14/2013 05:01 PM, Simo Sorce wrote: On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote: Then I recommend doing this. It avoids problems with delegation (the real tree permissions are used) and looping (plugin and IPA write to separate trees). Virtual objects are not free of issues, you are just trading some issues for others here, and I do not think you are properly evaluating the trade here. I am dead set against using staging areas, and I want to see proof they are a good idea, not handwaving 'fears' of using json in the server to forward operations directly to the framework. Other operations (deletes, mods) can be either similarly delegated to the real tree, And *this* is a slippery slope. you are trading delegating one single operation to the framework directly, with proper error propagation back to the client, with now implementing full virtualized operations for mod and delete, and bind ? and search and then ? You are now basically paving the way for a virtual directory in tree. Sorry, but no. or passed through IPA if we want to do that in the future. Problems with replication can be solved by just not replicating the separate tree. More and more hacks, for this supposedly 'cleaner' or 'simpler' solution ... sorry if I don't bite. It also doesn't pollute core IPA with special cases, which is what worries me. What does this mean ? We *have* a special case, and we are discussing how to handle it. The situation here (I do not want to call it a 'problem') is that we decided to put business logic around user creation in the framework because we thought that would be easier to prototype and develop in python code rather than in a plugin. However this special handling *must* be limited. LDAP is our main storage, and we must allow LDAP operations against it. Special cases needs to be limited to things that are really harder done in plugins rather then python code. For example if we need triggers for some operations in LDAP, they *must* be done through a 389ds plugin. Otherwise LDAP quickly becomes a read-only interface and interoperability quickly goes out of the window. I always treated the framework as a *management interface* on top. We can do things that are 'convenient', and 'help' admins avoid mistakes, but we cannot move core functionality in the framework, it would be a grave mistake. User creation *is* a special case, but should remain one of very few special exceptions. This very thread and the need for the interface proposed in this thread is a clear example of why we need to be extremely careful not to be too liberal with what business logic we move in the framework. LDAP keeps us honest, so we need to limit what we do in the framework, otherwise we'll keep taking shortcuts and soon enough it goes out of control and we loose interoperability with anything that is not purpose-built to talk to our framework. This should be an unacceptable scenario because it is like putting ourselves in a getto. We trade greater interoperability and acceptance for small conveniences here and there. We must thread *very* carefully along this line. Simo. Ah! This is a point we need to stress more, I didn't get it. All this time I thought of it the other way -- IPA being the main interface, with LDAP being more of an implementation detail -- the storage, and a read-only interface for LDAP consumers. Thanks for explaining, your solution makes perfect sense then. However, if there are more people like me, then there's code in IPA that assumes IPA is the only interface modifications, and raw LDAP operations are hacks that happen to work for now. IPA's command plugins also seem misguided now, as you pointed out. I don't like this view much but, well, I can adapt. Allowing writes by tools that aren't purpose-built to talk to our framework, (for example ones that don't honor our schema), still seems like something to be wary of. It's a balancing act. The schema is always honored, that's why there are MUST and MAY attributes. If the schema is build with the wrong specification of MUST and MAYs that's a bug on our part. Also, there are some parts of the tree that are more sensitive than others. Some things are pretty IPA specific, and for those cases relying a bit more on the framework is ok for now. But in general LDAP is a primary interface, it's where replication happens, and where all components converge. So it is the center of all things. Think about triggers for example. One of the triggers that gets often requested is to be create home directories when users are created. Now, besides the point of whether we want or can do that, if you were to implement it you would have to do it at the 389ds level. You cannot do it in the framework at all for the simple reason
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 02/14/2013 05:01 PM, Simo Sorce wrote: On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote: Then I recommend doing this. It avoids problems with delegation (the real tree permissions are used) and looping (plugin and IPA write to separate trees). Virtual objects are not free of issues, you are just trading some issues for others here, and I do not think you are properly evaluating the trade here. I am dead set against using staging areas, and I want to see proof they are a good idea, not handwaving 'fears' of using json in the server to forward operations directly to the framework. Other operations (deletes, mods) can be either similarly delegated to the real tree, And *this* is a slippery slope. you are trading delegating one single operation to the framework directly, with proper error propagation back to the client, with now implementing full virtualized operations for mod and delete, and bind ? and search and then ? You are now basically paving the way for a virtual directory in tree. Sorry, but no. or passed through IPA if we want to do that in the future. Problems with replication can be solved by just not replicating the separate tree. More and more hacks, for this supposedly 'cleaner' or 'simpler' solution ... sorry if I don't bite. It also doesn't pollute core IPA with special cases, which is what worries me. What does this mean ? We *have* a special case, and we are discussing how to handle it. The situation here (I do not want to call it a 'problem') is that we decided to put business logic around user creation in the framework because we thought that would be easier to prototype and develop in python code rather than in a plugin. However this special handling *must* be limited. LDAP is our main storage, and we must allow LDAP operations against it. Special cases needs to be limited to things that are really harder done in plugins rather then python code. For example if we need triggers for some operations in LDAP, they *must* be done through a 389ds plugin. Otherwise LDAP quickly becomes a read-only interface and interoperability quickly goes out of the window. I always treated the framework as a *management interface* on top. We can do things that are 'convenient', and 'help' admins avoid mistakes, but we cannot move core functionality in the framework, it would be a grave mistake. User creation *is* a special case, but should remain one of very few special exceptions. This very thread and the need for the interface proposed in this thread is a clear example of why we need to be extremely careful not to be too liberal with what business logic we move in the framework. LDAP keeps us honest, so we need to limit what we do in the framework, otherwise we'll keep taking shortcuts and soon enough it goes out of control and we loose interoperability with anything that is not purpose-built to talk to our framework. This should be an unacceptable scenario because it is like putting ourselves in a getto. We trade greater interoperability and acceptance for small conveniences here and there. We must thread *very* carefully along this line. Simo. Ah! This is a point we need to stress more, I didn't get it. All this time I thought of it the other way -- IPA being the main interface, with LDAP being more of an implementation detail -- the storage, and a read-only interface for LDAP consumers. Thanks for explaining, your solution makes perfect sense then. However, if there are more people like me, then there's code in IPA that assumes IPA is the only interface modifications, and raw LDAP operations are hacks that happen to work for now. IPA's command plugins also seem misguided now, as you pointed out. I don't like this view much but, well, I can adapt. Allowing writes by tools that aren't purpose-built to talk to our framework, (for example ones that don't honor our schema), still seems like something to be wary of. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP
On 2/14/2013 8:06 AM, Simo Sorce wrote: On Thu, 2013-02-14 at 14:26 +0100, Petr Spacek wrote: In my Fedora 17 I found package python-ldaptor. It seems to offer nice support for writing own event-based LDAP servers. For simple LDAP proxy it could be enough. $ yum install python-ldaptor $ python import ldaptor.protocols.ldap.ldapserver help(ldaptor.protocols.ldap.ldapserver) No. LDAP proxies are *not* simple. Ask Endi he's worked on a meta-directory for years. Simo. It depends on what you want to do with the proxy. If it's only a thin layer which converts the LDAP ADD to IPA user-add it might not be that complicated. Penrose virtual directory consists of a frontend LDAP interface, a transformation engine, and backends which may include an LDAP server as well. The front-end LDAP interface is the proxy we're talking about here, it's only used to receive LDAP requests and pass them to the transformation engine. The transformation engine is where the complexity occurs. In IPA this is already handled by the framework. In Penrose it's quite complex because it aims to provide a generic way to map an LDAP request to multiple backends which involves dealing with different types of backends, joining the backends, transforming the DN attributes back and forth, etc. So I'd say implementing an LDAP frontend for IPA using Python is something worth exploring. That way it can run in the same process so there's no concern about JSON performance/stability. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] patch for trac 2575
Thanks Martin and Dmitri. I have attached a patch that I -think- is formatted
correctly... I removed the new variable and added check for --unattended.
Thanks,
Brian
- Original Message -
From: Martin Kosek mko...@redhat.com
To: d...@redhat.com
Cc: freeipa-devel@redhat.com
Sent: Wednesday, February 13, 2013 11:16:51 PM
Subject: Re: [Freeipa-devel] patch for trac 2575
On 02/14/2013 03:49 AM, Dmitri Pal wrote:
On 02/13/2013 05:20 PM, Brian Cook wrote:
Please disregard the first patch as it still asked the user if they want to
install DNS even if --setup-dns was passed, this one is fixed.
Brian
Brian,
Thanks for the patch.
Can you please format it following these guidelines:
https://fedorahosted.org/freeipa/wiki/PatchFormat
Thanks
Dmitri
Hello Brian,
Thanks for the patch! Also few technical notes:
1) There is no need to invent the new variable, you can ask and set
options.setup_dns to True. We already to this in other parts incode
2) This patch would --unattended mode when no --setup-dns is passed
Martin
diff --git a/install/tools/ipa-server-install
b/install/tools/ipa-server-install
index 1559107..96ef802 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -564,6 +564,7 @@ def main():
global pw_name
global uninstalling
global installation_cleanup
+
ds = None
safe_options, options = parse_options()
@@ -740,8 +741,18 @@ def main():
admin_password =
reverse_zone = None
- # check bind packages are installed
+ # Setup a variable to use instead of options.setup_dns to enable
interactive DNS selection
+ setup_dns=False
if options.setup_dns:
+ setup_dns=True
+ else:
+ # Ask user if they want to install DNS
+ if ipautil.user_input(Do you want to configure integrated DNS (bind)?,
False):
+ setup_dns=True
+
+
+ # check bind packages are installed
+ if setup_dns:
if not bindinstance.check_inst(options.unattended):
sys.exit(Aborting installation)
@@ -827,7 +838,7 @@ def main():
else:
admin_password = options.admin_password
- if options.setup_dns:
+ if setup_dns:
if options.no_forwarders:
dns_forwarders = ()
elif options.forwarders:
@@ -858,7 +869,7 @@ def main():
print Realm name: %s % realm_name
print
- if options.setup_dns:
+ if setup_dns:
print BIND DNS server will be configured to serve IPA domain with:
print Forwarders: %s % (No forwarders if not dns_forwarders \
else , .join([str(ip) for ip in dns_forwarders]))
@@ -1102,7 +1113,7 @@ def main():
persistent_search=options.persistent_search,
serial_autoincrement=options.serial_autoincrement,
ca_configured=not options.selfsign)
- if options.setup_dns:
+ if setup_dns:
api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
bind_pw=dm_password)
bind.create_instance()
@@ -1147,11 +1158,11 @@ def main():
print \t\t * 80, 443: HTTP/HTTPS
print \t\t * 389, 636: LDAP/LDAPS
print \t\t * 88, 464: kerberos
- if options.setup_dns:
+ if setup_dns:
print \t\t * 53: bind
print \t\tUDP Ports:
print \t\t * 88, 464: kerberos
- if options.setup_dns:
+ if setup_dns:
print \t\t * 53: bind
if options.conf_ntp:
print \t\t * 123: ntp
Message: 8
Date: Wed, 13 Feb 2013 13:39:32 -0800
From: Brian Cook bc...@redhat.com
To: freeipa-devel@redhat.com freeipa-devel@redhat.com
Subject: [Freeipa-devel] patch for trac 2575
Message-ID: 9dd1d1bb-6b86-4ea1-b61b-b208e6bc7...@redhat.com
Content-Type: text/plain; charset=windows-1252
This is a patch for ticket 2575 on trac: [RFE] Installer wizard should
prompt for DNS. This is my first time submitting a patch so I was looking
for something that seemed relatively easy?
Thanks,
Brian
diff --git a/install/tools/ipa-server-install
b/install/tools/ipa-server-install
index 1559107..d8c4ae5 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -564,6 +564,7 @@ def main():
global pw_name
global uninstalling
global installation_cleanup
+
ds = None
safe_options, options = parse_options()
@@ -740,8 +741,18 @@ def main():
admin_password =
reverse_zone = None
- # check bind packages are installed
+ # Setup a variable to use instead of options.setup_dns to enable
interactive DNS selection
+ setup_dns=False
if options.setup_dns:
+ setup_dns=True
+
+ # Ask user if they want to install DNS
+ if ipautil.user_input(Do you want to cnfigure integrated DNS (bind)?,
false):
+ setup_dns=True
+
+
+ # check bind packages are installed
+ if setup_dns:
if not bindinstance.check_inst(options.unattended):
sys.exit(Aborting installation)
@@ -827,7 +838,7 @@ def main():
else:
admin_password = options.admin_password
- if options.setup_dns:
+ if setup_dns:
if options.no_forwarders:
dns_forwarders = ()
elif options.forwarders:
@@ -858,7 +869,7 @@ def main():
