openldap-technical

openldap-technical@openldap.org

1 participants
9898 discussions

Mingw regex compile issue
by Rasmus Schram 02 Feb '10

02 Feb '10

Hello I am trying to compile the openldap v. 2.4.19 client api with MingW and Msys. It will successfully make the configure command, but when I try to make, it complains about not having a shared version of the regex library. I have tried to use both 'mingw-libgnurx-2.5.1' and 'regex-0.12' but with no luck. I am only interested in building the client api libraries, but the error results in only building a static version of the library and I really need the shared dll's instead. This is the Warning/issue I get trying to compile. --------------------------------------------------------------------- /bin/sh ../../libtool --mode=link gcc -g -O2 -no-undefined -avoid-version -rpath /usr/local/lib -o liblber.la assert.lo decode.lo encode.lo io.lo bprint.lo debug.lo memory.lo options.lo sockbuf.lo nt_err.lo version.lo -lregex -lws2_32 *** Warning: linker path does not have real file for library -lregex. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libregex and none of the candidates passed a file format test *** using a file magic. Last file checked: /bin/libregex.a *** Warning: linker path does not have real file for library -lws2_32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2_32 and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib/gcc/mingw32/3.4.5/../../..//libws2_32.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. --------------------------------------------------------------------- I have tried various options but cannot find the cause of the problem. Any help would be appreciated. Regards Rasmus _________________________________________________________________ NY Windows Live Messenger med nye fede funktioner. Hent den her! http://download.live.com/messenger

1 1

refint overlay don't works as expected
by Sergei Butakov 01 Feb '10

01 Feb '10

Hi I'm using refint and memberof overlays. Refint overlay don't works as expected - it don't modifying one entry: uid=admin,ou=Users,dc=domain.local (which is a member of cn=webers,ou=Groups,dc=domain.local - see dump.ldif attachment). Changing the memberof-dangling option in the memberof overlay don't help. If I turn off the memberof overlay or move this entry to the end of dump.ldif file (after cn=webers,ou=Groups,dc=domain.local) then the refint overlay works as needed. Can somebody retest it or say where I'm wrong? Steps to reproduce: 1) stop slapd 2) copy the files (slapd.conf, bsl.schema, dump.ldif) from the attachment to the apropriate places. Correct the pathes (include, directory) in slapd.conf file. 3) rm -rf /path/to/openldap-data/* 4) slapadd -l dump.ldif 5) chown -R ldapd:ldapd openldap-data (use your own ldap user) 6) start slapd 7) test #1: $ ldapsearch -LLL -D cn=manager -w 1 -b "" '(cn=webers)' member dn: cn=webers,ou=Groups,dc=domain.local member: uid=admin,ou=Users,dc=domain.local member: uid=u1,ou=Users,dc=domain.local $ ldapsearch -LLL -D cn=manager -w 1 -b "" '(uid=*)' memberOf dn: uid=admin,ou=Users,dc=domain.local memberOf: cn=webers,ou=Groups,dc=domain.local dn: uid=u1,ou=Users,dc=domain.local memberOf: cn=webers,ou=Groups,dc=domain.local All OK. 8) now rename dc=domain.local: $ ldapmodrdn -r -D cn=manager -w 1 dc=domain.local dc=example.org -v ldap_initialize( <DEFAULT> ) Renaming "dc=domain.local" new rdn="dc=example.org" (delete old rdn) Rename Result: Success (0) 9) check #2: $ ldapsearch -LLL -D cn=manager -w 1 -b "" '(cn=webers)' member dn: cn=webers,ou=Groups,dc=example.org member: uid=admin,ou=Users,dc=example.org member: uid=u1,ou=Users,dc=example.org $ ldapsearch -LLL -D cn=manager -w 1 -b "" '(uid=*)' memberOf modifiersName dn: uid=admin,ou=Users,dc=example.org memberOf: cn=webers,ou=Groups,dc=domain.local memberOf: cn=webers,ou=Groups,dc=example.org modifiersName: cn=Manager dn: uid=u1,ou=Users,dc=example.org memberOf: cn=webers,ou=Groups,dc=example.org modifiersName: cn=Referential Integrity Overlay Error: refint overlay didn't change the uid=admin entry. -- Regards, Sergei Butakov

