Challenge With Access Control

2007-07-05 Thread Brian Gaber
Hope someone can explain this to me.  I am sure it is very trivial.  I
have a primary LDAP server (10.16.13.84), a replica LDAP server
(10.16.13.85) and a few clients all with a 10.16.13.x address.

Here is the access control I thought would work:

access  to *
  by self write
  by peername=10.16.13.84 write
  by peername=10.16.13.81 read
  by peername=10.16.13.82 read
  by peername=10.16.13.83 read
  by peername=10.16.13.85 read
  by peername=10.16.13.86 read

Here is what does work:

access to *
  by self write
  by peername.ip=10.16.13.84 write
  by * read

By work I mean that when I am on the replica (10.16.13.85) and
issue an ldapsearch to itself I get a 32 no such object with the top
access, but I get the expected result with the bottom access.

Brian Gaber


RE: Challenge With Access Control

2007-07-05 Thread Brian Gaber
Tried your suggestion and still have a problem.

Here is the new slapd.conf:

access to *
  by self write
  by peername.ip=10.16.13.84 write
  by peername.regex=IP=10\.16\.13\.8[1-6] read

Here is the log:

entry_decode: SFTid=0001-,ou=servers,o=sft
Jul  5 10:46:35 ias2 slapd[11401]: =
entry_decode(SFTid=0001-,ou=servers,o=sft)
Jul  5 10:46:35 ias2 slapd[11401]: =
bdb_dn2id(SFTid=0001-,ou=servers,o=sft)
Jul  5 10:46:35 ias2 slapd[11401]: = bdb_dn2id: got id=0x002f
Jul  5 10:46:35 ias2 slapd[11401]: = test_filter
Jul  5 10:46:35 ias2 slapd[11401]: EQUALITY
Jul  5 10:46:35 ias2 slapd[11401]: = access_allowed: search access to
SFTid=0001-,ou=servers,o=sft SFTid requested
Jul  5 10:46:35 ias2 slapd[11401]: = acl_get: [1] attr SFTid
Jul  5 10:46:35 ias2 slapd[11401]: = acl_mask: access to entry
SFTid=0001-,ou=servers,o=sft, attr SFTid requested
Jul  5 10:46:35 ias2 slapd[11401]: = acl_mask: to value by , (=0)
Jul  5 10:46:35 ias2 slapd[11401]: = check a_dn_pat: self
Jul  5 10:46:35 ias2 slapd[11401]: = check a_peername_path: 10.16.13.84
Jul  5 10:46:35 ias2 slapd[11401]: = check a_peername_path:
IP=10.16.13.8[1-6]
Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: pattern:
IP=10.16.13.8[1-6]
Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: expanded:
IP=10.16.13.8[1-6]
Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: string:^I
IP=127.0.0.1:46504
Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: rc: 1 no matches
Jul  5 10:46:35 ias2 slapd[11401]: = acl_mask: no more who clauses,
returning =0 (stop)
Jul  5 10:46:35 ias2 slapd[11401]: = access_allowed: search access
denied by =0
Jul  5 10:46:35 ias2 slapd[11401]: = test_filter 50 

-Original Message-
From: Michal Dobroczynski [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 05, 2007 10:36 AM
To: Brian Gaber
Cc: openldap-software@openldap.org
Subject: Re: Challenge With Access Control

On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:



 Hope someone can explain this to me.  I am sure it is very trivial.  I

 have a primary LDAP server (10.16.13.84), a replica LDAP server 
 (10.16.13.85) and a few clients all with a 10.16.13.x address.

 Here is the access control I thought would work:

 access  to *
   by self write
   by peername=10.16.13.84 write
   by peername=10.16.13.81 read
   by peername=10.16.13.82 read
   by peername=10.16.13.83 read
   by peername=10.16.13.85 read
   by peername=10.16.13.86 read

 Here is what does work:

 access to *
   by self write
   by peername.ip=10.16.13.84 write
   by * read

 By work I mean that when I am on the replica (10.16.13.85) and

 issue an ldapsearch to itself I get a 32 no such object with the top 
 access, but I get the expected result with the bottom access.

I am not 100% sure, but maybe this will help you (I am using similar
ACL). AFAIR in the peername you need to add the IP= - but I don't
really remember, please correct me. The regex matching directive that
works for me looks like this:

 by peername.regex=IP=10\.10\.120\..+ read

Then you could try:

by peername.regex=IP=10\.16\.13\.8[1-6] read

And please double check if you need to supply the IP=10.10.10.10 for
the by peername without regex.
The regex solution will not conflict with the first entry as write
permission includes reading (and ACL parsing stops on the first matched
rule).

Hope this helps.

Regards,
Michal


 Brian Gaber



RE: Challenge With Access Control

2007-07-05 Thread Brian Gaber
Michal,

Tried your suggestion, ldapsearch still fails.  Here is the log:

Jul  5 11:09:31 ias2 slapd[11565]: entry_decode:
SFTid=0002-,ou=servers,o=sft
Jul  5 11:09:31 ias2 slapd[11565]: =
entry_decode(SFTid=0002-,ou=servers,o=sft)
Jul  5 11:09:31 ias2 slapd[11565]: =
bdb_dn2id(SFTid=0002-,ou=servers,o=sft)
Jul  5 11:09:31 ias2 slapd[11565]: = bdb_dn2id: got id=0x0030
Jul  5 11:09:31 ias2 slapd[11565]: = test_filter
Jul  5 11:09:31 ias2 slapd[11565]: EQUALITY
Jul  5 11:09:31 ias2 slapd[11565]: = access_allowed: search access to
SFTid=0002-,ou=servers,o=sft SFTid requested
Jul  5 11:09:31 ias2 slapd[11565]: = acl_get: [1] attr SFTid
Jul  5 11:09:31 ias2 slapd[11565]: = acl_mask: access to entry
SFTid=0002-,ou=servers,o=sft, attr SFTid requested
Jul  5 11:09:31 ias2 slapd[11565]: = acl_mask: to value by , (=0)
Jul  5 11:09:31 ias2 slapd[11565]: = check a_dn_pat: self
Jul  5 11:09:31 ias2 slapd[11565]: = check a_peername_path: 10.16.13.84
Jul  5 11:09:31 ias2 slapd[11565]: = check a_peername_path:
IP=10.16.13.8[1-6]*
Jul  5 11:09:31 ias2 slapd[11565]: = acl_string_expand: pattern:
IP=10.16.13.8[1-6]*
Jul  5 11:09:31 ias2 slapd[11565]: = acl_string_expand: expanded:
IP=10.16.13.8[1-6]*
Jul  5 11:09:31 ias2 slapd[11565]: = regex_matches: string:^I
IP=127.0.0.1:46749
Jul  5 11:09:31 ias2 slapd[11565]: = regex_matches: rc: 1 no matches
Jul  5 11:09:31 ias2 slapd[11565]: = acl_mask: no more who clauses,
returning =0 (stop)
Jul  5 11:09:31 ias2 slapd[11565]: = access_allowed: search access
denied by =0
Jul  5 11:09:31 ias2 slapd[11565]: = test_filter 50
Jul  5 11:09:31 ias2 slapd[11565]: bdb_search: 48 does not match filter 

-Original Message-
From: Michal Dobroczynski [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 05, 2007 11:01 AM
To: Brian Gaber
Cc: openldap-software@openldap.org
Subject: Re: Challenge With Access Control

As far as I understand the log - you need to include the port. This
should help then:

by peername.regex=IP=10\.16\.13\.8[1-6]:[0-9]* read

Regards,
Michal

On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:
 Tried your suggestion and still have a problem.

 Here is the new slapd.conf:

 access to *
   by self write
   by peername.ip=10.16.13.84 write
   by peername.regex=IP=10\.16\.13\.8[1-6] read

 Here is the log:

 entry_decode: SFTid=0001-,ou=servers,o=sft
 Jul  5 10:46:35 ias2 slapd[11401]: =
 entry_decode(SFTid=0001-,ou=servers,o=sft)
 Jul  5 10:46:35 ias2 slapd[11401]: =
 bdb_dn2id(SFTid=0001-,ou=servers,o=sft)
 Jul  5 10:46:35 ias2 slapd[11401]: = bdb_dn2id: got id=0x002f Jul

 5 10:46:35 ias2 slapd[11401]: = test_filter
 Jul  5 10:46:35 ias2 slapd[11401]: EQUALITY
 Jul  5 10:46:35 ias2 slapd[11401]: = access_allowed: search access to

 SFTid=0001-,ou=servers,o=sft SFTid requested Jul  5 
 10:46:35 ias2 slapd[11401]: = acl_get: [1] attr SFTid Jul  5 10:46:35

 ias2 slapd[11401]: = acl_mask: access to entry 
 SFTid=0001-,ou=servers,o=sft, attr SFTid requested Jul  5 
 10:46:35 ias2 slapd[11401]: = acl_mask: to value by , (=0) Jul  5 
 10:46:35 ias2 slapd[11401]: = check a_dn_pat: self Jul  5 10:46:35 
 ias2 slapd[11401]: = check a_peername_path: 10.16.13.84 Jul  5 
 10:46:35 ias2 slapd[11401]: = check a_peername_path:
 IP=10.16.13.8[1-6]
 Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: pattern:
 IP=10.16.13.8[1-6]
 Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: expanded:
 IP=10.16.13.8[1-6]
 Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: string:^I
 IP=127.0.0.1:46504
 Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: rc: 1 no matches 
 Jul  5 10:46:35 ias2 slapd[11401]: = acl_mask: no more who clauses,

 returning =0 (stop) Jul  5 10:46:35 ias2 slapd[11401]: = 
 access_allowed: search access denied by =0 Jul  5 10:46:35 ias2 
 slapd[11401]: = test_filter 50

 -Original Message-
 From: Michal Dobroczynski [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 05, 2007 10:36 AM
 To: Brian Gaber
 Cc: openldap-software@openldap.org
 Subject: Re: Challenge With Access Control

 On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:
 
 
 
  Hope someone can explain this to me.  I am sure it is very trivial.

  I

  have a primary LDAP server (10.16.13.84), a replica LDAP server
  (10.16.13.85) and a few clients all with a 10.16.13.x address.
 
  Here is the access control I thought would work:
 
  access  to *
by self write
by peername=10.16.13.84 write
by peername=10.16.13.81 read
by peername=10.16.13.82 read
by peername=10.16.13.83 read
by peername=10.16.13.85 read
by peername=10.16.13.86 read
 
  Here is what does work:
 
  access to *
by self write
by peername.ip=10.16.13.84 write
by * read
 
  By work I mean that when I am on the replica (10.16.13.85) 
  and

  issue an ldapsearch to itself I get a 32 no such object with the top

  access, but I get the expected result with the bottom access.

 I am not 100

RE: Challenge With Access Control

2007-07-05 Thread Brian Gaber
Tried your suggestion.  Search still fails.  Here is the log:

 entry_decode: SFTid=0001-,ou=servers,o=sft
Jul  5 11:05:09 ias2 slapd[11516]: =
entry_decode(SFTid=0001-,ou=servers,o=sft)
Jul  5 11:05:09 ias2 slapd[11516]: =
bdb_dn2id(SFTid=0001-,ou=servers,o=sft)
Jul  5 11:05:09 ias2 slapd[11516]: = bdb_dn2id: got id=0x002f
Jul  5 11:05:09 ias2 slapd[11516]: = test_filter
Jul  5 11:05:09 ias2 slapd[11516]: EQUALITY
Jul  5 11:05:09 ias2 slapd[11516]: = access_allowed: search access to
SFTid=0001-,ou=servers,o=sft SFTid requested
Jul  5 11:05:09 ias2 slapd[11516]: = acl_get: [1] attr SFTid
Jul  5 11:05:09 ias2 slapd[11516]: = acl_mask: access to entry
SFTid=0001-,ou=servers,o=sft, attr SFTid requested
Jul  5 11:05:09 ias2 slapd[11516]: = acl_mask: to value by , (=0)
Jul  5 11:05:09 ias2 slapd[11516]: = check a_dn_pat: self
Jul  5 11:05:09 ias2 slapd[11516]: = check a_peername_path: 10.16.13.84
Jul  5 11:05:09 ias2 slapd[11516]: = check a_peername_path:
^IP=10.16.13.8[1-6]:
Jul  5 11:05:09 ias2 slapd[11516]: = acl_string_expand: pattern:
^IP=10.16.13.8[1-6]:
Jul  5 11:05:09 ias2 slapd[11516]: = acl_string_expand: expanded:
^IP=10.16.13.8[1-6]:
Jul  5 11:05:09 ias2 slapd[11516]: = regex_matches: string:^I
IP=127.0.0.1:46724
Jul  5 11:05:09 ias2 slapd[11516]: = regex_matches: rc: 1 no matches
Jul  5 11:05:09 ias2 slapd[11516]: = acl_mask: no more who clauses,
returning =0 (stop)
Jul  5 11:05:09 ias2 slapd[11516]: = access_allowed: search access
denied by =0
Jul  5 11:05:09 ias2 slapd[11516]: = test_filter 50
Jul  5 11:05:09 ias2 slapd[11516]: bdb_search: 47 does not match filter 

-Original Message-
From: Hallvard [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 05, 2007 10:27 AM
To: Brian Gaber
Cc: openldap-software@openldap.org
Subject: Re: Challenge With Access Control

Brian Gaber writes:
 access  to *
   by self write
   by peername=10.16.13.84 write
   by peername=10.16.13.81 read
   by peername=10.16.13.82 read
   by peername=10.16.13.83 read
   by peername=10.16.13.85 read
   by peername=10.16.13.86 read

Use peername.ip instead of peername, just like in the one which does
work.  Or replace the read lines with
by peername.regex=^IP=10\.16\.13\.8[1-6]: read

--
Regards,
Hallvard



RE: Challenge With Access Control

2007-07-05 Thread Brian Gaber
Michal,

Thanks, that worked.

Brian 

-Original Message-
From: Michal Dobroczynski [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 05, 2007 11:25 AM
To: Brian Gaber
Cc: openldap-software@openldap.org
Subject: Re: Challenge With Access Control

Add -h 10.16.13.84 or whatever the LDAP listens on to ldapsearch and try
again.

Regards,
Michal

On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:
 Michal,

 Tried your suggestion, ldapsearch still fails.  Here is the
log:

 Jul  5 11:09:31 ias2 slapd[11565]: entry_decode:
 SFTid=0002-,ou=servers,o=sft
 Jul  5 11:09:31 ias2 slapd[11565]: =
 entry_decode(SFTid=0002-,ou=servers,o=sft)
 Jul  5 11:09:31 ias2 slapd[11565]: =
 bdb_dn2id(SFTid=0002-,ou=servers,o=sft)
 Jul  5 11:09:31 ias2 slapd[11565]: = bdb_dn2id: got id=0x0030 Jul

 5 11:09:31 ias2 slapd[11565]: = test_filter
 Jul  5 11:09:31 ias2 slapd[11565]: EQUALITY
 Jul  5 11:09:31 ias2 slapd[11565]: = access_allowed: search access to

 SFTid=0002-,ou=servers,o=sft SFTid requested Jul  5 
 11:09:31 ias2 slapd[11565]: = acl_get: [1] attr SFTid Jul  5 11:09:31

 ias2 slapd[11565]: = acl_mask: access to entry 
 SFTid=0002-,ou=servers,o=sft, attr SFTid requested Jul  5 
 11:09:31 ias2 slapd[11565]: = acl_mask: to value by , (=0) Jul  5 
 11:09:31 ias2 slapd[11565]: = check a_dn_pat: self Jul  5 11:09:31 
 ias2 slapd[11565]: = check a_peername_path: 10.16.13.84 Jul  5 
 11:09:31 ias2 slapd[11565]: = check a_peername_path:
 IP=10.16.13.8[1-6]*
 Jul  5 11:09:31 ias2 slapd[11565]: = acl_string_expand: pattern:
 IP=10.16.13.8[1-6]*
 Jul  5 11:09:31 ias2 slapd[11565]: = acl_string_expand: expanded:
 IP=10.16.13.8[1-6]*
 Jul  5 11:09:31 ias2 slapd[11565]: = regex_matches: string:^I
 IP=127.0.0.1:46749
 Jul  5 11:09:31 ias2 slapd[11565]: = regex_matches: rc: 1 no matches 
 Jul  5 11:09:31 ias2 slapd[11565]: = acl_mask: no more who clauses,

 returning =0 (stop) Jul  5 11:09:31 ias2 slapd[11565]: = 
 access_allowed: search access denied by =0 Jul  5 11:09:31 ias2 
 slapd[11565]: = test_filter 50 Jul  5 11:09:31 ias2 slapd[11565]: 
 bdb_search: 48 does not match filter

 -Original Message-
 From: Michal Dobroczynski [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 05, 2007 11:01 AM
 To: Brian Gaber
 Cc: openldap-software@openldap.org
 Subject: Re: Challenge With Access Control

 As far as I understand the log - you need to include the port. This 
 should help then:

 by peername.regex=IP=10\.16\.13\.8[1-6]:[0-9]* read

 Regards,
 Michal

 On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:
  Tried your suggestion and still have a problem.
 
  Here is the new slapd.conf:
 
  access to *
by self write
by peername.ip=10.16.13.84 write
by peername.regex=IP=10\.16\.13\.8[1-6] read
 
  Here is the log:
 
  entry_decode: SFTid=0001-,ou=servers,o=sft
  Jul  5 10:46:35 ias2 slapd[11401]: =
  entry_decode(SFTid=0001-,ou=servers,o=sft)
  Jul  5 10:46:35 ias2 slapd[11401]: =
  bdb_dn2id(SFTid=0001-,ou=servers,o=sft)
  Jul  5 10:46:35 ias2 slapd[11401]: = bdb_dn2id: got id=0x002f 
  Jul

  5 10:46:35 ias2 slapd[11401]: = test_filter
  Jul  5 10:46:35 ias2 slapd[11401]: EQUALITY
  Jul  5 10:46:35 ias2 slapd[11401]: = access_allowed: search access 
  to

  SFTid=0001-,ou=servers,o=sft SFTid requested Jul  5
  10:46:35 ias2 slapd[11401]: = acl_get: [1] attr SFTid Jul  5 
  10:46:35

  ias2 slapd[11401]: = acl_mask: access to entry 
  SFTid=0001-,ou=servers,o=sft, attr SFTid requested Jul  
  5
  10:46:35 ias2 slapd[11401]: = acl_mask: to value by , (=0) Jul  5
  10:46:35 ias2 slapd[11401]: = check a_dn_pat: self Jul  5 10:46:35
  ias2 slapd[11401]: = check a_peername_path: 10.16.13.84 Jul  5
  10:46:35 ias2 slapd[11401]: = check a_peername_path:
  IP=10.16.13.8[1-6]
  Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: pattern:
  IP=10.16.13.8[1-6]
  Jul  5 10:46:35 ias2 slapd[11401]: = acl_string_expand: expanded:
  IP=10.16.13.8[1-6]
  Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: string:^I
  IP=127.0.0.1:46504
  Jul  5 10:46:35 ias2 slapd[11401]: = regex_matches: rc: 1 no 
  matches Jul  5 10:46:35 ias2 slapd[11401]: = acl_mask: no more 
  who clauses,

  returning =0 (stop) Jul  5 10:46:35 ias2 slapd[11401]: =
  access_allowed: search access denied by =0 Jul  5 10:46:35 ias2
  slapd[11401]: = test_filter 50
 
  -Original Message-
  From: Michal Dobroczynski [mailto:[EMAIL PROTECTED]
  Sent: Thursday, July 05, 2007 10:36 AM
  To: Brian Gaber
  Cc: openldap-software@openldap.org
  Subject: Re: Challenge With Access Control
 
  On 05/07/07, Brian Gaber [EMAIL PROTECTED] wrote:
  
  
  
   Hope someone can explain this to me.  I am sure it is very
trivial.

   I
 
   have a primary LDAP server (10.16.13.84), a replica LDAP server
   (10.16.13.85) and a few clients all with a 10.16.13.x address.
  
   Here is the access control I thought would work:
  
   access  to *
 by self write

No such object error after converting from 2.0.27 to 2.3.32

2007-07-04 Thread Brian Gaber
Took the slapcat output from version 2.0.27 (ldbm) to version 2.3.32
(bdm). Used /usr/local/bin/slapadd on 2.3.32 and am using Berkeley
4.5.20. The slapadd works fine. Then I issued chown ldap:ldap on the
/var/lib/ldap-2.3.32 directory and files. Any type of ldapsearch results
in a 32 no such object. The identical ldapsearch on the old ldap works
fine.

Search:
/usr/local/bin/ldapsearch -h 10.16.13.85 -x -b o=pwgsc -s sub uid=gaberb

Slapd.conf:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/fw1ng.schema

pidfile /usr/local/var/run/slapd.pid
argsfile/usr/local/var/run/slapd.args

allow bind_v2
#loglevel 296

sizelimit 50
access  to *
  by self write
  by peername=10.16.13.84 write
  by peername=10.16.13.81 read
  by peername=10.16.13.82 read
  by peername=10.16.13.83 read
  by peername=10.16.13.85 read
  by peername=10.16.13.86 read

database   bdb
suffix  o=pwgsc
rootdn  cn=admin,o=pwgsc
rootpw  {CRYPT}iWkhys7q1iVpM
directory   /var/lib/ldap-2.3.32

# Indices to maintain
index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
index   cn,mail,surname,givenname   eq,subinitial

# Master from which we should accept changes
updatedn cn=admin,o=pwgsc
updateref ldap://10.16.13.84

Log:

do_bind: v3 anonymous bind
daemon: activity on 1 descriptor
daemon: activity on: 10r
daemon: read activity on 10
connection_get(10)
connection_get(10): got connid=0
connection_read(10): checking for input on id=0
ber_get_next
ldap_read: want=8, got=8
  :  30 2d 02 01 02 63 28 040-...c(.

ldap_read: want=39, got=39
  :  07 6f 3d 70 77 67 73 63  0a 01 02 0a 01 00 02 01
.o=pwgsc  
  0010:  00 02 01 00 01 01 00 a3  0c 04 03 75 69 64 04 05
...uid..  
  0020:  66 61 74 61 6d 30 00   fatam0.

ber_get_next: tag 0x30 len 45 contents:
ber_dump: buf=0x081ff3d8 ptr=0x081ff3d8 end=0x081ff405 len=45
  :  02 01 02 63 28 04 07 6f  3d 70 77 67 73 63 0a 01
...c(..o=pwgsc..  
  0010:  02 0a 01 00 02 01 00 02  01 00 01 01 00 a3 0c 04
  
  0020:  03 75 69 64 04 05 66 61  74 61 6d 30 00
.uid..fatam0. 
ber_get_next
do_search
ber_scanf fmt ({mb) ber:
ldap_read: want=8 error=Resource temporarily unavailable
ber_dump: buf=0x081ff3d8 ptr=0x081ff3db end=0x081ff405 len=42
  :  63 28 04 07 6f 3d 70 77  67 73 63 0a 01 02 0a 01
c(..o=pwgsc.  
  0010:  00 02 01 00 02 01 00 01  01 00 a3 0c 04 03 75 69
..ui  
  0020:  64 04 05 66 61 74 61 6d  30 00 d..fatam0.

daemon: select: listen=6 active_threads=0 tvp=NULL
 dnPrettyNormal: o=pwgsc
= ldap_bv2dn(o=pwgsc,0)
= ldap_bv2dn(o=pwgsc)=0 
= ldap_dn2bv(272)
= ldap_dn2bv(o=pwgsc)=0 
= ldap_dn2bv(272)
= ldap_dn2bv(o=pwgsc)=0 
 dnPrettyNormal: o=pwgsc, o=pwgsc
SRCH o=pwgsc 2 00 0 0
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0x081ff3d8 ptr=0x081ff3f5 end=0x081ff405 len=16
  :  a3 0c 04 03 75 69 64 04  05 66 61 74 61 6d 30 00
uid..fatam0.  
end get_filter 0
filter: (uid=fatam)
ber_scanf fmt ({M}}) ber:
ber_dump: buf=0x081ff3d8 ptr=0x081ff403 end=0x081ff405 len=2
  :  00 00  ..

attrs:
== limits_get: conn=0 op=1 dn=[anonymous]
= bdb_search
bdb_dn2entry(o=pwgsc)
= bdb_dn2id(o=pwgsc)
= bdb_dn2id: got id=0x0001
send_ldap_result: conn=0 op=1 p=3
send_ldap_result: err=32 matched= text=
send_ldap_response: msgid=2 tag=101 err=32
ber_flush: 14 bytes to sd 10
  :  30 0c 02 01 02 65 07 0a  01 20 04 00 04 00 0e...

ldap_write: want=14, written=14
  :  30 0c 02 01 02 65 07 0a  01 20 04 00 04 00 0e...

daemon: activity on 1 descriptor
daemon: activity on: 10r
daemon: read activity on 10
connection_get(10)
connection_get(10): got connid=0
connection_read(10): checking for input on id=0
ber_get_next
ldap_read: want=8, got=7
  :  30 05 02 01 03 42 00   0B.

ber_get_next: tag 0x30 len 5 contents:
ber_dump: buf=0x082008e0 ptr=0x082008e0 end=0x082008e5 len=5
  :  02 01 03 42 00 ...B.

ber_get_next
ldap_read: want=8, got=0

ber_get_next on fd 10 failed errno=0 (Success)
connection_read(10): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=10 for close
do_unbind
connection_close: deferring conn=0 sd=10
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: activity on 1 descriptor
daemon: waked
connection_resched: attempting closing conn=0 sd=10
daemon: select: listen=6 active_threads=0 tvp=NULL
connection_close: conn=0 sd=10
daemon: removing 10
daemon: shutdown requested and initiated.
daemon: closing 6
slapd shutdown: waiting for 0 threads to terminate
slapd shutdown: initiated

No such object error after converting from 2.0.27 to 2.3.32

2007-05-07 Thread Brian Gaber
Took the slapcat output from version 2.0.27 (ldbm) to version 2.3.32
(bdm).  Used slapadd on 2.3.32 and am using Berkeley 4.2.52.  The
slapadd works fine.  Then I issued chown ldap:ldap on the
/var/lib/ldap-2.3.32 directory and files.  Any type of ldapsearch
results in a 32 no such object.  The identical ldapsearch on the old
ldap works fine.
 
 Thanks.


ldapsearch returns nothing after upgrade from v2.0.27-11 to v2.3.20

2006-05-09 Thread Brian Gaber
After installing version 2.3.20 and running slapcat to populate database with 
data from version 2.0.27 I get this on a test search:

/usr/local/bin/ldapsearch -h 10.19.14.141 -x -b o=pwgsc -s sub uid=gaberb
# extended LDIF
#
# LDAPv3
# base o=pwgsc with scope subtree
# filter: uid=gaberb
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

An identical search when OpenLDAP version 2.0.27 is running returns:

version: 2

#
# filter: uid=gaberb
# requesting: ALL
#

# brian gaber, gtis, ked1, ncr, pwgsc
dn: cn=brian gaber,ou=gtis,ou=ked1,ou=ncr,o=pwgsc
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: fw1person
...
...
...

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


RE: ldapsearch returns nothing after upgrade from v2.0.27-11 to v2.3.20

2006-05-09 Thread Brian Gaber


-Original Message-
From: Quanah Gibson-Mount [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 1:35 PM
To: Brian Gaber; OpenLDAP-software@OpenLDAP.org
Subject: Re: ldapsearch returns nothing after upgrade from v2.0.27-11 to v2.3.20

Thanks for responding.

Have you updated your ACL's to the 2.3 syntax?

Here is what I have

access  to *
  by self write
  by peername=10.19.14.141 write

I have also converted it to slapd.d directory with same results.

Have you examined the log files?
What log files would you recommend?  I have tried debug 255 which I can port.

I assume you ran slapcat with the 2.0 slapcat, and then used the 2.3 
slapadd when creating your DB..

Yes, Version 2.0 slapcat.
Yes, Version 2.3 slapadd and it was created without error.

Brian Gaber
Connectivity Services
Public Works and Government Services Canada


More Attributes with slapcat than with ldapsearch

2006-03-29 Thread Brian Gaber
Why does slapcat produce a LDIF entry with attributes that ldapsearch does not 
show?

With my slapcat I get these additional attributes (with values), not shown by 
ldapsearch:

creatorsName:
createTimestamp:
modifiersName:
modifyTimestamp:





Could not locate TLS/SSL package

2005-07-12 Thread Brian Gaber
Here are my paths

LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.3/lib
LDFLAGS=-L/usr/local/lib -L/usr/local/BerkeleyDB.4.3/lib -L/usr/local/ssl/lib 
-L/usr/kerberos/lib
CPPFLAGS=-I/usr/local/include -I/usr/local/BerkeleyDB.4.3/include 
-I/usr/local/ssl/include -I/usr/local/ssl/include/openssl 
-I/usr/kerberos/include

Here is my configure command:

./configure --with-ssl --with-tls --enable-wrappers --enable-hdb --enable-ldbm 
--enable-crypt

Here are the last six lines of the configure output

checking for openssl/ssl.h... yes
checking for ssl.h... yes
checking for SSLeay_add_ssl_algorithms in -lssl... no
checking for SSL_library_init in -lssl... no
checking for ssl3_accept in -lssl... no
configure: error: Could not locate TLS/SSL package

Appreciate any hints.