ok, you're right Centos 6 has 2.1.23.
cyrus-sasl.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-devel.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-gssapi.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-lib.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-plain.x86_64 2.1.23-15.el6_6.1 @updates
From yum logs this was indeed updated:
Nov 19 21:50:36 Updated: cyrus-sasl-lib-2.1.23-15.el6.x86_64
previously had 2.1.23-13
I give it a try to roll back to the old version (if possible), need some
time for it as I need to ask some experts to do that.
Thanks for the hints on other debugs will give them a try too. I'll
reply back with findings.
On 2015.02.04. 10:35, Sergio Gelato wrote:
* Soós László [2015-02-04 09:54:57 +0100]:
The one referrenced was for openldap 2.1 I have 2.4 installed. Was't
the issue fixed in 2 years? possible.
Not OpenLDAP but Cyrus SASL. The bug was fixed upstream in version 2.1.26
which may or may not have propagated to RHEL6. Of course I cannot be
certain that you're seeing the same problem but it's worth checking.
openldap.x86_64 2.4.39-8.el6 @base
openldap-clients.x86_64 2.4.39-8.el6 @base
openldap-devel.x86_64 2.4.39-8.el6 @base
openldap-servers.x86_64 2.4.39-8.el6 @base
What do you mean ldap server sane? I've got very plane gssapi config
and the exactly same config worked before with the same environment.
If you're sure you haven't upgraded the GSSAPI plugin for libsasl2 on the
server, or enabled TLS, or anything of that sort, then one may have to look
for an alternative explanation.
I just do not know what caused the breakdown as we upgraded more
components in the same time: windows updates; java; on servers end:
yum centos updates
Aha. You did apply CentOS updates on the servers; so it's not quite the same
environment any more, is it?
#GSSAPI
sasl-realm XXX.LAN
sasl-host backend.xxx.lan
#sasl-secprops noplain,noactive,noanonymous
Any hint on how to debug forther would be useful.
If you're using Oracle Java, try OpenJDK instead, just so we're 100% sure that
we have the source code. (I don't expect this to make any difference but it's
good to remove sources of uncertainty.)
Try disabling SSL/TLS (GSSAPI has its own encryption) and see if the problem
persists. (If "my" bug is the culprit the symptoms will probably disappear.)
If the problem does persist, capture the traffic with tcpdump or equivalent
and look at the SASL handshake.
Thank you
On 2015.02.04. 9:03, Sergio Gelato wrote:
* Sergio Gelato [2015-02-04 08:50:47 +0100]:
Which brings us to com.sun.jndi.ldap.sasl.SaslOutputStream.write, where I
have trouble seeing how the length could ever be negative… unless rawSendSize
is negative. The default value of rawSendSize is a safe 65536 but a different
one can be negotiated in the SASL handshake. There ought to be client-side
safeguards too, but is your LDAP server sane?
Following up on myself due to a sensation of déjà vu: could this be the
same problem I reported in https://bugs.debian.org/721010 ?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
Jxplorer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
Jxplorer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
Jxplorer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
Jxplorer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
