You can subscribe to this list here.
2000 |
Jan
|
Feb
(34) |
Mar
(9) |
Apr
|
May
(2) |
Jun
(14) |
Jul
(67) |
Aug
(34) |
Sep
(5) |
Oct
(20) |
Nov
(22) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(15) |
Feb
(16) |
Mar
(20) |
Apr
(13) |
May
(72) |
Jun
(42) |
Jul
(41) |
Aug
(11) |
Sep
(19) |
Oct
(67) |
Nov
(59) |
Dec
(57) |
2002 |
Jan
(74) |
Feb
(69) |
Mar
(34) |
Apr
(55) |
May
(47) |
Jun
(74) |
Jul
(116) |
Aug
(68) |
Sep
(25) |
Oct
(42) |
Nov
(28) |
Dec
(52) |
2003 |
Jan
(19) |
Feb
(18) |
Mar
(35) |
Apr
(49) |
May
(73) |
Jun
(39) |
Jul
(26) |
Aug
(59) |
Sep
(33) |
Oct
(56) |
Nov
(69) |
Dec
(137) |
2004 |
Jan
(276) |
Feb
(15) |
Mar
(18) |
Apr
(27) |
May
(25) |
Jun
(7) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
(10) |
Nov
(27) |
Dec
(28) |
2005 |
Jan
(22) |
Feb
(25) |
Mar
(41) |
Apr
(17) |
May
(36) |
Jun
(13) |
Jul
(22) |
Aug
(12) |
Sep
(23) |
Oct
(6) |
Nov
(4) |
Dec
|
2006 |
Jan
(11) |
Feb
(3) |
Mar
(5) |
Apr
(22) |
May
(1) |
Jun
(10) |
Jul
(19) |
Aug
(7) |
Sep
(25) |
Oct
(23) |
Nov
(5) |
Dec
(27) |
2007 |
Jan
(25) |
Feb
(17) |
Mar
(44) |
Apr
(8) |
May
(33) |
Jun
(31) |
Jul
(42) |
Aug
(16) |
Sep
(12) |
Oct
(16) |
Nov
(23) |
Dec
(73) |
2008 |
Jan
(26) |
Feb
(6) |
Mar
(46) |
Apr
(17) |
May
(1) |
Jun
(44) |
Jul
(9) |
Aug
(34) |
Sep
(20) |
Oct
(2) |
Nov
(4) |
Dec
(16) |
2009 |
Jan
(14) |
Feb
(3) |
Mar
(45) |
Apr
(52) |
May
(34) |
Jun
(32) |
Jul
(24) |
Aug
(52) |
Sep
(22) |
Oct
(23) |
Nov
(19) |
Dec
(10) |
2010 |
Jan
(10) |
Feb
(13) |
Mar
(22) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(8) |
Aug
(9) |
Sep
(10) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2011 |
Jan
|
Feb
(18) |
Mar
(39) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alain S. <asp...@gm...> - 2007-01-27 11:59:58
|
Yes, we did it ! My test case is working with your CVS ! I put it at the end. And what about the idea to put the try: except ldap.SERVER_DOWN,e: SimpleLDAPObject.unbind_s(self) in the function _ldap_call too ? This will correct also SimpleLDAPObject ? import sys, os, time import ldap, ldapurl host=3D'localhost' port=3D389 who=3D'cn=3Dnobody,cn=3Dinternal,dc=3Dasxnet,dc=3Dloc' cred=3D'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' dn=3D'dc=3Dasxnet,dc=3Dloc' def ldap_service(action): os.system('/kolab/bin/openpkg rc openldap %s' % action) if action.endswith('start'): time.sleep(1) def check_connection(): whoami=3Dl.whoami_s() print 'whoami', whoami # this search dont give any result as anonymous, but well if loggged as nobody #result=3Dl.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(member=3Dcn=3Ddomain.maintainer mydomain.loc,cn=3Dinternal,dc=3Dasxnet,dc=3Dloc)") #print 'search', result ldap_url=3Dldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn)) ldap_url.applyDefaults({ 'who': who, 'cred' : cred, }) # to be sure the server is up ldap_service('stop') ldap_service('start') l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl(),1) # I dont use ReconnectLDAPObject ! l.simple_bind_s(ldap_url.who, ldap_url.cred) check_connection() print 'Wait 120s' time.sleep(120) check_connection() print 'restart service' ldap_service('stop') ldap_service('start') check_connection() print 'stop service' ldap_service('stop') try: check_connection() except ldap.SERVER_DOWN: print 'check failed, OK' print 'restart service' ldap_service('start') check_connection() On 1/27/07, Michael Str=F6der <mi...@st...> wrote: > Alain Spineux wrote: > > > > The problem is the failed statement has initiated a new connection > > (when the server is down) > > calling initialize (that doesn't fail) and bind that fail but is in a > > try: except: block in ReconnectLDAPObject.reconnect() ! > > Then the server restart and the next statement get advantages of the > > work done initialize > > Yes. Inspired by you mentioning libldap I remembered that unbind_s() > should be called when handling ldap.SERVER_DOWN exception to completely > drop the whole connection context. > > Please test the version I've committed some minutes ago. > Thanks again. > > Ciao, Michael. > --=20 -- Alain Spineux aspineux gmail com May the sources be with you |
From: <mi...@st...> - 2007-01-27 01:01:24
|
Alain Spineux wrote: > > The problem is the failed statement has initiated a new connection > (when the server is down) > calling initialize (that doesn't fail) and bind that fail but is in a > try: except: block in ReconnectLDAPObject.reconnect() ! > Then the server restart and the next statement get advantages of the > work done initialize Yes. Inspired by you mentioning libldap I remembered that unbind_s() should be called when handling ldap.SERVER_DOWN exception to completely drop the whole connection context. Please test the version I've committed some minutes ago. Thanks again. Ciao, Michael. |
From: Alain S. <asp...@gm...> - 2007-01-27 00:57:49
|
Yes I got it ! The problem is the failed statement has initiated a new connection (when the server is down) calling initialize (that doesn't fail) and bind that fail but is in a try: except: block in ReconnectLDAPObject.reconnect() ! Then the server restart and the next statement get advantages of the work done initialize # first stop the service ldap_service('stop') # initiate a connection l=3Dldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObj= ect ! try: l.simple_bind_s(ldap_url.who, ldap_url.cred) except ldap.SERVER_DOWN: pass # bind fail like in ReconnectLDAPObject.reconnect() ldap_service('start') check_connection() # that return an empty string The probleme is initialize don't initialize any connection ! from "man 3 ldap" : The basic interaction is as follows. A session handle is creat= ed using ldap_initialize(3) and set the protocol version to 3 by calli= ng ldap_set_option(3). The underlying session is established first ope= r- ation is issued. This would generally be a Start TLS or Bind oper= a- tion. The problem is that the first operation after Initialize will never put the connection into failing state when server is down! The problem is probably into libldap into the "auto connect at first operation" like described into man 3 ldap This let us do something like l=3Dldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObj= ect ! while True: try: l.simple_bind_s(ldap_url.who, ldap_url.cred) except ldap.SERVER_DOWN: time.sleep(1) else: break print 'Connected' I don't know if this is a feature or a bug into libldap ! Then the logic of my patch look to be the good one. I still need to verify it once more. I go to sleep now On 1/26/07, Michael Str=F6der <mi...@st...> wrote: > Alain Spineux wrote: > > When testing ReconnectLDAPObject I found a bug. > > The object doesn't reconnect after a main failure ! > > [..] > > I thing the main probleme is here ! > > Look ! > > Yes, I can reproduce your observation. Thanks for pointing it out. > > > l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) > > print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectCla= ss=3D*)") > > > > this work too ! And don't give any error while their is no bind ! > > work like if l.simple_bind_s('', '') where used just before the search = ! > > Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY > send a LDAP request without prior bind request. > > > I wrote a patch but this is only a workaround that detect the main > > failure, set a flag and force a reconnect before any request if the > > flag is set. > > Where's the patch? Can't figure out why it does not send the formerly > sent bind request. It has all the data around. And if you take the > server down it will re-send the bind request. > > Ciao, Michael. > --=20 -- Alain Spineux aspineux gmail com May the sources be with you |
From: <mi...@st...> - 2007-01-27 00:40:13
|
Alain Spineux wrote: >> >> Where's the patch? > This is still only a workin "draft" I need to reread it's logic, > anyway I add it at the end Got your point now. But still I don't find an elegant solution without having to handle a 'disconnected' flag in several methods. > I thing libldap open a new connection, but libldap dont store anything > about the credential and then cannot authenticate with the good user ! > I will try to reproduce this in C with libc Yes, it's a bug in ReconnectLDAPObject. It doesn't have anything to do with libldap. Ciao, Michael. |
From: Alain S. <asp...@gm...> - 2007-01-26 23:23:02
|
On 1/26/07, Michael Str=F6der <mi...@st...> wrote: > Alain Spineux wrote: > > When testing ReconnectLDAPObject I found a bug. > > The object doesn't reconnect after a main failure ! > > [..] > > I thing the main probleme is here ! > > Look ! > > Yes, I can reproduce your observation. Thanks for pointing it out. Don't forget we are on the same boat Captain ! :-) > > > l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) > > print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectCla= ss=3D*)") > > > > this work too ! And don't give any error while their is no bind ! > > work like if l.simple_bind_s('', '') where used just before the search = ! > > Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY > send a LDAP request without prior bind request. > > > I wrote a patch but this is only a workaround that detect the main > > failure, set a flag and force a reconnect before any request if the > > flag is set. > > Where's the patch? This is still only a workin "draft" I need to reread it's logic, anyway I add it at the end > Can't figure out why it does not send the formerly > sent bind request. It has all the data around. And if you take the > server down it will re-send the bind request. The trick is it doesn't try to reconnect AFTER the main failure (or BEFORE the next statement) ! Because the first try (of the next ldap statement) doesn't generate any error, it doesn't try to reconnect and then give the answer as is ! But this is the answer it got like an unauthenticated user ! Look, this is the tcpdump of the last statement ! 00:14:21.109514 IP 127.0.0.1.36250 > 127.0.0.1.ldap: S 1795648490:1795648490(0) win 00:14:21.110352 IP 127.0.0.1.ldap > 127.0.0.1.36250: S 1793421325:1793421325(0) ack 1795648491 win 32768 <mss 16396,sackOK,timestamp 516494160 516494159,nop,wscale 7> 00:14:21.110430 IP 127.0.0.1.36250 > 127.0.0.1.ldap: . ack 1 win 257 <nop,nop,timestamp 516494160 516494160> You can identify the well known 3-way handshaking ! This is a new connectio= n ! I thing libldap open a new connection, but libldap dont store anything about the credential and then cannot authenticate with the good user ! I will try to reproduce this in C with libc Here is the patch (including my whoami_s() ) *** ldapobject.py.disconnet Fri Jan 26 22:22:57 2007 --- ldapobject.py.orig Fri Jan 26 13:42:59 2007 *************** *** 678,684 **** self._retry_delay =3D retry_delay self._start_tls =3D 0 self._reconnects_done =3D 0L - self._disconnected=3DTrue def __getstate__(self): """return data representation for pickled object""" --- 678,683 ---- *************** *** 723,730 **** self.start_tls_s() # Repeat last simple or SASL bind self._apply_last_bind() ! except Exception, e: ! self._disconnected=3DTrue if __debug__ and self._trace_level>=3D1: self._trace_file.write('*** %d. reconnect to %s failed\n' % ( self._retry_max-reconnect_counter+1,uri --- 722,728 ---- self.start_tls_s() # Repeat last simple or SASL bind self._apply_last_bind() ! except: if __debug__ and self._trace_level>=3D1: self._trace_file.write('*** %d. reconnect to %s failed\n' % ( self._retry_max-reconnect_counter+1,uri *************** *** 736,742 **** self._trace_file.write('=3D> delay %s...\n' % (self._retry_dela= y)) time.sleep(self._retry_delay) else: - self._disconnected=3DFalse if __debug__ and self._trace_level>=3D1: self._trace_file.write('*** %d. reconnect to %s successful, last operation will be repeated\n' % ( self._retry_max-reconnect_counter+1,uri --- 734,739 ---- *************** *** 745,762 **** break def _apply_method_s(self,func,*args,**kwargs): ! if self._disconnected: self.reconnect(self._uri) # Re-try last operation return func(self,*args,**kwargs) - else: - try: - return func(self,*args,**kwargs) - except ldap.SERVER_DOWN: - # Reconnect - self.reconnect(self._uri) - # Re-try last operation - return func(self,*args,**kwargs) def set_option(self,option,invalue): self._options[option] =3D invalue --- 742,754 ---- break def _apply_method_s(self,func,*args,**kwargs): ! try: ! return func(self,*args,**kwargs) ! except ldap.SERVER_DOWN: ! # Reconnect self.reconnect(self._uri) # Re-try last operation return func(self,*args,**kwargs) def set_option(self,option,invalue): self._options[option] =3D invalue *************** *** 764,772 **** def simple_bind_s(self,*args,**kwargs): self._last_bind =3D (self.simple_bind_s,args,kwargs) ! result=3DSimpleLDAPObject.simple_bind_s(self,*args,**kwargs) ! self._disconnected=3DFalse ! return result def start_tls_s(self): res =3D SimpleLDAPObject.start_tls_s(self) --- 756,762 ---- def simple_bind_s(self,*args,**kwargs): self._last_bind =3D (self.simple_bind_s,args,kwargs) ! return SimpleLDAPObject.simple_bind_s(self,*args,**kwargs) def start_tls_s(self): res =3D SimpleLDAPObject.start_tls_s(self) *************** *** 778,786 **** sasl_interactive_bind_s(who, auth) -> None """ self._last_bind =3D (self.sasl_interactive_bind_s,args,kwargs) ! result=3DSimpleLDAPObject.sasl_interactive_bind_s(self,*args,**kwargs= ) ! self._disconnected=3DFalse ! return result def add_ext_s(self,*args,**kwargs): return self._apply_method_s(SimpleLDAPObject.add_ext_s,*args,**kwargs= ) --- 768,774 ---- sasl_interactive_bind_s(who, auth) -> None """ self._last_bind =3D (self.sasl_interactive_bind_s,args,kwargs) ! return SimpleLDAPObject.sasl_interactive_bind_s(self,*args,**kwargs) def add_ext_s(self,*args,**kwargs): return self._apply_method_s(SimpleLDAPObject.add_ext_s,*args,**kwargs= ) *************** *** 800,808 **** def search_ext_s(self,*args,**kwargs): return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwa= rgs) - def whoami_s(self,*args,**kwargs): - return self._apply_method_s(SimpleLDAPObject.whoami_s,*args,**kwargs) - class SmartLDAPObject(ReconnectLDAPObject): """ --- 788,793 ---- -- Alain Spineux aspineux gmail com May the sources be with you |
From: <mi...@st...> - 2007-01-26 22:44:34
|
Alain Spineux wrote: > When testing ReconnectLDAPObject I found a bug. > The object doesn't reconnect after a main failure ! > [..] > I thing the main probleme is here ! > Look ! Yes, I can reproduce your observation. Thanks for pointing it out. > l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) > print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)") > > this work too ! And don't give any error while their is no bind ! > work like if l.simple_bind_s('', '') where used just before the search ! Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY send a LDAP request without prior bind request. > I wrote a patch but this is only a workaround that detect the main > failure, set a flag and force a reconnect before any request if the > flag is set. Where's the patch? Can't figure out why it does not send the formerly sent bind request. It has all the data around. And if you take the server down it will re-send the bind request. Ciao, Michael. |
From: Alain S. <asp...@gm...> - 2007-01-26 22:05:13
|
Thanks for these useful details On 1/26/07, Michael Str=F6der <mi...@st...> wrote: > Alain Spineux wrote: > > > > I use whoami_s() like a ping, to know if the server is still up. > > This requires support for "Who am I?" extended operation (see RFC 4532) > at the server's side which is not implemented in all server products. > > > Do you know a better way ? > > If it's an LDAPv3 server you could simply read the rootDSE. > Some servers implement special monitoring entries (e.g. cn=3DMonitor > implemented by OpenLDAP's back-monitor). > > You have to think about detailed error handling. > > But this all depends on which requirements you have. > How general? How many details? > > Ciao, Michael. > --=20 -- Alain Spineux aspineux gmail com May the sources be with you |
From: Alain S. <asp...@gm...> - 2007-01-26 21:39:40
|
When testing ReconnectLDAPObject I found a bug. The object doesn't reconnect after a main failure ! If I shutdown the ldap server and try a request, I get a ldap.SERVER_DOWN, this is correct. (this is what I call the main failure) But if I restart the server, and retry the same request (with the same object), I get an empty answer but no error! I'm expecting a correct answer or an error (exception)! I have a full script that show the problem at the end. It look the object is in an incoherent state after the main failure, in fact in an unauthenticated state ! I thing this is a problem with libldap or openldap, not with python code. I thing the main probleme is here ! Look ! l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) l.simple_bind_s('cn=nobody,cn=internal,dc=asxnet,dc=loc', '***********') print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)") works and return all object anonymous can get, but l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)") this work too ! And don't give any error while their is no bind ! work like if l.simple_bind_s('', '') where used just before the search ! I wrote a patch but this is only a workaround that detect the main failure, set a flag and force a reconnect before any request if the flag is set. Here is the output of my test case I use a modified python-ldap, that include the patch posted in my previous post that enable reconnect to work with whoami_s() -- without debuging -- OpenPKG: stop: openldap. OpenPKG: start: openldap. Connected whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc OpenPKG: stop: openldap. OpenPKG: start: openldap. whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc reconnect ok OpenPKG: stop: openldap. ok: ldap.SERVER_DOWN, server is realy down OpenPKG: start: openldap. whoami It look i'am connected, but like anonymous -- with debuging -- OpenPKG: stop: openldap. OpenPKG: start: openldap. *** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{}) *** ldap://localhost:389 - ReconnectLDAPObject.simple_bind (('cn=nobody,cn=internal,dc=asxnet,dc=loc', 'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{}) *** ldap://localhost:389 - ReconnectLDAPObject.result3 ((1, 1, -1),{}) Connected *** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{}) whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc OpenPKG: stop: openldap. OpenPKG: start: openldap. *** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{}) *** Try 1. reconnect to ldap://localhost:389... *** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{}) *** ldap://localhost:389 - ReconnectLDAPObject.simple_bind (('cn=nobody,cn=internal,dc=asxnet,dc=loc', 'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{}) *** ldap://localhost:389 - ReconnectLDAPObject.result3 ((1, 1, -1),{}) *** 1. reconnect to ldap://localhost:389 successful, last operation will be repeated *** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{}) whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc reconnect ok OpenPKG: stop: openldap. *** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{}) *** Try 1. reconnect to ldap://localhost:389... *** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{}) *** ldap://localhost:389 - ReconnectLDAPObject.simple_bind (('cn=nobody,cn=internal,dc=asxnet,dc=loc', 'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{}) *** 1. reconnect to ldap://localhost:389 failed ok: ldap.SERVER_DOWN, server is realy down OpenPKG: start: openldap. *** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{}) whoami It look i'am connected, but like anonymous ---- and finaly my test case ---- import sys, os, time import ldap, ldapurl host='localhost' port=389 who='cn=nobody,cn=internal,dc=asxnet,dc=loc' cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' dn='dc=asxnet,dc=loc' def ldap_service(action): os.system('/kolab/bin/openpkg rc openldap %s' % action) if action.endswith('start'): time.sleep(1) def check_connection(): whoami=l.whoami_s() print 'whoami', whoami # this search dont give any result as anonymous, but well if loggged as nobody #result=l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(member=cn=domain.maintainer mydomain.loc,cn=internal,dc=asxnet,dc=loc)") #print 'search', result ldap_url=ldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn)) ldap_url.applyDefaults({ 'who': who, 'cred' : cred, }) # to be sure the server is up ldap_service('stop') ldap_service('start') l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl(), 1) # l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl()) l.simple_bind_s(ldap_url.who, ldap_url.cred) print 'Connected' check_connection() ldap_service('stop') ldap_service('start') try: check_connection() except ldap.SERVER_DOWN: print "Error: ldap.SERVER_DOWN !" else: print "reconnect ok" ldap_service('stop') try: check_connection() except ldap.SERVER_DOWN: print "ok: ldap.SERVER_DOWN, server is realy down" ldap_service('start') check_connection() print "It look i'am connected, but like anonymous" import sys, os, time import ldap, ldapurl host='localhost' port=389 who='cn=nobody,cn=internal,dc=asxnet,dc=loc' cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' dn='dc=asxnet,dc=loc' def ldap_service(action): os.system('/kolab/bin/openpkg rc openldap %s' % action) if action.endswith('start'): time.sleep(1) def check_connection(): #print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(member=cn=domain.maintainer mydomain.loc,cn=internal,dc=asxnet,dc=loc)") print 'whoami', l.whoami_s() ldap_url=ldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn)) ldap_url.applyDefaults({ 'who': who, 'cred' : cred, }) ldap_service('stop') ldap_service('start') l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl()) # l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl()) l.simple_bind_s(ldap_url.who, ldap_url.cred) print 'Connected' check_connection() ldap_service('stop') ldap_service('start') try: check_connection() except ldap.SERVER_DOWN: print "Error: ldap.SERVER_DOWN !" ldap_service('stop') try: check_connection() except ldap.SERVER_DOWN: print "Ok: ldap.SERVER_DOWN" ldap_service('start') check_connection() ANY Comments ? -- Alain Spineux aspineux gmail com May the sources be with you |
From: <mi...@st...> - 2007-01-26 14:26:31
|
Alain Spineux wrote: > > I use whoami_s() like a ping, to know if the server is still up. This requires support for "Who am I?" extended operation (see RFC 4532) at the server's side which is not implemented in all server products. > Do you know a better way ? If it's an LDAPv3 server you could simply read the rootDSE. Some servers implement special monitoring entries (e.g. cn=Monitor implemented by OpenLDAP's back-monitor). You have to think about detailed error handling. But this all depends on which requirements you have. How general? How many details? Ciao, Michael. |
From: <mi...@st...> - 2007-01-26 14:13:42
|
Alain Spineux wrote: > ReconnectLDAPObject.whoami_s() is not protected again disconnection ! > Maybe someone forgot to redefine this method into ReconnectLDAPObject ! Thanks for pointing this out. I've committed it to CVS. Please test. Ciao, Michael. |
From: Alain S. <asp...@gm...> - 2007-01-26 13:47:40
|
ReconnectLDAPObject.whoami_s() is not protected again disconnection ! Maybe someone forgot to redefine this method into ReconnectLDAPObject ! Here is the patch *** /usr/lib/python2.4/site-packages/ldap/ldapobject.py.orig Fri Jan 26 13:42:59 2007 --- /usr/lib/python2.4/site-packages/ldap/ldapobject.py Fri Jan 26 13:46:12 2007 *************** *** 788,793 **** --- 788,796 ---- def search_ext_s(self,*args,**kwargs): return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs) + def whoami_s(self,*args,**kwargs): + return self._apply_method_s(SimpleLDAPObject.whoami_s,*args,**kwargs) + class SmartLDAPObject(ReconnectLDAPObject): """ I use whoami_s() like a ping, to know if the server is still up. Do you know a better way ? -- Alain Spineux aspineux gmail com May the sources be with you |
From: <mi...@st...> - 2007-01-22 09:47:03
|
Anil Jangity wrote: > Whats the recommend way to make modifications to an LDAP entry? In general 1. you should do as many modifications in a single modify as possible since a single modify operations is atomic. 2. you should try to avoid mods which need equality matching rules at the server side for sorting out specific attribute values. > Right now I am using ldap.modify (MOD_ADD, MOD_DELETE, or > MOD_REPLACE) but it seems cumbersome because there are multiple > possiblities for each modification depending on wether its a > multi-value attribute or single-value or required attribute or > optional attribute... Maybe the output of function ldap.modlist.modifyModlist() gives you some ideas: http://python-ldap.sourceforge.net/doc/python-ldap/module-ldap.modlist.html > It would be nice if there is a class available to simply pass in the > DN, and the *new* LDIF and it would be taken care of. Not LDIF. ldap.modlist.modifyModlist() handles dictionaries. > I am just > looking through some documentation and I guess something like > ldif.LDIFWriter(). It's fairly easy to glue ldif.LDIFReader() and ldap.modlist.modifyModlist() together. Ciao, Michael. |
From: Anil J. <an...@en...> - 2007-01-19 19:22:12
|
Whats the recommend way to make modifications to an LDAP entry? Right now I am using ldap.modify (MOD_ADD, MOD_DELETE, or MOD_REPLACE) but it seems cumbersome because there are multiple possiblities for each modification depending on wether its a multi-value attribute or single-value or required attribute or optional attribute... This is a rough code of what I am talking about: # optional attr if attribute not in newentry: MOD_DELETE if new_attribute and old_attribute are diff: if old_attr is None: MOD_ADD else: MOD_REPLACE # required attributes .... It would be nice if there is a class available to simply pass in the DN, and the *new* LDIF and it would be taken care of. I am just looking through some documentation and I guess something like ldif.LDIFWriter(). Unless I am missing something that is there already.... Thanks. |
From: <mi...@st...> - 2007-01-19 06:20:36
|
Jonathan Bowman wrote: > > You wrote a while back: > >>Regarding 2.: >>I asked Howard Chu, OpenLDAP core developer whether it's possible to >>build Cyrus-SASL on Win32 based on the MingW tool chain. He said they're >>doing it all the time with Symas' product. Additionally one would have >>to clarify the situation for Kerberos libs (preferrably heimdal). > > Would this fellow be willing to share instructions on how to do so? I > would be happy to contact him, if so. You could simply ask on the openldap-software mailing list. Ciao, Michael. |
From: Jonathan B. <bo...@us...> - 2007-01-19 01:32:21
|
Michael, You wrote a while back: > Regarding 2.: > I asked Howard Chu, OpenLDAP core developer whether it's possible to > build Cyrus-SASL on Win32 based on the MingW tool chain. He said they're > doing it all the time with Symas' product. Additionally one would have > to clarify the situation for Kerberos libs (preferrably heimdal). Would this fellow be willing to share instructions on how to do so? I would be happy to contact him, if so. Thanks, Jonathan |
From: Rich M. <ric...@gm...> - 2007-01-05 04:28:25
|
Michael Ströder wrote: > Anil wrote: > >> Will python-ldap package ever support other ldap servers? >> > > Short answer: Yes. > > Longer answer: > My web2ldap uses python-ldap. I used this tool with a wide range of > different server products. This page should give you a rough idea: > http://www.web2ldap.de/compability.html > > >> (primarily I >> am thinking of Sun's directory or the OpenDS) >> > > I'm not aware of any issues with this specific LDAP server regarding > access with python-ldap. > I use python-ldap with Red Hat and Fedora DS quite a bit, and it works just fine. Should work for all of the Netscape/iPlanet/Sun servers, since they are all very similar. > >> I've compiled python-ldap using openldap and have used it against them >> but one specific method I am concerned with is the modrdn/renames. Not >> sure they work well with Sun's directory. >> > > Can you please elaborate. What issues are you seeing? > Up until Sun DS 5.2, none of the Netscape derived servers supported modrdn with new superior. Could that be the issue you are seeing? > Ciao, Michael. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > > > |
From: <mi...@st...> - 2007-01-05 02:36:35
|
Anil wrote: > Will python-ldap package ever support other ldap servers? Short answer: Yes. Longer answer: My web2ldap uses python-ldap. I used this tool with a wide range of different server products. This page should give you a rough idea: http://www.web2ldap.de/compability.html > (primarily I > am thinking of Sun's directory or the OpenDS) I'm not aware of any issues with this specific LDAP server regarding access with python-ldap. > I've compiled python-ldap using openldap and have used it against them > but one specific method I am concerned with is the modrdn/renames. Not > sure they work well with Sun's directory. Can you please elaborate. What issues are you seeing? Ciao, Michael. |
From: Anil <an...@en...> - 2007-01-05 02:28:48
|
Will python-ldap package ever support other ldap servers? (primarily I am thinking of Sun's directory or the OpenDS) I've compiled python-ldap using openldap and have used it against them but one specific method I am concerned with is the modrdn/renames. Not sure they work well with Sun's directory. I know PHP didn't handle this too well. |
From: <mi...@st...> - 2007-01-02 16:03:36
|
Lionel, Lionel Porcheron wrote: > > One of Ubuntu users send us a patch on your documentation (see > attached). Can you check it and see if it is appropriate and in this > case include it in your future releases. > > The original bug is reachable here : > https://bugs.launchpad.net/distros/ubuntu/+source/python-ldap/+bug/73615 Thanks for pointing that out. But actually the __doc__ string has more appropriate wording which I will use in the docs: >>> import ldap >>> print ldap.ldapobject.LDAPObject.modrdn.__doc__ modrdn(dn, newrdn [,delold=1]) -> int modrdn_s(dn, newrdn [,delold=1]) -> None Perform a modify RDN operation. These routines take dn, the DN of the entry whose RDN is to be changed, and newrdn, the new RDN to give to the entry. The optional parameter delold is used to specify whether the old RDN should be kept as an attribute of the entry or not. The asynchronous version returns the initiated message id. This operation is emulated by rename() and rename_s() methods since the modrdn2* routines in the C library are deprecated. Ciao, Michael. |
From: <mi...@st...> - 2006-12-31 12:07:35
|
Vitaliyi wrote: > I found out that ldap.modify_s behaves strangely, at least from my > point of view: > > l.modify_s(dn,[(ldap.MOD_REPLACE,'someAttr',str(whatever))]) > will drop attribute, You SHOULD NOT use this form because attributes are most times supposed to be multi-valued. > but with list ([str(whatever)]), parameter do as expected. You SHOULD implement it with list. It was a bad design decision to even accept strings. Ciao, Michael. |
From: Vitaliyi <im...@gm...> - 2006-12-31 07:57:21
|
I found out that ldap.modify_s behaves strangely, at least from my point of view: l.modify_s(dn,[(ldap.MOD_REPLACE,'someAttr',str(whatever))]) will drop attribute, but with list ([str(whatever)]), parameter do as expected. |
From: <mi...@st...> - 2006-12-19 14:19:11
|
gee...@aa... wrote: > > Everything works fine if I'm linking against the shared version > of python.... > > I've no idea why it's not working with the static version????? I have also no idea. Ciao, Michael. |
From: <gee...@aa...> - 2006-12-18 11:02:03
|
Hi, Here is part of my makefile: VERSION =3D Python-2.5 VERSION=5FLDAP =3D python-ldap-2.2.1 compile: .python .python-ldap python: makefile.python .glibc $(VERSION).Setup.local $(EXTRACT=5FPACKAGE) && \ $(CP) ../$(VERSION).Setup.local=20 Modules/Setup.local && \ ./configure --prefix=3D/usr --enable-shared=3Dno &&= \ make && \ make install=20 cp $(VERSION)/libpython2.5.a /usr/lib/libpython.a (cd /usr/include; $(LN) -sf python2.5 python ) touch .python=20 .python-ldap: makefile.python .python .sasl .glibc .openldap=20 python-ldap.setup.cfg (rm -rf $(VERSION=5FLDAP) || /bin/true) && \ tar xjf $(ARCHIVE=5FPACKAGES)/$(VERSION=5FLDAP).tar.bz2 && \ cd $(VERSION=5FLDAP) && \ $(CP) ../python-ldap.setup.cfg setup.cfg && \ python setup.py build && \ python setup.py install rm -rf $(VERSION=5FLDAP) touch .python-ldap And my setup.cfg # Example for setup.cfg # You have to edit this file to reflect your system configuation # $Id: setup.cfg.suse-linux,v 1.1 2003/08/20 10:04:34 stroeder Exp $ [=5Fldap] # Section for compiling the C extension module # for wrapping OpenLDAP 2 libs library=5Fdirs =3D /usr/lib/ /usr/lib/sasl2/ include=5Fdirs =3D /usr/include/sasl/ /usr/include/sasl2/ extra=5Fcompile=5Fargs =3D extra=5Fobjects =3D # Example for full-featured SuSE build: # Support for StartTLS/LDAPS, SASL bind and reentrant libldap=5Fr. # This needs recent OpenLDAP 2.0.26+ or 2.1.3+ built with #./configure --with-cyrus-sasl --with-tls libs =3D python ldap=5Fr lber sasl2 ssl crypto resolv dl db m util pthread [install] # Installation options compile =3D 1 optimize =3D 1 Everything is done in a chroot-ed environment...when building python-ldap, = it uses the newly installed python includes.... The test application is linked against the static version libpython.a Thanks, Geert Michael Str=F6der <mi...@st...>=20 Sent by: pyt...@li... 12/18/2006 11:40 AM To gee...@aa... cc pyt...@li... Subject Re: Fw: crash in PyImport=5FImport (Unsigned Mail) gee...@aa... wrote: > > -> Python and python-ldap are recompiled for my environment > (python generates the static library....) Did you tweak the file setup.cfg? Can you please elaborate on how static linking is to be done? How is the embedded Python built? Ciao, Michael. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share=20 your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Python-LDAP-dev mailing list Pyt...@li... https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
From: <mi...@st...> - 2006-12-18 10:40:55
|
gee...@aa... wrote: > > -> Python and python-ldap are recompiled for my environment > (python generates the static library....) Did you tweak the file setup.cfg? Can you please elaborate on how static linking is to be done? How is the embedded Python built? Ciao, Michael. |
From: <gee...@aa...> - 2006-12-18 09:55:26
|
Hi, Unfortunately, it doesn't work with these releases... The crash happens when importing the python script (and no function is called...) Are there any ldapobject created and deleted at that time? (No bind is done before the crash...) Regards, Geert Michael Str=F6der <mi...@st...>=20 Sent by: pyt...@li... 12/18/2006 10:18 AM To gee...@aa... cc pyt...@li... Subject Re: Fw: crash in PyImport=5FImport (Plain) (Unsigned Mail) gee...@aa... wrote: > > I've been using the following versions of python and python-ldap > > python: 2.5 > python-ldap 2.2.1 And now it works? (see SF#1575329) Ciao, Michael. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share=20 your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Python-LDAP-dev mailing list Pyt...@li... https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |