openldap-devel August 2016

openldap-devel@openldap.org

2 participants
5 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

Fwd: LMDB and text encoding
by Timur Kristóf 07 Jun '17

07 Jun '17

> I just had a look at how BDB handled this. As you can see they used a > TO_TSTRING macro to convert incoming pathnames from UTF8 to UTF16. > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > (And a FROM_TSTRING for the reverse, as well.) (Mea culpa, I accidentally hit "reply" instead of "reply all". Sorry. Now reposting to the mailing list.) Since we only need to do this on Windows, we could use MultiByteToWideChar with CP_UTF8. (That's what TO_TSTRING does, too.) I do not think we would ever need to do any such conversion on UNIX. https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85… I'm not sure if we can just copy-paste BDB's code. Probably not, that would lead to licensing issues, wouldn't it?

4 16

Re: back-llog
by Howard Chu 09 Aug '16

09 Aug '16

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> Was just thinking we could do a quite simple backend for use with the accesslog >>>> overlay and delta-syncrepl. It would write into flat files and do typical >>>> logfile rotation on its own. The backing store would have a minimum of two files >>>> - one for the suffix entry, one for the current chunk of logs. There would be a >>>> configurable number of logfiles, with the oldest simply being deleted when it's >>>> time to purge. >>> >>> Two things I'd consider helpful for long-time archiving/auditing: >>> >>> 1. filenames to allow of "merging" different log flat files into one big file >>> store on a different slapd instance. >> >> Not sure what you mean by this. As sequential logs you could just cat them if >> you want to combine files into one, what does the filename have to do with it? > > Sorry for unclear wording. > I'd like to move archived files of all MMR replicas into another single > filesystem directory and let a special auditing slapd with back-llog search in > them without having to muck with file names. Then you would have to merge them entry-by-entry to preserve chronological order. >> If we just use datestamps for filenames YYYYMMDD it should be no problem for you >> to cat them in proper order. > > There could be conflicting timestamps from different MMR replicas. Maybe > appending the serverID could be a solution? Just keep them all in their own separate filesystem directories. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: back-llog
by Howard Chu 09 Aug '16

09 Aug '16

Michael Ströder wrote: > Howard Chu wrote: >> Was just thinking we could do a quite simple backend for use with the accesslog >> overlay and delta-syncrepl. It would write into flat files and do typical >> logfile rotation on its own. The backing store would have a minimum of two files >> - one for the suffix entry, one for the current chunk of logs. There would be a >> configurable number of logfiles, with the oldest simply being deleted when it's >> time to purge. > > Two things I'd consider helpful for long-time archiving/auditing: > > 1. filenames to allow of "merging" different log flat files into one big file > store on a different slapd instance. Not sure what you mean by this. As sequential logs you could just cat them if you want to combine files into one, what does the filename have to do with it? If we just use datestamps for filenames YYYYMMDD it should be no problem for you to cat them in proper order. > 2. instead of deleting moving files to an archive directory. Sounds fine as an option. > I know it's a different use-case but quite handy. > > Ciao, Michael. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

back-llog
by Howard Chu 09 Aug '16

09 Aug '16

Was just thinking we could do a quite simple backend for use with the accesslog overlay and delta-syncrepl. It would write into flat files and do typical logfile rotation on its own. The backing store would have a minimum of two files - one for the suffix entry, one for the current chunk of logs. There would be a configurable number of logfiles, with the oldest simply being deleted when it's time to purge. It would only support Add/Search in general, and Modify on the suffix entry. A rolling append-only format like this would allow much higher throughput for accesslog recording. Using a binary entry format would of course also help. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel August 2016