Re: (ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠suretecsystems.com
<quote who="Ralf Haferkamp">
> On Friday 20 July 2007 16:45, ghenry(a)openldap.org wrote:
>> Full_Name: Gavin Henry
>> Version: HEAD
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (80.229.93.1)
>> Submitted by: ghenry
>>
>>
>> Dear All,
>>
>> It's not clear or explained what AVA means in slapd-meta(5) and
>> slapo-rwm(5)
>>
>> A user was asking in #ldap
>>
>> I presume it means "Attribute Value"?
> It means "Attribute Value Assertion", normally.
Doh, helped if I read the RFCs.
Oh but look who has a nice page in it:
https://www.opends.org/wiki//page/DefinitionAttributeValueAssertion
Maybe we need a nice OpenLDAP Wiki? (one for -devel list I think)
>
>> If so, I will add an explaination in each man page.
>
> --
> Ralf
>
14 years, 10 months
Re: (ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by rhafer＠suse.de
On Friday 20 July 2007 16:45, ghenry(a)openldap.org wrote:
> Full_Name: Gavin Henry
> Version: HEAD
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.229.93.1)
> Submitted by: ghenry
>
>
> Dear All,
>
> It's not clear or explained what AVA means in slapd-meta(5) and
> slapo-rwm(5)
>
> A user was asking in #ldap
>
> I presume it means "Attribute Value"?
It means "Attribute Value Assertion", normally.
> If so, I will add an explaination in each man page.
--
Ralf
14 years, 10 months
(ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠OpenLDAP.org
Full_Name: Gavin Henry
Version: HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.229.93.1)
Submitted by: ghenry
Dear All,
It's not clear or explained what AVA means in slapd-meta(5) and slapo-rwm(5)
A user was asking in #ldap
I presume it means "Attribute Value"?
If so, I will add an explaination in each man page.
Gavin.
14 years, 10 months
(ITS#5053) openldap 2.3.36 crashing
by igbed＠wmin.ac.uk
Full_Name: Damian Igbe
Version: 2.3.6
OS: SLES 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (161.74.11.24)
I have a delta-syncrepl replication working with password policy in place.
Authentication to the master works fine but when a client tries to authenticate
to the replica server, the following bug is encountered and the system crashes.
bdb_modify: modify failed (20)
send_ldap_result: conn=1 op=3 p=3
send_ldap_response: msgid=4 tag=97 err=49
ber_flush: 82 bytes to sd 17
slapd: ppolicy.c:847: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)'
failed.
Aborted
Please help.
Thanks
Damian
It also happens in other instances with errors such as:
=> key_change(DELETE,13)
<= key_change 0
=> key_change(ADD,13)
<= key_change 0
=> entry_encode(0x00000013):
uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk
bdb_modify: updated id=00000013
dn="uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk"
send_ldap_result: conn=2 op=3 p=3
bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk")
bdb_entry_get: rc=0
bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk")
bdb_entry_get: rc=0
bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk")
bdb_entry_get: rc=0
bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk")
bdb_modify_internal: 0x00000013:
uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk
bdb_modify: modify failed (20)
send_ldap_result: conn=2 op=3 p=3
send_ldap_response: msgid=4 tag=97 err=49
ber_flush: 82 bytes to sd 17
slapd: ppolicy.c:847: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)'
failed.
Aborted
14 years, 10 months
Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD, RE23
> OS:
> URL:
> Submission from: (NULL) (129.240.202.105)
> Submitted by: hallvard
>
>
> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1.
> findcsn_cb() says
> /* We just want to know that at least one exists, so it's OK if
> * we exceed the unchecked limit or size limit.
> */
>
> This looks like it can return a false positive if two or more other
> entries which the filter would eliminate have the same hash as the
> value syncprov searches for.
I don't believe this can cause any problem though. CSN indexing doesn't use a
hash the way other indices do; the CSN timestamp is converted to binary form
and saved as a 40 bit integer. Index collisions will only occur for multiple
changes that occurred within the same 1-second interval.
The purpose of this search is to detect if a consumer's context CSN is stale,
i.e., the provider no longer has any entries as old as the consumer's CSN. The
fact that there is any index collision essentially proves that the CSN is not
stale.
> Also syncprov_findcsn() passes fc_limits uninitialized outside of the
> .lms_s_unchecked field to slapd. Valgrind complains in test018 about
> .lms_s_pr_hide in back-bdb/search.c:bdb_search(). Tested in HEAD.
Fixed in HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 10 months
(ITS#5052) slapadd -q can create invalid index
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.3.x
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (204.95.127.34)
Submitted by: hyc
On a database with a zero-length suffix, slapadd and slapindex in quick mode can
erroneously generate index records for the context entry, which has an entry ID
of zero. The entry ID zero is normally invalid in an index, and is always
filtered out of index operations, but the quick mode indexer didn't exclude it
as it should.
14 years, 10 months
Re: (ITS#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com
<quote who="hyc(a)symas.com">
> ghenry(a)OpenLDAP.org wrote:
>> Full_Name: Gavin Henry
>> Version: 19/07/07 HEAD
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (212.159.59.85)
>> Submitted by: ghenry
>>
>>
>> Dear All,
>>
>> Is slapd not started and giving below expected?
>>
>>
>> ================
>> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor"
>> scope=subordinate
>> filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))":
>> unable to find entry
>> backend_startup_one: bi_db_open failed! (1)
>> slapd shutdown: initiated
>> ================
>>
>> Using a config like:
>>
>> ================
>> include /usr/local/etc/openldap/schema/core.schema
>>
>> pidfile /usr/local/var/run/slapd.pid
>> argsfile /usr/local/var/run/slapd.args
>>
>> # Load dynamic backend modules:
>> modulepath /usr/local/libexec/openldap
>> moduleload back_bdb.la
>> moduleload back_ldap.la
>> moduleload back_monitor.la
>> moduleload translucent.la
>>
>> database bdb
>> directory /usr/local/var/openldap-data
>> cachesize 10000
>> suffix "dc=suretecsystems,dc=com"
>>
>> rootdn "cn=admin,dc=suretecsystems,dc=com"
>> rootpw {SSHA}blah
>>
>> index default eq
>> index objectClass,uid,dc,o,ou
>>
>> overlay translucent
>> uri ldap://x.x.x.x:389
>> idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com"
>> credentials=blah
>>
>> database config
>> rootdn "cn=config"
>> rootpw {SSHA}blah
>>
>> database monitor
>> ================
>>
>>
>> If I remove "database monitor", all is obviously well.
>>
>> However, if I put "database monitor" before "database bdb", slapd starts
>> fine,
>> but complains with:
>>
>> ================
>> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor"
>> scope=subordinate
>> filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))":
>> unable to find entry
>> slapd starting
>> ================
>
> Pretty sure your monitor database needs a rootdn now for this to work.
>
Ok. What can the rootdn do on the monitor database then? Write to anything?
I can update the "Monitoring" section with this info then ;-)
Gavin.
14 years, 10 months
Re: (ITS#5051) Translucent overlay and back-monitor
by hyc＠symas.com
ghenry(a)OpenLDAP.org wrote:
> Full_Name: Gavin Henry
> Version: 19/07/07 HEAD
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.159.59.85)
> Submitted by: ghenry
>
>
> Dear All,
>
> Is slapd not started and giving below expected?
>
>
> ================
> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor"
> scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))":
> unable to find entry
> backend_startup_one: bi_db_open failed! (1)
> slapd shutdown: initiated
> ================
>
> Using a config like:
>
> ================
> include /usr/local/etc/openldap/schema/core.schema
>
> pidfile /usr/local/var/run/slapd.pid
> argsfile /usr/local/var/run/slapd.args
>
> # Load dynamic backend modules:
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb.la
> moduleload back_ldap.la
> moduleload back_monitor.la
> moduleload translucent.la
>
> database bdb
> directory /usr/local/var/openldap-data
> cachesize 10000
> suffix "dc=suretecsystems,dc=com"
>
> rootdn "cn=admin,dc=suretecsystems,dc=com"
> rootpw {SSHA}blah
>
> index default eq
> index objectClass,uid,dc,o,ou
>
> overlay translucent
> uri ldap://x.x.x.x:389
> idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials=blah
>
> database config
> rootdn "cn=config"
> rootpw {SSHA}blah
>
> database monitor
> ================
>
>
> If I remove "database monitor", all is obviously well.
>
> However, if I put "database monitor" before "database bdb", slapd starts fine,
> but complains with:
>
> ================
> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor"
> scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))":
> unable to find entry
> slapd starting
> ================
Pretty sure your monitor database needs a rootdn now for this to work.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 10 months
Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠suretecsystems.com
<quote who="dhawes(a)vt.edu">
> On Thursday 19 July 2007 05:35, Gavin Henry wrote:
>> > An updated version of addpartial is available at:
>> >
>> > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz
>> >
>> > This version includes changes to work with OpenLDAP 2.3 as well as
>> > ensuring syncrepl works properly.
>> >
>> > david hawes
>>
>> If this hasn't been added to 2.4/HEAD yet, would you consider updating
>> it
>> for inclusion in 2.4 contrib?
>
> Absolutely, I've been meaning to test with 2.4. I'll bump it to the top
> of
> the list.
Can you make sure that is dynamically configurable via cn=config like
everything else in 2.4.
Thanks.
>
> dave
>
>
>
14 years, 10 months
Re: Contrib: addpartial overlay (ITS#3593)
by dhawes＠vt.edu
On Thursday 19 July 2007 05:35, Gavin Henry wrote:
> > An updated version of addpartial is available at:
> >
> > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz
> >
> > This version includes changes to work with OpenLDAP 2.3 as well as
> > ensuring syncrepl works properly.
> >
> > david hawes
>
> If this hasn't been added to 2.4/HEAD yet, would you consider updating it
> for inclusion in 2.4 contrib?
Absolutely, I've been meaning to test with 2.4. I'll bump it to the top of
the list.
dave
14 years, 10 months
