[VOTE] Apache Artemis 1.0.0 (RC2)

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Apache Artemis 1.0.0 (RC2)

Martyn Taylor
Hello all.

I've cut a second release candidate of Apache Artemis 1.0.0 addressing
the initial RC feedback from community members.

This is a first release of the Artemis project with protocol support for
AMQP, STOMP, CORE, HORNETQ and OPENWIRE.

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953 


The binary distributions can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/ 


The source archives can be found here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/ 


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1051/

The source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0

The project website for that version has been staged to:
http://people.apache.org/~martyntaylor/

The vote will remain open for 72 hours.

[ ] +1 approve the release as Apache Artemis 1.0.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my (non-binding) +1

Regards
Martyn
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
-1

Two reasons:

1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients could
connect.
2. The basic NMS OpenWire client fails to connect at all. It is getting
unknown response IDs from the broker. I don't think the OpenWire protocol
is being negotiated correctly. I am running with the latest NMS trunk
version (1.8.0).


On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]> wrote:

> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
> initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support for
> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic


Sent from my iPad

> On May 14, 2015, at 11:05, Jim Gomes <[hidden email]> wrote:
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.

You can specify the host when u create the broker.  I disagree this is a reason.

Just use --host when you create the broker.  Localhost by default is on purpose and I wouldn't change it.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>

That's probably a bug but I wouldn't hold the release on this. Raise the issue and we can fix it on 6.0.1.

>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]> wrote:
>>
>> Hello all.
>>
>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
>> initial RC feedback from community members.
>>
>> This is a first release of the Artemis project with protocol support for
>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.0.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>> Martyn
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Justin Bertram-2
In reply to this post by jgomes
IMO the broker correctly binds to localhost only and does not, by default, allow connections from remote machines.  This is a simple security/sanity measure to prevent access to default (i.e. unsecured) instances.

The merit of this configuration is obviously up for debate, but it's worth noting it was done on purpose.


Justin

----- Original Message -----
From: "Jim Gomes" <[hidden email]>
To: "ActiveMQ Dev" <[hidden email]>
Sent: Thursday, May 14, 2015 10:05:55 AM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

-1

Two reasons:

1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients could
connect.
2. The basic NMS OpenWire client fails to connect at all. It is getting
unknown response IDs from the broker. I don't think the OpenWire protocol
is being negotiated correctly. I am running with the latest NMS trunk
version (1.8.0).


On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]> wrote:

> Hello all.
>
> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
> initial RC feedback from community members.
>
> This is a first release of the Artemis project with protocol support for
> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>
> The binary distributions can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The source archives can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>
> The source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>
> The project website for that version has been staged to:
> http://people.apache.org/~martyntaylor/
>
> The vote will remain open for 72 hours.
>
> [ ] +1 approve the release as Apache Artemis 1.0.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my (non-binding) +1
>
> Regards
> Martyn
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.

Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients.  Here's the server exception being thrown:

ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
    at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]



On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]> wrote:

> IMO the broker correctly binds to localhost only and does not, by default,
> allow connections from remote machines.  This is a simple security/sanity
> measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth
> noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <[hidden email]>
> To: "ActiveMQ Dev" <[hidden email]>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> wrote:
>
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

chirino
In reply to this post by Justin Bertram-2
I'm not sure that's a good default.  ActiveMQ has traditionally
allowed remote access to it's ports.  I think a localhost binding is
fine for things like management ports, but for the main service the
product gives it should be on the public ports.

That would be like tomcat or jetty defaulting to binding it's http
ports to localhost.

On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]> wrote:

> IMO the broker correctly binds to localhost only and does not, by default, allow connections from remote machines.  This is a simple security/sanity measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <[hidden email]>
> To: "ActiveMQ Dev" <[hidden email]>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]> wrote:
>
>> Hello all.
>>
>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing the
>> initial RC feedback from community members.
>>
>> This is a first release of the Artemis project with protocol support for
>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>
>> The release notes can be found here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>
>> The binary distributions can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>
>> The Maven repository is here:
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>
>> The source tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>
>> The project website for that version has been staged to:
>> http://people.apache.org/~martyntaylor/
>>
>> The vote will remain open for 72 hours.
>>
>> [ ] +1 approve the release as Apache Artemis 1.0.0
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here's my (non-binding) +1
>>
>> Regards
>> Martyn
>>



--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
+1 to Hiram's suggestion.

On Thu, May 14, 2015 at 8:32 AM, Hiram Chirino <[hidden email]>
wrote:

