Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib

[Jan Cholasta]

Dne 3.11.2011 12:43, Alexander Bokovoy napsal(a):

On Thu, 03 Nov 2011, Jan Cholasta wrote:

The problem with the API class is that it creates all the plugin
instances every time. Both mine and your patch don't change that,
they deal only with finalization, which is the easier part of the
lazy initialization problem. Additionally, in your patch finalize()
is called only on Command subclasses, so non-Command plugins are not
ReadOnly-locked like they should (currently this is done only when
production mode is off).

I ended up with explicitly finalizing Object, Property, and Backend
objects. This, by the way, proved that major slowdown is brought by
the Command and Method instances as I've got statistically negligible
variations of execution time, within less than 1%.


We could change API so that the plugins are initialized on-demand.
That way we could probably get rid off finalize() on plugins
altogether and move the initialization code into __init__() (because
all the required information would be available on-demand) and the
locking into API. The flaw of this approach is that it would require
a number of fundamental changes, namely changing the way API class
handles plugin initialization and moving the initialization of
static Plugin properties (name, module, fullname, bases, label,
...) from instance level to class level. (Nonetheless, I think API
would't suffer from a facelift - currently it is messy, hard to read
code, with bits nobody ever used or uses anymore, some of the
docstrings and comments aren't correct, etc.)

A review of API class is a good idea. However, I think it is currently
enough what is in proposed patch as it gets you 2-3x speed increase
already.


I've already started experimenting with the API class, hopefully it will 
result in something useful :)




One important feature I'd like to still keep in FreeIPA is ability to
extend any object and action during plugin import phase regardless of
the python source file it comes from. So far our split between 'user
methods' and 'dnsrecord methods' is mostly utilitarian as they are
implemented in their own source code files. However, nobody prevents
you from implementing all needed modifications to all classes in the
single source file and I expect this to be fairly typical to
site-specific cases.

This is something I'd like to keep as it has great value for all
end-users and it requires loading all Python files in ipalib/plugins
(and in ipaserver/plugins for server side).


I'm not suggesting we should skip importing the modules. The plugin 
initialization process consists of these 3 steps:


 1. import plugin modules
 2. create plugin instances
 3. finalize plugin instances

What I'm suggesting is that we do steps 2 and 3 on-demand. We can't do 
step 1 on-demand, because we have no way of knowing what plugins are 
available without importing the modules. (Both your and my patch does 
only step 3 on-demand, but I think we can do better than that.)





Anyway, if we decide to go with your solution, please make sure
*all* the plugins that are used are finalized (because of the
locking) and add a new api.env attribute which controls the lazy
finalization, so that the behavior can be overriden (actually I have
already done that - see attached patch - just use
api.env.plugins_on_demand instead of api.env.context == 'cli').

Done.



+if not self.__dict__['_Plugin__finalized']:
+self.finalize()

This doesn't seem right, coding style-wise. If you want to access the 
property from outside the Plugin class, why did you name-mangle it in 
the first place?


 def finalize(self):
 
 
+if not self.__finalized:
+self.__finalized = True
+else:
+return
 if not is_production_mode(self):
 lock(self)

Finalize is supposed to be called just once, so IMO it would be better 
not to do the check and let it throw the exception.


+for i in ('Object', 'Property', 'Backend'):
+if i in self:
+namespaces.append(self[i])

AFAIK the framework is supposed to be generally usable for other 
projects in the future. With that in mind, I think we can't afford to 
hard-code things like this.


Anyway, I've made a patch that uses data descriptors for the trap 
objects (which is IMHO more elegant than what you do). I've also managed 
to add on-demand finalization to Object and Attribute subclasses by 
moving the set-up code from set_api() to finalize() (it doesn't add much 
performance, though). See attachment.


The numbers from my VM:

master  abbra   jcholast
$ time ipa
real0m1.288s0m0.619s0m0.601s
user0m1.103s0m0.478s0m0.451s
sys 0m0.161s0m0.126s0m0.133s

$ time ipa user-find
real0m1.897s0m1.253s0m1.235s
user0m1.119s0m0.486s0m0.488s
sys 0m0.160s0m0.160s0m0.136s

$ time ipa help
real0m1.299s0m0.629s0m0.600s
user0m1.094s0m0.477s

Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib

[Alexander Bokovoy]

