April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-821: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1088792|https://bugzilla.redhat.com/show_bug.cgi?id=1088792] from NEW to CLOSED > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6, Negotiation_2_2_8, Negotiation_2_3_1_Final > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3269) XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-3269: -------------------------------------- Summary: XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value. Key: WFLY-3269 URL: https://issues.jboss.org/browse/WFLY-3269 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.1.0.Final {code} Trying so, I run in the error (when starting WildFly) : 10:28:29,674 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[76,25] Message: JBAS014724: Missing required attribute(s): FORCE at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.domain.management.parsing.ManagementXml.parseUsernameToDn_2_0(ManagementXml.java:2118) [wildfly-domain-management-8.0.0.Final.jar:8.0.0.Final] {code} {code} <security-realm name="MgtRealm"> <authentication> <ldap connection="ovodavLDAP" base-dn="ou=People,dc=hydrogenic,dc=local">  <username-filter attribute="uid"/> </ldap> </authentication> <authorization> <ldap connection="ovodavLDAP"> <username-to-dn> <username-filter base-dn="ou=People,dc=hydrogenic,dc=local" recursive="false" attribute="uid" user-dn-attribute="dn" /> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> <group-to-principal base-dn="ou=Groups,dc=hydrogenic,dc=local" recursive="true" search-by="DISTINGUISHED_NAME"> <membership-filter principal-attribute="uniqueMember" /> </group-to-principal> </group-search> </ldap> </authorization> </security-realm> {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3269) XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value.

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3269?page=com.atlassian.jira.plugin.... ] SBS JIRA Integration updated WFLY-3269: --------------------------------------- Forum Reference: https://community.jboss.org/message/869014#869014 > XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value. > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3269 > URL: https://issues.jboss.org/browse/WFLY-3269 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.1.0.Final > > > {code} > Trying so, I run in the error (when starting WildFly) : > 10:28:29,674 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[76,25] > Message: JBAS014724: Missing required attribute(s): FORCE > at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.domain.management.parsing.ManagementXml.parseUsernameToDn_2_0(ManagementXml.java:2118) [wildfly-domain-management-8.0.0.Final.jar:8.0.0.Final] > {code} > {code} > <security-realm name="MgtRealm"> > <authentication> > <ldap connection="ovodavLDAP" base-dn="ou=People,dc=hydrogenic,dc=local"> >  > <username-filter attribute="uid"/> > </ldap> > </authentication> > <authorization> > <ldap connection="ovodavLDAP"> > <username-to-dn> > <username-filter base-dn="ou=People,dc=hydrogenic,dc=local" recursive="false" attribute="uid" user-dn-attribute="dn" /> > </username-to-dn> > <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> > <group-to-principal base-dn="ou=Groups,dc=hydrogenic,dc=local" recursive="true" search-by="DISTINGUISHED_NAME"> > <membership-filter principal-attribute="uniqueMember" /> > </group-to-principal> > </group-search> > </ldap> > </authorization> > </security-realm> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1829) Failing to connect to an unavailable member blocks all message sending

by David Hotham (JIRA)

David Hotham created JGRP-1829: ---------------------------------- Summary: Failing to connect to an unavailable member blocks all message sending Key: JGRP-1829 URL: https://issues.jboss.org/browse/JGRP-1829 Project: JGroups Issue Type: Bug Affects Versions: 3.4.2 Reporter: David Hotham Assignee: Bela Ban Hi, We're seeing a problem which appears to be caused by the TransferQueueBundler thread being blocked while it fails to connect to an unavailable member. The setup we have is a cluster split across two sites: say, members 0 through 4 in site A and members 5 through 9 in site B. Initially the cluster is complete: everyone has the same view. The case that we're testing is: what happens when connectivity is lost between the sites? NB we're using TCP transport. Obviously the expected result is that we'd get two sub-clusters, one in each site. But this doesn't always happen. Instead we sometimes see some members become singletons (that is, with only themselves in view). What seems to be happening is something like this: - When the cross-site link is cut, members in site A suspect members in site B (and vice versa). - So in each site there's a broadcast of SUSPECT messages - Now each of the members in site A tries to VERIFY_SUSPECT each of the members in site B - Each such attempt blocks the TransferQueueBundler for two seconds (TCP's default sock_conn_timeout), because we can't contact any member in the other site - But that introduces a delay for _all_ messages, not only for messages to the 'other' site - If there are enough members in the 'other' site, we can easily get a large enough delay that HEARTBEAT (and then VERIFY_SUSPECT) messages start timing out between members in the same site - At this point, members that ought to be able to see one another start to report that they cannot do so. We've seen cases where a member becomes completely isolated - forming a singleton cluster - and does not recover. Unfortunately we don't have full trace from that run, so it's not clear why the cluster didn't eventually recover. I suspect that we're hitting something like JGRP-1493, in which delays sending messages (in that case, a delay when failing to get a physical address) caused the MergeKiller always to prevent merging. It is highly undesirable that when a cluster contains several unavailable members, as in a partition between two sites, this should cause problems for members that can see one another. Should all message sending really be blocked while failing to connect to an unavailable member? This issue seems related also to JGRP-1815 which raises a similar question: should all message sending really be blocked while failing to find a physical address? What do you think? - do you agree that blocking message sending while attempting to connect to an unavailable member is undesirable? - if so, what do you think the right fix is? If it's not too hard, we may be able to find time to take a look at implementing this ourselves. - is there anything else we can do to help progress this issue? We're using JGroups 3.4.2. I've attached the code fragment with which we configure the stack below. Thanks for your help David {noformat} stack.addProtocol((new TCP) .setValue("enable_diagnostics", false) .setValue("logical_addr_cache_max_size", 70) .setValue("logical_addr_cache_expiration", 10000) .setValue("physical_addr_max_fetch_attempts", 1) .setValue("bind_addr", localAddr) .setValue("bind_port", basePort) .setValue("port_range", 0)) val tcpping = new TCPPING val jhosts = initialHosts map { addr => new IpAddress(addr.getHostAddress, basePort) } tcpping.setInitialHosts(jhosts) tcpping.setPortRange(0) tcpping.setValue("return_entire_cache", true) stack.addProtocol(tcpping) .addProtocol(new MERGE3) .addProtocol((new FD_SOCK) .setValue("bind_addr", localAddr) .setValue("client_bind_port", basePort + 1) .setValue("start_port", basePort + 101) .setValue("suspect_msg_interval", 1000)) .addProtocol(new FD) .addProtocol((new VERIFY_SUSPECT) .setValue("timeout", 1000)) .addProtocol((new NAKACK2) .setValue("use_mcast_xmit", false)) .addProtocol(new UNICAST3) .addProtocol(new STABLE) .addProtocol(new MFC) .addProtocol(new SEQUENCER) .addProtocol((new GMS) .setValue("max_join_attempts", 3) .setValue("use_delta_views", false)) .addProtocol(new FRAG2) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3070) The download link for Wildfly at http://www.jboss.org/projects is broken

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-3070: ----------------------------------- properties file is correct, i checked in few different browsers/machines and i see correct link. Also checked on sftp server and it is the same. Do you maybe have some browser cache or similar? > The download link for Wildfly at http://www.jboss.org/projects is broken > ------------------------------------------------------------------------ > > Key: WFLY-3070 > URL: https://issues.jboss.org/browse/WFLY-3070 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Karel Piwko > Assignee: Tomaz Cerar > > The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3268) Stabilize intermittently failing clustering tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3268?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-3268: -------------------------------------- On related node, fixing arquillian defaults: https://github.com/wildfly/wildfly/pull/6179 (note that these are not used in the integration TS). > Stabilize intermittently failing clustering tests > ------------------------------------------------- > > Key: WFLY-3268 > URL: https://issues.jboss.org/browse/WFLY-3268 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 8.1.0.Final > > > Some of the clustering tests > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover > org.jboss.as.test.clustering.cluster.singleton.SingletonTestCase(SYNC-tcp).testSingletonService > are failing due to OOM > ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread-4) ISPN000230: Failed to start rebalance for cache default-host/stateful-failover: java.lang.OutOfMemoryError: unable to create new native thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3268) Stabilize intermittently failing clustering tests

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-3268: ------------------------------------ Summary: Stabilize intermittently failing clustering tests Key: WFLY-3268 URL: https://issues.jboss.org/browse/WFLY-3268 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 8.1.0.Final Some of the clustering tests org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover org.jboss.as.test.clustering.cluster.singleton.SingletonTestCase(SYNC-tcp).testSingletonService are failing due to OOM ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread-4) ISPN000230: Failed to start rebalance for cache default-host/stateful-failover: java.lang.OutOfMemoryError: unable to create new native thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3070) The download link for Wildfly at http://www.jboss.org/projects is broken

by David Hladky (JIRA)

[ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.... ] David Hladky reopened WFLY-3070: -------------------------------- I checked the project matrix and it is still wrong. I checked http://wildfly.org/project.properties and the changes were not published. Therefore I am reopening the issue. > The download link for Wildfly at http://www.jboss.org/projects is broken > ------------------------------------------------------------------------ > > Key: WFLY-3070 > URL: https://issues.jboss.org/browse/WFLY-3070 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Karel Piwko > Assignee: Tomaz Cerar > > The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-821: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1088792, https://bugzilla.redhat.com/show_bug.cgi?id=1088793, https://bugzilla.redhat.com/show_bug.cgi?id=1088795 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1088792, https://bugzilla.redhat.com/show_bug.cgi?id=1088793) > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6, Negotiation_2_2_8, Negotiation_2_3_1_Final > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-821: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1088792 > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6, Negotiation_2_2_8, Negotiation_2_3_1_Final > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014