[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-software
Subject:    big value in attribute
From:       "Mangoentinojo, S (Sebastiaan)" <S.Mangoentinojo () rf ! rabobank ! nl>
Date:       2005-01-31 7:17:53
Message-ID: 3FB10963EBBA4F4197FE9378E23707E02BB756 () enipeus ! rabobank ! corp
[Download RAW message or body]

Hi,

We are running a Redhat linux based OpenLdap (Berkeley db) server for storing digital \
certificates for our PKI. It also stores the PKI's CRL (certificate revocation list) \
in an attribute. The problem is that the CRL is growing several kilobytes bigger \
every month . Currently it's about 2 Megabytes. Last week we had a network problem \
which caused clients to request the CRL from the OpenLdap server (it functions as a \
backup mechanisme, first clients try to receive the CRL from a webserver, if that \
fails they try LDAP). The LDAP server couldn't handle this load and dropped LDAP \
requests. Obviously I need to investigate the specifics behind the problem, like \
memory, bandwith etc in more detail, but I was wondering if anyone has any experience \
with serving up files of this size from OpenLdap and if he/she could advise if it \
should be done or not.

Cheers,

Seb

================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.


[Attachment #3 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6603.0">
<TITLE>big value in attribute</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Courier New">Hi,</FONT>
</P>

<P><FONT SIZE=2 FACE="Courier New">We are running a Redhat linux based OpenLdap \
(Berkeley db) server for storing digital certificates for our PKI. It also stores the \
PKI's CRL (certificate revocation list) in an attribute. The problem is that the CRL \
is growing several kilobytes bigger every month . Currently it's about 2 Megabytes. \
Last week we had a network problem which caused clients to request the CRL from the \
OpenLdap server (it functions as a backup mechanisme, first clients try to receive \
the CRL from a webserver, if that fails they try LDAP). The LDAP server couldn't \
handle this load and dropped LDAP requests. Obviously I need to investigate the \
specifics behind the problem, like memory, bandwith etc in more detail, but I was \
wondering if anyone has any experience with serving up files of this size from \
OpenLdap and if he/she could advise if it should be done or not.</FONT></P>

<P><FONT SIZE=2 FACE="Courier New">Cheers,</FONT>
</P>

<P><FONT SIZE=2 FACE="Courier New">Seb</FONT>
</P>

</BODY>
</HTML>
<P>================================================<br>
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en <br>
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht <br>
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en <br>
de afzender direct te informeren door het bericht te retourneren. <br>
================================================<br>
The information contained in this message may be confidential <br>
and is intended to be exclusively for the addressee. Should you <br>
receive this message unintentionally, please do not use the contents <br>
herein and notify the sender immediately by return e-mail.<br>
</P>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic