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
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&...
--On June 19, 2007 2:05:00 PM -0500 Jack Emmerichs beamrider1@hotmail.com wrote:
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.
It fails because it violates the requirements for inetOrgPerson.
Entry (cn=Test Account,ou=people,dc=example,dc=com): object class 'inetOrgPerson' requires attribute 'sn' slapadd: dn="cn=Test Account,ou=people,dc=example,dc=com" (line=24): (65) object class 'inetOrgPerson' requires attribute 'sn'
Of course, if you'd just take 5 minutes to play with ldapadd or slapadd, you could discover this yourself. ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Aha! the problem was not the Windows run environment but the Windows build environment. OpenLDAP ended up using an unexpected directory for it's slapd.conf file, so we were configuring the wrong oen had never changed the actual default config (we built a previous version in a full Cygwin enviroment, and built the current one in minGW--the minGW build was using the Cygwin/etc/openldap directory!).
The Windows build appears to work just fine when properly configured. However, it will take some additional work to rationalize the install environment, so we may look into the Symas offering.
Thanks to everyone who offered suggestions--this problem is now closed.
JFE.
From: "Jack Emmerichs" beamrider1@hotmail.com To: msporleder@gmail.com, openldap-software@openldap.org Subject: Re: Apparent character loss in Windows implementation Date: Tue, 19 Jun 2007 14:05:00 -0500
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&...
_________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_June07
openldap-software@openldap.org
-
Jack Emmerichs -
matthew sporleder -
Quanah Gibson-Mount