On 09/22/2011 08:41 AM, Zane Bitter wrote:
I've been attempting to get the SSL code in the agents going
again, and
some of the things we have on the wiki page are starting to make sense.
This one, for instance:
> At this time the only connection level settings available through the api is
ssl-cert-name, the other options need to be specified globally. For example,
>
> QPID_LOG_ENABLE=debug+ QPID_SSL_CERT_DB=src/tests/test_cert_db
QPID_SSL_CERT_PASSWORD_FILE=src/tests/cert.password ./matahari-qmf-hostd -N agent -p 5671
-S
Unfortunately, this appears to still be the case. It seems like the code
we had (but #ifdef'd out) was using some private API in qpid-cpp-client
that isn't actually exported in the headers(?).
As far as I can tell there is no way to pass the cert db and password
file options apart from through the environment. To make matters worse,
the qpid client library does its initialisation statically, so the
environment variables have to be set before the library is loaded. Which
happens before main() is run.
So the getenv() is being done in a constructor of a global object?
An alternative is to set them up in /etc/qpid/qpidc.conf. This
clearly
sucks, because the same file is also used by standard qpid client users.
Adam opened a bug against qpid to make this location configurable
(#703563), but it doesn't appear to have been fixed yet. Even then you
will have to configure it through the environment at startup, which is
easily handled by the init/service scripts, but will mean that if you
run the agent manually it will pick up config from the wrong file.
It sure would be nice to be able to set that via the API. I wonder how
hard it would be for us to submit a patch for that. It would be nice to
be able to use SSL when running agents directly without having to set
environment variables.
Finally, we can get the user to configure the Qpid environment
variables
in /etc/sysconfig/matahari. This is doable for a defined subset of the
Qpid environment variables, since we'd have to explicitly export each
one in the SysVInit script (systemd already makes all the variables in
the EnvironmentFile available in the daemon's environment).
Works for me. It seems to be the only viable option in the short term.
Is anyone aware of any changes to this information? Adam, I think,
mentioned on IRC the other day about some of this having been fixed?
The other question is whether it is even worthwhile us supporting SSL on
the agents. Perhaps we should recommend that agents should connect to a
local broker (without SSL) and that access to them from outside the box
should be by connecting to or federating with that broker, preferably
over SSL.
I think it is important and useful. There is no local broker for
Windows hosts. It's good for Linux, too. I don't think we should
artificially limit the architecture to require the use of a local broker.
--
Russell Bryant