openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

V 2.4.x schema extensions
by Bryce Powell 04 Oct '11

04 Oct '11

Hi, I need an attribute to store password expiry date for the inetOrgPerson objectClass entries in my directory. Since I could not find this or similar attribute in the existing set of schemas (including the ppolicy schema), I have tried to implemented an extension in a custom local.schema: objectclass ( 1.3.6.1.4.1.22280.1021.4.1 NAME 'x-sdids-enPortal' DESC 'Indicates that this entry has additional attributes used by enPortal.' AUXILIARY ) # The "MAY" directive below prevents slapd form starting, and is therefore commented out. # MAY 1.3.6.1.4.1.22280.1021.3.1 ) attributeType ( 1.3.6.1.4.1.22280.1021.3.1 NAME 'x-sdids-passwordExpirationTime' DESC 'TELUS defined password policy attribute type used by enPortal.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE userApplications ) I figured the best bet would be an auxiliary objectClass. After including the new local.schema file in the slapd.conf, and restarting slapd, I get an error when trying to add the new attribute value to an existing or new inetOrgPerson entry: Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 MOD dn="uid=john(a)abc.com,ou=CUSTOMER,ou=Users,dc=private,dc=sdi" Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 MOD attr=x-sdids-passwordExpirationTime Oct 4 10:37:43 vmsdildap04 slapd[31176]: Entry (uid= john(a)abc.com,ou=CUSTOMER,ou=Users,dc=private,dc=sdi), attribute 'x-sdids-passwordExpirationTime' not allowed Oct 4 10:37:43 vmsdildap04 slapd[31176]: entry failed schema check: attribute 'x-sdids-passwordExpirationTime' not allowed Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 RESULT tag=103 err=65 text=attribute 'x-sdids-passwordExpirationTime' not allowed I believe this error 65, as per the OpenLDAP docs, is: H.35. objectClassViolation (65) Indicates that the entry violates object class restrictions. The value I am specifying for the attribute is 20111004164129Z I have also tried to first add an objectClass attribute value to an existing entry with value 'x-sdids-enPortal', and then add the 'x-sdids-passwordExpirationTime' attribute value, with the same outcome. Thanks, Bryce Powell

3 2

connection problem with ldapmodify -Y EXTERNAL -H ldapi:///
by Andreas Rudat 04 Oct '11

04 Oct '11

Hello, everytime I try *ldapmodify -Y EXTERNAL -H ldapi:///* * I get the following SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 and thats all, same with password (-W), it stopped at all and no log messages. Thanks Andreas *

4 11

Re: Login takes more time (LDAP)
by vijay s sheelavantar 04 Oct '11

04 Oct '11

Hello, This was problem with the directory permissions where cacert.pem file was stored. The directory on the client machine had the permissions "drwx------" but the correct permission required was "drwxr-xr-x" this. I changed the directory permissions where cacert.pem file is stored on client machine to "drwxr-xr-x" and now there is no delay. This problem is fixed now.  Thank you very much. Warm Regards,VIJAY S.

1 0

Re: Login takes more time (LDAP)
by vijay s sheelavantar 04 Oct '11

04 Oct '11

Hi,I followed your suggestions, I have set 'UseDNS no' in sshd_config and restarted sshd. I tried 'getent passwd' and 'getent group' there is no delay in the output of these commands. I tried to create home directory after login using pam_mkhomedir.so but failed.  I am getting delay only while login. I am getting below errors during login. Please see the below error and kindly help me to fix this delay problem. Last login: Fri Sep 30 15:22:53 2011 from 10.254.194.148Could not chdir to home directory /home/kim: No such file or directoryid: cannot find name for user ID 105-bash-3.2$ Thanks and Regards,Vijay S.

3 2

Different replication methods in OpenLDAP 2.4
by Bob Fitch 03 Oct '11

03 Oct '11

Hi, I'm trying to correctly conceptualize the different replication models in OpenLDAP 2.4 and I'm a little unsure if I have my facts right. As far as I can tell from the OpenLDAP 2.4 Administrator's Manual the following is true: LDAP Sync Replication (a.k.a syncrepl) - Single Master Replication - Provides HA for reads to the directory but not for writes. - Provides data consistency - Replicates all attributes of the modified DN, even the unchanged ones. Delta Sync Replication - Single Master Replication - Provides HA for reads to the directory but not for writes - Provides data consistency - Replicates only the modified attributes of the modified DN N-Way Multi-Master Replication - As the name suggests, Multi-Master Replication - Provides HA for reads and writes to the directory. - Does not provide data consistency MirrorMode Replication - Hybrid between SMR and MMR - Creates chicken and egg problem with regards to HA - external frontend is a potential failure point and must also be made HA - Provides HA for reads and writes to the directory (assuming external frontend is made HA) - Both OpenLDAP servers can replicate changes to each other, however all directory writes are forced through one server at a time by the external frontend. - Provides data consistency - Does not support Delta Sync Repl (yet) Unfortunately I do not have the capacity to test MirrorMode Replication, so I was hoping I could hear from someone who has practical experience with it to let me know if I'm off-base there. Also, does N-Way Multi-Master Replication support Delta Sync Replication? Unlike MirrorMode Replication which specifically denotes that it can't, the section on N-Way Multi-Master Replication doesn't implicitly say one way or another. I guess I could assume then that it does, but I'd prefer not to - you know what they say about assumptions ;-) Many thanks in advance, Bob

2 1

Core dump in ldap_unbind_ext_s
by sachinv1821＠gmail.com 03 Oct '11

03 Oct '11

I have a wrapper manager code on top of openldap stack(ver.2.4.11), there manager code is responsible for creating the ldap connecting to the LDAP servers by using the standard ldap API(). u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } return LDAPRC_SUCCESS; by using this wrapper code I am creating many ldap links ,most of time this is working fine some times when the ldap_sasl_bind() returns -1 (can't contact server) or unknown error the code is crashing in ldap_unbind_ext_s. can anyone help out. the log and gdb trace are pasted below (gdb) bt #0 ldap_free_request (ld=0x16fd370, lr=0x1010001020001) at request.c:866 #1 0x00000000005372e8 in ldap_ld_free (ld=0x16fd370, close=1, sctrls=<value optimized out>, cctrls=<value optimized out>) at unbind.c:88 #2 0x000000000044b020 in LdapConnection::connect (this=0x157bcd0, loginDN=0x157b3ec "cn=TASuser", pwd=<value optimized out>) logs.. <18:06:56.414 **ERR** LDAP 22603:22470 3:0><LdapConnection.cpp(171)>:connect: LDAP Bind send Failed:Can't contact LDAP server <18:06:56.414 *WRN* MX 22603:22470 3:0>receive SEGV signal <18:06:56.414 *WRN* MX 22603:22470 3:0>Message dump is disabl Regards, Sachin Vastrad

2 1

ldapscripts
by Andreas Rudat 03 Oct '11

03 Oct '11

Hello, if I try to ad auser with ldapadduser I get the error >> 10/01/11 - 19:29 : Command : /usr/sbin/ldapadduser andi test ldap_add: No such object (32) matched DN: dc=foo,dc=intern Error adding user andi to LDAP but it's not a problem to add groups

2 1

translucent proxy add more then one group to user on proxy side
by joaosf 03 Oct '11

03 Oct '11

Hi All, I have a translucent proxy who connect's to other ldap server. I need this kind of solutions because I need to manage groups by my own. So, when a user connect over my translucent proxy everything goes ok, gets the password from the backend ldap server and groups, but user just see the prefered group of my translucent proxy (I have more) and the groups of the backend ldaps. I want the user to see all groups of my translucent proxy, is this possible, do I miss something? Thanks, João SF

1 0

[Re: ldap proxy acl filter problem]
by Ron Peterson 03 Oct '11

03 Oct '11

Had to turn away from this problem to deal w/ other stuff, but it's still an issue for me. Does anyone have a working example of a working proxy configuration they would be willing to share that: * includes a filter expression restricting the result set * allows you to query for the value of an individual attribute I would be very grateful. Right now I'm thinking I may try a different tack: put the filter expression on the master directory in an acl specific to the proxy base dn I'm dealing with. -Ron- ----- Forwarded message from Ron Peterson <rpeterso(a)mtholyoke.edu> ----- Date: Fri, 16 Sep 2011 09:25:41 -0400 From: Ron Peterson <rpeterso(a)mtholyoke.edu> To: Howard Chu <hyc(a)symas.com> Subject: Re: ldap proxy acl filter problem Organization: Mount Holyoke College X-Spam-Score: -0.504 () RP_MATCHES_RCVD Cc: openldap-technical(a)openldap.org 2011-09-15_08:22:54-0400 Ron Peterson <rpeterso(a)mtholyoke.edu>: > 2011-09-14_16:54:56-0400 Howard Chu <hyc(a)symas.com>: > > >I've turned my logging way up, and the hiccup seems to be that the DN > > >I've authenticated as > > >(uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read > > >access to the attributes in the filter expression. But how do I give > > >that account read access to those attributes, without then exposing the > > >objects that I'm trying to hide with the filter expression? > > > > Give it auth access, not read access. My previous example had too much going on for any sane person to wade through, so I've distilled this configuration down to illustrate the essence of the problem. No fancy rewrite rules, etc. The problem remains: adding a filter expression makes it impossible to query the value of particular attributes, although I can retrieve the entire object. It must be possible to filter the result set in a back-ldap proxy setup when querying for particular attributes, but how? ________________________________________________________________________ ldaprc like: BASE ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu BINDDN uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu URI ldap://dirt.mtholyoke.edu SIZELIMIT 40000 TLS_CACERT /local/etc/cert/ca/cacert.pem ________________________________________________________________________ proxy config like: database ldap suffix "ou=accounts,ou=prod,dc=mtholyoke,dc=edu" uri "ldapi://%2Fvar%2Frun%2Fslapd%2Fmastertest%2Fldapi" access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" attrs="entry" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" read by * none # log file (see below) seems to indicate proxy wants search permission on this attribute, # but this doesn't help access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" attrs="yApplicationPermission" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" search by * none access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" filter="(yApplicationPermission=email)" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" read by * none ________________________________________________________________________ (1) This query works (returns all attributes): ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' (2) This query does not (only returns DN, but not yPrimaryEmail): ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' yPrimaryEmail ________________________________________________________________________ Log for both master and proxy database (loglevel 256 128 64 32), for query (2) above: pid 32160 = proxy server pid 24268 = master directory server Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 ACCEPT from IP=138.110.86.129:51010 (IP=138.110.86.129:389) Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 STARTTLS Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 RESULT oid= err=0 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 TLS established tls_ssf=256 ssf=256 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" method=128 Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 ACCEPT from PATH=/var/run/slapd/mastertest/ldapi (PATH=/var/run/slapd/mastertest/ldapi) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" method=128 Sep 16 09:17:41 mid slapd[24268]: => access_allowed: result not in cache (userPassword) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: auth access to "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "userPassword" requested Sep 16 09:17:41 mid slapd[24268]: => acl_get: [1] attr userPassword Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "userPassword" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: self Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: anonymous Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [2] applying auth(=xd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [2] mask: auth(=xd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: auth access granted by auth(=xd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: auth access granted by auth(=xd) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" mech=SIMPLE ssf=0 Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 RESULT tag=97 err=0 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" mech=SIMPLE ssf=0 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 RESULT tag=97 err=0 text= Sep 16 09:17:41 mid slapd[32160]: begin get_filter Sep 16 09:17:41 mid slapd[32160]: EQUALITY Sep 16 09:17:41 mid slapd[32160]: end get_filter 0 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SRCH base="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" scope=2 deref=0 filter="(yUsername=rpeterso)" Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SRCH attr=yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SRCH base="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" scope=2 deref=0 filter="(yUsername=rpeterso)" Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SRCH attr=yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access to "ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] attr entry Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yUsername" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => dn: [4] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] attr yUsername Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "yUsername" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] attr entry Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: result not in cache (yPrimaryEmail) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => dn: [4] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] attr yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[32160]: => dn: [1] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] matched Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] attr entry Sep 16 09:17:41 mid slapd[32160]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[32160]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[32160]: <= check a_dn_pat: uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[32160]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: result not in cache (yPrimaryEmail) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[32160]: => dn: [1] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] matched Sep 16 09:17:41 mid slapd[32160]: => dn: [2] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [2] matched Sep 16 09:17:41 mid slapd[32160]: => dn: [3] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[32160]: => test_filter Sep 16 09:17:41 mid slapd[32160]: EQUALITY Sep 16 09:17:41 mid slapd[32160]: => access_allowed: search access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yApplicationPermission" requested Sep 16 09:17:41 mid slapd[32160]: <= test_filter 5 Sep 16 09:17:41 mid slapd[32160]: <= acl_get: done. Sep 16 09:17:41 mid slapd[32160]: => slap_access_allowed: no more rules Sep 16 09:17:41 mid slapd[32160]: => access_allowed: no more rules Sep 16 09:17:41 mid slapd[32160]: send_search_entry: conn 1001 access to attribute yPrimaryEmail, value #0 not allowed Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=3 UNBIND Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=2 UNBIND Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 closed Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 closed Sep 16 09:17:41 mid slapd[24268]: connection_read(13): no connection! Sep 16 09:17:41 mid slapd[24268]: connection_read(13): no connection! -- Ron Peterson Network & Systems Administrator Mount Holyoke College http://www.mtholyoke.edu/~rpeterso ----- End forwarded message -----

1 0

back-sql usage
by Worgan, Craig (Craig) 02 Oct '11

02 Oct '11

Hi, The documentation for back-sql indicates that it is experimental and warns against using it in a production environment. It also says that it is not intended as a general purpose back-end for OpenLDAP. My organization is looking at doing both of those things and I am trying to convince them not to do so. It is proving to be a difficult thing to do. Initially, I found the results of a performance analysis of back-sql that showed it was significantly slower than BDB and used that as an argument. I was asked to prove it so I built a prototype. The prototype showed that, at least for our purposes, performance was not an issue. Now I am falling back on the documentation, but very few people are listening. I fear that if we continue down the path we are on we will face significant problems with back-sql. I was hoping someone on the list could provide me with more concrete technical information as to why back-sql should not be used as a general purpose backend for OpenLDAP and/or in a production environment. Any information is greatly appreciated. Thanks, Craig Worgan Avaya| System Management Solutions | 250 Sidney Street | Belleville, Ontario Canada K8N 5B7 | (613) 967-5233 | worganc(a)avaya.com<mailto:worganc@avaya.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical