openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#8605) spelling
by quanah＠symas.com 23 Apr '17

23 Apr '17

Hi Josh, Thanks very much! In the future, please remember to CC openldap-its(a)openldap.org, or there will not be a record in the ITS of the submission. ;) --Quanah --On Sunday, April 23, 2017 8:37 PM -0400 Josh Soref <jsoref(a)gmail.com> wrote: > I've uploaded it again: >> ftp ftp.openldap.org > Connected to www.openldap.org. > 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] > 200 UTF8 set to on > User (www.openldap.org:(none)): ftp > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > ftp> cd incoming > 250 CWD command successful > ftp> dir > 200 PORT command successful > 150 Opening ASCII mode data connection for file list > 226 Transfer complete > ftp> ascii > 200 Type set to A > ftp> put > Local file 0001-spelling-fixes.patch > Remote file josh-soref-170423.patch > 200 PORT command successful > 150 Opening ASCII mode data connection for josh-soref-170423.patch > 226 Transfer complete > ftp: 133503 bytes sent in 1.13Seconds 117.73Kbytes/sec. > ftp> quit > 221 Goodbye -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8205)
by quanah＠symas.com 23 Apr '17

23 Apr '17

--On Sunday, October 25, 2015 10:28 AM +0000 hyc(a)symas.com wrote: > peter(a)adpm.de wrote: >> Hi, >> >> I extended the patch series with a manual page for pbkdf2 >> * >> https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f64 >> 9ca22aeb5ae4 contrib/passwd/pbkdf2: add man page, install it too > > Please use format-patch to submit patches, thanks. If you add .patch to the end of the URL, you can trivially get patches already formatted for use with git. A rather useful trick. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8605) spelling
by quanah＠symas.com 23 Apr '17

23 Apr '17

Hi Josh, Still waiting on a git format patch, as per the contribution guidelines: <http://www.openldap.org/devel/contributing.html#formats> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 21 Apr '17

21 Apr '17

--On Friday, April 21, 2017 2:26 AM +0100 Howard Chu <hyc(a)symas.com> wrote: >> It's fine for there to be legacy entryCSNs and a contextCSN for serverID >> of 0. However, it is not fine for any master in an MMR setup to have a >> specific serverID of 0. If you're running with serverID's 0-3, I'd >> simply try an ldapmodify on the server with 0 to set its serverID to 4, >> and then do a modification against it, so it generates a new contextCSN >> that gets pushed out to all nodes. > > Performance-wise, it would be better to delete the SID 0 contextCSN value > too. Yeah, definitely not optimal, but less of a worry at the moment. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by hyc＠symas.com 21 Apr '17

21 Apr '17

quanah(a)symas.com wrote: > --On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: > >>> From: Quanah Gibson-Mount >>> Sent: Thursday, April 20, 2017 8:07 AM >>> >>> You stated previously that you are in 4-way MMR. It's not valid to have >>> a serverID of 0 in an MMR environment (See >>> <http://www.openldap.org/its/index.cgi/?findid=8635>). >> >> Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people >> have serverID's of 0 in their replicated environments, as I don't know >> that I've ever seen that information before. What are the ramifications >> of having a server with an ID of 0 in a replicated environment? What is >> the procedure for remediating the issue? Is it as simple as shutting down >> that server, updating the configuration to have a serverID of 4 and >> restarting it? Or does the database need to be stripped of all CSN's >> which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w >> option on the master and then reloading from ldif on all the replicas? > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. Performance-wise, it would be better to delete the SID 0 contextCSN value too. -- -- 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#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, April 20, 2017 8:07 AM >> >> You stated previously that you are in 4-way MMR. It's not valid to have >> a serverID of 0 in an MMR environment (See >> <http://www.openldap.org/its/index.cgi/?findid=8635>). > > Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people > have serverID's of 0 in their replicated environments, as I don't know > that I've ever seen that information before. What are the ramifications > of having a server with an ID of 0 in a replicated environment? What is > the procedure for remediating the issue? Is it as simple as shutting down > that server, updating the configuration to have a serverID of 4 and > restarting it? Or does the database need to be stripped of all CSN's > which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w > option on the master and then reloading from ldif on all the replicas? It's fine for there to be legacy entryCSNs and a contextCSN for serverID of 0. However, it is not fine for any master in an MMR setup to have a specific serverID of 0. If you're running with serverID's 0-3, I'd simply try an ldapmodify on the server with 0 to set its serverID to 4, and then do a modification against it, so it generates a new contextCSN that gets pushed out to all nodes. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 8:07 AM > > You stated previously that you are in 4-way MMR. It's not valid to have a > serverID of 0 in an MMR environment (See > <http://www.openldap.org/its/index.cgi/?findid=8635>). Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people have serverID's of 0 in their replicated environments, as I don't know that I've ever seen that information before. What are the ramifications of having a server with an ID of 0 in a replicated environment? What is the procedure for remediating the issue? Is it as simple as shutting down that server, updating the configuration to have a serverID of 4 and restarting it? Or does the database need to be stripped of all CSN's which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w option on the master and then reloading from ldif on all the replicas?

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM > > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hmm, no, I don't see them in any of the three other accesslogs either. > Would you be able to try the patch I provided earlier on one of your > servers? This one? ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170327-ITS8609-ignore-inv= alid-accesslog-ops.patch Sure, I can drop this in on the master server that has been crashing and = see what happens. Thanks=E2=80=A6

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:34 AM +0000 okuznik(a)symas.com wrote: > On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: >> On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= > : >>> could you post the two accesslog entries (or at least an outline) >>> referenced in the backtrace? >> =20 >> That's weird. I can't find these exact entries. Based on the username, = > I >> found ones that are very close to the timestamp, but ones that match >> these exact timestamps do not exist. Last time Quanah asked me to look >> up the matching accesslog entry from the crash I believe I was able to >> find it. > > Hi Paul, > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hi Paul, You stated previously that you are in 4-way MMR. It's not valid to have a serverID of 0 in an MMR environment (See <http://www.openldap.org/its/index.cgi/?findid=8635>). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 20 Apr '17

20 Apr '17

On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: > On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= : >> could you post the two accesslog entries (or at least an outline) >> referenced in the backtrace? >=20 > That's weird. I can't find these exact entries. Based on the username, = I > found ones that are very close to the timestamp, but ones that match > these exact timestamps do not exist. Last time Quanah asked me to look > up the matching accesslog entry from the crash I believe I was able to > find it. Hi Paul, those come from master with ServerID 0? Maybe you can find them in another server's accesslog? >> - reqStart=3D20170415103641.000016Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170415103641.000068Z,cn=3Daccesslog > reqDN: uid=3Dbrandonl,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170415103641.599920Z#000000#000#000000 > entryCSN: 20170415103641.599920Z#000000#000#000000 >=20 >> - reqStart=3D20170416103057.000005Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170416103057.000045Z,cn=3Daccesslog > reqDN: uid=3Daaalmora,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170416103057.530384Z#000000#000#000000 > entryCSN: 20170416103057.530384Z#000000#000#000000 >=20 >> I assume you are still running the same code in production, correct? >=20 > Yes. It actually crashed 4 days in a row :(, the two days I provided > backtraces for and then the following two days. Just for something to d= o > I slapcat'd the db and accesslog and reloaded it after the fourth day i= n > case there was some weird mdb corruption or something. It hasn't crashe= d > since, but it crashes randomly so that could be meaningless <sigh>. I > wouldn't think reloaded the db would have affected finding the matching > accesslog entries but that is something different than last time too. > And of course now this is the non-optimized build. Would you be able to try the patch I provided earlier on one of your servers? Thanks, --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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