openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

--On Wednesday, December 03, 2008 9:54 PM +0100 Thomas Koeller <thomas(a)koeller.dyndns.org> wrote: > Am Mittwoch, 3. Dezember 2008 21:22:11 schrieb Quanah Gibson-Mount: >> Did you apply the patch from Oracle? And did you apply the patch in the >> build/ directory shipped with OpenLDAP? Both are necessary. It'd be >> nice if Oracle would add the second patch to their website, since it's >> needed, and it came from them. > > No, I missed that. I found the patch shipped with OpenLDAP, but what do > you mean by '_the_ patch from Oracle'? I revisited their website but could > not spot any patches there. <http://www.oracle.com/technology/software/products/berkeley-db/db/index.html> Berkeley DB Release History Latest Production Release 4.7.25 Requires log file format upgrade. change log - patches (1) Click on the "1", it's a link to the patch: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 21:22:11 schrieb Quanah Gibson-Mount: > Did you apply the patch from Oracle? And did you apply the patch in the > build/ directory shipped with OpenLDAP? Both are necessary. It'd be nice > if Oracle would add the second patch to their website, since it's needed, > and it came from them. No, I missed that. I found the patch shipped with OpenLDAP, but what do you mean by '_the_ patch from Oracle'? I revisited their website but could not spot any patches there. thanks, tk

1 0

(ITS#5848) INDEXES IN BACK-NDB
by evaristojosec＠yahoo.es 03 Dec '08

03 Dec '08

Full_Name: Evaristo Camarero Version: 2.4.13 OS: SuSe 10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.32.53.80) The issue is related with indexes support in the back-ndb that uses MySQL Cluster NDB backend. The problem happens when you define more than one index in the slapd.conf, and you try a search operation using a filter that does not contain the first define index. This my config in slapd.conf for the back-ndb ######################################################## # NDB ######################################################### database ndb suffix dc=example,dc=com rootdn cn=Manager,dc=example,dc=com rootpw secret dbname OpenLDAP dbuser root dbpass whatever # MySQL Server dbhost localhost # NDB management host dbconnect localhost # Number of API connections in the NDB cluster dbconnections 5 dbsocket /tmp/mysql.sock index cn index sn I have loaded the following LDIF file in the server: # root dn: dc=example,dc=com objectClass: organization objectClass: dcObject o: Example, Inc. dc: example # people dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People # company-wide address book dn: ou=Address Book,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in company-wide address book dn: cn=Rosco P. Coltrane,ou=Address Book,dc=example,dc=com objectClass: inetOrgPerson cn: Rosco P. Coltrane sn: Coltrane mail: rpc(a)example.com # address book administrator dn: cn=Admin,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Admin sn: Admin userPassword: admin # person dn: cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Flash Gordon sn: Gordon mail: fg(a)example.com userPassword: secret # person's personal address book dn: ou=Address Book,cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # another person dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Clark Kent sn: Kent mail: ck(a)example.com userPassword: secret # another person's personal address book dn: ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in another person's personal address book dn: cn=Mickey Mouse,ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Mickey Mouse sn: Mouse mail: mickey.mouse(a)example.com # one more person, yet without personal address book dn: cn=Donald Duck,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Donald Duck sn: Duck mail: dd(a)example.com userPassword: secret Using the first defined index (cn), works fine: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'cn=Clark Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: cn=Clark Kent # requesting: ALL # # Clark Kent, People, example.com dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson userPassword:: c2VjcmV0 sn: Kent cn: Clark Kent mail: ck(a)example.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But using the second defined index, does not work: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'sn=Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: sn=Kent # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Tell me if you need more details. Thanks in advance

1 0

(ITS#5847) INDEXES IN BACK-NDB
by evaristojosec＠yahoo.es 03 Dec '08

03 Dec '08

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

--On Wednesday, December 03, 2008 9:15 PM +0100 Thomas Koeller <thomas(a)koeller.dyndns.org> wrote: > Am Mittwoch, 3. Dezember 2008 02:39:58 schrieb Quanah Gibson-Mount: >> What version of BDB? > > db-4.7.25 Did you apply the patch from Oracle? And did you apply the patch in the build/ directory shipped with OpenLDAP? Both are necessary. It'd be nice if Oracle would add the second patch to their website, since it's needed, and it came from them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 02:39:58 schrieb Quanah Gibson-Mount: > What version of BDB? db-4.7.25 I ran 'make test' under strace, here's what I got. Seems to be some kind of deadlock. [pid 14035] pwrite(6, "\261\244\0\0O\20\0\0003\237E\251\221\0\0\0\10\0\0\200\1"..., 8453, 42224) = 8453 [pid 14035] fdatasync(6) = 0 [pid 14035] rename("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/__db.80000007.336a56f4", "/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb") = 0 [pid 14035] stat("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb", {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0 [pid 14035] open("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb", O_RDWR|O_CREAT, 0) = 10 [pid 14035] fcntl(10, F_GETFD) = 0 [pid 14035] fcntl(10, F_SETFD, FD_CLOEXEC) = 0 [pid 14035] fstat(10, {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0 [pid 14035] pread(10, "\0\0\0\0\1\0\0\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 4096, 0) = 4096 [pid 14035] pwrite(6, "\216\305\0\0(\0\0\0\311\30\225\0\f\0\0\0\7\0\0\200\0\0"..., 176, 50677) = 176 [pid 14035] fdatasync(6) = 0 [pid 14035] pread(10, "\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\1\5\0"..., 4096, 4096) = 4096 [pid 14035] pwrite(6, "y\306\0\0D\0\0\0\0028\257o)\0\0\0\6\0\0\200\1\0\0\0i\244"..., 1682, 50853) = 1682 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] pwrite(6, "\v\315\0\0]\0\0\0F\205\277r)\0\0\0\t\0\0\200\0\0\0\0\0"..., 1633, 52535) = 1633 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] pwrite(6, "l\323\0\0]\0\0\0\222\264S5)\0\0\0\n\0\0\200\0\0\0\0\0\0"..., 1404, 54168) = 1404 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] sched_yield() = 0 [pid 14035] futex(0x2aaf71fe7924, FUTEX_WAIT, 1, NULL *** hangs *** tk

1 0

Re: (ITS#5839) overlay glue
by rein＠OpenLDAP.org 03 Dec '08

03 Dec '08

LEHOUELLEUR, Marin wrote: > Can you confirm your sentence is it "for the same consumer" or "from the same provider" that syncrepl may not behave properly ? Both, i.e not "or" but "and".. Each consumer can only have one syncrepl instance below a common glue database that replicates from the same provider. Multiple providers is OK as long as they all have different serverID (although this might require 2.4). Each provider can replicate to an unlimited number of clients. If you configure syncrepl on both the glue database and a subordinate then syncrepl on the glue db will, when it start up, try to wipe out everything in the subordinate db (unless the content in the subordinate db is also replicated to syncrepl in the glue db, in which case the subordinate syncrepl is useless). If you have two subordinate databases on a consumer that replicates from the same provider, then syncrepl on one of them can (when slapd start) pick up a newer sync cookie saved by the other without actually being in sync with the provider. I.e it would miss some modifications. > I'm about to deliver so if I have no misfunction with 2.3 when I test it, i may go with it. I would definitely reconsider, unless you have an extremely good test scenario you are unlike to have tested all the pitfalls.. There can be som nasty race situations involved here. > But I'm worried about the syncrepl bugs your talking about. Does two replica may support to feed about thirty (30) consumers as the DB is very little ?? The number of servers is no problem, it is the number of syncrepl instances on the same consumer that can cause problems as outlined above. > Master replicates to two replica the full database. 30 Consumers plugged to the replicas with each a different login (SASL authentication). No problem as long as you don't have more than one syncrepl instance on each server. This ITS should probably be closed and further questions directed to the openldap-software list. Rein

1 0

Re: (ITS#5839) overlay glue
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

Your message is unreadable. --Quanah --On Wednesday, December 03, 2008 3:15 PM +0000 Marin.LEHOUELLEUR(a)astrium.eads.net wrote: > This is a multi-part message in MIME format. > > > ------_=_NextPart_001_01C95559.E58ECC4C > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I=20have=20no=20other=20impact=20than=20not=20having=20the=20glued=20bran= > ch=20visible=20in > LDAPBrowser=20: > Search=20queries=20on=20the=20glued=20branch=20works=20perfectly. > I'm=20wondering=20about=20the=20proper=20use=20of=20overlay=20glue=20as= > =20error=20message > appears=20in=20slapd=20log=20(directive=20glue-sub=20ignored). > > Solution=20offered=20by=20Rein=20is=20good=20looking=20but=20I'll=20have= > =20to=20deal=20with=2030 > ACLs=20on=20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20con= > sumers=20!! > > I'll=20do=20that=20if=20any=20bug=20shows=20its=20face.=20Still=20better= > =20than=20migrating=20the > servers=20(gloups,=20oh=20no=20I=20don't=20want=20that). > > Thank=20you=20for=20helping. > > M > > Marin=20Le=20Houelleur > Projet=20Pharos=20-=20Capgemini > marin.lehouelleur(a)astrium.eads.net > 05=2062=2019=2068=2059 > > > Ce=20courriel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut= > =20contenir=20des=20informations=20confidentielles=20et/ou=20protegees=20= > ou=20dont=20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu= > =20ce=20courriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,= > =20ni=20l'utiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.= > =20Merci=20d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer= > =20ce=20courriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20re= > sponsabilite=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration= > =20ou=20de=20falsification=20de=20ce=20courriel=20lors=20de=20sa=20transm= > ission=20par=20voie=20electronique. > This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= > tial=20and/or=20privileged=20information=20or=20information=20otherwise= > =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= > =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= > =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= > =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= > person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= > =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= > f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= > =20falsified.=20 > --------------------------------------------------------------------- > Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= > =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France > > ------_=_NextPart_001_01C95559.E58ECC4C > Content-Type: text/html; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE=20HTML=20PUBLIC=20"-//W3C//DTD=20HTML=203.2//EN"> > <HTML> > <HEAD> > <META=20HTTP-EQUIV=3D"Content-Type"=20CONTENT=3D"text/html;=20charset=3Du= > s-ascii"> > <META=20NAME=3D"Generator"=20CONTENT=3D"MS=20Exchange=20Server=20version= > =206.5.7653.2"> > <TITLE>Re:=20(ITS#5839)=20overlay=20glue</TITLE> > </HEAD> > <BODY> >  > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I=20have=20no=20other=20impact=20tha= > n=20not=20having=20the=20glued=20branch=20visible=20in=20LDAPBrowser=20:<= > /FONT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Search=20queries=20on=20the=20glued= > =20branch=20works=20perfectly. > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I'm=20wondering=20about=20the=20pro= > per=20use=20of=20overlay=20glue=20as=20error=20message=20appears=20in=20s= > lapd=20log=20(directive=20glue-sub=20ignored). > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Solution=20offered=20by=20Rein=20is= > =20good=20looking=20but=20I'll=20have=20to=20deal=20with=2030=20ACLs=20on= > =20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20consumers=20= > !! > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I'll=20do=20that=20if=20any=20bug=20= > shows=20its=20face.=20Still=20better=20than=20migrating=20the=20servers= > =20(gloups,=20oh=20no=20I=20don't=20want=20that). > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Thank=20you=20for=20helping. > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">M > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Marin=20Le=20Houelleur > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Projet=20Pharos=20-=20Capgemini</FO= > NT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">marin.lehouelleur(a)astrium.eads.net<= > /FONT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">05=2062=2019=2068=2059 > > > </BODY> > </HTML> > <table><tr><td=20bgcolor=3D#ffffff><font=20color=3D#000000><pre>Ce=20cour= > riel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut=20conteni= > r=20des=20informations=20confidentielles=20et/ou=20protegees=20ou=20dont= > =20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu=20ce=20co= > urriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,=20ni=20l'u= > tiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.=20Merci=20= > d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer=20ce=20cou= > rriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20responsabilit= > e=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration=20ou=20de=20= > falsification=20de=20ce=20courriel=20lors=20de=20sa=20transmission=20par= > =20voie=20electronique. > This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= > tial=20and/or=20privileged=20information=20or=20information=20otherwise= > =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= > =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= > =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= > =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= > person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= > =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= > f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= > =20falsified.=20 > --------------------------------------------------------------------- > Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= > =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France</pre></td></t= > r></table> > > ------_=_NextPart_001_01C95559.E58ECC4C-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5846) Support Solaris 10U6 GSS library
by andjo＠ida.liu.se 03 Dec '08

03 Dec '08

Full_Name: Andreas Johansson Version: 2.4.13 OS: Solaris 10 URL: http://www.ida.liu.se/~andjo/tmp/openldap-solaris-gssapi.patch Submission from: (NULL) (2001:6b0:17:f020:203:baff:fe7b:3cfa) The OpenLDAP configure script does not detect the GSSAPI library in Solaris 10 (at least the one in update 6). The library is named gss instead of gssapi or gssapi_krb5. Referenced is a small patch for configure.in to search for gss_wrap in libgss as well.

1 0

Re: (ITS#5839) overlay glue
by Marin.LEHOUELLEUR＠astrium.eads.net 03 Dec '08

03 Dec '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I=20have=20no=20other=20impact=20than=20not=20having=20the=20glued=20bran= ch=20visible=20in LDAPBrowser=20: Search=20queries=20on=20the=20glued=20branch=20works=20perfectly. I'm=20wondering=20about=20the=20proper=20use=20of=20overlay=20glue=20as= =20error=20message appears=20in=20slapd=20log=20(directive=20glue-sub=20ignored). Solution=20offered=20by=20Rein=20is=20good=20looking=20but=20I'll=20have= =20to=20deal=20with=2030 ACLs=20on=20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20con= sumers=20!! I'll=20do=20that=20if=20any=20bug=20shows=20its=20face.=20Still=20better= =20than=20migrating=20the servers=20(gloups,=20oh=20no=20I=20don't=20want=20that). Thank=20you=20for=20helping. M Marin=20Le=20Houelleur Projet=20Pharos=20-=20Capgemini marin.lehouelleur(a)astrium.eads.net 05=2062=2019=2068=2059 Ce=20courriel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut= =20contenir=20des=20informations=20confidentielles=20et/ou=20protegees=20= ou=20dont=20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu= =20ce=20courriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,= =20ni=20l'utiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.= =20Merci=20d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer= =20ce=20courriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20re= sponsabilite=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration= =20ou=20de=20falsification=20de=20ce=20courriel=20lors=20de=20sa=20transm= ission=20par=20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE=20HTML=20PUBLIC=20"-//W3C//DTD=20HTML=203.2//EN"> <HTML> <HEAD> <META=20HTTP-EQUIV=3D"Content-Type"=20CONTENT=3D"text/html;=20charset=3Du= s-ascii"> <META=20NAME=3D"Generator"=20CONTENT=3D"MS=20Exchange=20Server=20version= =206.5.7653.2"> <TITLE>Re:=20(ITS#5839)=20overlay=20glue</TITLE> </HEAD> <BODY>  <FONT=20SIZE=3D2=20FACE=3D"Arial">I=20have=20no=20other=20impact=20tha= n=20not=20having=20the=20glued=20branch=20visible=20in=20LDAPBrowser=20:<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">Search=20queries=20on=20the=20glued= =20branch=20works=20perfectly. <FONT=20SIZE=3D2=20FACE=3D"Arial">I'm=20wondering=20about=20the=20pro= per=20use=20of=20overlay=20glue=20as=20error=20message=20appears=20in=20s= lapd=20log=20(directive=20glue-sub=20ignored). <FONT=20SIZE=3D2=20FACE=3D"Arial">Solution=20offered=20by=20Rein=20is= =20good=20looking=20but=20I'll=20have=20to=20deal=20with=2030=20ACLs=20on= =20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20consumers=20= !! <FONT=20SIZE=3D2=20FACE=3D"Arial">I'll=20do=20that=20if=20any=20bug=20= shows=20its=20face.=20Still=20better=20than=20migrating=20the=20servers= =20(gloups,=20oh=20no=20I=20don't=20want=20that). <FONT=20SIZE=3D2=20FACE=3D"Arial">Thank=20you=20for=20helping. <FONT=20SIZE=3D2=20FACE=3D"Arial">M <FONT=20SIZE=3D2=20FACE=3D"Arial">Marin=20Le=20Houelleur <FONT=20SIZE=3D2=20FACE=3D"Arial">Projet=20Pharos=20-=20Capgemini</FO= NT> <FONT=20SIZE=3D2=20FACE=3D"Arial">marin.lehouelleur(a)astrium.eads.net<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">05=2062=2019=2068=2059 </BODY> </HTML> <table><tr><td=20bgcolor=3D#ffffff><font=20color=3D#000000><pre>Ce=20cour= riel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut=20conteni= r=20des=20informations=20confidentielles=20et/ou=20protegees=20ou=20dont= =20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu=20ce=20co= urriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,=20ni=20l'u= tiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.=20Merci=20= d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer=20ce=20cou= rriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20responsabilit= e=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration=20ou=20de=20= falsification=20de=20ce=20courriel=20lors=20de=20sa=20transmission=20par= =20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France</pre></td></t= r></table> ------_=_NextPart_001_01C95559.E58ECC4C--

1 0

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2008