Re: QPID dispatch and SASL.

[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.

[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.