openldap-software June 2007

openldap-software@openldap.org

86 participants
106 discussions

32 bit to 64 bit migration performance problems
by erin crego 21 Jun '07

21 Jun '07

I am moving our ldap instances to new servers; the old servers are 32 bit, the new ones are 64 bit. I have compiled the same versions of bdb (4.2.52) and openldap (2.2.26) with the same flags on the new servers. After running DirectoryMark tests, I have found the operations per second has gone down 33% - from 299 on the old servers to 192 on the new ones. I have tried adding what I think are the 64 bit flags to the compilation of bdb and openldap. LDFLAGS='-m64' and CFLAGS='-m64' This has resulted in the operations/second going down further to 52. Are there different compilation flags I should use for 64 bit systems? Or, is the performance change of -33% to be expected when moving from 32 bit to 64 bit? --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel.

2 1

Re: Apparent character loss in Windows implementation
by matthew sporleder 20 Jun '07

20 Jun '07

You could try running slapd -Ta to run it in slapadd mode if it's not in your install base anywhere. If ldapsearch doesn't suffer from the character loss problem, then I suspect it's an incompatibility with your ldap browser's ber-encoding libraries, or just some other kind of weirdo problem. More debugging would be necessary. Good luck! On 6/18/07, Jack Emmerichs <beamrider1(a)hotmail.com> wrote: > ldapsearch (from the new build) can retrieve the base DN described in the > slapd.conf file, so that looks okay. The next thing I need to do is to > rebuild the database from an exported ldif file (which I have) and build a > current database for the new openLDAP version. Unfortunately, I can't find > the slapadd utility in the new build. > > Question: do I need to enable any flags or options to have the build > generate an up-to-date version of slapadd? Sorry for such a really basic > question, but I expected it to just show up as part of the build like > ldapsearch did. > > > >From: "matthew sporleder" <msporleder(a)gmail.com> > >To: "Jack Emmerichs" <beamrider1(a)hotmail.com> > >CC: openldap-software(a)openldap.org > >Subject: Re: Apparent character loss in Windows implementation > >Date: Mon, 18 Jun 2007 09:29:43 -0400 > > > >On 6/15/07, Jack Emmerichs <beamrider1(a)hotmail.com> wrote: > >>We have just succeeded in creating a Windows (Windows XP Professional SP2) > >>implementation of the current stable version (2.3.32) by building all the > >>source code (back end, openSSL, OpenLDAP, etc.) within the MinGw Windows > >>build environment in order to enable the ppolicy options. We are using > >>the > >>standard BDB back-end. Oddly enough, it seems to have worked, and I can > >>execute the slapd.exe file, which seems to run normally. > >> > >>I know Windows is a non-standard environment, but as I understand it, the > >>underlyling OpenLDAP code is suppose to work correctly. Whether we have > >>achieved that or not remains to be seen. > >> > >>The test database we are using has a standard test Manager account in a > >>database structure defined as dn="cn=Manager,dc=my-domain,dc=com". In > >>trying to attach a browser to the LDAP, I seem to be getting a connection > >>to > >>the database, but something seems to be stripping the initinal character > >>from the db structure definition leaving the decoded "dc" component as: > >>"c=my-domain,dc=com". > >> > >>Here is the trace of the attempted connection to the LDAP: > >> > >>slapd starting > >> >>>slap_listener(ldap:///) > >>connection_get(420): got connid=0 > >>connection_read(420): checking for input on id=0 > >>ber_get_next > >>ber_get_next: tag 0x30 len 49 contents: > >>ber_get_next > >>do_bind > >>ber_scanf fmt ({imt) ber: > >>ber_scanf fmt (m}) ber: > >> >>>dnPrettyNormal: <cn=Manager, dc=my-domain,dc=com> > >><<< dnPrettyNormal: <cn=Manager,dc=my-domain,dc=com>, > >><cn=manager,dc=my-domain,d > >>c=com> > >>do_bind: version=3 dn="cn=Manager,dc=my-domain,dc=com" method=128 > >>do_bind: v3 bind: "cn=Manager,dc=my-domain,dc=com" to > >>"cn=Manager,dc=my-domain,d > >>c=com" > >>send_ldap_result: conn=0 op=0 p=3 > >>send_ldap_response: msgid=1 tag=97 err=0 > >>ber_flush: 14 bytes to sd 420 > >>connection_get(420): got connid=0 > >>connection_read(420): checking for input on id=0 > >>ber_get_next > >>ber_get_next: tag 0x30 len 69 contents: > >>ber_get_next > >>do_search > >>ber_scanf fmt ({miiiib) ber: > >> >>>dnPrettyNormal: <dc=my-domain,dc=com> > >><<< dnPrettyNormal: <dc=my-domain,dc=com>, <dc=my-domain,dc=com> > >>ber_scanf fmt (m) ber: > >>ber_scanf fmt ({M}}) ber: > >>=> bdb_search > >>bdb_dn2entry("dc=my-domain,dc=com") > >>=> bdb_dn2id("dc=my-domain,dc=com") > >><= bdb_dn2id: got id=0x01000000 > >>entry_decode: "c=my-domain,dc=com" > >><= entry_decode: str2ad(orsName): AttributeDescription contains > >>inappropriate ch > >>aracters > >><= entry_decode: slap_str2undef_ad(orsName): AttributeDescription contains > >>inapp > >>ropriate characters > >>send_ldap_result: conn=0 op=1 p=3 > >>send_ldap_response: msgid=2 tag=101 err=80 > >>ber_flush: 28 bytes to sd 420 > >> > >>The problem is about seven lines up from the end of the trace. It has the > >>flavor of trying to insert a newline into the full dn=... text and having > >>Unix insert a single expected character while Windows inserts two > >>characters, thereby overlaying the first character of the following text. > >> > >>Does anybody know of any gotchas in a Windows environment related to this > >>problem, or any other information about it? The build options we used > >>were: > >> > >>OPENLDAPCONF="--disable-static --enable-shared --enable-dynamic > >>--enable-lmpasswd --enable-bdb --disable-ldap --disable-ldbm > >>--disable-meta > >>--disable-monitor --disable-null --disable-sql --enable-ppolicy" > >> > >>Any suggestions, including a known impossibility of getting this to work, > >>would be appreciated. > > > > > >Have you tried your search with the 'ldapsearch' command that comes with > >slapd? > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > >

3 3

Proxy Authz interoperability of Sun's JNDI LDAP boost pack and OpenLDAP
by Michael Ströder 20 Jun '07

20 Jun '07

HI! I'm currently testing proxy authorization with the control implementation com.sun.jndi.ldap.ctl.ProxiedAuthorizationControl in Sun's LDAP boost pack for JNDI. slapd seems to be configured correctly since this command-line works: ldapsearch -x -H "ldap://localhost:1390" -D "uid=proxyuser,ou=proxyauthztests,ou=Testing,dc=stroeder,dc=de" -w testproxy -b "ou=Testing,dc=stroeder,dc=de" -s sub -e \!authzid="dn:uid=proxieduser,ou=proxyauthztests,ou=Testing,dc=stroeder,dc=de" "(objectClass=*)" Now I'm trying to do the same via JNDI (see attached Test2.java). But this results in: Exception: javax.naming.NamingException: [LDAP: error code 47 - authzId mapping failed]; remaining name 'ou=Testing,dc=stroeder,dc=de' If starting slapd with debugging (-d args,trace,packets) I get the log I've also attached. Note the extra char before "dn:" in line starting with "parseProxyAuthz". I extracted the control from Wireshark and even dumpasn1.c did not manage to decode it properly. So I suspect something's wrong with the encoding. Can anybody please confirm this? Any hint how to reach Sun's JNDI developers? Ciao, Michael. -- Michael Ströder michael(a)stroeder.com http://www.stroeder.com

4 4

rootpw ignored if userPassword exists
by Andreas Hasenack 20 Jun '07

20 Jun '07

I was just wondering if this is expected behaviour. If rootdn happens to match an existing entry in the directory, and that entry has a userPassword attribute, the rootpw value in slapd.conf is ignored and userPassword is used instead. I find this a bit unexpected. Suppose someone manages to create an entry matching rootdn. Then this person would be able to become rootdn, bypassing the rootpw setting in slapd.conf.

3 3

Checking authzTo case-sensitive
by Michael Ströder 20 Jun '07

20 Jun '07

