[
https://issues.apache.org/jira/browse/DISPATCH-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323165#comment-15323165
]
Alan Conway commented on DISPATCH-224:
--------------------------------------
Narrowed it down: it works OK for me with this mech list in qdrouterd.conf:
saslMechanisms: ANONYMOUS PLAIN LOGIN DIGEST-MD5 CRAM-MD5 SCRAM-SHA-1 #
GSSAPI GSS-SPNEGO
If I add either of GSSAPI or GSS-SPNEGO to the list, it fails.
The client side is failing. A slightly useful error is reported by proton, but
the error message is dropped by proton.utils.BlockingConnection before it gets
to the dispatch client:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=(null)]')
We could workaround this in all the router clients pending a proton fix. There
is nothing wrong with the router - it is offering the mechs, the client is
refusing them. Still not sure why this works for Jiri and not for me.
> Default installed configuration fails without error message.
> ------------------------------------------------------------
>
> Key: DISPATCH-224
> URL: https://issues.apache.org/jira/browse/DISPATCH-224
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Ted Ross
> Priority: Critical
> Fix For: 0.7.0
>
>
> A simple test of a default install of dispatch in /usr/local does not work:
> {code}
> $ make install
> $ qdrouterd&
> $ qdstat -g
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
> {code}
> The exception gives no hint why we were disconnected, and the router log file
> has no entries at all regarding the disconnection. The actual cause is a SASL
> rejection due to invalid configuration. There are several issues that need
> fixing:
> - The router log should show an error if SASL cant find/parse its config file.
> - The router log should show an error if a connection is rejected for
> security reasons.
> - The client exception should indicate that the disconnect was caused by a
> security problem.
> - The router should look for SASL configuration under its install prefix
> since that is where it is installed.
> - The default router configuration needs to be updated to either be
> functional or clearly NON functional.
> Question is is what should the default configuration allow? IMO it should at
> least allow you to use the tools shipped with qdrouterd to verify that it is
> running and working.
> The alternative is don't ship a default config at all. In that case the
> router should fail to start at all with a clear message "you must configure
> me first, see $prefix/share/doc/qdrouter/config-examples." We can provide a
> sample "qdrouterd-insecure.conf" to get developers started quickly without
> forcing them to learn SASL first. We can add other example configs for
> different scenarios as we go.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
