qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Crumpton (kcrumpto)" <kcrum...@cisco.com>
Subject Re: Way to bind qpid to a different IP?
Date Mon, 06 Jan 2014 17:31:56 GMT
Hi Rob, Sorry for the really late reply / hope you remember this thread.

I got some assistance from the irc. I pulled the latest source using "svn
checkout http://svn.apache.org/repos/asf/qpid/trunk/qpid qpid"
Then I ran "patch -i QPID-5437.patch --dry-run -p0" in the Java branch.
The patch seemed successful. From there I did an "ant build" and got the
file "qpid-all.jar"
Looking for where I would go from here to get this running and bound to a
different IP?

I am finding that when I run it there is no main class specified.

On 12/19/13 6:11 PM, "Rob Godfrey" <rob.j.godfrey@gmail.com> wrote:

>I've created https://issues.apache.org/jira/browse/QPID-5437 and attached
>a
>quick patch to allow for HTTP ports to be bound to a speicifc address in
>the same way that AMQP ports are.  The patch is against the head of trunk
>rather than 0.22, though I don't imagine it'd be too difficult to get it
>to
>apply to that version.
>
>Hope this helps,
>Rob
>
>
>On 20 December 2013 00:51, Robbie Gemmell <robbie.gemmell@gmail.com>
>wrote:
>
>> On 19 December 2013 23:36, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>>
>> > So it looks like it will be a completely trivial fix to allow the HTTP
>> port
>> > to bind to different interfaces... the JMX (as Robbie says) not so
>> much...
>> > however if you don't need the JMX management plugin you can disable
>>it.
>> >
>>
>> It shouldnt be too much harder to implement for the JMX ports either, it
>> would likely just need use of some custom RMIServerSocketFactory
>> implementations, something we already do for other reasons (e.g
>> QpidSslRMIServerSocketFactory to allow use of SSL config other than the
>>JVM
>> default)
>>
>> The bit I was speaking to earlier is that the interfaces JMX listens on
>>are
>> completely distinct from the single IP/host it can actually advertise
>>the
>> JMXConnectorServer as being available at in the registry.
>>
>>
>> >
>> > If we patch up the HTTP management then all you'll need to do is
>>change
>> the
>> > initial config file to be populated with something like
>>"bindingAddress":
>> > "${openshift.app_ip}" and then modify the qpid start script to set
>>that
>> > config parameter from the environment.
>> >
>> >
>> You can pass "-Dfoo=bar" type values via the QPID_OPTS environment
>>variable
>> the script makes available.
>>
>>
>> > Obviously if you are giving the users access to the http management
>>then
>> > they might try to do things like add more ports to the broker, and
>>then
>> if
>> > they don't similarly restrict themselves to binding to only their
>>given
>> > address then you'd get conflicts... You could - I imagine prevent this
>> > either through locking down the Qpid config somewhat, or maybe at the
>> Linux
>> > level...
>> >
>> > If you're willing to run a patched version of the code I can probably
>> send
>> > you a patch by tmr which will allow the HTTP port to be bound to a
>> specific
>> > address in the same way that the AMQP port is.
>> >
>> > Hope this helps,
>> > Rob
>> >
>> >
>> > On 20 December 2013 00:26, Kyle Crumpton (kcrumpto)
>><kcrumpto@cisco.com
>> > >wrote:
>> >
>> > > Hi Keith, Rob.
>> > >
>> > > Thank you for your replies.
>> > > I am actually at a point where I am trying to get qpid running on a
>> PaaS
>> > > instance in a linux container.
>> > >
>> > > Scenario is
>> > > User creates app: test in namespace test
>> > > domain is example.com
>> > > so you create this app on your PaaS which exists on your server:
>> > > "node1.example.com"
>> > > So what will happen is you have a bind server which will create an
>> entry:
>> > > test-test.example.com CNAME IN node1.example.com
>> > > This app will be spawned with an attribute OPENSHIFT_<APP_TYPE>_IP
>> which
>> > > will allow the user to bind to that IP instead of 127.0.0.1 which
>>would
>> > > just steal the port from the host machine.
>> > > So for example, test-test.example.com could have an IP 127.1.2.3;
>> > > Another user could create their own app too, say "test2" which would
>> also
>> > > be allocated a different IP address on the node1.example.com
>>machine.
>> > > This server is then treated as a gateway to your app which exists
>>on a
>> > > linux container. From here I'd want the user to be able to "add"
>>qpid
>> to
>> > > the app.
>> > >
>> > > So right now what would happen is, the main server,
>>node1.example.comis
>> > > running an http interface on port 8080 already. This will fail with
>>an
>> > > invalid port. I know you can configure the port, but that does not
>>seem
>> > to
>> > > be the proper way to handle the problem?
>> > >
>> > > Say you have 3 users who want to use qpid on their 3 respective
>>apps..
>> It
>> > > seems that it'd be better to bind to the same ports on different IPs
>> then
>> > > to different ports on the same IP.
>> > >
>> > > Any thoughts?
>> > >
>> > > On 12/19/13 5:18 PM, "Keith W" <keith.wall@gmail.com> wrote:
>> > >
>> > > >Hello Kyle,
>> > > >
>> > > >Yes, this is supported.  You can make the AMQP port bind to a
>> > > >particular interface using the binding address attribute.     Use
>>the
>> > > >Web Management Console to edit the AMQP port and specify a binding
>> > > >address (127.1.244.129 in your case).  Once done, restart the
>>Broker
>> > > >for that change to take effect.
>> > > >
>> > > >The Java Broker docs describe the process of editing the port.
>> > > >
>> > > >
>> > >
>> >
>> 
>>http://qpid.apache.org/releases/qpid-0.22/java-broker/book/Java-Broker-Po
>>r
>> > > >ts.html#Java-Broker-Ports-Configuring
>> > > >
>> > > >You can't yet specify a binding address for HTTP Management or JMX.
>> > > >
>> > > >Hope this helps.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >On 19 December 2013 21:18, Ted Ross <tross@redhat.com> wrote:
>> > > >> Sorry Kyle,
>> > > >>
>> > > >> Gordon and I are giving you information about the C++ broker,
not
>> the
>> > > >>Java
>> > > >> broker.  I will need to defer to one of the Java broker folks
to
>> > answer
>> > > >>for
>> > > >> that component.
>> > > >>
>> > > >> -Ted
>> > > >>
>> > > >>
>> > > >> On 12/19/2013 04:03 PM, Kyle Crumpton (kcrumpto) wrote:
>> > > >>>
>> > > >>> Hi Ted. I am using version 0.22. I actually got qpid from
tar:
>> > > >>> qpid-java-broker-0.22.tar.gz
>> > > >>>
>> > > >>> On 12/19/13 3:00 PM, "Ted Ross" <tross@redhat.com> wrote:
>> > > >>>
>> > > >>>> Kyle,
>> > > >>>>
>> > > >>>> That feature was added in release 0.20
>> > > >>>> (https://issues.apache.org/jira/browse/QPID-3351).  You
may be
>> > using
>> > > >>>>an
>> > > >>>> older version.
>> > > >>>>
>> > > >>>> -Ted
>> > > >>>>
>> > > >>>> On 12/19/2013 03:15 PM, Kyle Crumpton (kcrumpto) wrote:
>> > > >>>>>
>> > > >>>>> Hi. I did this and I got the error: Unrecognized option:
>> > --interface
>> > > >>>>>
>> > > >>>>> On 12/19/13 12:59 PM, "Gordon Sim" <gsim@redhat.com>
wrote:
>> > > >>>>>
>> > > >>>>>> On 12/19/2013 06:45 PM, Kyle Crumpton (kcrumpto)
wrote:
>> > > >>>>>>>
>> > > >>>>>>> I am just curious if there is a way to bind
qpid to an IP
>>such
>> as
>> > > >>>>>>> 127.1.244.129
>> > > >>>>>>>
>> > > >>>>>>> The reason I ask is I'm looking to deploy
many instances to
>>a
>> > PaaS
>> > > >>>>>>>and
>> > > >>>>>>> will need multiple running instances. This
is not possible
>>if
>> > > >>>>>>> everything
>> > > >>>>>>> tries to bind to localhost:8080.
>> > > >>>>>>>
>> > > >>>>>>> Does anyone know of a way to configure this?
I could not
>>find
>> in
>> > > >>>>>>>the
>> > > >>>>>>> qpid documentation.
>> > > >>>>>>
>> > > >>>>>> Yes, you can use --interface to restrict the interfaces
qpidd
>> will
>> > > >>>>>>bind
>> > > >>>>>> on.
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> > >
>> >
>> 
>>>>>>>>-------------------------------------------------------------------
>>>>>>>>--
>> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >>>>>>
>> > > >>>>>
>> > ---------------------------------------------------------------------
>> > > >>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > ---------------------------------------------------------------------
>> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >>>> For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >>>>
>> > > >>>
>> > > >>>
>> ---------------------------------------------------------------------
>> > > >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >>> For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >>>
>> > > >>
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >> For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >>
>> > > >
>> > > 
>>>---------------------------------------------------------------------
>> > > >To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > >For additional commands, e-mail: dev-help@qpid.apache.org
>> > > >
>> > >
>> > >
>> > > 
>>---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > > For additional commands, e-mail: dev-help@qpid.apache.org
>> > >
>> > >
>> >
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message