openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: LDAPI support in JLDAP
by Endi Sukma Dewata 04 Dec '09

04 Dec '09

Hi Marc, Thanks for your suggestions. I tried to create a subclass of LDAPConnection but I was getting a lot of problems accessing non-public methos/classes belonging to com.novell.java package. But it gave me a different idea, I finally got it to work using a custom socket factory. First I create an LDAPIUrl to parse LDAPI URL: LDAPIUrl url = new LDAPIUrl("ldapi://%2ftmp%2ftest"); Then I create a LDAPISocketFactory and pass it to LDAPConnection: LDAPISocketFactory factory = new LDAPISocketFactory(); LDAPConnection connection = new LDAPConnection(factory); To establish the connection I use the hostname parameter of the connect() function to pass the LDAPI path: connection.connect(url.getPath(), 0); The socket factory will use the path to create the Unix domain socket and ignore the port: public Socket createSocket(String path, int port) { AFUNIXSocket socket = AFUNIXSocket.newInstance(); socket.connect(new AFUNIXSocketAddress(new File(path))); return socket; } So thanks a lot and never mind about the proposal. :) -- Endi S. Dewata ----- "Marc Boorshtein" <mboorshtein(a)gmail.com> wrote: > Endi, > > A few years ago I was able to add DSMLv2 and SPMLv1 support to JLDAP > by creating subclasses of the LDAPConnection class. This worked well > without requiring changes to the rest of the JLDAP source code. I > used JLDAP as the core for the SQL Directory Browser, which supports > both SPML and DSMLv2. I think the same strategy would work with > LDAPI? > > Marc > > > On Thu, Dec 3, 2009 at 6:26 PM, Endi Sukma Dewata <edewata(a)redhat.com> > wrote: > > Hello, > > > > Let me introduce myself, I'm working on the IPA & Samba integration > > effort and I'm building a Java-based synchronization tool that > > communicates with LDAP servers using the JLDAP library. Here is > some > > background about the project: > > http://www.freeipa.org/page/IPAv3_development_status > > > > The LDAP servers used here is the 389 DS (formerly known as Fedora > > DS). When it's used as Samba private backend, the DS is configured > > only to listen to LDAPI protocol. I'm trying to use the JLDAP > library, > > but currently it doesn't seem to support LDAPI. I think it's > natural > > to add LDAPI support into JLDAP because OpenLDAP also supports > LDAPI. > > Is there already a plan to add this feature? > > > > I've been doing some investigation and it seems that it can be > added > > without too much effort because there's an existing library called > > junixsocket which can provide access to Unix Domain Sockets from > Java: > > http://code.google.com/p/junixsocket/ > > > > Here is a proposal of the changes need to be made to JLDAP in order > > to support LDAPI: > > http://www.freeipa.org/page/OpenLDAP_LDAPI_Support_in_JLDAP > > > > My questions are: > > 1. Who is currently maintaining the JLDAP module? > > 2. Is it ok to modify the IETF API slightly as described in the > > proposal? > > 3. Is it ok to include junixsocket in JLDAP? Alternatively we could > > design a pluggable interface so other people can add new protocol > > schemes into JLDAP. > > > > Please let me know if you have any comments, questions, or > > suggestions. Thank you very much. > > > > -- > > Endi S. Dewata > >

1 0

LDAPI support in JLDAP
by Endi Sukma Dewata 04 Dec '09

04 Dec '09

Hello, Let me introduce myself, I'm working on the IPA & Samba integration effort and I'm building a Java-based synchronization tool that communicates with LDAP servers using the JLDAP library. Here is some background about the project: http://www.freeipa.org/page/IPAv3_development_status The LDAP servers used here is the 389 DS (formerly known as Fedora DS). When it's used as Samba private backend, the DS is configured only to listen to LDAPI protocol. I'm trying to use the JLDAP library, but currently it doesn't seem to support LDAPI. I think it's natural to add LDAPI support into JLDAP because OpenLDAP also supports LDAPI. Is there already a plan to add this feature? I've been doing some investigation and it seems that it can be added without too much effort because there's an existing library called junixsocket which can provide access to Unix Domain Sockets from Java: http://code.google.com/p/junixsocket/ Here is a proposal of the changes need to be made to JLDAP in order to support LDAPI: http://www.freeipa.org/page/OpenLDAP_LDAPI_Support_in_JLDAP My questions are: 1. Who is currently maintaining the JLDAP module? 2. Is it ok to modify the IETF API slightly as described in the proposal? 3. Is it ok to include junixsocket in JLDAP? Alternatively we could design a pluggable interface so other people can add new protocol schemes into JLDAP. Please let me know if you have any comments, questions, or suggestions. Thank you very much. -- Endi S. Dewata

2 1

Re: commit: ldap/libraries/libldap util-int.c
by Quanah Gibson-Mount 02 Dec '09

02 Dec '09

--On Monday, November 30, 2009 8:47 PM +0000 hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > util-int.c 1.65 -> 1.66 > > Log Message: > ITS#6405 in ldap_pvt_gettime, also check for microsecs going backward Neither this function nor this code exist in RE24, which is what the bug was reported against. I assume a different fix is needed there? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE24 (2.4.20) testing call #3
by Quanah Gibson-Mount 24 Nov '09

24 Nov '09

A few new changes, please re-sync and test. Thanks! Hopefully this will be the last of it. In particular, watch test050 please. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

7 9

RE24 (2.4.20) testing call #4
by Quanah Gibson-Mount 24 Nov '09

24 Nov '09

Testing call for 2.4.20 #4. This should be the last one. :P Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 5

Java implementation of rfc4533 (Content Synchronization Operation)
by Joacim Breiler 24 Nov '09

24 Nov '09

Hi! I've made an attempt to implement rfc4533 in Java using JLDAP based on the work of Erik van Oosten's blog post: http://day-to-day-stuff.blogspot.com/2007/11/howto-extend-ldap-in-java-with… I'm currently struggling with the RefreshOnly mode: * On connect and the first search, a result with all entries is returned together with a LDAPSyncStateControl. * When the refresh i finnished, a LDAPSyncDoneControl is retreived and the syncookie is saved for next search * Next search is made using the saved syncookie, and I get no additional results. Everything seems fine and dandy so far... Now, if an entry is changed on OpenLDAP, a LDAPSearchResult is retreived by the search, but doesn't contain the changed entry. I don't get the LDAPSyncStateControl either. Any ideas? The source of the controls and examples can be found here: http://beskes.hgo.se/~joacimb/rfc4533/ Regards, Joacim Breiler

1 0

Re: commit: openldap-guide/admin appendix-ldap-result-codes.sdf
by Gavin Henry 24 Nov '09

24 Nov '09

----- hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > appendix-ldap-result-codes.sdf 1.5 -> 1.6 > > Log Message: > ITS#6399, fix RFC4511 references, other references > > > CVS Web URLs: > > http://www.openldap.org/devel/cvsweb.cgi/admin/?cvsroot=OpenLDAP-guide > > http://www.openldap.org/devel/cvsweb.cgi/admin/appendix-ldap-result-codes.s… > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. Thanks! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

RE24 (2.4.20) testing call #3
by Quanah Gibson-Mount 23 Nov '09

23 Nov '09

Significant work done with replication issues. Please test, and particularly test test050 and related a lot if possible. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

5 4

contextCSN of subordinate syncrepl DBs
by Rein Tollevik 22 Nov '09

22 Nov '09

I've been trying to figure out why syncrepl used on a backend that is subordinate to a glue database with the syncprov overlay should save the contextCSN in the suffix of the glue database rather than the suffix of the backend where syncrepl is used. But all I come up with are reasons why this should not be the case. So, unless anyone can enlighten me as to what I'm missing, I suggest that this be changed. The problem with the current design is that it makes it impossible to reliably replicate more than one subordinate db from the same remote server, as there are now race conditions where one of the subordinate backends could save an updated contextCSN value that is picked up by the other before it has finished its synchronization. An example of a configuration where more than one subordinate db replicated from the same server might be necessary is the central master described in my previous posting in http://www.openldap.org/lists/openldap-devel/200806/msg00041.html My idea as to how this race condition could be verified was to add enough entries to one of the backends (while the consumer was stopped) to make it possible to restart the consumer after the first backend had saved the updated contextCSN but before the second has finished its synchronization. But I was able to produce it by simply add or delete of an entry in one of the backends before starting the consumer. Far to often was the backend without any changes able to pick up and save the updated contextCSN from the producer before syncrepl on the second backend fetched its initial value. I.e it started with an updated contextCSN and didn't receive the changes that had taken place on the producer. If syncrepl stored the values in the suffix of their own database then they wouldn't interfere with each other like this. There is a similar problem in syncprov, as it must use the lowest contextCSN value (with a given sid) saved by the syncrepl backends configured within the subtree where syncprov is used. But to do that it also needs to distinguish the contextCSN values of each syncrepl backend, which it can't do when they all save them in the glue suffix. This also implies that syncprov must ignore contextCSN updates from syncrepl until all syncrepl backends has saved a value, and that syncprov on the provider must send newCookie sync info messages when it updates its contextCSN value when the changed entry isn't being replicated to a consumer. I.e as outlined in the message referred to above. Neither of these changes should interfere with ordinary multi-master configurations where syncrepl and syncprov are both use on the same (glue) database. I'll volunteer to implement and test the necessary changes if this is the right solution. But to know whether my analysis is correct or not I need feedback. So, comments please? -- Rein Tollevik Basefarm AS

2 6

Re: commit: ldap/doc/man/man5 slapd.conf.5
by Quanah Gibson-Mount 22 Nov '09

22 Nov '09

--On Sunday, November 22, 2009 1:44 PM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5 > > Modified Files: > slapd.conf.5 1.310 -> 1.311 > > Log Message: > minimal documentation of authid-rewrite* stuff > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/ > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/slapd.conf.5 > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. Shouldn't there be a corresponding update do slapd-config(5)? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel