(ITS#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
After heavily loading a MMR pool, valgrind finds the following:
==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely
lo
st in loss record 13 of 15
==29650== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==29650== by 0x825903B: ber_memalloc_x (memory.c:226)
==29650== by 0x80A743C: ch_malloc (ch_malloc.c:54)
==29650== by 0x82029CA: syncprov_op_search (syncprov.c:2200)
==29650== by 0x8104F7B: overlay_op_walk (backover.c:660)
==29650== by 0x81051B0: over_op_func (backover.c:722)
==29650== by 0x8105234: over_op_search (backover.c:744)
==29650== by 0x80897F6: fe_op_search (search.c:366)
==29650== by 0x8089196: do_search (search.c:217)
==29650== by 0x8085F41: connection_operation (connection.c:1090)
==29650== by 0x808641B: connection_read_thread (connection.c:1216)
==29650== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663)
==29650== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so)
==29650== by 0xD42DBD: clone (in /lib/libc-2.5.so)
==29594== 2,913 (160 direct, 2,753 indirect) bytes in 2 blocks are definitely
lo
st in loss record 10 of 15
==29594== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==29594== by 0x825903B: ber_memalloc_x (memory.c:226)
==29594== by 0x80A743C: ch_malloc (ch_malloc.c:54)
==29594== by 0x82029CA: syncprov_op_search (syncprov.c:2200)
==29594== by 0x8104F7B: overlay_op_walk (backover.c:660)
==29594== by 0x81051B0: over_op_func (backover.c:722)
==29594== by 0x8105234: over_op_search (backover.c:744)
==29594== by 0x80897F6: fe_op_search (search.c:366)
==29594== by 0x8089196: do_search (search.c:217)
==29594== by 0x8085F41: connection_operation (connection.c:1090)
==29594== by 0x808641B: connection_read_thread (connection.c:1216)
==29594== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663)
==29594== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so)
==29594== by 0xD42DBD: clone (in /lib/libc-2.5.so)
p.
14 years, 6 months
Re: (ITS#5825) syncrepl default is no retry
by ando＠sys-net.it
hyc(a)symas.com wrote:
> ando(a)sys-net.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version: irrelevant
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (82.63.140.131)
>> Submitted by: ando
>>
>>
>> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with
>> no retry will probably break, sooner or later, without notifying why it
>> happened.
>
> Legacy behavior, since retry was added later...
>
>> I believe it would be safe to have either:
>>
>> - a "safe" retry value (not too often, e.g. every hour, forever)
>
> Sounds fine, just add it to the doc.
>
>> - a warning (or an error) if retry is not given when configuring syncrepl
>
> Sounds rather annoying. We could combine these: if no retry was configured,
> give the warning and use a default of 1 hour. Have to ensure that the default
> setting doesn't persist in cn=config, so that it will keep warning until an
> explicit value is set.
>
>> Another interesting feature would be to register syncrepl-specific parameters in
>> back-monitor's entry of each database, that
>
>> - show the status of syncrepl (whether it's up, if rp)
>>
>> - show the timestamp of the last successful refresh
>>
>> - show the timestamp of the last failed attempt, and the reason of the failure
>
> Sounds fine, but unless you can add these quickly I don't see any reason to
> hold 2.4.13 for it.
Didn't mean to :) By now, only the warning is being issued. I don't
think I can implement the rest for 2.4.13, will need to wait for next
release.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 6 months
Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ghenry＠OpenLDAP.org
----- hyc(a)symas.com wrote:
> h.b.furuseth(a)usit.uio.no wrote:
> > Pierangelo Masarati writes:
> >> -ZZ should be deprecated, and -Z should simply and strictly
> require
> >> StartTLS.
> >
> > Good point. Except then people who are used to new clients will
> > make insecure connections when using old clients. Maybe -Z should
> > be an error instead...
> >
> > What I'd really really like to do is throw away all the options,
> > rename the programs, and start over. This time with the same
> option
> > names in ldap tools, slap tools, and slapd itself. Goes with the
> > someday-in-the-future library rewrite, I suppose.
>
> OpenLDAP 3.0...
>
> The question is, when do we stop the 2.x stream and begin 3.0?
Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-)
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
14 years, 6 months
Re: (ITS#5825) syncrepl default is no retry
by hyc＠symas.com
ando(a)sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version: irrelevant
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.63.140.131)
> Submitted by: ando
>
>
> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with
> no retry will probably break, sooner or later, without notifying why it
> happened.
Legacy behavior, since retry was added later...
> I believe it would be safe to have either:
>
> - a "safe" retry value (not too often, e.g. every hour, forever)
Sounds fine, just add it to the doc.
> - a warning (or an error) if retry is not given when configuring syncrepl
Sounds rather annoying. We could combine these: if no retry was configured,
give the warning and use a default of 1 hour. Have to ensure that the default
setting doesn't persist in cn=config, so that it will keep warning until an
explicit value is set.
> Another interesting feature would be to register syncrepl-specific parameters in
> back-monitor's entry of each database, that
> - show the status of syncrepl (whether it's up, if rp)
>
> - show the timestamp of the last successful refresh
>
> - show the timestamp of the last failed attempt, and the reason of the failure
Sounds fine, but unless you can add these quickly I don't see any reason to
hold 2.4.13 for it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 6 months
(ITS#5825) syncrepl default is no retry
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: irrelevant
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.63.140.131)
Submitted by: ando
Syncrepl by default uses no retry. This is extremely useless, as syncrepl with
no retry will probably break, sooner or later, without notifying why it
happened.
I believe it would be safe to have either:
- a "safe" retry value (not too often, e.g. every hour, forever)
- a warning (or an error) if retry is not given when configuring syncrepl
Another interesting feature would be to register syncrepl-specific parameters in
back-monitor's entry of each database, that
- show the status of syncrepl (whether it's up, if rp)
- show the timestamp of the last successful refresh
- show the timestamp of the last failed attempt, and the reason of the failure
p.
14 years, 6 months
ldap_domain2hostlist is for "ldap" service only
by Marc Lavergne
Have there been any considerations in providing a similar API for a
service name other than "ldap"? For example, what if I wanted to find
global catalog servers? Even though GCs are Active Directory specific, I
don't see why OpenLDAP would not support that type of query. It seems like
a new API where the service name can be passed in as a parameter (eg.
"gc") would be useful. Before using ITS to issue a bug report, I thought
I'd ask via this forum.
Thanks.
14 years, 6 months
Re: (ITS#5821) Small mistake in man page
by ando＠sys-net.it
andrew.findlay(a)skills-1st.co.uk wrote:
> On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote:
>
>> In the manpage for slapd.conf (slapd.conf.5) in the limits directive description
>> the value for the size.unchecked pattern should be disabled and not disable
>> according to limits.c
>
> Well spotted!
>
> I am curious about why this feature was added. The man page says:
>
> If it is set to disable, the search is not even performed; this
> can be used to disallow searches for a specific set of users.
>
> Disallowing searches seems more like an ACL job than a limit job
> to me, so I did not mention this when writing up the Limits features
> for the Admin Guide.
>
> Does anyone actually use unchecked=disabled and if so, why?
ACLs act too late, after the search has been performed; this acts at the
candidate selection level, and with similar granularity in terms of
identity the request is performed as. Now, search access to the
searchBase is checked, so a search can be stopped even earlier. This
was not requested when this limits feature was introduced.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 6 months
Re: (ITS#5821) Small mistake in man page
by andrew.findlay＠skills-1st.co.uk
On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote:
> In the manpage for slapd.conf (slapd.conf.5) in the limits directive description
> the value for the size.unchecked pattern should be disabled and not disable
> according to limits.c
Well spotted!
I am curious about why this feature was added. The man page says:
If it is set to disable, the search is not even performed; this
can be used to disallow searches for a specific set of users.
Disallowing searches seems more like an ACL job than a limit job
to me, so I did not mention this when writing up the Limits features
for the Admin Guide.
Does anyone actually use unchecked=disabled and if so, why?
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
14 years, 6 months
Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Pierangelo Masarati writes:
>> -ZZ should be deprecated, and -Z should simply and strictly require
>> StartTLS.
>
> Good point. Except then people who are used to new clients will
> make insecure connections when using old clients. Maybe -Z should
> be an error instead...
>
> What I'd really really like to do is throw away all the options,
> rename the programs, and start over. This time with the same option
> names in ldap tools, slap tools, and slapd itself. Goes with the
> someday-in-the-future library rewrite, I suppose.
OpenLDAP 3.0...
The question is, when do we stop the 2.x stream and begin 3.0?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 6 months
