Re: [Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data
On 01/16/2013 10:45 AM, Jan Cholasta wrote: Hi, this patch adds initial support for custom LDAP entry objects, as described in http://freeipa.org/page/V3/LDAP_code. 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 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] 93 Add custom mapping object for LDAP entry data
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 http://freeipa.org/page/V3/LDAP_code. 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] 351 Installer should not connect to 127.0.0.1
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
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
[Freeipa-devel] A new proopsal for Location Based Discovery
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
