openldap-software June 2008

openldap-software@openldap.org

62 participants
64 discussions

Supported RFC's and "features"
by Clowser, Jeff (Contractor) 13 Jul '09

13 Jul '09

I'm currently doing a review to see how OpenLDAP compares, *feature wise* ATM, to other directory servers and specifically to the Sun DS - i.e. to get a definitive list of features it's missing that Sun has and what it has that Sun doesn't have, etc. For brevity, I haven't included all the potentially useful features of OpenLDAP, but have just focused on those associated with 1) RFC compliance (of which Sun may or may not meet) and 2) features to match the Sun DS (which it would be replacing). So far, here's what I have for OpenLDAP: RFC 4510 (which includes 4511-4519). There was recent discussion on the list around this, such that in some cases, not everything that changed from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been updated in OpenLDAP, but I think those issues are fairly minor. The following additional RFC's are supported in OpenLDAP: - RFC 2247 and RFC 3088 - RFC 2696 simple paged results - RFC 2849 ldif - RFC 3062 password mod op - RFC 3296 named referals, manageDSAit - RFC 3673 All Op attrs + feature - RFC 3687 Component matching rules - RFC 3866 Languange tag and range - RFC 3876 matched values control - RFC 4370 proxy auth - RFC 4522 binary encoding - RFC 4523 x.509 cert schema - RFC 4524 COSINE schema - RFC 4525 Mod-increment - RFC 4526 Absolute true/false filters - RFC 4527 pre/post read control - RFC 4528 assertion control - RFC 4529 request attrs by objectclass - RFC 4530 entryUUID - RFC 4532 whoamI - RFC 4533 Content Sync op (replication) RFC's NOT supported are: - RFC 2589 dds Seems with 2.4, this has gone from experimental to production quality? - RFC 2891 server side sorting - RFC 3671 collective attributes - RFC 3928 LCUP mainly for updating cached addressbooks, etc - not replication between servers - RFC 3384 looks like just reqs for replication, not an actual replication protocol - RFC 4533 is used instead Unknown: - RFC 3672 (subentries) - RFC 3698 and 3727 (additional matching rules) - RFC 3909 LDAP Cancel operation - RFC 5020 entryDN operational attribute (There are some other, often obscure, LDAP related RFC's that I didn't include, but this seems to be the major/useful ones) Other features not supported: - VLV browse indexes (per http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an RFC, but supported by Sun and MS directories, and used by things like Outlook and Solaris. Other supported features: - dyngroup/dynlist/memberof overlay (A much more useful feature than Sun's groupOfURLs "dynamic" group and "roles" mechanism) - ppolicy overlay (matches Sun DS 5.x reasonably close, but is account lockout replicated to all servers? Sun DS 6.x claims to) - refint overlay (similar to Sun's referential integrity plugin) - unique overlay (similar to Sun's uniqueness plugin) - audit and accesslog overlays, syslog logging - much more useful/complete than Sun's access/audit/error logs. - live acl changes via LDAP Unknown features: - Per user resource limits (sizelimit, timelimit, idletimeout, etc). I think Howard Chu said OpenLDAP has some of this, but I haven't seen any reference to it or how to use it in the docs (does this functionality exist, and if so, is there any documentation?) - Tracking of last login (i.e. last successful ldap authentication) Is this still fairly accurate? The ones that are really problematic are the lack of: - VLV Browse indexes - RFC 2891 (server side sorting) - per user/entry resources limits (if they don't exist) Are there any unofficial updates/patches/overlays/plans for any of this functionality? Thanks, - Jeff

11 29

Chaining
by Jorge Medina 03 Jul '08

03 Jul '08

One more question, this time on the chaining overlay. "What is chaining? It indicates the capability of a DSA to follow referrals on behalf of the client, so that distributed systems are viewed as a single virtual DSA by clients that are otherwise unable to "chase" (i.e. follow) referrals by themselves." In the example shown at http://www.openldap.org/doc/admin24/overlays.html#Chaining Is the chaining overlay example used to forward write requests from the syncrepl slaves to the master server? -Jorge

2 3

ACL Help Please
by david stackis 02 Jul '08

02 Jul '08

Hello List - Please forgive my ignorance regarding the ACL's in OpenLDAP. For Starters I'm using OpenLDAP Software 2.4, and I've obtained the software from sunfreeware.com. OpenLDAP is running on a Solaris 10 Sparc system. My goal is to have each one of my user able to read/write to their own personal address book. I've added my initial LDIF file, and configured slapd as best I could understand. I can ldapadd using the root dn, and I can see all of the entries that I added using ldapsearch. However when I try to add to my personal entry, I receive this error. ldapadd -D "cn=Elliott Smith,ou=users,dc=Company,dc=com" -f contact.ldif Enter bind password: adding new entry cn=Nick Drake,ou=addressbook,dc=Company,dc=com ldap_add: Insufficient access ldap_add: additional info: no write access to parent Below are my LDIF and slapd. I want to express that I have read through as much of this list as I could regarding the "no write access to parent", and I've found many have similar issues. I feel that my setup is fairly straight forward. Any help is much appreciated. Let me know if you need more information. The LDIF I used to begin... # Initialize the suffix entry defined in slapd.conf # dn: dc=company,dc=com objectclass: top objectclass: dcObject objectclass: organization dc: company o: corporate # # Initialize the AddressBooks heirarchy # dn: ou=addressbook,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: addressbook # # Define individual address books # dn: o=hr,ou=addressbook,dc=company,dc=com objectclass: top objectclass: organization o: hr # # Initialize the Users heirarchy # dn: ou=users,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: users # # Define individual users # dn: cn=Elliott Smith,ou=users,dc=company,dc=com objectclass: top objectclass: person cn: Elliott Smith sn: Smith userPassword: mysecret uid: esmith The slapd I'm using... # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # # access to dn.regex="(.+,)?(uid=[^,]+,o=isc)$" by dn.exact,expand="$2" write by anonymous auth # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=Company,dc=com" rootdn "cn=root,dc=Company,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq ------------------- david stackis uc santa barbara

3 5

segfaults with syncrepl
by Liutauras Adomaitis 01 Jul '08

01 Jul '08

hello everybody, I'm quite new to OpenLdap. Actually i've been using it for a few years, but I have no deep knowlege. The problem I'm facing is my cosumer replicas are segfaulting. My design: I have one master with several o=BranchX,dc=example,dc=com This is provider. I have several (the number is X-1) replicas, consumers. All consumers are replicating its branch o=BranchX,dc=example,dc=com and one common branch o=BranchMain,dc=example,dc=com. The picture is like this: Provider o=BranchMain,dc=example,dc=com o=Branch1,dc=example,dc=com o=Branch2,dc=example,dc=com ..... o=BranchX,dc=example,dc=com Consumer 1: o=BranchMain,dc=example,dc=com o=Branch1,dc=example,dc=com Consumer 2: o=BranchMain,dc=example,dc=com o=Branch2,dc=example,dc=com At the begining I had one consumer, which was segfaultin just randomly once or twice a day. I decided to comment out my syncrepl directives in conf file and now it is running for a day and half. I should mention, that after cosumer segfaults I cannot start slapd any more. The only solution I have is to delete ol /var/lib/ldap (all database) directory contents and then restarting slapd. If restarting slapd on the old database - segfaulti is happening. Since this was a smaill branch and only one branch I thought to debug the problem later. Today I faced the same situation on a biger consumer. The same situation. slapd just crashed and only deleting database helped me to start it again. My systems are Mandriva 2008.1 with slapd version: @(#) $OpenLDAP: slapd 2.4.8 (Mar 23 2008 16:49:39) $ mandrake(a)klodia.mandriva.com: /home/mandrake/rpm/BUILD/openldap-2.4.8/servers/slapd I have one branch runing old slapd versions (the ones comming with Mandriva 2007.0), but they seem to work except that I can have replicated only one branch (one rid). Seems old slapd doesn't support several rids. Can anybody help me to debug this situation? This configuration is rather new but I was thinking to build all infrastructure on such a configuration, so segfaulting is very big issue. Provider (master) configuration is: include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/corba.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema include /usr/share/openldap/schema/openldap.schema include /usr/share/openldap/schema/samba.schema include /usr/share/openldap/schema/qmail.schema include /etc/openldap/schema/local.schema include /etc/openldap/slapd.access.conf access to dn.subtree="dc=example,dc=com" by group="cn=Replicator,ou=Group,dc=example,dc=com" by users read by anonymous read pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args modulepath /usr/lib64/openldap moduleload syncprov.la TLSRandFile /dev/random TLSCipherSuite HIGH:MEDIUM:+SSLv2+SSLv3 TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCACertificatePath /etc/pki/tls/certs/ TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSVerifyClient never # ([never]|allow|try|demand) database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap checkpoint 256 5 index mailAlternateAddress eq,sub index accountStatus,mailHost,deliveryMode eq index default sub index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index sambaSID,sambaDomainName,displayName eq index entryCSN,entryUUID eq limits group="cn=Replicator,dc=infosaitas,dc=lt" size=unlimited time=unlimited access to * by group="cn=Replicator,dc=infosaitas,dc=lt" write by * read overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 10 Consumers configuration (all the same): include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/corba.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema include /usr/share/openldap/schema/openldap.schema include /usr/share/openldap/schema/samba.schema include /usr/share/openldap/schema/qmail.schema include /etc/openldap/schema/local.schema include /etc/openldap/slapd.access.conf include /etc/openldap/slapd.access.ldapauth.conf access to dn.subtree="dc=example,dc=com" by group="cn=Replicator,ou=Group,dc=example,dc=com" by users read by anonymous read pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args modulepath /usr/lib64/openldap moduleload back_ldap.la TLSCertificateFile /etc/ssl/openldap/ldap.pem TLSCertificateKeyFile /etc/ssl/openldap/ldap.pem TLSCACertificateFile /etc/ssl/openldap/ldap.pem overlay chain chain-uri "ldap://master.server" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=example,dc=com" credentials=secret mode="none" chain-tls start chain-return-error TRUE database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap checkpoint 256 5 index objectClass eq index mailAlternateAddress eq,sub index accountStatus,mailHost,deliveryMode eq index default sub index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index sambaSID,sambaDomainName,displayName eq limits group="cn=Replicator,ou=Group,dc=example,dc=com" size=unlimited time=unlimited syncrepl rid=1 provider=ldap://master.server:389 type=refreshAndPersist retry="60 +" searchbase="o=BranchMain,dc=example,dc=com" filter="(objectClass=*)" scope=sub attrs=* schemachecking=off bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret starttls=yes syncrepl rid=2 provider=ldap://master.server:389 type=refreshAndPersist retry="60 +" searchbase="o=Branch1,dc=example,dc=com" filter="(objectClass=*)" scope=sub attrs=* schemachecking=off bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret starttls=yes updateref ldap://master.server Thanks for any hints on this Liutauras

4 5

Last bind timestamp?
by Pat Riehecky 01 Jul '08

01 Jul '08

At the university we have massive account creep. Alumni keep their accounts and terminated employees would never do anything bad so I generally don't get informed when the leave, drop outs aren't even tracked so who knows... Right now I estimate about 700 accounts that should not even exist. That being said, I would like to reclaim some sanity in my account system. For political reasons I can only ask for one account to be checked for validity at a time... could take a few years to filter through them all.... Thus was a plan hatched.... If there was a way I could store the timestamp of the last successful bind by this user in their entry (similarly to lastmod or create date) then after a year or three anyone who has no entry would be a candidate for further investigation.... Is there a way to make openldap store this data for me? Or must I write some C for an overlay (direct integration into the bind code seems a bad idea since if you don't need this why let it slow you down, and my C is more than a bit rough around the edges)? Pat OpenLDAP 2.4.10 on Linux for what it is worth.

2 4

RE: Mirror Mode
by Jorge Medina 01 Jul '08

01 Jul '08

Also, e) How does the load balancer knows what mirror to use and when to switch to the other? -----Original Message----- From: Jorge Medina Sent: Monday, June 30, 2008 4:39 PM To: 'openldap-software(a)openldap.org' Subject: Mirror Mode Hi, I am trying to configure OpenLDAP in mirror mode. From what I understood, the documentation suggests having two servers configured in mirror mode, plus a set of replicas. (As shown in the diagram at the end of the page at http://www.openldap.org/doc/admin24/replication.html#Configuring%20the%2 0different%20replication%20types) The documentation suggests that the backend LDAP module can be used as the load balancer. Nevertheless the documentation is missing the sections on configuring this module. http://www.openldap.org/doc/admin24/backends.html#LDAP a) I am assuming the replicas are just read-only replicas. Right? b) If a client requires to write to the directory, how are these request forwarded to the active mirror? c) Does anyone knows how to configure the LDAP backend to act as a proxy? d) Is mirror mode mature? Is it ready for production use? Any help or pointers are appreciated. -Jorge

2 1

Mirror Mode
by Jorge Medina 01 Jul '08

01 Jul '08

Hi, I am trying to configure OpenLDAP in mirror mode. From what I understood, the documentation suggests having two servers configured in mirror mode, plus a set of replicas. (As shown in the diagram at the end of the page at http://www.openldap.org/doc/admin24/replication.html#Configuring%20the%2 0different%20replication%20types) The documentation suggests that the backend LDAP module can be used as the load balancer. Nevertheless the documentation is missing the sections on configuring this module. http://www.openldap.org/doc/admin24/backends.html#LDAP a) I am assuming the replicas are just read-only replicas. Right? b) If a client requires to write to the directory, how are these request forwarded to the active mirror? c) Does anyone knows how to configure the LDAP backend to act as a proxy? d) Is mirror mode mature? Is it ready for production use? Any help or pointers are appreciated. -Jorge

2 1

syncprov and translucent
by Andy Cobaugh 30 Jun '08

30 Jun '08

As one might expect, mixing the translucent and syncprov overlays together on top of the same bdb database doesn't work. Because translucent uses back-ldap, lastmod is being set to off, while syncprov needs it to be on in order to function. I wonder if it might be possible to change the behavior of back-ldap to allow lastmod again? In my case, I only care about replicating changes that are stored in the local bdb database by the translucent overlay, and I never send updates back to the target ldap server. I suppose I could come up with something where I slapcat, then let the slaves pick up the ldif and see if it's different from the last time. If it is, shutdown slapd, delete the database files, slapadd, start slapd. I really want to avoid doing that though, since I consider that a hack and a half. Thoughts? Is enabling lastmod for back-ldap just a matter of commenting out some lines? --andy

3 2

modrelay 0.1
by joel reed 30 Jun '08

30 Jun '08

This is an OpenLDAP overlay that intercepts ADD and MODIFY requests for posixAccount and organization type entries, and relays the changes to a postgresql database. This code CANNOT be used anywhere else without modification. Consider it sample code only! Posting only in the spirit of share and share alike. Version 0.2 of the attached code will handle modrdn and delete requests and read the connection string from slapd.conf. This version is simpler. jr /** * modrelay.c * * Copyright (C) 2008 Joel W. Reed * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in file LICENSE in the * top-level directory of the distribution or, alternatively, at * http://www.OpenLDAP.org/license.html. * * SEE LICENSE FOR MORE INFORMATION * * Author: Joel W. Reed * Email: joelwreed(a)gmail.com * Version: 0.1 * Updated: 06.29.2008 * * modrelay * * This is an OpenLDAP overlay that intercepts ADD and MODIFY requests * for posixAccount and organization type entries, and relays the changes to * a postgresql database. */ #include "portable.h" #include <ac/string.h> #include <ac/ctype.h> #include "slap.h" #include "ldif.h" #include "libpq-fe.h" #include "config.h" // TODO: figure out config api #define CONNECTION_STRING "your connection string goes here" static slap_overinst modrelay; static ObjectClass *oc_posix_account; static ObjectClass *oc_organization; static ObjectClass *oc_dcobject; typedef struct modrelay_data { ldap_pvt_thread_mutex_t mutex; PGconn* connection; } modrelay_data; PGconn* get_db_connection(modrelay_data *ad) { // we lazily connect to the db whenever first needed if (ad->connection != NULL) return ad->connection; ad->connection = PQconnectdb(CONNECTION_STRING); if (!ad->connection || (PQstatus(ad->connection) != CONNECTION_OK)) { Debug( LDAP_DEBUG_ANY, "%s: failed to connect to database!\n", modrelay.on_bi.bi_type, 0, 0 ); } return ad->connection; } static void modrelay_process_organization(Operation* op, Entry* entry) { static const char INSERT_SQL[] = "insert into organization (id, version, name, description, mail_host, dn) values (nextval('organization_sequence'), 0, $1, $2, $3, $4)"; static const char UPDATE_SQL[] = "update organization set name=$1, description=$2, mail_host=$3 where dn=$4"; static int PARAM_CNT = 4; slap_overinst* on = (slap_overinst *)op->o_bd->bd_info; modrelay_data *ad = on->on_bi.bi_private; PGconn* connection = get_db_connection(ad); const char* paramValues[PARAM_CNT]; paramValues[0] = paramValues[1] = paramValues[2] = ""; paramValues[3] = entry->e_nname.bv_val; Debug( LDAP_DEBUG_TRACE, "%s: modrelay_response for add/edit organization %s\n", modrelay.on_bi.bi_type, paramValues[3], 0 ); Attribute* attr; for (attr = entry->e_attrs; attr; attr = attr->a_next ) { if (!strcmp(attr->a_desc->ad_cname.bv_val, "o")) paramValues[0] = attr->a_vals[0].bv_val; else if (!strcmp(attr->a_desc->ad_cname.bv_val, "description")) paramValues[1] = attr->a_vals[0].bv_val; else if (!strcmp(attr->a_desc->ad_cname.bv_val, "mailHost")) paramValues[2] = attr->a_vals[0].bv_val; } const char* SQL = (op->o_tag == LDAP_REQ_ADD)? INSERT_SQL : UPDATE_SQL; PGresult* res = PQexecParams(connection, SQL, PARAM_CNT, NULL, paramValues, NULL, NULL, 0); ExecStatusType status = PQresultStatus(res); if (status != PGRES_COMMAND_OK) { Debug(LDAP_DEBUG_ANY, "%s: org database error: (%d) %s\n", modrelay.on_bi.bi_type, status, PQresultErrorMessage(res)); Debug(LDAP_DEBUG_ANY, "%s: SQL: %s o:%s\n", modrelay.on_bi.bi_type, SQL, paramValues[0]); Debug(LDAP_DEBUG_ANY, "%s: desc:%s, mailHost:%s\n", modrelay.on_bi.bi_type, paramValues[1], paramValues[2]); } PQclear(res); } static void modrelay_process_user(Operation* op, Entry* entry) { slap_overinst* on = (slap_overinst *)op->o_bd->bd_info; modrelay_data *ad = on->on_bi.bi_private; PGconn* connection = get_db_connection(ad); static const char INSERT_SQL[] = "insert into person (id, version, first_name, last_name, email_address, dn) values (nextval('person_sequence'), 0, $1, $2, $3, $4)"; static const char UPDATE_SQL[] = "update person set first_name=$1, last_name=$2, email_address=$3 where dn=$4"; static int PARAM_CNT = 4; const char* paramValues[PARAM_CNT]; paramValues[0] = paramValues[1] = paramValues[2] = ""; paramValues[3] = entry->e_nname.bv_val; Debug( LDAP_DEBUG_TRACE, "%s: modrelay_response for add/edit user \n", modrelay.on_bi.bi_type, 0, 0 ); Attribute* attr; for (attr = entry->e_attrs; attr; attr = attr->a_next ) { if (!strcmp(attr->a_desc->ad_cname.bv_val, "givenName")) paramValues[0] = attr->a_vals[0].bv_val; else if (!strcmp(attr->a_desc->ad_cname.bv_val, "sn")) paramValues[1] = attr->a_vals[0].bv_val; else if (!strcmp(attr->a_desc->ad_cname.bv_val, "mail")) paramValues[2] = attr->a_vals[0].bv_val; } const char* SQL = (op->o_tag == LDAP_REQ_ADD)? INSERT_SQL : UPDATE_SQL; PGresult* res = PQexecParams(connection, SQL, PARAM_CNT, NULL, paramValues, NULL, NULL, 0); ExecStatusType status = PQresultStatus(res); if (status != PGRES_COMMAND_OK) { Debug(LDAP_DEBUG_ANY, "%s: user database error: (%d) %s\n", modrelay.on_bi.bi_type, status, PQresultErrorMessage(res)); } PQclear(res); if (op->o_tag == LDAP_REQ_ADD) { struct berval usersdn, orgdn; dnParent(&entry->e_nname, &usersdn ); dnParent(&usersdn, &orgdn); Debug( LDAP_DEBUG_TRACE, "%s: modrelay_response linking user: %s to org: %s \n", modrelay.on_bi.bi_type, entry->e_nname.bv_val, orgdn.bv_val ); static const char LINK_SQL[] = "insert into organization_person (organization_person_id, person_id) values ((select id from organization where dn=$1), (select id from person where dn=$2))"; paramValues[0] = orgdn.bv_val; paramValues[1] = entry->e_nname.bv_val; res = PQexecParams(connection, LINK_SQL, 2, NULL, paramValues, NULL, NULL, 0); status = PQresultStatus(res); if (status != PGRES_COMMAND_OK) { Debug(LDAP_DEBUG_ANY, "%s: user link database error: (%d) %s\n", modrelay.on_bi.bi_type, status, PQresultErrorMessage(res)); } PQclear(res); } } static int modrelay_response( Operation *op, SlapReply *rs ) { slap_overinst* on = (slap_overinst *)op->o_bd->bd_info; modrelay_data *ad = on->on_bi.bi_private; Entry* entry = NULL; /* if error no point in continuing */ if ( rs->sr_err != LDAP_SUCCESS ) return SLAP_CB_CONTINUE; switch (op->o_tag) { case LDAP_REQ_ADD: entry = op->ora_e; break; case LDAP_REQ_MODIFY: if ( overlay_entry_get_ov( op, &op->o_req_ndn, NULL, NULL, 0, &entry, on ) != LDAP_SUCCESS || entry == NULL ) { Debug( LDAP_DEBUG_ANY, "modrelay_response MODIFY cannot get entry for <%s>\n", op->o_req_dn.bv_val, 0, 0); return SLAP_CB_CONTINUE; } break; default: return SLAP_CB_CONTINUE; } ldap_pvt_thread_mutex_lock(&ad->mutex); /* is this a object class we care about */ if (is_entry_objectclass( (entry), oc_posix_account, 0)) modrelay_process_user(op, entry); else if ((is_entry_objectclass( (entry), oc_organization, 0))&& (is_entry_objectclass( (entry), oc_dcobject, 0))) modrelay_process_organization(op, entry); ldap_pvt_thread_mutex_unlock(&ad->mutex); if (op->o_tag == LDAP_REQ_MODIFY) overlay_entry_release_ov( op, entry, 0, on ); return SLAP_CB_CONTINUE; } static int modrelay_delete(Operation *op, SlapReply *rs ) { return SLAP_CB_CONTINUE; } static int modrelay_db_init(BackendDB *be, ConfigReply *cr) { slap_overinst *on = (slap_overinst *)be->bd_info; modrelay_data *ad = ch_calloc(1, sizeof(modrelay_data)); on->on_bi.bi_private = ad; ldap_pvt_thread_mutex_init( &ad->mutex ); ad->connection = NULL; return 0; } static int modrelay_db_destroy(BackendDB *be, ConfigReply *cr) { slap_overinst *on = (slap_overinst *)be->bd_info; modrelay_data *ad = on->on_bi.bi_private; ldap_pvt_thread_mutex_destroy( &ad->mutex ); if (ad->connection != NULL) PQfinish(ad->connection); free( ad ); return 0; } int modrelay_init() { modrelay.on_bi.bi_type = "modrelay"; modrelay.on_bi.bi_db_init = modrelay_db_init; modrelay.on_bi.bi_db_destroy = modrelay_db_destroy; modrelay.on_response = modrelay_response; modrelay.on_bi.bi_op_delete = modrelay_delete; oc_posix_account = oc_find( "posixAccount" ); if(oc_posix_account == NULL) { Debug( LDAP_DEBUG_ANY, "%s: unable to find default ObjectClass \"posixAccount\".\n", modrelay.on_bi.bi_type, 0, 0 ); return -1; } oc_organization = oc_find( "organization" ); if(oc_organization == NULL) { Debug( LDAP_DEBUG_ANY, "%s: unable to find default ObjectClass \"organization\".\n", modrelay.on_bi.bi_type, 0, 0 ); return -1; } oc_dcobject = oc_find( "dcObject" ); if(oc_dcobject == NULL) { Debug( LDAP_DEBUG_ANY, "%s: unable to find default ObjectClass \"dcObject\".\n", modrelay.on_bi.bi_type, 0, 0 ); return -1; } return ( overlay_register(&modrelay) ); } int init_module( int argc, char *argv[] ) { return modrelay_init(); }

1 0

automatic uidnumber overlay version 0.2
by joel reed 30 Jun '08

30 Jun '08

Please find attached version 0.2 of the uidnumber overlay I posted previously (http://www.openldap.org/lists/openldap-software/200806/msg00029.html). This version does not search the directory every time a posixAccount add entry request comes in - only the first time such a request is made to the directory. Subsequent requests are processed via the cached next uidNumber overlay data. This version of the overlay tracks the next uidNumber per database (the previous version used a static, overlay scoped variable). Just posting in case anyone ever finds it of use for their environment. jr

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software June 2008