openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

deleting pwdPolicySubentry attribute
by David Magda 03 Jun '15

03 Jun '15

Hello, "pwdPolicySubentry" is an operational attribute per slapo-ppolicy(5). I was able to add it quite easily, but I can't seem to delete it so an account goes back to using the default policy: $ ldapsearch -H ldap://master -W -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' '(uid=dmagda)' + Enter LDAP Password: # dmagda, People, example.com dn: uid=dmagda,ou=People,dc=example,dc=com structuralObjectClass: inetOrgPerson entryUUID: 1b0d0b6c-1115-1030-8396-1ba5239e5e7d creatorsName: cn=admin,dc=example,dc=com createTimestamp: 20110512185510Z pwdPolicySubentry: cn=service,ou=pwpolicies,dc=example,dc=com entryCSN: 20150602173051.854144Z#000000#000#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20150602173051Z entryDN: uid=dmagda,ou=People,dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: FALSE $ cat del.ldif dn: uid=dmagda,ou=People,dc=example,dc=com changetype: modify delete: pwdPolicySubentry $ ldapsearch -H ldap://master -W -D 'cn=admin,dc=example,dc=com' -f del.ldif Enter LDAP Password: [...] # search result search: 2 result: 32 No such object Given that I could add the attribute, was thought that it could be deleted as well. Thanks for any info. Regards, David

2 2

Where to find attribute description for dn in core.schema
by Stefan Bauer 02 Jun '15

02 Jun '15

Dear Users, I'm trying to understand the LDIF format and wonder in which schema file the attribute 'dn' is defined? I can only find the long form distinguishedName in core.schema. This is the example I'm using for research: dn: dc=structure-net, dc=de objectclass: organization objectclass: top o: Structure Net l: Hamburg postalcode: 21033 streetaddress: Billwiese 22 Any help is greatly appreciated. Regards, Stefan

3 3

Re: read openldap log file
by Luo, Frank 02 Jun '15

02 Jun '15

Can anybody give me a hint about the lines with a "r" in the end? I see a lot of them now. Thanks! Frank Jun 1 09:40:27 slapd[4049]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jun 1 09:40:27 slapd[4049]: daemon: removing 62 Jun 1 09:40:27 slapd[4049]: daemon: activity on 125 descriptors Jun 1 09:40:27 slapd[4049]: daemon: activity on: Jun 1 09:40:27 slapd[4049]: 115r Jun 1 09:40:27 slapd[4049]: conn=274354 fd=62 closed Jun 1 09:40:27 slapd[4049]: 162r Jun 1 09:40:27 slapd[4049]: 148r Jun 1 09:40:27 slapd[4049]: 196r Jun 1 09:40:27 slapd[4049]: 86r Jun 1 09:40:27 slapd[4049]: 201r Jun 1 09:40:27 slapd[4049]: 241r Jun 1 09:40:27 slapd[4049]: 316r Jun 1 09:40:27 slapd[4049]: 143r Jun 1 09:40:27 slapd[4049]: 320r On Mon, Jun 1, 2015 at 10:12 AM, Luo, Frank <luoy(a)miamioh.edu> wrote: > Can anybody give me a hint about the lines with a "r" in the end? I see a > lot of them now. > > Thanks! > > Frank > > > Jun 1 09:40:27 slapd[4049]: daemon: epoll: listen=7 active_threads=0 > tvp=zero > Jun 1 09:40:27 slapd[4049]: daemon: removing 62 > Jun 1 09:40:27 slapd[4049]: daemon: activity on 125 descriptors > Jun 1 09:40:27 slapd[4049]: daemon: activity on: > Jun 1 09:40:27 slapd[4049]: 115r > Jun 1 09:40:27 slapd[4049]: conn=274354 fd=62 closed > Jun 1 09:40:27 slapd[4049]: 162r > Jun 1 09:40:27 slapd[4049]: 148r > Jun 1 09:40:27 slapd[4049]: 196r > Jun 1 09:40:27 slapd[4049]: 86r > Jun 1 09:40:27 slapd[4049]: 201r > Jun 1 09:40:27 slapd[4049]: 241r > Jun 1 09:40:27 slapd[4049]: 316r > Jun 1 09:40:27 slapd[4049]: 143r > Jun 1 09:40:27 slapd[4049]: 320r > > >

