openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8644) test064-constraint should wait for slapd to start
by ryan＠openldap.org 24 Apr '17

24 Apr '17

Full_Name: Ryan Tandy Version: 2.4.44 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan test064-constraint can occasionally fail if ldapadd runs while slapd is still starting up. https://bugs.debian.org/770890 has links to examples. >>>>> Starting test064-constraint for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Adding basic structure... ldapadd failed (255)! >>>>> test064-constraint failed for hdb (exit 255) Other scripts have an ldapsearch loop that waits for slapd to start, and the same should suffice here.

1 0

Re: (ITS#8592) Double free in sssvlv.c
by kevinanties＠gmail.com 23 Apr '17

23 Apr '17

--f403043eddf896760a054de0b265 Content-Type: text/plain; charset=UTF-8 Why this bug is still not fixed? This is a critical bug for those who enable this overlay. On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, February 21, 2017 4:20 AM +0000 kevinanties(a)gmail.com wrote: > > --f403045e3462d25e8f054902b3a3 >> Content-Type: text/plain; charset=UTF-8 >> >> I have submitted to ftp/incoming. The filename is >> kevin-170221-sssvlv.patch. >> > > Please carefully read the contribution web page. Your submission is > clearly missing the IPR notice: > > <http://www.openldap.org/devel/contributing.html#notice> > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --f403043eddf896760a054de0b265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Why this bug is still not fixed? This is a critical bug fo= r those who enable this overlay.<br></div><div class=3D"gmail_extra"><br><d= iv class=3D"gmail_quote">On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@symas.com" target=3D"_bl= ank">quanah(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">--On Tuesday, February 21, 2017 4:20 AM +0000 <a href=3D"mailto:kevinant= ies(a)gmail.com" target=3D"_blank">kevinanties(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --f403045e3462d25e8f054902b3a3<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> I have submitted to ftp/incoming. The filename is<br> kevin-170221-sssvlv.patch.<br> </span></blockquote> <br> Please carefully read the contribution web page.=C2=A0 Your submission is c= learly missing the IPR notice:<br> <br> <<a href=3D"http://www.openldap.org/devel/contributing.html#notice" rel= =3D"noreferrer" target=3D"_blank">http://www.openldap.org/devel<wbr>/contri= buting.html#notice</a>><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> Regards,<br> Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> <br> </div></div></blockquote></div><br></div> --f403043eddf896760a054de0b265--

1 0

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 20 Apr '17

20 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

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