openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

RE: ITS#7020
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

> Could you help me to transfer this question to your openldap-technical > mailing list. All you need to do is: - subscribe to the list - post the message to the list's address Instructions here <http://www.openldap.org/lists/mm/listinfo/openldap-technical>. p.

1 0

(ITS#7022) Patch - Mozilla NSS - NSS_Init* functions are not thread safe
by rmeggins＠redhat.com 16 Aug '11

16 Aug '11

Full_Name: Rich Megginson Version: current tip of master branch OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-NSS_Init-functions-are-not-thread-safe… Submission from: (NULL) (76.26.104.137) The NSS_InitContext et. al, and their corresponding shutdown functions, are not thread safe. There can only be one thread at a time calling these functions. Protect the calls with a mutex. Create the mutex using a PR_CallOnce to ensure that the mutex is only created once and not used before created. Move the registration of the nss shutdown callback to also use a PR_CallOnce. Removed the call to SSL_ClearSessionCache() because it is always called at shutdown, and we must not call it more than once. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

hyc(a)symas.com wrote: > You seem to forget that nobody has any obligation to help you, at all. You're > imposing on the generosity of volunteers. And you seem to forget that my testing and filing ITS is also voluntary work. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > Howard Chu wrote: >> Of course, you've also been around the Project for pretty much its entire >> existence, and ought to know by now what information is needed in a useful bug >> report. > > I didn't expect having to provide a complete working setup for each small > issue. MMR setup with slapo-accesslog attached to each provider already says > it all. I also didn't expect to read non-sense about the accesslog DB itself > being replicated (see follow-up 1). > > Demanding more and more information for almost trivial things pretty much > reminds me of bad support for commercial products. You seem to forget that nobody has any obligation to help you, at all. You're imposing on the generosity of volunteers. If you're just going to complain about the response you get, as opposed to trying to help other people help you, then you should not be surprised if no help materializes. I even agree with you that follow-up #1 is nonsense. S#1t happens. Would you prefer that we moderate/censor all replies before they get posted? What exactly is it that you believe you're entitled to? > Now we'll see if this ITS will ever turn out something useful... With an attitude like that, why should anybody even take the time? > Ciao, Michael. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

Howard Chu wrote: > Of course, you've also been around the Project for pretty much its entire > existence, and ought to know by now what information is needed in a useful bug > report. I didn't expect having to provide a complete working setup for each small issue. MMR setup with slapo-accesslog attached to each provider already says it all. I also didn't expect to read non-sense about the accesslog DB itself being replicated (see follow-up 1). Demanding more and more information for almost trivial things pretty much reminds me of bad support for commercial products. Now we'll see if this ITS will ever turn out something useful... Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs >> on the provider side, when the Syncrepl control is present. Something else is >> going on here, but since you failed to provide any config info there's no way >> to tell where the problem is. > > Ah nice language, "you failed" boils down to "you suck". If you want to read that into it, that's your problem. Of course, you've also been around the Project for pretty much its entire existence, and ought to know by now what information is needed in a useful bug report. If, knowing what you know, you still choose not to file useful bug reports, that's also your problem. > Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz > > 0. Obviously you have to edit paths... > 1. Load schulung-initial-1.ldif to one of the providers. > 2. Modiy entry ou=schulung,dc=stroeder,dc=local. > > => > > dn: ou=schulung,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > [..] > > Tried this several times... > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 16 Aug '11

16 Aug '11

Full_Name: Version: 2.4.26 OS: URL: Submission from: (NULL) (84.128.254.201) slapo-ppolicy(5) says: pwdAllowUserChange This attribute specifies whether users are allowed to change their own passwords or not. If pwdAllowUserChange is set to "TRUE", or if the attribute is not present, users will be allowed to change their own passwords. If its value is "FALSE", users will not be allowed to change their own pass- words. Given this text I'd expect that admins can still set the userPassword attribute. Such a policy is often used for system/machine accounts where the machine entity itself does not have to change the password but an admin should be allowed to do so. Unfortunately if (pwdAllowUserChange=FALSE) no password change is allowed at all. slapd returns: "Insufficient access: User alteration of password is not allowed"

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

hyc(a)symas.com wrote: > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs > on the provider side, when the Syncrepl control is present. Something else is > going on here, but since you failed to provide any config info there's no way > to tell where the problem is. Ah nice language, "you failed" boils down to "you suck". Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz 0. Obviously you have to edit paths... 1. Load schulung-initial-1.ldif to one of the providers. 2. Modiy entry ou=schulung,dc=stroeder,dc=local. => dn: ou=schulung,dc=stroeder,dc=local auditContext: cn=accesslog,dc=stroeder,dc=local auditContext: cn=accesslog,dc=stroeder,dc=local [..] Tried this several times...

1 0

ITS#7016
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

Your analysis is correct. I think prefixing "frontend" with "{-1}" fixes the problem; however, back-config should recognize "frontent" as a special type of database that needs to go in place "{-1}" and can only be instantiated once, so the fix should probably be in back-config. p.

1 0

ITS#7020
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

The ITS is meant to discuss software bugs. Usage questions must be directed to the openldap-technical mailing list. This ITS will be closed. p.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs