February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6233) Format IPv6 addresses with ports in log messages as recommended by rfc5952

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6233?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6233: --------------------------------- Summary: Format IPv6 addresses with ports in log messages as recommended by rfc5952 (was: Format IPv6 addresses in log messages as recommended by rfc5952) Right, clarified in the Jira summary. The problematic log lines I have in mind all include port numbers and thus suffer on readability (not as much from ambiguity since they dont use the :: format). > Format IPv6 addresses with ports in log messages as recommended by rfc5952 > -------------------------------------------------------------------------- > > Key: WFLY-6233 > URL: https://issues.jboss.org/browse/WFLY-6233 > Project: WildFly > Issue Type: Enhancement > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. > {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} > e.g. > {noformat}INFO [org.jboss.modcluster] (ServerService Thread Pool -- 65) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432{noformat} > {noformat}INFO [io.undertow] (MSC service thread 1-1) UT005039: Undertow starts mod_cluster proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432 with frequency 10000 ms > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6233) Format IPv6 addresses in log messages as recommended by rfc5952

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6233?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-6233: ----------------------------------- Note that this applies specifically where IPv6 addresses are presented in combination with port numbers. > Format IPv6 addresses in log messages as recommended by rfc5952 > --------------------------------------------------------------- > > Key: WFLY-6233 > URL: https://issues.jboss.org/browse/WFLY-6233 > Project: WildFly > Issue Type: Enhancement > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. > {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} > e.g. > {noformat}INFO [org.jboss.modcluster] (ServerService Thread Pool -- 65) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432{noformat} > {noformat}INFO [io.undertow] (MSC service thread 1-1) UT005039: Undertow starts mod_cluster proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432 with frequency 10000 ms > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1377: ------------------------------------------ No, because the way of creating the operation node was not correct. It should have been: operation.get(OP_ADDR).set(addr); set not add Your addr node was of ModelType.LIST. When you called add instead of set you created another list with a single element, itself a list. > WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API > ----------------------------------------------------------------------- > > Key: WFCORE-1377 > URL: https://issues.jboss.org/browse/WFCORE-1377 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Choma > Assignee: Brian Stansberry > > Unable to get server-state using http management API > {noformat} > [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Tue, 16 Feb 2016 08:09:39 GMT > HTTP/1.1 500 Internal Server Error > Connection: keep-alive > Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 131 > Date: Tue, 16 Feb 2016 08:09:39 GMT > { > "outcome" : "failed", > "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'", > "rolled-back" : true > {noformat} > Running analogous CLI command works OK. > {noformat} > [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state) > { > "outcome" => "success", > "result" => "running" > } > {noformat} > Can't get server status neither with > {noformat} > curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin > ... > "WFLYCTL0201: Unknown attribute 'status'" > {noformat} > Issue can be seen in EAP 6, as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6234) Undertow mod_cluster should use multicast port from socket binding

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6234: ------------------------------------ Summary: Undertow mod_cluster should use multicast port from socket binding Key: WFLY-6234 URL: https://issues.jboss.org/browse/WFLY-6234 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Stuart Douglas Currently uses org.jboss.as.network.SocketBinding#getPort -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6234) Undertow mod_cluster should use multicast port from socket binding

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6234?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6234: --------------------------------- Issue Type: Bug (was: Enhancement) > Undertow mod_cluster should use multicast port from socket binding > ------------------------------------------------------------------ > > Key: WFLY-6234 > URL: https://issues.jboss.org/browse/WFLY-6234 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Stuart Douglas > > Currently uses org.jboss.as.network.SocketBinding#getPort -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6234) Undertow mod_cluster should use multicast port from socket binding

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6234?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-6234: ------------------------------------ Assignee: Radoslav Husar (was: Stuart Douglas) > Undertow mod_cluster should use multicast port from socket binding > ------------------------------------------------------------------ > > Key: WFLY-6234 > URL: https://issues.jboss.org/browse/WFLY-6234 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Currently uses org.jboss.as.network.SocketBinding#getPort -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6233) Format IPv6 addresses in log messages as recommended by rfc5952

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6233?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6233: --------------------------------- Description: Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} e.g. {noformat}INFO [org.jboss.modcluster] (ServerService Thread Pool -- 65) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432{noformat} {noformat}INFO [io.undertow] (MSC service thread 1-1) UT005039: Undertow starts mod_cluster proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432 with frequency 10000 ms {noformat} was: Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} > Format IPv6 addresses in log messages as recommended by rfc5952 > --------------------------------------------------------------- > > Key: WFLY-6233 > URL: https://issues.jboss.org/browse/WFLY-6233 > Project: WildFly > Issue Type: Enhancement > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. > {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} > e.g. > {noformat}INFO [org.jboss.modcluster] (ServerService Thread Pool -- 65) MODCLUSTER000032: Listening to proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432{noformat} > {noformat}INFO [io.undertow] (MSC service thread 1-1) UT005039: Undertow starts mod_cluster proxy advertisements on /ff0e:0:0:0:0:0:0:a:35432 with frequency 10000 ms > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6233) Format IPv6 addresses in log messages as recommended by rfc5952

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6233: ------------------------------------ Summary: Format IPv6 addresses in log messages as recommended by rfc5952 Key: WFLY-6233 URL: https://issues.jboss.org/browse/WFLY-6233 Project: WildFly Issue Type: Enhancement Components: Clustering, Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor Doesn't seem to be a violation but per https://tools.ietf.org/html/rfc5952#section-6 a general recommendation to use [ .. ] format. {noformat}The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified.{noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on SECURITY-921: ------------------------------------------- I don't think this is the correct fix. As mechTypes are the mechanisms from the client in descending priority order and as mechToken is the token being optimistically being sent from the client the assumption is that this would be the clients preferred token type. As the most preferred mechType is not our most preferred mech type the client is asked to send our most preferred mechType so possibly there is a bug in the message we are sending to the client which is why it can not respond - alternatively although the client has claimed it can support the type we want when challenged it decides it does not want to after all. I would suggest some detailed Wireshark traces to see if there is a problem with the message we are sending back as if that is faulty that needs fixing first. Secondly this code change may be working as the actual mechType is 'Windows Kerberos V5' so we may want to check if the first mechType in the list is either of the two variants of Kerberos. I think this proposed change risks the client saying it prefers NTLM and sending in an NTLM token but if it also claims it could support Kerberos then we would attempt to use the NTLM token and not prompt the client to use Kerberos. > 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 > Environment: * > Reporter: Harald Krause > Assignee: Darran Lofthouse > 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 (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ] Martin Choma commented on WFCORE-1377: -------------------------------------- Still one note. This buggy json structure from reproducer was generated with this java code: {code:java} final ModelNode operation = new ModelNode(); operation.get(OP).set(READ_ATTRIBUTE_OPERATION); ModelNode addr = new ModelNode(); addr.add(HOST, host); addr.add(SERVER, server); // When using this, it in constrast generate proper json //operation.get(OP_ADDR).add(HOST, host).add(SERVER, server); operation.get(OP_ADDR).add(addr); operation.get(NAME).set("server-state"); return operation.toJSONString(true); {code} Does it deserve JIRA? > WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API > ----------------------------------------------------------------------- > > Key: WFCORE-1377 > URL: https://issues.jboss.org/browse/WFCORE-1377 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Choma > Assignee: Brian Stansberry > > Unable to get server-state using http management API > {noformat} > [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Tue, 16 Feb 2016 08:09:39 GMT > HTTP/1.1 500 Internal Server Error > Connection: keep-alive > Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 131 > Date: Tue, 16 Feb 2016 08:09:39 GMT > { > "outcome" : "failed", > "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'", > "rolled-back" : true > {noformat} > Running analogous CLI command works OK. > {noformat} > [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state) > { > "outcome" => "success", > "result" => "running" > } > {noformat} > Can't get server status neither with > {noformat} > curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin > ... > "WFLYCTL0201: Unknown attribute 'status'" > {noformat} > Issue can be seen in EAP 6, as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

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 February 2016