asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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.
7 months, 3 weeks
OpenLDAP: syslog message not readability
by Karatas Ozgur
Hello all,
How are you? We have installed to OpenLDAP server a few days ago and referred server logs to logserver.
But couldn't not read to OpenLDAP log on the logserver.
Logserver record all log to database and send e-mailing.
Example:
Oct 21 10:54:23 ldapserver slapd[1595]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 21 2016 10:49:33) $#012#011mueddib@ldapserver:/home/mueddib/openldap-2.4.44/servers/slapd
Oct 21 10:54:23 ldapserver slapd[1596]: mdb_monitor_db_open: monitoring disabled; configure monitor database to enable
Oct 21 10:54:23 ldapserver slapd[1596]: slapd starting
For example unnecessary rows: "@(#)" " $#012#011"
I fixed it but I couldn't commit to git :)
# git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: build/mkvers.bat
modified: build/mkversion
# git push origin master
fatal: remote error: access denied or repository not exported: /openldap.git
# git push origin origin
fatal: remote error: access denied or repository not exported: /openldap.git
I don't know why don't have access to OpenLDAP Git Server (I would like your help).
Please can you fix the below code?
File: /build/mkvers.bat
from:
(echo "@(#) $" OPENLDAP_PACKAGE ": %3 " OPENLDAP_VERSION) >> %2
(echo " (" __DATE__ " " __TIME__ ") $\n") >> %2
(echo "\t%USERNAME%@%COMPUTERNAME% %CD:\=/%\n";) >> %2
to (please):
(echo OPENLDAP_PACKAGE ": %3 " OPENLDAP_VERSION) >> %2
(echo " (" __DATE__ " " __TIME__ ") \n") >> %2
(echo "%USERNAME%@%COMPUTERNAME% %CD:\=/%\n";) >> %2
File: /build/mkversion
from:
$static $const char $SYMBOL[] =
"@(#) \$$PACKAGE: $APPLICATION $VERSION (" __DATE__ " " __TIME__ ") \$\n"
"\t$WHOWHERE\n";
to (please):
$static $const char $SYMBOL[] =
"$PACKAGE: $APPLICATION $VERSION (" __DATE__ " " __TIME__ ") \n"
"$WHOWHERE\n";
This style a very primitive coding method, I know, sorry.
I'm waiting for help on how to Git.
Regards,
--
Ozgur Karatas
E: mueddib(a)openldap.org
T: https://twitter.com/openldaporg
F: http://facebook.com/openldap
D: https://hub.docker.com/r/openldap/
G: https://github.com/openldap/
5 years, 8 months
ITS8511 feedback
by Quanah Gibson-Mount
I've prepared a patch for ITS8511, that deprecates
mirrormode/olcMirrorMode. I'd like to include it as part of the 2.5
release.
What it does is rename the configuration parameter to be "multimaster" or
olcMultiMaster. This changes makes the configuration reflect what is
actually being done when this mode is enabled (set to TRUE). Mirrormode
itself is a concept completely external to the openldap configuration
(i.e., it's based off of some sort of load balancing configuration), and
the current usage of the term mirrormode is misleading and leads to
significant confusion. While we can update the docs in various ways, I
believe the configuration term should accurately reflect what's is
occurring when it is enabled. The current method simply leads to
unnecessary confusion and is misleading.
One potential issue is that it does change the cn=config schema. However,
we've done this before when deprecating keywords. pcache.c is an example
of where this has been done in the past.
I've validated that my change is 100% backwards compatible, so that
existing configurations continue to work.
Thoughts welcome.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 8 months
