exists a OpenLDAP API Documentation to develop a Overlay (like smbk5pwd)?
We just started to explore the source-code (smbk5pwd.c), but we noticed
the struct's and function syntax aren't easy to unterstand - We need a
Like the smbk5pwd module, we want to develop a analog module for Asterisk.
The feature introduced in 2.3  to map undefined attributes from
proxies as "proxied" attribute descriptions enables searches with
filters using attributes that have no local definition.
For example, given slapd with a back-ldap pointing to an Active
Directory (AD) server, this features makes searches with a filter of
"(samAccountName=login)" work with no extra configuration, and without
explicitly adding samAccountName to local schema.
However, such searches will be passed on to the AD server only if a
previous search result contained the attributes in question
(samAccountName) and was not based on a filter containing the attribute.
Otherwise, the filter is considered invalid and replaced with
"(?=undefined)" in the logs, and passed to the AD server as
This means that the same search, on the same data, can return different
results at different times, depending on whether or not a previous
search had succeeded and returned given attribute (samAccountName).
Currently, we have worked around this problem by either:
- running a bogus ldapsearch just after starting slapd, that returns
- adding the attribute description to a local schema
What is the general opinion on working around this issue? Might there be
a way to implement something that ensures this happens automatically?
I'm thinking of delegating filter checking to proxied servers for ldap
backends, or automatically fetching schemas from them... Any experience,
Thanks in advance. Best regards,
Open Source Software Assurance (OSSA) - Groupe LINAGORA
27 rue de Berri, 75008 Paris
Tél: 01 58 18 68 28, fax: 01 58 18 68 29
http://www.linagora.com - http://www.08000linux.com
We've noticed hard failures on both our Linux and Mac workstations
when an LDAP server fails in a way which causes it to stop responding
but leave a connection open (e.g. lock contention, disk failure). This
usually ends up requiring the system to be rebooted because a key
system process will probably have made a call which is waiting on a
read() which might take days to fail.
I've created a patch simply calls setsockopt() to set SO_SNDTIMEO|
SO_RCVTIMEO when LDAP_OPT_NETWORK_TIMEOUT has been set. This appears
to produce the desired result on Linux (both with pam_ldap and the
ldap utilities) and OS X (within the DirectoryService plugin).
Is there a drawback to this approach which I've missed? It appears
that the issue has come up in the past but there's no solution that I
can see (certainly nothing else uses socket-level timeouts). I'd like
to find a solution for this as it's by far the biggest source of Linux
downtime in our environment.
The OpenLDAP Project is tentatively planning on hosting
a developers' day conference in Dublin, Ireland in late July / early August
(most likely weekend of August 2-3, and August 4).
Those interested in speaking at the conference are
encouraged to contact <project(a)openldap.org> with a
specific proposal (title, abstract, duration). Discounts
will be available to speakers.
A formal (and more widely distributed) call for participation
will be made once conference details are firmed up a bit
(like we fix the date...).
Organizations interested in sponsoring this event are
encouraged to contact project(a)openldap.org. Currently we've
got an agreement with HEAnet to host the event, and Symas will
be sponsoring some of the activity.
At the moment it's been suggested that we conduct two
events - an ODD conference with presentations as we've done
in the past, and also a code-sprint where we all grind thru
a bunch of code together.
Feel free to email me with suggestions.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
What are glue entries and how do they work in OpenLDAP? The manageDSAit
code in back-bdb is intertwined with is_entry_glue() calls which I don't
know what to make of. The only glue I can see bdb create seems to be a
fake entry named "" if that is the database suffix. And I don't see
any mention of glue entries in other backends.