New debathena-discuss-server breaks mail feeds and local access

[mitchb]

This morning, I caught the following in a DSN:

----- The following addresses had permanent fatal errors -----

"|/usr/bin/dsmail -A -d /var/spool/discuss/lsc-trailers"

(reason: Can't create output)
(expanded from: <lsc-trailers-mtg@…>)

----- Transcript of session follows -----

550-Can't enter transaction
550- into meeting /var/spool/discuss/lsc-trailers: Connection reset by peer
550 5.0.0 "|/usr/bin/dsmail -A -d /var/spool/discuss/lsc-trailers"... Can't c
reate output

This is due to a reversion in the recently updated
debathena-discuss-server package. It results in dsmail being
completely unable to work, but not via a bug in dsmail itself.

Ordinarily, if root@ATHENA.MIT.EDU has bits on a meeting, then
user 'root' on that server is granted those bits. This means
that to set up a mail feed to a discuss archive, you figure out
what user your MTA will exec dsmail as, and adjust the ACL of
the meeting to grant bits to that username@ATHENA.MIT.EDU. With
the revised debathena-discuss-server package, if you run discuss
as some user on the local server and try to so much as add a
non-public meeting, you get the "Connection reset by peer" error.

Downgrading only debathena-discuss from 10.0.8-0debathena1 to
10.0.7-0debathena3 does not fix the problem. Downgrading only
debathena-discuss-server does fix the problem.

[mitchb]

Patch to restore local/dumb authentication functionality requred for dsmail and running the discuss client locally

[mitchb]

I've attached a patch that will fix the discuss package that's
been busted for a couple months. The issue was that several
of the source files were designed to have Kerberized and
non-Kerberized versions built, and certain programs intentionally
linked in the non-Kerberized versions so that they would perform
local authentication. This is what's used if you run the discuss
client locally on a discuss server (you communicate with the disserve
program instead of discussd - they differ only in whether the
objects were built with Kerberos). It's also what's used for
dsmail to support mail feeds into discuss archives.

While trying to clean up the build system, Evan had arranged for it
to always build with krb5 (if krb5 was available) and removed the
requirement to explicitly define things like HAVE_KRB5 in the
Makefiles. This caused the objects that were supposed to lack
Kerberization to have it anyway, and broke them. It also caused
dsmail to fail to build due to undefined (Kerberos) symbols. In
an attempt to get it to build, dsmail had been errantly changed to
link in the Kerberized versions of the objects. That allowed
it to build, but guaranteed that it would never work.

There's also a chunk in this patch addressing what I believe is a
mistake in the usage of krb5_get_host_realms().

A modified debathena-discuss and debathena-discuss-server package
using this code is running on lsc.mit.edu, and appears to work
for local, remote, and mailfeed operations.

[mitchb]

Patch to make the server's Kerberos authentication logic workable without krb4, and to actually use said logic

[mitchb]

The package Evan uploaded to proposed last night does indeed fix local
auth and make local access and mail feeds work. However, building it
without krb4 has now broken all remote authentication. I've attached
another patch; please punt the packages in proposed and rebuild them
with this additional patch, and we might have a winner.

[broder]

Ok. I've uploaded a package with that fix into proposed.

[broder]

   debathena / discuss / mitchb  01:04  (recursive mutex enter?  fsck that!)
       Okay.  Local auth and mailfeed access on lsc.mit.edu works.  Athena 9
       clients work to authenticate to the new lsc.mit.edu server.  New
       Debathena clients work to talk with both the new lsc.mit.edu server and
       menel, charon, and other existing Athena 9 servers.  Barring that
       anyone else stumbles over something, ACK for production when the time
       comes, for however much that counts from me.  Congratulations.  8-)

Barring objections, this should go into production late Monday or Tuesday.