[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-2626:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1442325|https://bugzilla.redhat.com/show_bug.cgi?id=1442325] from MODIFIED to ON_QA
> Network interface selection criteria is not working for a duplicate IP addresses but one is down
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2626
> URL: https://issues.jboss.org/browse/WFCORE-2626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
> {code}
> # ip address show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
> valid_lft 3483sec preferred_lft 3483sec
> inet6 fe80::782d:5d87:243d:917f/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens9
> valid_lft forever preferred_lft forever
> 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
> link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens10
> valid_lft forever preferred_lft forever
> {code}
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta16
>
>
> In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above.
> {code}
> <interfaces>
> <interface name="management">
> <up/>
> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
> </interface>
> <interface name="public">
> <up/>
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
> </interface>
> </interfaces>
> {code}
> But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error.
> {code}
> # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1
> ...
> 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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)
> 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-148:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1441890|https://bugzilla.redhat.com/show_bug.cgi?id=1441890] from MODIFIED to ON_QA
> Support suppressed exceptions in log formatting
> -----------------------------------------------
>
> Key: LOGMGR-148
> URL: https://issues.jboss.org/browse/LOGMGR-148
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 1.5.7.Final
>
>
> In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by.
> This JIRA was created to track a back port of the JDK 7 enhancement to support suppressed exceptions to the 1.5.x branch which requires JDK 6. This will introduce a new requirement that the 1.5 branch will require JDK 7 to compile, but will still work on JDK 6.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is not connected" error during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1958?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1958:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1399195|https://bugzilla.redhat.com/show_bug.cgi?id=1399195] from MODIFIED to ON_QA
> RequestCorrelator "channel is not connected" error during shutdown
> ------------------------------------------------------------------
>
> Key: JGRP-1958
> URL: https://issues.jboss.org/browse/JGRP-1958
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.5
>
>
> Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:
> ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> [incoming JGroups message]
> It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
> It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2894) Authentication with context defined in outbound connection with non-http-remoting protocol always fails unless it is Elytron default
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2894?page=com.atlassian.jira.plugi... ]
Farah Juma moved JBEAP-11258 to WFCORE-2894:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2894 (was: JBEAP-11258)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Remoting
Security
(was: Remoting)
(was: Security)
Affects Version/s: (was: 7.1.0.DR19)
> Authentication with context defined in outbound connection with non-http-remoting protocol always fails unless it is Elytron default
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2894
> URL: https://issues.jboss.org/browse/WFCORE-2894
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
> Labels: eap7.1-rfe-failure
>
> Attempting to authenticate with authentication context defined in remote outbound connection will always fail unless a correct Elytron default context is defined with following security output on client side server:
> {code}13:10:45,693 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:10:45,729 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=127.0.0.1,set-port=4447,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:10:45,756 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:10:45,758 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=127.0.0.1,set-port=4447,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> {code}
> When a correct Elytron default context is defined, security output on client side server is the following:
> {code}13:14:10,571 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:14:10,602 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:14:10,612 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 13:14:10,613 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1204) RealmIdentity should have a three-argument version of getCredential()
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1204?page=com.atlassian.jira.plugin.s... ]
David Lloyd reassigned ELY-1204:
--------------------------------
Assignee: David Lloyd
> RealmIdentity should have a three-argument version of getCredential()
> ---------------------------------------------------------------------
>
> Key: ELY-1204
> URL: https://issues.jboss.org/browse/ELY-1204
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, Realms
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta49
>
>
> {quote}
> I observe that there is no method overload for {{RealmIdentity#getCredential()}} which accepts an {{AlgorithmParameterSpec}} as the {{CredentialSource}} types do. This theoretically limits the range of selectivity of credentials that can be used by a mechanism; though things like salt or nonce are usually derived from the stored credential rather than the other way around, it is possible that there are other parameters which might have an impact on the selection of the appropriate credential (like realm name, as I think this issue is about).
> An appropriate three-argument overload can be added to this interface as a {{default}} method. An additional {{applyToCredential}} method can also be added accordingly. An additional {{getCredentialAcquireSupport}} method should be added as well; though it could be {{default}}, the default implementation would be less than optimal as it would have to delegate to {{getCredential}} to function properly.
> It might be a good idea to add this overload now while the compatibility impact would be minimal; in this case, the new {{getCredentialAcquireSupport}} method would not have to be {{default}} (instead, the two-argument form could be made {{default}} or removed completely in favor of the three-argument version).
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-721) Create a ModelNode to CLI call transformation facility
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-721?page=com.atlassian.jira.plugin... ]
Harald Pehl commented on WFCORE-721:
------------------------------------
This is the very basic / limited ModelNode to CLI transformation we use in HAL:
https://github.com/hal/hal.next/blob/develop/dmr/src/main/java/org/jboss/...
> Create a ModelNode to CLI call transformation facility
> ------------------------------------------------------
>
> Key: WFCORE-721
> URL: https://issues.jboss.org/browse/WFCORE-721
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Ken Wills
>
> Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
> This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
> Future transformations might be:
> - Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
> - Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
> - Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
> - XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
> This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-721) Create a ModelNode to CLI call transformation facility
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-721?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-721:
-----------------------------------------
Possibly the ModelNode to CLI transformation could deal with a few well known commands as well. For example
{code}
{ "operation" => "reload"}
{code}
becomes the CLI "reload" command instead of the "/:reload" low level operation.
Same thing with shutdown.
I'm not suggesting any broadly scoped DMR to high-level-command facility. This is really about the few operations that result in breaking the CLI's connection to the server. The high level CLI commands deal with that properly.
> Create a ModelNode to CLI call transformation facility
> ------------------------------------------------------
>
> Key: WFCORE-721
> URL: https://issues.jboss.org/browse/WFCORE-721
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Ken Wills
>
> Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
> This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
> Future transformations might be:
> - Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
> - Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
> - Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
> - XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
> This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months