You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2016/02/18 00:11:40 UTC
QPID dispatch and SASL.
I'd like to improve the dispatch out-of-box experience and doc
regarding SASL. Our present experience is Doesn't Work By Default/No
Useful Errors/Nothing In Doc (apologies if I'm just being dim)
My use case is:
- install dispatch (using make install to /usr/local)
- start qdrouterd with no arguments, using installed default config
- run 'qdstat -g' to see something happen.
The installer installs:
/usr/local/etc/sasl2/qdrouterd.conf
The only documentation about SASL config is in comments in that file,
following those I did:
sudo saslpasswd2 -c -f /var/lib/qdrouterd/qdrouterd.sasldb -u QPID user
and set password "pass".
However this doesn't work:
PN_TRACE_FRM=1 qdstat -g -b user:pass@localhost
[0x563852c40550]: -> SASL
[0x563852c40550]: <- SASL
[0x563852c40550]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:"SCRAM-SHA-1", :GSSAPI, :"GSS-SPNEGO", :"DIGEST-MD5", :"CRAM-MD5", :PLAIN, :LOGIN, :ANONYMOUS]]
[0x563852c40550]: -> EOS
ConnectionException: Connection amqp://user:pass@localhost:amqp/$management disconnected
There are no useful log messages, the exception is completely unhelpful. Only using PN_TRACE_FRM=1 reveals this to be a SASL issue.
According to strace, qdrouterd never opens
/usr/local/etc/sasl2/qdrouterd.conf so I suspect there may be a problem
with the default install location.
I never understood the role of the SASL "domain" or why it should be
QPID for qdrouterd - can anyone explain? "user@QPID:pass@localhost"
seems like it would confuse the URL parser so I guess domain @QPID is a
built-in default or settable in some other way, but there's nothing
obvious in the qdstat -h output.
Why does saslpasswd2 have a -a "appname" argument? Should we be setting
it to qdrouterd to create qdrouterd users?
I volunteer to write some doc for this if anyone can explain it to me.
The only way I can get anything to work is to edit the config and add
"saslMechanisms: ANONYMOUS" on the acceptor.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Ganesh Murthy <gm...@redhat.com>.
Hi Alan,
Dispatch router has a "saslConfigPath"
"saslConfigPath": {
"type": "path",
"description": "Absolute path to the SASL configuration file.",
"required": false,
"create": true
},
which ultimately calls pn_sasl_config_path(sasl, qd_server->sasl_config_path)
Is this what you were looking for?
Thanks.
----- Original Message -----
From: "Alan Conway" <ac...@redhat.com>
To: dev@qpid.apache.org
Sent: Wednesday, February 24, 2016 10:53:20 AM
Subject: Re: QPID dispatch and SASL.
On Fri, 2016-02-19 at 14:32 +0000, Gordon Sim wrote:
> On 17/02/16 23:11, Alan Conway wrote:
> > According to strace, qdrouterd never opens
> > /usr/local/etc/sasl2/qdrouterd.conf so I suspect there may be a
> > problem
> > with the default install location.
>
> The PN_SASL_CONFIG environment variable lets you specify where it
> looks
> for that. (Though I agree with the general point that the default
> install ideally would be somewhere that did not need any explicit
> location to be specified).
>
Can the application tell proton where to look? The config file belongs
to the application (dispatch, qpidd etc.) not the proton library.
---------------------------------------------------------------------
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
Re: QPID dispatch and SASL.
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2016-02-19 at 14:32 +0000, Gordon Sim wrote:
> On 17/02/16 23:11, Alan Conway wrote:
> > According to strace, qdrouterd never opens
> > /usr/local/etc/sasl2/qdrouterd.conf so I suspect there may be a
> > problem
> > with the default install location.
>
> The PN_SASL_CONFIG environment variable lets you specify where it
> looks
> for that. (Though I agree with the general point that the default
> install ideally would be somewhere that did not need any explicit
> location to be specified).
>
Can the application tell proton where to look? The config file belongs
to the application (dispatch, qpidd etc.) not the proton library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Gordon Sim <gs...@redhat.com>.
On 17/02/16 23:11, Alan Conway wrote:
> According to strace, qdrouterd never opens
> /usr/local/etc/sasl2/qdrouterd.conf so I suspect there may be a problem
> with the default install location.
The PN_SASL_CONFIG environment variable lets you specify where it looks
for that. (Though I agree with the general point that the default
install ideally would be somewhere that did not need any explicit
location to be specified).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-02-24 at 14:17 -0500, Andrew Stitcher wrote:
> On Tue, 2016-02-23 at 07:49 -0800, Justin Ross wrote:
> > How will you avoid overwriting user config if you write to
> > /etc? You'll
> > need some sort of alternate extension, such as qdrouterd.conf.new.
> >
>
> I'll note that this discussion is pretty much the exact discussion we
> already had when arguing about where to install python, ruby etc.
> binding libraries:
>
> There is a system installation of something, and it (in general) is
> not
> looking for its modules (config files) in the installation prefix of
> proton, unless /usr is the installation prefix (which is not common
> unless you are building system packages)
Nope, not the same. The SASL config file is an *application* config
file. It belongs to qdrouterd. The SASL docs are clear that
/etc/sasl2/app.conf is an acceptable default location but that
applications can put it anywhere they want. Putting a qdrouterd config
file in the qdrouterd's install prefix (of course using the default
sasl path) *by default* seems like a sensible thing to do and allows us
to install a *working* dispatch configuration out of the box and to not
explode if you have say RPM and source installs on the same box.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-02-24 at 14:17 -0500, Andrew Stitcher wrote:
> On Tue, 2016-02-23 at 07:49 -0800, Justin Ross wrote:
> > How will you avoid overwriting user config if you write to
> > /etc? You'll
> > need some sort of alternate extension, such as qdrouterd.conf.new.
> >
>
> I'll note that this discussion is pretty much the exact discussion we
> already had when arguing about where to install python, ruby etc.
> binding libraries:
>
> There is a system installation of something, and it (in general) is
> not
> looking for its modules (config files) in the installation prefix of
> proton, unless /usr is the installation prefix (which is not common
> unless you are building system packages)
Nope, not the same. The SASL config file is an *application* config
file. It belongs to qdrouterd. The SASL docs are clear that
/etc/sasl2/app.conf is an acceptable default location but that
applications can put it anywhere they want. Putting a qdrouterd config
file in the qdrouterd's install prefix (of course using the default
sasl path) *by default* seems like a sensible thing to do and allows us
to install a *working* dispatch configuration out of the box and to not
explode if you have say RPM and source installs on the same box.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2016-02-23 at 07:49 -0800, Justin Ross wrote:
> How will you avoid overwriting user config if you write to
> /etc? You'll
> need some sort of alternate extension, such as qdrouterd.conf.new.
>
I'll note that this discussion is pretty much the exact discussion we
already had when arguing about where to install python, ruby etc.
binding libraries:
There is a system installation of something, and it (in general) is not
looking for its modules (config files) in the installation prefix of
proton, unless /usr is the installation prefix (which is not common
unless you are building system packages)
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2016-02-23 at 07:49 -0800, Justin Ross wrote:
> How will you avoid overwriting user config if you write to
> /etc? You'll
> need some sort of alternate extension, such as qdrouterd.conf.new.
>
I'll note that this discussion is pretty much the exact discussion we
already had when arguing about where to install python, ruby etc.
binding libraries:
There is a system installation of something, and it (in general) is not
looking for its modules (config files) in the installation prefix of
proton, unless /usr is the installation prefix (which is not common
unless you are building system packages)
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Alan Conway <ac...@redhat.com>.
Rant ahead. You have been warned.
On Wed, 2016-02-24 at 14:12 -0500, Andrew Stitcher wrote:
> But the library that is *depended on* specifies where it's
> configuration file goes.
No it does not, unless the library is brain-damaged. A library
developer cannot predict where applications will want to store their
config.
Cyrus had this brain-damage in the distant past but the current cyrus
doc is clear: applications can put their config wherever they want,
consult the app's documentation.
By the law of least surprise, we should still use the cyrus default
etc/sasl2/qdrouterd.conf but relative to the install prefix. In an RPM
install this would be exactly the cyrus default.
> > I propose we redefine it to follow the
> > same
> > standard Unix file-system conventions that we use for everything
> > else.
>
> That actually makes no sense! The Unix convention is that this kind
> of
> configuration file goes in /etc/ (At least according to the Linux
> FHS).
Check http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
Host-specific system configuration for local binaries goes in
/usr/local/etc. /etc has a tortured past, older FHS versions probably
support your statement, but thankfully they finally got it right ;)
Note "configuration for local *binaries*", not libraries. It doesn't
matter if libsasl is installed in a different prefix. A library can't
read a config file except as part of a binary.
Respecting the prefix has enormous benefits. Consider a user testing a
new version of dispatch. Even with no root access and
/usr/bin/qdrouterd already installed from RPM (even running), you can
do:
cmake -DCMAKE_INSTALL_PREFIX=/home/aconway/test; make install
By setting a few *standard* env. vars (PATH, LD_LIBRARY_PATH etc. see
attached prefix.sh script) you can run qdrouterd like it was "really
installed", no extra arguments, no dispatch-specific env vars.
Completely independent of the RPM install or other local installs.
Developers need to be able to do local installs too for testing
purposes. This thread started because the dispatch tests were all
green, but I installed dispatch and tried this:
qdrouterd&
qdstat -g
The first thing any user will do. It Just Doesn't Work. No explanation.
Nobody noticed - all the auto tests have valid security config or config to turn security off. The installed config has neither. I never would have noticed if I couldn't install and use the code like a user would.
Re: QPID dispatch and SASL.
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2016-02-24 at 10:44 -0500, Alan Conway wrote:
> ...
> Don't see how SASL is different from any other Unix configuration
> file
> or library dependency. I agree a standard RPM install should use
> /etc/sasl2/qdrouterd.conf, but a /usr/local install should not.
But the library that is *depended on* specifies where it's
configuration file goes. You can install it wherever you like, but it
had better be somewhere *it* will look for it. Where you do *your*
install is irrelevant, if you want to use a library installed in your
install prefix then you can do that.
>
> The SASL docs (https://cyrusimap.org/docs/cyrus-sasl/2.1.23/sysadmin.
> ph
> p) say "Applications can redefine how the SASL library looks for
> configuration information." I propose we redefine it to follow the
> same
> standard Unix file-system conventions that we use for everything
> else.
That actually makes no sense! The Unix convention is that this kind of
configuration file goes in /etc/ (At least according to the Linux FHS).
The proton application can already use pn_sasl_config_path() to tell
cyrus sasl where to look for its config files (or the environment var
mentioned earlier).
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID dispatch and SASL.
Posted by Justin Ross <ju...@gmail.com>.
How will you avoid overwriting user config if you write to /etc? You'll
need some sort of alternate extension, such as qdrouterd.conf.new.
Separately, why is this on the dev list? /me grumbles about the qpid list
situation.
On Tue, Feb 23, 2016 at 6:57 AM, Andrew Stitcher <as...@redhat.com>
wrote:
> On Wed, 2016-02-17 at 18:11 -0500, Alan Conway wrote:
> > I'd like to improve the dispatch out-of-box experience and doc
> > regarding SASL. Our present experience is Doesn't Work By Default/No
> > Useful Errors/Nothing In Doc (apologies if I'm just being dim)
> >
> > My use case is:
> > - install dispatch (using make install to /usr/local)
> > - start qdrouterd with no arguments, using installed default config
> > - run 'qdstat -g' to see something happen.
> >
> > The installer installs:
> >
> > /usr/local/etc/sasl2/qdrouterd.conf
>
> That would be a mistake! The installed code will look by default
> wherever the default for cyrus-sasl is - almost certainly /etc/sasl2 in
> your case.
>
> This is one of those cases where you can't sensibly restrict the new
> installed config file to the install prefix for what's being installed.
> Simply because it relies on something external with it's own
> installation in a potentially different place.
>
> Andrew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: QPID dispatch and SASL.
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2016-02-17 at 18:11 -0500, Alan Conway wrote:
> I'd like to improve the dispatch out-of-box experience and doc
> regarding SASL. Our present experience is Doesn't Work By Default/No
> Useful Errors/Nothing In Doc (apologies if I'm just being dim)
>
> My use case is:
> - install dispatch (using make install to /usr/local)
> - start qdrouterd with no arguments, using installed default config
> - run 'qdstat -g' to see something happen.
>
> The installer installs:
>
> /usr/local/etc/sasl2/qdrouterd.conf
That would be a mistake! The installed code will look by default
wherever the default for cyrus-sasl is - almost certainly /etc/sasl2 in
your case.
This is one of those cases where you can't sensibly restrict the new
installed config file to the install prefix for what's being installed.
Simply because it relies on something external with it's own
installation in a potentially different place.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org