On Wed, 09 Nov 2011, Jan Cholasta wrote:
 would't suffer from a facelift - currently it is messy, hard to read
 code, with bits nobody ever used or uses anymore, some of the
 docstrings and comments aren't correct, etc.)
 A review of API class is a good idea. However, I think it is currently
 enough what is in proposed patch as it gets you 2-3x speed increase
 already.
 
 I've already started experimenting with the API class, hopefully it
 will result in something useful :)
Good.

 This is something I'd like to keep as it has great value for all
 end-users and it requires loading all Python files in ipalib/plugins
 (and in ipaserver/plugins for server side).
 
 I'm not suggesting we should skip importing the modules. The plugin
 initialization process consists of these 3 steps:
 
  1. import plugin modules
  2. create plugin instances
  3. finalize plugin instances
 
 What I'm suggesting is that we do steps 2 and 3 on-demand. We can't
 do step 1 on-demand, because we have no way of knowing what plugins
 are available without importing the modules. (Both your and my patch
 does only step 3 on-demand, but I think we can do better than that.)
Agreed.

 Anyway, if we decide to go with your solution, please make sure
 *all* the plugins that are used are finalized (because of the
 locking) and add a new api.env attribute which controls the lazy
 finalization, so that the behavior can be overriden (actually I have
 already done that - see attached patch - just use
 api.env.plugins_on_demand instead of api.env.context == 'cli').
 Done.
 
 
 +if not self.__dict__['_Plugin__finalized']:
 +self.finalize()
 
 This doesn't seem right, coding style-wise. If you want to access
 the property from outside the Plugin class, why did you name-mangle
 it in the first place?
It is supposed to be internal detail of a Plugin. I agree it stinks a 
bit here. :)

 
  def finalize(self):
  
  
 +if not self.__finalized:
 +self.__finalized = True
 +else:
 +return
  if not is_production_mode(self):
  lock(self)
 
 Finalize is supposed to be called just once, so IMO it would be
 better not to do the check and let it throw the exception.
On contrary, I think sequential finalize() calls should do nothing. 
This is at least what I expect from a finalized object -- no-op.

 +for i in ('Object', 'Property', 'Backend'):
 +if i in self:
 +namespaces.append(self[i])
 
 AFAIK the framework is supposed to be generally usable for other
 projects in the future. With that in mind, I think we can't afford
 to hard-code things like this.
That's true. As you managed to get around without hardcoding, we can 
drop this part.
 
 Anyway, I've made a patch that uses data descriptors for the trap
 objects (which is IMHO more elegant than what you do). I've also
 managed to add on-demand finalization to Object and Attribute
 subclasses by moving the set-up code from set_api() to finalize()
 (it doesn't add much performance, though). See attachment.
I read through the code and I like it! Did you get the whole test 
suite running with it? There are some parts of tests that expect 
non-finalized objects to have None properties while they are now not 
None.

If so, preliminary ACK for your patch from reading it if you would 
make sure on_finalize() allows multiple calls and would make a better 
commit message. ;)

I'll try to arrange testing myself today/tomorrow.

 The numbers from my VM:
 
 master  abbra   jcholast
 $ time ipa
 real0m1.288s0m0.619s0m0.601s
 user0m1.103s0m0.478s0m0.451s
 sys 0m0.161s0m0.126s0m0.133s
 
 $ time ipa user-find
 real0m1.897s0m1.253s0m1.235s
 user0m1.119s0m0.486s0m0.488s
 sys 0m0.160s0m0.160s0m0.136s
 
 $ time ipa help
 real0m1.299s0m0.629s0m0.600s
 user0m1.094s0m0.477s0m0.446s
 sys 0m0.183s0m0.136s0m0.140s
Looks good (your VM is supposedly at the same farm as mine so numbers 
are comparable). There is anyway great variation in execution times in 
VMs so 600ms vs 629ms is roughly the same.

Thanks a lot! I think it is great advance over the original approach.
-- 
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 163+164 Fix DNS zone --allow-dynupdate option behavior

[Martin Kosek]

Patch 164 fixes dnszone-mod --allow-dynupdate behavior which  disables
the zone dynamic updates value whenever a dnszone-mod command is run and
--allow-dynupdate options is not set.

I introduced a Param.encode() function (patch 163) to our framework to
help encoding Python native values to LDAP representation more
effectively. True/False to LDAP's TRUE/FALSE in this case. Encoding
functions are executed in a server context only.

Martin
From 6e230b1e1638a57a92c8654672bd4cbd7cc560cd Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Wed, 9 Nov 2011 14:10:08 +0100
Subject: [PATCH 1/2] Allow custom server backend encoding

Server framework does not support encoding of native Python type
values stored in Param classes and sub-classes. When backend (LDAP)
value encoding differs from Python type value representation user
has to has to hard-code the encoders in his processing.

This patch introduces a method Param.encode which is used in server
context to encode native Python Param values. The new encode method
is used for Bool parameter to convert native Python bool type value
(True, False) to LDAP value (TRUE, FALSE).

https://fedorahosted.org/freeipa/ticket/2039
---
 ipalib/frontend.py |   10 ++
 ipalib/parameters.py   |   29 +
 ipaserver/plugins/ldap2.py |   17 +
 3 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 61e7f493f8a8e30a1a189d06cd6a69893319deaf..851de4379536e10741d012186b9a914a36923ec7 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -428,6 +428,8 @@ class Command(HasParam):
 if not self.api.env.in_server and 'version' not in params:
 params['version'] = API_VERSION
 self.validate(**params)
+if self.api.env.in_server:
+params = self.encode(**params)
 (args, options) = self.params_2_args_options(**params)
 ret = self.run(*args, **options)
 if (
@@ -648,6 +650,14 @@ class Command(HasParam):
 (k, self.params[k].convert(v)) for (k, v) in kw.iteritems()
 )
 
+def encode(self, **kw):
+
+Return a dictionary of encoded values.
+
+return dict(
+(k, self.params[k].encode(v)) for (k, v) in kw.iteritems()
+)
+
 def __convert_iter(self, kw):
 for param in self.params():
 if kw.get(param.name, None) is None:
diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index f9e171b0e5fa9590be73f4935b677c2f4447621c..1f3fdfde7452dace6b13a534b9737e8c3b1b0e5d 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -307,6 +307,7 @@ class Param(ReadOnly):
 ('multivalue', bool, False),
 ('primary_key', bool, False),
 ('normalizer', callable, None),
+('encoder', callable, None),
 ('default_from', DefaultFrom, None),
 ('create_default', callable, None),
 ('autofill', bool, False),
@@ -768,6 +769,34 @@ class Param(ReadOnly):
 rule=rule,
 )
 
+def encode(self, value):
+
+Encode Python native type value to chosen backend format. Encoding is
+applied for parameters representing actual attributes (attribute=True).
+
+The default encode method `Param._encode` can be overriden in a `Param`
+instance with `encoder` attribute:
+
+ s = Str('my_str', encoder=lambda x:encode(x))
+
+Note that the default method of encoding values is defined in
+`Param._encode()`.
+
+:param value: Encoded value
+
+if not self.attribute: #pylint: disable=E1101
+return value
+if self.encoder is not None: #pylint: disable=E1101
+return self.encoder(value) #pylint: disable=E1101
+
+return self._encode(value)
+
+def _encode(self, value):
+
+Encode a value to backend format.
+
+return value
+
 def get_default(self, **kw):
 
 Return the static default or construct and return a dynamic default.
diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index 5c40182933143021abf817bff4ed12287697e4ea..32a1eccb437a1ed3ed74208cdbbb834b3dd1fbc6 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -45,6 +45,7 @@ from ldap.controls import LDAPControl
 from ldap.functions import explode_dn
 from ipalib.dn import DN
 from ipalib import _
+from ipalib.parameters import Bool
 
 import krbV
 
@@ -62,6 +63,22 @@ MEMBERS_INDIRECT = 2
 # SASL authentication mechanism
 SASL_AUTH = _ldap_sasl.sasl({}, 'GSSAPI')
 
+# OID 1.3.6.1.4.1.1466.115.121.1.7 (Boolean) syntax encoding
+def _encode_bool(self, value):
+def encode_bool_value(value):
+if value:
+return u'TRUE'
+else:
+return u'FALSE'
+
+if type(value) in (tuple, list):
+return tuple(encode_bool_value(v) for v in value)
+else:
+

Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts

[Simo Sorce]

On Tue, 2011-11-08 at 20:45 -0500, Dan Scott wrote:
 Hi,
 
 On Tue, Nov 8, 2011 at 18:35, Simo Sorce s...@redhat.com wrote:
  On Tue, 2011-11-08 at 17:57 -0500, Dmitri Pal wrote:
  On 11/08/2011 02:56 PM, Dan Scott wrote:
   Hi,
  
   This is a great feature. It feels like I'm always re-installing VMs
   and having to remove old SSH keys and re-accept new ones.
  
   One feature I'd like is to have this working cross-realm. We have 2
   IPA realms here and it would be great if I could configure SSSD to
   check the local realm if I'm SSHing to a local PC and to check the
   other IPA server(s) if my SSH target is part of the other realm. Even
   better if it could do this without explicit configuration.
  
   Do you think it would be possible to do this securely?
 
  When we start to support Cross Realm Kerberos Trusts for IPA to IPA I
  think this would be doable but then I do not think the ssh host keys
  will be used (needed). Simo, am I correct?
 
  We do not have the GSSAPI key exchange patches in OpenSSH. With those
  the ssh host key is not necessary when using GSSAPI auth, even in the
  same realm.
 
  But when you want to use ssh host keys, across realm kerberos trust is
  not going to help.
 
 I don't quite understand this. What trust is required, other than the
 cross-realm authentication of kerberos tickets? Surely each realm
 would manage its own host keys. All I'm looking for is an
 authenticated cross-realm key lookup so that my client can pre-cache
 entries in the known_hosts file. Wouldn't this just be an LDAP lookup?

Well in 2-way trusts you could do that. But in general you do not want
to have any client in realm1 to contact any server in realm2. They might
be geographically very far and use high latency/low bandwidth links.

So, for a first implementation, we could do what you say, but I rather
think it through and see how to cache/transfer information making
clients go through their IPA server rather than trying to connect
directly to a remote one.

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] 163+164 Fix DNS zone --allow-dynupdate option behavior

[Alexander Bokovoy]

On Wed, 09 Nov 2011, Martin Kosek wrote:
 Patch 164 fixes dnszone-mod --allow-dynupdate behavior which  disables
 the zone dynamic updates value whenever a dnszone-mod command is run and
 --allow-dynupdate options is not set.
As discussed on IRC, please rename the CLI option name to 
--dynamic-update.

Otherwise, ACK.

Please also file a ticket for 3.0 for gathering all renames of CLI 
options where we feel they are unclear or unfriendly.

 I introduced a Param.encode() function (patch 163) to our framework to
 help encoding Python native values to LDAP representation more
 effectively. True/False to LDAP's TRUE/FALSE in this case. Encoding
 functions are executed in a server context only.
Ack.

-- 
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts

[Dan Scott]

Hi,

On Tue, Nov 8, 2011 at 18:35, Simo Sorce s...@redhat.com wrote:
 On Tue, 2011-11-08 at 17:57 -0500, Dmitri Pal wrote:
 On 11/08/2011 02:56 PM, Dan Scott wrote:
  Hi,
 
  This is a great feature. It feels like I'm always re-installing VMs
  and having to remove old SSH keys and re-accept new ones.
 
  One feature I'd like is to have this working cross-realm. We have 2
  IPA realms here and it would be great if I could configure SSSD to
  check the local realm if I'm SSHing to a local PC and to check the
  other IPA server(s) if my SSH target is part of the other realm. Even
  better if it could do this without explicit configuration.
 
  Do you think it would be possible to do this securely?

 When we start to support Cross Realm Kerberos Trusts for IPA to IPA I
 think this would be doable but then I do not think the ssh host keys
 will be used (needed). Simo, am I correct?

 We do not have the GSSAPI key exchange patches in OpenSSH. With those
 the ssh host key is not necessary when using GSSAPI auth, even in the
 same realm.

 But when you want to use ssh host keys, across realm kerberos trust is
 not going to help.

I don't quite understand this. What trust is required, other than the
cross-realm authentication of kerberos tickets? Surely each realm
would manage its own host keys. All I'm looking for is an
authenticated cross-realm key lookup so that my client can pre-cache
entries in the known_hosts file. Wouldn't this just be an LDAP lookup?

Dan

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib

[Jan Cholasta]

Dne 9.11.2011 11:59, Alexander Bokovoy napsal(a):

On Wed, 09 Nov 2011, Jan Cholasta wrote:

would't suffer from a facelift - currently it is messy, hard to read
code, with bits nobody ever used or uses anymore, some of the
docstrings and comments aren't correct, etc.)

A review of API class is a good idea. However, I think it is currently
enough what is in proposed patch as it gets you 2-3x speed increase
already.


I've already started experimenting with the API class, hopefully it
will result in something useful :)

Good.


This is something I'd like to keep as it has great value for all
end-users and it requires loading all Python files in ipalib/plugins
(and in ipaserver/plugins for server side).


I'm not suggesting we should skip importing the modules. The plugin
initialization process consists of these 3 steps:

  1. import plugin modules
  2. create plugin instances
  3. finalize plugin instances

What I'm suggesting is that we do steps 2 and 3 on-demand. We can't
do step 1 on-demand, because we have no way of knowing what plugins
are available without importing the modules. (Both your and my patch
does only step 3 on-demand, but I think we can do better than that.)

Agreed.


Anyway, if we decide to go with your solution, please make sure
*all* the plugins that are used are finalized (because of the
locking) and add a new api.env attribute which controls the lazy
finalization, so that the behavior can be overriden (actually I have
already done that - see attached patch - just use
api.env.plugins_on_demand instead of api.env.context == 'cli').

Done.



+if not self.__dict__['_Plugin__finalized']:
+self.finalize()

This doesn't seem right, coding style-wise. If you want to access
the property from outside the Plugin class, why did you name-mangle
it in the first place?

It is supposed to be internal detail of a Plugin. I agree it stinks a
bit here. :)



  def finalize(self):
  
  
+if not self.__finalized:
+self.__finalized = True
+else:
+return
  if not is_production_mode(self):
  lock(self)

Finalize is supposed to be called just once, so IMO it would be
better not to do the check and let it throw the exception.

On contrary, I think sequential finalize() calls should do nothing.
This is at least what I expect from a finalized object -- no-op.


In my patch, finalize() throws an exception if called more than once, 
but ensure_finalized() does nothing for plugins that are already 
finalized. So there are both kinds of behavior available.





+for i in ('Object', 'Property', 'Backend'):
+if i in self:
+namespaces.append(self[i])

AFAIK the framework is supposed to be generally usable for other
projects in the future. With that in mind, I think we can't afford
to hard-code things like this.

That's true. As you managed to get around without hardcoding, we can
drop this part.


Anyway, I've made a patch that uses data descriptors for the trap
objects (which is IMHO more elegant than what you do). I've also
managed to add on-demand finalization to Object and Attribute
subclasses by moving the set-up code from set_api() to finalize()
(it doesn't add much performance, though). See attachment.

I read through the code and I like it! Did you get the whole test
suite running with it? There are some parts of tests that expect
non-finalized objects to have None properties while they are now not
None.


I always run the test suite ;-)

All the unit tests succeed (they do when run with my patch 54 applied, 
which fixes failures of some unrelated unit tests).




If so, preliminary ACK for your patch from reading it if you would
make sure on_finalize() allows multiple calls and would make a better
commit message. ;)


on_finalize() shouldn't be called directly (perhaps I should rename it 
to _on_finalize to emphasize that...?)


I'll work on the commit message. As usual, it is the hardest part of the 
patch for me.




I'll try to arrange testing myself today/tomorrow.


The numbers from my VM:

 master  abbra   jcholast
$ time ipa
real0m1.288s0m0.619s0m0.601s
user0m1.103s0m0.478s0m0.451s
sys 0m0.161s0m0.126s0m0.133s

$ time ipa user-find
real0m1.897s0m1.253s0m1.235s
user0m1.119s0m0.486s0m0.488s
sys 0m0.160s0m0.160s0m0.136s

$ time ipa help
real0m1.299s0m0.629s0m0.600s
user0m1.094s0m0.477s0m0.446s
sys 0m0.183s0m0.136s0m0.140s

Looks good (your VM is supposedly at the same farm as mine so numbers
are comparable). There is anyway great variation in execution times in
VMs so 600ms vs 629ms is roughly the same.


Yep.



Thanks a lot! I think it is great advance over the original approach.


Thanks for the kind words :-)

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com

Re: [Freeipa-devel] [PATCH] 163+164 Fix DNS zone --allow-dynupdate option behavior

[Martin Kosek]

On Wed, 2011-11-09 at 16:14 +0200, Alexander Bokovoy wrote:
 On Wed, 09 Nov 2011, Martin Kosek wrote:
  Patch 164 fixes dnszone-mod --allow-dynupdate behavior which  disables
  the zone dynamic updates value whenever a dnszone-mod command is run and
  --allow-dynupdate options is not set.
 As discussed on IRC, please rename the CLI option name to 
 --dynamic-update.
 
 Otherwise, ACK.

Renamed and pushed to master.

Endi, Petr, I created a ticket to implement this new behavior in WebUI
too:

https://fedorahosted.org/freeipa/ticket/2084

 
 Please also file a ticket for 3.0 for gathering all renames of CLI 
 options where we feel they are unclear or unfriendly.

https://fedorahosted.org/freeipa/ticket/2083

 
  I introduced a Param.encode() function (patch 163) to our framework to
  help encoding Python native values to LDAP representation more
  effectively. True/False to LDAP's TRUE/FALSE in this case. Encoding
  functions are executed in a server context only.
 Ack.
 

Pushed to master.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts

[Simo Sorce]

CCing freeipa-devel so that others can benefit from replies too.

On Wed, 2011-11-09 at 09:49 -0500, Dan Scott wrote:
  Well in 2-way trusts you could do that. But in general you do not want
  to have any client in realm1 to contact any server in realm2. They might
  be geographically very far and use high latency/low bandwidth links.
 
 I must be missing something here. Why does it need to be a 2-way
 trust?

Because otherwise you may not have access to the keys at all unless
anonymous binds are allowed (this is the default indeed).

  My local IPA server doesn't have to trust the remote IPA server
 at all, does it (other than encryption/certificates to prevent a MITM
 - although the existing system doesn't help with that either, for the
 initial host key transfer)? Even then, wouldn't an unauthenticated
 LDAP lookup be OK for transferring the host keys?

No, this is the other aspect. With GSSAPI auth you have mutual
authentication. This means you can trust the remote server. If you just
let clients do anonymous binds and fetch data from a server w/o
authentication then it is easy for an attacker to MITM the LDAP
connection and give you public keys for a ssh server that will also MITM
you.

I know that in many environments people will consider this an unlikely
threat and not care about it, so maybe an RFC to allow SSSD to do this
with un-authenticated connections will be allowed.

 My client would be trying to contact a system in the other realm
 anyway, so I don't really see the latency/bandwidth problems.

It depends on the architecture of your specific setup. I was giving
generic reasons why.

  Surely
 whatever I'm doing over SSH will require more bandwidth than the key
 transfer.

Maybe, maybe not, you may have a host in your local lan that belongs to
a remote realm and only the KDC/LDAP server is remote to you.

  Instead of my client contacting the remote SSH host
 directly. My local SSSD would contact the other realm's IPA server to
 get the key of the host I'm connecting to. Even then, this would be a
 'one-time' key transfer although it would need to be re-checked
 occasionally.

Yes, hence we may allow it.

  So, for a first implementation, we could do what you say, but I rather
  think it through and see how to cache/transfer information making
  clients go through their IPA server rather than trying to connect
  directly to a remote one.
 
 Sure, makes sense. Getting it working in one realm is the priority.

There is also another reason why going through a 'proxy' service is
useful. If you have different IPA versions (or even different DC
technology like IPA vs AD) on the 2 sides of the trust we would be able
to build a 'translation' service on the IPA server so that clients do
not need to learn how to speak to other Identity Domains directly.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 311 Added paging on search facet.

[Endi Sukma Dewata]

The search facet has been modified to support paging on most entities
using the --pkey-only option to get the primary keys and a batch command
to get the complete records.

Paging on DNS records is not supported because a record may appear as
multiple rows. The following entities do not have --pkey-only option:
Automount Key, Self-Service Permissions, Delegation.

The search and association facet have been refactored to reuse the
common code from the table facet base class.

Ticket #981

--
Endi S. Dewata
From 4b8e273447cb3c82ea8668dece54adc5146e831c Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Fri, 4 Nov 2011 20:43:39 -0500
Subject: [PATCH] Added paging on search facet.

The search facet has been modified to support paging on most entities
using the --pkey-only option to get the primary keys and a batch command
to get the complete records.

Paging on DNS records is not supported because a record may appear as
multiple rows. The following entities do not have --pkey-only option:
Automount Key, Self-Service Permissions, Delegation.

The search and association facet have been refactored to reuse the
common code from the table facet base class.

