"Warning" during OL Head compile
by Marco Pizzoli
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
12 years, 1 month
Overlay supporting password syntax checking
by Mathieu
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
12 years, 1 month
OpenLDAP git repo?
by Volker Lendecke
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
12 years, 1 month
git repo?
by Volker Lendecke
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
12 years, 2 months
RE 24 testing call (OL 2.4.25)
by Quanah Gibson-Mount
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
12 years, 2 months
Re: commit: ldap/build crupdate
by Hallvard B Furuseth
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
12 years, 2 months
authTimestamp and relax rules control
by Michael Ströder
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.
12 years, 2 months
Generalize olcHidden -> olcLabel
by Hallvard B Furuseth
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
12 years, 2 months
