(ITS#6605) Webmin LDAP User Module Don't Work
by andrea.minardi＠port.ravenna.it
Full_Name: Andrea Minardi
Version: 2.3.27
OS: RedHat 5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.40.179.242)
Webmin's LDAP Users and Groups module stopped working after upgrading from
Webmin 1.400 to webmin 1.510
I have been using Webmin's LDAP Users and Groups module on my company's server
to administer users. It was working fine on Webmin 1.400, but after upgrading I
get the error:
"Webmin has connected to the LDAP server, but failed to fetch the schema. Make
sure that access has not been denied in the LDAP Server module."
12 years, 8 months
(ITS#6604) nssov build error
by mhardin＠symas.com
Full_Name: Matt Hardin
Version: 2.4.23
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (184.11.32.102)
nssov.c doesn't compile correctly on systems that don't have a getpeereid
function because it doesn't use the LUTIL_GETPEEREID macro. The following patch
corrects this.
--- nssov.c.orig Mon Jul 26 19:50:47 2010
+++ nssov.c Mon Jul 26 19:32:15 2010
@@ -260,9 +260,15 @@
uid_t uid;
gid_t gid;
char authid[sizeof("gidNumber=4294967295+uidNumber=424967295,cn=peercred,cn=external,cn=auth")];
+#ifdef LDAP_PF_LOCAL_SENDMSG
+ char peerbuf[8];
+ struct berval peerbv = BER_BVNULL;
+ peerbv.bv_val = peerbuf;
+ peerbv.bv_len = sizeof( peerbuf );
+#endif
/* log connection */
- if (lutil_getpeereid(sock,&uid,&gid))
+ if( LUTIL_GETPEEREID( sock, &uid, &gid, &peerbv ))
Debug( LDAP_DEBUG_TRACE,"nssov: connection from unknown client:
%s\n",strerror(errno),0,0);
else
Debug( LDAP_DEBUG_TRACE,"nssov: connection from uid=%d gid=%d\n",
12 years, 8 months
(ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by masarati＠aero.polimi.it
Full_Name: Pierangelo Masarati
Version: irrelevant
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.72.165.243)
Submitted by: ando
At least in libldap and liblber EAGAIN and EWOULDBLOCK are occasionally used
without checking whether they are defined or not. Either the checks should be
removed, counting on the fact that these error codes are always defined, or they
should be used consistently.
12 years, 8 months
Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it
> Full_Name: Jonathan CLARKE
> Version: RE24
> OS:
> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch
> Submission from: (NULL) (80.13.86.63)
>
>
> While checking it's configuration, the pcache overlay verifies each
> configured
> attribute set (pcacheAttrset), to ensure that all attributes in the set
> are
> defined, via slap_str2ad. Given an attribute set with a non-existant
> attribute,
> an error is logged and slapd refuses to start (as expected):
>
> line 117 (pcacheAttrset 0 nonexistantAttr)
> /etc/ldap/slapd.conf: line 117: attribute type undefined.
>
> However, when a search request comes in, the requested attributes list is
> not
> checked by the pcache overlay to ensure that attributes are properly
> defined. In
> effect, slapd just ignores the non-existant attributes, and returns other
> attributes (or behaves as if 1.1 was requested if all requested attributes
> are
> invalid).
>
> This causes pcache's attribute set matching to fail for some requests,
> since it
> counts invalid attributes. If it were to ignore them, configured attribute
> sets
> might match, and successfully cache the search. The patch above implements
> this
> behaviour. Would you consider it for inclusion in OpenLDAP?
>
> I realize this may be considered "repairing bad requests", but sometimes
> one
> can't (easily) control what clients are requesting. Furthermore, it seems
> to
> make sense to have matching behavior all over (since slapd ignores invalid
> requested attributes, pcache should too, IMHO).
Yours looks like a good catch; however, your patch looks a bit like an
overkill, since the an_desc field of the attribute list that is passed to
get_attr_set() should already be set if the attribute was recognized by
slapd, so you don't need to go through slap_bv2ad() once more.
p.
12 years, 8 months
Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com
--On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote:
> Full_Name: Binoy Joseph
> Version: 2.4.21
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (210.210.79.19)
Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking
behavior introduced in 2.4.21 that was backed out in 2.4.23.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
12 years, 8 months
Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no
quanah(a)zimbra.com writes:
>>> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is
>>> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY
>>> somewhere is defined to expand to an expression involving a (long) cast.
>>
>> Apprently so.
>>
>> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259.
>> html>
>
> Fixed by debian.
Which is nice, but doesn't help with older debian versions.
I don't see what's wrong with changing our #elif to #elif defined
like you originally suggested, though I remember there was some
confused #elif discussion earlier.
--
Hallvard
12 years, 8 months
(ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net
Full_Name: Jonathan CLARKE
Version: RE24
OS:
URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch
Submission from: (NULL) (80.13.86.63)
While checking it's configuration, the pcache overlay verifies each configured
attribute set (pcacheAttrset), to ensure that all attributes in the set are
defined, via slap_str2ad. Given an attribute set with a non-existant attribute,
an error is logged and slapd refuses to start (as expected):
line 117 (pcacheAttrset 0 nonexistantAttr)
/etc/ldap/slapd.conf: line 117: attribute type undefined.
However, when a search request comes in, the requested attributes list is not
checked by the pcache overlay to ensure that attributes are properly defined. In
effect, slapd just ignores the non-existant attributes, and returns other
attributes (or behaves as if 1.1 was requested if all requested attributes are
invalid).
This causes pcache's attribute set matching to fail for some requests, since it
counts invalid attributes. If it were to ignore them, configured attribute sets
might match, and successfully cache the search. The patch above implements this
behaviour. Would you consider it for inclusion in OpenLDAP?
I realize this may be considered "repairing bad requests", but sometimes one
can't (easily) control what clients are requesting. Furthermore, it seems to
make sense to have matching behavior all over (since slapd ignores invalid
requested attributes, pcache should too, IMHO).
12 years, 8 months
(ITS#6599) slapd not responding
by binoy＠cordys.com
Full_Name: Binoy Joseph
Version: 2.4.21
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (210.210.79.19)
I run OpenLDAP 2.4.21 configured to bdb on Windows and Linux. We run some
applications on top of our application framework which in turn is connected to
OpenLDAP via JLDAP. We list children of 'cn=soap nodes' (search LDAP) very often
as shown in the DIT below. I wrote a test case to create soapnode, soapproc,
connectionpoint and then delete them one after the other, ie I create set1,
delete set1, create set2, delete set2... Note that list children of 'cn=soap
nodes' happen in parallel as mentioned above.
Randomly but very consistently, suddenly we face an LDAP not responding issue.
When I connect via an LDAP Explorer, I am able to see and expand most of the
LDAP entries, except the 'cn=soap nodes' as shown in the DIT below, which says
LDAP query did not return indefinitely. CPU: slapd shoots to 50% in Windows and
100% in Linux. Then I have to kill slapd and start again.
This does not happen in OpenLDAP 2.4.16. After upgrading to 2.4.21 this started
happening. When I switched to hdb, this does not occur in Linux, but continues
to happen in Windows.
This also looks very similar to
http://www.openldap.org/its/index.cgi?findid=6322, Subject: slapd suddenly stops
working, and starts using 100% CPU.
o=org1
|
+-cn=soap nodes
|
+-cn=soapnode1
| |
| +cn=soapproc1
| |
| +cn=connectionpoint1
|
+-cn=soapnode2
.
.
Thanks and regards,
Binoy Joseph
12 years, 8 months
