[JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2348?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2348:
------------------------------------------
There is no downstream dependency here. These files are not used in EAP. There is no docs/contrib folder in the EAP distribution.
> Error while starting WildFly as service in domain mode using init scripts.
> --------------------------------------------------------------------------
>
> Key: WFCORE-2348
> URL: https://issues.jboss.org/browse/WFCORE-2348
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 3.0.0.Beta7
> Environment: Fedora, RHEL
> Reporter: Radovan Stancel
> Assignee: Radovan Stancel
> Priority: Minor
> Labels: downstream_dependency
> Original Estimate: 4 hours
> Time Spent: 3 hours
> Remaining Estimate: 1 hour
>
> When starting WildFly as a service in domain mode using init scripts there appears in console.log error:
> /usr/bin/dirname: unrecognized option '--domain-config=domain.xml'
> Try '/usr/bin/dirname --help' for more information.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-9300 to WFCORE-2360:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2360 (was: JBEAP-9300)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
(was: User Experience)
Affects Version/s: 3.0.0.Beta6
(was: 7.1.0.DR13)
> Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2360
> URL: https://issues.jboss.org/browse/WFCORE-2360
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta6
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI:
> {code}[domain@localhost:9990 /] /host=hc1/server-config=server-two:remove()
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}},
> "rolled-back" => true
> }
> {code}
> This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative:
> {code}[domain@localhost:9990 /] /host=master/server-config=server-two:remove()
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2360:
-------------------------------------
Affects Version/s: (was: 3.0.0.Beta6)
> Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2360
> URL: https://issues.jboss.org/browse/WFCORE-2360
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
>
> When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI:
> {code}[domain@localhost:9990 /] /host=hc1/server-config=server-two:remove()
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}},
> "rolled-back" => true
> }
> {code}
> This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative:
> {code}[domain@localhost:9990 /] /host=master/server-config=server-two:remove()
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Radovan Netuka (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Radovan Netuka commented on SECURITY-921:
-----------------------------------------
PR for 2.3.x: https://github.com/wildfly-security/jboss-negotiation/pull/35
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final
> Environment: *
> Reporter: Harald Krause
> Assignee: Radovan Netuka
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Radovan Netuka (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Radovan Netuka updated SECURITY-921:
------------------------------------
Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/35
Affects Version/s: Negotiation_2_3_11_Final
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final
> Environment: *
> Reporter: Harald Krause
> Assignee: Radovan Netuka
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months