openldap-devel March 2011

openldap-devel@openldap.org

16 participants
16 discussions

"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

git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Being excited about the git repo, I had to try it: $ git clone git://git.OpenLDAP.org/module.git Initialized empty Git repository in /data/vlendec/git/module/.git/ fatal: The remote end hung up unexpectedly $ Is it possible that something is not set up right yet? Thanks, Volker

2 1

Re: openldap.git branch master updated. cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f
by Hallvard B Furuseth 29 Mar '11

29 Mar '11

> commit cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f > Merge: cd1f718 0adef98 > Author: Kurt Zeilenga <kurt(a)OpenLDAP.org> > Date: Mon Mar 28 18:42:22 2011 -0700 > > Merge branch 'master' of ssh://git-master.openldap.org/~git/git/openldap We'll need better messages for merges, this doesn't say much. -- Hallvard

3 5

RE 24 testing call (OL 2.4.25)
by Quanah Gibson-Mount 28 Mar '11

28 Mar '11

A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 5

Re: commit: ldap/build crupdate
by Hallvard B Furuseth 25 Mar '11

25 Mar '11

kurt(a)OpenLDAP.org writes: > Removed Files: > crupdate 1.12 -> NONE > Remove from CVS (now in openldap-etc.git) No big deal, but I think such changes belong in Git only. Might as well leave the frozen CVS repo in a working state, e.g. if we find we need to use it for one more release or want to play around with it to verify the transition to Git. -- Hallvard

1 0

authTimestamp and relax rules control
by Michael Ströder 19 Mar '11

19 Mar '11

HI! I'm using slapo-lastbind with 2.4.24 found under contrib/ which writes the operational attribute authTimestamp to an entry. Now I have a use-case where a LDAP client (connector continously pumping data from another non-OpenLDAP directory server) should write this attribute to the OpenLDAP server. But even when using the relax rules control this does not seem to be allowed. Section 3.6. of draft-zeilenga-ldap-relax-03 says: The subsections of this section discuss modification of various operational attributes where their NO-USER-MODIFICATION constraint may be relaxed. Future documents may specify where NO-USER-MODIFICATION constraints on other operational attribute may be relaxed. In absence of a document detailing that the NO-USER-MODIFICATION constraint on a particular operational attribute may be relaxed, implementors SHOULD assume relaxation of the constraint is not appropriate for that attribute. Hmm, since there's no formal spec for authTimestamp I'm lost here? Ciao, Michael.

2 2

Release testing
by Howard Chu 18 Mar '11

18 Mar '11

Since fermat.openldap.org which was to be the core of our build farm has been down almost from the time the machine arrived, we haven't been able to set up the automated builds we had envisioned. It's clear now that nobody tested RE24 on Windows before we released 2.4.24. Anybody willing to take responsibility for Windows testing in the future? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Generalize olcHidden -> olcLabel
by Hallvard B Furuseth 17 Mar '11

17 Mar '11

I'd like a simple way to manipulate an off-line database while slapd is running, e.g. to slapadd it from scratch and activate it when done. Here is one suggestion: Make olcHidden a dynamic attribute computed from an attribute olcLabel="some text" + a startup option -L "label to activate,...". Updates to olcHidden could fail or update olcLabel for backwards compatibility, depending on configuration. Then to rebuild database X off-line, maybe with a different config: - Copy ldapadd X's config to a new database Y, except set olcLabel = "offline" and olcDbDirectory = "<new dir>". - Set olcReadOnly=TRUE in X's config, so we won't lose any changes. - Slapcat <X> | slapadd -L offline - Set X's olcDbDirectory="<new dir>" and olcReadOnly=FALSE, to pick up the changes and resume normal operation. This doesn't cover all cases of reconfiguring a database, e.g. we can't modify a global option like olcIndexIntLen this way. But it's a start. Also instead of pointing X's olcDbDirectory at Y's directory, one might want to atomically hide database X and un-hide Y, by removing Y's label and then labelling X. That works if one can have two active databases with the same suffix where the former hides the latter. (Maybe the hidden database would be treated as if it had olcHidden.) Slapd does not currently accept that at startup, but does if one starts with olcHidden=TRUE in the first database and then removes olcHidden. That should probably be cleaned up anyway. The olcHidden machinery has some bugs, I'll ITS them after exploring abit. -- Hallvard

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel March 2011