> I'm not sure that's a good default.  ActiveMQ has traditionally
> allowed remote access to it's ports.  I think a localhost binding is
> fine for things like management ports, but for the main service the
> product gives it should be on the public ports.
>
> That would be like tomcat or jetty defaulting to binding it's http
> ports to localhost.
>
> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]>
> wrote:
> > IMO the broker correctly binds to localhost only and does not, by
> default, allow connections from remote machines.  This is a simple
> security/sanity measure to prevent access to default (i.e. unsecured)
> instances.
> >
> > The merit of this configuration is obviously up for debate, but it's
> worth noting it was done on purpose.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <[hidden email]>
> > To: "ActiveMQ Dev" <[hidden email]>
> > Sent: Thursday, May 14, 2015 10:05:55 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> >> initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> [hidden email] | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
In reply to this post by jgomes
Logged bug ACTIVEMQ6-106.

And at the risk of opening a big can of worms, do we need to have
Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
something? I was very hesitant to enter a bug there, and had to
double-check that it was indeed the Artemis bug tracker.

On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <[hidden email]> wrote:

> If it was done on purpose for security reasons, that's cool. However, it
> is doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the
> release should be held up because of this problem. It's a show-stopper for
> NMS clients.  Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
>     at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>     at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>     at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
>     at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
>     at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by
>> default, allow connections from remote machines.  This is a simple
>> security/sanity measure to prevent access to default (i.e. unsecured)
>> instances.
>>
>> The merit of this configuration is obviously up for debate, but it's
>> worth noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <[hidden email]>
>> To: "ActiveMQ Dev" <[hidden email]>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>> wrote:
>>
>> > Hello all.
>> >
>> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>> > initial RC feedback from community members.
>> >
>> > This is a first release of the Artemis project with protocol support for
>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>> >
>> > The release notes can be found here:
>> >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>> >
>> > The binary distributions can be found here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >
>> > The source archives can be found here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >
>> > The Maven repository is here:
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>> >
>> > The source tag:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>> >
>> > The project website for that version has been staged to:
>> > http://people.apache.org/~martyntaylor/
>> >
>> > The vote will remain open for 72 hours.
>> >
>> > [ ] +1 approve the release as Apache Artemis 1.0.0
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> > Here's my (non-binding) +1
>> >
>> > Regards
>> > Martyn
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic
We have requested a rename.  Infra is waiting on a window to reboot JIRA.

Sent from my iPad

> On May 14, 2015, at 11:41, Jim Gomes <[hidden email]> wrote:
>
> Logged bug ACTIVEMQ6-106.
>
> And at the risk of opening a big can of worms, do we need to have
> Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> something? I was very hesitant to enter a bug there, and had to
> double-check that it was indeed the Artemis bug tracker.
>
>> On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <[hidden email]> wrote:
>>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release should be held up because of this problem. It's a show-stopper for
>> NMS clients.  Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>>    at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>    at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>    at
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>>    at
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>>    at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default, allow connections from remote machines.  This is a simple
>>> security/sanity measure to prevent access to default (i.e. unsecured)
>>> instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <[hidden email]>
>>> To: "ActiveMQ Dev" <[hidden email]>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>>> wrote:
>>>
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>> the
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>>
>>>> The binary distributions can be found here:
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>> The source archives can be found here:
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>> The Maven repository is here:
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>>
>>>> The source tag:
>>>>
>>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>>
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
In reply to this post by Martyn Taylor
Thinking about it I agree with Hiram too


Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: Jim Gomes <[hidden email]> </div><div>Date:14/05/2015  16:42  (GMT+00:00) </div><div>To: ActiveMQ Dev <[hidden email]> </div><div>Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2) </div><div>
</div>+1 to Hiram's suggestion.

On Thu, May 14, 2015 at 8:32 AM, Hiram Chirino <[hidden email]>
wrote:

> I'm not sure that's a good default.  ActiveMQ has traditionally
> allowed remote access to it's ports.  I think a localhost binding is
> fine for things like management ports, but for the main service the
> product gives it should be on the public ports.
>
> That would be like tomcat or jetty defaulting to binding it's http
> ports to localhost.
>
> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]>
> wrote:
> > IMO the broker correctly binds to localhost only and does not, by
> default, allow connections from remote machines.  This is a simple
> security/sanity measure to prevent access to default (i.e. unsecured)
> instances.
> >
> > The merit of this configuration is obviously up for debate, but it's
> worth noting it was done on purpose.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <[hidden email]>
> > To: "ActiveMQ Dev" <[hidden email]>
> > Sent: Thursday, May 14, 2015 10:05:55 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> >> initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> [hidden email] | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic
In reply to this post by jgomes
here is the JIRA with the current progress on the renames:

https://issues.apache.org/jira/browse/INFRA-9543

On Thu, May 14, 2015 at 11:41 AM, Jim Gomes <[hidden email]> wrote:

> Logged bug ACTIVEMQ6-106.
>
> And at the risk of opening a big can of worms, do we need to have
> Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> something? I was very hesitant to enter a bug there, and had to
> double-check that it was indeed the Artemis bug tracker.
>
> On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <[hidden email]> wrote:
>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release should be held up because of this problem. It's a show-stopper for
>> NMS clients.  Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>>     at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>     at
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>     at
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>>     at
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>>     at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default, allow connections from remote machines.  This is a simple
>>> security/sanity measure to prevent access to default (i.e. unsecured)
>>> instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <[hidden email]>
>>> To: "ActiveMQ Dev" <[hidden email]>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>>> wrote:
>>>
>>> > Hello all.
>>> >
>>> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>> the
>>> > initial RC feedback from community members.
>>> >
>>> > This is a first release of the Artemis project with protocol support for
>>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>> >
>>> > The release notes can be found here:
>>> >
>>> >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>> >
>>> > The binary distributions can be found here:
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> >
>>> > The source archives can be found here:
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>> >
>>> > The Maven repository is here:
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>> >
>>> > The source tag:
>>> >
>>> >
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>> >
>>> > The project website for that version has been staged to:
>>> > http://people.apache.org/~martyntaylor/
>>> >
>>> > The vote will remain open for 72 hours.
>>> >
>>> > [ ] +1 approve the release as Apache Artemis 1.0.0
>>> > [ ] +0 no opinion
>>> > [ ] -1 disapprove (and reason why)
>>> >
>>> > Here's my (non-binding) +1
>>> >
>>> > Regards
>>> > Martyn
>>> >
>>>
>>
>>



--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@...
http://clebertsuconic.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

clebertsuconic
In reply to this post by andytaylor
https://github.com/apache/activemq-artemis/pull/261


but if you guys could please keep the feedback coming.. no need to
wait the next RC to try it out.

On Thu, May 14, 2015 at 11:50 AM, andy.tayls67 <[hidden email]> wrote:

> Thinking about it I agree with Hiram too
>
>
> Sent from Samsung Mobile
>
> <div>-------- Original message --------</div><div>From: Jim Gomes <[hidden email]> </div><div>Date:14/05/2015  16:42  (GMT+00:00) </div><div>To: ActiveMQ Dev <[hidden email]> </div><div>Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2) </div><div>
> </div>+1 to Hiram's suggestion.
>
> On Thu, May 14, 2015 at 8:32 AM, Hiram Chirino <[hidden email]>
> wrote:
>
>> I'm not sure that's a good default.  ActiveMQ has traditionally
>> allowed remote access to it's ports.  I think a localhost binding is
>> fine for things like management ports, but for the main service the
>> product gives it should be on the public ports.
>>
>> That would be like tomcat or jetty defaulting to binding it's http
>> ports to localhost.
>>
>> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]>
>> wrote:
>> > IMO the broker correctly binds to localhost only and does not, by
>> default, allow connections from remote machines.  This is a simple
>> security/sanity measure to prevent access to default (i.e. unsecured)
>> instances.
>> >
>> > The merit of this configuration is obviously up for debate, but it's
>> worth noting it was done on purpose.
>> >
>> >
>> > Justin
>> >
>> > ----- Original Message -----
>> > From: "Jim Gomes" <[hidden email]>
>> > To: "ActiveMQ Dev" <[hidden email]>
>> > Sent: Thursday, May 14, 2015 10:05:55 AM
>> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>> >
>> > -1
>> >
>> > Two reasons:
>> >
>> > 1. The default configuration of localhost for the broker does not allow
>> > connections from off-machine. For some reason, socket connections are
>> > refused from non-local clients. I had to change the broker.xml config to
>> > use the machine's actual IP address, and then non-local clients could
>> > connect.
>> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> > unknown response IDs from the broker. I don't think the OpenWire protocol
>> > is being negotiated correctly. I am running with the latest NMS trunk
>> > version (1.8.0).
>> >
>> >
>> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>> wrote:
>> >
>> >> Hello all.
>> >>
>> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>> >> initial RC feedback from community members.
>> >>
>> >> This is a first release of the Artemis project with protocol support for
>> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>> >>
>> >> The release notes can be found here:
>> >>
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>> >>
>> >> The binary distributions can be found here:
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >>
>> >> The source archives can be found here:
>> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>> >>
>> >> The Maven repository is here:
>> >>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>> >>
>> >> The source tag:
>> >>
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>> >>
>> >> The project website for that version has been staged to:
>> >> http://people.apache.org/~martyntaylor/
>> >>
>> >> The vote will remain open for 72 hours.
>> >>
>> >> [ ] +1 approve the release as Apache Artemis 1.0.0
>> >> [ ] +0 no opinion
>> >> [ ] -1 disapprove (and reason why)
>> >>
>> >> Here's my (non-binding) +1
>> >>
>> >> Regards
>> >> Martyn
>> >>
>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> [hidden email] | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>>



--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@...
http://clebertsuconic.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Justin Bertram-2
In reply to this post by jgomes
> However, it is doubtful this is the way any broker will ever be run for real.

Yes, of course.

As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case.  To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.

I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.


> It's like having a web server start up without the ability to server web pages by default.

If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password.  That just seems like common sense to me.

In short, I think we should take a pretty conservative approach with our user's security.  I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal.  If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).


Justin

----- Original Message -----
From: "Jim Gomes" <[hidden email]>
To: "ActiveMQ Dev" <[hidden email]>
Sent: Thursday, May 14, 2015 10:28:15 AM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
Kind of silly.

Anyway, I will log the bug with the NMS clients, and I do think the release
should be held up because of this problem. It's a show-stopper for NMS
clients.  Here's the server exception being thrown:

ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConsumerControl
{commandId = 0, responseRequired = false, consumerId =
ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
false, start = false, flush = false, prefetch = 32766, destination =
topic://UnitTest.Status}
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
    at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
    at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]



On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]> wrote:

> IMO the broker correctly binds to localhost only and does not, by default,
> allow connections from remote machines.  This is a simple security/sanity
> measure to prevent access to default (i.e. unsecured) instances.
>
> The merit of this configuration is obviously up for debate, but it's worth
> noting it was done on purpose.
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <[hidden email]>
> To: "ActiveMQ Dev" <[hidden email]>
> Sent: Thursday, May 14, 2015 10:05:55 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> -1
>
> Two reasons:
>
> 1. The default configuration of localhost for the broker does not allow
> connections from off-machine. For some reason, socket connections are
> refused from non-local clients. I had to change the broker.xml config to
> use the machine's actual IP address, and then non-local clients could
> connect.
> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> unknown response IDs from the broker. I don't think the OpenWire protocol
> is being negotiated correctly. I am running with the latest NMS trunk
> version (1.8.0).
>
>
> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> wrote:
>
> > Hello all.
> >
> > I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> > initial RC feedback from community members.
> >
> > This is a first release of the Artemis project with protocol support for
> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >
> > The release notes can be found here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >
> > The binary distributions can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >
> > The source tag:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.0.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> > Martyn
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Bruce Snyder
In reply to this post by chirino
+1 We debated this some time ago for ActiveMQ and opted for the current
functionality of allowing remote connections by default.

Bruce

On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino <[hidden email]>
wrote:

> I'm not sure that's a good default.  ActiveMQ has traditionally
> allowed remote access to it's ports.  I think a localhost binding is
> fine for things like management ports, but for the main service the
> product gives it should be on the public ports.
>
> That would be like tomcat or jetty defaulting to binding it's http
> ports to localhost.
>
> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]>
> wrote:
> > IMO the broker correctly binds to localhost only and does not, by
> default, allow connections from remote machines.  This is a simple
> security/sanity measure to prevent access to default (i.e. unsecured)
> instances.
> >
> > The merit of this configuration is obviously up for debate, but it's
> worth noting it was done on purpose.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <[hidden email]>
> > To: "ActiveMQ Dev" <[hidden email]>
> > Sent: Thursday, May 14, 2015 10:05:55 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > -1
> >
> > Two reasons:
> >
> > 1. The default configuration of localhost for the broker does not allow
> > connections from off-machine. For some reason, socket connections are
> > refused from non-local clients. I had to change the broker.xml config to
> > use the machine's actual IP address, and then non-local clients could
> > connect.
> > 2. The basic NMS OpenWire client fails to connect at all. It is getting
> > unknown response IDs from the broker. I don't think the OpenWire protocol
> > is being negotiated correctly. I am running with the latest NMS trunk
> > version (1.8.0).
> >
> >
> > On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> wrote:
> >
> >> Hello all.
> >>
> >> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> the
> >> initial RC feedback from community members.
> >>
> >> This is a first release of the Artemis project with protocol support for
> >> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>
> >> The release notes can be found here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>
> >> The binary distributions can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>
> >> The Maven repository is here:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>
> >> The source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>
> >> The project website for that version has been staged to:
> >> http://people.apache.org/~martyntaylor/
> >>
> >> The vote will remain open for 72 hours.
> >>
> >> [ ] +1 approve the release as Apache Artemis 1.0.0
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Here's my (non-binding) +1
> >>
> >> Regards
> >> Martyn
> >>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> [hidden email] | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>



--
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

jgomes
In reply to this post by clebertsuconic
Thanks, Clebert!

And thanks for the quick update on the default bindings.

On Thu, May 14, 2015 at 8:59 AM, Clebert Suconic <[hidden email]>
wrote:

> here is the JIRA with the current progress on the renames:
>
> https://issues.apache.org/jira/browse/INFRA-9543
>
> On Thu, May 14, 2015 at 11:41 AM, Jim Gomes <[hidden email]> wrote:
> > Logged bug ACTIVEMQ6-106.
> >
> > And at the risk of opening a big can of worms, do we need to have
> > Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
> > something? I was very hesitant to enter a bug there, and had to
> > double-check that it was indeed the Artemis bug tracker.
> >
> > On Thu, May 14, 2015 at 8:28 AM, Jim Gomes <[hidden email]> wrote:
> >
> >> If it was done on purpose for security reasons, that's cool. However, it
> >> is doubtful this is the way any broker will ever be run for real. The
> whole
> >> purpose of a broker is to integrate disparate systems. It's like having
> a
> >> web server start up without the ability to server web pages by default.
> >> Kind of silly.
> >>
> >> Anyway, I will log the bug with the NMS clients, and I do think the
> >> release should be held up because of this problem. It's a show-stopper
> for
> >> NMS clients.  Here's the server exception being thrown:
> >>
> >> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> >> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> >> {commandId = 0, responseRequired = false, consumerId =
> >> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> >> false, start = false, flush = false, prefetch = 32766, destination =
> >> topic://UnitTest.Status}
> >>     at
> >>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> >> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >>     at
> >>
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> >> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >>     at
> >>
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> >> [artemis-server-1.0.0.jar:1.0.0]
> >>     at
> >>
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> >> [artemis-core-client-1.0.0.jar:1.0.0]
> >>     at
> >>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at
> >>
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> >> [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >>
> >>
> >>
> >> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
> >> wrote:
> >>
> >>> IMO the broker correctly binds to localhost only and does not, by
> >>> default, allow connections from remote machines.  This is a simple
> >>> security/sanity measure to prevent access to default (i.e. unsecured)
> >>> instances.
> >>>
> >>> The merit of this configuration is obviously up for debate, but it's
> >>> worth noting it was done on purpose.
> >>>
> >>>
> >>> Justin
> >>>
> >>> ----- Original Message -----
> >>> From: "Jim Gomes" <[hidden email]>
> >>> To: "ActiveMQ Dev" <[hidden email]>
> >>> Sent: Thursday, May 14, 2015 10:05:55 AM
> >>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >>>
> >>> -1
> >>>
> >>> Two reasons:
> >>>
> >>> 1. The default configuration of localhost for the broker does not allow
> >>> connections from off-machine. For some reason, socket connections are
> >>> refused from non-local clients. I had to change the broker.xml config
> to
> >>> use the machine's actual IP address, and then non-local clients could
> >>> connect.
> >>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> >>> unknown response IDs from the broker. I don't think the OpenWire
> protocol
> >>> is being negotiated correctly. I am running with the latest NMS trunk
> >>> version (1.8.0).
> >>>
> >>>
> >>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> >>> wrote:
> >>>
> >>> > Hello all.
> >>> >
> >>> > I've cut a second release candidate of Apache Artemis 1.0.0
> addressing
> >>> the
> >>> > initial RC feedback from community members.
> >>> >
> >>> > This is a first release of the Artemis project with protocol support
> for
> >>> > AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>> >
> >>> > The release notes can be found here:
> >>> >
> >>> >
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>> >
> >>> > The binary distributions can be found here:
> >>> >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> >
> >>> > The source archives can be found here:
> >>> >
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>> >
> >>> > The Maven repository is here:
> >>> >
> >>>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>> >
> >>> > The source tag:
> >>> >
> >>> >
> >>>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>> >
> >>> > The project website for that version has been staged to:
> >>> > http://people.apache.org/~martyntaylor/
> >>> >
> >>> > The vote will remain open for 72 hours.
> >>> >
> >>> > [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> > [ ] +0 no opinion
> >>> > [ ] -1 disapprove (and reason why)
> >>> >
> >>> > Here's my (non-binding) +1
> >>> >
> >>> > Regards
> >>> > Martyn
> >>> >
> >>>
> >>
> >>
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@...
> http://clebertsuconic.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

tabish121@gmail.com
In reply to this post by Bruce Snyder
+1

On 05/14/2015 12:14 PM, Bruce Snyder wrote:

> +1 We debated this some time ago for ActiveMQ and opted for the current
> functionality of allowing remote connections by default.
>
> Bruce
>
> On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino <[hidden email]>
> wrote:
>
>> I'm not sure that's a good default.  ActiveMQ has traditionally
>> allowed remote access to it's ports.  I think a localhost binding is
>> fine for things like management ports, but for the main service the
>> product gives it should be on the public ports.
>>
>> That would be like tomcat or jetty defaulting to binding it's http
>> ports to localhost.
>>
>> On Thu, May 14, 2015 at 11:20 AM, Justin Bertram <[hidden email]>
>> wrote:
>>> IMO the broker correctly binds to localhost only and does not, by
>> default, allow connections from remote machines.  This is a simple
>> security/sanity measure to prevent access to default (i.e. unsecured)
>> instances.
>>> The merit of this configuration is obviously up for debate, but it's
>> worth noting it was done on purpose.
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <[hidden email]>
>>> To: "ActiveMQ Dev" <[hidden email]>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>> wrote:
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>> The binary distributions can be found here:
>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>> The source archives can be found here:
>>>>
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>> The Maven repository is here:
>>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>> The source tag:
>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> [hidden email] | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>>
>
>


--
Tim Bish
Sr Software Engineer | RedHat Inc.
[hidden email] | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
In reply to this post by Justin Bertram-2
On 14/05/15 17:11, Justin Bertram wrote:
>> However, it is doubtful this is the way any broker will ever be run for real.
>
> Yes, of course.
>
> As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case.  To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.
>
> I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.
The security issue is a valid argument, but like you say if its not
common for users to unzip and deploy into production then its actually a
moot point.

There are arguments to and for it but personally im happy to open the
broker up to remote clients. Maybe we just improve the management
functionality(and write) and only allow local clients for admin stuff.

>
>
>> It's like having a web server start up without the ability to server web pages by default.
>
> If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password.  That just seems like common sense to me.
>
> In short, I think we should take a pretty conservative approach with our user's security.  I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal.  If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <[hidden email]>
> To: "ActiveMQ Dev" <[hidden email]>
> Sent: Thursday, May 14, 2015 10:28:15 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If it was done on purpose for security reasons, that's cool. However, it is
> doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the release
> should be held up because of this problem. It's a show-stopper for NMS
> clients.  Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
>      at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by default,
>> allow connections from remote machines.  This is a simple security/sanity
>> measure to prevent access to default (i.e. unsecured) instances.
>>
>> The merit of this configuration is obviously up for debate, but it's worth
>> noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <[hidden email]>
>> To: "ActiveMQ Dev" <[hidden email]>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>> initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

chirino
BTW now that we generate the instance configuration, we could create
fully secure configurations by default.  For example we could generate
a broker with SSL enabled using a generated self signed cert.  We
could also create a default admin users with a generated password etc.

On Thu, May 14, 2015 at 1:21 PM, Andy Taylor <[hidden email]> wrote:

> On 14/05/15 17:11, Justin Bertram wrote:
>>>
>>> However, it is doubtful this is the way any broker will ever be run for
>>> real.
>>
>>
>> Yes, of course.
>>
>> As I see it, the default configuration is for users (mostly developers)
>> who want to start up a broker quickly, run a few examples, look at the
>> console, etc. All that would typically be done locally since that is the
>> simplest, fastest use-case.  To move beyond that use-case (e.g. to one with
>> remote clients) hopefully the user would have reviewed a bit of the
>> documentation and come to understand more of how the broker works, the
>> importance of security, etc.
>>
>> I don't think it's common for users to unzip the broker and deploy to
>> production with no changes. IMO, the broker configuration is typically
>> tailored for the application and environment. Binding the network transports
>> to the proper interface is just part of that process.
>
> The security issue is a valid argument, but like you say if its not common
> for users to unzip and deploy into production then its actually a moot
> point.
>
> There are arguments to and for it but personally im happy to open the broker
> up to remote clients. Maybe we just improve the management functionality(and
> write) and only allow local clients for admin stuff.
>
>>
>>
>>> It's like having a web server start up without the ability to server web
>>> pages by default.
>>
>>
>> If the web server was 100% read-only then I'd probably be find with it
>> binding to a public interface by default. However, if there was any way for
>> remote users to impact my machine through that server (beyond a DOS attack)
>> then I would want the server to bind to localhost by default or be secured
>> with e.g. a username/password.  That just seems like common sense to me.
>>
>> In short, I think we should take a pretty conservative approach with our
>> user's security.  I think binding the server to 0.0.0.0 (i.e. all network
>> interfaces) by default with the current configuration is too liberal.  If we
>> were to bind to 0.0.0.0 by default I'd want to either remove the default
>> user account altogether or change it so that the default user could only
>> consume messages (i.e. couldn't produce messages, create queues, or perform
>> management operations).
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <[hidden email]>
>> To: "ActiveMQ Dev" <[hidden email]>
>> Sent: Thursday, May 14, 2015 10:28:15 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is
>> doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release
>> should be held up because of this problem. It's a show-stopper for NMS
>> clients.  Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>>      at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>      at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>>      at
>>
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>>      at
>>
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>>      at
>>
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at
>>
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default,
>>> allow connections from remote machines.  This is a simple security/sanity
>>> measure to prevent access to default (i.e. unsecured) instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth
>>> noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <[hidden email]>
>>> To: "ActiveMQ Dev" <[hidden email]>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>>> wrote:
>>>
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>>
>>> the
>>>>
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>>
>>>>
>>>> The binary distributions can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The source archives can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The Maven repository is here:
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>>
>>>>
>>>> The source tag:
>>>>
>>>>
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>>
>>>>
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>>
>



--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

Justin Bertram-2
In reply to this post by andytaylor
> The security issue is a valid argument, but like you say if its not common for users to unzip and deploy into production then its actually a moot point.

"Production" systems are not the only systems on which security is important.  Consider a casual user who starts the broker just to play around with it and then forgets to turn it off.  Now that unsuspecting user has an additional attack vector on their machine.  Oftentimes black-hats will compromise a "lesser" (i.e. non production) system in order to get to the real target.

I'm not trying to be some kind of security alarmist or saying our distribution has to be 100% air-tight.  All I'm saying is that the default configuration should be conservative from a security/access stand-point.  I don't think it's acceptable that if I start the broker then anybody who can connect to my machine remotely now has the ability to start filling up my disk with messages.  If the consensus is to bind to public network interfaces by default then we should likewise modify the configuration to be read-only by default at the very least.


Justin

----- Original Message -----
From: "Andy Taylor" <[hidden email]>
To: [hidden email]
Sent: Thursday, May 14, 2015 12:21:24 PM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

On 14/05/15 17:11, Justin Bertram wrote:
>> However, it is doubtful this is the way any broker will ever be run for real.
>
> Yes, of course.
>
> As I see it, the default configuration is for users (mostly developers) who want to start up a broker quickly, run a few examples, look at the console, etc. All that would typically be done locally since that is the simplest, fastest use-case.  To move beyond that use-case (e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation and come to understand more of how the broker works, the importance of security, etc.
>
> I don't think it's common for users to unzip the broker and deploy to production with no changes. IMO, the broker configuration is typically tailored for the application and environment. Binding the network transports to the proper interface is just part of that process.
The security issue is a valid argument, but like you say if its not
common for users to unzip and deploy into production then its actually a
moot point.

There are arguments to and for it but personally im happy to open the
broker up to remote clients. Maybe we just improve the management
functionality(and write) and only allow local clients for admin stuff.

>
>
>> It's like having a web server start up without the ability to server web pages by default.
>
> If the web server was 100% read-only then I'd probably be find with it binding to a public interface by default. However, if there was any way for remote users to impact my machine through that server (beyond a DOS attack) then I would want the server to bind to localhost by default or be secured with e.g. a username/password.  That just seems like common sense to me.
>
> In short, I think we should take a pretty conservative approach with our user's security.  I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current configuration is too liberal.  If we were to bind to 0.0.0.0 by default I'd want to either remove the default user account altogether or change it so that the default user could only consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <[hidden email]>
> To: "ActiveMQ Dev" <[hidden email]>
> Sent: Thursday, May 14, 2015 10:28:15 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If it was done on purpose for security reasons, that's cool. However, it is
> doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the release
> should be held up because of this problem. It's a show-stopper for NMS
> clients.  Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
>      at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by default,
>> allow connections from remote machines.  This is a simple security/sanity
>> measure to prevent access to default (i.e. unsecured) instances.
>>
>> The merit of this configuration is obviously up for debate, but it's worth
>> noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <[hidden email]>
>> To: "ActiveMQ Dev" <[hidden email]>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>> initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Apache Artemis 1.0.0 (RC2)

andytaylor
If its not 100% air tight then there are still vulnerabilities. I think
something useful out of the box is better.

Since the user now has to create an instance befote tunning tbw broker,
why don't we just add a flag --secure or something similar and document it.
Then it's up to the user to decide which they want.
On 14 May 2015 19:08, "Justin Bertram" <[hidden email]> wrote:

> > The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> "Production" systems are not the only systems on which security is
> important.  Consider a casual user who starts the broker just to play
> around with it and then forgets to turn it off.  Now that unsuspecting user
> has an additional attack vector on their machine.  Oftentimes black-hats
> will compromise a "lesser" (i.e. non production) system in order to get to
> the real target.
>
> I'm not trying to be some kind of security alarmist or saying our
> distribution has to be 100% air-tight.  All I'm saying is that the default
> configuration should be conservative from a security/access stand-point.  I
> don't think it's acceptable that if I start the broker then anybody who can
> connect to my machine remotely now has the ability to start filling up my
> disk with messages.  If the consensus is to bind to public network
> interfaces by default then we should likewise modify the configuration to
> be read-only by default at the very least.
>
>
> Justin
>
> ----- Original Message -----
> From: "Andy Taylor" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, May 14, 2015 12:21:24 PM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> On 14/05/15 17:11, Justin Bertram wrote:
> >> However, it is doubtful this is the way any broker will ever be run for
> real.
> >
> > Yes, of course.
> >
> > As I see it, the default configuration is for users (mostly developers)
> who want to start up a broker quickly, run a few examples, look at the
> console, etc. All that would typically be done locally since that is the
> simplest, fastest use-case.  To move beyond that use-case (e.g. to one with
> remote clients) hopefully the user would have reviewed a bit of the
> documentation and come to understand more of how the broker works, the
> importance of security, etc.
> >
> > I don't think it's common for users to unzip the broker and deploy to
> production with no changes. IMO, the broker configuration is typically
> tailored for the application and environment. Binding the network
> transports to the proper interface is just part of that process.
> The security issue is a valid argument, but like you say if its not
> common for users to unzip and deploy into production then its actually a
> moot point.
>
> There are arguments to and for it but personally im happy to open the
> broker up to remote clients. Maybe we just improve the management
> functionality(and write) and only allow local clients for admin stuff.
> >
> >
> >> It's like having a web server start up without the ability to server
> web pages by default.
> >
> > If the web server was 100% read-only then I'd probably be find with it
> binding to a public interface by default. However, if there was any way for
> remote users to impact my machine through that server (beyond a DOS attack)
> then I would want the server to bind to localhost by default or be secured
> with e.g. a username/password.  That just seems like common sense to me.
> >
> > In short, I think we should take a pretty conservative approach with our
> user's security.  I think binding the server to 0.0.0.0 (i.e. all network
> interfaces) by default with the current configuration is too liberal.  If
> we were to bind to 0.0.0.0 by default I'd want to either remove the default
> user account altogether or change it so that the default user could only
> consume messages (i.e. couldn't produce messages, create queues, or perform
> management operations).
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Jim Gomes" <[hidden email]>
> > To: "ActiveMQ Dev" <[hidden email]>
> > Sent: Thursday, May 14, 2015 10:28:15 AM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > If it was done on purpose for security reasons, that's cool. However, it
> is
> > doubtful this is the way any broker will ever be run for real. The whole
> > purpose of a broker is to integrate disparate systems. It's like having a
> > web server start up without the ability to server web pages by default.
> > Kind of silly.
> >
> > Anyway, I will log the bug with the NMS clients, and I do think the
> release
> > should be held up because of this problem. It's a show-stopper for NMS
> > clients.  Here's the server exception being thrown:
> >
> > ERROR [org.apache.activemq.artemis.core.server] error decoding:
> > java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> > {commandId = 0, responseRequired = false, consumerId =
> > ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> > false, start = false, flush = false, prefetch = 32766, destination =
> > topic://UnitTest.Status}
> >      at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >      at
> >
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> > [artemis-openwire-protocol-1.0.0.jar:1.0.0]
> >      at
> >
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> > [artemis-server-1.0.0.jar:1.0.0]
> >      at
> >
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> > [artemis-core-client-1.0.0.jar:1.0.0]
> >      at
> >
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at
> >
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> > [netty-all-4.0.20.Final.jar:4.0.20.Final]
> >      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> >
> >
> >
> > On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <[hidden email]>
> wrote:
> >
> >> IMO the broker correctly binds to localhost only and does not, by
> default,
> >> allow connections from remote machines.  This is a simple
> security/sanity
> >> measure to prevent access to default (i.e. unsecured) instances.
> >>
> >> The merit of this configuration is obviously up for debate, but it's
> worth
> >> noting it was done on purpose.
> >>
> >>
> >> Justin
> >>
> >> ----- Original Message -----
> >> From: "Jim Gomes" <[hidden email]>
> >> To: "ActiveMQ Dev" <[hidden email]>
> >> Sent: Thursday, May 14, 2015 10:05:55 AM
> >> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >>
> >> -1
> >>
> >> Two reasons:
> >>
> >> 1. The default configuration of localhost for the broker does not allow
> >> connections from off-machine. For some reason, socket connections are
> >> refused from non-local clients. I had to change the broker.xml config to
> >> use the machine's actual IP address, and then non-local clients could
> >> connect.
> >> 2. The basic NMS OpenWire client fails to connect at all. It is getting
> >> unknown response IDs from the broker. I don't think the OpenWire
> protocol
> >> is being negotiated correctly. I am running with the latest NMS trunk
> >> version (1.8.0).
> >>
> >>
> >> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <[hidden email]>
> >> wrote:
> >>
> >>> Hello all.
> >>>
> >>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
> >> the
> >>> initial RC feedback from community members.
> >>>
> >>> This is a first release of the Artemis project with protocol support
> for
> >>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
> >>>
> >>> The release notes can be found here:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
> >>>
> >>> The binary distributions can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The source archives can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
> >>>
> >>> The Maven repository is here:
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
> >>>
> >>> The source tag:
> >>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
> >>>
> >>> The project website for that version has been staged to:
> >>> http://people.apache.org/~martyntaylor/
> >>>
> >>> The vote will remain open for 72 hours.
> >>>
> >>> [ ] +1 approve the release as Apache Artemis 1.0.0
> >>> [ ] +0 no opinion
> >>> [ ] -1 disapprove (and reason why)
> >>>
> >>> Here's my (non-binding) +1
> >>>
> >>> Regards
> >>> Martyn
> >>>
> >>
>
12