deprecated functions
by Quanah Gibson-Mount
I'm interested in updating Net::LDAPapi so that it no longer uses the
deprecated C API. ldap.h is nicely commented on the replacement functions
for just about all of the deprecated functions, except for:
ldap_sort_entries
ldap_sort_values
ldap_sort_strcasecmp
of which Net::LDAPapi only uses ldap_sort_entries.
Is there a replacement function for this? If not, any thoughts on what the
steps are to duplicate that functionality?
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 7 months
Re: Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Howard Chu
Pierangelo Masarati wrote:
> For back-meta, I'd like to create children entries for each target; in
> this case, an overlay with specific per-target behavior, would need to
> either create a similar tree, or to append entries to targets'. This is
> really going to mess up back-config. Still, I think having separate
> entries makes sense. That's how I made, for example, the monitor
> interface to "foobar" overlay...
Speaking of which, ITS#4789, were you actually suggesting that back-monitor
also use olcDatabase={x}foo to name its database entries? That would change
its apparent behavior quite a bit from 2.3.
As I mentioned before, I chose not to use a cn=Databases container in
back-config because I didn't want to have to deal with creating a lot of
do-nothing infrastructure entries. Philosophically I also prefer RDNs that
use task-specific attributes; I've always thought cn was too overused... And
if we're using olcDatabase, then e.g.
olcDatabase={1}foo,cn=databases,cn=monitor
is just redundant information, we already know foo is a database so we don't
need the container to remind us of that.
--
-- 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/
16 years, 7 months
Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Pierangelo Masarati
ando(a)sys-net.it wrote:
> The above had nothing to do with your problem. Your problem is related
> to the fact that you intermixed overlay and database configuration
> statements, so the idletimeout statement after the accesslog overlay
> instantiation was causing invalid memory write (beyond the private data
> of the accesslog overlay instead of in the private data of the bdb
> database) resulting in heap corruption.
>
> Maybe it hasn't been stressed enough, but the order of directives is:
I believe the problem is here:
=========================================================================
diff -u -r1.341.2.25 config.c
--- servers/slapd/config.c 8 Feb 2007 12:31:24 -0000 1.341.2.25
+++ servers/slapd/config.c 24 Feb 2007 13:29:42 -0000
@@ -308,13 +308,28 @@
return(0);
}
if(arg_type & ARG_OFFSET) {
- if (c->be && (!overlay_is_over(c->be) ||
- ((slap_overinfo *)c->be->bd_info)->oi_orig ==
c->bi))
- ptr = c->be->be_private;
- else if (c->bi)
+ if ( c->be ) {
+ if (!overlay_is_over(c->be) ||
+ ((slap_overinfo
*)c->be->bd_info)->oi_orig == c->bi)
+ {
+ ptr = c->be->be_private;
+
+ } else {
+ snprintf( c->msg, sizeof( c->msg ),
+ "<%s> statement outside scope "
+ "(after overlay?)",
+ c->argv[0] );
+ Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n",
+ c->log, c->msg, 0);
+ return(ARG_BAD_CONF);
+ }
+
+ } else if ( c->bi ) {
ptr = c->bi->bi_private;
- else {
- snprintf( c->msg, sizeof( c->msg ), "<%s> offset
is missing base pointer",
+
+ } else {
+ snprintf( c->msg, sizeof( c->msg ),
+ "<%s> offset is missing base pointer",
c->argv[0] );
Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n",
c->log, c->msg, 0);
=========================================================================
that is, if both the database and the overlay allow back-config, there
are cases in which config_set_vals() can be called with (arg_type &
ARG_OFFSET) and the c->be points to the database's structure while c->bi
points to the overlay's structure, and the config statement refers to
the database although appearing after the overlay's instantiation.
This is Bad (TM) and should be avoided. However, for example, I have
special needs in back-meta that require to allow overlay instantiation
__before__ the database configuration is complete (in that case, I need
an overlay to be instantiated before targets are defined, so that the
overlay can get per-target configuration parameters much like the
underlying database does). This may defer introduction of back-config
support for back-meta.
Comments?
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
liblber additions
by Howard Chu
We have a port of GNUtls support for OpenLDAP underway. Their certificate DN
parsing APIs are pretty bad. Rather than use their APIs I've modified
libldap's ldap_X509dn2bv function to take a DN in DER form, directly from the
certificate, and parse it directly using liblber. For that purpose I've
needed to add a few new tag definitions as well as a decoder for BER-encoded
OIDs.
Not sure if these should be ber_pvt definitions or just public. Since a
typical LDAP program rarely is faced with real ASN.1 structures it seems we
don't need to expose them. Comments?
Also as a side-effect, we can support certificate parsing, to implement the
certificate-related component matching rules, without needing OpenSSL or any
other crypto library. I.e., I have a complete certificate parser using
liblber. (The code is trivial. We probably should have done this from the
start...)
Something I'd like to revisit - when using liblber and parsing in-place, our
parse is destructive because we NUL-terminate all octet strings. I'm
considering changing this behavior, to leave the original BER data
unmodified. At present it seems this change would have the greatest effect on
Debug output, where we pass ber->bv_val's for printing without any further
qualification. Any thoughts?
as an aside - the fact that GNUtls' certificate DN handling is broken is
worrisome, since issuer DNs are an integral part of certificate path
validation. Until we have time to dig deeper into that code and patch all the
problems, it would be a good idea to avoid using GNUtls.
--
-- 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/
16 years, 7 months
Re: commit: ldap/servers/slapd sasl.c sl_malloc.c connection.c proto-slap.h
by Howard Chu
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> sasl.c 1.245 -> 1.246
> sl_malloc.c 1.40 -> 1.41
> connection.c 1.393 -> 1.394
> proto-slap.h 1.715 -> 1.716
>
> Log Message:
> Added "slapd" rewrite map handler, connection_fake_init2 to use existing
> tmpmemctx without reinitializing
The documentation for this feature presents a bit of a problem, since most of
the functionality of librewrite is documented in slapo-rwm(5). When
SLAP_AUTH_REWRITE is defined (which it is, whenever --enable-rewrite is used)
then all of librewrite's capabilities really should be in the main slapd
documentation.
In the meantime, here's an example usage:
rwm-rewriteMap slapd cn2dn
"ldap:///dc=example,dc=com?dn?sub?(&(objectclass=person)"
rwm-rewriteContext bindDN
rwm-rewriteRule "^(cn=[^,]+),.*" "${cn2dn(($1)))}" ":@I"
This (stupid) example allows a user with a long DN to bind using just their
RDN plus any subset of the DB suffix. E.g, a user with DN
cn=Joe Bob,ou=Team1,ou=Teams,ou=Divisions,dc=example,dc=com
could bind with just cn=Joe Bob,dc=example,dc=com
--
-- 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/
16 years, 7 months
Re: commit: ldap/servers/slapd/schema dyngroup.schema
by Pierangelo Masarati
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/schema
>
> Modified Files:
> dyngroup.schema 1.9 -> 1.10
>
> Log Message:
> Revert memberURL back to STRUCTURAL - test044 breaks otherwise
AFAIR, there's no need in slapo-dynlist(5) code for 'groupOfURLs' (not
'memberUrl' :) to be STRUCTURAL; what test044 does is simply add some
dynamic groups, so reworking the test data should suffice, if you
believe that class should be AUXILIARY. Do you want me to look at that
test with the above change?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
Re: commit: ldap/servers/slapd bconfig.c
by Howard Chu
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> bconfig.c 1.255 -> 1.256
>
> Log Message:
> ITS#4752 add undo for schema entries.
back-config was already cleaning up failed Adds for databases and overlays.
This commit adds another special case for schema entries. A general solution
doesn't really exist, since some attributes just don't support a Delete
operation. But this covers the key object types.
E.g. deleting a moduleLoad directive will be a major problem until we add a
lot of unregister / destroy functions which currently don't exist. (An
overlay like syncprov dynamically registers a schema, a control and the
overlay itself. Each of those needs a tear-down function.
The Modify handler does a more thorough job of undoing things.
--
-- 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/
16 years, 7 months
syncrepl
by Howard Chu
ITS#4618, 4623, 4626 and 4703 all basically have to do with trying to
use multiple replication contexts with a single provider. This is a
behavior that the 2.3 syncprov implementation just wasn't designed for;
it was meant to handle only a single context.
Looking at the ideas in 2.2's syncrepl, it might have gone in the
direction of solving these problems if it weren't weighed down by so
many insurmountable design and implementation flaws. 2.2 probably tried
to do too much too soon, and got waylaid by the devil in the details.
At this point, this solution for multiple contexts presents itself:
1) We assign distinct searchbases to each context.
2) Every distinct source of changes must have its own unique rid. E.g.,
if a database is a provider for a context, it must have an rid. Every
consumer within its namingContext must have their own rid's just as
before. (The new requirement here is assigning rid's to providers that
are masters of their data.)
3) Currently the provider hands a consumer a cookie consisting of the
rid that the consumer supplied, plus a single contextCSN from the
provider. This single contextCSN is inadequate for accurately capturing
all of the changes that may come from multiple sources in a
namingContext. Instead, the provider will send out a cookie consisting
of multiple rid,CSN pairs - one for every rid of the provider's that
resides in the consumer's search space. This is the only reliable way to
make sure that all changes are tracked and propagated.
This says that in general, rids should not need to be configured on
consumers - they should be dictated solely by the providers. It may be a
good idea to allow them to be configured on consumers as an override,
but for now that seems unimportant.
So:
1) the provider must have its own unique rid configured
2) the consumer's rid is optional
3) the provider must be told about all of the consumers living under it
4) the provider must aggregate all of the consumer cookies under it with
its own context info when generating a cookie for its own consumers
Currently slapd treats an entire database as read-only when it has a
consumer configured on it. This raises the question of how to allow
multiple consumers in a single context - should we allow multiple
consumers per DB, as 2.2 tried (and failed) to do, or should we continue
with the current approach of one consumer per DB, and use glue to
collect multiple consumers under one roof?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 7 months
