December 2016 - openldap-bugs

(ITS#8539) Fix regression suite to do all backends

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) When running the regression suite via "make its" it will only run with the first defined backend, rather than all compiled backends like the test suite does. This needs to be fixed.

6 years, 10 months

1
0
0 / 0

(ITS#8538) Update slapd.conf/slapd-config (5) to note interval is requird for syncrepl config

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapd.conf/slapd-config (5) man pages need to be updated to note that the "interval" parameter to olcSyncrepl is required.

6 years, 10 months

1
0
0 / 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d

by elecharny＠gmail.com

Actually, it's an invalid issue. The problem is all in teh sequence of updates on the provider. There are 6 possible scenario, depending on which order we inject the serverID, teh syncprov overlay and the data : 1) data, serverID, syncprov : invalid. All the data will have a wrong entryCSN 2) data, syncprov,serverID : invalid, same reason 3) serverID, syncprov, data : All work properly 4) syncprov, serverID, data : All work properly 5) serverID, data, syncprov : the corner case scenario... Syncprov has no way to know which contextCSN to generate. The only way for the server to replicate is to do an update, so that the contextCSN is properly generated. 6) syncprov, data, serverID : invalid. All the data will have a wrong entryCSN Bottom line, *always* inject the serverID and syncprov *before injecting some data, or be ready to do an update after having injected syncprov and serverID. =20 Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

6 years, 10 months

1
0
0 / 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d

by elecharny＠gmail.com

FTR, the check on slapd_serverID presence has been added in ITS#8281. Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

6 years, 10 months

1
0
0 / 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d

by elecharny＠gmail.com

The problem is that if we already have a ServerID on the producer, it will never generate a contextCSN, waiting for the consumer to send one, or for an update to occur : static int syncprov_db_open( BackendDB *be, ConfigReply *cr ) { ... /* Didn't find a contextCSN, should we generate one? */ if ( !si->si_ctxcsn ) { char csnbuf[ LDAP_PVT_CSNSTR_BUFSIZE ]; struct berval csn; if ( slap_serverID || SLAP_SYNC_SHADOW( op->o_bd )) { /* If we're also a consumer, then don't generate anything. * Wait for our provider to send it to us, or for a local * modify if we have multimaster. */ goto out; } At this point, nothing happens when teh consumer connects for teh very first time, because it is expected to send a contextCSN, which it obviously don't have. I do think that the provider should always generate a contextCSN for its own data, when the syncprov overlay is added. that should solve the problem. Now, I don't know (yet) what would be the impact on replication if we do so. Still investigating... -- Emmanuel Lecharny Symas.com directory.apache.org

6 years, 10 months

1
0
0 / 0

Re: (ITS#8536) Solaris unable to login to open ldap

by quanah＠symas.com

--On Thursday, December 01, 2016 3:04 PM +0000 sameer.shaikh(a)wipro.com wrote: > Full_Name: sameer > Version: 2.4.40 > OS: solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.64.88) Hello, The ITS system is for reporting bugs. This does not appear to be a bug report. If you require help with configuring your LDAP server and you are using OpenLDAP, then you should subscribe to the openldap-technical(a)openldap.org mailing list and post your questions there. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 10 months

1
0
0 / 0

Re: (ITS#8537) liblmdb errors with data=NULL and non-matching SET_KEY

by h.b.furuseth＠usit.uio.no

Related issue: mdb_cursor_prev/mdb_cursor_last() with data==NULL position the xcursor at 1st data item, while data!=NULL puts it at last item. That's unintuitive and should either be documented or normalized - but changing it can break existing programs. In the cases when it didn't just fail earlier, anyway: mdb_cursor_prev(), and maybe mdb_cursor_last() on a sub-DB. Haven't tested the latter. Whatever mdb_cursor_last() ends up doing, I think mdb_cursor_prev() should do the same. There is positioning code inside if(data) elsewhere too, but defaults to doing cursor_first() or something similar. Don't know if that can have any visible effect on the next operation. -- Hallvard

6 years, 10 months

1
0
0 / 0

(ITS#8537) liblmdb errors with data=NULL and non-matching SET_KEY

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard B Furuseth Version: mdb.master, fa83b25ec536ac2642f8e0d3c6bf587008513ef4 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-161201.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard liblmdb can crash or give an EINVAL in some cases after it forgets to initialize an xcursor on a sub-page: To fail the init, use next/prev with data=NULL, or SET_KEY to a non-existe k key (so it gets positioned on next key). Then try to use the cursor in another operation. Test program enclosed.

6 years, 10 months

1
0
0 / 0

(ITS#8536) Solaris unable to login to open ldap

by sameer.shaikh＠wipro.com

Full_Name: sameer Version: 2.4.40 OS: solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.64.88) i have update below schema # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif Followinthe docuemnt but below is the error still recieved Dec 1 14:58:32 hnmpvdbs01 sshd[3078]: [ID 685508 auth.info] libgss dlopen(/usr/lib/gss/mech_spnego.so.1): ld.so.1: sshd: fatal: /usr/lib/gss/mech_spnego.so.1: open failed: No such file or directory Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Illegal user sameer from 10.200.10.30 Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] input_userauth_request: illegal user sameer Dec 1 14:58:35 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Failed none for <invalid username> from 10.200.10.30 port 49362 ssh2 Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 219349 auth.debug] pam_unix_auth: user sameer not found Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Keyboard-interactive (PAM) userauth failed[13] while authenticating: No account present for user Dec 1 14:58:38 hnmpvdbs01 sshd[3078]: [ID 800047 auth.info] Failed keyboard-interactive for <invalid username> from 10.200.10.30 port 49362 ssh2

6 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2016