ActiveMQ Console - moving toward a solution (starting with brainstorming)

[artnaseef <ar...@artnaseef.com>]

With the "problem definition" having collected a decent amount of
information, let's start talking about where we want to be and possible ways
to solve the problems.

Before starting, this is "brainstorming".  So please, feel free to share any
ideas without concern for absurdity.  And please be respectful of others
sharing.  That means, provide actionable feedback, or perceptions, of the
content of the idea and try to avoid pure criticism (negative feedback
that's unactionable) and personal attacks.  We will filter the ideas later.

First off, I want to argue that the solution to security concerns with the
console, and the rest of ActiveMQ, is to pursue the best practice of not
exposing ActiveMQ to untrusted sources.  So the following guidelines for
ActiveMQ installations follow:

* Avoid placing ActiveMQ's web console on the internet, or otherwise making
it accessible to untrusted parties, by placing it behind firewalls and
requiring internal network access or VPN access to reach the console.
* Avoid opening ActiveMQ's transports to the internet, or otherwise making
them accessible to untrusted parties to the extent possible, again using
firewalls and network precautions.
* Where absolutely necessary, using SSL with required client-certificates
can greatly reduce security risks.  Any brokers whose SSL connectors are
accessible to untrusted parties should also incorporate firewall protections
to prevent access to other, non-SSL-secured ports on the same ActiveMQ
instances.

Should we do anything more on this front?

For the "buggy" issue - I recommend to start fixing it.  Without any
evidence that the time and effort to maintain the console is significant, it
seems like this is more an issue of lack of motivation.  I'll start working
on the bugs myself.

For look-and-feel, what makes sense?  I like the idea of a built-in console
that is minimalistic - making it easy to navigate and get specific content,
and having it consistent for everyone to make talking about their
experiences, especially when reporting problems, straight-forward.  Note
that does not mean I'm against a major change to look-and-feel.  And, a nice
looking UI is awesome to have.  Should we promote the use of third-party
UIs?  If so, how can we do so in a way that is acceptable to everyone?  Or,
should we put in some effort on the built-in console - giving it a facelift
while still keeping to a more streamlined/information-focused than something
like Hawt.io.




--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-moving-toward-a-solution-starting-with-brainstorming-tp4677405.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[CLOSED] ActiveMQ Console - moving toward a solution (starting with brainstorming)

[artnaseef <ar...@artnaseef.com>]

I've chatted with a few folks and feel that now is a good time to focus
directly on the problems identified with the current webconsole.

So, I'm "closing" this thread at this time.  Thank you!



--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-moving-toward-a-solution-starting-with-brainstorming-tp4677405p4677484.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: ActiveMQ Console - moving toward a solution (starting with brainstorming)

[Daniel Kulp <dk...@apache.org>]

On Feb 4, 2014, at 10:31 AM, artnaseef <ar...@artnaseef.com> wrote:

> With the "problem definition" having collected a decent amount of
> information, let's start talking about where we want to be and possible ways
> to solve the problems.
> 
> Before starting, this is "brainstorming".  So please, feel free to share any
> ideas without concern for absurdity.  And please be respectful of others
> sharing.  That means, provide actionable feedback, or perceptions, of the
> content of the idea and try to avoid pure criticism (negative feedback
> that's unactionable) and personal attacks.  We will filter the ideas later.
> 
> First off, I want to argue that the solution to security concerns with the
> console, and the rest of ActiveMQ, is to pursue the best practice of not
> exposing ActiveMQ to untrusted sources.  So the following guidelines for
> ActiveMQ installations follow:
> 
> * Avoid placing ActiveMQ's web console on the internet, or otherwise making
> it accessible to untrusted parties, by placing it behind firewalls and
> requiring internal network access or VPN access to reach the console.
> * Avoid opening ActiveMQ's transports to the internet, or otherwise making
> them accessible to untrusted parties to the extent possible, again using
> firewalls and network precautions.
> * Where absolutely necessary, using SSL with required client-certificates
> can greatly reduce security risks.  Any brokers whose SSL connectors are
> accessible to untrusted parties should also incorporate firewall protections
> to prevent access to other, non-SSL-secured ports on the same ActiveMQ
> instances.
> 
> Should we do anything more on this front?

This sounds mostly like documentation things.   That definitely brings up the point that the docs at:

http://activemq.apache.org/web-console.html

need some major updates.  I’d certainly start with removing all the references to ActiveMQ 4.  :-)



> For the "buggy" issue - I recommend to start fixing it.  Without any
> evidence that the time and effort to maintain the console is significant, it
> seems like this is more an issue of lack of motivation.  I'll start working
> on the bugs myself.

I’m happy to help as well.   I’ll start by getting the issues Tim brought up assigned to the we console component.   

Does everyone have access to assign themselves issues in JIRA?  If not, let me know and I can help out making sure people can do so.


> For look-and-feel, what makes sense?  I like the idea of a built-in console
> that is minimalistic - making it easy to navigate and get specific content,
> and having it consistent for everyone to make talking about their
> experiences, especially when reporting problems, straight-forward.  Note
> that does not mean I'm against a major change to look-and-feel.  And, a nice
> looking UI is awesome to have.  Should we promote the use of third-party
> UIs?  If so, how can we do so in a way that is acceptable to everyone?  Or,
> should we put in some effort on the built-in console - giving it a facelift
> while still keeping to a more streamlined/information-focused than something
> like Hawt.io.

I also would prefer a very stream lined ActiveMQ specific interface as well.   I’m certainly OK with just a simple facelift if we fell thats needed, but I’m not even sure that is needed.


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com