[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: win 2000 problem?

To: "Rob Tice" <rob.tice@k-int.com>, <ando@sys-net.it>
Subject: RE: win 2000 problem?
From: "Ken Turley" <kturley@invizeon.com>
Date: Thu, 20 Mar 2003 14:04:16 -0700
Cc: <openldap-software@OpenLDAP.org>
Content-class: urn:content-classes:message
Thread-index: AcLkycDXC+1ba8h1Rza5oe+U148BfwKS93Kw
Thread-topic: win 2000 problem?
Hello Pierangelo and Rob,

I would like to pick up on your thread of back-sql/Win2k issues that appeared a couple of weeks ago.  

First, the suggestion given to Rob to use "schemacheck off" was an absolute LIFE SAVER here for me!!  I encountered, under v2.1.16, the exact same problem and behavior as Rob indicated in his Thu 3/6/2003 10:11 AM message:  

"backsql_search(): error in backsql_id2entry() - skipping entry"

The "schemacheck off" switch fixed this and finally (after several days' building effort) I have 2.1.16 up and running.  I thank you for that suggestion!

A little background: We have been running 2.0.11 in evaluation on a Win2k platform with back-sql to MS SQL Server.  It ran fine, except for an occcasional crash due to a known bug (ITS# 1655).  We have been working steadily since Monday to build the new version, 2.1.16, on same configuration (Win2k, back-sql, MS SQL Server; build tool: VS .NET v7 ) using same SQL tables (actual data + ldap_ support tables). As of this morning, I have it up and running on our test data and am putting it through some stress tests with ldapsearch in looping ksh scripts.

Note: In our initial test LDAP directory, in order to create the directory tree structure we wanted, we created a non-standard "placeholder" object class. This object class was not associated with any schema.  It worked fine in 2.0.11, but 2.1.16, even with "schemacheck off" complains (" load_schema_map(): objectClass '<our-custom-object-class-name-here>' is not defined in schema " is the error message)and slapd refuses to start. I suppose this is desirable, and we knew we'd need to move away from our non-std placeholder anyway.  For the time being, I've replaced it with dcObject and am able to achieve the same tree structure.  However, we may also just flatten out our tree in our production version.

Question: Pierangelo, you stated that the "developer of back-sql is not maintaining it any more."  Assuming openLDAP 2.1.16 passes our validation unit tests, we are committing to it heavily as our LDAP solution. Do you anticipate problems with back-sql support/fixes down the line, or is there another developer stepping up to support it?  Any thoughts on that are appreciated as they have a bearing on our project.

Question: Is "schemacheck off" the way to go for the time being? Is it a workaround for a bug, or?

Having just worked through a 2.1.16 build of Back-SQL on Windows 2000, I'm willing to answer build questions for this rather specific configuration if I'm able.

Best regards,

Ken Turley
Invizeon Corporation



-----Original Message-----
From: Rob Tice [mailto:rob.tice@k-int.com]
Sent: Friday, March 07, 2003 9:17 AM
To: ando@sys-net.it
Cc: openldap-software@OpenLDAP.org
Subject: RE: win 2000 problem?


Hi. 

Hi

As a follow up I turned schemacheck off. It still fails but I can
actually see things in the log file now (although they are not much help
to me with my limited openldap knowledge:) )

I am getting an error 32 no such object when there are entries in the
database. I can view the top level using the softerra browser and there
are lots of missing attributes in the display (in comparison to what is
displayed for the entries in my functioning bdb database)

Here is the extract of the log printout which appears to suggest a
problem with some missing attributes as you suggested, however I'm not
sure how to rectify it.



Constructed query: SELECT DISTINCT
ldap_entries.id,contacts.id,'inetOrgPerson' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,contacts WHERE
contacts.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND
ldap_entries.dn=? AND NOT ('inetOrgPerson' IS NULL)
<==backsql_oc_get_candidates()
backsql_search(): loading data for entry id=1, oc_id=1, keyval=1
==>backsql_id2entry()
>>> dnPrettyNormal: <ou=contacts,dc=k-int,dc=com>
=> ldap_bv2dn(ou=contacts,dc=k-int,dc=com,0)
<= ldap_bv2dn(ou=contacts,dc=k-int,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(ou=contacts,dc=k-int,dc=com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(ou=contacts,dc=k-int,dc=com,272)=0
<<< dnPrettyNormal: <ou=contacts,dc=k-int,dc=com>,
<ou=contacts,dc=k-int,dc=com>
backsql_id2entry(): custom attribute list
backsql_id2entry(): attribute 'createTimestamp' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'modifyTimestamp' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'creatorsName' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'modifiersName' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'subschemaSubentry' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'attributeTypes' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'objectClasses' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'matchingRules' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'matchingRuleUse' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'namingContexts' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'altServer' is not defined for objectlass
'organizationalUnit'
backsql_id2entry(): attribute 'supportedExtension' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'supportedControl' is not defined for
objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'supportedSASLMechanisms' is not defined
for objectlass 'organizationalUnit'
backsql_id2entry(): attribute 'supportedLDAPVersion' is not defined for
objectlass 'organizationalUnit'
<==backsql_id2entry()
=> test_filter
    PRESENT
=> access_allowed: search access to "ou=contacts,dc=k-int,dc=com"
"objectClass" requested
=> access_allowed: backend default search access granted to ""
<= test_filter 6
=> send_search_entry: dn="ou=contacts,dc=k-int,dc=com"
=> access_allowed: read access to "ou=contacts,dc=k-int,dc=com" "entry"
requested
=> access_allowed: backend default read access granted to ""
==>backsql_operational(): entry 'ou=contacts,dc=k-int,dc=com'
==>backsql_get_db_conn()
<==backsql_get_db_conn()
==>backsql_count_children(): dn='ou=contacts,dc=k-int,dc=com'
children id query 'SELECT COUNT(distinct subordinates.id) FROM
ldap_entries,ldap_entries AS subordinates WHERE
subordinates.parent=ldap_entries.id AND ldap_entries.dn=?'
<==backsql_count_children(): 3
=> access_allowed: read access to "ou=contacts,dc=k-int,dc=com"
"subschemaSubentry" requested
=> access_allowed: backend default read access granted to ""
=> access_allowed: read access to "ou=contacts,dc=k-int,dc=com"
"hasSubordinates" requested
=> access_allowed: backend default read access granted to ""
ber_flush: 102 bytes to sd 1204
  0000:  30 64 02 01 07 64 5f 04  1b 6f 75 3d 63 6f 6e 74
0d...d_..ou=cont  
  0010:  61 63 74 73 2c 64 63 3d  6b 2d 69 6e 74 2c 64 63
acts,dc=k-int,dc  
  0020:  3d 63 6f 6d 30 40 30 23  04 11 73 75 62 73 63 68
=com0@0#..subsch  
  0030:  65 6d 61 53 75 62 65 6e  74 72 79 31 0e 04 0c 63
emaSubentry1...c  
  0040:  6e 3d 53 75 62 73 63 68  65 6d 61 30 19 04 0f 68
n=Subschema0...h  
  0050:  61 73 53 75 62 6f 72 64  69 6e 61 74 65 73 31 06
asSubordinates1.  
  0060:  04 04 54 52 55 45                                  ..TRUE

ldap_write: want=102, written=102
  0000:  30 64 02 01 07 64 5f 04  1b 6f 75 3d 63 6f 6e 74
0d...d_..ou=cont  
  0010:  61 63 74 73 2c 64 63 3d  6b 2d 69 6e 74 2c 64 63
acts,dc=k-int,dc  
  0020:  3d 63 6f 6d 30 40 30 23  04 11 73 75 62 73 63 68
=com0@0#..subsch  
  0030:  65 6d 61 53 75 62 65 6e  74 72 79 31 0e 04 0c 63
emaSubentry1...c  
  0040:  6e 3d 53 75 62 73 63 68  65 6d 61 30 19 04 0f 68
n=Subschema0...h  
  0050:  61 73 53 75 62 6f 72 64  69 6e 61 74 65 73 31 06
asSubordinates1.  
  0060:  04 04 54 52 55 45                                  ..TRUE

<= send_search_entry
send_search_result: err=0 matched="" text=""
send_ldap_response: msgid=7 tag=101 err=0
ber_flush: 14 bytes to sd 1204
  0000:  30 0c 02 01 07 65 07 0a  01 00 04 00 04 00
0....e........    
ldap_write: want=14, written=14
  0000:  30 0c 02 01 07 65 07 0a  01 00 04 00 04 00
0....e........    
<==backsql_search()



Any more clues would be gratefully accepted as I feel that I am close
now (thanks to the lots of help I have received previously :))

Rob Tice
Rob.tice@k-int.com








-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Pierangelo
Masarati
Sent: 07 March 2003 07:45
To: rob.tice@k-int.com
Cc: openldap-software@OpenLDAP.org
Subject: Re: win 2000 problem?


> Running 2.1.14 on win2000 with back-sql
>
>
>
> I have been trying to get this to work for days. Slapd works +
connects
> + runs thro its diagnostics + back-sql startup diagnostics are fine.
> When I try + connect from a client to backsql I get the following
trace
> when back-sql is in debug mode.

I have a clue: since recently checks for structural objectclass
and consistency between naming attributes (types and values in
the entry rdn) and entry attributes have been added, this may
cause your problem (which should be logged, though).

You may try setting "schemacheck off" in slapd.conf and see if
your problem disappears.  In case, we'll have to see how to make
your data schema compliant.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
Follow-Ups:
- RE: win 2000 problem?
  - From: "Pierangelo Masarati" <ando@sys-net.it>
Prev by Date: Re: test of SASL DIGEST-MD5 mechanism
Next by Date: I'm getting different results returned from two identical LDAP servers, one running 2.0 and the other 2.1...
Index(es):
- Chronological
- Thread