HI! checking a DN sent by proxy authorization control against authzTo seems to be case-sensitive. Or better said: DNs in the attribute value of authzTo must be lower-cased to make matching work. Is that by purpose? Ciao, Michael.

2 3

OpenLDAP for Windows Available
by Matthew Hardin 20 Jun '07

20 Jun '07

Hi All, There's been a lot of conversation about OpenLDAP for Windows lately, and we thought it would nice to make a package available free of charge. CDS Silver 3.7.1 for Windows (32-bit) is based on OpenLDAP 2.3.35 plus patches. It's been tested on Windows 2000, Windows XP, and Windows 2003 Server, and it's packaged in a nice InstallShield wrapper. No extra software is needed. The package can be downloaded from CDS 3.x Silver Edition section of our download site at http://www.symas.net/portal. Check the release notes and the ReadMe file for additional information. Enjoy! Matt (the elder), Howard, Marty, Chuck, and Matt (the younger) Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com

2 1

Replication, ACL's - newbie questions.
by lauro＠npd.ufsc.br 20 Jun '07

20 Jun '07

Hi, I have about 10 locations on my tree where specific DN's have write access. To get the ACL's properly processed I have these ACL's before an ACL to resource "*" to the LDAP admin (access to * \ by "admin,suffix" write \ by * read). On the slaves I should not have an ACL to each of those entries (those 10 before), cause if so, on each one I have to add an extra line to the replication agent for that slave. I need just one like this: access to * by "admin,suffix" write by replication-agent-for-this-slave,suffix write by * read on the slave the replication DN is the only one requesting write access on syncronization(?), at least on the logs that's what I get, and it makes more sense. Despite the DN used to write on the master, always the replication agent is the one to request write access to the slave tree. And another thing: If I try to write anything on the slave with any DN (even admin DN) I get a referral error/message, ok, but when using the replication DN for that slave, I can write with no problems..then the databases are out of sync. I know nobody but the slapd and slurpd will have access to that DN pass, but is that right? Should the replication DN be able to write to the slave tree directly? Is there a way to make it right just when called by slurpd? (*Of course* it does have to write directly to the slave db, that's why it exists, if there were a way to make it do so just when called by slurpd..(I don't know who starts the write process if it's slapd or slurpd.) thanks, lauro ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 2

I need get random entries
by Elier Delgado 19 Jun '07

19 Jun '07

Hi guys, It's very strange but I need get random entries from the OpenLdap, specifically get randoms users (N users) .. it's a requirement of the system that I'm designing .... I'm using PHP and is not efficient get all results and do the random with the index of the result array ...because the results must be many .. And I'm not happy to apply a random to a filter values, for example generating randomly uid and getting near results ... So, I will appreciate any idea ... Regards, Elier

3 3

Re: Limiting attributes through ACL
by Pierangelo Masarati 19 Jun '07

19 Jun '07

[please keep replies on the list] >>Dan Ciarniello wrote: >># anyone can see the cn of inetOrgPersons >>access to filter="(objectClass=inetOrgPerson)" attrs=cn >> by * read >> >># only users can see anything else of inetOrgPersons >>access to filter="(objectClass=inetOrgPerson)" >> by users read > Unfortunately, that doesn't seem to do it. I set the above filters but > I still get back all attributes when binding anonymously (using > JXplorer). I don't know if it makes a difference but I'm using OpenLDAP > 2.2 rather than 2.4. Well, apart from any consideration strictly related to your issue, you should be using 2.3 (2.4 is not released yet but in alpha, so it's not recommended). The fact that the above rules do not seem to work sounds odd, as they're known to work as suggested. How can you tell they ever get used? Did you run slapd with "acl" debug level enabled (with 2.2, OR 128 to the log level). My guess is that you have broader ACLs in place that get called before the suggested ones. I suggest you post your entire slapd.conf (after appropriate sanitization for any sensistive info). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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 ---------------------------------------

2 3

Data Store Question
by Jacques Voris 19 Jun '07

19 Jun '07

To All: My employers wish to use a SQL Database (specifically MySQL) as the data store for OpenLDAP. All of the information I have been able to find thus far seems to indicate that while this may be technically possible, it is a very bad idea. Therefore, I wish to know if any of you have any experience with using a SQL database for the data store, or if it is such a bad idea what specific reasons is it such? -- Thank You, Jacques Voris

3 3

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software June 2007