Ticket #981
---
 install/ui/aci.js |2 +
 install/ui/add.js |6 +-
 install/ui/association.js |  221 ---
 install/ui/automount.js   |1 +
 install/ui/dns.js |   57 +++-
 install/ui/facet.js   |  227 -
 install/ui/search.js  |  131 +-
 install/ui/widget.js  |   14 ++--
 8 files changed, 335 insertions(+), 324 deletions(-)

diff --git a/install/ui/aci.js b/install/ui/aci.js
index 92c5dcf02db36dfe48be4b80f0d6d0656c72de61..5d66bfb2bb2542dc57e2a2ac8fe0547948c57ed2 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -200,6 +200,7 @@ IPA.aci.selfservice_entity = function(spec) {
 that.init = function(params) {
 
 params.builder.search_facet({
+pagination: false,
 columns:['aciname']}).
 details_facet({
 sections:[{
@@ -232,6 +233,7 @@ IPA.aci.delegation_entity = function(spec) {
 that.init = function(params) {
 
 params.builder.search_facet({
+pagination: false,
 columns:['aciname']}).
 details_facet({sections:[
 {
diff --git a/install/ui/add.js b/install/ui/add.js
index 621861fd6736fe8c34a2e926f8ed76773737ad96..c9d5e46bb44bafd087fe214be06adb0ecf3d180b 100644
--- a/install/ui/add.js
+++ b/install/ui/add.js
@@ -46,8 +46,7 @@ IPA.entity_adder_dialog = function(spec) {
 that.add(
 function(data, text_status, xhr) {
 var facet = IPA.current_entity.get_facet();
-var table = facet.table;
-table.refresh();
+facet.refresh();
 that.close();
 },
 that.on_error);
@@ -67,8 +66,7 @@ IPA.entity_adder_dialog = function(spec) {
 that.show_message(message);
 
 var facet = IPA.current_entity.get_facet();
-var table = facet.table;
-table.refresh();
+facet.refresh();
 that.reset();
 },
 that.on_error);
diff --git a/install/ui/association.js b/install/ui/association.js
index 6ef73dafe445af5c68fb506c2450fa67724efd84..553966eb93c12c92a8b592bd1054ea7615b153a3 100644
--- a/install/ui/association.js
+++ b/install/ui/association.js
@@ -457,9 +457,9 @@ IPA.association_table_widget = function (spec) {
 }
 
 var batch = IPA.batch_command({
-'name': that.entity.name+'_'+that.name,
-'on_success': on_success,
-'on_error': on_error
+name: that.entity.name+'_'+that.name,
+on_success: on_success,
+on_error: on_error
 });
 
 for (var i=0; ilength; i++) {
@@ -701,7 +701,6 @@ IPA.association_facet = function (spec) {
 
 var that = IPA.table_facet(spec);
 
-that.entity = spec.entity;
 that.attribute_member = spec.attribute_member;
 that.indirect_attribute_member = spec.indirect_attribute_member;
 
@@ -721,8 +720,6 @@ IPA.association_facet = function (spec) {
 
 that.adder_columns = $.ordered_map();
 
-that.page_length = spec.page_length === undefined ? 20 : spec.page_length;
-
 that.get_adder_column = function(name) {
 return that.adder_columns.get(name);
 };
@@ -748,10 +745,16 @@ IPA.association_facet = function (spec) {
 return column;
 };
 
-function setup_columns(){
+var init = function() {
+
 var column;
 var i;
 
+var adder_columns = spec.adder_columns || [];
+for (i=0; iadder_columns.length; i++) {
+

Re: [Freeipa-devel] Screens For HBAC Testing (Ticket #388)

[Dmitri Pal]

On 11/09/2011 05:08 PM, Kyle Baker wrote:
 Endi and I worked to create the model for the new HBAC Testing section. The 
 screens are attached.

 Kyle Baker
 Visual Designer   Desk (978) 392 3116
 UX Team   IRC  kylebaker

Since from host is unreliable, one of the latest decisions in SSSD was
to ignore from host part of the rule by default (causes a lot of
performance issues too) and have a config parameter to explicitly not
ignore it. I think the UI should reflect in some way that From should
not be generally used and not an equal citizen  of the HBAC rule. We
probably should update the existing UI too to discourage people from
using it and also document it in man pages for HBAC and in the docs.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel