[JBoss JIRA] (WFLY-6780) could not spécify version 3 for ldap connection
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6780?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-6780:
------------------------------
Component/s: Security
> could not spécify version 3 for ldap connection
> -----------------------------------------------
>
> Key: WFLY-6780
> URL: https://issues.jboss.org/browse/WFLY-6780
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: cyril leclerc
> Assignee: Jason Greene
>
> HI,
> in case of using LDAPExtLoginModule and ldap realm if in active directory there is more than 1000 groups it returns an error :
> Caused by: javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name 'CN=Users,DC=realad,DC=ad'
> i can't change in AD the MAXPAGESIZE parameter and i can't specify the module to use version 3 of ldap how i can do ?
> it is a big issue for me -)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
To answer to your question about our using the old version of wildfly, we have this already in production and at that time we used the version that was available. We are considering to upgrade to new version in near future.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
That was a good explanation. Thanks Paul. Never knew about the loopback interface before while I was configuring.
We have this configuration in our domain.xml
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:10.76.82.121}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:10.76.82.121}"/>
</interface>
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:10.76.82.121}"/>
</interface>
</interfaces>
where the bind-address is the ip-address of the VM.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6680:
--------------------------------
Labels: downstream_dependency (was: )
> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6680
> URL: https://issues.jboss.org/browse/WFLY-6680
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch,
> Reporter: Kristina Clair
> Assignee: Radoslav Husar
> Labels: downstream_dependency
> Fix For: 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host:
> {noformat}
> [domain@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-info
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (ELY-583) Add ability for outbound clients to directly consume IdentityCredentials
by David Lloyd (JIRA)
David Lloyd created ELY-583:
-------------------------------
Summary: Add ability for outbound clients to directly consume IdentityCredentials
Key: ELY-583
URL: https://issues.jboss.org/browse/ELY-583
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.1.0.Beta7
Outbound clients can gain substantial flexibility by being able to use {{IdentityCredentials}} directly. This allows a non-type-specific object like a {{byte[]}} to be interpreted as many different types of credentials.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6781:
------------------------------------
[~kpreeta12] More confusion. A loopback interface is a virtual network interface that your host uses to communicate with itself. When you "disable your host network", you are not actually disabling this interface, but rather your actual network interface (e.g. eth0).
WildFly's default configuration uses this interface for all of its socket bindings. For example, in your configuration, the socket-binding used by the FD_SOCK protocol uses the "jgroups-udp-fd" socket binding. In WF 8.2 (OT: I have to wonder why you have chosen to use an old release), this socket binding uses the default "public" interface, which is defined as:
{code:xml}
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
{code}
So, unless you have started your server using a specific "jboss.bind.address" property, it will use 127.0.0.1, which is the IPv4 loopback address of your host.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2085) IndexOutOfBoundsException when trace logging
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2085?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2085:
---------------------------
Fix Version/s: (was: 4.0)
4.0 doesn't have the issue as size() is not cached in the log stmt
> IndexOutOfBoundsException when trace logging
> --------------------------------------------
>
> Key: JGRP-2085
> URL: https://issues.jboss.org/browse/JGRP-2085
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.9
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11
>
>
> When running with trace logging, I got couple of these STs:
> {code}
> Exception in thread "OOB-1,test-NodeE-13479" java.lang.IndexOutOfBoundsException: Index: 4, Size: 2
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:868)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:705)
> at org.jgroups.stack.Protocol.up(Protocol.java:425)
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1600)
> at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1820)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Seems that part of the list of received messages is removed in handleMessages:864 in
> {code}
> boolean added=loopback || buf.add(msgs, oob, oob? DUMMY_OOB_MSG : null);
> {code}
> But the {{size}} is not recomputed afterwards.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months