2 1

slapadd 4096-character LDIF line length limitation
by Kartik Subbarao 02 Jun '15

02 Jun '15

I wanted to ask if someone could shed some light on the 4096 character LDIF line length limitation, which seems to have been introduced sometime after 2.4.25. I learned about this the hard way, while trying to slapadd an LDIF file with long jpegPhoto attributes (e.g. 50K+) which loaded just fine on 2.4.25. Now, I get this error: ldif_parse_line: jpegPhoto: invalid base64 encoding char (556b9f15 <= str2entry: str2ad(....) slapadd: could not parse entry (line=14) When I need to preprocess LDIF files before loading them with slapadd, I often remove line continuations in order to simplify pattern matching. So of course from my perspective, it would be great to have the previous behavior back again. But if there are compelling reasons for the current behavior, I'd like to suggest that the code print a better error message that explicitly mentions the line length limit. Regards, -Kartik

2 2

nss_ldap: failed to bind to LDAP ser
by Gokan Atmaca 01 Jun '15

01 Jun '15

I installed OpenLDAP. "ldapsearch -x" comes with everything. However, I get an error when I try to connect to the client as follows: Ldapcliet: (/var/log/auth.log) 02:49:58 debian8 nscd: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... May 31 02:49:59 debian8 nscd: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server May 31 02:49:59 debian8 nscd: nss_ldap: failed to bind to LDAP server ldapi://ldap01.gokan.local: Can't contact LDAP server May 31 02:49:59 debian8 nscd: nss_ldap: could not search LDAP server - Server is unavailable ====================== Ldapserver; # ldapsearch -x # extended LDIF # # LDAPv3 # base <dc=gokan,dc=local> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # gokan.local dn: dc=gokan,dc=local objectClass: top objectClass: dcObject objectClass: organization o: gokan dc: gokan # admin, gokan.local dn: cn=admin,dc=gokan,dc=local objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # IT, gokan.local dn: ou=IT,dc=gokan,dc=local objectClass: organizationalUnit objectClass: top ou: IT # Genel, IT, gokan.local dn: cn=Genel,ou=IT,dc=gokan,dc=local gidNumber: 500 cn: Genel objectClass: posixGroup objectClass: top # Gokhan Atmaca, Genel, IT, gokan.local dn: cn=Gokhan Atmaca,cn=Genel,ou=IT,dc=gokan,dc=local cn: Gokhan Atmaca givenName: Gokhan gidNumber: 500 homeDirectory: /home/users/gokhana sn: Atmaca loginShell: /bin/sh objectClass: inetOrgPerson objectClass: posixAccount objectClass: top uidNumber: 1000 uid: gokhana # search result search: 2 result: 0 Success # numResponses: 7 # numEntries: 6 ====================== Listening to the socket. tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 4409/slapd tcp6 0 0 :::389 :::* LISTEN 4409/slapd What could be the problem?

2 1

LDAP schema issue
by Leander Schäfer 01 Jun '15

01 Jun '15

Hi This is the current relevant part of my schema: attributetype ( objectClassAccount:1.1 NAME 'mailAddress' DESC 'The hosted mail addresses' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) 1. How can I achieve, that upper case will always and only be stored as lower case? 2. How do I achieve a validation check whether the value is actually a valid email addres - very simple: user(a)domain.tld? Thanks & Best regards Leander

3 2

Create Mailing List
by Jerry 01 Jun '15

01 Jun '15

Is it possible to create a "mailing list" in openldap? My MUA allows me to create an alias like "MyGroup" that would then contain all the email addresses of the people in the group. I can then simply type that alias and it is replaced by the actual email addresses. I am looking for something like that in openldap. I realize that I can associate multiple email addresses to a single name; however, only one address can be chosen at a time. -- Jerry

4 3

filling up, flushing and inserting again sometimes fails
by Dominik Taborsky 29 May '15

29 May '15

Hello, I'm playing around with LMDB and I'd like to know more about how it deletes items and reclaims space. I've been having some problems with this lately. For simplicity I'm testing smaller 20MiB DBs with data values of sizes from 40B to 4000B. The test checks all kinds of stuff, but mainly tries to do a few fillups and flushes in short sequence. The first cycle slowly increases the size of the data until the DB is full, then it flushes. Then 10 cycles of fillup-flush of static-sized data follow. For flushing I've been doing both mdb_drop and removing batches of stored data. I've tried batches of sizes between 2 and 100 items. The results differ very much, depending on all these parameters: (only the 10 equal cycles counted): batch:2, data size: 40B first three runs pass, 7 fail batch:50, data size: 40B first three runs pass, 7 fail batch:100, data size: 40B first three runs pass, 7 fail mdb_drop, data size: 40B first run only passes, all other 9 fail batch:20, data size: 400B all runs pass batch:100, data size: 400B all runs pass mdb_drop, data size: 400B all runs pass batch:2, data size: 4000B all runs pass batch:50, data size: 4000B first run only passes, all other 9 fail batch:100, data size: 4000B first run only passes, all other 9 fail mdb_drop, data size: 4000B all odd runs pass, all even runs fail Note: I've implemented a simple protection from hitting MDB_MAP_FULL by some arithmetic over fields in MDB_stat and MDB_envinfo structures. The protection reserves at least 32 pages - every insert checks whether it would violate this reservation and if so returns with an error. I've read through a previous thread[1] which was similar in its nature. From that I gathered I need 3 cleanup commits to reclaim all that space. This would explain why the 4000-byte runs succeeded only when flushing using batches of 2 (about 40 4KB-sized items fit into the DB). But it doesn't explain the 40-byte runs which should all succeed apart from the mdb_drop version. And I have no idea why mdb_drop works well in the 400-byte-sized case. Can anybody shed some light into this for me, please? What can I do about it? I need to provide some guarantee the DB will stay functional after fillup. Thanks, Dominik [1] http://www.openldap.org/lists/openldap-technical/201306/msg00116.html

1 1

H350
by Charles Hindmarsh 28 May '15

28 May '15

Good afternoon I'm new to the Open LDAP software, but I have configured it on a windows server and all looks good. I now need to add a h350 schema to the installation and wondered if anyone had come across or developed a h350 schema file. I did try and follow some instructions found here : http://www.manualslib.com/manual/666642/Tandberg-Vcs.html?page=182 however the process failed under the first instruction : dn: commUniqueld=LeedsMeetingroom1, ou=h350, dc=TTGROUP, dc=com I am able to add other user objects etc, so the LDAP service is working. I am guessing that the dn "commUniqueld" value is misunderstood by openLdap and therefore fails. Any help would be greatly appreciated. Charles Hindmarsh Turner & Townsend Turner & Townsend plc Queen’s Award for Enterprise: International Trade 2014 Construction Consultant of the Year | Building Awards 2014, 2013 Global Consultant of the Year | NCE/ACE Consultants of the Year 2013 Outstanding International Business | British Expertise International Awards 2013 For further information and registration details visit our website http://www.turnerandtownsend.com This email and any attachments (“the email”) is confidential and may also be privileged, is subject to copyright and may be read, copied and used only by the intended recipient. The recipient is responsible for virus checking this email. If you are not the intended recipient please immediately notify us, delete and do not use, disclose, distribute, copy, print or rely on this email or any part of it. Turner & Townsend does not accept any liability for any loss or damage from your receipt or use of this email. Please consider the environment before printing this email.

4 5

hiding a naming context
by Craig White 26 May '15

26 May '15

Back with a further clarification and trying to solve a problem for our programmers. ldapsearch -x -H ldapi:/// -s base -b '' namingContext "*" + -D $ROOTDN -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContext * + # # dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: cn=accesslog namingContexts: dc=example,dc=com monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN supportedSASLMechanisms: EXTERNAL entryDN: subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So our programmers want me to filter out 'namingContexts: cn=accesslog' for them (please don't ask). # cat naming_context.ldif dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext val/distinguishedNameMatch="cn=accesslog transitional" by * none ldapmodify -H ldapi:/// -Y EXTERNAL -f naming_context.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> handler exited with 1 Anyone want to hit me with a clue stick so I can hide the 'cn=accesslog' database from my programmers so they don't have to rewrite code?

4 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical