[sf-lug] @lists.sf-lug.org? @sf-lug.org?

Thu Sep 21 08:57:57 PDT 2017

Well, let's see ...

And I'm probably also among those that didn't fully follow-up
earlier.  In any case ...

> From: "Daniel Gimpelevich" <daniel at gimpelevich.san-francisco.ca.us>
> To: sf-lug at linuxmafia.com
> Subject: Re: [sf-lug] @lists.sf-lug.org? @sf-lug.org?
> Date: Thu, 21 Sep 2017 06:34:27 -0700

> On Thu, 2017-09-21 at 03:08 -0700, Michael Paoli wrote:
>> Also, an open question - would there be any need/reason for
>> @sf-lug.org
>> to accept (or originate/send) email?
>>
>> Also, on present MTA infrastructure, don't really have a way to
>> do different things for different email addresses where
>> localpart is the same, but domain differs.  E.g. if I were to add
>> @sf-lug.org atop the same host that covers @balug.org, then, for
>> example, webmaster at sf-lug.org and webmaster at balug.org ... I wouldn't,
>> at least presently, have means to have those handled differently in
>> terms of where that email went ... again, that's if both domains
>> are on same existing host.  If that email is sent elsewhere (e.g. via
>> MX records), then of course the separate receiving hosts can each
>> do their own things regarding how they process such email.
>
> To recap, the question of sf-lug at sf-lug.org vs. sf-lug at lists.sf-lug.org
> persisted because at an SF-LUG meeting, Jim had stated he wished to
> globally disallow the future possibility of user e-mail aliases such as
> jim at sf-lug.org, and that if there were a separately defined
> lists.sf-lug.org, there would be undesirable duplication such as
> webmaster at lists.sf-lug.org on top of webmaster at sf-lug.org.
>
> However, he is usually open to arguments to the contrary, such as when
> he (possibly at that same meeting) said that the canonical domain for
> the website, and by extension, the list, should specifically be
> sf-lug.com instead of sf-lug.org, apparently later reversing that
> decision. At that time, the migration to joker.com was still on his
> to-do list and a blocker for MTA changes.
>
> The obvious remaining argument against sf-lug at sf-lug.org is that there
> is no clear future migration path for list archive URL's should the
> list, and by extension, its archive, ever actually move.
>
> It seems I somehow missed responding to this message when it was sent:
> http://linuxmafia.com/pipermail/sf-lug/2016q1/011633.html
> Isn't it prudent to ask why going down the rabbit hole of a separate
> DocumentRoot for lists.sf-lug.org needs to be undertaken _in the same
> step_ as migrating the MTA, since in the interim, it could easily just
> point to linuxmafia.com's the way sf-lug.linuxmafia.com was made to
> point in the opposite direction? Is there a real danger of crawlers
> attempting addresses such as http://foo.sf-lug.org/~rick?

Ah, ... that message ...
http://linuxmafia.com/pipermail/sf-lug/2016q1/011633.html

Looks like from that, earlier, Rick had made if fairly far
along to implementing lists.sf-lug.org.

The MTA bits are fairly straight-forward ... I'll skip mentioning
details on that.

Mailman ... quite doable, ... though that may also depend upon
version and stuff ... only really know for the version I've
been dealing with ... may not be quite so easy/feasible for
older versions.  But, for version I'm dealing with ...
$ lsb_release -d && dpkg -l mailman | grep '^ii '
Description:    Debian GNU/Linux 8.9 (jessie)
ii  mailman        1:2.1.18-2+deb8u1 amd64        Powerful, web-based  
mailing list manager
$
With suitable configuration for the (virtual) domains in
mailman, then moving list from one domain to other - even
back and forth, at least after figuring out the relevant
command and syntax and such ... turned out to be quite easy.
Details/example of that can be found on here:
https://lists.balug.org/pipermail/balug-admin/2017-September/000920.html
e.g.:
$ id
uid=38(list) gid=38(list) groups=38(list)
$ (umask 027 && withlist -l -r fix_url balug-test -u lists.balug.org)
Importing fix_url...
Running fix_url.fix_url()...
Loading list balug-test (locked)
Saving list
Finalizing
$
This is also, on Debian oldstable.  I'd presume more for stable on
Debian it would work as well or better, and for well maintained
sufficiently current Linux distributions that also support the
relevant software packes, would likely work about as well/easily
there, though some of the details may vary.

And, as for the Apache bits ... also highly doable,
though at least for oldstable (maybe fixed/better in stable?),
there was one bit that wasn't quite adequately covered in the
mailman documentation and example/prototype configuration for
integration into Apache ... at least on Debian oldstable.
What wee bit? ...
from my:
/etc/apache2/sites-available/Include/lists.balug.org
it includes ... not all of it, but bit particularly
worthy of note:
Include ../mailman/apache.conf
# ../mailman/apache.conf failed to include the requried:
# Require all granted
# So we add it below.
# Apache doesn't seem to mind same Directory being specified again,
# and seems to just use the last configuration it reads for that
# Directory
<Directory /var/lib/mailman/archives/public/>
     Options FollowSymlinks
     AllowOverride None
     Order allow,deny
     Allow from all
     Require all granted
</Directory>
Once the wee bit that was missing was found and corrected,
that all worked fine.  In fact, before I dropped in
additional redirects on http[s]://temp.balug.org/... now all
going to https://lists.balug.org/... for a little while, I
had some lists on both virtual domains, with their respective
separate web URLs, each fully accessible and manageable there,
etc., and could even move them back and forth between the
domains (did so briefly in testing).  But for BALUG's purposes
they were all to move to the canonical lists.balug.org - and
that's been done ... though temp.balug.org also functions for
backwards compatibility through remainder of transition
period (expecting to get rid of temp.balug.org around
2017-11-30).

Also, on that else-posted list:
https://lists.balug.org/pipermail/balug-admin/2017-September/000920.html
The key bit of mailman config for virtual domains,
(leading "> " here being PS2):
$ hostname; pwd -P; fgrep -e lists.balug.org -e temp.balug.org \
> mm_cfg.py | grep -v '^#'
balug-sf-lug-v2.balug.org
/etc/mailman
DEFAULT_EMAIL_HOST = 'lists.balug.org'
DEFAULT_URL_HOST   = 'lists.balug.org'
add_virtualhost('temp.balug.org', 'temp.balug.org')
POSTFIX_STYLE_VIRTUAL_DOMAINS = [ 'lists.balug.org', 'temp.balug.org' ]
$
On the above, there are two virtual domains,
a DEFAULT one (lists),
and one additional (temp),
each also has a pair of domains - one for email, one for web.  I did
also run across some mailman documentation that indicates with
virtual domains, they must be unique, e.g. can't use
same web domain for different email domains (or vice versa,
or both - notably was comment that one of them is used for key in
python dictionary).

Anyway, presuming we figure out the plan, and the relevant folks
are amenable to it and willing to implement it, etc., at least
most reasonable things should be fairly doable.

Rick Moen does also have login on the host that
hosts the BALUG lists (and web, and email - *everything* BALUG that's
online at this point ... well, excepting DNS slaves & upstream authority).
His account doesn't have privileged access there, but most of the
relevant config stuff is world-readable - and I believe he gathered
a fair bit of that config fairly recently (though it's a bit different
now, as BALUG has completed fully migrated off of DreamHost.com's hosting).
Some other folk(s) (besides myself) do also have some limited privileged
access ... e.g. Jim Stockford has all the access needed to change
SF-LUG web page(s) and also SF-LUG.{org,com} DNS, but not including
SF-LUG list stuff, which is on Rick Moen's linuxmafia.com).
The balug-sf-lug-v2.balug.org (yeah, that's the canonical name of the
host itself ... somewhat interesting history as to how it ended up
being that) - that virtual machine has, for SF-LUG, all non-list
stuff - and also everything BALUG.  Jim (and myself) also have
access to SF-LUG registry data, so, between that, and DNS master
presently on balug-sf-lug-v2.balug.org host, can point whatever
of SF-LUG (or portions thereof) to wherever.
# hostname && sudo -l -U jstockford | sed -ne '/may run/,$p'
balug-sf-lug-v2.balug.org
User jstockford may run the following commands on balug-sf-lug-v2:
     (root) /bin/su - sflug
     (root) /bin/su - sflugwww
     (sflug) ALL
     (root) sudoedit /etc/bind/master/sf-lug.org
     (root) sudoedit /etc/bind/master/sf-lug.com
     (root) /bin/systemctl reload bind9
#
That balug-sf-lug-v2.balug.org also automagically (generally gently
overnightly) also snags/rsyncs backups of the SF-LUG list roster and full
raw mbox archive.

Could also be possible, with various schemes, to make higher availability
web stuff for SF-LUG ... e.g. on multiple hosts with use of rsync.
List, though, much easier if it's in *one* place - but obviously
need not be the same place as, e.g. notably, non-list web stuff.