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

Re: Apparent character loss in Windows implementation

To: msporleder@gmail.com, openldap-software@openldap.org
Subject: Re: Apparent character loss in Windows implementation
From: "Jack Emmerichs" <beamrider1@hotmail.com>
Date: Tue, 19 Jun 2007 14:05:00 -0500
In-reply-to: <b0459d5c0706181347uc032681maf4936a09496bf45@mail.gmail.com>

Thanks for the hints, I'm making progress. The problem was slapd.conf still pointing to the old database files. With new database, things go well until I get to loading a posixAccount object. While trying ldif formats that folks on the general LDAP forum say works for them, I have concluded that my current config is not handling objectClass: inetOrgPerson at all.

As I'm converting from an older OpenLDAP version, I'm still using slapd.conf. I see that the schemas have changed, so I'm loading everything that seems reasonable:

 include      ./schema/core.schema
 include      ./schema/cosine.schema
 include      ./schema/inetorgperson.schema
 include      ./schema/nis.schema
 include      ./schema/misc.schema
 include      ./schema/openldap.schema
 include      ./schema/ppolicy.schema

I don't see anything any obvious errors in loading inetorgperson.schema, yet whenever I use inetOrgPerson in an object's hierarchy, I get an error such as:

   LDAP error code 21 - objectClass: value #1 invalid per syntax

where value #1 will be inetOrgPerson.

Here is an example of the ldif file format I'm trying to load:

 # Test Account, people, my-domain.com
 dn: cn=Test Account,ou=people,dc=my-domain,dc=com
 objectClass: top
 objectClass: inetOrgPerson
 objectClass: posixAccount
 cn: Test Account
 uid: testaccount
 uidNumber: 100
 gidNumber: 100
 homeDirectory: /tmp

I have no trouble processing ldif files for the database initialization or connecting with clients The only remaining problem is loading posixAccount objects.

Thanks for any suggestion anyone may have.

JFE

From: "matthew sporleder" <msporleder@gmail.com> To: "Jack Emmerichs" <beamrider1@hotmail.com>, "openldap-software@OpenLDAP.org" <openldap-software@openldap.org> Subject: Re: Apparent character loss in Windows implementation Date: Mon, 18 Jun 2007 16:47:47 -0400
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
http://liveearth.msn.com?source=msntaglineliveearthhm

_________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01

Follow-Ups:
- Re: Apparent character loss in Windows implementation
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- Re: Apparent character loss in Windows implementation
  - From: "Jack Emmerichs" <beamrider1@hotmail.com>

References:
- Re: Apparent character loss in Windows implementation
  - From: "matthew sporleder" <msporleder@gmail.com>

Prev by Date: Re: Backend meta as a module errors
Next by Date: Re: Backend meta as a module errors
Index(es):
- Chronological
- Thread