[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)
6 years, 10 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)
6 years, 10 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)
6 years, 10 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)
6 years, 10 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)
6 years, 10 months