/etc/sasl

[Fabian Fagerholm]

On Mon, 2008-01-14 at 18:27 -0800, Russ Allbery wrote:
> Patrick Ben Koetter <p at state-of-mind.de> writes:
> > How about this for a migration path from /usr/lib/sasl2 to /etc/sasl2:
> >
> > 1. Search in app specific path (controlled by app maintainer/developer)
> > 2. Search in /etc/sasl2 (controlled by SASL defaults)
> > 3. Search in /usr/lib/sasl2 and log a warning that /usr/lib/sasl2 is being
> >    deprecated.
> 
> Isn't this what the current SASL packages are already doing?  I thought I
> looked at them recently and found that this was already the algorithm.

I don't know about the warning being logged, but the rest is definitely
how it works right now. (1) is searched if the application registers its
own configuration location with SASL, and (2) and (3) are searched
because that's what we specify at build time.

However, please recall (or look in the BTS for) all the problems users
had when the configdir was last changed -- that's why we
search /etc/sasl and /usr/lib/sasl2. People have config files all over
the place, in at least /usr/lib/sasl2, /etc/sasl and
application-specific locations. Countless howto's specify all kinds of
locations and when you've read one of them, it's hard to see what you
should put where if someone tells you not to use the locations in that
particular document.

So I would suggest starting the migration by building with
--with-configdir=/etc/sasl2:/etc/sasl:/usr/lib/sasl2 and
promoting /etc/sasl2 as the preferred default location, to be used
unless the application specifies its own location. Then getting rid
of /etc/sasl and /usr/lib/sasl2 requires some more effort. We can
certainly remove all references of them from our own documentation, but
I'm not sure it's worth removing them from the build-time default for a
long time -- new systems will be more FHS compliant if they follow the
documentation, but it costs us very little to avoid breaking old ones.

This said, I'd like to know if any other distros besides RHEL 5.1
use /etc/sasl2 or if we're likely to just create an even bigger mess
than we already have. Here's what I currently know is specified:

Upstream docs: /usr/lib/sasl2 + app-specific dir
        "... we want the library to *always* be able to find its plugins
        under /usr/lib/sasl2, ..., so that the SASL plugin ABI on all
        platforms is roughly the same." (doc/install.html)

Upstream build default: /usr/lib/sasl2

Debian docs: No mention of configdir.

Debian build: /etc/sasl:/usr/lib/sasl2


Googling for each of the directories gives:

/usr/lib/sasl2: 23500 results
/etc/sasl: 1560 results
/etc/sasl2: 3580 results

If you look at some of the Google search results, you'll see all kinds
of strange stuff like /opt/etc/sasl2 and mentions of defaults that are
distribution-specific or exist only in the conventions of the writer.

Regardless of what location(s) we're going to use, the main problem is
(still) the lack of clear documentation that explains how things work. I
regret that I haven't had time to write it yet.

One thing to remember is that Cyrus SASL is not a separate
authentication daemon -- it's a library that is part of the run-time
code of an application. Thus the configuration idioms that apply to
regular unix daemons don't apply (unless we're talking about saslauthd,
which is obviously a daemon) and the documentation needs to take this
into account. You're configuring the application code, not a separate
program. Some of that code just happens to be dynamically linked.

To summarize:

      * I want to use
        --with-configdir=/etc/sasl2:/etc/sasl:/usr/lib/sasl2 .
      * I want to promote /etc/sasl2 as the proper default.
      * I want to keep /etc/sasl for backwards compatibility with older
        Debian systems, but not mention it in the documentation.
      * I want to keep /usr/lib/sasl2 for compatibility with upstream's
        wishes, but not mention it as an option in the documentation.
      * I want applications to continue to use their own config
        locations if they wish (Postfix, OpenLDAP, Cyrus IMAPd) and
        explain how that works in the documentation.
      * I want to write the documentation for this, or have it written
        by someone else. :)

Opinions for or against?

-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20080115/77e5440d/attachment.pgp