Re: commit: ldap/servers/slapd backend.c backglue.c backover.c bconfig.c config.h proto-slap.h slap.h
by Ralf Haferkamp
The BI_db_func()-functions (xxx_db_init, xxx_db_open, xxx_db_close and
xxx_db_destroy) now accept a ConfigArgs pointer as an additional argument. I
think I fixed all existing backends and overlays to accept the new parameter
(make test succeeded with --enable-backends=yes and --enable-overlays=yes).
Currently only back-monitor uses the new parameter for printing error messages
to the ca->msg attribute. I plan to update the other backends and overlays
next.
On Wednesday 25 July 2007 17:21, ralf(a)openldap.org wrote:
[..]
> Log Message:
> Added a new parameter (ConfigArgs*) to the _db_init, _db_open, _db_close
> and _db_destroy functions.
[..]
--
Ralf
15 years, 10 months
Certificate list validation
by Pierangelo Masarati
I'm playing with certification authorities and so, and I came across
certificate lists. Currently, the certificate list syntax
1.3.6.1.4.1.1466.115.121.1.9 is validated by sequenceValidate, which
simply checks if the value starts with a LBER_SEQUENCE tag. After
reading related RFCs and X.509 I understood that a certificate list is
always supposed to be a complete structure, respectful of X.509 7.3.
I stumbled on this problem because I have to implement an architecture
based on strongAuthenticationUser and certificationAuthority (I know
they're deprecated in favor of pkiUser and pkiCA, but this is not an
option right now, unfortunately), where the latter requires
authorityRevocationList and certificateRevocationList.
When the lists are empty, common practice allowed to use an arbitrary
dummy value, while OpenLDAP requires at least ":: MAAAAA==" (i.e.
LBER_SEQUENCE in base64) to fool sequenceValidate().
I'd like to know:
- is my understanding of X.509 correct? (certificate lists need to be
complete as per X.509 7.3, with no revokedCertificates)
- is there any other common practice to deal with empty
authorityRevocationList/certificateRevocationList?
- would a certificateListValidate() that complies with X.509 7.3 be
helpful/welcome in 2.4?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Yet another backport to suggest
by Benoit Donnette
Dear Howard,
Let me suggest yet another backport on the 2.3 branch (specifically on
2.3.37) from the Head, this time related to the entryDN attributes
indexing. Once again you are the original author of the commit that was
backported, it seems my contributions relate to backport your most awaited
features - am I a serial backporter ? :-)
I hope it will be interesting enough a feature to be included.
Yours sincerely,
Benoît Donnette - Expert TM2L/OSSA - www.08000linux.com
LINAGORA - 27 rue de Berri - 75008 PARIS
LINAGORA recrute : http://www.linagora.com/societe/nous_rejoindre/
15 years, 10 months
ITS#5040, operational attribute updates
by Howard Chu
I don't see anything in X.501/X.511 etc to imply there's any difference -
should modifyTimeStamp be left untouched when an update only changes an entry's
operational attributes, or should all modifications, regardless of how they
were initiated or what they touch, update the modifyTimeStamp?
Possible alternatives:
1) only update modifyTimeStamp in response to actual Modify (and MoDDN)
requests from a client. (thus, not for any internally generated updates.)
2) only update modifyTimeStamp if user attributes are changed.
3) always update modifyTimeStamp
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 10 months
BDB 4.6 is out
by Quanah Gibson-Mount
This release showed amazing promise in the past as the first release to
move to after 4.2 that showed real performance gains across the board.
Curious to see if the official release will hold up.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 10 months
recommend loglevel 256 (statslog)
by Hallvard B Furuseth
Bug reports with huge logs but without loglevel 256 can be amazingly
useless... I'll commit this change to slapd.conf(5):
@@ -559,3 +559,3 @@
.B (0x100 stats)
-stats log connections/operations/results
+connections, LDAP operations, results (recommended)
.TP
@@ -615,3 +616,6 @@
level is required to have high priority messages logged.
-The loglevel defaults to \fBstats\fP.
+
+The loglevel defaults to \fBstats\fP.
+This level which should usually also be included when using other
+logevels, to help analyze the logs.
.RE
--
Regards,
Hallvard
15 years, 10 months
Getting more meaningful error out of back-config
by Ralf Haferkamp
Hi,
I'd like to improve the error messages that back-config returns via LDAP to
the client. Currently in many case you only get back a very generic error
messages. E.g. when trying to add a second monitor database you just get:
Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed
init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding
an additional const char** text parameter to the _db_init functions (and
probably some other of the BI_db_func() functions as well), similiar to what
is done in many other case when error messages need to be passed to the
caller.
Does somebody have better ideas how to achieve this?
--
Ralf
15 years, 10 months
Re: Releasedate OpenLDAP 2.4
by Gavin Henry
<quote who="Dagobert Michelsen">
> Hi Gavin,
>
> Am 17.07.2007 um 12:15 schrieb Gavin Henry:
>>> The question is if there is a chance of changing the backend to
>>> OpenLDAP 2.4 after release if it is not going to make it in the
>>> initial release. The next version 3.0 (or 2.5) is probably years
>>> away.
>>
>> I couldn't comment as I'm not part of the core team, only the
>> Engineering
>> team.
>>
>> Have anyone seen your code in the project yet?
Please CC openldap-devel(a)openldap.org as well.
>
> No. I didn't want to waste anybodys time in contributing
> half-finished code. Currently I am working hard on getting
> things in a contributable quality.
>
> I am worried that the changes which may be accepted won't
> go in the next release but in the one to be released in a few years.
That's always the risk.
>
> Best regards
>
> -- Dagobert
>
> --
> Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH
> Firmensitz: Alter Markt 1-2, 24103 Kiel, Telefon: +49 431 54003-0
> Geschäftsführer: Erik Cickovskis, Amtsgericht Kiel, HRB 3756
> "Of course computer servers don't need thrust, since they generally
> don't go anywhere." -- Comment in TR on new HP server turbine fans
>
>
>
>
15 years, 10 months
