[JBoss JIRA] (WFCORE-200) Ability to launch server instances under different Linux cgroups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-200?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-200:
------------------------------------
Labels: domain-mode (was: )
> Ability to launch server instances under different Linux cgroups
> ----------------------------------------------------------------
>
> Key: WFCORE-200
> URL: https://issues.jboss.org/browse/WFCORE-200
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Linux specific
> Reporter: James Livingston
> Labels: domain-mode
>
> Linux supports 'cgroups' which allows certain limitations to be applied to a group of processes, such as binding to specific CPU cores or apply CPU usage limits. It would be nice to be able to have a server group or specific server to be launched under a different cgroup so that more fine grained limits can be applied than to the whole host. Obviously this would be Linux specific.
> If the cgexec command is available, using "cgexec -g cpu:groupname java ..." rather than "java ..." allows the running of the process under a different cpu cgroup. It should be possible to do this now by pointing it to a shell script rather than the actual java executable, and having the script identify the server from arguments, and then invoking the real java executable via cgexec.
> The 'cgexec' tool uses the native code cglib, but I believe that if we just need to put processes under a control group, it is very simple -
> just write the process ID to /sys/fs/cgroup/HIERARCHY/GROUPNAME/tasks (where HIERARCHY is 'cpu', 'cpu,cpuacct' or other appropriate thing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[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: 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
> Affects Versions: domain-mode
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> 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, 2 months
[JBoss JIRA] (WFCORE-494) Timestamped GC logs in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-494?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-494:
------------------------------------
Labels: domain-mode (was: )
> Timestamped GC logs in domain mode
> ----------------------------------
>
> Key: WFCORE-494
> URL: https://issues.jboss.org/browse/WFCORE-494
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: James Livingston
> Labels: domain-mode
>
> In standalone mode, you can add "-Xloggc:gc.log.`date +%Y%m%d%H%M%S`" (or Windows equivalent batch scripting) to have timestamped GC logs which is useful to prevent them from being overwritten when a server is restarted. This does not work in domain mode, since JBoss obviously does not process the back-ticks like a shell interpreter.
> It would be useful to be able to get time-stamped gc logs in domain mode.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[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: 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
> Affects Versions: domain-mode
> Reporter: Heiko Rupp
> Assignee: ehsavoie Hugonnet
> Labels: 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, 2 months
[JBoss JIRA] (WFCORE-1099) Utility to report on differences in domain configuration between domains
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1099?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1099:
-------------------------------------
Labels: domain-mode (was: )
> Utility to report on differences in domain configuration between domains
> ------------------------------------------------------------------------
>
> Key: WFCORE-1099
> URL: https://issues.jboss.org/browse/WFCORE-1099
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> One of the motivations for the domain controller was to help customers manage drift in their JBoss configurations. Because of operational concerns, specifically datacenter isolation, some customers expect to need to run multiple identical domain controllers. They would then still be faced with drift across domain controllers. A utility to detect this drift would be helpful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[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: 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
> Affects Versions: domain-mode
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> 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, 2 months
[JBoss JIRA] (WFCORE-343) Trailing forgotten --> does not generate a good error message on host.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-343?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-343:
------------------------------------
Affects Version/s: domain-mode
> Trailing forgotten --> does not generate a good error message on host.xml
> -------------------------------------------------------------------------
>
> Key: WFCORE-343
> URL: https://issues.jboss.org/browse/WFCORE-343
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: domain-mode
> Reporter: Jim Tyrrell
> Labels: eap6-ux
>
> This snippet from the host.xml file, note the --> that was forgotten to be removed in the remote line...
> <domain-controller>
> <!--<local/>-->
> <!-- Alternative remote domain controller configuration with a host and$
> <remote host="127.0.0.1" port="9999"/>-->
> </domain-controller>
> Generates this error message:
> [Host Controller] 21:24:51,341 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> Several lines further down...you get this message...
> [Host Controller] Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
> [Host Controller] at [row,col {unknown-source}]: [44,4]
> It would be nice if the first error message in an XML parsing error would just show me the place it failed, along with maybe the prior line.
> Less nice would be the 44,4 to be in the first message and break it down as line 44, character 4. More verbosity would be nice.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months