openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

hyc(a)symas.com writes: >quanah(a)zimbra.com wrote: >> --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> >>> hyc(a)symas.com writes: >>>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >>> >>> There are several fopen(filename, "w") calls, which truncate the file. >>> Maybe the error confuses slapd so it takes a detour into one of them. > > Irrelevant. In Windows the OS prevents you from writing to an executable file > that is currently running. I.e., it is impossible for this to be the cause. Aha. OK. I don't know Windows, so I was reacting to what you said, not to what you didn't say:-) > Try it yourself: Can't without Windows. > (...) > If you still believe it's happening inside slapd the obvious thing to do to > track this is to run slapd under gdb and set a few breakpoints. E.g., one at > the end of the config parser, and one at slapd's call to exit(). At each > breakpoint, check the filesize of the slapd.exe. Something like that was what I had in mind, yes. I might try anyway. -- Hallvard

1 0

(ITS#6930) Socket leak in ldap_connect_to_path(too long path)
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_connect_to_path() verifies its parameters after instead of before socket(), and does not close the socket on failure. Also the cleanup code can be simplified. Found by Klocwork, issue#117.

1 0

(ITS#6929) lutil_get_filed_password() filed descriptor leak
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard lutil_get_filed_password() does not always close the file on error. Found with Klocwork: Issue #203. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 05 May '11

05 May '11

quanah(a)zimbra.com wrote: > --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> hyc(a)symas.com writes: >>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >> >> There are several fopen(filename, "w") calls, which truncate the file. >> Maybe the error confuses slapd so it takes a detour into one of them. Irrelevant. In Windows the OS prevents you from writing to an executable file that is currently running. I.e., it is impossible for this to be the cause. Try it yourself: #include <stdio.h> main(int argc, char *argv[]) { FILE *f=fopen(argv[0], "w"); if (f) printf("opened!\n"); else printf("failed!\n"); } >> Quanah, can you provide a full slapd.conf and command line which causes >> this? Not that I have a Windows box to test it on, but still... > > The command line was just slapd.exe -d -1 -f slapd.conf > > The slapd.conf itself is fairly small. The line that wrapped was the > include for inetOrgPerson. Everything obviously stopped when it hit the > wrapped include. > > ucdata-path "/opt/zimbra/openldap/ucdata" > include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" > include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" > include > "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" Yes, but since "everything obviously stopped" there's nothing in slapd that fopen's any files from that point. First of all this problem cannot be specific to the include statement, since the input validation will reject the line before ever going anywhere the code for include handling. So, you ought to be able to reproduce this issue using any config statement that requires a single argument. Second, slapd stops all parsing and simply exits when it hits a config error. And this is early enough in the config file that nothing else has been initialized yet, so the teardown processing has very little to do. If you still believe it's happening inside slapd the obvious thing to do to track this is to run slapd under gdb and set a few breakpoints. E.g., one at the end of the config parser, and one at slapd's call to exit(). At each breakpoint, check the filesize of the slapd.exe. -- -- 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#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

The root cause in this case is that the schema differs on the consumer and schema violation errors were logged at the consumer. Obviously this is a configuration error but the provider should not crash because of this!

1 0

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

1 0

Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com 04 May '11

04 May '11

ryans(a)aweber.com wrote: > Full_Name: Ryan Steele > Version: 2.4.23 > OS: Ubuntu Server 10.04 (Lucid) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle > Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet > attribute, populating it with a value that does not take DST into account. As > an example, consider the following attributes from one of the entries in my > directory: > > pwdChangedTime: 20110502160329Z > sambaPwdLastSet: 1304352209 > > Obviously, pwdChangedTime specifies the timestamp: > > Mon May 2 16:03:29 EDT 2011 > > On the other hand, sambaPwdLastSet specifies the timestamp as being an hour > later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 > sec'): > > Mon May 2 17:03:29 EDT 2011 > > Right now we're in DST on the east coast, which is GMT -0400. This would mean > that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly > calculating results using GMT -0500. The sambaPwdLastSet value is not calculated at all, it is exactly what the OS system clock returns, and the OS system clock is in UTC so DST is irrelevant. Probably your machine's timezone is misconfigured; notice that pwdChangedTime is also in UTC so 20110502160329Z cannot be "May 2 16:03:29 EDT". Closing this ITS. -- -- 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#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com 04 May '11

04 May '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server 10.04 (Lucid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet attribute, populating it with a value that does not take DST into account. As an example, consider the following attributes from one of the entries in my directory: pwdChangedTime: 20110502160329Z sambaPwdLastSet: 1304352209 Obviously, pwdChangedTime specifies the timestamp: Mon May 2 16:03:29 EDT 2011 On the other hand, sambaPwdLastSet specifies the timestamp as being an hour later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 sec'): Mon May 2 17:03:29 EDT 2011 Right now we're in DST on the east coast, which is GMT -0400. This would mean that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly calculating results using GMT -0500.

1 0

(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de 04 May '11

04 May '11

Full_Name: Sascha Kuehndel Version: 2.4.25 OS: HP-UX 11.31 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.166.104.102) Hi, i tested the delta-sync in a multi-master (2 master) architecture. In a split-brain szenario the sync produced an undefinded state. Some times the data wasn't synchronized (both master hold there data unchanged), sometimes the data was fliped (master1 take data from master2, and master2 from master1). A defined and synchronized state must reached after the end of the split-brain. Senario: 1. master1 and master2 runs in sync 2. shutdown of master2 3. data change on master1 4. shutdown of master1 5. start of master2 6. data change on master2 (the same attribute on the same object, other value) > now the masters are out of sync in the same field 7. restart of master1 8. the sync process is running 9. take a look on the change field.. there are different regards Sascha Kuehndel PS - Nice to have: The posibility to define the action in thouch an situation - master1 or master2... wins - the newest win - or no change and the posibility to write a log-entry about it (with the exact dn,the attribute and the values before the synchronization)

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