[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Apparent character loss in Windows implementation

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@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@gmail.com> >To: "Jack Emmerichs" <beamrider1@hotmail.com> >CC: openldap-software@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@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