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.
1 year, 7 months
New logging system ideas
by Howard Chu
Just some initial thoughts on what a new logging daemon should do for us:
The primary goal - we want to use a binary message format with as few format conversions as possible between log
sender and log processor.
I'm thinking that we use message catalogs; we will need a tool to preprocess every logging
invocation in the source tree and replace them with a integer messageID. So at runtime only
the messageID and the message parameters need to be sent, not any plaintext.
The message catalog will be compiled into the binary. When it performs its "openlog" to talk
to the logging server, it will send the UUID of its catalog. If the logging server doesn't
know this UUID, it will transmit the message catalog to the logging server, before doing
anything else. (It may make more sense just to use a SHA hash here instead of a UUID.)
This way the logging server will work with any version of the binaries, and we don't need
to do special coordination to update message catalogs between revisions. The logging server
will just know that a specific catalog is to be used with a particular logging session.
The message protocol will be length-prefixed. We may even just use DER, since that would
allow us to encode arrays of parameters, and other such stuff.
The logging server will write the log messages to disk/network verbatim, doing no
parsing at all. It may prefix the records with a log session ID, so that a postprocessor
can lookup the catalog that belongs to the session, for dumping out as text.
The logging server can store its received catalogs in an LMDB database. The postprocessor
can then lookup individual messageIDs in this database, interpolate the parameters, and
dump out in text.
... that's what I have so far. It's a bit worrisome because of the additional moving parts:
message catalog creator, log server, log postprocessor. There's definitely more complexity
here, but most of it is moved out of the runtime hot path, which is the main goal. Suggestions?
--
-- 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 year, 10 months
Moving OpenLDAP 2.5 towards release
by Quanah Gibson-Mount
There's been great and steady progress on getting closer to an official 2.5
release. At this time, I feel that 2.5 is ready for its first alpha.
While there are some hard blockers to an official release that still need
to be finished, there is plenty of items that are in the 2.5 tree that it
would be good to get additional testing on now.
One thing that differentiates 2.5 from the time when 2.4 was released is
that a substantial portion of the new code has already been being used in
the Symas OpenLDAP Gold series which means it has already had extensive
testing and production deployment.
For those interested in helping getting 2.5 an official release timeframe,
the following things would be helpful:
*) I've been using Bugzilla's Target milestone to indicate items I'd like
to see addressed for 2.5. This does not necessarily mean they will be
fixed for 2.5. Many of the items are several years old, and simply need a
confirmation as to whether they are still issues or were already fixed. It
also may make more sense to push some of these items out to 2.6. I've done
that for a number of issues already, so what remains are the ones where I
felt I was not able to make that call. Anything I've added the keyword
OL_2_5_REQUIRED to is something I think must be done for 2.5, but that's
subject to review.
A list of issues currently marked as 2.5 (mostly minus doc bugs) can be
seen here:
<https://bugs.openldap.org/buglist.cgi?component=backends&component=build&...>
*) There are about 40 explicit documentation bugs, as found here:
<https://bugs.openldap.org/buglist.cgi?component=documentation&list_id=837...>
It would be great if community members who are familiar with the product
could help chip in here, particularly with flushing out the Admin guide.
For the man pages, we do have one item that really needs a policy decision
that I can't make (ITS#7335), which is how we handle documenting options
for slapd.conf vs cn=config. Right now, we are completely inconsistent in
this and many relevant man pages are entirely missing anything about how to
configure via cn=config. Once that policy is decided, it will unblock a
lot of other work.
*) Testing -- We need a lot of this. It would be especially helpful if
people who have QA/Test/Pre-prod environments were to run 2.5 through known
work loads. To this end, Symas is planning on providing pre-compiled
binaries for a number of platforms once there is an official alpha release.
I still have a bit of work to do on that end, however, so it would not
necessarily coincide with the source release. This may be something the
LTB project could also participate in as a way to help testing of the 2.5
series.
To the above, it may be useful to go over the list of items that are new
and changed with 2.5:
<https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERI...>
One area where it would be especially helpful for testing for the *BSD
folks out there is the support added for kqueue. I'm hoping the FreeBSD
project and similar will be able to participate in this.
Another area would be OpenSSL 3.0 testing, since it is nearing completion.
It would be helpful if people could build and test the 2.5 branch against
their current beta and see if they hit any new/odd issues and open issues
on that accordingly if encountered.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2 years, 7 months
