[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack
by Chao Wang (JIRA)
Chao Wang created WFLY-3696:
-------------------------------
Summary: Security domain configuration doesn't allow empty or missing login-module-stack
Key: WFLY-3696
URL: https://issues.jboss.org/browse/WFLY-3696
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.1.0.Final
Reporter: Chao Wang
Assignee: Chao Wang
https://bugzilla.redhat.com/show_bug.cgi?id=901075 description:
project_key: JBPAPP6
Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules.
{code:xml}
<security-domain name="jmx-console" cache-type="default">
<authentication-jaspi>
<!-- FIXME: the not empty login-module-stack must be provided even it's not used -->
<login-module-stack name="lm-stack">
<login-module code="UsersRoles" flag="required"/>
</login-module-stack>
<auth-module code="org.jboss.example.CustomServerAuthModule" flag="required">
<module-option name="option1" value="value1" />
</auth-module>
</authentication-jaspi>
</security-domain>
{code}
It should be possible to remove here the login-module-stack element.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-1706) Clone a profile
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1706?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1706:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125143
> Clone a profile
> ---------------
>
> Key: WFLY-1706
> URL: https://issues.jboss.org/browse/WFLY-1706
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (DROOLS-546) FactType.get/set should throw specific exception (not NPE) for unknown fields
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-546?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-546.
--------------------------------
Fix Version/s: 6.1.0.Final
Resolution: Done
> FactType.get/set should throw specific exception (not NPE) for unknown fields
> -----------------------------------------------------------------------------
>
> Key: DROOLS-546
> URL: https://issues.jboss.org/browse/DROOLS-546
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR1
> Reporter: Benoit Voisin
> Assignee: Mario Fusco
> Fix For: 6.2.0.Beta1, 6.1.0.Final
>
>
> factType.get(instance, "unknownField") is currently throwing an NPE. This gives improper information to the user/developper.
> I propose that it throws a new UnknownFactFieldException giving improved information giving good hints for debugging or enabling specific exception management.
> See pull request for test-case and proposed fix
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1856) FD_ALL should not update all mbrs timestamp in handleViewChange
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1856?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1856:
--------------------------------
Fixed as suggested by Takayoshi, thanks !
> FD_ALL should not update all mbrs timestamp in handleViewChange
> ---------------------------------------------------------------
>
> Key: JGRP-1856
> URL: https://issues.jboss.org/browse/JGRP-1856
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Takayoshi Kimura
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> In large cluster, when multiple instances (e.g. A, B, C, D) gone at once, FD_ALL interval based checker detects first few instances already timed out (e.g. A, B), suspects them and the coord sends a view change.
> In FD_ALL.handleViewChange(), it updates all mbrs timestamps including the rest of dead members (e.g. C, D) and they get extra life until suspect.
> It would be better not to do this so we can expel them sooner.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1855 at 7/31/14 2:17 AM:
---------------------------------------------------------
OK, first impl is done and has been tested with VirtualBox/Fedora 14 instances. The config would look like this:
{code:xml}
<FD_HOST interval="10000" timeout="35000" />
{code}
The current impl uses {{InetAddress.isReachable()}}. Next: include ability to use external commands such as {{/sbin/ping}}.
was (Author: belaban):
OK, first impl is done and has been tested with VirtualBox/Fedora 14 instances. The config would look like this:
{code:xml}
<FD_PING2 interval="10000" timeout="35000" />
{code}
The current impl uses {{InetAddress.isReachable()}}. Next: include ability to use external commands such as {{/sbin/ping}}.
> FD_HOST: host failure detection protocol
> ----------------------------------------
>
> Key: JGRP-1855
> URL: https://issues.jboss.org/browse/JGRP-1855
> Project: JGroups
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
> Features are:
> * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
> ** A structure keeps track of hosts (IP addresses) and members on those hosts
> *** Example
> ||192.168.1.2||192.168.1.3||192.168.1.5||
> |A,B,C|D,E,F|X,Y,Z|
> * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
> * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
> * When an entire host is suspected, we suspect *all* cluster members on it
> ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1855:
---------------------------
Description:
A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
Features are:
* Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
** A structure keeps track of hosts (IP addresses) and members on those hosts
*** Example
||192.168.1.2||192.168.1.3||192.168.1.5||
|A,B,C|D,E,F|X,Y,Z|
* We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
* The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
* When an entire host is suspected, we suspect *all* cluster members on it
** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
was:
A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
Features are:
* Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
** A structure keeps track of hosts (IP addresses) and members on those hosts
*** Example
||192.168.1.2||192.168.1.3||192.168.1.5||
|A,B,C|D,E,F|X,Y,Z|
* We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
* The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
* When an entire host is suspected, we suspect *all* clusters members on it
** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
> FD_HOST: host failure detection protocol
> ----------------------------------------
>
> Key: JGRP-1855
> URL: https://issues.jboss.org/browse/JGRP-1855
> Project: JGroups
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
> Features are:
> * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
> ** A structure keeps track of hosts (IP addresses) and members on those hosts
> *** Example
> ||192.168.1.2||192.168.1.3||192.168.1.5||
> |A,B,C|D,E,F|X,Y,Z|
> * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
> * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
> * When an entire host is suspected, we suspect *all* cluster members on it
> ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
Hmm, I can still not reproduce this. So you didn't use any {{java.net.preferXXX}} system props (which defaults to IPv6).
What was your JGroups config ? And did you set {{jgroups.bind_addr}} ? Seems {{bind_addr}} was set to {{127.0.0.1}} ?
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Eugene Shvartsman (JIRA)
[ https://issues.jboss.org/browse/DROOLS-570?page=com.atlassian.jira.plugin... ]
Eugene Shvartsman updated DROOLS-570:
-------------------------------------
Attachment: tester-module.7z
> Rule inheritance fails when using or pattern binding
> ----------------------------------------------------
>
> Key: DROOLS-570
> URL: https://issues.jboss.org/browse/DROOLS-570
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7 VM. Running drools using a JUnit driver
> Reporter: Eugene Shvartsman
> Assignee: Mark Proctor
> Attachments: tester-module.7z
>
>
> I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
> The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
> I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
> 1. Don't use rule inheritance
> 2. Don't have an or statement
> 3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Eugene Shvartsman (JIRA)
[ https://issues.jboss.org/browse/DROOLS-570?page=com.atlassian.jira.plugin... ]
Eugene Shvartsman updated DROOLS-570:
-------------------------------------
Affects Version/s: 6.0.1.Final
> Rule inheritance fails when using or pattern binding
> ----------------------------------------------------
>
> Key: DROOLS-570
> URL: https://issues.jboss.org/browse/DROOLS-570
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7 VM. Running drools using a JUnit driver
> Reporter: Eugene Shvartsman
> Assignee: Mark Proctor
> Attachments: tester-module.7z
>
>
> I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
> The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
> I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
> 1. Don't use rule inheritance
> 2. Don't have an or statement
> 3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Eugene Shvartsman (JIRA)
Eugene Shvartsman created DROOLS-570:
----------------------------------------
Summary: Rule inheritance fails when using or pattern binding
Key: DROOLS-570
URL: https://issues.jboss.org/browse/DROOLS-570
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows 7 VM. Running drools using a JUnit driver
Reporter: Eugene Shvartsman
Assignee: Mark Proctor
I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
1. Don't use rule inheritance
2. Don't have an or statement
3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months