[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan commented on WFCORE-433:
---------------------------------------
BTW we have an implementation of a reusable microservice or command for automatically upgrading the git commit sha used to provide configuration files from git in kubernetes here:
https://github.com/fabric8io/gitcontroller
This lets you mount configuration files to a volume in kubernetes; such as this example:
https://github.com/jstrachan/springboot-config-demo/blob/master/src/main/...
so provided the standalone.xml files or whatever are stored in git; it'd be easy to use them in an EAP/wildfly/wildfly swarm docker image. The only thing to watch with gitRepo volumes with kubernetes is to ensure that the configuration files are mounted to a folder that your microservice can then read them from (and you don't try and mix and match the same folder for configuration and secrets/code).
There's more detail on the configuration tradeoffs of microservices on kubernetes here:
http://fabric8.io/guide/develop/configuration.html
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6660:
-----------------------------------
I'm not sure about that: the Artemis command has this warning: "Print data records information (WARNING: don't use while a production server is running)"
[~ataylor] would it be "safe" to execute this command on a running Artemis server or should it be allowed only on admin-only server (ie no Artemis runtime)?
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBJCA-1320) Unable to create JDBC local datasource without properties on JBoss EAP 7
by ted won (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1320?page=com.atlassian.jira.plugin... ]
ted won updated JBJCA-1320:
---------------------------
Description:
It should display warning message than throwing error as [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 or creating non-XA datasource for using local transactions in JBoss EAP 7.
In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but not EAP 7.
was:
It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 or creating non-XA datasource, using local transactions in JBoss EAP 7.
It should display warning message than throwing error like [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but EAP 7.
> Unable to create JDBC local datasource without properties on JBoss EAP 7
> ------------------------------------------------------------------------
>
> Key: JBJCA-1320
> URL: https://issues.jboss.org/browse/JBJCA-1320
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.3.Final
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Attachments: com.msql.tar.gz
>
>
> It should display warning message than throwing error as [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
> It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 or creating non-XA datasource for using local transactions in JBoss EAP 7.
> In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but not EAP 7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6660:
--------------------------------------
Dump to CLI appears to be ok. It's possible to redirect CLI output file like:
{code}[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=DLQ:count-messages > number_of_messages.txt{code}
Also I just figured out that it's possible to dump journal during runtime as well. So admin only mode is not required.
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6660:
-----------------------------------
Artemis API provides only dump to the standard output.
This operation would only dump to the CLI and can not store its output in a file.
[~mnovak] Would you prefer to have the dump stored in a file (this requies a fix in Artemis) or is it acceptable to print the dump?
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-6660:
---------------------------------
Attachment: journal.txt
This dump contains useful information for debugging of issues. It's possible to track which messages were processed in which transaction. Which jms transactions are unfinished and useful info about XA transactions.
I'm attaching dump Artemis journal after one of our tests for review.
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6660:
-----------------------------------
This new operation seems to duplicate the :export-journal operation that provides a XML version of the Artemis files.
Is there anything in that new operation that is not covered by the :export-journal? Otherwise, I don't think it would help much as the output would likely be so huge that users will store it in a file for examination anyway...
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6644) Provide container managed sign on in configuration of pooled-connection-factory
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6644?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-6644:
---------------------------------
Description:
Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
Such security-domain could look like:
{code}<security-domain name="CrashRecoveryDomain0">
<authentication>
<login-module code="ConfiguredIdentity" flag="required">
<module-option name="principal" value="crash0"/>
<module-option name="password" value="crash0"/>
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="userName" value="crash0"/>
</login-module>
</authentication>
</security-domain>{code}
The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
[1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
was:
Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
Such security-domain could look like:
<security-domain name="CrashRecoveryDomain0">
<authentication>
<login-module code="ConfiguredIdentity" flag="required">
<module-option name="principal" value="crash0"/>
<module-option name="password" value="crash0"/>
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="userName" value="crash0"/>
</login-module>
</authentication>
</security-domain>
The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
[1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
> Provide container managed sign on in configuration of pooled-connection-factory
> -------------------------------------------------------------------------------
>
> Key: WFLY-6644
> URL: https://issues.jboss.org/browse/WFLY-6644
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
> Such security-domain could look like:
> {code}<security-domain name="CrashRecoveryDomain0">
> <authentication>
> <login-module code="ConfiguredIdentity" flag="required">
> <module-option name="principal" value="crash0"/>
> <module-option name="password" value="crash0"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="userName" value="crash0"/>
> </login-module>
> </authentication>
> </security-domain>{code}
> The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
> [1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-553) Make use of realm events to handle OTP timeout updates
by Farah Juma (JIRA)
Farah Juma created ELY-553:
------------------------------
Summary: Make use of realm events to handle OTP timeout updates
Key: ELY-553
URL: https://issues.jboss.org/browse/ELY-553
Project: WildFly Elytron
Issue Type: Feature Request
Components: SASL
Reporter: Farah Juma
Assignee: Farah Juma
For the OTP SASL mechanism, we need to protect against race attacks, as described in [RFC 2289|https://tools.ietf.org/html/rfc2289#section-9.0]. The approach {{OTPSaslServer}} [currently takes|https://github.com/wildfly-security/wildfly-elytron/blob/master/src...] to defend against such attacks is the one suggested in RFC 2289, i.e., we prevent multiple simultaneous authentication sessions for a user. This means that once a legitimate user has started the authentication process, an attacker would be blocked until that first authentication process finishes. With this approach, a timeout is needed in order to prevent a denial of service attack. We could store the timeout info for a user via a {{RealmIdentity}} attribute as in [PR #277|https://github.com/wildfly-security/wildfly-elytron/pull/277]. We could then add support for a new event that indicates a timeout attribute change for a realm identity and then handle a {{TimeoutUpdateCallback}} by handling this new event.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6192:
--------------------------------------
The reason is because it is public it would allow any code to access field reflection. I think the correct fix is to move the privileged block into whatever actually creates this class.
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months