Re: ITS#4853
by ando＠sys-net.it
Richard Bos wrote:
> Hello Pierangelo,
>
> Op dinsdag 27 februari 2007 22:27, schreef u:
>> Fixed in re23; please test.
>>
>> I note that the name of the macro may have tricked you; Debug() is
>> actually the logging system of OpenLDAP software, not a mere debug
>> statement.
>
> I assume I may not update the ticket,
You should never __assume__, when the system is self-documented:
> Replies and Followups
> ---------------------
>
> A reply is a message that has been sent from JitterBug to answer an
> incoming message.
>
> A followup is a reply to a reply. Followups are created when a user
> sends a email reply to a JitterBug generated message. Followups are
> detected by looking for the PR# automatically added to the subject
> line in replies.
> hence this email to you:
>
> What do you mean with fixed in "re23".
The code has been fixed in the release engineering branch of 2.3 code,
and will thus appear in the next release.
> Which release is that exactly?
Likely, 2.3.35, if any.
> What does the change involve?
Look at the code from the CVS.
> Is the message now sent to a log file?
> < Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n",
>> Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new attribute <%s>\n",
It's sent wherever configured, like it was before (see slapd(8) and
slapd.conf(5) for details about logging). The difference is that
earlier that message was being always issued, while now it's only issued
if expressly requested, since it's just informative and not indicative
of any bug.
The macros seem pretty self-esplicative. I hope that bug didn't cause
any harm to your system, though.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
ITS#4853
by ando＠sys-net.it
Fixed in re23; please test.
I note that the name of the macro may have tricked you; Debug() is
actually the logging system of OpenLDAP software, not a mere debug
statement.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
(ITS#4853) A debug message is printed, from the released version
by ml＠radoeka.nl
Full_Name: Richard Bos
Version: 2.3.27
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.126.75.243)
I just upgraded to the new slapd.conf file from cvs and now when I run
slapcat I get the following output:
# slapcat >/dev/null
/etc/openldap/slapd.conf: line 67: new attribute <member>
The config file contains:
63 #### Using overlays to improve data consistency
64 # Ensure that we never get dangling member attributes
65 # Checked on rename and delete
66 overlay refint
67 refint_attributes member
68
The code in servers/slapd/overlays/refint.c reads as follows:
if(!strcasecmp(*argv, "refint_attributes")) {
for(i = 1; i < argc; i++) {
...
some checks for error conditions here but if
all is fine we fall through to the following
section
...
ip = ch_malloc(sizeof(refint_attrs));
ip->attr = ad;
ip->next = id->attrs;
id->attrs = ip;
Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute
<%s>\n",
fname, lineno, argv[i]);
The final debug message results seems to be the message that is printed.
It's my assumption that no debug messages should be printed in a released
product/version/project.
The initial bug report is located at:
https://intevation.de/roundup/kolab/issue1622
16 years, 7 months
Re: (ITS#4845) Back-perl is non working
by hyc＠symas.com
kiwi(a)oav.net wrote:
>> No surprise that such a careful redesign resulted, as a side
>> effect, in a stricter compliance with RFC2589. The fact that
>> nobody complained up to now indicates that strict adherence to
>> specs usually helps in code portability.
>
> Yeah. But I didn't know that RFC2589 is used inside back_<whatever>.
> Now I am aware of that and I really thanks about your help and your
> kindness to take some time to find where my error was.
I think he meant RFC2849, which is the LDIF specification.
> Maybe a little not in slapd-perl man page that entry sent to openldap
> have to conform to RFC2589 should be a point to avoid such loss of time.
The slapd-perl(5) man page says that it expects LDIF entries to be
returned. As such, it is already a given that they must actually conform
to the LDIF spec.
> Thanks again, and this bug is closed for me.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 7 months
Potential bug (schema or ldap add?)
by Andrew Seguin
I'm not too sure of the details yet, I wanted to check with this list
first, but here's the story.
In general, I'm using phpLDAPadmin to work with the ldap directory.
I added the iaaa-radius.schema from Interlink. I found it was missing the
EQUALITY statements, so phpLDAPadmin couldn't "add" new aaaReply items
once the first one was added. Via import and adding a user all at once was
not a problem.
I modified the iaaa-radius.schema file, found the aaaReply attribute and
added the lines "EQUALITY caseIgnoreMatch" and "SUBSTR
caseIgnoreSubstringsMatch".
I went into phpLDAPadmin, created a new aaaPerson with one initial
aaaReply attribute, then added a second aaaReply value without problem. To
date all is good.
I went to a user which already exists, which already has three aaaReply
attributes/values, and tried to add a new aaaReply value - at which point
it would seem that slapd either crashed or shutdown. I turned on logging
and couldn't see anything really abnormal... nor did I find any core dump
file.
Any ideas if this is a bug or possibly just some kind of internal
consistency check on records created before the Schema was modified?
Thank you,
Andrew
16 years, 7 months
Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net
--Apple-Mail-13-1003230263
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Hello,
>> By the way, I still don't understand why this kind of script was
>> working on
>> openldap 2.1 and 2.2.... ?
>> Does str2entry() is more picky since openldap 2.3 ?
>
> The fact that something __worked__ doesn't mean it was correct.
> That code working was apparently the consequence of two bugs
> canceling each other.
I totaly agree with you :)
> str2entry() is not just more picky: it has been __entirely__
> rewritten, to reduce the performance impact of the related memory
> allocation, which guaranteed orders of magnitude of improvement
> from 2.0 to 2.3 (the amount of fragmented malloc()s was a
> considerable bottleneck). Redesigning code for performance, as well
> as for stricter adherence to specs, is part of its natural evolution.
Again I agree with you. I am also maintainer of some opensource
project and sometimes we need to recode something that is slow to
have better performances.
> No surprise that such a careful redesign resulted, as a side
> effect, in a stricter compliance with RFC2589. The fact that
> nobody complained up to now indicates that strict adherence to
> specs usually helps in code portability.
Yeah. But I didn't know that RFC2589 is used inside back_<whatever>.
Now I am aware of that and I really thanks about your help and your
kindness to take some time to find where my error was.
Maybe a little not in slapd-perl man page that entry sent to openldap
have to conform to RFC2589 should be a point to avoid such loss of time.
Thanks again, and this bug is closed for me.
/Xavier
--Apple-Mail-13-1003230263
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w
ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA
dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d
yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow
OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js
MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw
DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI
Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3
DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp
b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT
BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz
MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE
CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy
aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN
lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE
7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV
HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7
L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx
FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV
BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv
b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2
Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+
CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf
WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G
A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0
MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph
ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ
a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG
SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv
dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd
niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc
0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb
Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E
eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W
7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA
Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp
dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1
ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph
2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv
0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx
ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzQ1NThaMCMGCSqGSIb3DQEJBDEWBBQ9bmnTVofdoSRh
8583ZE8AFNXOujCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL
YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO
MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6
YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0
aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu
bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD
Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAB98WnfO9tT2nVJIJ8FVh9+MiP9A
1tC2CirbtmCIgimXAC9A3briBvInedOr85WLpisE2M+VSmownkh9qkVtyIBdPs/M/7qfqvSD3Rlf
FkEuIBSGKgU1AcYFmN/XoRTtetDnTgZNDe5aIh6rxd0s1juilxMsJiL4iCSBfk4cGVKpxCXsZlAp
3/QfI3yGscc9sZG2MoROANqAo6JU6vg6D+obhhXfgQqluahRk4LkPdqlgTVuhdaJADGuvQv0y/fY
UDEYz3X5w5dDJG/HdECrgzPhRLNygcwUqANuUGXDI5vdrBSsmXOb4raeTfR0FSGjVssdPRMx3Nvc
Elughcf1ZlsAAAAAAAA=
--Apple-Mail-13-1003230263--
16 years, 7 months
Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it
Xavier Beaudouin wrote:
> By the way, I still don't understand why this kind of script was working on
> openldap 2.1 and 2.2.... ?
>
> Does str2entry() is more picky since openldap 2.3 ?
The fact that something __worked__ doesn't mean it was correct. That
code working was apparently the consequence of two bugs canceling each
other.
str2entry() is not just more picky: it has been __entirely__ rewritten,
to reduce the performance impact of the related memory allocation, which
guaranteed orders of magnitude of improvement from 2.0 to 2.3 (the
amount of fragmented malloc()s was a considerable bottleneck).
Redesigning code for performance, as well as for stricter adherence to
specs, is part of its natural evolution.
No surprise that such a careful redesign resulted, as a side effect, in
a stricter compliance with RFC2589. The fact that nobody complained up
to now indicates that strict adherence to specs usually helps in code
portability.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net
--Apple-Mail-8-1002308974
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed
Hello,
Le 26 f=E9vr. 07 =E0 09:35, Pierangelo Masarati a =E9crit :
> Xavier Beaudouin wrote:
>
>
>>> Unless you can prove that back-perl LDIF parser doesn't work with
>>> decently
>>> formatted LDIF, I'll consider this ITS closed.
>>
>> It *is* buggy proove me the contrary and be not so arrogant.
>
> OK, I'll be less "arrogant". I've tested back-perl with your script
> corrected, and it works exactly as expected both with OpenLDAP 2.3 and
> with OpenLDAP 2.4. What are corrections?
>
> 1)
>
> <attr>: <value>
>
> 2) eliminate nonsensical "\t" at end of each line. What is really
> offending is the space between "attr" and ":" and the last "\t", while
> the other "\t" seem to be tolerated (I suggest to fix str2entry() in
> order to detect this malformation as well).
>
> It took me 5 minutes to rebuild with back-perl and find the error, and
> it's the first time in my life that I program perl.
Thanks to helped me on that.
You can close the bug and sorry to have bother you for such "easy" fix.
By the way, I still don't understand why this kind of script was =20
working on
openldap 2.1 and 2.2.... ?
Does str2entry() is more picky since openldap 2.3 ?
/Xavier=
--Apple-Mail-8-1002308974
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w
ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA
dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d
yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow
OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js
MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw
DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI
Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3
DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp
b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT
BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz
MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE
CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy
aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN
lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE
7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV
HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7
L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx
FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV
BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv
b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2
Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+
CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf
WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G
A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0
MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph
ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ
a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG
SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv
dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd
niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc
0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb
Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E
eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W
7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA
Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp
dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1
ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph
2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv
0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx
ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzMwMzdaMCMGCSqGSIb3DQEJBDEWBBS7xwRCcJciq2f1
0nv+lAcwXB/WaTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL
YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO
MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6
YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0
aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu
bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD
Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAECl4VHgzjlhaIgC+ynI6fwsEig0
G2rw/NLSqYGw8cLsMx2iqXSnlQWVV8oLUe5gMGHV0eE65yfKx+vnXTUyJnUN08ECvHx+eM4bxxgV
c1cvP6XqqR+nHRUVucriSGrMKqTfI9Qg9DyxPAdF1znIF2TrMwytcVHq+RptaREhEPrpH6+Klnp+
oT9HZwHIRC5tDkZ64uCisHno5QnvwRkT3V2PaSYK5wYtZBHOSchVWWPLeAA9yEzEeMbo07cHWVbj
LAxwKoLF+ckJbQRSjWekQ7YwmOkRGVhb4hjtq17b4f6k3Cs3PSOPBOxhktJtinBgU9wSaBYzR5f3
i66IZQDPpkIAAAAAAAA=
--Apple-Mail-8-1002308974--
16 years, 7 months
Re: (ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com
2.3.34 solves the problem. Thanks.
--
____________________________________
Ulf Möller
Senior Consultant
Secardeo GmbH
Office +49 (0)89 - 18 93 589-5
Fax +49 (0)89 - 18 93 589-9
E-mail ulf.moeller(a)secardeo.com
Secardeo GmbH
Betastrasse 9a
D-85774 Unterföhring
Web http://www.secardeo.de
Geschäftsführer: Dr. Gunnar Jacobson
Amtsgericht München HRB 137969
____________________________________
16 years, 7 months
