Menu
▾
▴
python-ldap-dev
|
From: Jens V. <je...@zo...> - 2002-04-30 19:01:01
|
hi everyone, i had no idea that this ever worked, but apparently (i verified it with python-ldap 1.10alpha3) ldap.open used to accept a hostname string as argument with more than one LDAP host, separated by whitespace. this worked in a failover fashion where if one became unavailable the next one would be used to execute queries. i am noticing that this no longer works on 2.0. is this (now that i know about it...) useful feature going to be available again at some point? (either in ldap.open or through ldap.initialize) jens |
|
From: <mi...@st...> - 2002-05-01 16:37:19
|
Jens Vagelpohl wrote: > > i had no idea that this ever worked, but apparently (i verified it with > python-ldap 1.10alpha3) ldap.open used to accept a hostname string as > argument with more than one LDAP host, separated by whitespace. this > worked in a failover fashion where if one became unavailable the next > one would be used to execute queries. 1. You have to decide what you want. You requested the old "parameter signature" for ldap.open(). You remember? Think of defining the port number... 2. I'd recommend you drop support for old python-ldap and use ldap.initialize() directly. That's far more powerful anyway. Hmm, I would have to remove/modify the is_ldap_url(uri) in the wrapper function for handling the space separated list. But that's least of a problem. 3. IMHO it can't be used for fail-over. AFAIK simply the connection is established to the first host reachable. You could argue that it works kinda fail-over-like if you re-open the LDAP connection for the requests all the time. But if you have a persistent connection you have to implement fail-over by catching ldap.SERVER_DOWN. (I'm currently thinking about sub-classing ldapobject.LDAPObject for this purpose. Note that fail-over means repeating the whole connection-establishment sequence after connecting to the replica). Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-05-01 17:21:49
|
>> i had no idea that this ever worked, but apparently (i verified it with >> python-ldap 1.10alpha3) ldap.open used to accept a hostname string as >> argument with more than one LDAP host, separated by whitespace. this >> worked in a failover fashion where if one became unavailable the next >> one would be used to execute queries. > > 1. You have to decide what you want. You requested the old "parameter > signature" for ldap.open(). You remember? Think of defining the port > number... this actually doesn't have anything to do with my earlier complaints about ldap.open. i'm just saying that apparently back in the 1.10 days ldap.open never checked the parameter and passed it straight to the ldap libraries, which would interpret it as "if the first server is dead just use the second". > 2. I'd recommend you drop support for old python-ldap and use > ldap.initialize() directly. That's far more powerful anyway. Hmm, I would > have to remove/modify the is_ldap_url(uri) in the wrapper function for > handling the space separated list. But that's least of a problem. my software is written so that it attempts to determine what version of python-ldap is in use and behave accordingly. anything that is not version 2 and above uses ldap.open, 2.x uses ldap.initialize. simply dropping support for ldap.open is not an option, most everyone i know still uses 1. 10alpha3. but apart from that' that's not really my point. i'm just wondering if this "server fallback" behavior could find its way back into python-ldap2, regardless of connection building method used, because it seems it is supported by the OpenLDAP libraries and i am thinking it is a useful behavior. that's all. > 3. IMHO it can't be used for fail-over. AFAIK simply the connection is > established to the first host reachable. You could argue that it works > kinda fail-over-like if you re-open the LDAP connection for the requests > all the time. But if you have a persistent connection you have to > implement fail-over by catching ldap.SERVER_DOWN. (I'm currently thinking > about sub-classing ldapobject.LDAPObject for this purpose. Note that > fail-over means repeating the whole connection-establishment sequence > after connecting to the replica). it's true that the first available connection is used, and my software actually does re-open the connection every single time. so for this use case it does work like failover. if i remember correctly i had at one time tried to come up with a way to test whether a given LDAP connection object was still good for use, but could not find anything that would not already involve making LDAP queries. so i assumed the difference in overhead was not that large. let me know if i am way off-base here, i could be talking out of my rear end. i have never experimented with long-lived connections. i am all for improving performance, if you can show me a good way to test existing connection objects and tell me that it is indeed faster to do it, i'm all ears. jens |
|
From: <mi...@st...> - 2002-05-01 17:37:40
Attachments:
smime.p7s
|
Jens Vagelpohl wrote: >>> i had no idea that this ever worked, but apparently (i verified it >>> with python-ldap 1.10alpha3) ldap.open used to accept a hostname >>> string as argument with more than one LDAP host, separated by >>> whitespace. this worked in a failover fashion where if one became >>> unavailable the next one would be used to execute queries. >> >> >> 1. You have to decide what you want. You requested the old "parameter >> signature" for ldap.open(). You remember? Think of defining the port >> number... > > this actually doesn't have anything to do with my earlier complaints > about ldap.open. It has. > i'm just saying that apparently back in the 1.10 days > ldap.open never checked the parameter and passed it straight to the ldap > libraries, which would interpret it as "if the first server is dead just > use the second". Well, we can implement it like this. But it contradicts your inquiry for a parameter signature like described in the documentation. --------------------- snip ----------------------- open(host [, port=PORT]) Opens a new connection with an LDAP server, and return an LDAP object (see 1.1.4) used to perform operations on that server. host is a string containing solely the host name. port is an integer specifying the port where the LDAP server is listening (default is 389). Note: Using this function is deprecated. --------------------- snip ----------------------- We can either 1. change the docs and pass string-parameter _host_ to OpenLDAP's ldap_open() function and drop parameter _port_ or 2. comply to the docs which means not supporting the multiple-hosts-in-space-separated-list parameter. If you don't get the difference I'm pretty sure that you've never used to connect to a LDAP server running on "non-standard" port... >> 2. I'd recommend you drop support for old python-ldap and use >> ldap.initialize() directly. > > my software is written so that it attempts to determine what version of > python-ldap is in use and behave accordingly. I did that in former versions of web2ldap but dropped support for python-ldap 1.x because it's getting too complex if you want to do that completely (referrals, etc.). Also python-ldap does not support LDAPv3 which has some serious implications if you take RFC2251 ff. seriously (e.g. character set T.61 for LDAPv2 instead of UTF-8). > i'm just > wondering if this "server fallback" behavior could find its way back > into python-ldap2, regardless of connection building method used, > because it seems it is supported by the OpenLDAP libraries and i am > thinking it is a useful behavior. that's all. Someone has to decide on that. See above. > if i remember correctly i had at one time tried to come up with a way to > test whether a given LDAP connection object was still good for use, but > could not find anything that would not already involve making LDAP queries. Yes, you have to try a LDAPRequest and catch ldap.SERVER_DOWN. > i have > never experimented with long-lived connections. i am all for improving > performance, if you can show me a good way to test existing connection > objects and tell me that it is indeed faster to do it, i'm all ears. Well, if you're after performance you should work with persistent connections. Especially for web2ldap it was a great performance boost since web2ldap does a lot of special stuff after establishing the connection. Doing this for each request is a performance nightmare. Think of negotiating LDAP protocol version, evaluating RootDSE attributes, more complex bind operations, etc. Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-05-02 12:32:53
|
> 1. change the docs and pass string-parameter _host_ to OpenLDAP's > ldap_open() function and drop parameter _port_ or the space-separated host list was only used in place of the first argument, "host". i am not sure if you were still able to pass a "port" parameter or what would happen if you did. > 2. comply to the docs which means not supporting the > multiple-hosts-in-space-separated-list parameter. comply to which docs? the docs that came with python-ldap 1.10? i have a feeling that the author might not have realized that you can send space-separated host names in the "host" portion of the argument list. > If you don't get the difference I'm pretty sure that you've never used to > connect to a LDAP server running on "non-standard" port... well of course i have ;) all my products allow selecting nonstandard ports, too. > I did that in former versions of web2ldap but dropped support for > python-ldap 1.x because it's getting too complex if you want to do that > completely (referrals, etc.). Also python-ldap does not support LDAPv3 > which has some serious implications if you take RFC2251 ff. seriously (e. > g. character set T.61 for LDAPv2 instead of UTF-8). well, my products lack the complexity to really be worried about that. no one has ever come to me and said they couldn't get things to work using referrals :) and i don't think i'll try to provide that ability. >> if i remember correctly i had at one time tried to come up with a way to >> test whether a given LDAP connection object was still good for use, but >> could not find anything that would not already involve making LDAP >> queries. > > Yes, you have to try a LDAPRequest and catch ldap.SERVER_DOWN. is there a suitable and simple LDAP request that would work on most servers without knowing what the tree looks like? > > i have >> never experimented with long-lived connections. i am all for improving >> performance, if you can show me a good way to test existing connection >> objects and tell me that it is indeed faster to do it, i'm all ears. > > Well, if you're after performance you should work with persistent > connections. Especially for web2ldap it was a great performance boost > since web2ldap does a lot of special stuff after establishing the > connection. Doing this for each request is a performance nightmare. Think > of negotiating LDAP protocol version, evaluating RootDSE attributes, more > complex bind operations, etc. well, again, my products lack that kind of complexity... i connect, i bind, i might rebind as someone else, i read and i write. then i disconnect. nothing exotic really. jens |
|
From: <mi...@st...> - 2002-05-02 15:53:51
|
Jens Vagelpohl wrote: >> 1. change the docs and pass string-parameter _host_ to OpenLDAP's >> ldap_open() function and drop parameter _port_ or > > the space-separated host list was only used in place of the first argument, > "host". i am not sure if you were still able to pass a "port" parameter > or what would happen if you did. Jens, can you please tell us exactly how the declaration of ldap.open() should look like and how the behaviour should be? I've changed the declaration and behaviour according to your inquiry because you complained about an incompatible change (review thread "signature of ldap.open changed?" started by you). > comply to which docs? the docs that came with python-ldap 1.10? The docs weren't changed since 1.x for ldap.open(). > i have a > feeling that the author might not have realized that you can send > space-separated host names in the "host" portion of the argument list. It's very likely that David did not know about the space-separated multiple host feature. I'm not even sure if it was available in OpenLDAP 1.x or Netscape 3 libs. But he defined the ldap.open() function's interface and old code might be using it. As I understood your former inquiry you relied on this old behaviour of ldap.open(). Now you're requesting a change. >> I did that in former versions of web2ldap but dropped support for >> python-ldap 1.x because it's getting too complex if you want to do >> that completely (referrals, etc.). Also python-ldap does not support >> LDAPv3 which has some serious implications if you take RFC2251 ff. >> seriously (e. >> g. character set T.61 for LDAPv2 instead of UTF-8). > > well, my products lack the complexity to really be worried about that. Not caring about the complexity does not mean the complexity isn't there... >> Yes, you have to try a LDAPRequest and catch ldap.SERVER_DOWN. > > is there a suitable and simple LDAP request that would work on most > servers without knowing what the tree looks like? Read RootDSE on LDAPv3 servers. Well, that means you have to know the protocol version. Also the node of the search root has to be existent. But IMHO you're thinking the wrong way: Just try the LDAPRequest, catch ldap.SERVER_DOWN, re-connect/-bind and re-try same LDAPRequest if necessary. >>> never experimented with long-lived connections. i am all for >>> improving performance, >> >> Well, if you're after performance you should work with persistent >> connections. Especially for web2ldap it was a great performance boost >> since web2ldap does a lot of special stuff after establishing the >> connection. Doing this for each request is a performance nightmare. >> Think of negotiating LDAP protocol version, evaluating RootDSE >> attributes, more complex bind operations, etc. > > well, again, my products lack that kind of complexity... Are you sure? ;-) > i connect, i bind, > i might rebind as someone else, i read and i write. then i disconnect. > nothing exotic really. Not exotical but too many LDAPRequests for being a light-weight authenticating process. Also think of the costs when doing a connect, especially SSL/TLS connection establishment. Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-05-02 16:31:36
|
> Jens, can you please tell us exactly how the declaration of ldap.open() > should look like and how the behaviour should be? > > I've changed the declaration and behaviour according to your inquiry > because you complained about an incompatible change (review thread > "signature of ldap.open changed?" started by you). the declaration of ldap.open doesn't have anything to do with this as far as i know. actually, it now even seems to be supporting two ways to get a connection: ldap.open( 'server:port' ) ldap.open( 'server', port ) the only item (for this discussion) that i am looking it is the string 'host'. i know that under 1.10 i could do.. ldap.open( 'host1 host2 host3' ) assuming they all run on the default port. i'm not interested in non-default ports here. if i execute the same on python2.1 and python-ldap 2.0pre4 i am getting a strange error: ldap.LDAPError: ( 2, 'No such file or directory' ). don't get me wrong, i am not trying to warm over some ldap.open declaration semantics. i'm not even trying to badger anyone into bringing back this type of behavior, i'm just curious if that's something that would be interesting for others and the package as a whole. >> It's very likely that David did not know about the space-separated >> multiple host feature. I'm not even sure if it was available in OpenLDAP >> 1.x or Netscape 3 libs. But he defined the ldap.open() function's >> interface and old code might be using it. > > As I understood your former inquiry you relied on this old behaviour of > ldap.open(). Now you're requesting a change. this whole deal with the space-separated hosts is nothing i ever relied on (because i did not know it even worked at all). it was brought to my attention by someone else who had been doing it previously and it failed after he upgraded python-ldap. i appreciate your comments regarding long-lived connections. i'll start using it when i have time to do more tinkering. jens |
|
From: <mi...@st...> - 2002-05-02 21:33:13
|
Jens Vagelpohl wrote: > ldap.open doesn't have anything to do with this as > far as i know. It has. Please think again. > actually, it now even seems to be supporting two ways to > get a connection: > > ldap.open( 'server:port' ) > ldap.open( 'server', port ) Note: The exact declaration is currently: def open(host,port=389,trace_level=0,trace_file=sys.stdout): > the only item (for this discussion) that i am looking it is the > string 'host'. i know that under 1.10 i could do.. > > ldap.open( 'host1 host2 host3' ) Which is not possible with separate key-word parameter _port_ in function parameter list of ldap.open(). > assuming they all run on the default port. i'm not interested > in non-default ports here. Are you kidding? > don't get me wrong, i am not trying to warm over some ldap.open > declaration semantics. If it's just an interesting thing go and use ldap.initialize() and we'll close this thread. Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-05-02 16:48:08
|
we can close the thread, that's fine. for me it was just an interesting=20= tidbit that someone else revealed to me. i still maintain that the discussion about ldap.open back in january was=20= for totally different reasons and doesn't really have any bearing on = this. jens On Thursday, May 2, 2002, at 12:41 , Michael Str=F6der wrote: > Jens Vagelpohl wrote: > > ldap.open doesn't have anything to do with this as > > far as i know. > > It has. Please think again. > > > actually, it now even seems to be supporting two ways to > > get a connection: > > > > ldap.open( 'server:port' ) > > ldap.open( 'server', port ) > > Note: The exact declaration is currently: > > def open(host,port=3D389,trace_level=3D0,trace_file=3Dsys.stdout): > > > the only item (for this discussion) that i am looking it is the > > string 'host'. i know that under 1.10 i could do.. > > > > ldap.open( 'host1 host2 host3' ) > > Which is not possible with separate key-word parameter _port_ in > function parameter list of ldap.open(). > > > assuming they all run on the default port. i'm not interested > > in non-default ports here. > > Are you kidding? > > > don't get me wrong, i am not trying to warm over some ldap.open > > declaration semantics. > > If it's just an interesting thing go and use ldap.initialize() and > we'll close this thread. > > Ciao, Michael. > |
Thanks for helping keep SourceForge clean.
X