March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6278) Expose client socket binding config through CLI connect configs

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6278?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6278: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Expose client socket binding config through CLI connect configs > --------------------------------------------------------------- > > Key: AS7-6278 > URL: https://issues.jboss.org/browse/AS7-6278 > Project: Application Server 7 > Issue Type: Sub-task > Components: CLI > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Alpha1 > > > Once AS7-6277 is done, continue exposing the client bind socket config to CLI users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-4676) Support Password Stacking for Domain HTTP Server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4676?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4676: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Support Password Stacking for Domain HTTP Server > ------------------------------------------------ > > Key: AS7-4676 > URL: https://issues.jboss.org/browse/AS7-4676 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Jess Sightler > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > Our clients need the ability to restrict logins by client certificate, and by a role stored within an LDAP server. Ideally, the system would support some form of password-stacking feature to allow access based upon a combination of authentication systems. > Cf, http://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/Usin... for how this is implemented in existing EAP5 installations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-4838) Real time updates to truststore within security realms.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4838?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4838: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Real time updates to truststore within security realms. > ------------------------------------------------------- > > Key: AS7-4838 > URL: https://issues.jboss.org/browse/AS7-4838 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > Within the CLI we already have an example of how the trust store can be updated during runtime - we should update the use of a trust store within the security realms so that updates can be picked up at runtime, this could either be the addition or removal of certificates. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-2254) Point to explicit security doc in server.log

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-2254?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-2254: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Point to explicit security doc in server.log > -------------------------------------------- > > Key: AS7-2254 > URL: https://issues.jboss.org/browse/AS7-2254 > Project: Application Server 7 > Issue Type: Enhancement > Components: Server > Affects Versions: 7.1.0.Alpha1 > Environment: Thinkpad T510 w/ 4 cores, 8Gb, running CSB > Reporter: Chuck Mosher > Assignee: Darran Lofthouse > Priority: Minor > Labels: eap6-ux > Fix For: 8.0.0.Alpha1 > > > Nice to warn me (in the server.log) that I have a security issue due to the cluster admin/user pwd using the defaults. Warning tells me to look at the docs; would it be possible to put it the hyperlink to the specific doc? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5359) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5359?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5359: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error) > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: AS7-5359 > URL: https://issues.jboss.org/browse/AS7-5359 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Pavel Janousek > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as: > {code} > <server xmlns="urn:jboss:domain:1.3"> > {code} > The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd. > The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public"> > <any-ipv4-address /> > </interface>{code} > The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too! > With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5360) CLONE - Config. XML with <interface ...><any-ipv6-address /></interface> + -Djava.net.preferIPv4Stack=true (default setting) produces mess error message

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5360?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5360: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > CLONE - Config. XML with <interface ...><any-ipv6-address /></interface> + -Djava.net.preferIPv4Stack=true (default setting) produces mess error message > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: AS7-5360 > URL: https://issues.jboss.org/browse/AS7-5360 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Pavel Janousek > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as: > {code} > <server xmlns="urn:jboss:domain:1.3"> > {code} > The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd. > The very common Linux system has implemented and enabled dualstack in these days. If we instruct EAP instance to bind to +any+ IPv6 address via {code}<interface name="public"> > <any-ipv6-address /> > </interface>{code} > The real result is mess messages to output log:{code} > 08:17:55,779 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Error initializing endpoint: java.net.SocketException: Protocol family unavailable > at java.net.PlainSocketImpl.socketBind(Native Method) [rt.jar:1.6.0_30] > at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [rt.jar:1.6.0_30] > at java.net.ServerSocket.bind(ServerSocket.java:328) [rt.jar:1.6.0_30] > at java.net.ServerSocket.<init>(ServerSocket.java:194) [rt.jar:1.6.0_30] > at org.apache.tomcat.util.net.DefaultServerSocketFactory.createSocket(DefaultServerSocketFactory.java:56) [jbossweb-7.0.15.Final-redhat-0-todo.jar:] > at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:978) [jbossweb-7.0.15.Final-redhat-0-todo.jar:] > at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:190) [jbossweb-7.0.15.Final-redhat-0-todo.jar:] > at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.0.15.Final-redhat-0-todo.jar:] > at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:267) [jboss-as-web-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > 08:17:55,828 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.web.connector.http: org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector > at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:271) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > Caused by: LifecycleException: Protocol handler initialization failed: java.net.SocketException: Protocol family unavailable > at org.apache.catalina.connector.Connector.init(Connector.java:985) > at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:267) > ... 5 more > 08:17:55,999 WARN [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012210: Unable to use InetAddress.getLocalHost() to resolve address. > 08:17:56,294 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.0.3.GA-redhat-1 > 08:17:56,294 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS] > 08:17:56,904 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /home/hudson/users-tmp/pjanouse/jboss-eap-6.0/standalone/deployments > 08:17:56,918 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on /127.0.0.1:9999 > 08:17:56,953 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.remoting.server.remoting-connector: org.jboss.msc.service.StartException in service jboss.remoting.server.remoting-connector: JBAS017113: Failed to start service > at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind(Native Method) [rt.jar:1.6.0_30] > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [rt.jar:1.6.0_30] > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [rt.jar:1.6.0_30] > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) [rt.jar:1.6.0_30] > at org.xnio.nio.NioXnioWorker.createTcpServer(NioXnioWorker.java:287) > at org.xnio.XnioWorker.createStreamServer(XnioWorker.java:135) > at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:209) > at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:101) > ... 5 more > 08:17:57,611 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.remoting.server.remoting-connector: org.jboss.msc.service.StartException in service jboss.remoting.server.remoting-connector: JBAS017113: Failed to start service > service jboss.web.connector.http: org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector > {code} > The valid result message could be only - there isn't available any IPv6 address when IPv6 is disabled. Or there isn't a such IP address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-4551) Force container to settle before returning from rollback management ops

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4551?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4551: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Force container to settle before returning from rollback management ops > ----------------------------------------------------------------------- > > Key: AS7-4551 > URL: https://issues.jboss.org/browse/AS7-4551 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > When an operation fails and triggers rollback, the service container gets modified on the return path of the operation. But the operation does not wait for the container to settle before returning. This is the source of intermittent failures in org.jboss.as.controller.ModelControllerImplUnitTestCase.testRemoveDependentService -- the test checks container state that may not yet be settled. > This task is to investigate forcing the container state to settle before releasing the controller lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6269) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6269?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6269: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Consider using a "describe" notion for providing the model to slaves on registration > ------------------------------------------------------------------------------------ > > Key: AS7-6269 > URL: https://issues.jboss.org/browse/AS7-6269 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave. > Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC. > This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6277) Expose mgmt client socket binding config through ModelControllerClient Factory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6277?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6277: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Expose mgmt client socket binding config through ModelControllerClient Factory > ------------------------------------------------------------------------------ > > Key: AS7-6277 > URL: https://issues.jboss.org/browse/AS7-6277 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > Parent task used a secret system property to configure this to support Open Shift's immediate need, but proper configuration is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-639) Common mechanism for all secure socket definitions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-639?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry updated AS7-639: --------------------------------- Fix Version/s: (was: 7.3.0.Alpha1) > Common mechanism for all secure socket definitions > -------------------------------------------------- > > Key: AS7-639 > URL: https://issues.jboss.org/browse/AS7-639 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > > This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: > >> The JAASSecurityDomain in my opinion should > >> handle all secure socket definitions. Mod-cluster currently does > >> not support JAASSecurityDomains. > I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013