March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-348) review server debug-options configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-348?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-348: ------------------------------------ Labels: domain-mode (was: ) > review server debug-options configuration > ----------------------------------------- > > Key: WFCORE-348 > URL: https://issues.jboss.org/browse/WFCORE-348 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Labels: domain-mode > > We need to review the server debug-options configuration, since it's not entirely clear what value is expected. Currently the JVM specific builder is doing additional checks, so that the value passed to the JVM startsWith -X. Which might not be true for all JVMs. > <jvm name="default" debug-enabled="true" debug-options="runjdwp:transport=dt_socket,address=8787,server=y,suspend=n" /> > https://issues.jboss.org/browse/AS7-1606 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1146) Research behavior of fork with ProcessBuilder on modern JVMs

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1146?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1146: ------------------------------------- Labels: domain-mode (was: ) > Research behavior of fork with ProcessBuilder on modern JVMs > ------------------------------------------------------------ > > Key: WFCORE-1146 > URL: https://issues.jboss.org/browse/WFCORE-1146 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: David Lloyd > Labels: domain-mode > > Right now our Process Controller exists for two primary reasons: > # fork() misbehaves for large processes on some OSes, causing leaks or crashes > # if the HC crashes, the PC can respawn it > We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems: > * Linux > * Solaris > * IBM OSes > * Windows > * BSDs > * Mac OS X > Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-359) Failure to start the JVM should trigger a management update plan to rollback

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-359?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-359: ------------------------------------ Labels: domain-mode (was: domain_mode) > Failure to start the JVM should trigger a management update plan to rollback > ---------------------------------------------------------------------------- > > Key: WFCORE-359 > URL: https://issues.jboss.org/browse/WFCORE-359 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Andrig Miller > Labels: domain-mode > > I have come across situations where certain JVM options, typically related to NUMA options, can cause the JVM to segfault. With our domain model, we expose the ability to set the JVM options, so I think this certainly would be a possibility. > So, as we discussed on the Andiamo call today, this type of situation should cause a rollback of the management update plan, if the JVM fails to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-359) Failure to start the JVM should trigger a management update plan to rollback

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-359?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-359: ------------------------------------ Labels: domain_mode (was: ) > Failure to start the JVM should trigger a management update plan to rollback > ---------------------------------------------------------------------------- > > Key: WFCORE-359 > URL: https://issues.jboss.org/browse/WFCORE-359 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Andrig Miller > Labels: domain_mode > > I have come across situations where certain JVM options, typically related to NUMA options, can cause the JVM to segfault. With our domain model, we expose the ability to set the JVM options, so I think this certainly would be a possibility. > So, as we discussed on the Andiamo call today, this type of situation should cause a rollback of the management update plan, if the JVM fails to start. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-674) Unable to configure Krb5LoginModule options in elytron kerberos implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.sy... ] Jan Kalina resolved ELY-674. ---------------------------- Fix Version/s: 1.1.0.Beta29 Resolution: Done > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: ELY-674 > URL: https://issues.jboss.org/browse/ELY-674 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta29 > > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s... > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-674) Unable to configure Krb5LoginModule options in elytron kerberos implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reopened ELY-674: ---------------------------- > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: ELY-674 > URL: https://issues.jboss.org/browse/ELY-674 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s... > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-2518: ------------------------------- Affects Version/s: 3.0.0.Beta7 > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s... > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2518) Unable to configure Krb5LoginModule options in elytron kerberos implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2518?page=com.atlassian.jira.plugi... ] Jan Kalina moved WFLY-7340 to WFCORE-2518: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2518 (was: WFLY-7340) Component/s: Security (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFCORE-2518 > URL: https://issues.jboss.org/browse/WFCORE-2518 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s... > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7340) Unable to configure Krb5LoginModule options in elytron kerberos implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.... ] Jan Kalina reopened WFLY-7340: ------------------------------ > Unable to configure Krb5LoginModule options in elytron kerberos implementation > ------------------------------------------------------------------------------ > > Key: WFLY-7340 > URL: https://issues.jboss.org/browse/WFLY-7340 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... > {code:java} > if (debug) { > options.put("debug", "true"); > } > options.put("principal", principal); > final AppConfigurationEntry ace; > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", isServer ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options); > } else { > options.put("storeKey", "true"); > options.put("useKeyTab", "true"); > options.put("keyTab", keyTab.getAbsolutePath()); > options.put("isInitiator", isServer ? "false" : "true"); > ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options); > } > {code} > ^ GSSCredentialSecurityFactory > * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s... > * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7337) Introduce an authorization SPI

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on WFLY-7337 at 3/10/17 12:38 PM: ------------------------------------------------------------------ [~dmlloyd] This list of requirements refer to state changes for both transactions and resources. Please could provide more detail about why these are needed (preferably on an event by event basis). Also you say that the list is incomplete, do you have a view about which kind of future event may be of interest. And finally how does this requirement relate to WFTC? was (Author: mmusgrov): [~dmlloyd] This list of requirements refer to state changes in a transactions and in resources. Please could provide more detail about why these are needed (preferably on an event by event basis). Also you say that the list is incomplete, do you have a view about which kind of future event may be of interest. > Introduce an authorization SPI > ------------------------------ > > Key: WFLY-7337 > URL: https://issues.jboss.org/browse/WFLY-7337 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 2017