Menu
▾
▴
python-ldap-dev
|
From: Torsten K. <pyt...@tk...> - 2008-02-26 09:13:58
|
Hi Guido, > > [...] > > decided to wrap some functions on my own. The result is a branch of > > Apple's PyKerberos, enriched by a kadm5 module, which provides > > basic methods to connect to a remote kerberos admin server and > > maintain principals. [...] > That's great news. I also added some more stuff to pykerberos like > user password changing: > http://trac.macosforge.org/projects/calendarserver/ticket/256 > and very basic GSSWrap/Unwrap support (just enough to talk to > dovecot). Some of this has already been merged on the more-kerberos > branch of pykerberos's SVN but things move slowly there. > We already have a packages in Debian that has these patches and I > could a add yours too if that makes sense. That's a great idea! I'd appreciate too, if some C-regulars would take a look at the code, since this is my first (and probably last ;o) ever project written in C. > > If someone wants to use and/or extend this code, you can check it > > out at: > > > > http://svn.kmrc.de/projects/devel/PyKerberos/trunk > The server doesn't answer - not even to a ping. It should now! We had a defective UPS that pulled down our uplink media transceiver. ;o( If you still encounter problems, please let me know. Regards, Torsten -- The person who's taking you to lunch has no intention of paying. |
|
From: <mi...@st...> - 2003-04-06 15:33:21
|
Peter Hawkins wrote:
>>
> Q: "Why you want to pass a NULL argument to ldap_initialize?"
>
> Short answer: Because you _can_ do it (at least in C)
I have to admit that I'm not in favour of following everything that is
possible with the OpenLDAP C API. Note that the C API is considered to be
highly flawed (see postings on OpenLDAP lists). Especially this particular
feature could cause some FAQs. Before accepting a patch I would really like
to understand the background issues.
> Long answer:
>
> Passing a NULL argument to ldap_initialize, you prevent this code from
> running (excerpt from ldap_initialize/OpenLDAP 2.0.27):
>
> if (url != NULL) {
> rc = ldap_set_option(ld, LDAP_OPT_URI, url);
> if ( rc != LDAP_SUCCESS ) {
> ldap_ld_free(ld, 1, NULL, NULL);
> return rc;
> }
> }
>
> I haven't checked deeply, but it seems to deactivate further URI
> checkins, making the LDAP library assume that you want to connect to a
> local LDAP server.
What does local exactly mean? I guess the LDAP URI is taken from ldap.conf
if uri is NULL. Is that right? If yes, I have to admit that I have some
objections to introduce (implicit) support for ldap.conf in python-ldap.
I posted a message to ope...@Op... to find out......
> It seems to help on some scenarios involving broken
> DNS configs, and it probably (again, I haven't checked) speeds up
> initial bindings even at good configured DNS places, as you don't need to
> make lookups
Well, at some point you have to make a DNS lookup. Where does the speed up
come from?
> It makes difference for me
> (severals seconds waiting for the lookup to timeout -> 0 seconds passing
> NULL), since I cannot modify those (possibly) broken DNS records.
Maybe it's me but I still don't get it. If you have a DNS name of an LDAP
server you're trying to connect the lookup for the IP address has to be
done. If DNS entries are completely broken and you already know the IP
address you can pass this to ldap.initialize().
Or do you suspect the OpenLDAP libs to do reverse lookups in the URL checking?
Did you compile your OpenLDAP with --enable-wrappers (TCP wrapper support)?
This could cause reverse lookups on the server's side. Not sure if it also
has an effect on the client libs.
> Anyway, there's no reason to not been able to send a NULL as URL
> argument to ldap_initialize, since the API _does_ recognize it as a
> valid argument
I have some plans to let python-ldap be just a wrapper above other APIs
(e.g. ADSI on Win32 or maybe a pure Python version). Therefore there MUST be
a good rationale to change semantics of the uri argument of
ldap.initialize() or introduce a dependency on OpenLDAP's ldap.conf.
>(in fact OpenLDAP's client
> tools use NULL as the default argument to ldap_initialize if you don't
> specify -h or -H).
I guess that's where ldap.conf is used.
> Of course, if Michael has a more deep view of OpenLDAP internals than I
No, I don't have more insight. In fact I'm not very familiar with the C part
of python-ldap which is hard to maintain for me since David Leonard does not
have time to spent anymore. Contributions welcome (e.g. support for extended
controls).
> I can keep applying patches.
Instead you could derive from ldap.ldapobject.LDAPObject and do the host
lookup once(!) in the __init__() method passing an IP address to underlying
_ldap.initialize(). Or better rewrite your LDAP applications to keep
persistent connections. See ldap.ldapobject.ReconnectLDAPObject for a
pickable version of LDAPObject.
Ciao, Michael.
|
|
From: Ricardo J. C. <ri...@co...> - 2003-04-10 16:27:12
|
On Sun, Apr 06, 2003 at 05:33:16PM +0200, Michael Ströder wrote:
> >Passing a NULL argument to ldap_initialize, you prevent this code from
> >running (excerpt from ldap_initialize/OpenLDAP 2.0.27):
> >
> > if (url != NULL) {
> > rc = ldap_set_option(ld, LDAP_OPT_URI, url);
> > if ( rc != LDAP_SUCCESS ) {
> > ldap_ld_free(ld, 1, NULL, NULL);
> > return rc;
> > }
> > }
> >
> >I haven't checked deeply, but it seems to deactivate further URI
> >checkins, making the LDAP library assume that you want to connect to a
> >local LDAP server.
>
> What does local exactly mean? I guess the LDAP URI is taken from ldap.conf
> if uri is NULL. Is that right? If yes, I have to admit that I have some
> objections to introduce (implicit) support for ldap.conf in python-ldap.
Ok. Now I've checked deeply :-) Note that I wasn't thinking of speaking
truth, but just making some guesses looking at ldap_initialize and my
practical experience (in fact, I was expecting to be corrected, as I
couldn't explain the strange behaviour). Now, there's how this works:
* If you pass some string as "url" to ldap_initialize, then it
calls ldap_set_option and sets LDAP_INT_GLOBAL_OPT()->ldo_defludp
with "url" (or "urls", if you have more than one).
* If you pass NULL as "url" to ldap_initialize, it doesn't call
ldap_set_option, and so you get the default value. If we look at
libraries/libldap/init.c:
void ldap_int_initialize_global_options(...) {
...
...
ldap_url_parselist(&gopts->ldo_defludp, "ldap://localhost/");
...
...
}
This (if I've read ldap_url_parselist well) loads
"ldap://localhost/" as the default value.
So, ldap_initialize(&ldp, NULL) is the same (to all effects) that
ldap_initialize(&ldp, "ldap://localhost/"). Of course, that doesn't
explain my previous problems with LDAP lookups (again, that problems
_seemed_ as DNS lookup timeouts, I'm not 100% sure).
Oddly enough, I've those problems no more :-? in any of the three
machines I've tried, including two of them which were showing thatu
problem. I know that both of them was upgraded to Debian Testing
recently, so I can't provide info about OpenLDAP versions. :-/
> Well, at some point you have to make a DNS lookup. Where does the speed up
> come from?
I still don't know (now I'm more confused). Any:
ldapsearch -h SOME_NAME_FOR_LOCAL_LDAP_HOST ...........
made me wait several seconds until some timeout (even "localhost"),
while:
ldapsearch ............
didn't. But now that I think about it, I'm not the only admin on those
machines, and maybe someone played tricks with /etc/ldap/ldap.conf
> Or do you suspect the OpenLDAP libs to do reverse lookups in the URL
> checking?
>
> Did you compile your OpenLDAP with --enable-wrappers (TCP wrapper support)?
> This could cause reverse lookups on the server's side. Not sure if it also
> has an effect on the client libs.
That's what I was suspecting the first time, but I discarded it. A
change in client side's options shouldn't affect server's behaviour on
doing reverses.
In fact, haven't read more deeply the library code I was thinking at
that moment on some kind of "direct access" (ie: UNIX sockets vs. TCP
sockets).
> >Anyway, there's no reason to not been able to send a NULL as URL
> >argument to ldap_initialize, since the API _does_ recognize it as a
> >valid argument
>
> I have some plans to let python-ldap be just a wrapper above other APIs
> (e.g. ADSI on Win32 or maybe a pure Python version). Therefore there MUST
> be a good rationale to change semantics of the uri argument of
> ldap.initialize() or introduce a dependency on OpenLDAP's ldap.conf.
Well, a NULL url seems to mean "get the default server URL, whatever
it is", and it seems like a reasonable semantic, since you can't define
default arguments on C callables. Anyway, looking at current OpenLDAP
stable implementation (2.0.27, as I said), the library sets some internal
defaults (including ldo_defludp = "http://localhost/") before looking into
ldap.conf (no ldap.conf dependency at all).
> >Of course, if Michael has a more deep view of OpenLDAP internals than I
Note that I wasn't looking for any type of offence. I regretted about
this particular statement after sending the mail.
> No, I don't have more insight. In fact I'm not very familiar with the C
> part of python-ldap which is hard to maintain for me since David Leonard
> does not have time to spent anymore. Contributions welcome (e.g. support
> for extended controls).
Mmh... I can help if you need someone doing the C part. I'm somewhat
experienced dealing with C/C++ extending/embedding Python :-)
> >I can keep applying patches.
>
> Instead you could derive from ldap.ldapobject.LDAPObject and do the host
> lookup once(!) in the __init__() method passing an IP address to underlying
> _ldap.initialize(). Or better rewrite your LDAP applications to keep
> persistent connections. See ldap.ldapobject.ReconnectLDAPObject for a
> pickable version of LDAPObject.
The actual lookup is delayed until ldap_bind :-), and I dit it twice.
Anyway, this is not a problem now.
> Ciao, Michael.
Regards,
Ricardo
|
|
From: <mi...@st...> - 2003-04-10 20:43:58
|
Ricardo Javier Cardenes wrote: > > Ok. Now I've checked deeply :-) Great. I didn't get a response on the openldap-users list up to now... > So, ldap_initialize(&ldp, NULL) is the same (to all effects) that > ldap_initialize(&ldp, "ldap://localhost/"). Well, this could be achieved by just patching ldap.initialize() or LDAPObject.__init__(). There might be valid reasons to do so. I'll think about it. > Of course, that doesn't explain my previous problems with LDAP lookups > [..] > Oddly enough, I've those problems no more :-? Glad to hear that. ;-) >>>Of course, if Michael has a more deep view of OpenLDAP internals than I > > Note that I wasn't looking for any type of offence. I regretted about > this particular statement after sending the mail. No problem at all. >>No, I don't have more insight. In fact I'm not very familiar with the C >>part of python-ldap which is hard to maintain for me since David Leonard >>does not have time to spent anymore. Contributions welcome (e.g. support >>for extended controls). > > Mmh... I can help if you need someone doing the C part. I'm somewhat > experienced dealing with C/C++ extending/embedding Python :-) I'd really appreciate your help. Look at the TODO file. > Anyway, this is not a problem now. So Peter can close the Debian bug and we'll meet at the python-ldap-dev list... Ciao, Michael. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X