[wildfly-dev] HTTP Upgrade Options (Re: 8.0.0.Alpha3 Released!)

[Andrig Miller]

----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Andrig Miller" <anmiller at redhat.com>
> Cc: wildfly-dev at lists.jboss.org, "Bill Burke" <bburke at redhat.com>
> Sent: Thursday, July 18, 2013 12:54:08 PM
> Subject: Re: [wildfly-dev] HTTP Upgrade Options (Re:  8.0.0.Alpha3 Released!)
> 
> 
> On Jul 18, 2013, at 12:51 PM, Andrig Miller <anmiller at redhat.com>
> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Jason Greene" <jason.greene at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: wildfly-dev at lists.jboss.org
> >> Sent: Thursday, July 18, 2013 11:40:47 AM
> >> Subject: [wildfly-dev] HTTP Upgrade Options (Re:  8.0.0.Alpha3
> >> Released!)
> >> 
> >> 
> >> On Jul 18, 2013, at 7:51 AM, Bill Burke <bburke at redhat.com> wrote:
> >> 
> >>> 
> >>> 
> >>> On 7/18/2013 1:06 AM, Jason Greene wrote:
> >>>>  • EJB invocations now use HTTP upgrade over port 8080
> >>> 
> >>> Very cool!  Every remoting protocol headed this way?!  That's
> >>> awesome!
> >> 
> >> 
> >> Yes thats the plan. Although maybe you and others could share your
> >> opinion on something. We have been looking as a goal to create two
> >> profiles:
> >> 
> >> 1. Two ports - 8080 (application = servlet, ejb, remote jndi, jms)
> >>               9990 (management  = native management, HTTP/JSON
> >>               managmeent, web console, JMX)
> >> 2. One port - 8080 (all of the above)
> >> 
> >> AJP & IIOP can't be multiplexed and would be disabled by default.
> >> Using SSL would either add or replace the above ports.
> >> 
> >> So the big question is which configuration is the better default.
> >> Administrators like the 2 port because its easy to separate
> >> access.
> >> For example, today when you start wildfly with -b 0.0.0.0 or
> >> whatever, it only affects the application ports and not the
> >> management port. It's also easy to firewall. One port is in big
> >> demand for massive hosting environments like openshift. Going to
> >> one
> >> port would probably mean we would need to add some ip pattern
> >> restriction features to standalone.xml, but I'm not sure this is a
> >> good substitute because administrators won't be familiar with it,
> >> but they already know how to use iptables and -b.
> >> 
> >> Any thoughts?
> >> 
> > 
> > One port is interesting in that it becomes like Weblogic.  The
> > management aspect would still require separate authentication
> > anyway (management user vs. application user), so I'm not that
> > sure that the management port being separate is really a big win
> > for administrators.
> 
> Yeah, thats a good point that is not that weak as a default (and we
> bind to localhost by default anyway). However, I could see people
> still wanting management locked to a separate interface with
> different firewall policies, since you don't have to worry about a
> bad password being all that stands in the way from someone breaking
> into your infrastructure.
> 
> > 
> > What could be interesting is see if we can run a community poll,
> > through the Andiamo community site.  If we promote to poll through
> > all our blogs, maybe we can get some good community feedback?
> 
> Thats a good idea. I would love to get feedback on this.
> 

So, how about a poll, that looks like the following:

Would you prefer two ports - 8080 (application = servlet, ejb, remote jndi, jms) and 9990 (management = native management, HTTP/JSON managmeent, web console, JMX) or alternatively:

One port - 8080 (for everything including management)?

Maybe a simply checkbox, and perhaps the explanation of TLS/SSL too?

Andy
 
> > Andy
> > 
> >> 
> >> --
> >> Jason T. Greene
> >> WildFly Lead / JBoss EAP Platform Architect
> >> JBoss, a division of Red Hat
> >> 
> >> 
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> 
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
>