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
VC exop and LDAPWhoAmI?
by Ondřej Kuzník
Trying to get SASL bind support into the Load Balancer now and a bit
stuck when it comes to figuring out what the resulting authorisation
identity is (SASL or LDAP say it's backend specific) for use with the
proxyauthz control.
Passing the binds on is the simple one, we can just send an LDAPWhoAmI
after a successful result and we're set.
If the backends support the VC extended operation, we want to use that,
since that doesn't necessarily tie up a connection for each active bind.
In that case, there is no way to get the authzId out.
What is the best way to amend the VC spec?
I would think adding another optional boolean field "return authzid"
might be preferable. Setting it would have the server return a new field
in the response containing the authorisation identity (maybe letting the
server return it anyway, but that mightn't do good things to backward
compatibility).
A new control might be another option, that control could then be
attached to bind requests as well I guess to obviate the need to send
LDAPWhoAmI afterwards.
This might be of use for applications that have a similar usecase: use
VC Exop and then attach the proxyauthz control to operations performed
on each of its client's behalf.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
5 years, 4 months
The Case for Learned Index Structures
by Howard Chu
This has been making some waves today on social media:
https://www.arxiv-vanity.com/papers/1712.01208v1/
For now, it's only a novelty. Just like perfect hash functions. It assumes a
static data set being used in read-only fashion, so it's unsuitable for a
directory or database that serves ongoing modifications. It also assumes an
entire data set fits in RAM, which is generally not true for database
applications. In particular, the "fast" case of using highly parallel GPUs
assumes everything fits inside GPU RAM, which is even more tightly constrained
than server main memory.
It's axiomatic that if you have advance knowledge about the
shape/characteristics of a dataset, you can construct a dedicated mapping
function for that dataset that is perfectly optimal, and outperforms any
general-purpose mapping. That's kind of the point of general-purpose mappings
- they are general. There are plenty of use cases where this fact may be
useful. In LDAP and any database system ingesting data in realtime, these
findings are irrelevant since advance knowledge of the dataset doesn't exist.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 5 months