Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it
Marco Pizzoli wrote:
> Hi,
> the (same?) problem arises again.
>
> I downloaded the upgraded source, created a new accesslog and today tried to
> slapcat/drop/slapadd.
> This is the error that I'm encountering:
>
> [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc=
> mycorp.it" -l dump_ldap_dblog_20110201.ldif
> .### 17.14% eta 01h17m elapsed 15m56s spd 443.0
> k/s str2entry: invalid value for attributeType reqAttr #1 (syntax
> 1.3.6.1.4.1.1466.115.121.1.15)
> slapadd: could not parse entry (line=13502606)
> _### 17.14% eta 01h17m elapsed 15m56s spd 330.0
> k/s
> Closing DB...
>
> The corrupted entry is:
>
> dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it
> objectClass: auditSearch
> structuralObjectClass: auditSearch
> reqStart: 20110128141509.000004Z
> reqEnd: 20110128141510.000000Z
> reqType: search
> reqSession: 6521
> reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it
> reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it
> reqResult: 0
> reqScope: base
> reqDerefAliases: never
> reqAttrsOnly: FALSE
> reqFilter: (&(objectClass=*))
> reqAttr: *
> reqAttr:
> reqEntries: 1
> reqTimeLimit: -1
> reqSizeLimit: 500
> entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf
> creatorsName: cn=Manager,cn=log03,dc=mycorp.it
> createTimestamp: 20110128141510Z
> entryCSN: 20110128141510.000116Z#000000#003#000000
> modifiersName: cn=Manager,cn=log03,dc=mycorp.it
> modifyTimestamp: 20110128141510Z
I've found that a search for '*' does generate a log with only one
reqAttr value,
reqAttr: *
However a search for '*' '' (the empty string) actually generates a log
like the one you posted. I'll fix this, but in the meanwhile you should
fix your client.
p.
12 years, 8 months
Re: (ITS#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it
h.b.furuseth(a)usit.uio.no wrote:
> masarati(a)aero.polimi.it writes:
>> Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule
>
> Is this denormalizion a user-visible or internal matter?
AFAIK it's about generating a printable form of some normal forms, e.g.
UUIDs. It's used very seldom, but for some reasons that bit of code
assumed an EQUALITY rule was present, and I ran into that after enabling
undefined attr filters to be saved in Filter structures for logging
purposes (ava.c 1.53 -> 1.54). I don't think the user needs to be aware
of that.
p.
12 years, 8 months
Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com
--00504502c82c9d7fc8049b363033
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
the (same?) problem arises again.
I downloaded the upgraded source, created a new accesslog and today tried t=
o
slapcat/drop/slapadd.
This is the error that I'm encountering:
[ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,=
dc=3D
mycorp.it" -l dump_ldap_dblog_20110201.ldif
.### 17.14% eta 01h17m elapsed 15m56s spd 443.0
k/s str2entry: invalid value for attributeType reqAttr #1 (syntax
1.3.6.1.4.1.1466.115.121.1.15)
slapadd: could not parse entry (line=3D13502606)
_### 17.14% eta 01h17m elapsed 15m56s spd 330.0
k/s
Closing DB...
The corrupted entry is:
dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3Dmycorp.it
objectClass: auditSearch
structuralObjectClass: auditSearch
reqStart: 20110128141509.000004Z
reqEnd: 20110128141510.000000Z
reqType: search
reqSession: 6521
reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3Dmycorp.it
reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3Dmycorp.it
reqResult: 0
reqScope: base
reqDerefAliases: never
reqAttrsOnly: FALSE
reqFilter: (&(objectClass=3D*))
reqAttr: *
reqAttr:
reqEntries: 1
reqTimeLimit: -1
reqSizeLimit: 500
entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf
creatorsName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it
createTimestamp: 20110128141510Z
entryCSN: 20110128141510.000116Z#000000#003#000000
modifiersName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it
modifyTimestamp: 20110128141510Z
Thanks
Marco Pizzoli
On Sun, Jan 2, 2011 at 4:01 PM, <masarati(a)aero.polimi.it> wrote:
> > Full_Name: Marco Pizzoli
> > Version: 2.4.23
> > OS: Linux x86_64
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (193.41.84.11)
> >
> >
> > Hi,
> > I had a problem with my Accesslog database.
> > I was investigating an anomaly that I had and, in doing this, I tried t=
o:
> > - backup (slapcat) my accesslog db
> > - drop the entire db (rm -f alock, *.bdb, log.*, __db*)
> > - slapadd the db
> >
> > In slapadd I obtained this error:
> >
> > --- BEGIN
> > /usr/sbin/slapadd -b "cn=3Dlog,dc=3Dmycorp.it" -l
> > /srv/bck/dump_db_log.ldif.20100916
> > . 0.00% eta 08h35m elapsed spd
> 90.2
> > k/s
> > str2entry: invalid value for attributeType reqControls #0 (syntax
> > 1.3.6.1.4.1.4203.666.11.5.3.1)
> > slapadd2.4: could not parse entry (line=3D4907)
> > - 0.01% eta 05h58m elapsed spd
> 205.7
> > k/s
> > Closing DB...
> > --- END
> >
> > I went to that line and found this entry:
> >
> > --- BEGIN
> > dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3Dmycorp.it
> > objectClass: auditSearch
> > structuralObjectClass: auditSearch
> > reqStart: 20100913065628.000008Z
> > reqEnd: 20100913065628.000009Z
> > reqType: search
> > reqSession: 1129
> > reqAuthzID:
> > cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3Dmy=
corp.it
> > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue
> > "30440K0103043M7269643N
> >
> 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735=
355K2
> > 330303030303023303033233030303030300001PP"}
> > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE}
> > reqDN: dc=3Dmycorp.it
> > reqResult: 0
> > reqScope: base
> > reqDerefAliases: never
> > reqAttrsOnly: TRUE
> > reqFilter: (objectclass=3D*)
> > reqAttr: 1.1
> > reqEntries: 0
> > reqTimeLimit: -1
> > reqSizeLimit: 1
> > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7
> > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it
> > createTimestamp: 20100913065628Z
> > entryCSN: 20100913065628.167225Z#000000#003#000000
> > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it
> > modifyTimestamp: 20100913065628Z
> > --- END
> >
> > Having produced this ldif using slapcat and not having "touched" the
> > environment
> > in between could I assume this to be a bug?
> > The entry showed is related to an access made by another OL server of m=
y
> > deployment, which is in mirrormode(=3Dtrue).
> > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26
> >
> >
> > I deleted this entry and retried the import.
> > Now I have the following error:
> > --- BEGIN
> > /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3Dmycorp.it" -l
> > /tmp/dump_db_log.ldif.20100916_Corrected
> > " 4.69% eta 01h07m elapsed 03m19s spd
> 542.3
> > k/s
> > str2entry: invalid value for attributeType reqRespControls #0 (syntax
> > 1.3.6.1.4.1.4203.666.11.5.3.1)
> > slapadd2.4: could not parse entry (line=3D3099715)
> > * 4.70% eta 01h07m elapsed 03m20s spd
> 979.8
> > k/s
> > Closing DB...
> > --- END
> >
> > The "corrupted" entry is this one:
> >
> > --- BEGIN
> > dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3Dmycorp.it
> > objectClass: auditBind
> > structuralObjectClass: auditBind
> > reqStart: 20100913093021.000000Z
> > reqEnd: 20100913093021.000001Z
> > reqType: bind
> > reqSession: 2746
> > reqAuthzID:
> > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1}
> > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"}
> > reqDN: uid=3Dpe1597,ou=3DPeople,dc=3Dmycorp.it
> > reqResult: 0
> > reqVersion: 3
> > reqMethod: SIMPLE
> > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be
> > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it
> > createTimestamp: 20100913093021Z
> > entryCSN: 20100913093021.411398Z#000000#003#000000
> > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it
> > modifyTimestamp: 20100913093021Z
> > --- END
> >
> > Is this a software bug?
> >
> > If yes, do I need to produce other infos related to my environment?
>
> Hi, I have fixed a couple of bugs in reqControls validation. However a
> problem remains: the validator expects control values to consist in
> hexadecimal digits (0-9, a-f), while your values in some cases aren't.
> This could be related to interoperation issues between different slapd
> versions, although I couldn't go back to the point where this change in
> syntax occurred, if any.
>
> p.
>
>
--=20
_________________________________________
Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
--00504502c82c9d7fc8049b363033
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,<br>the (same?) problem arises again.<br><br>I downloaded the upgraded s=
ource, created a new accesslog and today tried to slapcat/drop/slapadd.<br>=
This is the error that I'm encountering:<br><br>[ldap@ldap03 db_log]$ t=
ime /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,dc=3D<a href=3D"ht=
tp://mycorp.it">mycorp.it</a>" -l dump_ldap_dblog_20110201.ldif<br>
.###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17=
m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 443.0 k/s str2entry: invali=
d value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15)=
<br>slapadd: could not parse entry (line=3D13502606)<br>
_###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17=
m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 330.0 k/s<br>Closing DB...<=
br><br>The corrupted entry is:<br><br>dn: reqStart=3D20110128141509.000004Z=
,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a><br>
objectClass: auditSearch<br>structuralObjectClass: auditSearch<br>reqStart:=
20110128141509.000004Z<br>reqEnd: 20110128141510.000000Z<br>reqType: searc=
h<br>reqSession: 6521<br>reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a hre=
f=3D"http://mycorp.it">mycorp.it</a><br>
reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp=
.it">mycorp.it</a><br>reqResult: 0<br>reqScope: base<br>reqDerefAliases: ne=
ver<br>reqAttrsOnly: FALSE<br>reqFilter: (&(objectClass=3D*))<br>reqAtt=
r: *<br>
reqAttr:<br>reqEntries: 1<br>reqTimeLimit: -1<br>reqSizeLimit: 500<br>entry=
UUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf<br>creatorsName: cn=3DManager,cn=
=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a><br>createTimestamp=
: 20110128141510Z<br>
entryCSN: 20110128141510.000116Z#000000#003#000000<br>modifiersName: cn=3DM=
anager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a><br>modify=
Timestamp: 20110128141510Z<br><br><br>Thanks<br>=A0=A0=A0=A0=A0=A0 Marco Pi=
zzoli<br><br><br>
<br><br><div class=3D"gmail_quote">On Sun, Jan 2, 2011 at 4:01 PM, <span d=
ir=3D"ltr"><<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.pol=
imi.it</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">
> Full_Name: Marco Pizzoli<br>
> Version: 2.4.23<br>
> OS: Linux x86_64<br>
> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft=
p://ftp.openldap.org/incoming/</a><br>
> Submission from: (NULL) (193.41.84.11)<br>
><br>
><br>
> Hi,<br>
> I had a problem with my Accesslog database.<br>
> I was investigating an anomaly that I had and, in doing this, I tried =
to:<br>
> - backup (slapcat) my accesslog db<br>
> - drop the entire db (rm -f alock, *.bdb, log.*, __db*)<br>
> - slapadd the db<br>
><br>
> In slapadd I obtained this error:<br>
><br>
> --- BEGIN<br>
> /usr/sbin/slapadd -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" =
target=3D"_blank">mycorp.it</a>" -l<br>
> /srv/bck/dump_db_log.ldif.20100916<br>
> . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.00% eta 08h35m elapsed=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd =A090.2<br>
> k/s<br>
> str2entry: invalid value for attributeType reqControls #0 (syntax<br>
> 1.3.6.1.4.1.4203.666.11.5.3.1)<br>
> slapadd2.4: could not parse entry (line=3D4907)<br>
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.01% eta 05h58m elapsed=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd 205.7<br>
> k/s<br>
> Closing DB...<br>
> --- END<br>
><br>
> I went to that line and found this entry:<br>
><br>
> --- BEGIN<br>
> dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3D<a href=3D"http://=
mycorp.it" target=3D"_blank">mycorp.it</a><br>
> objectClass: auditSearch<br>
> structuralObjectClass: auditSearch<br>
> reqStart: 20100913065628.000008Z<br>
> reqEnd: 20100913065628.000009Z<br>
> reqType: search<br>
> reqSession: 1129<br>
> reqAuthzID:<br>
> cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3D<=
a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a><br>
> reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue<br>
> "30440K0103043M7269643N<br>
> =A03030332M7369643N3030342M63736O3N32303130303931333036353130362O39323=
43735355K2<br>
> =A0330303030303023303033233030303030300001PP"}<br>
> reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE}<br>
> reqDN: dc=3D<a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</=
a><br>
> reqResult: 0<br>
> reqScope: base<br>
> reqDerefAliases: never<br>
> reqAttrsOnly: TRUE<br>
> reqFilter: (objectclass=3D*)<br>
> reqAttr: 1.1<br>
> reqEntries: 0<br>
> reqTimeLimit: -1<br>
> reqSizeLimit: 1<br>
> entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7<br>
> creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" =
target=3D"_blank">mycorp.it</a><br>
> createTimestamp: 20100913065628Z<br>
> entryCSN: 20100913065628.167225Z#000000#003#000000<br>
> modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"=
target=3D"_blank">mycorp.it</a><br>
> modifyTimestamp: 20100913065628Z<br>
> --- END<br>
><br>
> Having produced this ldif using slapcat and not having "touched&q=
uot; the<br>
> environment<br>
> in between could I assume this to be a bug?<br>
> The entry showed is related to an access made by another OL server of =
my<br>
> deployment, which is in mirrormode(=3Dtrue).<br>
> This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26<=
br>
><br>
><br>
> I deleted this entry and retried the import.<br>
> Now I have the following error:<br>
> --- BEGIN<br>
> /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.i=
t" target=3D"_blank">mycorp.it</a>" -l<br>
> /tmp/dump_db_log.ldif.20100916_Corrected<br>
> " =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.69% eta 01h07m el=
apsed =A0 =A0 =A0 =A0 =A003m19s spd 542.3<br>
> k/s<br>
> str2entry: invalid value for attributeType reqRespControls #0 (syntax<=
br>
> 1.3.6.1.4.1.4203.666.11.5.3.1)<br>
> slapadd2.4: could not parse entry (line=3D3099715)<br>
> * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.70% eta 01h07m elapsed=
=A0 =A0 =A0 =A0 =A003m20s spd 979.8<br>
> k/s<br>
> Closing DB...<br>
> --- END<br>
><br>
> The "corrupted" entry is this one:<br>
><br>
> --- BEGIN<br>
> dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3D<a href=3D"http://=
mycorp.it" target=3D"_blank">mycorp.it</a><br>
> objectClass: auditBind<br>
> structuralObjectClass: auditBind<br>
> reqStart: 20100913093021.000000Z<br>
> reqEnd: 20100913093021.000001Z<br>
> reqType: bind<br>
> reqSession: 2746<br>
> reqAuthzID:<br>
> reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1}<br>
> reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000=
"}<br>
> reqDN: uid=3Dpe1597,ou=3DPeople,dc=3D<a href=3D"http://mycorp.it" targ=
et=3D"_blank">mycorp.it</a><br>
> reqResult: 0<br>
> reqVersion: 3<br>
> reqMethod: SIMPLE<br>
> entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be<br>
> creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" =
target=3D"_blank">mycorp.it</a><br>
> createTimestamp: 20100913093021Z<br>
> entryCSN: 20100913093021.411398Z#000000#003#000000<br>
> modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"=
target=3D"_blank">mycorp.it</a><br>
> modifyTimestamp: 20100913093021Z<br>
> --- END<br>
><br>
> Is this a software bug?<br>
><br>
> If yes, do I need to produce other infos related to my environment?<br=
>
<br>
Hi, I have fixed a couple of bugs in reqControls validation. =A0However a<b=
r>
problem remains: the validator expects control values to consist in<br>
hexadecimal digits (0-9, a-f), while your values in some cases aren't.<=
br>
This could be related to interoperation issues between different slapd<br>
versions, although I couldn't go back to the point where this change in=
<br>
syntax occurred, if any.<br>
<br>
p.<br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>_______________________=
__________________<br>Non =E8 forte chi non cade, ma chi cadendo ha la forz=
a di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br>
<div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde=
x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;=
word-wrap: break-word; color: black; font-size: 10px; text-align: left; li=
ne-height: 130%;" id=3D"avg_ls_inline_popup">
</div>
--00504502c82c9d7fc8049b363033--
12 years, 8 months
Réf. : Re: (ITS#6810) slapd crashes writing to bdb backend
by Bruno_Haleblian＠carrefour.com
--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: multipart/alternative;
Boundary="1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE"
--1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: text/plain; charset=US-ASCII
Hi, Quanah,
Here are my answers plus some comments.
All is under ext3 fs
BDB log files and data files are one seperate filesystem
BDB is 4.6.21 with patch 4 (as provided by
http://ltb-project.org/wiki/download )
Running on a VSPhere4 VM - this hardware emulated :
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 01)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
bridge (rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:07.7 System peripheral: VMware Virtual Machine Communication Interface
(rev 10)
00:0f.0 VGA compatible controller: VMware SVGA II Adapter
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 01)
The 2 servers are in mirror mode. See below the diff between their conf
and here's a slapd.conf extract plus the DB_CONFIG file.
Most parameters have been provided in the early ages with the old slapd
(2.2.x).
Mirroring setup is based on admin guide
--------------
slapd.conf excerpt
--------------
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include my schemas
serverID 2
pidfile /var/ldap/server/var/run/slapd.pid
argsfile /var/ldap/server/var/run/slapd.args
loglevel 256
allow bind_v2
gentlehup off
idletimeout 3600
defaultsearchbase "dc=carrefour,dc=com"
timelimit unlimited
sizelimit unlimited
database bdb
suffix "dc=carrefour,dc=com"
rootdn "cn=*******,dc=carrefour,dc=com"
rootpw *******
directory /var/ldap/data
cachesize 500000
maxderefdepth 5
checkpoint 512 720
# Indices to maintain
index objectclass,entryCSN,entryUUID eq
index uid pres,eq,sub
index cn,sn pres,eq,sub,subany
index
memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso
eq
index businessCategory eq
index eduPersonAffiliation,employeeType eq
index mail eq
index givenName eq
index userCertificate eq
# some acces rules, granting write user replic
dn="uid=replic,dc=carrefour,dc=com"
#...
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncrepl rid=001
provider=ldap://X.X.X.X
bindmethod=simple
binddn="uid=replic,dc=carrefour,dc=com"
credentials=**********
searchbase="dc=carrefour,dc=com"
schemachecking=on
type=refreshAndPersist
retry="20 +"
mirrormode on
# pour cacti
database monitor
-------------
--------------
slapd.conf diff between mirror peers
--------------
< serverID 1
---
> serverID 2
27c27
< loglevel 0
---
> loglevel 256
132c132
< provider=ldap://X.X.X.X
---
> provider=ldap://X.X.X.Y
--------------
DB_CONFIG
--------------
#====================================================================
# BDB configuration
#
# Provided by LTB-project (http://www.ltb-project.org)
#====================================================================
set_cachesize 1 0 1
set_flags DB_LOG_AUTOREMOVE
set_lg_regionmax 1048576
set_lg_max 10485760
set_lg_bsize 2097152
set_lg_dir /var/ldap/logs
--------------
Regards
Bruno HALEBLIAN
|---------+---------------------------->
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------|
| |
| Quanah Gibson-Mount <quanah(a)zimbra.com> |
| |
|Pour : bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org |
|cc : |
|Objet : Re: (ITS#6810) slapd crashes writing to bdb backend |
| |
| 31/01/2011 22:14 |
>---------------------------------------------------------------------------------------------------------------------|
--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com
wrote:
> Full_Name: Bruno HALEBLIAN
> Version: 2.4.23
> OS: RHEL 5.5/64 bits
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (92.243.12.111)
>
>
> Hello,
> I'm stuck with "random" slapd crashes, my slapd has been tested
> successfully in read mode but since I run updates, I get several crashes
> a day, with no BDB corruption (recover and restart OK) but I can't let
> this go to production stage.
>
> Here's the first core stack I caught, I'll send more if I meet different
> ones.
>
> Thanks for your help.
Hi Bruno,
What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc.
Also, what version of BDB are you using from Oracle? Can you provide your
configuration file/cn=config directory (minus any passwords)?
Thanks,
Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.
http://disclaimer.carrefour.com/
Let's respect the environment together. Only print this message if necessary
--1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
<html><body>
<p><tt>Hi,</tt> <tt>Quanah,</tt><br>
<br>
<tt>Here are my answers plus some comments.</tt><br>
<br>
<tt>All is under ext3 fs</tt><br>
<tt>BDB log files and data files are one seperate filesystem</tt><br>
<br>
<tt>BDB is 4.6.21 with patch 4 (as provided by <a href="http://ltb-project.org/wiki/download">http://ltb-project.org/wiki/download</a> )</tt><br>
<br>
<tt>Running on a VSPhere4 VM - this hardware emulated : </tt><br>
<tt>00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)</tt><br>
<tt>00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)</tt><br>
<tt>00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)</tt><br>
<tt>00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)</tt><br>
<tt>00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)</tt><br>
<tt>00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10)</tt><br>
<tt>00:0f.0 VGA compatible controller: VMware SVGA II Adapter</tt><br>
<tt>00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)</tt><br>
<br>
<tt>The 2 servers are in mirror mode. See below the diff between their conf</tt><br>
<tt>and here's a slapd.conf extract plus the DB_CONFIG file. </tt><br>
<br>
<tt>Most parameters have been provided in the early ages with the old slapd (2.2.x).</tt><br>
<tt>Mirroring setup is based on admin guide</tt><br>
<br>
<tt>--------------</tt><br>
<tt>slapd.conf excerpt</tt><br>
<tt>--------------</tt><br>
<tt># See slapd.conf(5) for details on configuration options.</tt><br>
<tt># This file should NOT be world readable.</tt><br>
<tt>#</tt><br>
<tt>include my schemas</tt><br>
<br>
<tt>serverID 2</tt><br>
<br>
<tt>pidfile /var/ldap/server/var/run/slapd.pid</tt><br>
<tt>argsfile /var/ldap/server/var/run/slapd.args</tt><br>
<br>
<tt>loglevel 256</tt><br>
<br>
<tt>allow bind_v2</tt><br>
<br>
<tt>gentlehup off</tt><br>
<tt>idletimeout 3600</tt><br>
<tt>defaultsearchbase "dc=carrefour,dc=com"</tt><br>
<tt>timelimit unlimited</tt><br>
<tt>sizelimit unlimited</tt><br>
<br>
<tt>database bdb</tt><br>
<tt>suffix "dc=carrefour,dc=com"</tt><br>
<tt>rootdn "cn=*******,dc=carrefour,dc=com"</tt><br>
<tt>rootpw *******</tt><br>
<tt>directory /var/ldap/data</tt><br>
<br>
<tt>cachesize 500000</tt><br>
<br>
<tt>maxderefdepth 5</tt><br>
<br>
<tt>checkpoint 512 720</tt><br>
<br>
<tt># Indices to maintain</tt><br>
<tt>index objectclass,entryCSN,entryUUID eq</tt><br>
<tt>index uid pres,eq,sub</tt><br>
<tt>index cn,sn pres,eq,sub,subany</tt><br>
<tt>index memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso eq</tt><br>
<tt>index businessCategory eq</tt><br>
<tt>index eduPersonAffiliation,employeeType eq</tt><br>
<tt>index mail eq</tt><br>
<tt>index givenName eq</tt><br>
<tt>index userCertificate eq</tt><br>
<br>
<br>
<tt># some acces rules, granting write user replic dn="uid=replic,dc=carrefour,dc=com"</tt><br>
<tt>#...</tt><br>
<br>
<tt>overlay syncprov</tt><br>
<tt>syncprov-checkpoint 100 10</tt><br>
<tt>syncprov-sessionlog 100</tt><br>
<br>
<tt>syncrepl rid=001</tt><br>
<tt> provider=ldap://X.X.X.X</tt><br>
<tt> bindmethod=simple</tt><br>
<tt> binddn="uid=replic,dc=carrefour,dc=com"</tt><br>
<tt> credentials=**********</tt><br>
<tt> searchbase="dc=carrefour,dc=com"</tt><br>
<tt> schemachecking=on</tt><br>
<tt> type=refreshAndPersist</tt><br>
<tt> retry="20 +"</tt><br>
<br>
<tt>mirrormode on</tt><br>
<br>
<tt># pour cacti</tt><br>
<tt>database monitor</tt><br>
<tt>-------------</tt><br>
<br>
<tt>--------------</tt><br>
<tt>slapd.conf diff between mirror peers</tt><br>
<tt>--------------</tt><br>
<br>
<tt>< serverID 1</tt><br>
<tt>---</tt><br>
<tt>> serverID 2</tt><br>
<tt>27c27</tt><br>
<tt>< loglevel 0</tt><br>
<tt>---</tt><br>
<tt>> loglevel 256</tt><br>
<tt>132c132</tt><br>
<tt>< provider=ldap://X.X.X.X</tt><br>
<tt>---</tt><br>
<tt>> provider=ldap://X.X.X.Y</tt><br>
<br>
<br>
<tt>--------------</tt><br>
<tt>DB_CONFIG</tt><br>
<tt>--------------</tt><br>
<tt>#====================================================================</tt><br>
<tt># BDB configuration</tt><br>
<tt>#</tt><br>
<tt># Provided by LTB-project (<a href="http://www.ltb-project.org">http://www.ltb-project.org</a>)</tt><br>
<tt>#====================================================================</tt><br>
<tt>set_cachesize 1 0 1</tt><br>
<br>
<tt>set_flags DB_LOG_AUTOREMOVE</tt><br>
<br>
<tt>set_lg_regionmax 1048576</tt><br>
<tt>set_lg_max 10485760</tt><br>
<tt>set_lg_bsize 2097152</tt><br>
<br>
<tt>set_lg_dir /var/ldap/logs</tt><br>
<br>
<tt>--------------</tt><br>
<br>
<tt> </tt><br>
Regards <br>
Bruno HALEBLIAN<br>
<img width="16" height="16" src="cid:1__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt="Inactive hide details for unnamed section"><br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="72" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""><br>
</td><td style="background-image:url(cid:3__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com); background-repeat: no-repeat; " width="1%"><img width="222" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""><br>
</td><td width="100%"><img width="1" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> </font><b><font size="2">Quanah Gibson-Mount <quanah(a)zimbra.com></font></b>
<p><font size="2">Pour : </font><font size="2">bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org</font><br>
<font size="2">cc : </font><br>
<font size="2">Objet : </font><font size="2">Re: (ITS#6810) slapd crashes writing to bdb backend</font>
<p><font size="2"> </font><b><font size="2">31/01/2011 22:14</font></b></td></tr>
</table>
<br>
<br>
<tt>--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com <br>
wrote:<br>
<br>
> Full_Name: Bruno HALEBLIAN<br>
> Version: 2.4.23<br>
> OS: RHEL 5.5/64 bits<br>
> URL: </tt><tt><a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a></tt><tt><br>
> Submission from: (NULL) (92.243.12.111)<br>
><br>
><br>
> Hello,<br>
> I'm stuck with "random" slapd crashes, my slapd has been tested<br>
> successfully in read mode but since I run updates, I get several crashes<br>
> a day, with no BDB corruption (recover and restart OK) but I can't let<br>
> this go to production stage.<br>
><br>
> Here's the first core stack I caught, I'll send more if I meet different<br>
> ones.<br>
><br>
> Thanks for your help.<br>
<br>
Hi Bruno,<br>
<br>
What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc. <br>
Also, what version of BDB are you using from Oracle? Can you provide your <br>
configuration file/cn=config directory (minus any passwords)?<br>
<br>
Thanks,<br>
Quanah<br>
<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Sr. Member of Technical Staff<br>
Zimbra, Inc<br>
A Division of VMware, Inc.<br>
--------------------<br>
Zimbra :: the leader in open source messaging and collaboration<br>
</tt>
<br><br>
<div class=Section1>
<p align="justify" class=MsoNormal style='margin-top:12.0pt;line-height:12.0pt;mso-layout-grid-align:
none;text-autospace:none'><i><span style='font-size:9.0pt;font-family:Arial;
color:gray'>This e-mail and any attachment are confidential and intended solely
for the use of the individual to whom it is addressed. If you are not the
intended recipient, please telephone or email the sender and delete this message
and any attachment from your system. Unauthorized publication, use, dissemination,
forwarding, printing or copying of this e-mail and its associated attachments
is strictly prohibited.
<br>
<a href="http://disclaimer.carrefour.com"> http://disclaimer.carrefour.com </a>
<br>
Let's respect the environment together. Only print this message if necessary
<o:p></o:p></span></i></p>
</div>
</body></html>
--1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE--
--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <1__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIX
lI+py+0PopwxUbpuZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFk
IFNtYXJ0U2F2ZXIhAAA7
--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <2__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE
Content-type: image/gif;
name="pic10697.gif"
Content-Disposition: inline; filename="pic10697.gif"
Content-ID: <3__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com>
Content-transfer-encoding: base64
R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIue
zf///wAAAAAAAAAAAAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq7046827
70RiFMRinqggEUNSHIchG0BCfHhOjAuhEDeUqTASLCbBhQrhG7xis2j0lssN
DopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYRRghXcAGFhoUE
TwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09l
mgkHLZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtC
KW3jfz4uMKmq3xu4N0nKBVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQ
EEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAITihRL/4FEwbp28BXMMcoscQC
VxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFRM00oQAqN
IstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE
4zk+T6FGuQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3m
pOaKnL0Z2EKvNMSILEThKhCgzMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI
+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpbqxIKsjUPRgD7I2XYV6wy
rOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33YEWQ
YNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1
KOODHiu+4aEwNEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcs
oCWOOUwgltIwAKRxJgbIkJAQZEq02YliZnpZZ4BH3CnYOXldOUOfQoYDqF1L
FHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCcoCgrMFsROrIEX3o2w
hVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eI
xJJoUBc+3CbBuwZEV5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4se
nwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvHESfCwVt5hTgYiqQqtdRNHQIU1PJ3
3ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKTmrKIN07AnGcI
9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9
aQcw9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgL
L/r1R40BZEnuBWgmQEybjqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpb
jVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPlfmh+xl4WtR0zGu24I4KbMQm3
lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIAOw==
--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE--
12 years, 8 months
Re: (ITS#6404) tests return success on failure
by h.b.furuseth＠usit.uio.no
Reopening this ITS.
tests/scripts/test038-retcode rev 1.9 can be imported to RE24,
it's a mislabeled fix for this.
I would commit the following fix for test020-proxycache, except I'd
like to know why the test deliberately does 'exit 0' on some failures.
'exit 0' #1-4 are OK, but I do not understand the next 5 of them from:
rev 1.34 (hyc) ITS#6152 add tests for cache refresh and Bind caching
rev 1.35 (hyc) ITS#6152 test pwdModify
If nothing else, these success exits should first give a message
which clarifies that the condition which caused the exit is not a bug.
As in hunk #1 below.
Index: test020-proxycache
--- test020-proxycache 4 Jan 2011 23:43:43 -0000 1.40
+++ test020-proxycache 1 Feb 2011 09:39:19 -0000
@@ -153,5 +153,5 @@
RC=$?
if test $RC != 0 ; then
- echo "Debug messages unavailable, test aborted..."
+ echo "Debug messages unavailable, remaining test skipped"
test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait
exit 0
@@ -257,5 +257,5 @@
echo "ldapsearch should have failed!"
test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ exit 1
;;
4)
@@ -284,5 +284,5 @@
echo "ldapsearch should have failed!"
test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ exit 1
;;
4)
@@ -407,5 +407,5 @@
echo "ldapsearch should have failed!"
test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ exit 1
;;
4)
@@ -434,5 +434,5 @@
echo "ldapsearch should have failed!"
test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ exit 1
;;
4)
--
Hallvard
12 years, 8 months
Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com
hyc(a)symas.com wrote:
> Howard Chu wrote:
>> jgilmour(a)techsmog.com wrote:
>>> Full_Name: Josh Gilmour
>>> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14)
>>> OS: CentOS release 5.4 32bit
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (38.112.23.58)
>>>
>>>
>>> I get a segfault when using the following command and applying a filter file. If
>>> we remove the -f, the command runs properly. It doesn't seem to be a major
>>> security issue (or one at all, I'm not sure), but it does seem to be a bug I
>>> believe...
>>
>> OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a
>> current release please followup with the relevant stack trace, otherwise this
>> ITS will be closed. Currently I see no such symptom in 2.4.x.
>>
> Valgrind disagreed with me, the bug was still present in 2.4. Fixed in HEAD.
>
But the fix needs some more thought. I don't believe this combination of
options actually makes any sense; we should probably just disallow it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 8 months
Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com
Howard Chu wrote:
> jgilmour(a)techsmog.com wrote:
>> Full_Name: Josh Gilmour
>> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14)
>> OS: CentOS release 5.4 32bit
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (38.112.23.58)
>>
>>
>> I get a segfault when using the following command and applying a filter file. If
>> we remove the -f, the command runs properly. It doesn't seem to be a major
>> security issue (or one at all, I'm not sure), but it does seem to be a bug I
>> believe...
>
> OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a
> current release please followup with the relevant stack trace, otherwise this
> ITS will be closed. Currently I see no such symptom in 2.4.x.
>
Valgrind disagreed with me, the bug was still present in 2.4. Fixed in HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 8 months