(ITS#7826)
by antonin.meunier@cgi.com
--_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_
Content-Type: multipart/alternative;
boundary="_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_"
--_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGksDQpUbyBjb21wbGVtZW50IHRoZSBpbmNpZGVudCwgd2UgaGF2ZSByZXNldCBvdXIgZGlyZWN0
b3J5IChleHBvcnQsIGRlbGV0ZSwgaW1wb3J0KSB0aGUgc2l6ZSBvZiB0aGUgZGlyZWN0b3J5IGlz
IHJldHVybmVkIHRvIDIwR0INCkR1cmluZyB0aGUgcGFzc2FnZSBvZiBsZGlmIGFtZW5kaW5nIDc1
MCwwMDAgcGVvcGxlLCB0aGUgc2l6ZSBpcyBhZ2FpbiBpbmNyZWFzZWQgdG8gODBHQiAoYW5kIHNh
dHVyYXRpb24pLg0KV2UgY291bGQgZnVydGhlciBpbmNyZWFzZSB0aGUgc2l6ZSBidXQgODBHQiBm
b3IgZnVsbCByZWVsIHNpemUgb2YgMjBHQiwgYWxyZWFkeSBzZWVtIHRvIGRvIG11Y2guDQoNClRo
ZSBzcGVjaWZpYyBwYXJhbWV0ZXJzIHRvIE1EQiBhcmU6DQojIGVjcml0dXJlIGRpZmbDqXLDqWUN
CmRibm9zeW5jIFRSVUUNCiMgZWNyaXR1cmUgdG91cyBsZXMgMTUgbWludXRlcw0KY2hlY2twb2lu
dCAwIDE1DQojIFNldCB0byAzMiBHbw0KIyAzMiBHYiBzaG91bGQgYmUgZW5vdWdoLi4uIG5vbiBk
b25jIDgwR28NCiNtYXhzaXplIDM0MzU5NzM4MzY4DQptYXhzaXplIDg1ODk5MzQ1OTIwDQojIFBh
cmFtZXRyZXMgTURCDQptYXhyZWFkZXJzIDEyNg0KbW9kZSAwNjAwDQojIFNob3VsZCBiZSBtb3Jl
IHRoYW4gZW5vdWdoLi4uDQpzZWFyY2hzdGFjayAxNg0KDQpUaGUgbGRpZiBhcHBsaWVzIHRoZSBj
aGFuZ2VzIGJlbG93IHRvIDc1MCAwMDAgcGVvcGxlcyA6DQpkbjogdWlkPTk5OTkxMDAwMDAwMDAx
MjAwMSxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnINCmNoYW5nZXR5cGU6IG1vZGlm
eQ0KcmVwbGFjZTogdXNlclBhc3N3b3JkDQp1c2VyUGFzc3dvcmQ6IGF2bnA1emsNCg0KQW5kIHdo
ZW4gdGhlIHNhdHVyYXRpb24gYmVjb21lICg4MEdvKSB3ZSBoYXZlIGVycm9yIGxvZyA6DQoyMDE0
LTAzLTI1VDEyOjE3OjQ2LjA0ODg2MCswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02
NzgyNCBvcD0wIFJFU1VMVCB0YWc9OTcgZXJyPTAgdGV4dD0NCjIwMTQtMDMtMjVUMTI6MTc6NDYu
MDQ5MTUwKzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgTU9EIGRu
PSJ1aWQ9MjAyNyxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnIiDQoyMDE0LTAzLTI1
VDEyOjE3OjQ2LjA0OTE3NSswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02NzgyNCBv
cD0xIE1PRCBhdHRyPXVzZXJQYXNzd29yZA0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDkzNDMrMDE6
MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IHNsYXBfcXVldWVfY3NuOiBxdWVpbmcgMHg3ZmUyOTY3
ZmEyNzAgMjAxNDAzMjUxMTE3NDYuMDQ5MjcwWiMwMDAwMDAjMDAyIzAwMDAwMA0KMjAxNC0wMy0y
NVQxMjoxNzo0Ni4wNDk1MzErMDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106ID0+IG1kYl9pZGxf
ZGVsZXRlX2tleTogY19kZWwgaWQgZmFpbGVkOiBNREJfTUFQX0ZVTEw6IEVudmlyb25tZW50IG1h
cHNpemUgbGltaXQgcmVhY2hlZCAoLTMwNzkyKQ0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1NTgr
MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IGNvbm49Njc4MjQgb3A9MTogYXR0cmlidXRlICJl
bnRyeUNTTiIgaW5kZXggZGVsZXRlIGZhaWx1cmUNCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTY1
KzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgUkVTVUxUIHRhZz0x
MDMgZXJyPTgwIHRleHQ9DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0OTU3MiswMTowMCBsZGFwcDAx
IHNsYXBkWzM5MjgzXTogc2xhcF9ncmFkdWF0ZV9jb21taXRfY3NuOiByZW1vdmluZyAweDdmZTIy
NDEwMmY2MCAyMDE0MDMyNTExMTc0Ni4wNDkyNzBaIzAwMDAwMCMwMDIjMDAwMDAwDQoyMDE0LTAz
LTI1VDEyOjE3OjQ2LjA0OTk0MiswMTowMCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02Nzgy
NCBvcD0yIFVOQklORA0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk5NjMrMDE6MDAgbGRhcHAwMSBz
bGFwZFszOTI4M106IGNvbm49Njc4MjQgZmQ9MTE4IGNsb3NlZA0KDQoNCg0KQW50b25pbiBNZXVu
aWVyIHwgQ29uc3VsdGFudCBzb2x1dGlvbnMgc8Opbmlvcg0KT0JQIC0gTkJNIHwgQ0dJDQpJbW1l
dWJsZSBBbmRyb23DqGRlLCA2IHJ1ZSBkZXMgY29tw6h0ZXMsIENTIDEwMDI2LCAzMzE4NyBMZSBI
YWlsbGFuIENlZGV4IHwgRnJhbmNlDQpUIDogKzMzIDUgNTcgNzggNTkgNTQgfCBNIDogKzMzIDYg
ODUgMzEgNjEgNzYNCmFudG9uaW4ubWV1bmllckBjZ2kuY29tPG1haWx0bzphbnRvbmluLm1ldW5p
ZXJAY2dpLmNvbT4gfCB3d3cuY2dpLmNvbTxodHRwOi8vd3d3LmNnaS5jb20vPiB8IGdyYW5kYW5n
bGUuZnIubG9naWNhLmNvbTxodHRwOi8vZ3JhbmRhbmdsZS5mci5sb2dpY2EuY29tLz4NCg0KQ0dJ
IEZyYW5jZSBTQVMNCkNhcGl0YWwgOiAxMiA5MTMgOTMzIGV1cm9zIHwgUkNTIE5hbnRlcnJlIDcw
MiAwNDIgNzU1DQpTacOoZ2Ugc29jaWFsIDogSW1tZXVibGUgQ0IxNiB8IDE3LCBwbGFjZSBkZXMg
UmVmbGV0cyB8IDkyNDAwIENvdXJiZXZvaWUgfCBGcmFuY2UNCg0KW2NnaS1sb2dvMjAxMy1lbWFp
bC00NXgyNS5wbmddDQoNCltlbnZpcm9ubWVudC1sb2dvLWVtYWlsLWZyLmdpZl0NCg0KQVZJUyBE
RSBDT05GSURFTlRJQUxJVMOJIDogQ2UgbWVzc2FnZSBwZXV0IGNvbnRlbmlyIGRlcyByZW5zZWln
bmVtZW50cyBjb25maWRlbnRpZWxzIGFwcGFydGVuYW50IGV4Y2x1c2l2ZW1lbnQgYXUgR3JvdXBl
IENHSSBpbmMuIG91IMOgIHNlcyBmaWxpYWxlcy4gU2kgdm91cyBuJ8OqdGVzIHBhcyBsZSBkZXN0
aW5hdGFpcmUgaW5kaXF1w6kgb3UgcHLDqXZ1IGRhbnMgY2UgbWVzc2FnZSAob3UgcmVzcG9uc2Fi
bGUgZGUgbGl2cmVyIGNlIG1lc3NhZ2Ugw6AgbGEgcGVyc29ubmUgaW5kaXF1w6llIG91IHByw6l2
dWUpIG91IHNpIHZvdXMgcGVuc2V6IHF1ZSBjZSBtZXNzYWdlIHZvdXMgYSDDqXTDqSBhZHJlc3PD
qSBwYXIgZXJyZXVyLCB2b3VzIG5lIHBvdXZleiBwYXMgdXRpbGlzZXIgb3UgcmVwcm9kdWlyZSBj
ZSBtZXNzYWdlLCBuaSBsZSBsaXZyZXIgw6AgcXVlbHF1J3VuIGQnYXV0cmUuIERhbnMgY2UgY2Fz
LCB2b3VzIGRldmV6IGxlIGTDqXRydWlyZSBldCB2b3VzIMOqdGVzIHByacOpIGQnYXZlcnRpciBs
J2V4cMOpZGl0ZXVyIGVuIHLDqXBvbmRhbnQgYXUgY291cnJpZWwu4oCLDQoNCg0K
--_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv
QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl
IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K
c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K
c3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMg
Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRl
IGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uaHBz
DQoJe21zby1zdHlsZS1uYW1lOmhwczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w
cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMjA1MCIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG
UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBjbGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+VG8gY29tcGxlbWVudCB0
aGUgaW5jaWRlbnQsIHdlIGhhdmUgcmVzZXQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIj4N
CjxzcGFuIGNsYXNzPSJocHMiPm91ciBkaXJlY3Rvcnk8L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMi
PihleHBvcnQ8L3NwYW4+LCBkZWxldGUsIDxzcGFuIGNsYXNzPSJocHMiPg0KaW1wb3J0KTwvc3Bh
bj4gPHNwYW4gY2xhc3M9ImhwcyI+dGhlIHNpemUgb2YgdGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0i
aHBzIj5kaXJlY3RvcnkgaXM8L3NwYW4+DQo8c3BhbiBjbGFzcz0iaHBzIj5yZXR1cm5lZDwvc3Bh
bj4gPHNwYW4gY2xhc3M9ImhwcyI+dG8gMjBHQjwvc3Bhbj4gPGJyPg0KPHNwYW4gY2xhc3M9Imhw
cyI+RHVyaW5nPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj50aGUgcGFzc2FnZSBvZjwvc3Bhbj4g
PHNwYW4gY2xhc3M9ImhwcyI+DQpsZGlmPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5hbWVuZGlu
Zzwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+NzUwLDAwMDwvc3Bhbj4gPHNwYW4gY2xhc3M9Imhw
cyI+DQpwZW9wbGU8L3NwYW4+LCB0aGUgc2l6ZSBpcyA8c3BhbiBjbGFzcz0iaHBzIj5hZ2Fpbjwv
c3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+aW5jcmVhc2VkIHRvPC9zcGFuPg0KPHNwYW4gY2xhc3M9
ImhwcyI+ODBHQjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+KGFuZDwvc3Bhbj4gPHNwYW4gY2xh
c3M9ImhwcyI+c2F0dXJhdGlvbikuPC9zcGFuPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhwcyI+PHNwYW4gbGFuZz0iRU4iPldlIGNv
dWxkPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+DQo8c3BhbiBjbGFzcz0iaHBzIj5mdXJ0
aGVyIGluY3JlYXNlPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj50aGUgc2l6ZTwvc3Bhbj4gPHNw
YW4gY2xhc3M9ImhwcyI+DQpidXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPjgwR0I8L3NwYW4+
IDxzcGFuIGNsYXNzPSJocHMiPmZvcjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImhwcyI+DQpmdWxsIHJl
ZWwgc2l6ZTwvc3Bhbj4gb2YgPHNwYW4gY2xhc3M9ImhwcyI+MjBHQjwvc3Bhbj4sIDxzcGFuIGNs
YXNzPSJocHMiPmFscmVhZHkgc2VlbTwvc3Bhbj4NCjxzcGFuIGNsYXNzPSJocHMiPnRvIGRvIG11
Y2g8L3NwYW4+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOIj48YnI+DQo8c3BhbiBjbGFzcz0iaHBzIj5UaGU8L3NwYW4+IDxzcGFuIGNs
YXNzPSJocHMiPnNwZWNpZmljPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj4NCnBhcmFtZXRlcnM8
L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPnRvPC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5NREI8
L3NwYW4+IDxzcGFuIGNsYXNzPSJocHMiPg0KYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIGVjcml0dXJlIGRpZmbDqXLDqWU8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRibm9zeW5jIFRSVUU8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiMgZWNyaXR1cmUgdG91cyBsZXMgMTUgbWludXRlczxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hlY2twb2ludCAwIDE1PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFNldCB0byAzMiBHbzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IyAzMiBHYiBzaG91bGQgYmUgZW5vdWdoLi4uIG5vbiBk
b25jIDgwR288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiNtYXhzaXplIDM0
MzU5NzM4MzY4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYXhzaXplIDg1
ODk5MzQ1OTIwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFBhcmFtZXRy
ZXMgTURCPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYXhyZWFkZXJzIDEy
NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bW9kZSAwNjAwPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4jIFNob3VsZCBiZSBtb3JlIHRoYW4gZW5vdWdo
Li4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWFyY2hzdGFjayAxNjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iaHBzIj48c3BhbiBsYW5nPSJFTiI+
VGhlPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+DQo8c3BhbiBjbGFzcz0iaHBzIj5sZGlm
PC9zcGFuPiA8c3BhbiBjbGFzcz0iaHBzIj5hcHBsaWVzIHRoZSBjaGFuZ2VzPC9zcGFuPiA8c3Bh
biBjbGFzcz0iaHBzIj4NCmJlbG93PC9zcGFuPiB0byA8c3BhbiBjbGFzcz0iaHBzIj43NTA8L3Nw
YW4+Jm5ic3A7PHNwYW4gY2xhc3M9ImhwcyI+MDAwPC9zcGFuPiBwZW9wbGVzIDoNCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj5kbjog
dWlkPTk5OTkxMDAwMDAwMDAxMjAwMSxvdT1wZXJzb25uZXMsb3U9Q1JJRixkYz1lbnQsZGM9ZnI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
TiI+Y2hhbmdldHlwZTogbW9kaWZ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPnJlcGxhY2U6IHVzZXJQYXNzd29yZDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj51c2VyUGFz
c3dvcmQ6IGF2bnA1ems8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPkFuZCB3aGVuIHRoZSBzYXR1cmF0aW9uIGJlY29t
ZSAoODBHbykgd2UgaGF2ZSBlcnJvciBsb2cgOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDg4NjAmIzQzOzAxOjAwIGxk
YXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTAgUkVTVUxUIHRhZz05NyBlcnI9MCB0
ZXh0PQ0KPGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDkxNTAmIzQzOzAxOjAwIGxkYXBwMDEg
c2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9wPTEgTU9EIGRuPSZxdW90O3VpZD0yMDI3LG91PXBl
cnNvbm5lcyxvdT1DUklGLGRjPWVudCxkYz1mciZxdW90Ow0KPGJyPg0KMjAxNC0wMy0yNVQxMjox
Nzo0Ni4wNDkxNzUmIzQzOzAxOjAwIGxkYXBwMDEgc2xhcGRbMzkyODNdOiBjb25uPTY3ODI0IG9w
PTEgTU9EIGF0dHI9dXNlclBhc3N3b3JkDQo8YnI+DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0OTM0
MyYjNDM7MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IHNsYXBfcXVldWVfY3NuOiBxdWVpbmcg
MHg3ZmUyOTY3ZmEyNzAgMjAxNDAzMjUxMTE3NDYuMDQ5MjcwWiMwMDAwMDAjMDAyIzAwMDAwMA0K
PGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1MzEmIzQzOzAxOjAwIGxkYXBwMDEgc2xhcGRb
MzkyODNdOiA9Jmd0OyBtZGJfaWRsX2RlbGV0ZV9rZXk6IGNfZGVsIGlkIGZhaWxlZDogTURCX01B
UF9GVUxMOiBFbnZpcm9ubWVudCBtYXBzaXplIGxpbWl0IHJlYWNoZWQgKC0zMDc5MikNCjxicj4N
CjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTU4JiM0MzswMTowMCBsZGFwcDAxIHNsYXBkWzM5Mjgz
XTogY29ubj02NzgyNCBvcD0xOiBhdHRyaWJ1dGUgJnF1b3Q7ZW50cnlDU04mcXVvdDsgaW5kZXgg
ZGVsZXRlIGZhaWx1cmUNCjxicj4NCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5NTY1JiM0MzswMTow
MCBsZGFwcDAxIHNsYXBkWzM5MjgzXTogY29ubj02NzgyNCBvcD0xIFJFU1VMVCB0YWc9MTAzIGVy
cj04MCB0ZXh0PQ0KPGJyPg0KMjAxNC0wMy0yNVQxMjoxNzo0Ni4wNDk1NzImIzQzOzAxOjAwIGxk
YXBwMDEgc2xhcGRbMzkyODNdOiBzbGFwX2dyYWR1YXRlX2NvbW1pdF9jc246IHJlbW92aW5nIDB4
N2ZlMjI0MTAyZjYwIDIwMTQwMzI1MTExNzQ2LjA0OTI3MFojMDAwMDAwIzAwMiMwMDAwMDANCjxi
cj4NCjIwMTQtMDMtMjVUMTI6MTc6NDYuMDQ5OTQyJiM0MzswMTowMCBsZGFwcDAxIHNsYXBkWzM5
MjgzXTogY29ubj02NzgyNCBvcD0yIFVOQklORCA8YnI+DQoyMDE0LTAzLTI1VDEyOjE3OjQ2LjA0
OTk2MyYjNDM7MDE6MDAgbGRhcHAwMSBzbGFwZFszOTI4M106IGNvbm49Njc4MjQgZmQ9MTE4IGNs
b3NlZDxzcGFuIGxhbmc9IkVOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+QW50b25pbiBNZXVuaWVyPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+fCA8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zdWx0YW50IHNvbHV0aW9ucyBzw6luaW9y
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PQlAgLSBOQk0g
fCBDR0k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkltbWV1YmxlIEFuZHJvbcOoZGUsIDYgcnVlIGRlcyBjb23DqHRl
cywgQ1MgMTAwMjYsIDMzMTg3IExlIEhhaWxsYW4gQ2VkZXggfCBGcmFuY2U8YnI+DQpUIDombmJz
cDsmIzQzOzMzIDUgNTcgNzggNTkgNTQgfCBNIDogJiM0MzszMyA2IDg1IDMxIDYxIDc2PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNBMjk3OTEiPjxicj4NCjxhIGhyZWY9
Im1haWx0bzphbnRvbmluLm1ldW5pZXJAY2dpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUi
PmFudG9uaW4ubWV1bmllckBjZ2kuY29tPC9zcGFuPjwvYT4gfA0KPHU+PGEgaHJlZj0iaHR0cDov
L3d3dy5jZ2kuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPnd3dy5jZ2kuY29tPC9zcGFu
PjwvYT48L3U+IHwNCjx1PjxhIGhyZWY9Imh0dHA6Ly9ncmFuZGFuZ2xlLmZyLmxvZ2ljYS5jb20v
Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Z3JhbmRhbmdsZS5mci5sb2dpY2EuY29tPC9zcGFu
PjwvYT48L3U+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibHVl
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkNHSSBGcmFuY2UgU0FTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYXBpdGFsJm5ic3A7OiAxMiZuYnNwOzkxMyZu
YnNwOzkzMyBldXJvcw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnw8L3NwYW4+IFJDUyBO
YW50ZXJyZSA3MDImbmJzcDswNDImbmJzcDs3NTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpw6hnZSBzb2NpYWwg
OiBJbW1ldWJsZSBDQjE2DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+fDwvc3Bhbj4gMTcs
IHBsYWNlIGRlcyBSZWZsZXRzIDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCnw8L3NwYW4+
IDkyNDAwIENvdXJiZXZvaWUgfCBGcmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzNiIgaGVpZ2h0PSIyMCIgaWQ9IkltYWdl
X3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUNGNDhEOS5CNDZERURDMCIgYWx0PSJj
Z2ktbG9nbzIwMTMtZW1haWwtNDV4MjUucG5nIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtjb2xvcjpibGFjayI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNjQiIGhlaWdodD0iMTYi
IGlkPSJJbWFnZV94MDAyMF8zIiBzcmM9ImNpZDppbWFnZTAwNi5wbmdAMDFDRjQ4RDkuQjQ2REVE
QzAiIGFsdD0iZW52aXJvbm1lbnQtbG9nby1lbWFpbC1mci5naWYiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+QVZJUyBERSBDT05GSURFTlRJQUxJVMOJJm5ic3A7OiBDZSBtZXNzYWdlIHBldXQg
Y29udGVuaXIgZGVzIHJlbnNlaWduZW1lbnRzIGNvbmZpZGVudGllbHMgYXBwYXJ0ZW5hbnQgZXhj
bHVzaXZlbWVudCBhdSBHcm91cGUgQ0dJIGluYy4gb3Ugw6Agc2VzIGZpbGlhbGVzLg0KIFNpIHZv
dXMgbifDqnRlcyBwYXMgbGUgZGVzdGluYXRhaXJlIGluZGlxdcOpIG91IHByw6l2dSBkYW5zIGNl
IG1lc3NhZ2UgKG91IHJlc3BvbnNhYmxlIGRlIGxpdnJlciBjZSBtZXNzYWdlIMOgIGxhIHBlcnNv
bm5lIGluZGlxdcOpZSBvdSBwcsOpdnVlKSBvdSBzaSB2b3VzIHBlbnNleiBxdWUgY2UgbWVzc2Fn
ZSB2b3VzIGEgw6l0w6kgYWRyZXNzw6kgcGFyIGVycmV1ciwgdm91cyBuZSBwb3V2ZXogcGFzIHV0
aWxpc2VyIG91IHJlcHJvZHVpcmUgY2UgbWVzc2FnZSwNCiBuaSBsZSBsaXZyZXIgw6AgcXVlbHF1
J3VuIGQnYXV0cmUuIERhbnMgY2UgY2FzLCB2b3VzIGRldmV6IGxlIGTDqXRydWlyZSBldCB2b3Vz
IMOqdGVzIHByacOpIGQnYXZlcnRpciBsJ2V4cMOpZGl0ZXVyIGVuIHLDqXBvbmRhbnQgYXUgY291
cnJpZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_--
--_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_
Content-Type: image/png; name="image005.png"
Content-Description: image005.png
Content-Disposition: inline; filename="image005.png"; size=1648;
creation-date="Wed, 26 Mar 2014 08:56:49 GMT";
modification-date="Wed, 26 Mar 2014 08:56:49 GMT"
Content-ID: <image005.png(a)01CF48D9.B46DEDC0>
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAACQAAAAUCAYAAADlep81AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAXwSURBVEhL
zVZrbBRVFD73zt3udNmlbHnYpYhQYE3rD2OJQFV8JNAYVATlB1hACwLVtAl/lOAPmiUmioSkoSVZ
bLAhsfGBBlK1kvpKMBADIvIwTRqyMYW2BIF2u+2+ZuYcz50+pFhSfnKzs7tz53z3fufc75wzKhKJ
wP001P1ERnMZl9D6aMs0r1RPIsIcCdKwAR2QsmcyZk/VV628ejcnaupacpO+nCcQsEQiKNSGUvYr
lO2Jnn/OfB6psPTUrtpLxpVQ52P8bCYgWBbI9k+ryv/+H6E10ZapeaC2InleE0izJcBkATTEGnEw
Dapr88HWc0iwr6lqxZkRYmubm715iekbk6baJpEeIoBpQnPhiwgtArw5KRTsqoy2fsa4fRBOKJGA
HZNBLO8HB72A77FpdAyhLdHWEik8dUSwPFcKJi7AIwST0ZQAbKJJAkTYAgxnAH/jKZfQ+rqWB3LN
/AMKaJVHSEPbKqaiGKuHReRxBBV4hVEQRyvF5Pd3dAD5CvKDPmHkZQRCltcecc51fku0JWST+mSK
MBYPgOMSyBJCiuAPQdDDt7kkqHiK9IT4nsm6zjOuLWiZ6qBPypeTfL4eJs8EIAV4nkhoHAhB87wg
Fxg6Wu5neLBphvdgMnrCGUPIBqM6TxqLE2SDV0htdIkPe28OqBOha4GeHrPTZwcDxX2IzxqCKlHy
3voUwX4nIAwm47gRYSc6HCn3Qtb4xW+nXUIDfjU/aeOjTGU13waVPZs12enKa7yhauraCpOmeDPD
THOYjEUYs22oOFy94sJ/gLIM/z+lr8po21GfpdL8W8y+bUCtMSZjAV1hWpuatpafvGMjvc6FtbXN
X+SGps87Gwtay4K9OYN3I5Q07Wc4KjNYIyxAQltiY1P1i7eRGYtsqipv1zObo61v80+hxjEek0T1
h6uGyOyqrRWx4EI/mOCdCabTy3Op4Gwr1dN5uT1S7iyrO8tHPmP8CHHsHteLso4hA5SArPzybuEc
O0/zA1IJrYFBcrp4h59HnsegyOsxPTs4OZbcQMdNdTN3wEBv/jkmu7Mj/LztS/SNT0iCMPUTziAQ
JOxJduD6vRASIAOuiPnI+NjiFnAiD49gENQg0NJ84Xk6LnSSDMmhT9qBjnDYgI4YQSh/fEJ8Sv2C
jTWINeEZ8KcK2PLyRKTYetA9Zu2MEMFcgsm3YYjdG+gnhzh6rr+2/iZIT7SuMoQ4wZp8l4udLoB+
G/FVBu2ZCMiZ/2ccHCsHhMcHxsxBcJ5jzO8aF+wNZ5KF8WgK6AcO4iJFYt1QVZp4KDOtzgya9lVT
yFkEQhLSti0Nrccbq1ecHw9e+XHrKgSZkOlsm+NVV5QURdxaBBfQtzjzTrHoT+6OlOmAfKPxLP6N
7PS6iakMWahg78kbA4VlDRzOD/URsC7mZhUc4Y33K7SPNXLvGuo93U8JctYYEtbbAvc0bl/506aD
3x/hpNjhcHRzhJiLZB1iXB3jjjDupt6AyU+5VzIuod2RCNYc/vXAQCqxJE+oVWkumiaIBUmkeq4r
NZuirb1dIe4iIGb5pZyh6w4iupljkPFRUlglAaFe4voFpjAeTiM22EM4V+Ts44NZ/uW2ou8mPDm3
ddS/vnSAC+S2RK6dYU28wj2MdcH5BxDW33oVLV7d2xLcIqSEuMY1VpXf4vZRlRROKkfAao4ufyQH
UZSM7Izca7SsA9KAGw6asaIiKuqI6cdeH5PM8JUiHH3rGP1Tv738enFtbcWSwrI3kHCdDVTqByPI
2oIke58E7JUEf9mSvvUnbVcfw6S6F9U2b3ikcOoGy8EKklTKIs/TOJ3wfehoPt1xhy46gMdOl5XZ
RTHwQqLvcpycWUxG62201Ix5H2qPRBwuw4deqGv5usCnSvnVYE4WyJMmyEhJnamkuvQpE79TE6cj
FdnTjFvzQdvRvKlYmgQqTKNj8nsRcd+7Dqi6r6bTF7/bvjKlseGO41ZPaOH7t6Rq8HBDVKCujaw5
7gsaA/vYYLTy3qsov9pZfottf5zIXuuWbTqHrzHm/wLUFr4zzKdK5gAAAABJRU5ErkJggg==
--_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_
Content-Type: image/png; name="image006.png"
Content-Description: image006.png
Content-Disposition: inline; filename="image006.png"; size=3311;
creation-date="Wed, 26 Mar 2014 08:56:49 GMT";
modification-date="Wed, 26 Mar 2014 08:56:49 GMT"
Content-ID: <image006.png(a)01CF48D9.B46DEDC0>
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAQgAAAAQCAYAAADqBOG9AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAxvSURBVHja
7VoNcFTVFb7v3mtIJQgaRBShCFakSPmpVhEDqLRqwaoFRasIogNVYUAo8ishFCFACPt2sySr5IcY
qFEGBRUUpCjjdOpABepQSsFarWUsatoZbGc62Ln9zn33be6+fbsJyjhgd5gz7L537rnn97vn3A0r
KSlhLdGgVwYXO9Vc7Ti261OllGzNmhzlKEdnPrXI8Pvj+0ru3fkzxVYyNfPtGZ+/r94fk3NcjnKU
Awi2819vLpy0Y4KSpY5yIo5qX1aginfP+88BdfD+nPNylKP/Y4DYrw4+VPzbeSfOjxUqFmGKu0L/
f3H0ov9G3l1x4CP16fAzytBS1jEX8Bzl6BQBhFIn+mw6tuFPY9+6TzmrHE3tazqoUa+OPjjr/Vm3
KqUuCBWYYGfLhBzCY3wET/AR0pVXnQ6GcpfP4HH+KIDiWwHg6MDKWA/92WW9QG2+kkNd1om5st8Z
nRQuu4joa9inDfm8te91fBRzKF4szi49ZXpA1qmUd5rHNmt+6nqIe/WQESCOqmMDG/685g+XvthT
oeAVrxKKR0BPoYuoZKpoR5F64cMXXgNIXJSugLyeV4gPeEzU8YSoE65Yw2Jy2OnhHP4AHHBeCnDE
+K3ojp6hz05U7IADL/kqewAQe/Fyfs+ZnEQA05lEX0Oynu9ExJYs7y9GTF73v5v4dJLlcpiMyVPW
wZKsUynvdCadny6/O2PsvXpYlxUgTijVZ86umQ+zmWw8i7HxAIe1/GkAhCsXAV3GsxlsgnugfAoA
omPoBhFRZSk0FIHdZAKeh80reK2ow/PrzPu+UHgUKc2jopZ4rESdxxsANC4f14xw+V15JZ6BaGwA
XchX47sHSE+D94k0pyCheJ2o5TG5hD3HRKAYRtK+QYDA8/vM3vMs3oeoI+I10L9MDgLvWbB3mmX7
JLILfLdZ/Nfj+fiTtR9r7sW7q8GfAOCMD7c/v6uRcTNsHA4ZcxGjxWb9hCz+vM8fu0g2imMY6ZT0
Z5zvJWKlsmewO4Q+ca1/XF4dYv80OvW1D2ppH1ERao+JJ4/y5fDl37DXuJR4lcki7eNyeYMTExvT
AMKVRbQH7RWif2e+VsenqEX/0jqXj9WA48rBrZFnZIbbR+ti/OG0/CN7IIOV5fewYpGWXyl5CT0o
p8nnWePn8inW+yna/wR4yAl8nwiefOv7WK17Ob89Uz4iFlQPa5MxpxOVTWTnjdw+ssshdegsejhx
z8SzA8r+HAYqFhgXsK6AWr4AQNziuGID2sDuAJPulAzYMOYlhIjhFB/F6uGwiKiEvAFQ8hpeLT6h
5ALvXeCp0LwR+SS+T9W8MT6fggxnFXDqSOKyiAi8VdjnMl6JUSaGZKoQfyEZAcT8AYpmBcmhvX1d
LH1HQGadPWLo4nL5ErYee7h8MoBlvqe/PIiO6BVejTURFEqMj0bSbqYgEsHujZ4dosHi3w47+xr7
K7Q/6vT6NaxM9s9of1Q8S+t1YKmQkICmQJvtp8/6GZ+OgvpAry/nE5w68SY+/yJFHmwgW4xNSyjJ
9NqoOA7/lGudXPE0neo8LtagC6yndjPgqyUMyaVj4soIvt8ZsP8lPLudQCro7xR7Ip49OmYJsdv3
j4nXYNKDfAzfbRaufDs4YmD9L+kgYFuZtPXH/pux9ldJW1r0rziMva/A8+LWy5MDdO6G2qflDQnk
n2ePJyNKIy4VaiC/FgQOrQdMzEfj81Irfo/zesiJ8pU6H1xWCP+/ZQHoW4hDO21rtfgr9BsDHqk7
Qvpezm9hOj6iMWM9atD06kH73Inwpk7VnZoe2f3IG0fV0QvvWT/qwRu3Dde/WgDBPKoE1QAgos6/
WZQ14f8mJy6aIOg9tpCdmwIahJZx8RGU3Yrgb0WQ4z4KagPiUBo8TlTugUJD8XkQCnsDGUJgBZ6d
npPkYh8gUAy96bTC+65OlP/OLxDwHsHzbgZNOxPyBZOaOgbwfJslsKaS32U7NAgQVoDmU1eibUnI
Yr8Dwv8odvZ9jwcFFJc/BN2IxH+SCM4dbhxck+QvYwOtAO6kAjTrnyFe+ODacPtFjd95QJ/Z+DyX
kitg/2EDEI8B+VckO7aYeFnbbcuLigbYMkfbtFo8B3kLsDYf798AXzutnyt+beRNJoAJuV8qIH1B
Rdhjp46fZT90uEPfG5Sm+zvUnucYpyIM+P42f+QjX5MPQ0ageaQf9mmbon9MvIk1V7Xav34nE6PO
6yTkke3wI0vwexyXvxuUl8WeQg1wpL+dXwDWwJpF5CN/DPMByB+D8G6OyQfSd4uVX1u8QxQHhsmH
JH9zftxs5Wd6PXqAZgGE66grXuyrlh1eVo+RIa/bos4lrIqtwGjhUZSt0giIsaH9inZfnL0sT+Wv
zFMyIemXjeMhM/0Iv2UPkoiKXU6VeB6gU8NXy1W6hYPRkF1jivwS22CNfOvI8bIchdaXih+JeAjO
rdFEIw+KBk4cQK0vjL88ZI7tCjkLgKA1vErUCpMgLQDEVJ7g7+igV4tK8PzEJMwr2K+LSYg6pttS
OZSQ2EPjpINrgvwmIFupeKz1RURh9pMMJMSPUgqCWvqA/cmCMwmlW8QweVHxFP5t1zatETGMCP3x
vhPevxySYNR9zA25w7lDj5uVogon2gHEpL9tPyWf7kBC/B1qD/YiH6WNfBGvxcX7c4LFk7be1j89
PkVav3JR6R1erDvFIKs+LcpDrlWIIzqHvZH2Ua/jFbW+vEz2WB35tJT8MiNpygEVGD3o8MOzH1v6
ztT6up49Jn6bCNxM/GYH/DXbyvearPVoA4T++bKMqcs3Xq4GR6/a3G/OZUsHzu61eODcXouvLOmz
+OqZ353gM99cPuzu5XuWfvHTxpEqb4WkjuKzDJd+DWEAAWO2oePo4CcbHN6TTmGf3yT0dn+GppPf
GPgE2soSE8CkQ9AujddzlNdyzs9w6UJt4LNmbAGffKclfSFroX9JRwkCnjHJjqDUv6MQDUiIm/TM
7rXsS+gzPaPuIshv7H+dktQ/0Q2gDA21HzJIN6PjAtAsah9D7G+jT0DwBO0JyHuGZm1TKNfS3YgB
iO1Wgm3XAIG9qMjT4hcVb+tOroz14WvkIUb3ALb9LrvAzLBp/s5gDwHEtkyXxhp4XLk3JKbN64P6
W/HxOlTWH4B4RHrFXUgxyKpPS/KoQ/QBGOcr8vhB37++vIz24GSnOwEzMjfnV+BS24w8czHy5NEa
f3/ybVJfFLytr7lz+ru5F5rl54Nln50f9a2pxyRAaJBYyVR+RRvVfnU7dU5lgab8eJ4ScRo1ZHHz
z5+qX92HdcVDthURsKQBBKEoneYZbqWvhFIvYkbeAqfMobU0h/r8NC7AyEYzqvTDeLLOaQCvK5dS
Iuq2Gae5Uym2EOn5CQHUl2ou34+RZgvAYlXwZxvsNcWppj3lPH/+yqYv/cRHe9LepAMc9z2TsI3+
SKM7FoCBCehjREbeTdZcmuRPs5/uA1DwSNwbw+zXJ3LzCTed5IfYP1bPmN58PT1oT6o/WQ+cGLXa
n1Hp6p8KvbGs0TqlGrFHW31PUsv3w+5eafEDQFHngtOznkAmaD94zg3zd4g9k8kenF7vgX96aLzc
9HgF1rdN09+KD5J9EGy4BqfkRtJZd3CwwbyvCNEnqzyKlZ7xwUsxpO4GgHFDUF5o/q1tjheocyC/
+qXlX0Qu1wVs5KfEL1gPXj7NptzSAOSNiNMD/rLzoyJrPfr564pEEiA0SES5YjFHsVWYlJYx1eOF
nqrfqwNSAIJo48cbi4teCwcIfcJYN68hDuvC6lk3cpR/k+rz00xKqGjxdsSzbhS4wCzcjcis1w7X
lNByO4cAk6Q9zdr81uhLe+q9rT+w0jM4dPRv9GmtL9OXa8uz+U/W/kzyg/Zn3b8Ff+oEs9+TvvpU
1DI6h/1NCBWM5rtT3+3kheoX4u80e0qT+p5PJ3tr42Wv17oG9U+Nj6R7EZz467z7E8tnmN+D+rRC
Xp6tnz0+2vKy5V+2/ArkSTtb36z1YPJJ5xL9nUhpWr6k5kdp8/qs+Uh/DwO0UDZhgSqs7aju3ztO
VXy0+qXD6r3HbWU+UZ8tKt+3XLVZBDCJsn8EASJHOTrNfvfv61+O5uhL/K0KjwMYQE6Fo/Iq26iJ
+yapZX9c/puP1bFJdGnpM+5XB8Y9/8/nG6fumqz61/dVMoY1Uf45ZpjCnCNzlKNvKEBgTOjtU0G8
oPdxdbw3gKFDkHGP2vOd9U3rr2MjWR82C/wJUFxeFvzDoxzlKEffHPofSxluCl3TycEAAAAASUVO
RK5CYII=
--_005_F2AD894A2AA6704C8D712D76B50B8320AE7564B5SEEX023groupinf_--
9 years, 6 months
Re: (ITS#7825) LMDB: misleading error message
by timur.kristof@gmail.com
--001a11c13346e990f604f57e2991
Content-Type: text/plain; charset=UTF-8
Hi,
For further information, see the discussion here:
https://github.com/Venemo/node-lmdb/pull/20
We genuinely thought that there had been something wrong with our value
sizes somewhere, so I wasted several hours debugging in the wrong place.
Then, by accident I discovered that it's in fact an issue with V8's GC.
I definitely suggest to choose one of the solutions that don't cost any
execution time when there is no error.
Perhaps mdb_dbi_close could return an error (or crash) when the dbi is
still used by a cursor. That'd eliminate the issue but it'd also mean an
API/ABI break.
Best regards,
Timur
On Tue, Mar 25, 2014 at 10:37 AM, Hallvard Breien Furuseth <
h.b.furuseth(a)usit.uio.no> wrote:
> On Sat, 2014-03-22 at 22:49 +0000, timur.kristof(a)gmail.com wrote:
> > When you operate on a dbi using a cursor and accidentally close the dbi
> before
> > committing the transaction of the cursor, mdb_txn_commit will return
> > MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't
> actually
> > have anything to do with what the error message suggests. ("Too big
> key/data,
> > key is empty, or wrong DUPFIXED size")
> >
> > I suggest to either add a new kind of error code for this situation or
> to extend
> > the description of MDB_BAD_VALSIZE.
>
> Let's see -- here are the options I can see (after an IRC chat):
>
> 1) Extending the MDB_BAD_VALSIZE description. Simple. However:
>
> This is documented as a user error, and it's one which lmdb
> won't always catch. If you also called mdb_dbi_open() and the
> DBI got reused, lmdb silently updates the wrong named database.
>
> So I'm a bit wary about both of these fixes: Documenting this
> case can be misleading if it makes users expect it to be caught.
>
> Unless people know better - it corresponds to EBADF for using a
> closed file descriptor, not caught if open() reused it.
>
>
> 2) Catch this case and instead return a generic "something is
> wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE.
> And maybe assert(did not happen) to teach users to avoid this.
>
> Needs to be done where md_name is used: Commit/drop(named DB),
> page_search(stale named DB), cursor_touch(clean named DB). Or
> pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE"
> statements to detect this.
>
> After playing around a bit, I guess this is my favorite.
>
>
> 3) Leave the misleading message alone, which can send the user
> off to a wild goose chase (as described on IRC).
>
>
> Or we can add code to also catch close followed by open:
>
> 4) Put hash(DB name) in MDB_db.md_pad and verify it before
> overwriting a named DB. Costs execution time even when there's
> no error. Must be done in commit, drop and maybe cursor_touch.
> (I've pushed a demo patch for just commit.)
>
> 5) Add field MDB_dbx.md_dbiseq = DBI usage sequence number,
> incremented when dbi_open creates (not reuses) a DBI and in
> dbi_close. Copy it to a new malloced array txn->mt_dbiseqs[]
> in write txns, verify it in at least commit and drop.
> This means close()-open(same DB) will also be caught, which
> seems a good thing since with (4) it will work unreliably:
> Only if open() reuses the same DBI for the same DB.
>
--001a11c13346e990f604f57e2991
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Hi,<br><br>For further information, see the disc=
ussion here: <a href=3D"https://github.com/Venemo/node-lmdb/pull/20">https:=
//github.com/Venemo/node-lmdb/pull/20</a><br></div><div>We genuinely though=
t that there had been something wrong with our value sizes somewhere, so I =
wasted several hours debugging in the wrong place. Then, by accident I disc=
overed that it's in fact an issue with V8's GC.<br>
</div><div><br>I definitely suggest to choose one of the solutions that don=
't cost any execution time when there is no error. <br><br></div>Perhap=
s mdb_dbi_close could return an error (or crash) when the dbi is still used=
by a cursor. That'd eliminate the issue but it'd also mean an API/=
ABI break.<br>
<br></div>Best regards,<br>Timur<br><div><div><br><br></div></div></div><di=
v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 25, =
2014 at 10:37 AM, Hallvard Breien Furuseth <span dir=3D"ltr"><<a href=3D=
"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.uio.n=
o</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Sat, 2014-03-22 at 22:49 +0000, <a href=
=3D"mailto:timur.kristof@gmail.com">timur.kristof(a)gmail.com</a> wrote:<br>
> When you operate on a dbi using a cursor and accidentally close the db=
i before<br>
> committing the transaction of the cursor, mdb_txn_commit will return<b=
r>
> MDB_BAD_VALSIZE. This is quite misleading because the problem doesn=
9;t actually<br>
> have anything to do with what the error message suggests. ("Too b=
ig key/data,<br>
> key is empty, or wrong DUPFIXED size")<br>
><br>
> I suggest to either add a new kind of error code for this situation or=
to extend<br>
> the description of MDB_BAD_VALSIZE.<br>
<br>
Let's see -- here are the options I can see (after an IRC chat):<br>
<br>
1) Extending the MDB_BAD_VALSIZE description. Simple. However:<br>
<br>
This is documented as a user error, and it's one which lmdb<br>
won't always catch. =C2=A0If you also called mdb_dbi_open() and the<br>
DBI got reused, lmdb silently updates the wrong named database.<br>
<br>
So I'm a bit wary about both of these fixes: Documenting this<br>
case can be misleading if it makes users expect it to be caught.<br>
<br>
Unless people know better - it corresponds to EBADF for using a<br>
closed file descriptor, not caught if open() reused it.<br>
<br>
<br>
2) Catch this case and instead return a generic "something is<br>
wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE.<br>
And maybe assert(did not happen) to teach users to avoid this.<br>
<br>
Needs to be done where md_name is used: Commit/drop(named DB),<br>
page_search(stale named DB), cursor_touch(clean named DB). =C2=A0Or<br>
pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE"<br>
statements to detect this.<br>
<br>
After playing around a bit, I guess this is my favorite.<br>
<br>
<br>
3) Leave the misleading message alone, which can send the user<br>
off to a wild goose chase (as described on IRC).<br>
<br>
<br>
Or we can add code to also catch close followed by open:<br>
<br>
4) Put hash(DB name) in MDB_db.md_pad and verify it before<br>
overwriting a named DB. =C2=A0Costs execution time even when there's<br=
>
no error. =C2=A0Must be done in commit, drop and maybe cursor_touch.<br>
(I've pushed a demo patch for just commit.)<br>
<br>
5) Add field MDB_dbx.md_dbiseq =3D DBI usage sequence number,<br>
incremented when dbi_open creates (not reuses) a DBI and in<br>
dbi_close. =C2=A0Copy it to a new malloced array txn->mt_dbiseqs[]<br>
in write txns, verify it in at least commit and drop.<br>
This means close()-open(same DB) will also be caught, which<br>
seems a good thing since with (4) it will work unreliably:<br>
Only if open() reuses the same DBI for the same DB.<br>
</blockquote></div><br></div>
--001a11c13346e990f604f57e2991--
9 years, 6 months
(ITS#7828) LMDB crash in mdb_cursor_put(MDB_CURRENT)
by sbn@tbricks.com
Full_Name: Dmitri Shubin
Version: LMDB 0.9.11 (2727e97)
OS: Linux (CentOS 6)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.239.140.98)
Hi!
I got a crash inside LMDB in mdb_cursor_put() functions when I trying to modify
the record under cursor.
Simple test:
$ cat test-mdb_current.c
#include <stdio.h>
#include <stdlib.h>
#include "lmdb.h"
#define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr)
#define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \
"%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort()))
#define DBDIR "./testdb"
int main()
{
int rc;
MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;
MDB_val key, data;
MDB_cursor *cursor;
int key_v = 17;
char data_v[] = "0123456789";
E(system("rm -rf " DBDIR " && mkdir " DBDIR));
E(mdb_env_create(&env));
E(mdb_env_open(env, DBDIR, 0, 0664));
E(mdb_txn_begin(env, NULL, 0, &txn));
E(mdb_dbi_open(txn, NULL, 0, &dbi));
/* put some data */
key.mv_data = &key_v;
key.mv_size = sizeof(key_v);
data.mv_data = data_v;
data.mv_size = sizeof(data_v);
E(mdb_put(txn, dbi, &key, &data, 0));
E(mdb_txn_commit(txn));
/* replace using cursor */
E(mdb_txn_begin(env, NULL, 0, &txn));
E(mdb_cursor_open(txn, dbi, &cursor));
E(mdb_cursor_get(cursor, &key, &data, MDB_SET));
data.mv_data = data_v;
data.mv_size = sizeof(data_v) - 1;
E(mdb_cursor_put(cursor, &key, &data, MDB_CURRENT));
mdb_cursor_close(cursor);
E(mdb_txn_commit(txn));
mdb_dbi_close(env, dbi);
mdb_env_close(env);
return 0;
}
$ gcc -g test-mdb_current.c -llmdb -L. -Wl,-rpath,.
$ ./a.out
Segmentation fault (core dumped)
$ gdb a.out
...
Program terminated with signal 11, Segmentation fault.
#0 0x00007fefaba9895c in mdb_leaf_size (env=0xbd8010, key=0x0,
data=0x7fff59e6a830) at mdb.c:6430
6430 sz = LEAFSIZE(key, data);
(gdb) bt
#0 0x00007fefaba9895c in mdb_leaf_size (env=0xbd8010, key=0x0,
data=0x7fff59e6a830) at mdb.c:6430
#1 0x00007fefaba97c53 in mdb_cursor_put (mc=0xbda2f0, key=0x0,
data=0x7fff59e6a830, flags=64) at mdb.c:6178
#2 0x0000000000400ee0 in main () at test-mdb_current.c:51
(gdb) l
6425 static size_t
6426 mdb_leaf_size(MDB_env *env, MDB_val *key, MDB_val *data)
6427 {
6428 size_t sz;
6429
6430 sz = LEAFSIZE(key, data);
6431 if (sz > env->me_nodemax) {
6432 /* put on overflow page */
6433 sz -= data->mv_size - sizeof(pgno_t);
6434 }
(gdb) p key
$1 = (MDB_val *) 0x0
If I remove MDB_CURRENT flag from mdb_cursor_put() call it works fine.
Thanks!
9 years, 6 months
Re: (ITS#7827) Typo in slapacl can causes unclean database
by hyc@symas.com
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: openldap master
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.58.125)
>
>
> As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741248, slapacl
> when used with a base that is not contained in the OpenLDAP configuration can
> cause unclean DB messages.
Fixed now in master
>
> To reproduce, I had to disable the monitor database in my configuration, so that
> there was only the cn=config db and a primary BDB based backend. It also does
> not occur if the suffix for the database is "" (as that contains everything).
>
> If the suffix of the DB is specific(such as "cn=zimbra"), then you can cause the
> unclean shutdown status to trigger by running slapacl against a suffix that is
> not contained in the slapd configuration:
>
> zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
> /opt/zimbra/data/ldap/config -b "cn=zimbraaaaa" -D
> "uid=zimbra,cn=admins,cn=zimbra" entry
> 5331d242 hdb_monitor_db_open: monitoring disabled; configure monitor database to
> enable
> 5331d242 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
> attempting recovery.
> 5331d242 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
> Run manual recovery if errors are encountered.
> authcDN: "uid=zimbra,cn=admins,cn=zimbra"
> cn=zimbraaaaa: no target database has been found for baseDN="slapacl"; you may
> try with "-u" (dry run).
> zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
> /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
> entry
> 5331d258 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
> attempting recovery.
> 5331d258 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
> Run manual recovery if errors are encountered.
> 5331d258 hdb_monitor_db_open: monitoring disabled; configure monitor database to
> enable
> authcDN: "uid=zimbra,cn=admins,cn=zimbra"
> entry: write(=wrscxd)
> zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
> /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
> entry
> 5331d262 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
> attempting recovery.
> 5331d262 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
> Run manual recovery if errors are encountered.
> 5331d262 hdb_monitor_db_open: monitoring disabled; configure monitor database to
> enable
> authcDN: "uid=zimbra,cn=admins,cn=zimbra"
> entry: write(=wrscxd)
>
> Even running db_recover does not fix it:
>
> zimbra@zre-ldap001:~/data/ldap/hdb/db$ db_recover
> zimbra@zre-ldap001:~/data/ldap/hdb/db$ cd
> zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
> /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
> entry
> 5331d350 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
> attempting recovery.
> 5331d350 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
> Run manual recovery if errors are encountered.
> 5331d350 hdb_monitor_db_open: monitoring disabled; configure monitor database to
> enable
> authcDN: "uid=zimbra,cn=admins,cn=zimbra"
> entry: write(=wrscxd)
>
> After starting slapd, the db is properly cleaned up:
>
> zimbra@zre-ldap001:~$ ps -eaf | grep slapd
> zimbra 1655 1 3 12:05 ? 00:00:00 /opt/zimbra/openldap/sbin/slapd
> -l LOCAL0 -u zimbra -h ldap://zre-ldap001.eng.zimbra.com:389 ldapi:/// -F
> /opt/zimbra/data/ldap/config
>
> zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
> /opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
> entry
> authcDN: "uid=zimbra,cn=admins,cn=zimbra"
> entry: write(=wrscxd)
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 6 months
(ITS#7827) Typo in slapacl can causes unclean database
by quanah@OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: openldap master
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.58.125)
As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741248, slapacl
when used with a base that is not contained in the OpenLDAP configuration can
cause unclean DB messages.
To reproduce, I had to disable the monitor database in my configuration, so that
there was only the cn=config db and a primary BDB based backend. It also does
not occur if the suffix for the database is "" (as that contains everything).
If the suffix of the DB is specific(such as "cn=zimbra"), then you can cause the
unclean shutdown status to trigger by running slapacl against a suffix that is
not contained in the slapd configuration:
zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
/opt/zimbra/data/ldap/config -b "cn=zimbraaaaa" -D
"uid=zimbra,cn=admins,cn=zimbra" entry
5331d242 hdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
5331d242 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
attempting recovery.
5331d242 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
Run manual recovery if errors are encountered.
authcDN: "uid=zimbra,cn=admins,cn=zimbra"
cn=zimbraaaaa: no target database has been found for baseDN="slapacl"; you may
try with "-u" (dry run).
zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
/opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
entry
5331d258 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
attempting recovery.
5331d258 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
Run manual recovery if errors are encountered.
5331d258 hdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
authcDN: "uid=zimbra,cn=admins,cn=zimbra"
entry: write(=wrscxd)
zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
/opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
entry
5331d262 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
attempting recovery.
5331d262 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
Run manual recovery if errors are encountered.
5331d262 hdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
authcDN: "uid=zimbra,cn=admins,cn=zimbra"
entry: write(=wrscxd)
Even running db_recover does not fix it:
zimbra@zre-ldap001:~/data/ldap/hdb/db$ db_recover
zimbra@zre-ldap001:~/data/ldap/hdb/db$ cd
zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
/opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
entry
5331d350 hdb_db_open: database "cn=zimbra": unclean shutdown detected;
attempting recovery.
5331d350 hdb_db_open: database "cn=zimbra": recovery skipped in read-only mode.
Run manual recovery if errors are encountered.
5331d350 hdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
authcDN: "uid=zimbra,cn=admins,cn=zimbra"
entry: write(=wrscxd)
After starting slapd, the db is properly cleaned up:
zimbra@zre-ldap001:~$ ps -eaf | grep slapd
zimbra 1655 1 3 12:05 ? 00:00:00 /opt/zimbra/openldap/sbin/slapd
-l LOCAL0 -u zimbra -h ldap://zre-ldap001.eng.zimbra.com:389 ldapi:/// -F
/opt/zimbra/data/ldap/config
zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapacl -F
/opt/zimbra/data/ldap/config -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra"
entry
authcDN: "uid=zimbra,cn=admins,cn=zimbra"
entry: write(=wrscxd)
9 years, 6 months
Re: (ITS#7825) LMDB: misleading error message
by h.b.furuseth@usit.uio.no
I wrote:
> Let's see -- here are the options I can see (after an IRC chat):
> (...)
> 2) Catch this case and instead return a generic "something is
> wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE.
> (...)
Duh, I forgot
(6) Like (2) but create a new error code after all. Then we can
document in its description that it's not caught reliably. That
wasn't hard:-)
9 years, 6 months
Re: (ITS#7825) LMDB: misleading error message
by h.b.furuseth@usit.uio.no
On Sat, 2014-03-22 at 22:49 +0000, timur.kristof(a)gmail.com wrote:
> When you operate on a dbi using a cursor and accidentally close the dbi before
> committing the transaction of the cursor, mdb_txn_commit will return
> MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't actually
> have anything to do with what the error message suggests. ("Too big key/data,
> key is empty, or wrong DUPFIXED size")
>
> I suggest to either add a new kind of error code for this situation or to extend
> the description of MDB_BAD_VALSIZE.
Let's see -- here are the options I can see (after an IRC chat):
1) Extending the MDB_BAD_VALSIZE description. Simple. However:
This is documented as a user error, and it's one which lmdb
won't always catch. If you also called mdb_dbi_open() and the
DBI got reused, lmdb silently updates the wrong named database.
So I'm a bit wary about both of these fixes: Documenting this
case can be misleading if it makes users expect it to be caught.
Unless people know better - it corresponds to EBADF for using a
closed file descriptor, not caught if open() reused it.
2) Catch this case and instead return a generic "something is
wrong" - MDB_BAD_TXN or MDB_INCOMPATIBLE.
And maybe assert(did not happen) to teach users to avoid this.
Needs to be done where md_name is used: Commit/drop(named DB),
page_search(stale named DB), cursor_touch(clean named DB). Or
pass F_SUBDATA inwards and tweak the "return MDB_BAD_VALSIZE"
statements to detect this.
After playing around a bit, I guess this is my favorite.
3) Leave the misleading message alone, which can send the user
off to a wild goose chase (as described on IRC).
Or we can add code to also catch close followed by open:
4) Put hash(DB name) in MDB_db.md_pad and verify it before
overwriting a named DB. Costs execution time even when there's
no error. Must be done in commit, drop and maybe cursor_touch.
(I've pushed a demo patch for just commit.)
5) Add field MDB_dbx.md_dbiseq = DBI usage sequence number,
incremented when dbi_open creates (not reuses) a DBI and in
dbi_close. Copy it to a new malloced array txn->mt_dbiseqs[]
in write txns, verify it in at least commit and drop.
This means close()-open(same DB) will also be caught, which
seems a good thing since with (4) it will work unreliably:
Only if open() reuses the same DBI for the same DB.
9 years, 6 months
Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc@symas.com
This is a multi-part message in MIME format.
--------------050807020608030505070800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
hyc(a)symas.com wrote:
> Michael Ströder wrote:
>> hyc(a)symas.com wrote:
>>> I was considering returning LDAP_BUSY for this case, but it may make more
>>> sense to return a REFERRAL to the provider instead. (Although again, if we
>>> have two MMR servers pointed at each other starting at the same time, they
>>> would just refer to each other and clients would get nowhere until one of them
>>> finishes its refresh.)
>>
>> IMO referrals are harmful.
>> Just returning LDAP_BUSY seems best to me because if reliable HA is really
>> important for a deployment you have decent load-balancers in front of your
>> LDAP server which should do a proper health-check.
The attached patch should provide the desired behavior. It needs more testing
though.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------050807020608030505070800
Content-Type: text/plain; charset=UTF-8;
name="diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="diff.txt"
diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c
index 9b5c0f3..4ea8a70 100644
--- a/servers/slapd/syncrepl.c
+++ b/servers/slapd/syncrepl.c
@@ -148,6 +148,8 @@ static int syncrepl_add_glue_ancestors(
/* delta-mmr overlay handler */
static int syncrepl_op_modify( Operation *op, SlapReply *rs );
+static int syncrepl_op_search( Operation *op, SlapReply *rs );
+
/* callback functions */
static int dn_callback( Operation *, SlapReply * );
static int nonpresent_callback( Operation *, SlapReply * );
@@ -216,16 +218,14 @@ init_syncrepl(syncinfo_t *si)
if ( !syncrepl_ov.on_bi.bi_type ) {
syncrepl_ov.on_bi.bi_type = "syncrepl";
syncrepl_ov.on_bi.bi_op_modify = syncrepl_op_modify;
+ syncrepl_ov.on_bi.bi_op_search = syncrepl_op_search;
overlay_register( &syncrepl_ov );
}
- /* delta-MMR needs the overlay, nothing else does.
- * This must happen before accesslog overlay is configured.
- */
- if ( si->si_syncdata &&
- !overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) {
+ if (!overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) {
overlay_config( si->si_be, syncrepl_ov.on_bi.bi_type, -1, NULL, NULL );
- if ( !ad_reqMod ) {
+ /* delta-MMR needs this. Must happen before accesslog overlay is configured. */
+ if ( si->si_syncdata && !ad_reqMod ) {
const char *text;
logschema *ls = &accesslog_sc;
@@ -1179,6 +1179,7 @@ do_syncrep2(
} else {
rc = -2;
}
+ si->si_refreshDone = 1;
goto done;
case LDAP_RES_INTERMEDIATE:
@@ -2164,6 +2165,31 @@ syncrepl_op_modify( Operation *op, SlapReply *rs )
}
static int
+syncrepl_op_search( Operation *op, SlapReply *rs )
+{
+ slap_overinst *on = (slap_overinst *)op->o_bd->bd_info;
+ syncinfo_t *si;
+
+ /* Allow syncrepl internal searches */
+ if ( op->o_conn->c_conn_idx == -1 )
+ return SLAP_CB_CONTINUE;
+
+ /* Check if any of our consumers are refreshing */
+ for ( si = op->o_bd->be_syncinfo; si; si = si->si_next ) {
+ /* If we have some state, allow other consumers to progress */
+ if ( si->si_cookieState->cs_num > 0 &&
+ op->o_sync > SLAP_CONTROL_IGNORED )
+ return SLAP_CB_CONTINUE;
+ /* If we have any consumer refreshing, reject searches */
+ if ( !si->si_refreshDone ) {
+ send_ldap_error( op, rs, LDAP_BUSY, "syncrepl refresh in progress" );
+ return rs->sr_err;
+ }
+ }
+ return SLAP_CB_CONTINUE;
+}
+
+static int
syncrepl_message_to_op(
syncinfo_t *si,
Operation *op,
--------------050807020608030505070800--
9 years, 6 months
Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ck@cksoft.de
Hi,
I can confirm that openldap-2.4.39 still has in issue with this.
When connecting via TLS I tried to modify olcTLSVerifyClient from never
to try with following ldif:
dn: cn=config
changetype: modify
replace: olcTLSVerifyClient
olcTLSVerifyClient: try
this caused slapd to hang indefinetely.
I was able to successfully modify above when connecting without TLS.
I need to complete my current task but will set up a small proof of
concept later on in my lab.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
9 years, 6 months