May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1550) wildfly-init-redhat.sh script does not work on RHEL 5 OS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1550?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1550: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1328146|https://bugzilla.redhat.com/show_bug.cgi?id=1328146] from MODIFIED to ON_QA > wildfly-init-redhat.sh script does not work on RHEL 5 OS > -------------------------------------------------------- > > Key: WFCORE-1550 > URL: https://issues.jboss.org/browse/WFCORE-1550 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.CR2 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > Fix For: 3.0.0.Alpha2 > > > Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: > grep -o '[0-9]*' $JBOSS_MARKERFILE > This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from MODIFIED to ON_QA > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message "key server is currently not set" should be logged with debug level

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2121: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1380657|https://bugzilla.redhat.com/show_bug.cgi?id=1380657] from MODIFIED to ON_QA > ASYM_ENCRYPT error message "key server is currently not set" should be logged with debug level > ---------------------------------------------------------------------------------------------- > > Key: JGRP-2121 > URL: https://issues.jboss.org/browse/JGRP-2121 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > Priority: Trivial > Fix For: 4.0 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-8631) Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8631?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8631: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1327758|https://bugzilla.redhat.com/show_bug.cgi?id=1327758] from MODIFIED to ON_QA > Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-8631 > URL: https://issues.jboss.org/browse/WFLY-8631 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2647) Add an option to always send the client SSL certificate to LDAP server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2647?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2647: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1327758|https://bugzilla.redhat.com/show_bug.cgi?id=1327758] from MODIFIED to ON_QA > Add an option to always send the client SSL certificate to LDAP server > ---------------------------------------------------------------------- > > Key: WFCORE-2647 > URL: https://issues.jboss.org/browse/WFCORE-2647 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.0.0.Beta18 > > > This is the component issue for https://issues.jboss.org/browse/JBEAP-4439 and https://bugzilla.redhat.com/show_bug.cgi?id=1327758 > The present code in {{LdapConnectionManagerService}} was designed so that the client cert is sent to authenticate the search account but during the username / password verification step, the client cert is not sent. > The present objective is to add an option (that will default to the old behavior) to send the client password also during the username / password verification. > This includes (citing [~dlofthouse]): > * Implement management model based configuration and an implementation for the current version > * Port back to older versions using a system property. > * Forward port the system property to the current version for compatibility. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2678) LDAP credential is revealed when error occurs at startup

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2678?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2678: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1443122|https://bugzilla.redhat.com/show_bug.cgi?id=1443122] from MODIFIED to ON_QA > LDAP credential is revealed when error occurs at startup > -------------------------------------------------------- > > Key: WFCORE-2678 > URL: https://issues.jboss.org/browse/WFCORE-2678 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: - EAP 6.4.13 > Reporter: Hisanobu Okuda > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta16 > > > When an error occurs at startup, LDAP credential is shown in the log file. It should not appear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017