1 1

ACLs based on attributes?
by Jaap Winius 01 Feb '10

01 Feb '10

Hi all, Is it possible to define an ACL that gives a DN access to a particular attribute in other DNs based on the value of one of its own attributes? For example, would it be possible to define an ACL that would allow a DN with title=telephonemanager to update only the telephoneNumber attribute of other DNs? In other words, the ACL would allow updates to telephoneNumber, but only for search filter title=telephonemanager; a simple a change of the title would result in the gain or loss of the right to make such updates. Thanks, Jaap

4 12

understanding userid .vs. uid
by Stefan Palme 30 Jan '10

30 Jan '10

Hi all, This is not a problem, just a question to understand the things "behind the scenes". I am just playing around with some LDAP frontends helping the user to add the correct attributes depending on the selected objectclass(es) when creating new LDAP entries. A have tried to add an entry with objectclass "account", which requires an attribute "userid" and may have some more attributes. After adding the entry with "userid=test", the LDAP tree contained an appropriate entry, but the attributes "userid" is named "uid" now. Although I gave the entry an RDN with "userid=test", the RDH has also automagically changed to "uid=test". Obviously, userid and uid are "the same" attribute, and here are my questions: 1) The objectclass "account" is defined with "MUST userid" - but I can create an "account" entry either by giving it an "userid" attribute or by using "uid" - both works (I've expected the "uid" approach to fail). Why? 2) Where is the relationship between userid and uid defined? I've found some "attributetype" definitions in the schema files (namely NAME ('uid', 'userid')), but they are commented out. So is this relationship hardcoded in OpenLDAP's source code? If yes - is this a standard relationship also used by other LDAP servers? 3) Are there some more attribute pairs like userid/uid which are "interchangable" in this way? If yes, can I derive the list of such attributes from the schema files somehow? Or is there a RFC or something naming all such attributes? Thanks and regards -stefan- -- --------------------------------------------------------------------- Stefan Palme Email: palme(a)kapott.org WWW: http://hbci4java.kapott.org GnuPG-Fingerprint: 1BA7 D217 36A1 534C A5AD F18A E2D1 488A E904 F9EC ---------------------------------------------------------------------

3 2

Requiring LDAP host entries for user login
by Jaap Winius 30 Jan '10

30 Jan '10

Hi all, My v2.4.11 OpenLDAP server, which runs Debian lenny and requires Kerberos authentication, has these access directives: access to attrs=userPassword,shadowLastChange by * none access to dn.base="" by * read access to * by anonymous auth by users read (The second directive seems not to matter. Why?) Users cannot login unless libnss-ldap on the workstations first uses a Kerberos host key to authenticate and then searches the DIT for a matching user account. I prefer this to allowing libnss-ldap to search the DIT anonymously. I've also created LDAP entries for the hosts that are matched to their Kerberos (GSSAPI) counterparts with: authz-regexp uid=host/([^/\.]+).example.com,cn=example.com,cn=gssapi,cn=auth cn=$1,ou=hosts,dc=example,dc=com The server's syslog shows that these LDAP host names are being resolved when clients login to the workstations. However, I've also found that if the above authz-regexp statement is disabled, the host names will remain in their GSSAPI format, but the DIT is still searched and the users can still login. So, is it possible to make the successful authz-regexp resolution of LDAP host entries a requirement for user login? If so, how? Many thanks, Jaap

1 0

Re: Error 53 applying syncrepl LDIF
by Hung Luu 29 Jan '10

29 Jan '10

On Fri, Jan 29, 2010 at 3:06 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, January 29, 2010 2:39 PM -0700 Hung Luu <hung.n.luu(a)gmail.com> > wrote: > > Are you able to get it to work with ldapadd as well? I'm getting a >> segmentation fault using ldapmodify (installed as part of >> openldap-clients.x86_64 rpm 2.3.43-3.el5). >> > > I would suggest you use a 2.4 version of ldapmodify and/or ldapadd. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > This is interesting -- if I apply the hdb LDIF _before_ the config LDIF then ldapadd has no complaints. Reversing the order of my entries in the LDIF so the olcSyncrepl attribute is added to the hdb backend first did the trick. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=001 provider="ldap://provider:389" type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=ldap,ou=services, dc=example,dc=com" credentials=secret dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=000 provider="ldap://provider:389" type=refreshAndPersist retry="5 5 300 +" searchbase="cn=config" attrs="*,+" bindmethod=simple binddn="cn=ldap,ou=services,dc=example,dc=com" credentials=secret I will try to find 2.4 versions of ldapadd and ldapmodify. Thanks, Hung

1 0

Re: Error 53 applying syncrepl LDIF
by Hung Luu 29 Jan '10

29 Jan '10

On Fri, Jan 29, 2010 at 2:16 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, January 29, 2010 1:56 PM -0700 Hung Luu <hung.n.luu(a)gmail.com> > wrote: > > Hello all, >> >> In a syncrepl setup, I understand that the syncrepl specification is >> defined on the consumer server. I understand this to mean that I should >> apply my LDIF (that adds the olcSyncrepl attribute to my config and hdb >> backends) on the consumer server. However, ldapadd was only successful in >> configuring my config backend for syncrepl, which is defined first in the >> LDIF, and failed with LDAP error 53 when attempting to add the >> olcSyncrepl attribute to my hdb backend; additional error info: "shadow >> context; no update referral." >> >> Is this because the olcSyncrepl attribute added to my config backend >> already established my consumer server as a replica and hence subsequent >> writes to the consumer server will not be accepted? >> >> Ideally, I wanted to add the syncrepl configuration in my slapd.conf and >> then convert it to cn=config; however, this doesn't appear to work with >> 2.4.21 because the slaptest added a uri="" to the olcSyncrepl attribute >> that running slapd complained of an invalid URL for olcSyncrepl. This is >> not an issue in 2.4.20. >> >> Anyway, what's the right way for me to configure syncrepl on my 2.4.21 >> consumer server for both the config and hdb backends? >> > > It works for me with 2.4.21: > > dn: olcDatabase={2}hdb,cn=config > changetype: modify > add: olcSyncrepl > olcSyncrepl: rid=100 provider=${ldap_master_url} bindmethod=si > mple timeout=0 network-timeout=0 binddn=uid=zmreplica,cn=admins,cn=zimbra c > redentials=${ldap_replication_password} starttls=critical > filter="(objectclass=*)" searchbase="" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > logbase=cn=access > log scope=sub schemachecking=off type=refreshAndPersist retry="60 +" > syncdat > a=accesslog tls_cacertdir=/opt/zimbra/conf/ca > > is the LDIF I use to ldapmodify my entry. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > Are you able to get it to work with ldapadd as well? I'm getting a segmentation fault using ldapmodify (installed as part of openldap-clients.x86_64 rpm 2.3.43-3.el5). Here's my LDIF file: dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=000 provider="ldap://provider:389" type=refreshAndPersist retry="5 5 300 +" searchbase="cn=config" attrs="*,+" bindmethod=simple binddn="cn=ldap,ou=services,dc=example,dc=com" credentials=secret dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=001 provider="ldap://provider:389" type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=ldap,ou=services,dc=example,dc=com" credentials=secret Something else that I tried that seems to get syncrepl working on 2.4.21 is to use a slapd.d converted from a 2.4.20 slapd.conf, but I'm a little uneasy about it. Thanks, Hung.

2 1

Error 53 applying syncrepl LDIF
by Hung Luu 29 Jan '10

29 Jan '10

Hello all, In a syncrepl setup, I understand that the syncrepl specification is defined on the consumer server. I understand this to mean that I should apply my LDIF (that adds the olcSyncrepl attribute to my config and hdb backends) on the consumer server. However, ldapadd was only successful in configuring my config backend for syncrepl, which is defined first in the LDIF, and failed with LDAP error 53 when attempting to add the olcSyncrepl attribute to my hdb backend; additional error info: "shadow context; no update referral." Is this because the olcSyncrepl attribute added to my config backend already established my consumer server as a replica and hence subsequent writes to the consumer server will not be accepted? Ideally, I wanted to add the syncrepl configuration in my slapd.conf and then convert it to cn=config; however, this doesn't appear to work with 2.4.21 because the slaptest added a uri="" to the olcSyncrepl attribute that running slapd complained of an invalid URL for olcSyncrepl. This is not an issue in 2.4.20. Anyway, what's the right way for me to configure syncrepl on my 2.4.21 consumer server for both the config and hdb backends? Thanks, Hung.

2 1

All of slapd's configuration options can be changed on the fly?
by Hung Luu 28 Jan '10

28 Jan '10

Hello all, I am just experimenting with applying LDIF to the dynamic config backend and see what configuration directives I'm allowed to modify. I've tried deleting an olcModuleLoad attribute and replacing the olcModulePath attribute with a new value; both times resulted in an LDAP error code 80. >From the 2.4 Admin Guide on configuration slapd: "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect." There is also a note that says: "Some of the backends and of the distributed overlays do not support runtime configuration yet. In those cases, the old style slapd.conf file must be used." Is there a list of slapd configuration directives that are allowed (or not allowed) to be changed dynamically at runtime? Thanks, Hung

2 1

Re: performance on Solaris
by Stefano Zanmarchi 28 Jan '10

28 Jan '10

Thank you very much Quanah, you sound very encouraging. Does anyone knows how OpenLDAP performs on Sun Solaris (10) on Sun's hardware (sparc cpus)? Some more data to complete the picture. - OpenLDAP 2.4.16 + Berkeley BDB 4.7 + back-bdb - 800.000 entries occupy 880MB (log excluded), and a typical entry would just be: dn: uid=657321(a)myunit.myorg.org, ou=people,dc=myorg,dc=org objectClass: account objectClass: simpleSecurityObject uid: 657321(a)myunit.myorg.org userPassword: whatever - The "working set" is around 25% (i.e. most of the bind/updates will be done on the same 200.000 entries) Given these numbers, I thought 500MB be enough, do you agree? Thanks a lot, Stefano On Wed, Jan 27, 2010 at 7:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Wednesday, January 27, 2010 7:06 PM +0100 Stefano Zanmarchi < > zanmarchi(a)gmail.com> wrote: > > Hi, >> I need to set up a LDAP production server with 800.000 entries. >> Performance and stability are >> my main concern, I expect around 250 binds and 50 ldapupdate/insert per >> minute. >> The machine is a SunFire6900 with 8 sparc US-IV+ CPUs and I'd like to >> dedicate around 500MB >> of ram to OpenLdap (more, if necessary). The OS is SunSolaris 10. >> >> >> I'd like to know if OpenLdap is sincerely a good choice with these >> numbers, and if anyone can >> share his on-the-field experience with so many users. >> > > 250 binds/minute and 50 updates/minute is a very low number of each. You > fail to state what version of OpenLDAP you plan on using, or which backend > (sql, bdb, hdb, etc) so it's hard to give you anything concrete. Assuming > you'd be using OpenLDAP 2.4.21 + Berkeley BDB 4.8 with either back-bdb or > back-hdb, you should be fine. I would note however any testing I've ever > done using Solaris as the OS has been significantly slower than Linux > running on the same hardware. > > If you have 800,000 entries, your main concern is definitely going to be > the RAM. 500MB is unlikely to cut it, but it depends on the size of your > entries. You may need upwards of 16GB of RAM depending again on how large > your DB actually is. > > I.e., you fail to provide the data necessary to give you a conclusive > answer. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical