ITS#3707 filters
by hyc＠symas.com
I've had a patch for the Filter handling sitting here half-finished for
quite a while. The intent is to preserve all of the original filter data
so that it can be reused directly.
On a related note, RFC4511 changes the behavior of presence matching on
unknown attributes to be Undefined now instead of FALSE. So presumably
we should update our code accordingly.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
14 years, 11 months
Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com
hyc(a)OpenLDAP.org wrote:
> I presume there's some kind of callback for registering new suffixes but I
> haven't looked very hard.
This highlights some other issues lurking in here - back-monitor
basically doesn't deal with dynamic configuration well at all. It
assumes that all databases and overlays have been fully configured by
the time it starts - an assumption that was valid for old-style
slapd.conf use, but not with back-config.
The monitor_subsys_database_init_one() function probably needs to be
split into separate pieces so that database and overlay info can be set
up and removed incrementally.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
14 years, 11 months
(ITS#4789) can't add BDB database when monitoring
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
When back-monitor is active, attempting to add a bdb database thru cn=config
fails in bdb_monitor_db_open. The call to mbe->register_entry_attrs() fails
because the new database's suffixes aren't known to back-monitor:
monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one
filter="(namingContexts:distinguishedNameMatch:=dc=foo,dc=example,dc=com)":
unable to find entry
====> bdb_cache_release_all
backend_startup_one: bi_db_open failed! (-1)
olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=example,dc=com)!
send_ldap_result: conn=0 op=12 p=3
send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup"
I presume there's some kind of callback for registering new suffixes but I
haven't looked very hard.
14 years, 11 months
Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu
On Wednesday 20 December 2006 01:43, dhawes(a)vt.edu wrote:
> On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote:
> > David Hawes wrote:
> > > Here's the valgrind output with the set clause in place:
> > >
> > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log
> > >
> > > Here's the valgrind output without the set clause (for reference):
> > >
> > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log
> > >
> > > The following patch causes memory use to stabilize with my SLAMD test:
> >
> > Try the patch in HEAD sets.c 1.29 -> 1.30.
>
> I haven't tested the patch with valgrind yet, but I no longer see the
> memory leak with my SLAMD test.
Just to follow up, I no longer see the memory leaks with valgrind.
dave
14 years, 11 months
Re: (ITS#4788) test043-delta-syncrepl failed (exit 49)
by hyc＠symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD
> OS: SuSE Linux 10.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.124.24.222)
>
>
>>>>>> Starting test043-delta-syncrepl ...
> running defines.sh
> Starting master slapd on TCP/IP port 9011...
> Using ldapsearch to check that master slapd is running...
> Using ldapadd to create the context prefix entries in the master...
> Starting slave slapd on TCP/IP port 9012...
> Using ldapsearch to check that slave slapd is running...
> Using ldapadd to populate the master directory...
> Waiting 15 seconds for syncrepl to receive changes...
> Stopping the provider, sleeping 10 seconds and restarting it...
> Using ldapsearch to check that master slapd is running...
> Using ldapmodify to modify master directory...
> Waiting 15 seconds for syncrepl to receive changes...
> Stopping consumer to test recovery...
> Modifying more entries on the master...
> Restarting consumer...
> Waiting 25 seconds for syncrepl to receive changes...
> Try updating the slave slapd...
> ldapmodify failed (49)!
>>>>>> ./scripts/test043-delta-syncrepl failed (exit 49)
> make[2]: *** [bdb-mod] Error 49
> make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests'
> make: *** [test] Error 2
You didn't look back far enough in slapd.2.log; the real error is here:
syncrepl_message_to_entry: rid 001 mods check (auditContext: attribute
type undefined)
ldap_msgfree
this is from Ando's recent patch to accesslog.c. I think that an
appropriate fix would be to exclude dsaOperational attributes from
replication since they only have meaning on the hosting DSA.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
14 years, 11 months
(ITS#4788) test043-delta-syncrepl failed (exit 49)
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: HEAD
OS: SuSE Linux 10.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.124.24.222)
>>>>> Starting test043-delta-syncrepl ...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to create the context prefix entries in the master...
Starting slave slapd on TCP/IP port 9012...
Using ldapsearch to check that slave slapd is running...
Using ldapadd to populate the master directory...
Waiting 15 seconds for syncrepl to receive changes...
Stopping the provider, sleeping 10 seconds and restarting it...
Using ldapsearch to check that master slapd is running...
Using ldapmodify to modify master directory...
Waiting 15 seconds for syncrepl to receive changes...
Stopping consumer to test recovery...
Modifying more entries on the master...
Restarting consumer...
Waiting 25 seconds for syncrepl to receive changes...
Try updating the slave slapd...
ldapmodify failed (49)!
>>>>> ./scripts/test043-delta-syncrepl failed (exit 49)
make[2]: *** [bdb-mod] Error 49
make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests'
make: *** [test] Error 2
----------------------------------------------------------------------------
test.out:
ldap_initialize( ldap://localhost:9012 )
ldap_bind: Invalid credentials (49)
----------------------------------------------------------------------------
last lines of slapd.2.log
slap_listener_activate(7):
>>> slap_listener(ldap://localhost:9012/)ldap_pvt_gethostbyname_a: host=nb2,
r=0
conn=0 fd=11 ACCEPT from IP=127.0.0.1:6312 (IP=127.0.0.1:9012)
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 46 contents:
ber_get_next
ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable)
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
>>> dnPrettyNormal: <cn=Manager,dc=example,dc=com>
=> ldap_bv2dn(cn=Manager,dc=example,dc=com,0)
<= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=example,dc=com)=0
<<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>,
<cn=manager,dc=example,dc=com>
do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128
conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128
==> bdb_bind: dn: cn=Manager,dc=example,dc=com
bdb_dn2entry("cn=manager,dc=example,dc=com")
=> bdb_dn2id("dc=example,dc=com")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)
send_ldap_result: conn=0 op=0 p=3
send_ldap_result: err=49 matched="" text=""
send_ldap_response: msgid=1 tag=97 err=49
ber_flush2: 14 bytes to sd 11
conn=0 op=0 RESULT tag=97 err=49 text=
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
ber_get_next
ber_get_next on fd 11 failed errno=0 (Success)
connection_closing: readying conn=0 sd=11 for close
connection_close: conn=0 sd=11
conn=0 fd=11 closed (connection lost)
daemon: shutdown requested and initiated.
slapd shutdown: waiting for 0 threads to terminate
lt-slapd shutdown: initiated
====> bdb_cache_release_all
lt-slapd destroy: freeing system resources.
14 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it
fcusack(a)fcusack.com wrote:
> But still you can do the bind async, and just close the fd on the client
> side on timeout. I don't see why connect() timeout can't be handled
> the same way. (ignoring the problem that there is no API call AFAICT
> to just drop the connection)
>
I'll note that there's been some interest in that area --- I loosely
have the same need (see
<http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but
unfortunately it's not in my priority list, considering that it might
have relevant impact on the client library.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
14 years, 11 months
Re: (ITS#4784) a small patch for back-sql
by ando＠sys-net.it
> back-sql fails to compile with BACKSQL_TRACE defined, I think this is the
> correct fix.
(blind) fixed in HEAD/re23.
Thanks for reporting. p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
14 years, 11 months
(ITS#4787) Download links with version vs. date
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: not relevant
OS: not relevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.124.17.77)
HI!
It's hard for beginners to understand the download links here:
http://www.openldap.org/software/download/
The file names of latest release contains the release number but the file names
of releases tagged as "stable" contains the release date. Current example:
2.3.31
ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.3.31.tgz
2.3.27 (20060823)
ftp://ftp.openldap.org/pub/OpenLDAP/openldap-stable/openldap-stable-20060...
I see several problems with this current practice:
1. Common practice in other open source projects is to create file names with
dates only for CVS/SVN snapshots. So it might be hard for beginners to recognize
that these files are really stable releases even though the string "stable" is
also in the file name. Note that these .tar.gz files could be obtained from
another source, not directly from the official download page.
2. On the mailing lists always the version number is referred/proposed. But this
does not appear in the file name. And frankly no-one remembers the release
dates. Especially since also CHANGES does not contain the release dates. So the
only mapping is the download page.
3. Common practice is that the root directory name within the .tar.gz matches
the exact version in the .tar.gz file name.
=> I'd recommend to always create the same form of file names containing solely
the release version. I see no benefit in using the date at all.
Ciao, Michael.
14 years, 11 months
Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com
Pierangelo Masarati wrote:
> I'll note that unless you defined it yourself, "dn" is not a valid
> attribute name. I suspect your back-sql meta-data generates an entry
> that doesn't pass schema checking, otherwise I don't see a chance for
> that error to be reported.
Pierangelo,
the objects are inetOrgPerson objects, the full object looks like this
# robb(a)example.org, sql.example.org
dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org
objectClass: inetOrgPerson
cn: Robert Brooks
uid: robb(a)example.org
mail: robb(a)example.org
I believe the only required attribute for such an object is cn. A
similar search against a non back-sql part for the tree (see below) does
not show an error
ldapsearch -x -b "ou=people,dc=example,dc=org" "cn=Robert Brooks" dn cn
objectclass
# robb, people, example.org
dn: uid=robb,ou=people,dc=example,dc=org
cn: Robert Brooks
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
Unfortunately seems some software doesn't understand it doesn't need to
request dn explicitly hence I noticed this.
> In any case, since the behavior you report is very data and meta-data
> dependent, you don't provide enough info for debugging, and at a very
> first glance this is not indicative of a software bug.
Let me know what you'd like, I thought this one may well reproduce on
any back-sql, so didn't spray the ITS with extraneous information.
Regards,
Rob
--
Robert Brooks, Network Manager, Cable & Wireless UK
<robb(a)wtg.cw.com> http://wtg.cw.com/
Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601
- "What was your username again?" - BOFH -
14 years, 11 months
