Re: <nettime> Direction of Travel

[Rich Kulawiec via Nettime-tmp <nettime-tmp@mail.ljudmila.org>]

On Wed, Jun 14, 2023 at 05:21:40PM +0200, Christian Swertz via Nettime-tmp wrote:
> You mean running everything in something like a docker container that can
> easily be shifted to another machine? 

No, that's not what I mean.  There's no reason at all to use any kind
of virtualization, and a number of reasons not to.  I think it would be
a big mistake to introduce docker et.al. here.

So let me explain what I do mean.

Running a quality mailing list operation means making judicious choices
from the bottom up: OS, MTA, firewall, DNS, MLM, everything.  It means
building the entire stack for this purpose (although: doing so isn't
all that much different from building a general-purpose mail server).

As an example of the sort of thing that can/should be done: admins will
need ssh access to the system.  That access should be tightly restricted
(on a default-deny basis) to only those network allocations that the
sysadmins use.  If there are no admins in Peru, Pakistan, or Portugal,
then all incoming traffic to port 22 from those countries should be
dropped.  Same for the rest of the planet.  This of course isn't a panacea
-- brute-force and other attacks against ssh can be still be launched.
But the attackers will have to figure out where to launch them *from*
and then they'll have to figure out how to acquire control of attack
resources in those chunks of network space.

There are many more such choices available, from deciding whether to
enforce FCrDNS checks in the MTA (very good idea) to determining
the filesystem backup frequency ("daily" is good) to figuring out
who should do what (and there's no "best" answer to that).

All of those choices need to be documented, and the documentation should
be checked to make sure it matches implementation.  One way to do this
(and there are others): build while making a checklist of all the steps.
Make sure everything works, make a backup, then wipe it.

Test the checklist by rebuilding the system and seeing if you get back
to where you were (i.e., compare against the backup).  If everything
works, and everything matches, then you have a written, itemized, tested
procedure for building -- and for rebuilding elsewhere, should that ever
be necessary.

If not, then fix the checklist, wipe, and rebuild again.

And then: you need to be utterly ruthless about updating the checklist
every single time a change is made to the running instance; otherwise
the checklist will become outdated.

This is a fair amount of extra work, but the payoff comes if/when you
need it.  (And I have.  I moved a couple dozen mailing lists overnight
due to an outage and nobody but the admins noticed.)

Can some of this be automated?  Yes, but given the infrequency with which
it needs to be done it's not really worth taking the time to automate it
(and to debug the automation).  And: another reason not to automate this
is to force a human being (or three) into the loop and get them to think
about what they're doing.  That will come in handy if the day comes that
this needs to rebuilt somewhere else, and the "somewhere else" is a
slightly different environment that will compel on-the-fly adjustments
in the process.

(That's a lesson I learned.  20+ years ago I had about 80% of the process
automated.  Now I have about 10% automated and that consists of simple
shell scripts that I run by hand.  It works better this way AND it's
easier to teach to others.)

-R
#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: https://mail.ljudmila.org/cgi-bin/mailman/listinfo/nettime-tmp
#  archive: http://www.nettime.org contact: nettime@kein.org
#  @nettime_bot tweets mail w/ sender unless #ANON is in Subject: