You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Kevin Smith <ks...@redhat.com> on 2007/01/22 21:50:29 UTC
QPID-6
I'm going to take a swing at implementing this as a way to learn parts of the
codebase. Are there any example config files in the tree I could look at to see
how we're structuring the configs?
--Kevin
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
>> >
>> Would something as simple as a properties file work? All I really need
>> right now
>> are a few name/value pairs.
>
> Yes, it would work for me at least.
>
> Currently we use system properties in various places.
>
> RG
>
I have a first pass at configurable SSL support for the server and am looking at
the client now. I'm having trouble tracing thru the code and finding the main
entry points for the client code. Could someone point me in the right direction?
--Kevin
Re: QPID-6
Posted by Robert Greig <ro...@gmail.com>.
On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
> >
> Would something as simple as a properties file work? All I really need right now
> are a few name/value pairs.
Yes, it would work for me at least.
Currently we use system properties in various places.
RG
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
>
>> Another question - how does the Java QPID client get its config?
>> Purely from the
>> AMQP connect URL or is there a configuration mechanism similar to the
>> code in
>> the server? I'm trying to find a place to read in keystore paths,
>> passwords and
>> other types of useful SSL config info but haven't found it yet. I
>> _could_ put
>> this info on the URL but I'm concerned it would make for a very long
>> URL and
>> also introduce security issues since the keystore password would be
>> embedded > in
>> the URL also.
>
> Ah yes, this is an area we have sidestepped so far. The reason was
> that I didn't want to introduce another dependency in the client (e.g.
> on commons-configuration).
>
> So we really need a configuration mechanism for the client, ideally
> that does not introduce any other dependencies.
>
> RG
>
Would something as simple as a properties file work? All I really need right now
are a few name/value pairs.
--Kevin
Re: QPID-6
Posted by Robert Greig <ro...@gmail.com>.
On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
> Another question - how does the Java QPID client get its config? Purely from the
> AMQP connect URL or is there a configuration mechanism similar to the code in
> the server? I'm trying to find a place to read in keystore paths, passwords and
> other types of useful SSL config info but haven't found it yet. I _could_ put
> this info on the URL but I'm concerned it would make for a very long URL and
> also introduce security issues since the keystore password would be embedded > in
> the URL also.
Ah yes, this is an area we have sidestepped so far. The reason was
that I didn't want to introduce another dependency in the client (e.g.
on commons-configuration).
So we really need a configuration mechanism for the client, ideally
that does not introduce any other dependencies.
RG
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Kevin Smith wrote:
> Robert Greig wrote:
>> On 22/01/07, Kevin Smith <ks...@redhat.com> wrote:
>>> I'm going to take a swing at implementing this as a way to learn
>>> parts of the
>>> codebase. Are there any example config files in the tree I could look
>>> at to see
>>> how we're structuring the configs?
>>
>> That's a good one to start with.
>>
>> You might find this page in the wiki useful:
>> http://cwiki.apache.org/confluence/display/qpid/Qpid+Design+-+Configuration
>>
>>
>> Let us know if you have any questions though.
>>
>> RG
>>
>
> OK. I've had a chance to look at the docs, and I think I have a handle
> on how to do this. I'm thinking of adding a <ssl></ssl> block to the
> configs containing all the info needed to fully configure the SSL
> context factory:
>
> <ssl>
> <keystore-path>/some/path/to/keystore.ks</keystore-path>
> <keystore-password>some_password</keystore-password>
> <cert-type>SunX509</cert-type>
> </ssl>
>
> I do have a couple of questions surrounding this though:
>
> 1) Does more need to be configurable? For example, would we ever use a
> protocol other than TLS for the SSLContext? My experience with SSL is
> limited so it's quite likely I'm missing some use cases here.
>
> 2) Does this config need to be interchangeable with the C++ broker?
>
> Thoughts?
>
> --Kevin
>
Another question - how does the Java QPID client get its config? Purely from the
AMQP connect URL or is there a configuration mechanism similar to the code in
the server? I'm trying to find a place to read in keystore paths, passwords and
other types of useful SSL config info but haven't found it yet. I _could_ put
this info on the URL but I'm concerned it would make for a very long URL and
also introduce security issues since the keystore password would be embedded in
the URL also.
--Kevin
Authentication (RE: QPID-6)
Posted by Tomas Restrepo <to...@devdeo.com>.
Hi Robert,
> The other thing we definitely need to be able to support is mutual
> authentication with SSL - i.e. the client must present a certificate
> to the broker as well as the other way round.
Mutual authentication would be a good features, though it does bring up a
question: Isn't it a bit redundant to have client-side certificates for
authentication and then for the client to also have to use SASL to
authenticate yet again? Which of the two identity tokens would then be used
for authorizing access to resources?
And while we're at it, would someone find also useful to support anonymous
(i.e. unauthenticated) access to the server for some scenarios? (the easiest
way would be by supporting the ANONYMOUS mechanism per RFC 2245).
Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
>
>> OK. I've had a chance to look at the docs, and I think I have a handle
>> on how to
>> do this. I'm thinking of adding a <ssl></ssl> block to the configs
>> containing
>> all the info needed to fully configure the SSL context factory:
>>
>> <ssl>
>> <keystore-path>/some/path/to/keystore.ks</keystore-path>
>> <keystore-password>some_password</keystore-password>
>> <cert-type>SunX509</cert-type>
>> </ssl>
>
> This looks good.
>
>> I do have a couple of questions surrounding this though:
>>
>> 1) Does more need to be configurable? For example, would we ever use a
>> protocol
>> other than TLS for the SSLContext? My experience with SSL is limited
>> so it's
>> quite likely I'm missing some use cases here.
>
> I think TLS 1.0 is the only one that is going to be used. Until of
> course someone invents TLS 2.0 :-). Whether we want to put a
> placeholder for this now, I'm not sure and I don't think it's a
> biggie.
>
> We probably want to have a section for a keystore to contain the
> certificates of any certificate authorities (i.e. separate from the
> identity keystore) that need to be trusted by the broker.
>
> The other thing we definitely need to be able to support is mutual
> authentication with SSL - i.e. the client must present a certificate
> to the broker as well as the other way round.
>
> One thing that does occur to me is that some people might want to use
> a different JCE provider. For example, nCipher
> (http://www.ncipher.com) provide a hardware SSL solution (i.e.
> offloading SSL to a separate processor) and use a custom JCE provider.
> I have never done it but it might be useful to look at how you go
> about setting up a custom JCE provider and whether we need to do
> anything special to support that.
>
>> 2) Does this config need to be interchangeable with the C++ broker?
>
> I'm not sure any of our config is interchangable with the C++ broker.
>
> RG
>
This seems to me to be a co-mingling of two related issues. The first, which is
what I'm doing right now, is how to make the currently hardcoded SSL parameters
configurable. The second, which follows after the first, is what kind of
capabilities do we want to layer on top of SSL support. I'd like to get the
first point done and committed before figuring out the second.
--Kevin
Re: QPID-6
Posted by John O'Hara <jo...@gmail.com>.
Whatever we do:
1) We shouldn't invent anything new here. We should taks from the Apache
tradition too.
2) It would be fab if there was some commonality between Java and C++ broker
config. We want to look like one project, don't we :-)
John
On 25/01/07, Andrew Stitcher <as...@redhat.com> wrote:
>
> On Wed, 2007-01-24 at 13:24 -0500, Nuno Santos wrote:
> > ...
> > My understanding, having only started looking into the C++ broker a
> > couple of days ago (coincidentally, to start implementing security and
> > bring it up to par with the Java broker), is that there's no actual
> > configuration files, all options are passed on the command line.
> >
> > I understand and respect that there's been an effort to keep
> > configuration to an absolute minimum on the C++ broker, so maybe we can
> > follow that lead and keep SSL-related config as command line
> > parameters...
>
> The point about there being no configuration isn't whether it's
> specified on the cmd line or in a config file - both of these are
> equally configuration.
>
> It's that there should be no arbitrary parameters for the admin to
> decide as it's usually hard to choose parameters like this - for
> instance buffer sizes or timeouts. It's not that if you need to pass a
> certificate file into the SSL that you use the cmd line rather than a
> config file.
>
> In principle I don't think there is any reason not to use a config file
> - it's just not needed this kind of configuration yet. It looks like SSL
> is going to provide a good justification for needing a config file, in
> which case we will have to decide on a file format.
>
> My preference for config file format would currently be YAML
> (http://www.yaml.org/). As there are implementations for lots of
> languages and the file format is easy to read and write by a person
> (unlike XML).
>
> It would obviously be beneficial for the C++ broker to use the same
> config file as the Java broker for ease of transistion so this would be
> another consideration. However then we would presumably need to add XML
> persing into the C++ broker (in my experience big and unwieldy) just for
> the config file.
>
> Andrew
>
>
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Andrew Stitcher wrote:
> On Wed, 2007-01-24 at 13:24 -0500, Nuno Santos wrote:
>> ...
>> My understanding, having only started looking into the C++ broker a
>> couple of days ago (coincidentally, to start implementing security and
>> bring it up to par with the Java broker), is that there's no actual
>> configuration files, all options are passed on the command line.
>>
>> I understand and respect that there's been an effort to keep
>> configuration to an absolute minimum on the C++ broker, so maybe we can
>> follow that lead and keep SSL-related config as command line
>> parameters...
>
> The point about there being no configuration isn't whether it's
> specified on the cmd line or in a config file - both of these are
> equally configuration.
>
> It's that there should be no arbitrary parameters for the admin to
> decide as it's usually hard to choose parameters like this - for
> instance buffer sizes or timeouts. It's not that if you need to pass a
> certificate file into the SSL that you use the cmd line rather than a
> config file.
>
> In principle I don't think there is any reason not to use a config file
> - it's just not needed this kind of configuration yet. It looks like SSL
> is going to provide a good justification for needing a config file, in
> which case we will have to decide on a file format.
>
> My preference for config file format would currently be YAML
> (http://www.yaml.org/). As there are implementations for lots of
> languages and the file format is easy to read and write by a person
> (unlike XML).
>
> It would obviously be beneficial for the C++ broker to use the same
> config file as the Java broker for ease of transistion so this would be
> another consideration. However then we would presumably need to add XML
> persing into the C++ broker (in my experience big and unwieldy) just for
> the config file.
>
> Andrew
>
>
Either format would work for me. I was looking at XML first since the Java
broker already has infrastructure in place to populate a configuration-based
object graph with values from XML. It seems that commons-configuration doesn't
have YAML support out-of-the-box, but it might not be that hard to add. If this
is the path we want to go down, I'd advocate for moving any existing
configuration files to YAML as well.
I think a config file is the right place to store SSL configuration information,
at least for the Java broker, because there are things like the keystore
password which should be protected and not easily snoopable.
--Kevin
Re: QPID-6
Posted by John O'Hara <jo...@gmail.com>.
Sorry - <include> tag, should beg borrow and stral from ANT, HTTPD, and
anything else which has "pretty" XML
On 31/01/07, John O'Hara <jo...@gmail.com> wrote:
>
> Oh, but we do need an "include" directive to make it easier to structure
> the config files, and for certain security reasons.
>
> On 30/01/07, Marnie McCormack <ma...@googlemail.com> wrote:
> >
> > I'm definitely ...
> >
> > +1 XML -1 YAML
> >
> > I agree with the feedback on using a well established standard with
> > loads of
> > parsers.
> >
> > Marnie
> >
> >
>
Re: QPID-6
Posted by John O'Hara <jo...@gmail.com>.
Oh, but we do need an "include" directive to make it easier to structure the
config files, and for certain security reasons.
On 30/01/07, Marnie McCormack <ma...@googlemail.com> wrote:
>
> I'm definitely ...
>
> +1 XML -1 YAML
>
> I agree with the feedback on using a well established standard with loads
> of
> parsers.
>
> Marnie
>
>
Re: QPID-6
Posted by Marnie McCormack <ma...@googlemail.com>.
I'm definitely ...
+1 XML -1 YAML
I agree with the feedback on using a well established standard with loads of
parsers.
Marnie
Re: QPID-6
Posted by Rupert Smith <ru...@googlemail.com>.
I would prefer something a little more artistic, something that would let us
compose a config that rolls off the tongue. How about this?
http://shakespearelang.sourceforge.net/
"According to the Authors, the language has the expressiveness of BASIC and
the user friendliness of assembly language."
- Rupert
On 1/29/07, John O'Hara <jo...@gmail.com> wrote:
>
> Or we could use LISP like emacs, for the ultimate in configurability
>
> On 29/01/07, John O'Hara <jo...@gmail.com> wrote:
> >
> > Guys WE ARE PART OF APACHE!
> >
> > Can we do what the rest of the Apache family does for configuration, and
> > not invent our own just for the sake of personal preference.
> >
> > No one likes XML; but at the same time I have *never* seen a config file
> > in YAML syntax!
> > Sysadmins are used to Apache's HTTPD.CONF file format, and XML.
> > So long as we don't get into name space sillyness, it won't look too
> > offensive.
> >
> > Let's not alienate all of potential our users at once ;-)
> >
> > Pretty please with sugar
> > John
> >
> > On 29/01/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > -1 YAML +1 XML
> > >
> > > Why throw away such a well established standard to use something
> > > experimental? Especially given that there are so many libraries
> already
> > > based around XML.
> > >
> > > Is XML really so hard to write by hand? Sorry for having a negative
> > > opinion, but this just seems like using something different for the
> sake
> > of
> > > it, without any really compeling reason to do so.
> > >
> > > Rupert
> > >
> > > On 1/26/07, Alan Conway <ac...@redhat.com> wrote:
> > > >
> > > > On Thu, 2007-01-25 at 20:44 -0500, Jesus M. Rodriguez wrote:
> > > > > While I like flexibility, I think one or the other (yaml or xml)
> is
> > > > > better. I've never been
> > > > > a fan of XML configuration files, I've found that simple property
> > > > > value files were
> > > > > sufficient for most things, but YAML seems to give a simple file
> > format
> > > > that is
> > > > > easy to both read and edit.
> > > > >
> > > > > +1 YAML
> > > > > -1 XML
> > > > >
> > > >
> > > > I'm with you all the way. My point was only that if we go with a
> YAML
> > > > solution it won't *prevent* us from accommodating an XML
> presentation
> > > > if/when we ever need to - hopefully we won't ;) We should definitely
> > > > start with YAML.
> > > >
> > > > Cheers,
> > > > Alan.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
Re: QPID-6
Posted by John O'Hara <jo...@gmail.com>.
Or we could use LISP like emacs, for the ultimate in configurability
On 29/01/07, John O'Hara <jo...@gmail.com> wrote:
>
> Guys WE ARE PART OF APACHE!
>
> Can we do what the rest of the Apache family does for configuration, and
> not invent our own just for the sake of personal preference.
>
> No one likes XML; but at the same time I have *never* seen a config file
> in YAML syntax!
> Sysadmins are used to Apache's HTTPD.CONF file format, and XML.
> So long as we don't get into name space sillyness, it won't look too
> offensive.
>
> Let's not alienate all of potential our users at once ;-)
>
> Pretty please with sugar
> John
>
> On 29/01/07, Rupert Smith <ru...@googlemail.com> wrote:
> > -1 YAML +1 XML
> >
> > Why throw away such a well established standard to use something
> > experimental? Especially given that there are so many libraries already
> > based around XML.
> >
> > Is XML really so hard to write by hand? Sorry for having a negative
> > opinion, but this just seems like using something different for the sake
> of
> > it, without any really compeling reason to do so.
> >
> > Rupert
> >
> > On 1/26/07, Alan Conway <ac...@redhat.com> wrote:
> > >
> > > On Thu, 2007-01-25 at 20:44 -0500, Jesus M. Rodriguez wrote:
> > > > While I like flexibility, I think one or the other (yaml or xml) is
> > > > better. I've never been
> > > > a fan of XML configuration files, I've found that simple property
> > > > value files were
> > > > sufficient for most things, but YAML seems to give a simple file
> format
> > > that is
> > > > easy to both read and edit.
> > > >
> > > > +1 YAML
> > > > -1 XML
> > > >
> > >
> > > I'm with you all the way. My point was only that if we go with a YAML
> > > solution it won't *prevent* us from accommodating an XML presentation
> > > if/when we ever need to - hopefully we won't ;) We should definitely
> > > start with YAML.
> > >
> > > Cheers,
> > > Alan.
> > >
> > >
> > >
> > >
> >
> >
>
Re: QPID-6
Posted by John O'Hara <jo...@gmail.com>.
Guys WE ARE PART OF APACHE!
Can we do what the rest of the Apache family does for configuration, and not
invent our own just for the sake of personal preference.
No one likes XML; but at the same time I have *never* seen a config file in
YAML syntax!
Sysadmins are used to Apache's HTTPD.CONF file format, and XML.
So long as we don't get into name space sillyness, it won't look too
offensive.
Let's not alienate all of potential our users at once ;-)
Pretty please with sugar
John
On 29/01/07, Rupert Smith <ru...@googlemail.com> wrote:
> -1 YAML +1 XML
>
> Why throw away such a well established standard to use something
> experimental? Especially given that there are so many libraries already
> based around XML.
>
> Is XML really so hard to write by hand? Sorry for having a negative
> opinion, but this just seems like using something different for the sake
of
> it, without any really compeling reason to do so.
>
> Rupert
>
> On 1/26/07, Alan Conway <ac...@redhat.com> wrote:
> >
> > On Thu, 2007-01-25 at 20:44 -0500, Jesus M. Rodriguez wrote:
> > > While I like flexibility, I think one or the other (yaml or xml) is
> > > better. I've never been
> > > a fan of XML configuration files, I've found that simple property
> > > value files were
> > > sufficient for most things, but YAML seems to give a simple file
format
> > that is
> > > easy to both read and edit.
> > >
> > > +1 YAML
> > > -1 XML
> > >
> >
> > I'm with you all the way. My point was only that if we go with a YAML
> > solution it won't *prevent* us from accommodating an XML presentation
> > if/when we ever need to - hopefully we won't ;) We should definitely
> > start with YAML.
> >
> > Cheers,
> > Alan.
> >
> >
> >
> >
>
>
Re: QPID-6
Posted by Rupert Smith <ru...@googlemail.com>.
-1 YAML +1 XML
Why throw away such a well established standard to use something
experimental? Especially given that there are so many libraries already
based around XML.
Is XML really so hard to write by hand? Sorry for having a negative
opinion, but this just seems like using something different for the sake of
it, without any really compeling reason to do so.
Rupert
On 1/26/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Thu, 2007-01-25 at 20:44 -0500, Jesus M. Rodriguez wrote:
> > While I like flexibility, I think one or the other (yaml or xml) is
> > better. I've never been
> > a fan of XML configuration files, I've found that simple property
> > value files were
> > sufficient for most things, but YAML seems to give a simple file format
> that is
> > easy to both read and edit.
> >
> > +1 YAML
> > -1 XML
> >
>
> I'm with you all the way. My point was only that if we go with a YAML
> solution it won't *prevent* us from accommodating an XML presentation
> if/when we ever need to - hopefully we won't ;) We should definitely
> start with YAML.
>
> Cheers,
> Alan.
>
>
>
>
Re: QPID-6
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2007-01-25 at 20:44 -0500, Jesus M. Rodriguez wrote:
> While I like flexibility, I think one or the other (yaml or xml) is
> better. I've never been
> a fan of XML configuration files, I've found that simple property
> value files were
> sufficient for most things, but YAML seems to give a simple file format that is
> easy to both read and edit.
>
> +1 YAML
> -1 XML
>
I'm with you all the way. My point was only that if we go with a YAML
solution it won't *prevent* us from accommodating an XML presentation
if/when we ever need to - hopefully we won't ;) We should definitely
start with YAML.
Cheers,
Alan.
Re: QPID-6
Posted by "Jesus M. Rodriguez" <jm...@gmail.com>.
On 1/25/07, Alan Conway <ac...@redhat.com> wrote:
> On Thu, 2007-01-25 at 11:20 +0000, Andrew Stitcher wrote:
> > My preference for config file format would currently be YAML
> > (http://www.yaml.org/). As there are implementations for lots of
> > languages and the file format is easy to read and write by a person
> > (unlike XML).
> >
> > It would obviously be beneficial for the C++ broker to use the same
> > config file as the Java broker for ease of transistion so this would be
> > another consideration. However then we would presumably need to add XML
> > persing into the C++ broker (in my experience big and unwieldy) just for
> > the config file.
>
>
> yaml looks good to me, and it still lets us support the XML fetishists
> out there. From http://www.yaml.org/xml.html :
>
> "For those who love YAML, but require buzz-word compliance or require
> XML angle brackets, there is a clean option -- a subset of XML which has
> YAML's information model, but XML's syntax. Since a YAML stream may not
> start with a '<' character, a YAML implementation could implement an
> implicit, automatic conversion of XML in this schema to the equivalent
> YAML. As a proof of concept, a XSLT Stylesheet is provided, along with
> the canonical invoice example in XML using this schema.
>
> Cheers,
> Alan.
>
>
While I like flexibility, I think one or the other (yaml or xml) is
better. I've never been
a fan of XML configuration files, I've found that simple property
value files were
sufficient for most things, but YAML seems to give a simple file format that is
easy to both read and edit.
+1 YAML
-1 XML
jesus
Re: YAML Configuration (Was Re: QPID-6)
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2007-01-26 at 09:33 -0500, Kevin Smith wrote:
> I'm planning on writing this using pure YAML for commons-configuration soonish
> (over the weekend). My plan is to get this into commons-configuration proper
> since they already have a bug open on this
> (http://issues.apache.org/jira/browse/CONFIGURATION-201).
>
>
> Thoughts?
>
> --Kevin
Sounds great. We'll need it in C++ too but it'll be easier if there's
already something to base it on in Java.
We'll need to think about naming conventions etc. so we can share useful
info between C++ and Java without creating conflicts over
language-specific items, but that's another conversation.
Cheers,
Alan.
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Greig <ro...@gmail.com>.
On 26/01/07, Robert Godfrey <ro...@gmail.com> wrote:
> > >
> > This is an interesting idea. We could do that for both the broker and the
> > client, assuming that there's a commons-configuration class which supports
> > the
> > user's desired format.
Maybe jarjar could be used to repackage commons-configuration so that
we can use it but not extend the client's dependency set.
commons-configuration does seem pretty good.
See http://tonicsystems.com/products/jarjar/
Has anyone used it?
RG
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Godfrey <ro...@gmail.com>.
> >
> > Given that we cannot control the context in which the client library is
> > deployed, I think we need to be flexible in the way in which these
> > configuration options can be set. That is I think that it should be
> > possible to configure the library by passing in a
> > commons.Configurationobject. In that sense for the (Java) client I
> > think the decision over XML
> > vs YAML vs Properties file etc may be something of a red-herring.
> > However I
> > am +1 for using XML as the default and as the basis for a common
> > configuration style between clients / brokers of all languages.
>
> This is an interesting idea. We could do that for both the broker and the
> client, assuming that there's a commons-configuration class which supports
> the
> user's desired format.
I've no idea what exists in the C++ world (if anything) that gives similar
flexibility... so having a common "QPID" format (in XML) still makes sense
to me. However, certainly for the client I think it is essential we let the
use of the library decide where they source their configuration from (they
themselves may not have much choice).
>
> > A couple of quick questions...
> >
> > With the Java Client changes, will the client now always require a
> > configuration file? [ I hope not :-) ]
>
> The client would only require a config file if you wanted to configure
> options
> which would require a config file :-) Right now, this would mean SSL, but
> it
> could mean other options down the road. It should still be possible to get
> the
> client running without a config file.
Again - I think it is essential that the client can run without
configuration (pretty much as it does now)... we want to make it as easy as
possible to just drop in the appropriate jars and start using, without
having to worry about a myriad of config files (I'm starting to sound like
Alan)
... And at what level are you
> > planning to make these options configurable (application instance or
> > connection being the two most obvious).
>
> I haven't dug into the client code yet so I can't really say at what level
> is
> the most practical. Now that we've got the XML/YAML thing put to bed, I'll
> be
> looking at this shortly. I'd like to add it at the most flexible point
> possible
> (connection), but that will depend on what the code looks like.
Yes... thinking about it, the most obvious thing is that you look up
connection strings by name (in a config file, through JNDI or whatever).
You also then want to get the configure options for that connection (e.g. if
your connection is called MY_CONNECTION then you might want to get a config
value option by looking up MY_CONNECTION.<config option name> with further
levels of nesting if necessary).
-- Rob
Re: YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Kevin Smith wrote:
> Robert Greig wrote:
>> On 26/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
>>
>>> It's OK for a broker to depend on explicit configuration, but a client
>>> library is usually used in very different contexts, and at least in
>>> some of
>>> those forcing external configuration is going to cause a lot of
>>> troubles.
>>> Likewise, it's very OK to be able to use external configuration (an
>>> XML file
>>> for example) as an *alternative* to the API, but shouldn't be the
>>> only way
>>> to set options like this, I think.
>>
>> Yes, agree completely.
>>
>> RG
>>
> OK. I feel like I haven't been clear about my intentions wrt the client.
> Let me outline what I've gotten written for the client:
>
> 1) org.apache.qpid.client.SSLConfiguration class which contains three
> pieces of info: keystore file path, keystore password, and cert type
> (defaults to "SunX509").
>
> 2) Modifications to the constructors on
> org.apache.qpid.client.AMQConnection to accept an additional
> SSLConfiguration argument.
>
> 3) Changed the logic in org.apache.qpid.client.AMQProtocolHandler to get
> the SSLConfiguration from it's parent AMQConnection and call the
> SSLContextFactory (from qpid commons) to create a SSLContext to pass to
> Mina.
>
> So, from a coding perspective the only thing which a developer needs to
> do to enable SSL is create an instance of SSLConfiguration with the
> appropriate information and then use that instance when creating a
> AMQConnection instance directly or via a AMQConnectionFactory.
>
> I still have some cleanup to do with FailoverHandler and write a few
> tests, but the basic work is done (I think). I think this satisfies the
> requirements I've heard on the list.
>
> --Kevin
>
I also wanted to mention that the code changes for the broker and commons are
attached as a patch to the JIRA issue, if anyone wants to take a look at that.
--Kevin
Re: YAML Configuration (Was Re: QPID-6)
Posted by Carl Trieloff <cc...@redhat.com>.
Kevin,
I think what you describe seems good. I am not sure we even need to add
any config as these options can easily be set pragmatically. I would be
inclined to do examples and leave it to the user to decide how to store
the options as config if they want to.
Carl.
Kevin Smith wrote:
> Robert Greig wrote:
>> On 26/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
>>
>>> It's OK for a broker to depend on explicit configuration, but a client
>>> library is usually used in very different contexts, and at least in
>>> some of
>>> those forcing external configuration is going to cause a lot of
>>> troubles.
>>> Likewise, it's very OK to be able to use external configuration (an
>>> XML file
>>> for example) as an *alternative* to the API, but shouldn't be the
>>> only way
>>> to set options like this, I think.
>>
>> Yes, agree completely.
>>
>> RG
>>
> OK. I feel like I haven't been clear about my intentions wrt the
> client. Let me outline what I've gotten written for the client:
>
> 1) org.apache.qpid.client.SSLConfiguration class which contains three
> pieces of info: keystore file path, keystore password, and cert type
> (defaults to "SunX509").
>
> 2) Modifications to the constructors on
> org.apache.qpid.client.AMQConnection to accept an additional
> SSLConfiguration argument.
>
> 3) Changed the logic in org.apache.qpid.client.AMQProtocolHandler to
> get the SSLConfiguration from it's parent AMQConnection and call the
> SSLContextFactory (from qpid commons) to create a SSLContext to pass
> to Mina.
>
> So, from a coding perspective the only thing which a developer needs
> to do to enable SSL is create an instance of SSLConfiguration with the
> appropriate information and then use that instance when creating a
> AMQConnection instance directly or via a AMQConnectionFactory.
>
> I still have some cleanup to do with FailoverHandler and write a few
> tests, but the basic work is done (I think). I think this satisfies
> the requirements I've heard on the list.
>
> --Kevin
Re: YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 26/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
>
>> It's OK for a broker to depend on explicit configuration, but a client
>> library is usually used in very different contexts, and at least in
>> some of
>> those forcing external configuration is going to cause a lot of troubles.
>> Likewise, it's very OK to be able to use external configuration (an
>> XML file
>> for example) as an *alternative* to the API, but shouldn't be the only
>> way
>> to set options like this, I think.
>
> Yes, agree completely.
>
> RG
>
OK. I feel like I haven't been clear about my intentions wrt the client. Let me
outline what I've gotten written for the client:
1) org.apache.qpid.client.SSLConfiguration class which contains three pieces of
info: keystore file path, keystore password, and cert type (defaults to "SunX509").
2) Modifications to the constructors on org.apache.qpid.client.AMQConnection to
accept an additional SSLConfiguration argument.
3) Changed the logic in org.apache.qpid.client.AMQProtocolHandler to get the
SSLConfiguration from it's parent AMQConnection and call the SSLContextFactory
(from qpid commons) to create a SSLContext to pass to Mina.
So, from a coding perspective the only thing which a developer needs to do to
enable SSL is create an instance of SSLConfiguration with the appropriate
information and then use that instance when creating a AMQConnection instance
directly or via a AMQConnectionFactory.
I still have some cleanup to do with FailoverHandler and write a few tests, but
the basic work is done (I think). I think this satisfies the requirements I've
heard on the list.
--Kevin
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Greig <ro...@gmail.com>.
On 26/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
> It's OK for a broker to depend on explicit configuration, but a client
> library is usually used in very different contexts, and at least in some of
> those forcing external configuration is going to cause a lot of troubles.
> Likewise, it's very OK to be able to use external configuration (an XML file
> for example) as an *alternative* to the API, but shouldn't be the only way
> to set options like this, I think.
Yes, agree completely.
RG
Re: YAML Configuration (Was Re: QPID-6)
Posted by John O'Hara <jo...@gmail.com>.
How do OTHER Apache projects manage keyfiles and encryption bits and bobs?
We're not the first, I'm sure.
Also, at Apache there seems to be a strong tradition of XML style config
files -- even the style of the original httpd.conf file.
Let's keep with the Apache culture.
We should look at hot Tomcat and HTTPD and the Directory Project manage
client and server SSL settings...... who ever is interested in coding this
should #include one of those.
John
On 26/01/07, Colin Crist <co...@hermesjms.com> wrote:
>
>
> > >
> > > A couple of quick questions...
> > >
> > > With the Java Client changes, will the client now always require a
> > > configuration file? [ I hope not :-) ]
> >
> > The client would only require a config file if you wanted to
> > configure options which would require a config file :-) Right
> > now, this would mean SSL, but it could mean other options
> > down the road. It should still be possible to get the client
> > running without a config file.
>
> Applications, especailly in house ones, have enough configuration files as
> it is without requiring them to have yet another one for a messaging
> product.
>
> I personally try and get all my configuration into an RDBMS (if I've got
> one
> already) for example and avoid files but that does not work for all. I
> certainly don't mind files for server side config but the client is part
> of
> a bigger picture the less you dictate deployment to the user the better.
>
> What particular bit of SSL needs reference to a file? Can I not also just
> use strings as well in the ConnectionFactory so you get files and other
> sources of config? Files are fine for som3, but its good to give options
> for
> others.
>
> Finally, if I bind a connection factory into JNDI then files don't work.
>
> Regards,
>
> Colin.
>
>
>
>
Re: YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Tomas Restrepo wrote:
> Hi Kevin,
>
>>> With the Java Client changes, will the client now always require a
>>> configuration file? [ I hope not :-) ]
>> The client would only require a config file if you wanted to configure
>> options
>> which would require a config file :-)
>
> I can't speak about the Java client per se since I don't know about how
> people expect to use it. However, I'm collaborating a bit on the .NET client
> and wondering a lot about some of the same issues you're talking about
> (including the SSL support which hasn't been added yet).
>
> Given this, I know how I'd like to use the .NET client for some stuff and
> things like SSL should definitely be configurable from code without needing
> an external configuration file, at least from in my very humble opinion. I
> would think that at the very least, the option to enable SSL or not as well
> as the client certificate should be easily exposed programmatically at the
> time the connection to the broker is opened, and I was thinking that
> exposing this in some way in the ConnectionInfo sounded like the a
> reasonable approach.
>
> It's OK for a broker to depend on explicit configuration, but a client
> library is usually used in very different contexts, and at least in some of
> those forcing external configuration is going to cause a lot of troubles.
> Likewise, it's very OK to be able to use external configuration (an XML file
> for example) as an *alternative* to the API, but shouldn't be the only way
> to set options like this, I think.
+1. This is what I was thinking. The approach I took with the broker was to add
API to allow it to be configured and then added the logic in the config layer to
call the appropriate API with the values from the file.
I was going to do something very similar for the client.
>
> Then again, it's just my opinion :)
>
> Tomas Restrepo
> tomas.restrepo@devdeo.com
> http://www.winterdom.com/weblog/
>
>
>
>
RE: YAML Configuration (Was Re: QPID-6)
Posted by Tomas Restrepo <to...@devdeo.com>.
Hi Kevin,
> > With the Java Client changes, will the client now always require a
> > configuration file? [ I hope not :-) ]
>
> The client would only require a config file if you wanted to configure
> options
> which would require a config file :-)
I can't speak about the Java client per se since I don't know about how
people expect to use it. However, I'm collaborating a bit on the .NET client
and wondering a lot about some of the same issues you're talking about
(including the SSL support which hasn't been added yet).
Given this, I know how I'd like to use the .NET client for some stuff and
things like SSL should definitely be configurable from code without needing
an external configuration file, at least from in my very humble opinion. I
would think that at the very least, the option to enable SSL or not as well
as the client certificate should be easily exposed programmatically at the
time the connection to the broker is opened, and I was thinking that
exposing this in some way in the ConnectionInfo sounded like the a
reasonable approach.
It's OK for a broker to depend on explicit configuration, but a client
library is usually used in very different contexts, and at least in some of
those forcing external configuration is going to cause a lot of troubles.
Likewise, it's very OK to be able to use external configuration (an XML file
for example) as an *alternative* to the API, but shouldn't be the only way
to set options like this, I think.
Then again, it's just my opinion :)
Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/
RE: YAML Configuration (Was Re: QPID-6)
Posted by Colin Crist <co...@hermesjms.com>.
> >
> > A couple of quick questions...
> >
> > With the Java Client changes, will the client now always require a
> > configuration file? [ I hope not :-) ]
>
> The client would only require a config file if you wanted to
> configure options which would require a config file :-) Right
> now, this would mean SSL, but it could mean other options
> down the road. It should still be possible to get the client
> running without a config file.
Applications, especailly in house ones, have enough configuration files as
it is without requiring them to have yet another one for a messaging
product.
I personally try and get all my configuration into an RDBMS (if I've got one
already) for example and avoid files but that does not work for all. I
certainly don't mind files for server side config but the client is part of
a bigger picture the less you dictate deployment to the user the better.
What particular bit of SSL needs reference to a file? Can I not also just
use strings as well in the ConnectionFactory so you get files and other
sources of config? Files are fine for som3, but its good to give options for
others.
Finally, if I bind a connection factory into JNDI then files don't work.
Regards,
Colin.
Re: YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Robert Godfrey wrote:
> Hi Kevin,
>
>> I've already attached a patch to the JIRA for the Java broker changes.
>> Once we
>> > can agree on one or the other I'll be able to finish the Java client
>> work.
>>
>> I think a (simple!) XML configuration file will do the trick and fully
>> support that.
>
>
> Given that we cannot control the context in which the client library is
> deployed, I think we need to be flexible in the way in which these
> configuration options can be set. That is I think that it should be
> possible to configure the library by passing in a
> commons.Configurationobject. In that sense for the (Java) client I
> think the decision over XML
> vs YAML vs Properties file etc may be something of a red-herring.
> However I
> am +1 for using XML as the default and as the basis for a common
> configuration style between clients / brokers of all languages.
This is an interesting idea. We could do that for both the broker and the
client, assuming that there's a commons-configuration class which supports the
user's desired format.
>
> A couple of quick questions...
>
> With the Java Client changes, will the client now always require a
> configuration file? [ I hope not :-) ]
The client would only require a config file if you wanted to configure options
which would require a config file :-) Right now, this would mean SSL, but it
could mean other options down the road. It should still be possible to get the
client running without a config file.
... And at what level are you
> planning to make these options configurable (application instance or
> connection being the two most obvious).
I haven't dug into the client code yet so I can't really say at what level is
the most practical. Now that we've got the XML/YAML thing put to bed, I'll be
looking at this shortly. I'd like to add it at the most flexible point possible
(connection), but that will depend on what the code looks like.
--Kevin
>
> Cheers,
> Rob
>
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Godfrey <ro...@gmail.com>.
Hi Kevin,
> I've already attached a patch to the JIRA for the Java broker changes.
> Once we
> > can agree on one or the other I'll be able to finish the Java client
> work.
>
> I think a (simple!) XML configuration file will do the trick and fully
> support that.
Given that we cannot control the context in which the client library is
deployed, I think we need to be flexible in the way in which these
configuration options can be set. That is I think that it should be
possible to configure the library by passing in a
commons.Configurationobject. In that sense for the (Java) client I
think the decision over XML
vs YAML vs Properties file etc may be something of a red-herring. However I
am +1 for using XML as the default and as the basis for a common
configuration style between clients / brokers of all languages.
A couple of quick questions...
With the Java Client changes, will the client now always require a
configuration file? [ I hope not :-) ] ... And at what level are you
planning to make these options configurable (application instance or
connection being the two most obvious).
Cheers,
Rob
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Greig <ro...@gmail.com>.
On 26/01/07, Kevin Smith <ks...@redhat.com> wrote:
> If I had really, really had to pick, I'd pick XML for two reasons: 1) we've
> already got XML config file support built in for the Java broker, and 2) people
> are generally more familiar with XML than YAML.
I agree with this.
> I think we should pick one config file formatting language and use it
> everywhere. Having YAML for the Java pieces and XML for C++ pieces (would this
> also include the Python and Ruby clients?) is not where I think we want to be.
Yes, agree also.
> I've already attached a patch to the JIRA for the Java broker changes. Once we
> can agree on one or the other I'll be able to finish the Java client work.
I think a (simple!) XML configuration file will do the trick and fully
support that.
RG
Re: YAML Configuration (Was Re: QPID-6)
Posted by Carl Trieloff <cc...@redhat.com>.
I think it would be safe to stick with XML. I would support that.
Carl.
Kevin Smith wrote:
> Robert Greig wrote:
>> On 26/01/07, Kevin Smith <ks...@redhat.com> wrote:
>>> I'm planning on writing this using pure YAML for
>>> commons-configuration soonish
>>> (over the weekend). My plan is to get this into
>>> commons-configuration proper
>>> since they already have a bug open on this
>>> (http://issues.apache.org/jira/browse/CONFIGURATION-201).
>>
>> I've looked at YAML briefly and we would still use xml for our java
>> broker deployments. Operate (i.e. support) teams are familiar with xml
>> and understand xml. I appreciate that may seem an odd comment to
>> people who have not worked extensively with operate teams. The yaml
>> native syntax is not exactly intuitive.
>>
>> The config file format is not for our benefit but that of our users.
>>
>> RG
>>
> So, I guess it boils down to do we want to use YAML or XML, then. My
> own goal is to address the obstacle which is currently blocking me on
> implementing SSL configuration, namely no configuration file
> infrastructure inside the Java client. Whether that config file is in
> YAML or XML doesn't matter that much to me.
>
> If I had really, really had to pick, I'd pick XML for two reasons: 1)
> we've already got XML config file support built in for the Java
> broker, and 2) people are generally more familiar with XML than YAML.
>
> I think we should pick one config file formatting language and use it
> everywhere. Having YAML for the Java pieces and XML for C++ pieces
> (would this also include the Python and Ruby clients?) is not where I
> think we want to be.
>
> I've already attached a patch to the JIRA for the Java broker changes.
> Once we can agree on one or the other I'll be able to finish the Java
> client work.
>
> --Kevin
Re: YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 26/01/07, Kevin Smith <ks...@redhat.com> wrote:
>> I'm planning on writing this using pure YAML for commons-configuration
>> soonish
>> (over the weekend). My plan is to get this into commons-configuration
>> proper
>> since they already have a bug open on this
>> (http://issues.apache.org/jira/browse/CONFIGURATION-201).
>
> I've looked at YAML briefly and we would still use xml for our java
> broker deployments. Operate (i.e. support) teams are familiar with xml
> and understand xml. I appreciate that may seem an odd comment to
> people who have not worked extensively with operate teams. The yaml
> native syntax is not exactly intuitive.
>
> The config file format is not for our benefit but that of our users.
>
> RG
>
So, I guess it boils down to do we want to use YAML or XML, then. My own goal is
to address the obstacle which is currently blocking me on implementing SSL
configuration, namely no configuration file infrastructure inside the Java
client. Whether that config file is in YAML or XML doesn't matter that much to me.
If I had really, really had to pick, I'd pick XML for two reasons: 1) we've
already got XML config file support built in for the Java broker, and 2) people
are generally more familiar with XML than YAML.
I think we should pick one config file formatting language and use it
everywhere. Having YAML for the Java pieces and XML for C++ pieces (would this
also include the Python and Ruby clients?) is not where I think we want to be.
I've already attached a patch to the JIRA for the Java broker changes. Once we
can agree on one or the other I'll be able to finish the Java client work.
--Kevin
Re: YAML Configuration (Was Re: QPID-6)
Posted by Robert Greig <ro...@gmail.com>.
On 26/01/07, Kevin Smith <ks...@redhat.com> wrote:
> I'm planning on writing this using pure YAML for commons-configuration soonish
> (over the weekend). My plan is to get this into commons-configuration proper
> since they already have a bug open on this
> (http://issues.apache.org/jira/browse/CONFIGURATION-201).
I've looked at YAML briefly and we would still use xml for our java
broker deployments. Operate (i.e. support) teams are familiar with xml
and understand xml. I appreciate that may seem an odd comment to
people who have not worked extensively with operate teams. The yaml
native syntax is not exactly intuitive.
The config file format is not for our benefit but that of our users.
RG
YAML Configuration (Was Re: QPID-6)
Posted by Kevin Smith <ks...@redhat.com>.
Alan Conway wrote:
> On Thu, 2007-01-25 at 11:20 +0000, Andrew Stitcher wrote:
>> My preference for config file format would currently be YAML
>> (http://www.yaml.org/). As there are implementations for lots of
>> languages and the file format is easy to read and write by a person
>> (unlike XML).
>>
>> It would obviously be beneficial for the C++ broker to use the same
>> config file as the Java broker for ease of transistion so this would be
>> another consideration. However then we would presumably need to add XML
>> persing into the C++ broker (in my experience big and unwieldy) just for
>> the config file.
>
>
> yaml looks good to me, and it still lets us support the XML fetishists
> out there. From http://www.yaml.org/xml.html :
>
> "For those who love YAML, but require buzz-word compliance or require
> XML angle brackets, there is a clean option -- a subset of XML which has
> YAML's information model, but XML's syntax. Since a YAML stream may not
> start with a '<' character, a YAML implementation could implement an
> implicit, automatic conversion of XML in this schema to the equivalent
> YAML. As a proof of concept, a XSLT Stylesheet is provided, along with
> the canonical invoice example in XML using this schema.
>
> Cheers,
> Alan.
>
>
I'm planning on writing this using pure YAML for commons-configuration soonish
(over the weekend). My plan is to get this into commons-configuration proper
since they already have a bug open on this
(http://issues.apache.org/jira/browse/CONFIGURATION-201).
Thoughts?
--Kevin
Re: QPID-6
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2007-01-25 at 11:20 +0000, Andrew Stitcher wrote:
> My preference for config file format would currently be YAML
> (http://www.yaml.org/). As there are implementations for lots of
> languages and the file format is easy to read and write by a person
> (unlike XML).
>
> It would obviously be beneficial for the C++ broker to use the same
> config file as the Java broker for ease of transistion so this would be
> another consideration. However then we would presumably need to add XML
> persing into the C++ broker (in my experience big and unwieldy) just for
> the config file.
yaml looks good to me, and it still lets us support the XML fetishists
out there. From http://www.yaml.org/xml.html :
"For those who love YAML, but require buzz-word compliance or require
XML angle brackets, there is a clean option -- a subset of XML which has
YAML's information model, but XML's syntax. Since a YAML stream may not
start with a '<' character, a YAML implementation could implement an
implicit, automatic conversion of XML in this schema to the equivalent
YAML. As a proof of concept, a XSLT Stylesheet is provided, along with
the canonical invoice example in XML using this schema.
Cheers,
Alan.
Re: QPID-6
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2007-01-24 at 13:24 -0500, Nuno Santos wrote:
> ...
> My understanding, having only started looking into the C++ broker a
> couple of days ago (coincidentally, to start implementing security and
> bring it up to par with the Java broker), is that there's no actual
> configuration files, all options are passed on the command line.
>
> I understand and respect that there's been an effort to keep
> configuration to an absolute minimum on the C++ broker, so maybe we can
> follow that lead and keep SSL-related config as command line
> parameters...
The point about there being no configuration isn't whether it's
specified on the cmd line or in a config file - both of these are
equally configuration.
It's that there should be no arbitrary parameters for the admin to
decide as it's usually hard to choose parameters like this - for
instance buffer sizes or timeouts. It's not that if you need to pass a
certificate file into the SSL that you use the cmd line rather than a
config file.
In principle I don't think there is any reason not to use a config file
- it's just not needed this kind of configuration yet. It looks like SSL
is going to provide a good justification for needing a config file, in
which case we will have to decide on a file format.
My preference for config file format would currently be YAML
(http://www.yaml.org/). As there are implementations for lots of
languages and the file format is easy to read and write by a person
(unlike XML).
It would obviously be beneficial for the C++ broker to use the same
config file as the Java broker for ease of transistion so this would be
another consideration. However then we would presumably need to add XML
persing into the C++ broker (in my experience big and unwieldy) just for
the config file.
Andrew
Re: QPID-6
Posted by Nuno Santos <ns...@redhat.com>.
Robert Greig wrote:
> On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
>> 2) Does this config need to be interchangeable with the C++ broker?
>
> I'm not sure any of our config is interchangable with the C++ broker.
My understanding, having only started looking into the C++ broker a
couple of days ago (coincidentally, to start implementing security and
bring it up to par with the Java broker), is that there's no actual
configuration files, all options are passed on the command line.
I understand and respect that there's been an effort to keep
configuration to an absolute minimum on the C++ broker, so maybe we can
follow that lead and keep SSL-related config as command line
parameters... on the other hand, if there's a large number of
configurable options, it may become too complicated to do it all from
the command line and I start seeing the need for a config file
(especially if there are no universally useful defaults). I don't feel
strongly either way, I'll defer this to the people who have worked on
the C++ broker more extensively.
One option that would enable reuse of the Java xml config while still
keeping the command line oriented nature of the C++ broker would be to
"wrap" the C++ broker binary with a script that would read the file and
pass the appropriate values as command line parameters. But that would
only push the issue onto a separate layer, not eliminate it.
Nuno
RE: Authentication (RE: QPID-6)
Posted by Tomas Restrepo <to...@devdeo.com>.
John,
>
> SASL supports client side certs.
Through EXTERNAL, yes, but maybe I'm missing something but I don't see
anything put up that would require a client to manage the SASL
authentication exchange using EXTERNAL instead of some other SASL mechanism.
Am I wrong here?
Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/
Re: Authentication (RE: QPID-6)
Posted by John O'Hara <jo...@gmail.com>.
You're right.
I think we should emulate XMPP (Jabber's) approach
http://www.xmpp.org/extensions/xep-0178.html
It also means we're not fully formed in the AMQP specification wrt
specifying how TLS gets started.
I've raised a JIRA over at AMQP for that :
https://wiki.108.redhat.com/jira/browse/AMQP-8
John
On 25/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
>
> John,
>
> >
> > SASL supports client side certs.
>
> Through EXTERNAL, yes, but maybe I'm missing something but I don't see
> anything put up that would require a client to manage the SASL
> authentication exchange using EXTERNAL instead of some other SASL
> mechanism.
> Am I wrong here?
>
>
> Tomas Restrepo
> tomas.restrepo@devdeo.com
> http://www.winterdom.com/weblog/
>
>
>
>
>
Re: Authentication (RE: QPID-6)
Posted by John O'Hara <jo...@gmail.com>.
SASL supports client side certs.
SASL supports everything, which is why we're using it :-)
On 25/01/07, Tomas Restrepo <to...@devdeo.com> wrote:
>
> Hi Robert,
>
> > The other thing we definitely need to be able to support is mutual
> > authentication with SSL - i.e. the client must present a certificate
> > to the broker as well as the other way round.
>
> Mutual authentication would be a good features, though it does bring up a
> question: Isn't it a bit redundant to have client-side certificates for
> authentication and then for the client to also have to use SASL to
> authenticate yet again? Which of the two identity tokens would then be
> used
> for authorizing access to resources?
>
> And while we're at it, would someone find also useful to support anonymous
> (i.e. unauthenticated) access to the server for some scenarios? (the
> easiest
> way would be by supporting the ANONYMOUS mechanism per RFC 2245).
>
>
> Tomas Restrepo
> tomas.restrepo@devdeo.com
> http://www.winterdom.com/weblog/
>
>
>
>
>
Re: QPID-6
Posted by Robert Greig <ro...@gmail.com>.
On 23/01/07, Kevin Smith <ks...@redhat.com> wrote:
> OK. I've had a chance to look at the docs, and I think I have a handle on how to
> do this. I'm thinking of adding a <ssl></ssl> block to the configs containing
> all the info needed to fully configure the SSL context factory:
>
> <ssl>
> <keystore-path>/some/path/to/keystore.ks</keystore-path>
> <keystore-password>some_password</keystore-password>
> <cert-type>SunX509</cert-type>
> </ssl>
This looks good.
> I do have a couple of questions surrounding this though:
>
> 1) Does more need to be configurable? For example, would we ever use a protocol
> other than TLS for the SSLContext? My experience with SSL is limited so it's
> quite likely I'm missing some use cases here.
I think TLS 1.0 is the only one that is going to be used. Until of
course someone invents TLS 2.0 :-). Whether we want to put a
placeholder for this now, I'm not sure and I don't think it's a
biggie.
We probably want to have a section for a keystore to contain the
certificates of any certificate authorities (i.e. separate from the
identity keystore) that need to be trusted by the broker.
The other thing we definitely need to be able to support is mutual
authentication with SSL - i.e. the client must present a certificate
to the broker as well as the other way round.
One thing that does occur to me is that some people might want to use
a different JCE provider. For example, nCipher
(http://www.ncipher.com) provide a hardware SSL solution (i.e.
offloading SSL to a separate processor) and use a custom JCE provider.
I have never done it but it might be useful to look at how you go
about setting up a custom JCE provider and whether we need to do
anything special to support that.
> 2) Does this config need to be interchangeable with the C++ broker?
I'm not sure any of our config is interchangable with the C++ broker.
RG
Re: QPID-6
Posted by Kevin Smith <ks...@redhat.com>.
Robert Greig wrote:
> On 22/01/07, Kevin Smith <ks...@redhat.com> wrote:
>> I'm going to take a swing at implementing this as a way to learn parts
>> of the
>> codebase. Are there any example config files in the tree I could look
>> at to see
>> how we're structuring the configs?
>
> That's a good one to start with.
>
> You might find this page in the wiki useful:
> http://cwiki.apache.org/confluence/display/qpid/Qpid+Design+-+Configuration
>
> Let us know if you have any questions though.
>
> RG
>
OK. I've had a chance to look at the docs, and I think I have a handle on how to
do this. I'm thinking of adding a <ssl></ssl> block to the configs containing
all the info needed to fully configure the SSL context factory:
<ssl>
<keystore-path>/some/path/to/keystore.ks</keystore-path>
<keystore-password>some_password</keystore-password>
<cert-type>SunX509</cert-type>
</ssl>
I do have a couple of questions surrounding this though:
1) Does more need to be configurable? For example, would we ever use a protocol
other than TLS for the SSLContext? My experience with SSL is limited so it's
quite likely I'm missing some use cases here.
2) Does this config need to be interchangeable with the C++ broker?
Thoughts?
--Kevin
Re: QPID-6
Posted by Robert Greig <ro...@gmail.com>.
On 22/01/07, Kevin Smith <ks...@redhat.com> wrote:
> I'm going to take a swing at implementing this as a way to learn parts of the
> codebase. Are there any example config files in the tree I could look at to see
> how we're structuring the configs?
That's a good one to start with.
You might find this page in the wiki useful:
http://cwiki.apache.org/confluence/display/qpid/Qpid+Design+-+Configuration
Let us know if you have any questions though.
RG