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/
3 months
RE25 make depend
by Michael Ströder
HI!
With RE25 branch make depend fails on my system (see below).
Find attached my build script which works just fine for RE24. Any
changes needed for RE25?
Ciao, Michael.
cd back-shell && make -w depend
make[3]: Entering directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell'
make[3]: *** No rule to make target 'Makefile.in', needed by 'Makefile'.
Stop.
make[3]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell'
make[2]: *** [Makefile:589: depend-local-srv] Error 1
make[2]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers/slapd'
make[1]: *** [Makefile:328: depend-common] Error 1
make[1]: Leaving directory
'/home/michael/src/openldap-git/re25/openldap/servers'
make: *** [Makefile:349: depend-common] Error 1
1 year, 2 months
ppolicy control exposure in RE24?
by Quanah Gibson-Mount
Currently the ppolicy overlay does not expose the related control in the
supportedControl attribute of the rootDSE. This is due to the general
policy that controls for items that are not part of a finalized
specification are not published.
However, at this point, ppolicy while not finalized, is long established.
For 2.5, we will be exposing the control, but I think it could be useful to
do this for 2.4.51+ as well.
Does anyone have any objections to this change being backported to RE24?
<https://bugs.openldap.org/show_bug.cgi?id=9285>
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1 year, 3 months
