Re: (ITS#8048) back-sock/slapo-sock issue
by hyc＠symas.com
michael(a)stroeder.com wrote:
> michael(a)stroeder.com wrote:
>> Null-bytes really needed?
>
> Hmm, with null-bytes the wrong result code is returned to the LDAP client.
>
> Without null-bytes the correct result code is returned to the client but slapd
> complains about unknown string:
>
> 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n'
>
> results in log message:
>
> 559174df str2result (msgid: 1
> code: 0
>
> ) unknown
> 559174df str2result (
> ) unknown
I would almost suspect you were running on Windows. None of the behavior
you're reporting occurs for me using the searchexample.pl script. Sounds like
your problem is a python runtime configuration, not a slapd bug.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 5 months
Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com
michael(a)stroeder.com wrote:
> Null-bytes really needed?
Hmm, with null-bytes the wrong result code is returned to the LDAP client.
Without null-bytes the correct result code is returned to the client but slapd
complains about unknown string:
'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n'
results in log message:
559174df str2result (msgid: 1
code: 0
) unknown
559174df str2result (
) unknown
8 years, 5 months
Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com
Michael Str=F6der wrote:
> This is my Python response string:
>=20
> 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n'
Hmmpf! After adding null-bytes in each line like this
'RESULT\n\x00msgid: 1\n\x00code: 49\n\x00\n\x00'
at least this message went away also with RE24:
> This leads to slapd debug output:
>=20
> 55914b01 str2result (msgid: 1
> code: 49
> info: remote NOK
>=20
> ) unknown
> 55914b01 str2result (
> ) unknown
Null-bytes really needed? str2result() checks for null-bytes in a bunch o=
f
cases. I really wonder why null-terminated char *s is used.
Ciao, Michael.
8 years, 5 months
Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com
hyc(a)openldap.org wrote:
> Full_Name: Howard Chu
> Version: 2.4
> OS:=20
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (110.49.207.42)
> Submitted by: hyc
>=20
> The result parser is checking for CONTINUE in the wrong place.
Please re-open this ticket. RE24 (tagged as 2.4.41) made things worse.
Is there a chance to get things fixed? I promise to help testing.
First CONTINUE\n works in RE24 better than in 2.4.40 which was the cause =
of
this ITS.
But handling RESULT is seriously broken, even more than in 2.4.40.
Example:
This is my Python response string:
'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n'
This leads to slapd debug output:
55914b01 str2result (msgid: 1
code: 49
info: remote NOK
) unknown
55914b01 str2result (
) unknown
Note that the whole string is returned as being unknown.
Also with 2.4.40 my client script receives ' remote NOK' as diagnostic
message. With RE24 the diagnostic message is complete garbage.
So I tried many response string variants regarding number of \n and leavi=
ng
away space after the colon etc. But not really working.
Sometimes slapd hangs, sometimes my client hangs e.g. when sending two
subsequent bind requests in one open LDAP connection.
8 years, 5 months
(ITS#8180) back-sock should not return sucess in case of error
by michael＠stroeder.com
Full_Name:
Version: HEAD
OS:
URL:
Submission from: (NULL) (84.181.173.53)
back-sock should definitely never return success(0) to the client in case the
external listener returned non-parseable message:
Example trace log:
55913915 => str2entry: "FOOBAR
msgid: 1
code: 49
"
55913915 <= str2entry NULL (parse_line)
55913915 str2entry: entry -1 has no dn
55913915 str2entry(FOOBAR) failed
55913915 sock: fgets failed: Success (0)
8 years, 5 months
(ITS#8179) LMDB: Feature Request: mdb_env_check_mapsize(env)
by scott＠GameRanger.com
Full_Name: Scott Kevill
Version: LMDB 0.9.14
OS: CentOS 5-7
URL: ftp://ftp.openldap.org/incoming/scott-kevill-150628.patch
Submission from: (NULL) (60.224.160.178)
mdb_txn_begin / mdb_txn_renew will return MDB_MAP_RESIZED for the current
process if another process has changed the mapsize AND the data has grown past
the current process mapsize. However, by that point, in a multithreaded
environment it may be difficult to wind back to a "safe" point of no active txns
in order to call mdb_env_set_mapsize(env, 0) to update the mapsize.
Requesting:
int mdb_env_check_mapsize(MDB_env *env);
to return either MDB_SUCCESS or MDB_MAP_RESIZED. This should be lightweight
enough to call frequently enough to decide whether to initiate a "safe" point to
enable calling mdb_env_set_mapsize(env, 0). Return MDB_SUCCESS if the MDB has
not been opened yet.
Scenario:
- Process W is a writer
- Process R is a reader with multiple reader threads (read-only)
- Both processes are running and using a 2GB mapsize MDB
- Data is currently 1GB
- Ops decide W should increase mapsize to 3GB allowing for more expansion
- W calls mdb_env_set_mapsize(env, 3GB)
- R's mapsize remains at 2GB%0 D Data grows
- R:1 thread begins a moderately long read-only txn
- Data grows past 2GB
- R:2 thread tries to begin a read-only txn, but fails with MDB_MAP_RESIZED
- R:2 thread cannot call mdb_env_set_mapsize(env, 0), because of R:1's txn
- A major control flow issue exists now, as R:2 may be deep into work, but can't
continue nor back out
With mdb_env_check_mapsize(), R could periodically test it and if needed,
initiate a "safe" point where none of R's threads have active txns. This could
be done long before the data size actually reaches R's original mapsize (ie.
when data is ~1GB rather >2GB).
- Enforcing synchronisation to a "safe" point might be relatively expensive, so
it would be important to know if the mapsize has changed first. ie. Making
mdb_env_set_mapsize(env, 0) lightweight for the unchanged mapsize case isn't
enough
I've attached a sample patch against master (scott-kevill-150628.patch). I've
tested it against 0.9.14. The code is trivial and is based on the behaviour of
mdb_env_set_mapsize(env, 0). I didn't use git for the patch, so not too
difficult to get working. Less than 10 new lines, but for the record, I release
it to public domain. Feel free to massage it as needed.
8 years, 5 months
Re: (ITS#7791) 3-Way delta MMR segfault
by quanah＠zimbra.com
--On Saturday, June 27, 2015 8:01 AM +0000 frederic.nass(a)univ-lorraine.fr
wrote:
> ------=_Part_4076294_1166621201.1435388481648
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> Hi,=20
>
> We are facing the exact same situation with a 3-way configuration with
> open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20
>
> Slapd crashes at some point during first replication. We can reproduce
> this= on any of the 3 nodes by stopping ldap service, deleting databases
> (access= log and mdb) and restarting ldap service.=20
>
> Please tell us how we can be helpful.=20
Provide a gdb backtrace. <http://www.openldap.org/faq/data/cache/59.html>
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 5 months
(ITS#7791) 3-Way delta MMR segfault
by frederic.nass＠univ-lorraine.fr
------=_Part_4076294_1166621201.1435388481648
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,=20
We are facing the exact same situation with a 3-way configuration with open=
ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20
Slapd crashes at some point during first replication. We can reproduce this=
on any of the 3 nodes by stopping ldap service, deleting databases (access=
log and mdb) and restarting ldap service.=20
Please tell us how we can be helpful.=20
Fr=C3=A9d=C3=A9ric Nass=20
Sous-direction Infrastructures=20
Direction du Num=C3=A9rique=20
Universit=C3=A9 de Lorraine=20
------=_Part_4076294_1166621201.1435388481648
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s=
ize: 12pt; color: #000000"><div>Hi,</div><div><br data-mce-bogus=3D"1"></di=
v><div>We are facing the exact same situation with a 3-way configurati=
on with openldap-2.4.39.2z packaged by Zimbra 8.6 p2.</div><div><br></=
div><div>Slapd crashes at some point during first replication. We can repro=
duce this on any of the 3 nodes by stopping ldap service, deleting dat=
abases (accesslog and mdb) and restarting ldap service.</div><div><br></div=
><div>Please tell us how we can be helpful.</div><div data-marker=3D"__SIG_=
PRE__"><br>Fr=C3=A9d=C3=A9ric Nass<br><br>Sous-direction Infrastructures <b=
r>Direction du Num=C3=A9rique <br>Universit=C3=A9 de Lorraine <br></div></d=
iv></body></html>
------=_Part_4076294_1166621201.1435388481648--
8 years, 5 months
Re: (ITS#8173)
by hyc＠symas.com
Adrian.Raemy(a)vtg.admin.ch wrote:
> --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Dear Howard,
>
> I did a core dump when the crash occurred at slapd respectively when the ba=
> ck-ldap crashed.
> Maybe the output of the gdb can help you find out where the problem is.
> Please let me know what you need more.
This trace seems to lack debug symbols. Without source line numbers etc.
there's nothing we can determine from this trace. Please read the FAQ.
http://www.openldap.org/faq/index.cgi?file=59
The trace shows that you probably have some overlays configured. What
overlays? You need to provide your slapd config files if you want any help here.
Volunteers aren't going to go out of their way to help you if you aren't going
to provide the needed info.
> Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap=
> s://0.0.0.0:636 -f /etc/op'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007fc0627492c6 in ldap_back_bind ()
> (gdb) where
> #0 0x00007fc0627492c6 in ldap_back_bind ()
> #1 0x00007fc062639fcb in fe_op_bind ()
> #2 0x00007fc0626a86fd in overlay_op_walk ()
> #3 0x00007fc0626a8956 in over_op_func ()
> #4 0x00007fc0626a89de in over_op_bind ()
> #5 0x00007fc062639697 in do_bind ()
> #6 0x00007fc06260ff19 in connection_operation ()
> #7 0x00007fc0626104e1 in connection_read_thread ()
> #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l=
> ibldap_r-2.4.so.2
> #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0
> #10 0x00007fc05fda902d in clone () from /lib64/libc.so.6
> #11 0x0000000000000000 in ?? ()
>
> Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap=
> s://0.0.0.0:636 -f /etc/op'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007fc0627492c6 in ldap_back_bind ()
> (gdb) where
> #0 0x00007fc0627492c6 in ldap_back_bind ()
> #1 0x00007fc062639fcb in fe_op_bind ()
> #2 0x00007fc0626a86fd in overlay_op_walk ()
> #3 0x00007fc0626a8956 in ?? ()
> #4 0x00007fc0626a89de in ?? ()
> #5 0x00007fc062639697 in do_bind ()
> #6 0x00007fc06260ff19 in ?? ()
> #7 0x00007fc0626104e1 in ?? ()
> #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l=
> ibldap_r-2.4.so.2
> #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0
> #10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6
> #11 0x0000000000000000 in ?? ()
>
> Best regards
> Adrian
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 5 months
(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch
--_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Dear Howard,
I did a core dump when the crash occurred at slapd respectively when the ba=
ck-ldap crashed.
Maybe the output of the gdb can help you find out where the problem is.
Please let me know what you need more.
Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap=
s://0.0.0.0:636 -f /etc/op'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fc0627492c6 in ldap_back_bind ()
(gdb) where
#0 0x00007fc0627492c6 in ldap_back_bind ()
#1 0x00007fc062639fcb in fe_op_bind ()
#2 0x00007fc0626a86fd in overlay_op_walk ()
#3 0x00007fc0626a8956 in over_op_func ()
#4 0x00007fc0626a89de in over_op_bind ()
#5 0x00007fc062639697 in do_bind ()
#6 0x00007fc06260ff19 in connection_operation ()
#7 0x00007fc0626104e1 in connection_read_thread ()
#8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l=
ibldap_r-2.4.so.2
#9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0
#10 0x00007fc05fda902d in clone () from /lib64/libc.so.6
#11 0x0000000000000000 in ?? ()
Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap=
s://0.0.0.0:636 -f /etc/op'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fc0627492c6 in ldap_back_bind ()
(gdb) where
#0 0x00007fc0627492c6 in ldap_back_bind ()
#1 0x00007fc062639fcb in fe_op_bind ()
#2 0x00007fc0626a86fd in overlay_op_walk ()
#3 0x00007fc0626a8956 in ?? ()
#4 0x00007fc0626a89de in ?? ()
#5 0x00007fc062639697 in do_bind ()
#6 0x00007fc06260ff19 in ?? ()
#7 0x00007fc0626104e1 in ?? ()
#8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l=
ibldap_r-2.4.so.2
#9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0
#10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6
#11 0x0000000000000000 in ?? ()
Best regards
Adrian
--_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Dear Howard,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I did a core dump when the cras=
h occurred at slapd respectively when the back-ldap crashed.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Maybe the output of the gdb can=
help you find out where the problem is.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Please let me know what you nee=
d more.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Core was generated by `/usr/lib=
/openldap/slapd -h ldap://0.0.0.0:389 ldaps://0.0.0.0:636 =
-f /etc/op'.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Program terminated with signal =
11, Segmentation fault.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#0 0x00007fc0627492c6 in =
ldap_back_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">(gdb) where<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#0 0x00007fc0627492c6 in =
ldap_back_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal">#1 0x00007fc062639fcb in fe_op_bind ()<o:p></o=
:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#2 0x00007fc0626a86fd in =
overlay_op_walk ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#3 0x00007fc0626a8956 in =
over_op_func ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#4 0x00007fc0626a89de in =
over_op_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#5 0x00007fc062639697 in =
do_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#6 0x00007fc06260ff19 in =
connection_operation ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#7 0x00007fc0626104e1 in =
connection_read_thread ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#8 0x00007fc062145c3c in =
ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#9 0x00007fc06155e806 in =
start_thread () from /lib64/libpthread.so.0<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#10 0x00007fc05fda902d in clone=
() from /lib64/libc.so.6<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#11 0x0000000000000000 in ?? ()=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Core was generated by `/usr/lib=
/openldap/slapd -h ldap://0.0.0.0:389 ldaps://0.0.0.0:636 =
-f /etc/op'.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Program terminated with signal =
11, Segmentation fault.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#0 0x00007fc0627492c6 in =
ldap_back_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">(gdb) where<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#0 0x00007fc0627492c6 in =
ldap_back_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal">#1 0x00007fc062639fcb in fe_op_bind ()<o:p></o=
:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#2 0x00007fc0626a86fd in =
overlay_op_walk ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#3 0x00007fc0626a8956 in =
?? ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#4 0x00007fc0626a89de in =
?? ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#5 0x00007fc062639697 in =
do_bind ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#6 0x00007fc06260ff19 in =
?? ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#7 0x00007fc0626104e1 in =
?? ()<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#8 0x00007fc062145c3c in =
ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#9 0x00007fc06155e806 in =
start_thread () from /lib64/libpthread.so.0<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#10 0x00007fc05fda902d in gnu_d=
ev_makedev () from /lib64/libc.so.6<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">#11 0x0000000000000000 in ?? ()=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:DE-CH"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:DE-CH">Best rega=
rds<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:DE-CH">Adrian</s=
pan><o:p></o:p></p>
</div>
</body>
</html>
--_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_--
8 years, 5 months
