openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 03 Dec '08

03 Dec '08

--0-334172624-1228364660=:46006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Andrew for the reply.=0A=0A=0AQMail schema didn't seem to work for a= distribution list. I am looking for other options as well.=0A=0AI agree th= at this is a mail system issue. I am using Exim/Dovecot for mails. I though= t it was the LDAP which gets the group mail id from the address book for th= e Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick.=0A= =0AWith Regards=0ABejoy=0A=0A=0A=0A________________________________=0AFrom:= Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>=0ATo: bejnet(a)yahoo.com=0A= Cc: openldap-its(a)openldap.org=0ASent: Wednesday, 3 December, 2008 2:02:05 P= M=0ASubject: Re: (ITS#5845) Distribution List support for OpenLDAP schema= =0A=0AOn Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote:=0A= =0A> I want to create distribution list in OpenLDAP. Meaning - If I have a = group=0A> called admins(a)ldap.com and there are two members - bejoy(a)ldap.com= and=0A> bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com =3D both thes= e members must=0A> get the email. Exchange has this feature. This mail id s= hould have a display=0A> name feature as well - that would show up on searc= h of address books.=0A> =0A> At present the work around is using qmail's sc= hema for this distribution list. I=0A> believe inetOrgPerson schema could h= ave a group version too - which would need a=0A> compulsory attribute calle= d members which must have atleast one member mentioned=0A> under it.=0A=0AI= think you have just described groupOfNames. I do not like groupOfNames=0A*= because* it makes the member attribute mandatory, which makes management=0A= complicated.=0A=0AAnyway, I cannot see this as a defect in OpenLDAP. LDAP s= chema is=0Aextensible: if you want something that is not in the standard se= t=0Ayou can add it locally. You say that you have used qmail's schema:=0Ais= there anything wrong with that?=0A=0AMost LDAP-capable mail systems can be= persuaded to use groups as=0Amailing lists, but that is a mail system issu= e not an OpenLDAP one.=0AIt could be argued that simple groups are not rich= enough to use=0Afor list expansion (no way to keep track of per-member lis= t=0Apreferences etc) but if we are going to talk about defining an=0Aimprov= ed group this is the wrong place to do it: maybe IETF's=0Aldapext list woul= d be better.=0A=0AAndrew=0A-- =0A------------------------------------------= -----------------------------=0A| From Andrew Findlay, Skil= ls 1st Ltd |=0A| Consultant in large-scale systems, network= s, and directory services |=0A| http://www.skills-1st.co.uk/ = +44 1628 782565 |=0A-----------------------------------------------= ------------------------=0A=0A=0A=0A From Chandigarh to Chennai - find= friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups= / --0-334172624-1228364660=:46006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon= t-size:12pt"><div>Thanks Andrew for the reply. </div><div style=3D"font-= family: times new roman,new york,times,serif; font-size: 12pt;"> QMail s= chema didn't seem to work for a distribution list. I am looking for other o= ptions as well. I agree that this is a mail system issue. I am using= Exim/Dovecot for mails. I thought it was the LDAP which gets the group mai= l id from the address book for the Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick. = With Regards Bejoy <div style=3D"font-family: arial,helvetica= ,sans-serif; font-size: 13px;"><hr size=3D"1">From: Andrew F= indlay <andrew.findlay(a)skills-1st.co.uk> To: bejnet(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, 3 December, 2008 2:02:05 PM<b= r>Subject: Re: (ITS#5845) = Distribution List support for OpenLDAP schema On Wed, Dec 03,= 2008 at 05:02:52AM +0000, <a ymailto=3D"mailto:bejnet@yahoo.com" href=3D"m= ailto:bejnet@yahoo.com">bejnet(a)yahoo.com</a> wrote: > I want to c= reate distribution list in OpenLDAP. Meaning - If I have a group > ca= lled <a ymailto=3D"mailto:admins@ldap.com" href=3D"mailto:admins@ldap.com">= admins(a)ldap.com</a> and there are two members - <a ymailto=3D"mailto:bejoy@= ldap.com" href=3D"mailto:bejoy@ldap.com">bejoy(a)ldap.com</a> and > <a ymailto=3D"mailto:bejnet@ldap.com" href=3D"mailto:bejnet@ldap.com">bejnet@= ldap.com</a>; and mail is sent to <a ymailto=3D"mailto:admins@ldap.com" hre= f=3D"mailto:admins@ldap.com">admins(a)ldap.com</a> =3D both these members mus= t > get the email. Exchange has this feature. This mail id should hav= e a display > name feature as well - that would show up on search of = address books. > > At present the work around is using qmail's= schema for this distribution list. I > believe inetOrgPerson schema = could have a group version too - which would need a > compulsory attr= ibute called members which must have atleast one member mentioned > u= nder it. I think you have just described groupOfNames. I do not like= groupOfNames *because* it makes the member attribute mandatory, which m= akes management complicated. Anyway, I cannot see this as a defec= t in OpenLDAP. LDAP schema is extensible: if you want something that is = not in the standard set you can add it locally. You say that you have used = qmail's schema: is there anything wrong with that? Most LDAP-capa= ble mail systems can be persuaded to use groups as mailing lists, but th= at is a mail system issue not an OpenLDAP one. It could be argued that s= imple groups are not rich enough to use for list expansion (no way to ke= ep track of per-member list preferences etc) but if we are going to talk= about defining an improved group this is the wrong place to do it: mayb= e IETF's ldapext list would be better. Andrew -- ---------= -------------------------------------------------------------- |  &= nbsp;             From Andrew Findlay, Skill= s 1st Ltd                | | Co= nsultant in large-scale systems, networks, and directory services | |&nb= sp;   <a href=3D"http://www.skills-1st.co.uk/" target=3D"_blank">http://www.skills-1st.co.uk/</a>      &nb= sp;         +44 1628 782565    | --------= --------------------------------------------------------------- </div></= div></div> =0A <hr size=3D1></hr> Add more friends to your = messenger and enjoy! <a href=3D"http://in.rd.yahoo.com/tagline_messenger_6/= *http://messenger.yahoo.com/invite/"> Invite them now.</a></body></html> --0-334172624-1228364660=:46006--

1 0

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

03 Dec '08

Am Mittwoch, 3. Dezember 2008 22:14:20 schrieb Quanah Gibson-Mount: > <http://www.oracle.com/technology/software/products/berkeley-db/db/index.ht >ml> > > 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…> > After applying the patches, everything seems to be working working now. Thank you very much for your assistance! tk

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs