openldap-devel

openldap-devel@openldap.org

1416 discussions

OpenLDAP / Oracle LDAP: naming collision for ldap_set_option/ldap_get_option
by Peter Steiert 26 May '11

26 May '11

Hello alltogether, i'm not quite sure whether this list is the correct place to discuss the following topic but I hope so. I recently had an issue after compiling and running freeradius with oracle and openldap support. The error is as following: Thu May 12 10:06:42 2011 : Debug: [ldap] (re)connect to ldaps.localnet.local:636, authentication 0 Thu May 12 10:06:42 2011 : Error: [ldap] Could not set LDAP_OPT_NETWORK_TIMEOUT 1: Bad parameter to an ldap routine Thu May 12 10:06:42 2011 : Debug: [ldap] setting TLS mode to 1 Thu May 12 10:06:42 2011 : Error: [ldap] could not set LDAP_OPT_X_TLS option Bad parameter to an ldap routine: Thu May 12 10:06:42 2011 : Debug: [ldap] bind as cn=RADIUSADMIN, c=DE/PASSWORD to ldaps.localnet.local:636 Thu May 12 10:06:42 2011 : Debug: [ldap] waiting for bind result ... Thu May 12 10:06:42 2011 : Debug: [ldap] ldap_result() Thu May 12 10:06:42 2011 : Error: [ldap] cn=RADIUSADMIN, c=DE bind to ldaps.localnet.local:636 failed: Can't contact LDAP server sgslufread: Hard error on read, OS error = 32 sgslufread: Hard error on read, OS error = 32 After longer investigation i found out that the routines: ldap_set_option ldap_get_option are defined in OpenLDAP/ldap.h as well as in Oracle/ldap.h and are locatable in Oraclelib/libclntsh.so.11.1 as well as in OpenLDAP/libldap_r.so. So the ld-loader is sometimes offering the oracle code to the client and sometime the openldap code. This causes failure in the application. Now my question to the community here: Is there a global naming definiton about these routines to avoid such a conflict? Wouldn't it be better if Oracle would use it's own namespace convention as well as OpenLDAP? Kind regards Peter If the list is wrong please tell me the correct one to discuss this topic. Btw: We did a workaround by using the LD_PRELOAD path :)

2 2

replicate internal operations (was: (ITS#6915) memberof+accesslog duplicate reqStart)
by Michael Ströder 25 May '11

25 May '11

Taking this to -devel for clarification. hyc(a)symas.com wrote: > The original design for memberOf was for the internal modifications to not be > replicated. Instead, any replicas that wanted to maintain member information > was expected to run an identical memberOf overlay configuration. Ok. > In general it's incorrect to replicate internal operations. The fanout from > replicating every internal operation would be too large and the information > content of what is being replicated is essentially nil. When the servers are > configured identically they will maintain identical data by virtue of the > overlays on each node performing the same internal operations in response to a > given sequence of user operations. While I agree here I think "internal operations" has to be defined a little bit more clear: What about extended operations which may result in several write operations? Extended operations are not written to the accesslog-DB and are not replicated. Ciao, Michael.

2 1

Critical client controls stop ldap_unbind()
by Hallvard B Furuseth 13 May '11

13 May '11

ldap_unbind() & co fail without doing anything if a critical client control is set with ldap_set_option() or passed to ldap_unbind_ext_s(). This seems wrong, since ldap_unbind() has always been documented as the way to both close the connection and free the LDAP structure. Yet if some code does set a critical client control, that might be a hack to get exactly this functionality: Temporarily protect the LDAP* from being destroyed by some other code. Server controls do not prevent the Unbind. RFC 4511 says the criticality field MUST be ignored for Unbind controls. But that's in the protocol. Client controls are an LDAP API invention. I don't know which solution to pick. Opinions? Maybe we should deprecate ldap_unbind... calls now that we have ldap_destroy(). That function also sends an Unbind if it can. But that doesn't affect existing code using ldap_unbind...(). LDAPControl ctrl = {"1.2.3.4", {0,""}, 1}, *ctrls[] = {&ctrl, NULL}; LDAP *ld = ldap_open("ldap", LDAP_PORT); ldap_set_option(ld, LDAP_OPT_CLIENT_CONTROLS, ctrls); ldap_unbind_ext_s(ld, NULL, NULL); /* Connection remains open here... */ sleep(999); -- Hallvard

2 1

sizelimit and pagedResultsControl - AD vs Openldap ...
by Mads Freek Petersen 09 May '11

09 May '11

Hi all I have written a simple pure php ldap library to be able to use the pagedResultsControl - which the standard php library - to my knowledge - doesn't support. Testing it against Openldap and AD i have found that given: a dit with 1000 objects a sizelimit of 500 a pagesize of 100 Openldap returns 5 pages of 100 objects while AD returns 10 pages of 100 objects. Ie. if the sizelimit is greater than the pagesize AD ignores it. What is the correct behavior? Bwt.hHas anyone ever looked at the "cookie" AD returns - it is more than 1K bytes long! Regards Mads Freek ------------------------------------------------------ Mads Freek Petersen Special Consultant Computer Science Department Roskilde University Building 42-1, P.O. Box 260, DK-4000 Roskilde, Denmark Phone: +45 4674 3882 Fax: +45 4674 3072 E-mail: freek(a)ruc.dk There are two types of code. A large pile of crap code, and a small pile of crap code. Favour the small. - unknown IBM engineer

2 1

.git* files in .tar.gz releases?
by Hallvard B Furuseth 06 May '11

06 May '11

Should .gitattributes and .gitignore be included in releases? If not, .gitattributes needs the lines: .gitignore export-ignore .gitattributes export-ignore -- Hallvard

1 0

Static Analysis of OpenLDAP
by Lynn Gayowski 03 May '11

03 May '11

Klocwork's open source program did some source code analysis for OpenLDAP a few years back. We've analyzed the project again using our static analysis product, Klocwork Insight, and found some bugs and potential security vulnerabilities that may be of interest. The results are hosted on a secure web portal so only contributors to the project will have access to the results. They will not be published. Please email opensource at klocwork dot com for the login credentials. Issue Summary: https://opensource.klocwork.com/review/insight-review.html#reportviewer_ goto:project=openldap,report=6,scope=1 Full Details/Issue Management: http://goo.gl/9GNiu This program will be offered free to open source projects on an ongoing basis, so if you find the results of value we could analyze future versions of your project as well. Cheers, Lynn Gayowski Klocwork P +1.613. 836.8899 ext. 424 lynn.gayowski at klocwork.com

3 3

Module development
by Abu Marcose 15 Apr '11

15 Apr '11

Is there any documentation out there on overlay development ? I need to port a module that was developed for OnpeLDAP 2.3 to 2.4, and can't find any tutorials or examples on how to go about this. Any help will be much appreciated. Thanks

1 0

"Warning" during OL Head compile
by Marco Pizzoli 12 Apr '11

12 Apr '11

Hi all, this is my first post in this list. I downloaded head tree from OL CVS and made some compile runs. I see some warning about some deprecated functions and so on... I'm asking myself if this could be of some usefulness on the project if I would share with the developers these evidences. This is an example, obtained on a Fedora14_i686 system, gcc-4.5.1-4.fc14.i686: gcc -DOPENLDAP_FD_SETSIZE=4096 -O2 -g -o slapd-bind slapd-bind.o slapd-common.o -L/usr/local/berkeleydb/lib -L/usr/lib/perl5/CORE ../../libraries/libldap/.libs/libldap.a /tmp/appoggio_openldap/openldap-post2.4.24_3/libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a ../../libraries/liblber/.libs/liblber.a -lsasl2 -lssl -lcrypto -lresolv ../../libraries/libldap/.libs/libldap.a(os-ip.o): In function `ldap_pvt_is_socket_ready': /tmp/appoggio_openldap/openldap-post2.4.24_3/libraries/libldap/os-ip.c:262: *warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead* /tmp/appoggio_openldap/openldap-post2.4.24_3/libraries/libldap/os-ip.c:262: *warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead* -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

2 2

Overlay supporting password syntax checking
by Mathieu 29 Mar '11

29 Mar '11

Hi, I am currently migrating a users database to an OpenLDAP solution. I have to deal with some constraints for this project, namely password policy and/or password syntax checking. Fortunately the ppolicy overlay already implements the draft-behera-ldap-password-policy, and offers the possibility to use pwdCheckModule to check password via external modules. Unfortunately, I did not find any module meeting all my requirements: The check_password() function, as defined in ppolicy, provides to the underlying module two parameters: - The entry being modified - The new password. Now to support per user settings, which is one of these requirements, I have to either store extra attributes among each entry, or the module has to perform a ldapsearch against the db. An option is to modify the check_password() function so it sends the ppolicy object itself: int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry, Entry *ppolicyEntry); This way people using external modules would just need to store their settings attributes in it. As I don't want to break existing modules implementation, I have developed a simple overlay which enforces password syntax checking on a per user or per database basis. The overlay implements also the check_password() function so it can be used in conjunction with ppolicy. I believe the code is clean enough to be contributed and I will be glad to upload it if you think it can be of any interest. However, I have some questions first. The overlay allows me to define a default password constraints object at a database level, or a subentry in the user entry, in a similar way as the ppolicy_default setting and the pwdPolicySubentry attributes. This is so similar that I think it would be more relevant to extend the ppolicy overlay so it could support basic syntax checking. I understand the need to have the pwdCheckModule functionality, for those in need of exotics or platform dependent checks, but counting the characters belonging to a class is not harder than checking the min/max length of the password. So to summarize: - Could the check_password function be modified? - Could basic syntax checking be integrated in ppolicy? And If none of these options are acceptable, should I upload the overlay I developed? Of course I'm willing to help on the first two points. Regards, -- Mathieu

2 2

OpenLDAP git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Out of several rumors I've heard that OpenLDAP converted it source repo to git. Is that true? www.openldap.org still speaks about cvs. If you changed to git, is the repo publically available? Thanks, Volker

5 12

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel