On 02/14/2013 09:01 AM, Simo Sorce wrote:
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
On 02/14/2013 12:33 PM, Endi Sukma Dewata wrote:
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
On Fri, 2013-02-15 at 17:28 -0500, Dmitri Pal wrote:
On 02/14/2013 12:33 PM, Endi Sukma Dewata wrote:
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
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
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
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
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
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
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
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
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/
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
___
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
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
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
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
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
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
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,
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
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,
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
$
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really recommend it because we add
quite a number of attributes automatically in our framework code when we
create
On 02/13/2013 07:53 AM, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really recommend it because we add
quite a number of attributes
On 02/13/2013 03:53 PM, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really recommend it because we add
quite a number of attributes
On 13.2.2013 15:53, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really recommend it because we add
quite a number of attributes automatically
On 02/13/2013 04:15 PM, Petr Spacek wrote:
On 13.2.2013 15:53, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really recommend it because we
On Wed, 2013-02-13 at 16:33 +0100, Petr Viktorin wrote:
On 02/13/2013 04:15 PM, Petr Spacek wrote:
On 13.2.2013 15:53, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in mind IPA is
plugable; at least for outside plugins' sake (if not our own sanity's)
we should keep the number of code
On Wed, 2013-02-13 at 11:27 -0500, Simo Sorce wrote:
This is why I proposed a plugin that is limited to users and calls the
framework so we can use common code.
The *simpler* way would be to simply replicate the core framework
login
in the 389ds plugin or even *move* it there.
But we want
On Wed, 2013-02-13 at 08:08 -0700, Rich Megginson wrote:
On 02/13/2013 07:53 AM, Simo Sorce wrote:
Hello list,
with recently seen a few requests to add FreeIPA users via LDAP
directly. This is a common method supported by many meta-directory/HR
systems, however so far we cannot really
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in mind IPA is
plugable; at least for
On 02/13/2013 05:27 PM, Simo Sorce wrote:
[...]
I am sorry, but 'cleaner' is really the last word I'd use, 'hack' is
what comes to mind here to be honest.
Then I'm missing something. Thanks for your explanations.
What about small (optional) separate daemon?
One more moving part one
On 02/13/2013 09:57 AM, Simo Sorce wrote:
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in
On 02/13/2013 05:57 PM, Simo Sorce wrote:
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in mind IPA is
plugable; at least for outside plugins' sake (if not our own sanity's)
we should keep the
On Wed, 2013-02-13 at 18:16 +0100, Petr Viktorin wrote:
On 02/13/2013 05:57 PM, Simo Sorce wrote:
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP,
I appreciate Simo's concern for authorization and audit in this process,
we must solve that problem. If I understand the proposal correctly it's
akin to recording a macro that can be replayed. The framework executes
as normal but instead of issuing the LDAP modify commands we record
them. Then
On Wed, 2013-02-13 at 18:11 +0100, Petr Viktorin wrote:
1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com
This has more consequences than you may think.
I do not like the separate field idea because you need to treat it in a
special way. We would probably need
On Wed, 2013-02-13 at 12:40 -0500, John Dennis wrote:
I appreciate Simo's concern for authorization and audit in this process,
we must solve that problem. If I understand the proposal correctly it's
akin to recording a macro that can be replayed. The framework executes
as normal but instead
On 02/13/2013 10:50 AM, Simo Sorce wrote:
On Wed, 2013-02-13 at 18:11 +0100, Petr Viktorin wrote:
1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com
This has more consequences than you may think.
I do not like the separate field idea because you need to treat it in a
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
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
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
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
On 02/13/2013 01:30 PM, 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
John Dennis wrote:
On 02/13/2013 01:30 PM, 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
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
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
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
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
On 02/13/2013 09:16 AM, Petr Viktorin wrote:
On 02/13/2013 05:57 PM, Simo Sorce wrote:
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows
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
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
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
55 matches
Mail list logo
