Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it
Sebastian,
Thanks for the contribution.
I have a few comments (also gathered from others):
1) you should provide patches against HEAD code; there has been some
limited changes in the API related to overlay initialization and so.
2) you could try to rework the overlay to avoid any specific reference
to Active Directory, since your cache should apply to any remote system
implementing Kerberos V. It could be abstracted even more, to act as a
replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
not just Kerberos.
3) you should add a (configurable) TTL, so that the cache could
eventually be notified of an account lockout at the remote server's side.
4) you should add support for dynamic configuration, so that the module
can fit into the new configuration paradigm for possible release with 2.4.
5) you should follow coding guidelines (indentation and so) as in most
of the code.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: (ITS#5073) Syncrepl spinlock
by quanah＠zimbra.com
--On August 6, 2007 5:01:08 PM +0000 quanah(a)zimbra.com wrote:
>
>
> --On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote:
>
>> quanah(a)OpenLDAP.org wrote:
>>> Full_Name: Quanah Gibson-Mount
>>> Version: 2.3.37
>>> OS: Linux
>>> URL:
>>> Submission from: (NULL) (71.202.148.128)
>>>
>>>
>>> If you create a syncrepl master that serves the "" base, and then set up
>>> a syncrepl consumer to pull down "dc=example,dc=com", which does *not*
>>> exist on the master, the replica will sit at 100% CPU, endlessly trying
>>> to add nothing.
>>
>> I'm not observing this with either re23 nor HEAD. The initial search
>> correctly fails with noSuchObject, and then both slapds sit at 0% CPU.
>> Can you give further details?
>
> I'll look at reproducing it again.
>
> In this particular case, the master had a database rooted at "", with
> some data around "cn=zimbra" contained in it. A replica was configured
> as a syncrepl client, but with "dc=example,dc=com" as its base, by
> mistake. This resulted in the CPU usage shooting to 100% on the replica,
> and the logs showing it trying to add without success.
Okay, I figured it out -- This is definitely a misconfiguration type
scenario...
The database is something like:
database bdb
base "dc=example,dc=com"
...
Then the syncrepl config has:
searchbase=""
I'm not sure this is something that should be allowed -- where the search
base is broader than the database.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 10 months
Re: (ITS#5073) Syncrepl spinlock
by quanah＠zimbra.com
--On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote:
> quanah(a)OpenLDAP.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.3.37
>> OS: Linux
>> URL:
>> Submission from: (NULL) (71.202.148.128)
>>
>>
>> If you create a syncrepl master that serves the "" base, and then set up
>> a syncrepl consumer to pull down "dc=example,dc=com", which does *not*
>> exist on the master, the replica will sit at 100% CPU, endlessly trying
>> to add nothing.
>
> I'm not observing this with either re23 nor HEAD. The initial search
> correctly fails with noSuchObject, and then both slapds sit at 0% CPU.
> Can you give further details?
I'll look at reproducing it again.
In this particular case, the master had a database rooted at "", with some
data around "cn=zimbra" contained in it. A replica was configured as a
syncrepl client, but with "dc=example,dc=com" as its base, by mistake.
This resulted in the CPU usage shooting to 100% on the replica, and the
logs showing it trying to add without success.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 10 months
(ITS#5076) Spell checking man pages
by ghenry＠OpenLDAP.org
Full_Name: Gavin Henry
Version: HEAD adn RE_23
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.229.93.1)
Submitted by: ghenry
Dear all,
Just creating a ticket for CHANGES, as I'm running:
aspell --lang=en_US -c
on all our manpages in HEAD and RE_23.
Will query if I haev any concerns.
Gavin.
15 years, 10 months
Re: ITS#5075
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> fixed in HEAD; please test.
also fixed in re23; please test.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
ITS#5075
by ando＠sys-net.it
fixed in HEAD; please test.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
(ITS#5075) openldap is not compilable with newest glibc and -D_FORTIFY_SOURCE=2
by jsafranek＠redhat.com
Full_Name: Jan Safranek
Version: 2.3.37
OS: Linux (Fedora rawhide)
URL: http://people.redhat.com/jsafrane/openldap-2.3.37-fortify-open.patch
Submission from: (NULL) (62.40.79.66)
Recently we have integrated glibc 2.6.90 into Fedora Linux distribution and
OpenLDAP is not compilable anymore. We use -D_FORTIFY_SOURCE=2 to check for
common errors on compile time and this switch causes that open() in fcntl.h
is not a function name but a macro in the new glibc headers. Berkeley DB often
uses 'something->open(...)' to open database, which is expanded by the compiler
using the macro from fcntl.h -> compilation error.
Compilation can be easily fixed by using additional braces around open, like
'(something->open)(...)'.
I do not like open() being macro, but POSIX allows it and glibc guys seems to be
quite strict in this. The new glibc shall be released in fall and all major
distributions will use it sooner or later, therefore I would suggest to adapt
few OpenLDAP sources to it.
15 years, 10 months
Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by ando＠sys-net.it
zep-openldap-software(a)ni.enate.org wrote:
> For an application which specifies LDAP_NO_ATTRS to the attributes parameter of
> ldap_search_st(), it seems not possible to cache its results using
> slapo-pcache.
>
> It would be great to be able to define within "overlay pcache", something like:
>
> proxyattrset 0 (1.1)
>
> or, simply
>
> proxyattrset 0
>
> Which would match queries which provide LDAP_NO_ATTRS. This would allow the
> ability to cache responses for routines which are interested only in the
> presence of a result set, but not in the contents of that set, without the
> additional overhead of trasnferring the result.
I believe there's something odd in pcache's current behavior. In fact,
right now "proxyattrset 0" is already a valid directive, but it implies
"proxyattrset 0 *", which means all attributes. Unfortunately, this
seems to only work if no attribute is requested, while it fails if a "*"
is explicitly requested.
I've modified the propxycache code in HEAD so that a "1.1" can only
explicitly appear in a list if it's the only string. An empty attribute
set is no longer valid, to avoid confusion about the meaning of
non-explicit attribute sets. A "*" or a "+" can explicitly appear in a
proxyattrset statement, resulting in the expected behavior. Use both to
indicate that all attributes are in the set.
Please test.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: (ITS#5073) Syncrepl spinlock
by ando＠sys-net.it
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.3.37
> OS: Linux
> URL:
> Submission from: (NULL) (71.202.148.128)
>
>
> If you create a syncrepl master that serves the "" base, and then set up a
> syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on
> the master, the replica will sit at 100% CPU, endlessly trying to add nothing.
I'm not observing this with either re23 nor HEAD. The initial search
correctly fails with noSuchObject, and then both slapds sit at 0% CPU.
Can you give further details?
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
(ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep-openldap-software＠ni.enate.org
Full_Name: Mike Malsman
Version: 2.3.33
OS: FreeBSD 6
URL:
Submission from: (NULL) (65.12.196.28)
For an application which specifies LDAP_NO_ATTRS to the attributes parameter of
ldap_search_st(), it seems not possible to cache its results using
slapo-pcache.
It would be great to be able to define within "overlay pcache", something like:
proxyattrset 0 (1.1)
or, simply
proxyattrset 0
Which would match queries which provide LDAP_NO_ATTRS. This would allow the
ability to cache responses for routines which are interested only in the
presence of a result set, but not in the contents of that set, without the
additional overhead of trasnferring the result.
15 years, 10 months
