[JBoss JIRA] (WFCORE-330) No Spaces Allowed in Host -> Name, but ' do work, odd
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-330?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-330:
------------------------------------
Labels: domain-mode eap6-ux (was: eap6-ux)
> No Spaces Allowed in Host -> Name, but ' do work, odd
> -----------------------------------------------------
>
> Key: WFCORE-330
> URL: https://issues.jboss.org/browse/WFCORE-330
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jim Tyrrell
> Labels: domain-mode, eap6-ux
>
> For some reason spaces do not seem to be allowed, but an Apostrophe seems to be okay.
> [Host Controller] 20:56:20,250 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.IllegalArgumentException: JBAS014719: Invalid value specification Jim's Most_Excellent_Domain_Ever_so_here
> Would be nice if the error message would kick out what values are acceptable?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1145:
-------------------------------------
Affects Version/s: (was: domain-mode)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron, domain-mode
> Fix For: 3.0.0.Beta8
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-583:
------------------------------------
Labels: domain-mode (was: )
> Think about interactive slave domain controller registration.
> -------------------------------------------------------------
>
> Key: WFCORE-583
> URL: https://issues.jboss.org/browse/WFCORE-583
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: domain-mode
> Fix For: 4.0.0.Beta1
>
>
> We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.
> As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.
> - Start slave domain controller disconnected.
> - Start CLI and connect to slave using local auth.
> - Execute join-domain(hostname, port)
> At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.
> Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.
> The slave process generates a public and private key and with interaction with the administrator a certificate signing request.
> The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.
> The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.
> Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.
> This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.
> Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1145:
-------------------------------------
Labels: affects_elytron domain-mode (was: affects_elytron)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron, domain-mode
> Fix For: 3.0.0.Beta8
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-583:
------------------------------------
Affects Version/s: (was: domain-mode)
> Think about interactive slave domain controller registration.
> -------------------------------------------------------------
>
> Key: WFCORE-583
> URL: https://issues.jboss.org/browse/WFCORE-583
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: domain-mode
> Fix For: 4.0.0.Beta1
>
>
> We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.
> As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.
> - Start slave domain controller disconnected.
> - Start CLI and connect to slave using local auth.
> - Execute join-domain(hostname, port)
> At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.
> Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.
> The slave process generates a public and private key and with interaction with the administrator a certificate signing request.
> The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.
> The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.
> Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.
> This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.
> Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-81:
-----------------------------------
Affects Version/s: (was: domain-mode)
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Rupp
> Assignee: ehsavoie Hugonnet
> Labels: domain-mode, rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-81:
-----------------------------------
Labels: domain-mode rhq (was: rhq)
> Expose address of DC as runtime attributes on the HC
> ----------------------------------------------------
>
> Key: WFCORE-81
> URL: https://issues.jboss.org/browse/WFCORE-81
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Rupp
> Assignee: ehsavoie Hugonnet
> Labels: domain-mode, rhq
>
> Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime.
> 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined
> [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute
> [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC
> [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well
> [17:04:51] <+bstansberry> yes please
> [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute
> 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address
> [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-405:
------------------------------------
Labels: domain-mode (was: )
> Filesystem deployment scanner for a managed domain
> --------------------------------------------------
>
> Key: WFCORE-405
> URL: https://issues.jboss.org/browse/WFCORE-405
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Deployment Scanner, Domain Management
> Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final
> Reporter: hitesh yadav
> Labels: domain-mode
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node.
> For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group .....
> Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group .............
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-405) Filesystem deployment scanner for a managed domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-405?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-405:
------------------------------------
Issue Type: Feature Request (was: Enhancement)
> Filesystem deployment scanner for a managed domain
> --------------------------------------------------
>
> Key: WFCORE-405
> URL: https://issues.jboss.org/browse/WFCORE-405
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Deployment Scanner, Domain Management
> Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final
> Reporter: hitesh yadav
> Labels: domain-mode
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node.
> For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group .....
> Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group .............
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-291) Handle mixed-domain transformation use cases involving splitting out new subsystems
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-291?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-291:
------------------------------------
Labels: domain-mode (was: )
> Handle mixed-domain transformation use cases involving splitting out new subsystems
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-291
> URL: https://issues.jboss.org/browse/WFCORE-291
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> This may end up needing subtasks.
> We need to be able to handle the mixed-domain transformation issues that arise when a subsystem is split out from a previously existing subsystem.
> 1) The registering slave will have no version info for the new subsystem. The new subsystem needs to be able to register a transformer for the logical equivalent of the 'null' version.
> 2) It needs to be possible to register a discard for the root resource of a subsystem. For example, when jsf was split out, the presence of the subsystem was equivalent to the default behavior of the legacy 'web' subsystem, so jsf could just be discarded.
> 3) It needs to be possible for one subsystem to issue a reject transformation if the another subsystem is not configured. For example, when jsf was split out it would have been valid for a reject transformation to have been applied by web if the jsf subsystem was not present, since the legacy slave will have jsf. (It's ok this reject wasn't done; I'm just using jsf/web as an example.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month