[sf-lug] SF-LUG list (etc.) hosting: Re: Belated writeup of last SF-LUG meeting
Michael Paoli
michael.paoli at cal.berkeley.edu
Sat Sep 16 05:51:35 PDT 2023
Speaking of which, ...
One of the few things that DreamHost.com (a.k.a. NightmareHost, yes,
they royally fscked over BALUG.org multiple times, most notably
repeatedly losing list data, and providing no reasonably sane way to
back up list data with any regularity) did right, they had separate
subdomain for lists, so when BALUG.org used to be hosted on DreamHost,
the list address were all under lists.balug.org ... and in fact we
retained that when we migrated off of DreamHost.com. That also allowed
us to do the list migrations highly independent of the web migration,
and in fact we migrated web before migrating the lists. Some more about
that can be found at these locations:
https://www.wiki.balug.org/wiki/doku.php?id=balug:dreamhost_exodus
https://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists
So, yes, ... quite doable to, e.g. set up and migrate list(s), and even
very fully retain existing functionality ... but ... not trivial either.
Also, if SF-LUG wants highly independent subdomain(s) for testing, or
migration of list, or whatever, that's very doable. E.g.
BerkeleyLUG.com also has Pi.BerkelyLUG.com - which is set up so it can
be managed highly independently (though that hasn't exactly been fully
leveraged ... at least yet).
$ hostname --fqdn && ip a s | grep -F "$(dig +short berkeleylug.com. A
berkeleylug.com. AAAA)"
balug-sf-lug-v2.balug.org
inet 96.86.170.229/29 brd 96.86.170.231 scope global ens3
link/sit 96.86.170.229 peer 72.52.104.74
inet6 2001:470:1f05:19e::4/64 scope global
$ ip a s | grep -F "$(dig +short www.sf-lug.org. A www.sf-lug.org. AAAA)"
inet 96.86.170.229/29 brd 96.86.170.231 scope global ens3
link/sit 96.86.170.229 peer 72.52.104.74
inet6 2001:470:1f05:19e::3/64 scope global
$ sudo su - piberk -c 'sudo -l' | sed -ne '/may run/,$p'
User piberk may run the following commands on balug-sf-lug-v2:
(piberk : bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com
(root) NOPASSWD: /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/privkey.pem
Yeah, that account also has access to the private key for the
TLS(/"SSL") cert for [www.]pi.berkeleylug.com - so even has that
available if it wants to move those web bits elsewhere (and all the other
cert bits are public and anyone can pull 'em directly from existing
site, etc.).
$ sudo grep -F ddns-key.pi /etc/bind/named.conf.local
include "/var/cache/bind/keys/ddns-key.pi.berkeleylug.com";
grant ddns-key.pi.berkeleylug.com subdomain pi.berkeleylug.com.;
grant ddns-key.pi.berkeleylug.com subdomain
pi.berkeleylug.com. NS;
$
So, essentially anyone with sudo access to piberk has access to do just
about anything with pi.berkeleylug.com. DNS - including even
setting/changing NS authority/delegation records for that subdomain -
i.e. delegating it to other nameserver(s).
In fact, I believe there are already folks that have access to do quite
a bit with SF-LUG's DNS ...
sudo cat /etc/sudoers.d/DNS | sed -e '/^#/d' | sed -ne '/SFLUG_DNS/,/^$/p'
User_Alias SFLUG_DNS_USERS = \
grantbow, \
jstockford, \
rick
User_Alias SFLUG_DNS_USERS_NP = \
al
Cmnd_Alias SFLUG_DNS_COMMANDS_ROOT = \
/bin/su - root -c bin/Named-checkconf, \
/usr/sbin/rndc sync sf-lug.org, \
/usr/sbin/rndc sync -clean sf-lug.org, \
/usr/sbin/rndc freeze sf-lug.org, \
sudoedit /etc/bind/master/sf-lug.org, \
/usr/sbin/rndc thaw sf-lug.org, \
/usr/sbin/rndc zonestatus sf-lug.org, \
/usr/sbin/rndc notify sf-lug.org, \
/usr/sbin/rndc sync sflug.com, \
/usr/sbin/rndc sync -clean sflug.com, \
/usr/sbin/rndc freeze sflug.com, \
sudoedit /etc/bind/master/sflug.com, \
/usr/sbin/rndc thaw sflug.com, \
/usr/sbin/rndc zonestatus sflug.com, \
/usr/sbin/rndc notify sflug.com, \
/usr/sbin/rndc sync sflug.net, \
/usr/sbin/rndc sync -clean sflug.net, \
/usr/sbin/rndc freeze sflug.net, \
sudoedit /etc/bind/master/sflug.net, \
/usr/sbin/rndc thaw sflug.net, \
/usr/sbin/rndc zonestatus sflug.net, \
/usr/sbin/rndc notify sflug.net, \
/usr/sbin/rndc sync sflug.org, \
/usr/sbin/rndc sync -clean sflug.org, \
/usr/sbin/rndc freeze sflug.org, \
sudoedit /etc/bind/master/sflug.org, \
/usr/sbin/rndc thaw sflug.org, \
/usr/sbin/rndc zonestatus sflug.org, \
/usr/sbin/rndc notify sflug.org, \
/usr/sbin/rndc sync sf-lug.net, \
/usr/sbin/rndc sync -clean sf-lug.net, \
/usr/sbin/rndc freeze sf-lug.net, \
sudoedit /etc/bind/master/sf-lug.net, \
/usr/sbin/rndc thaw sf-lug.net, \
/usr/sbin/rndc zonestatus sf-lug.net, \
/usr/sbin/rndc notify sf-lug.net, \
/usr/sbin/rndc sync sf-lug.com, \
/usr/sbin/rndc sync -clean sf-lug.com, \
/usr/sbin/rndc freeze sf-lug.com, \
sudoedit /etc/bind/master/sf-lug.com, \
/usr/sbin/rndc thaw sf-lug.com, \
/usr/sbin/rndc zonestatus sf-lug.com, \
/usr/sbin/rndc notify sf-lug.com
SFLUG_DNS_USERS ALL= SFLUG_DNS_COMMANDS_ROOT
SFLUG_DNS_USERS ALL=(:bind) /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.SF-LUG
SFLUG_DNS_USERS_NP ALL= NOPASSWD: SFLUG_DNS_COMMANDS_ROOT
SFLUG_DNS_USERS_NP ALL=(:bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.SF-LUG
$
So, yes, that's 4 users (in addition to myself) that have pretty dang
free rein over over most all of SF-LUG's DNS - and can update it using
dynamic DNS, or ye olde fashioned way by editing zone file(s) (and by
using appropriate related commands to do that and also not mess up
dynamic DNS).
So folks that already have that access can make DNS changes they may
wish. And if we want to do dedicated subdomain(s), and even set up
additional folks with access to those to do with as they wish, well, not
too hard to set that up. Uhm ... but hopefully if folks request stuff
like that, maybe some might actually do bit more useful (semi-)active
stuff with it? Fair number of folks have gotten set up with access ...
and sure, some of that also good for backup/redundancy 'n all that ...
but not much have done anything with it. E.g. like even the simplest of
web page changes for SF-LUG ... everybody seems to always fall back to
asking me to do it, 'cause nobody else can be bothered? SF-LUG ...
a Linux Users' Group, 243 members strong:
http://linuxmafia.com/pipermail/sf-lug/2023q3/015890.html
And, let's see ... I do a fair bit, Rick does much in providing the list
hosting (and answering a lot of questions and correcting a whole lot 'o
folks on stuff stated that's just not correct), Al covers fair chunk of
DNS (most notably footing the bill for numerous additional domains, and
also many secondaries) ... let's see, other than those bits, how long
has it been since other folks have logged in to do anything possibly
related to SF-LUG?
$ lastlog | grep -F -v '**Never logged in**' | grep -E -v
'^(Username|root|mpaoli|test|bad|mycert) ' | sort -k 9,9bnr -k 5,5Mbr
-k 6,6bnr -k 7,7r
rick pts/6 96.95.217.99 Thu Aug 25 03:22:27 +0000 2022
al pts/2 2001:1890:1672:1 Sat Jan 8 18:09:58 +0000 2022
kdavalos pts/3 2600:1700:37a0:1 Sun Oct 31 17:57:36 +0000 2021
jstockford pts/9 173-13-130-174-s Fri Jul 29 04:20:37 +0000 2016
thawley pts/8 104-244-27-45.pu Fri Jan 15 06:05:40 +0000 2016
sdubois pts/0 c-76-103-152-134 Mon Mar 10 00:27:01 +0000 2014
grantbow pts/8 173-8-189-243-sf Sun Apr 28 20:50:11 +0000 2013
$
Hasn't exactly been huge amounts of activity nor generally recent.
I mean even simply editing a web page ...
ssh(1), sudo(1), vi(1) ... is it that hard?
Or change something in DNS ... e.g.:
(and pickin' on al's account 'cause it's got passwordless sudo access,
and I don't have nor should I have other user's passwords):
$ sudo su - al
al at balug-sf-lug-v2:~$ PS1='$ '
sudo -l | grep -F nsupdate
(al : bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.SF-LUG
$ echo 'update add expires-2023-10-31-tmp-test.foo.bar.baz.sf-lug.org.
300 IN CNAME linuxmafia.com.
> send' | sudo -g bind /usr/bin/nsupdate -l -k /var/cache/bind/keys/ddns-key.SF-LUG
$ dig @$(dig +short sf-lug.org. NS | head -n 1) +noall +answer
+norecurse expires-2023-10-31-tmp-test.foo.bar.baz.sf-lug.org. CNAME
expires-2023-10-31-tmp-test.foo.bar.baz.sf-lug.org. 300 IN CNAME linuxmafia.com.
$ (cd / && TZ=GMT0 at noon oct 31 << \__EOT__
> echo 'update del expires-2023-10-31-tmp-test.foo.bar.baz.sf-lug.org. 300 IN CNAME linuxmafia.com.
> send' | sudo -g bind /usr/bin/nsupdate -l -k /var/cache/bind/keys/ddns-key.SF-LUG
> __EOT__
> )
warning: commands will be executed using /bin/sh
job 78 at Tue Oct 31 12:00:00 2023
$ exit
logout
$
So, yes, lots folks can do or potentially do ... if they want to bother
to.
On Fri, Sep 15, 2023 at 2:17 PM Rick Moen <rick at linuxmafia.com> wrote:
>
> Quoting Ronald Barnes (ron at ronaldbarnes.ca):
>
> > Rick Moen wrote on 2023-09-10 23:06:
> >
> > >Which leads me to another thing Michael's suggesting: It's generally
> > >speaking a good idea to put mailing lists on a subdomain, the usual
> > >one being lists.$FOO , analogous to the domain's Web site being at
> > >www.$FOO, and sometimes non-lists e-mail at mail.$FOO .
> >
> > Correct me if I'm wrong, but that's so the web interface to mailman
> > can be on port 80 at lists.$foo while port 80 on $foo can serve up
> > other sites?
Well, yes, it can (also) do that ... and I do happen to have that set up
(and also https on port 443) for lists.balug.org so, e.g.:
https://lists.balug.org/
and:
http://lists.balug.org/
Do in fact do something pretty intuitive and useful.
> It's so that lists.$foo can point to _anywhere_, including, without
> limitation, on the same host that serves Web pages from unqualified
> domain $foo and/or www.$foo. Also, even more usefully, where that
> points to can then be changed by you, transparently to users.
>
> > However, I do find it awkward to have mailing lists reside at
> > @lists.bclug.ca, so I have entries in my /etc/postfix/canonical file
> > to allow @bclug.ca lists messages to work too:
> >
> > > discuss at bclug.ca discuss at lists.bclug.ca
> >
> > etc.
>
> Sure, you can do that. Don't forget to configure each Mailman list (in
> the admin webUI) to recognise that as a valid alternate address,
> otherwise Mailman will reject received mail as "implicitly addressed"
> (a spam-suspect trait).
>
> > It's a daunting task, and scary having one's own email server open
> > to all the malicious actors out there.
>
> Well... default setups of MTAs are good enough to defeat various ways to
> exploit the MTA as an open forwarder. (That was pretty much a 1990s
> problem.) What distros' default MTA setups are reportedly still _not_
> good enough at, is antispam. Configuring effective antispam thus
> becomes a separate, post-installation problem.
>
> > My domain registrar has begun charging for email hosting, so I'm
> > looking at moving at least my email away from them to a VPS
> > (actually cheaper, even for a single domain), perhaps all domain
> > registry business as well.
>
> Can work well. However, beware that many VPSes' IP netblocks suffer bad
> established spam reputation, i.e., their IPs are on DNSBLs, because of
> past disreputable customers who used to operate spamhauses there.
>
> You could hang up your shingle on a shiny new virthost, only to find out
> that you're suffering poor deliverability because of the bad reputation
> of a customer who used the IP before you.
More information about the sf-lug
mailing list