Re: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data

[Jan Cholasta]

On 21.1.2013 17:46, Petr Viktorin wrote:

On 01/21/2013 04:48 PM, John Dennis wrote:

On 01/16/2013 10:45 AM, Jan Cholasta wrote:

Hi,

this patch adds initial support for custom LDAP entry objects, as
described in .



Just in case you missed it, I added some requirements to the above
design page about making LDAP attributes and their values be "smarter".


It would be nice to discuss these changes on the list, since the
implementation is already underway...


An LDAP attribute has a syntax defining how comparisons are to be
performed. Python code using standard Python operators, sorting
functions, etc. should "just work" because underneath the object is
aware of it's LDAP syntax.

The same holds true for attribute names, it should "just work" correctly
any place we touch an attribute name because it's an object implementing
the desired comparison and hashing behavior.

Thus the keys in an Entry dict would need to be a new class and the
values would need to be a new class as well. Simple strings do not give
rich enough semantic behavior (we shouldn't be providing this semantic
behavior every place in the code where we touch an attribute name or
value, rather it should just automatically work using standard Python
operators.


I think plain strings are fine for attribute names, as long as the entry
class handles them correctly. We don't really need to hash or compare
them outside of an entry. Or at least not enough to warrant a special
class, IMO.
Of course Entry.keys() and friends should return normalized names that
would sort/hash correctly.


+1




As for attribute values, you're right that LDAP specifies how they
should be compared, but that's only in the context of a single attribute
type. What happens when you try comparing a case-sensitive string to a
case-insensitive one in Python?



I would say TypeError. But I don't think we should be too strict in 
following the schema, it's too much work for questionable benefit. As 
you pointed out, it might bring problems for which there is no right 
solution.


Honza

--
Jan Cholasta

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

[Freeipa-devel] A new proopsal for Location Based Discovery

[Simo Sorce]

Hello FreeIPA developers and other followers,

we've have thought for quite a while about how to best implement
location based discovery for our clients so that we can easily redirect
group of clients to specific servers in order to better use resources
and keep traffic local to clients.

However although we made some proposal we haven't implemented anything
so far, one reason is that all solution we came up till now were complex
and involved substantial client changes.

I recently came up with a new take on how to resolve the problem, I've
written it up here after some minimal discussion with Petr Spacek and
others.

It is available here:
http://www.freeipa.org/page/V3/DNS_Location_Mechanism


I thinks this proposal stands an actual chance at being implemented and
getting enough client support, mostly because the necessary changes to
existing clients vary from none to very minimal.

This is proposal is not yet definitive, and is open to adjustments.

I've also inlined a copy below for easier commenting.
Please trim out unnecessary text if you choose to reply and comment, and
keep only the relevant sections of text if you comment inline.

Have a good read,
Simo.



A Mechanism to allow for location based discovery 
by Simo Sorce with help from Petr Spacek and others


Forewords 
This is a new proposal (Jan 2013) to support Location Based discovery in
FreeIPA. It was inspired by this earlier proposal made a while ago. The
main difference is that it simplifies the whole management by
eliminating IP subnets and special client code while still maintaining a
great deal of flexibility. The key insight being that different
locations can configure the network to use different FreeIPA DNS
servers, that are local to the location being considered.


Introduction 
Service Discovery is a process whereby a client uses information stored
in the network to find servers that offer a specific service. It is
useful for two reasons. First, it places the information required for
the location of servers in the network, lessening the burden of client
configuration. Second, it gives system and network administrators a
central point of control that can be used to to define an optimized
policy that determines which clients should use which server and in what
order.

A standard for service discovery is defined in RFC 2782. This standard
defines a DNS RR with the mnemonic SRV and usage rules around it. It
allows a client to discover servers that offer a given service over a
given protocol.

A drawback of SRV Records is that it assumes clients know the correct
DNS domain to use as the query target. Without any further information,
the client's options includes using their own DNS domain and the name of
the security domain in which the client operates (such as the domain
name associated to the Kerberos REALM the client refers to). Neither
option is likely to yield optimal results however. One key service
discovery requirement, especially in large distributed enterprises, is
to choose a server that is close to a client. However in many situation
binding the client name to a specific zone that is tied to a physical
location is not possible. And even if it were it would not address the
needs of a roaming client that moves across the networks. We cannot have
the name of a client change when it move across networks as this break
the Kerberos protocol that associates keys to a fixed host name for
Service Principals.

The incompleteness of RFC 2782 is acknowledged by systems such as Active
Directory that contain extra functionality to augment SRV lookups to
make them site aware. The basic idea is to use a target in SRV service
discovery that is specific to a location or "site" in AD parlance.
Unfortunately AD clients rely on additional configureation or side
protocols to determine the client "site" and it is quite specific to
Microsoft technologies so the method they use is not easily portable and
reusable in other contexts nor documented in Standards or informative
IETF RFCs.

This document specifies a protocol for location discovery based
exclusively on DNS. While the protocol itself can be fully implemented
with a normal DNS the FreeIPA mechanism is augmented by additional
'location' awarness and will depend on additional computation done by
the FreeIPA DNS plugins.


The Discovery Protocol 
The main point about this protocol is the recognition that all we really
need is to find a specific (set of) server(s) that a specific client
needs to find. The second point is that the client has 1 bit of
information that is inequivocal: its own fully qualified name. Whether
this is fixed or assigned by the network (via DHCP) is not important,
what matters is that the name univocally identifies this specific host
in the network.

Based on these two points the idea is to make the client query for a
special set of SRV records keyed on the client's own DNS name. From the
client persp

Re: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data

[John Dennis]

On 01/21/2013 01:48 PM, Simo Sorce wrote:


There is also the little issue that we may treat a string in a more
restrictive way than the LDAP schema allow


In an object orientated language restricted behaviors are modeled by 
subclassing.



or we may not have schema loaded yet for example in the installer case


In what circumstance do we not know the schema? Yes, during install the 
schema may not already be present on the server for the attribute in 
question, but that doesn't mean we don't know what the syntax is, rather 
we just have to look for it in a a different place (because by 
definition we have to have the schema available to install it). We 
should never have a situation where we don't know the schema for an 
attribute.


The only issues I've ever seen are attributes whose syntax was 
incorrectly defined (mostly attributes that are logically DN's but were 
defined with string syntax). Fortunately those seem to be rare and are 
currently handled via an "exceptions" table in ldap2.


--
John Dennis 

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] 93 Add custom mapping object for LDAP entry data

[Simo Sorce]

On Mon, 2013-01-21 at 17:46 +0100, Petr Viktorin wrote:
> As for attribute values, you're right that LDAP specifies how they 
> should be compared, but that's only in the context of a single
> attribute 
> type. What happens when you try comparing a case-sensitive string to
> a 
> case-insensitive one in Python?
> 
There is also the little issue that we may treat a string in a more
restrictive way than the LDAP schema allow or we may not have schema
loaded yet for example in the installer case, so if you want to make the
objects 'smart' make sure you do not cause them to be 'too' smart to be
usable :)

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] 351 Installer should not connect to 127.0.0.1

[Rob Crittenden]

Martin Kosek wrote:

On 01/16/2013 03:10 PM, Simo Sorce wrote:

On Wed, 2013-01-16 at 15:01 +0100, Martin Kosek wrote:

On 01/16/2013 02:50 PM, Simo Sorce wrote:

On Wed, 2013-01-16 at 10:42 +0100, Martin Kosek wrote:

IPA installer sometimes tries to connect to the Directory Server
via loopback address 127.0.0.1. However, the Directory Server on
pure IPv6 systems may not be listening on this address. This address
may not even be available.

Rather use the FQDN of the server when connecting to the DS to fix
this issue and make the connection consistent ldapmodify calls which
also use FQDN instead of IP address.

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


Martin,
shouldn't the installer rather always use the ldapi socket ?

Simo.



Probably yes, but the fix would be much more intrusive than the current patch
as we connect to ldap://$HOST:389 all over the installer code. My intention was
to prepare rather a short fix for the upcoming release...


Uhmm wouldn't you just need to replace ldap://$HOST:389 with
ldapi://path ?

However it is understandable to have a short term fix, but can you open
a ticket for the longer term goal of moving away from TCP connections to
LDAPI ones ?

Simo.



Sure. I updated ticket https://fedorahosted.org/freeipa/ticket/3272 which
already plans to fix other inappropriate protocol in installer code.


ACK, pushed to master, ipa-3-1 and ipa-3-0

rob

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

Re: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data

[Petr Viktorin]

On 01/21/2013 04:48 PM, John Dennis wrote:

On 01/16/2013 10:45 AM, Jan Cholasta wrote:

Hi,

this patch adds initial support for custom LDAP entry objects, as
described in .



Just in case you missed it, I added some requirements to the above
design page about making LDAP attributes and their values be "smarter".


It would be nice to discuss these changes on the list, since the 
implementation is already underway...



An LDAP attribute has a syntax defining how comparisons are to be
performed. Python code using standard Python operators, sorting
functions, etc. should "just work" because underneath the object is
aware of it's LDAP syntax.

The same holds true for attribute names, it should "just work" correctly
any place we touch an attribute name because it's an object implementing
the desired comparison and hashing behavior.

Thus the keys in an Entry dict would need to be a new class and the
values would need to be a new class as well. Simple strings do not give
rich enough semantic behavior (we shouldn't be providing this semantic
behavior every place in the code where we touch an attribute name or
value, rather it should just automatically work using standard Python
operators.


I think plain strings are fine for attribute names, as long as the entry 
class handles them correctly. We don't really need to hash or compare 
them outside of an entry. Or at least not enough to warrant a special 
class, IMO.
Of course Entry.keys() and friends should return normalized names that 
would sort/hash correctly.



As for attribute values, you're right that LDAP specifies how they 
should be compared, but that's only in the context of a single attribute 
type. What happens when you try comparing a case-sensitive string to a 
case-insensitive one in Python?


--
Petr³

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

Re: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data

[John Dennis]

On 01/16/2013 10:45 AM, Jan Cholasta wrote:

Hi,

this patch adds initial support for custom LDAP entry objects, as
described in .



Just in case you missed it, I added some requirements to the above 
design page about making LDAP attributes and their values be "smarter".


An LDAP attribute has a syntax defining how comparisons are to be 
performed. Python code using standard Python operators, sorting 
functions, etc. should "just work" because underneath the object is 
aware of it's LDAP syntax.


The same holds true for attribute names, it should "just work" correctly 
any place we touch an attribute name because it's an object implementing 
the desired comparison and hashing behavior.


Thus the keys in an Entry dict would need to be a new class and the 
values would need to be a new class as well. Simple strings do not give 
rich enough semantic behavior (we shouldn't be providing this semantic 
behavior every place in the code where we touch an attribute name or 
value, rather it should just automatically work using standard Python 
operators.


--
John Dennis 

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