openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#8466) remove FAQ trash entries
by hyc＠symas.com 16 Jul '16

16 Jul '16

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (213.240.180.113) > > > It seems some people are abusing FAQ-O-MATIC. :-( > > I tried to remove these entries but I probably don't have enough access rights: You probably do, but you need to actually authenticate before you can do such edits. > > http://www.openldap.org/faq/data/cache/1548.html > > http://www.openldap.org/faq/data/cache/1552.html I've trashed these two and the other as well. > > How about banning their e-mail addresses completely? I don't see how that would help since people can just use garbage email addresses. -- -- 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#8466) remove FAQ trash entries
by michael＠stroeder.com 16 Jul '16

16 Jul '16

more junk: http://www.openldap.org/faq/data/cache/1517.html

1 0

(ITS#8466) remove FAQ trash entries
by michael＠stroeder.com 16 Jul '16

16 Jul '16

Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.180.113) It seems some people are abusing FAQ-O-MATIC. :-( I tried to remove these entries but I probably don't have enough access rights: http://www.openldap.org/faq/data/cache/1548.html http://www.openldap.org/faq/data/cache/1552.html How about banning their e-mail addresses completely?

1 0

(ITS#8465) ldapsearch & slapcat : different output
by norbert.massa＠yopmail.com 15 Jul '16

15 Jul '16

Full_Name: Norbert MASSA Version: 2.4.40 OS: CentOS 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.240.254.57) Hi everyone, I'm struggling to find a root cause on a weird problem which recently happened on one of our servers, let me give you some history : - server installed beginning of April - openldap 2.4.40 installed via packages - client data loaded into ldap, no problem - server had never been rebooted since We have a script that (luckily, see why below) makes a backup every night, with 2 different commands : - slapcat > file-slapcat.ldif - ldapsearch -b "dc=our_root" -x -D "cn=admin,dc=our_root" -w password > file-ldapsearch.ldif So far so good, the application behind was running fine, users were added and authentication was successful. That's for the background. Now, 3 days ago during night, there was a planned reboot of the server, and after it came back, it appeared our LDAP server was missing lots and lots of entries that should have been here since months. Even some passwords were "back to their values weeks ago". Weird. So let's have a look at the backups, that's where the fun stuff begins : it appeared that the ldapsearch backups were always complete whereas the slapcat ones never where ! It looked like slapcat was not seeing any other data than what was added at the beginning. The final solution was to perform a restore / import of the ldapsearch generated file. So from a system perspective, it would appear the behavior was something like : - new data was storred in "some kind of memory" - slapcat, as it's reading the files on the drive, would not see it :-( -dadapsearch, as it's using ldap protocol, would see it :-) - after the reboot => everything was lost, slapcat & ldapsearch were seeing the same (incomplete) data. Is it something possible ? I was unable to find anything related on google, and sadly have no idea how to reproduce Thanks a lot, Regards, Norbert

1 0

Re: (ITS#8464) Documentation for enabling monitoring via cn=config
by michael＠stroeder.com 14 Jul '16

14 Jul '16

ryan(a)openldap.org wrote: > Module loading is a generic task, IMO it doesn't make sense to talk > about in the context of an individual module. This is true. But there should be a hint that the monitor database must be the last database backend (order!). Otherwise it does not see all other backends. Ciao, Michael.

1 0

Re: (ITS#8464) Documentation for enabling monitoring via cn=config
by ryan＠openldap.org 14 Jul '16

14 Jul '16

On Fri, Jul 15, 2016 at 12:06:22AM +0000, dave(a)pandora.com wrote: >I've attached a patch whichrovivides some minimal instructions to enable >monitoring via cn=config Thanks for the patch! I commented on these points in IRC, duplicating here for the record: Module loading is a generic task, IMO it doesn't make sense to talk about in the context of an individual module. Covering how to load each module would get repetitive really quickly. Also, while the LDIF you wrote makes sense, the way of authenticating to the config database is local to each site (the -H ldapi:// -Y EXTERNAL in your example is to some extent a Debian-ism), so this is another thing that I don't really think should be covered when talking about a specific module.

1 0

(ITS#8464) Documentation for enabling monitoring via cn=config
by dave＠pandora.com 14 Jul '16

14 Jul '16

Full_Name: Dave Rawks Version: 2.4 OS: debian linux URL: https://gist.githubusercontent.com/drawks/dd3fa73604bf0d6ac454e515ff2a33f9/… Submission from: (NULL) (2620:106:e00f:f167::13) http://www.openldap.org/doc/admin24/monitoringslapd.html section 20.1 "Monitor configuration via cn=config(5)" of the documentation simply reads "This section has yet to be written" Seeing as how cn=config is the primary/default configuration method in all current major distributions of openldap and the only method referenced in the main slapd quickstart guide it feels a major oversight to not provide proper documentation on how to enable monitoring via this method. I've attached a patch whichrovivides some minimal instructions to enable monitoring via cn=config

1 0

Re: (ITS#8458) syncrepl ppolicy with LDIF backend fails
by jesse＠braintreepayments.com 13 Jul '16

13 Jul '16

We are also experiencing this issue with 2.4.40 when we try to create a replica from the primary. our current workaround is to exclude the pwdPolicy objectclass: olcSyncrepl: {0}rid=000 provider=ldap://127.0.0.1:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=chi,dc=braintreepayments,dc=com" attrs="*,+" filter="(!(objectClass=pwdPolicy))" bindmethod=simple binddn="cn=admin,dc=chi,dc=braintreepayments,dc=com" credentials=openldaptest schemachecking=off

1 0

Re: (ITS#8463) Steps to upgarde 2.4 to 2.44
by ryan＠openldap.org 11 Jul '16

11 Jul '16

Hello, On Mon, Jul 11, 2016 at 11:58:04AM +0000, lokesh.gowdaml(a)hubzu.com wrote: >I am new to this, i need to upgrade the openldap 2.4 tp 2.4.44 can you please >send me the steps to do the same. The ITS is for reporting bugs only. For support, please write to the openldap-technical mailing list.

1 0

(ITS#8463) Steps to upgarde 2.4 to 2.44
by lokesh.gowdaml＠hubzu.com 11 Jul '16

11 Jul '16

Full_Name: Lokesh Gowda Version: 2.4 OS: Lunix URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.141.91.41) I am new to this, i need to upgrade the openldap 2.4 tp 2.4.44 can you please send me the steps to do the same.

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