[sf-lug] @lists.sf-lug.org? @sf-lug.org?
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Thu Sep 21 03:08:47 PDT 2017
So ... was a while since we last had some communications regarding
possibility of @lists.sf-lug.org and/or @sf-lug.org.
I think some key bits discussed earlier were, it might be nice
to have SF-LUG list be able to use email domain - and perhaps also
for web - of lists.sf-lug.org - or sf-lug.org.
Some advantages/disadvantages, of using lists.sf-lug.org (or some
other subdomain of sf-lug.org, rather than sf-lug.org itself).
If a subdomain is used, that makes it much more practical/feasible
to, e.g. separately host and/or manage the list and its web
accessible archives, list information web pages, etc.
So, e.g. [www.]sf-lug.org and lists.sf-lug.org could be
on completely different hosts/infrastructures, even managed
quite highly independently ... that's kind'a what the case is
presently, ... except the lists are using linuxmafia.com. Even
presuming they'd remain on same hosts ... could add/change
configurations and such, so one could use/see lists.sf-lug.org.
"Of course" that's presuming Rick Moen (graciously hosting SF-LUG
list on linuxmafia.com) would be amenable to such.
And ... disadvantage of lumping all of web and lists, etc. smack
directly on sf-lug.org? Well, then they can't be very much separated
out. E.g. if one sends mail to postmaster at sf-lug.org ... it gets
sent to just one host (or set of IPs or hosts) ... but in any case,
under one single administrative realm/hosting. Likewise for
webmaster at sf-lug.org, security at sf-lug.org, etc.
So ... I mostly tend to think it would be better having such
separate. It mostly allows things to be well separated out as,
if, and when desired ... as otherwise, options are much more limited.
Anyway, ... just a thought ... perhaps reopen that discussion/dialog.
Also, as for managing lists.sf-lug.org - presuming we were to go such a
route, and that such was hosted upon the host machine that's
linuxmafia.com ... rather than, e.g. me, mucking about with
DNS records, anytime any changes were needed for lists.sf-lug.org.,
could set that up as a fully delegated subdomain, then, e.g.
Rick Moen, could for most all intents and purpose fully manage
DNS for lists.sf-lug.org. (and I could also offer slave services
for that domain).
So ... just some thoughts.
Anyway, the host that hosts [www.]sf-lug.org not only has an
infrastructure to reasonably cover web hosting (Apache),
but does (as of relatively recently) also have MTA (exim4 + eximconfig)
and list (Mailman) infrastructure now too. "Of course" I've got
negligible interest in also hosting the SF-LUG list myself - I think
it's wonderfully fine where it is with Rick Moen's marvelous hosting.
:-) But ... if folks are interested, and the relevant persons also
amenable to such, could adjust things logically for
presentation ("vanity") effects (/benefits?) and such.
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.
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: *un*done*: SF-LUG & MX records ... @lists.sf-lug.org ...
> Date: Tue, 12 Jan 2016 01:09:43 -0800
> Anyway, dropped out the lists.sf-lug.org. records and the sf-lug.org.
> MX record. We can add 'em back in if/when we're more ready to further
> test, etc. (though much of that can also probably be tested without
> need to add them). I figure in the meantime, we'll save Rick Moen
> from getting lots of (probably mostly unwanted thus far) email traffic
> to the linuxmafia.com host.
> And, as earlier, may take a bit for the DNS changes to be fully
> effective across The Internet (and for some of the slaves to
> fully catch up even before that).
>
> $ { dig -t SOA sf-lug.org. +noall +answer +norecurse; dig -t MX
> lists.sf-lug.org. +noall +answer +norecurse; dig -t A
> lists.sf-lug.org. +noall +answer +norecurse; dig -t MX sf-lug.org.
> +noall +answer +norecurse; } | grep '^[ ]*[^ ;]'; (for ns
> in $(dig -t NS sf-lug.org. +short +norecurse | tr '[A-Z]' '[a-z]' |
> sort); do for ip in $(dig +short "$ns" A "$ns" AAAA); do echo "$ns
> $ip>" $(dig @"$ip" -t SOA sf-lug.org. +noall +answer +norecurse|
> grep '^[ ]*[^ ;]'); done; done)
> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452588035 10800 3600 1209600 3600
> ns.primate.net. 198.144.194.12> sf-lug.org. 7200 IN SOA
> ns1.sf-lug.org. jim.well.com. 1452588035 10800 3600 1209600 3600
> ns.primate.net. 2001:470:1f04:51a::2>
> ns1.linuxmafia.com. 198.144.195.186> sf-lug.org. 7200 IN SOA
> ns1.sf-lug.org. jim.well.com. 1452588035 10800 3600 1209600 3600
> ns1.svlug.org. 64.62.190.98> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452588035 10800 3600 1209600 3600
> ns2.he.net. 216.218.131.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns2.he.net. 2001:470:200::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns3.he.net. 216.218.132.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns3.he.net. 2001:470:300::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns4.he.net. 216.66.1.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns4.he.net. 2001:470:400::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns5.he.net. 216.66.80.18> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> ns5.he.net. 2001:470:500::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
> jim.well.com. 1452456844 10800 3600 1209600 3600
> $
>
>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>> Subject: Re: done*: SF-LUG & MX records ... @lists.sf-lug.org ...
>> Date: Sun, 10 Jan 2016 12:32:23 -0800
>
>> Anyway, as per Daniel Gimpelevich's suggestion, have also set up,
>> at least for
>> "testing" purposes, MX record for sf-lug.org.
>> Like earlier, will take a little will to be fully available across all
>> Internet DNS.
>>
>> $ (for ns in $(dig @8.8.8.8 -t NS sf-lug.org. +short | tr '[A-Z]'
>> '[a-z]' | sort); do for ip in $(dig +short "$ns" A "$ns" AAAA); do
>> echo "$ns $ip>" $(dig @"$ip" -t SOA sf-lug.org. +noall +answer|
>> grep '^[ ]*[^ ;]'); done; done)
>> ns.primate.net. 198.144.194.12> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452456844 10800 3600 1209600 3600
>> ns.primate.net. 2001:470:1f04:51a::2>
>> ns1.linuxmafia.com. 198.144.195.186> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452456844 10800 3600 1209600 3600
>> ns1.svlug.org. 64.62.190.98> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452456844 10800 3600 1209600 3600
>> ns2.he.net. 216.218.131.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
>> jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns2.he.net. 2001:470:200::2> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns3.he.net. 216.218.132.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
>> jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns3.he.net. 2001:470:300::2> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns4.he.net. 216.66.1.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
>> jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns4.he.net. 2001:470:400::2> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns5.he.net. 216.66.80.18> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
>> jim.well.com. 1452445360 10800 3600 1209600 3600
>> ns5.he.net. 2001:470:500::2> sf-lug.org. 7200 IN SOA
>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>> $
>>
>>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>>> Subject: done*: SF-LUG & MX records ... @lists.sf-lug.org ...
>>> Date: Sun, 10 Jan 2016 11:21:36 -0800
>>
>>> done*:
>>> $ dig -t MX lists.sf-lug.org. +short
>>> 100 linuxmafia.com.
>>> $ dig -t A lists.sf-lug.org. +short
>>> 198.144.195.186
>>> $
>>> *Note that this may not yet be fully propagated through all slaves
>>> and throughout
>>> all Internet DNS.
>>> Also note, no AAAA records yet for linuxmafia.com. and thus
>>> likewise not present for
>>> lists.sf-lug.org.
>>>
>>> Rick - also, if you want/prefer me to delegate linuxmafia.com.
>>> (or ns1.linuxmafia.com) as NS for lists.sf-lug.org. (and can also
>>> set up sf-lug.org.
>>> as slave of same), just let us know, and I/we can set it up that way.
>>>
>>> Details, details - quite commented implementation, for those that
>>> wish to learn and/or
>>> follow along:
>>>
>>> below, some empty lines added, and my comments preceded with //
>>>
>>> //IP addresses for sf-lug.org. and www.sf-lug.org.:
>>> $ dig +short sf-lug.org. A sf-lug.org. AAAA
>>> 198.144.194.238
>>> 2001:470:1f04:19e::2
>>> $ dig +short www.sf-lug.org. A www.sf-lug.org. AAAA
>>> 198.144.194.238
>>> 2001:470:1f04:19e::2
>>> $
>>>
>>> $ dig +short balug-sf-lug-v2.balug.org. AAAA balug-sf-lug-v2.balug.org. A
>>> 2001:470:1f04:19e::2
>>> 198.144.194.238
>>> // And again, same IP addresses ... at present, the SF-LUG web site
>>> // stuff (except for the lists), and master DNS, is hosted on the BALUG
>>> // host (that host itself a virtual machine (VM), which is
>>> // balug-sf-lug-v2.balug.org (that slightly odd name being a bit having
>>> // to do with how it came into being and evolved historically, and is
>>> // preserved for reasonable logical consistency). Again, note that it's
>>> // a BALUG VM, not an SF-LUG VM ... but that it happens to presently be
>>> // serving several SF-LUG services. This has been the case since quite
>>> // shortly after the physical box that had been hosting those same
>>> // SF-LUG services, was permanently disconnected from The Internet at
>>> // the colo where it had been located for many years - the free hosting
>>> // deal for SF-LUG got phased out in fairly quick order after the colo
>>> // was bought out yet again by yet another hosting company. It was
>>> // wonderful that SF-LUG was provided that hosting for free for years,
>>> // ... but that deal ended.
>>>
>>> //We probably don't yet have IP addresses for lists.sf-lug.org.,
>>> //but let's check to be sure:
>>> $ dig lists.sf-lug.org. A lists.sf-lug.org. AAAA | fgrep NX
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1490
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27711
>>> //Likewise, let's check for any existing MX records:
>>> $ dig lists.sf-lug.org. MX | fgrep NX
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38658
>>> //The NXDOMAIN in our response is "No such domain" - there is no
>>> // Resource Record (RR) for the requested domain information, i.e. we
>>> // don't have the A, AAAA, and MX records we queried for.
>>> // AAAA records are IPv6 address records.
>>>
>>> $ ssh-add -l | wc -l
>>> 2
>>> // I have some ssh keys active - and happens to include at least one I
>>> // want to use presently. It's generally more secure to authenticate
>>> // using ssh keys, rather than passwords. By authenticating via ssh
>>> // key, neither password nor ssh private key are ever sent to the
>>> // server, but rather server sends us a challenge encrypted to our
>>> // public key, since we have that corresponding private key, we can
>>> // decrypt the challenge, and thus use that to authenticate ourselves.
>>> // Also, by having strong passphrase on the key, and use of
>>> // ssh-agent(1), we also avoid storing the private key in non-volatile
>>> // (persistent) storage in the clear - the private key is only in the
>>> // clear in Random Access Memory (RAM), and just on the client, never
>>> // given to the server. By taking such security precautions, if the
>>> // server were to be compromised, that avoids password or private key
>>> // being discovered on server and potentially used to break into
>>> // additional hosts with that information.
>>>
>>> $ ssh balug-sf-lug-v2.balug.org. hostname
>>> balug-sf-lug-v2.balug.org
>>> // as we can see above, balug-sf-lug-v2.balug.org is the hostname.
>>>
>>> // I then proceed on that host:
>>> $ ssh -ax balug-sf-lug-v2.balug.org.
>>>
>>> // We see that jstockford and grantbow accounts both have access to edit
>>> // the sf-lug master DNS file, and to reload bind9
>>> // (the running DNS server)'s configuration:
>>> $ sudo sudo -l -U jstockford | fgrep -e sf-lug.org -e reload
>>> (root) sudoedit /var/lib/named/etc/bind/master/sf-lug.org
>>> (root) /usr/sbin/service bind9 reload
>>> $ sudo sudo -l -U grantbow | fgrep -e sf-lug.org -e reload
>>> (root) sudoedit /var/lib/named/etc/bind/master/sf-lug.org
>>> (root) /usr/sbin/service bind9 reload
>>> $
>>> // And in case one was wondering or we're not sure who those accounts
>>> // belong to:
>>> $ awk -F: '{if(($1=="jstockford")||($1=="grantbow")){print
>>> $1,$5;}}' /etc/passwd
>>> jstockford Jim Stockford
>>> grantbow Grant Bowman,,,
>>> $
>>>
>>> // Let's also get the DNS target IP address(es) we'll want to be adding:
>>> $ dig +short linuxmafia.com. A linuxmafia.com. AAAA
>>> 198.144.195.186
>>>
>>> // I've also got similar access on there, so I'll make the requested
>>> // changes. I'll use ed(1), a line-oriented editor, to make capturing
>>> // the input and output much easier to see - were I not saving that from
>>> // the session, I'd just use vi(1), which happens to also be be at least
>>> // my default on the host anyway.
>>> $ SUDO_EDITOR=ed sudoedit /var/lib/named/etc/bind/master/sf-lug.org
>>> 1465
>>> // That's the number of characters in the file.
>>>
>>> /SERI
>>> 1451934639 ; SERIAL ; perl -e
>>> 'print(time%(2**32));'
>>> // I search for the line having the zone serial number - relatively easy
>>> // to find as it's well commented. This zone is using seconds from the
>>> // epoch. (There are various schemes that can be used, one that's
>>> // recommended and quite commonly used is:
>>> // YYYYMMDDNN, where NN is iteration within that day, starting with 00,
>>> // allowing up to 100 (00 through 99) different serial number versions
>>> // within the day). However, we're not restricted to that scheme. We
>>> // can use any proper scheme that works properly with DNS - (e.g. one
>>> // can start with 1, and simply increment the number with each change).
>>> // Anyway, seconds since the epoch - we can also get that more //
>>> // concisely with GNU date(1):
>>> // date +%s
>>> // In any case, we need to update the serial number if we're making
>>> // changes to the data, so let's also update that comment to be more
>>> // concise and handy. In DNS zone files, comments are semicolon (;)
>>> // through end of the line
>>>
>>> // we update our comment, changing the perl through end of line portion
>>> // with our simpler GNU date example. % might have special meaning in
>>> // the Regular Expression (RE), so we precede it with backslash (\) to
>>> // prevent it from having any special meaning in the RE:
>>> s/perl.*$/date +\%s
>>> 1451934639 ; SERIAL ; date +%s
>>> // The editor (ed) also shows us what we changed.
>>>
>>> // We do a shell escape, again, we backslash (\) escape %, as the %
>>> // otherwise might have special meaning in context of command execution
>>> // within our editor ed:
>>> !date +\%s
>>> 1452445360
>>> !
>>>
>>> // We update the serial number, again using RE substitution, but this time
>>> // it doesn't show us what we changed (likely because it's yet another
>>> // change on the same line and we've not yet moved off that same line),
>>> // so we give the . command in the editor, which will simply show us our
>>> // current (resultant) line:
>>> s/1451934639/1452445360/
>>> .
>>> 1452445360 ; SERIAL ; date +%
>>>
>>> // I check to see if there's anything in the zone file that changes the
>>> // ORIGIN - I find no surprises on that, so the ORIGIN is sf-lug.org.,
>>> // so that being the case, essentially any name we use in the file
>>> // that doesn't end with ., is presumed to have sf-lug.org. appended to
>>> // it (which generally makes things much more clear, concise, and
>>> // generally human-friendly, and can also safe some fair bits of
>>> // filesystem data space).
>>> g/^[^;]*@/p
>>> @ 7200 IN SOA (
>>> g/ORIGIN/p
>>> g/INCLUDE/p
>>>
>>> // I'm just going to add our RR's at the end of the file - having
>>> // glanced over the file earlier, there isn't any other place that
>>> // would logically be significantly better, or perhaps even so much as
>>> // better at all, ... so end is quite fine for this.
>>> $a
>>> lists IN MX 100 linuxmafia.com.
>>> IN A 198.144.195.186; linuxmafia.com.
>>> .
>>> w
>>> 1514
>>> q
>>> $
>>> // The a command is for append - start adding lines after current line;
>>> // by preceding that with $, we do that relative to the last line. We
>>> // then type our input and then enter a line with only the character .
>>> // on it to terminate our input of added lines. We then use w to write
>>> // out the file , and it responds by showing us the number of characters
>>> // written, and q to quit ed(1). Also, in the above, when we
>>> // entered a line starting with spaces and/or tabs, that is a
>>> // continuation of the immediately above RR, so it's implied, as if the
>>> // line instead started with lists, before that whitespace.
>>>
>>> // Also, I added both MX and A records. The (latest)
>>> // request/communication may have been slightly ambiguous on that, but
>>> // rather than do more back-and-forth on that, since in this case it's
>>> // not critical, and can be changed later quite easily if need be, I
>>> // guestimate that both are desired or at least okay, and implement
>>> // that.
>>>
>>> // We then tell the nameserver to reload its configuration, so it will
>>> // pick up the changes:
>>> $ sudo /usr/sbin/service bind9 reload
>>> $
>>>
>>> // Let's check - do we have the new serial number in the zone's data?:
>>> $ dig @127.0.0.1 -t SOA sf-lug.org. +short
>>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>>> $
>>> // Yes, that's our new serial number, so that looks good.
>>> // Also note, we first checked just against our master DNS server (local
>>> // since we're on the host that is master). We did that, as there's no
>>> // use or reason to expect it to show up on slaves if it's not yet been
>>> // properly updated on the master.
>>>
>>> // Let's check our added RR's:
>>> $ dig @127.0.0.1 -t MX lists.sf-lug.org. +short
>>> 100 linuxmafia.com.
>>> $ dig @127.0.0.1 -t A lists.sf-lug.org. +short
>>> 198.144.195.186
>>> $
>>> // So far all looking good. Let's check the advertised NS servers.:
>>> $ dig @8.8.8.8 -t NS sf-lug.org. +short | tr '[A-Z]' '[a-z]' | sort
>>> ns.primate.net.
>>> ns1.linuxmafia.com.
>>> ns1.svlug.org.
>>> ns2.he.net.
>>> ns3.he.net.
>>> ns4.he.net.
>>> ns5.he.net.
>>> $
>>> // Oh, and I did upper case to lowercase conversion for my convenience -
>>> // DNS is case insensitive (excepting, e.g., the data within TXT
>>> // records), but generally case preserving - so I just squashed all to
>>> // lowercase (and sorted) for ease of my use.
>>> // We could have picked other ways to determine those, in this case,
>>> // perhaps just for variety, I used Google's DNS server to do the lookup
>>> // against - I'd expect they ought also have results consistent with
>>> // what we're generally expecting. I could just as well have not
>>> // included @8.8.8.8 at all, in which case we would've defaulted to
>>> // using what's specified in /etc/resolv.conf, which for this host
>>> // would've used the local nameserver - which is perfectly fine if we
>>> // know or can reasonably presume all is fine and well with that
>>> // nameserver and it is consistent in its world view of DNS (I happen to
>>> // have every reason to believe it's fine, but thought for variety I'd
>>> // pick another to look up against).
>>>
>>> // Now let's look up against those nameservers, to see if they have the
>>> // updated serial number yet. In fact, I'll even go one better than
>>> // that, and check against all the IPs of those nameservers (some of
>>> // them have multiple IPs).
>>>
>>> $ (for ns in $(dig @8.8.8.8 -t NS sf-lug.org. +short | tr '[A-Z]'
>>> '[a-z]' | sort); do for ip in $(dig +short "$ns" A "$ns" AAAA); do
>>> echo "$ns $ip>"; dig @"$ip" -t SOA sf-lug.org. +short; done; done)
>>> ns.primate.net. 198.144.194.12>
>>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>>> ns.primate.net. 2001:470:1f04:51a::2>
>>>
>>> ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @2001:470:1f04:51a::2 -t SOA
>>> sf-lug.org. +
>>> short
>>> ; (1 server found)
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>> ns1.linuxmafia.com. 198.144.195.186>
>>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>>> ns1.svlug.org. 64.62.190.98>
>>> ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
>>> ns2.he.net. 216.218.131.2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns2.he.net. 2001:470:200::2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns3.he.net. 216.218.132.2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns3.he.net. 2001:470:300::2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns4.he.net. 216.66.1.2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns4.he.net. 2001:470:400::2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns5.he.net. 216.66.80.18>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> ns5.he.net. 2001:470:500::2>
>>> ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
>>> $
>>>
>>> // And from the above, we notice a couple things going on:
>>> // IPv6 address 2001:470:1f04:51a::2 on ns.primate.net. fails to work
>>> // (a known issue), however the other IP addresses on ns.primate.net.
>>> // work. We have sufficient redundancy, so we're not going to worry
>>> // particularly about that one (have earlier notified contact of that
>>> // NS of that issue). We also notice the *.he.net. nameservers still
>>> // have the old zone serial number - so they've not yet picked up the
>>> // updates. That's actually a nice free DNS service, so can't complain
>>> // too much. I've noticed they pull the zone down relatively quickly.
>>> // And, perhaps at least in theory, from what's implied on some of
>>> // their web pages, seems their servers should start serving up the
>>> // updated data within about 5 to 10 minutes - but in practice more
>>> // recently, I've noticed it can often take many hours or more ... but
>>> // that's sufficiently okay - it still happens quite fast enough for
>>> // our purposes - we're in no extreme rush, and "worst case", we have
>>> // Time To Live (TTL) expirations to wait through on any DNS that may
>>> // already be cached out there on various DNS servers across The
>>> // Internet - so we can't expect our data to be fully available
>>> // Internet wide in all of DNS everywhere quite yet - and that's also a
>>> // *good* thing, as it makes for efficient DNS and less wasted traffic
>>> // on The Internet - the data is cached for a while to avoid excessive
>>> // DNS traffic. So we have our pieces in place, we just wait for the
>>> // *.he.net NS servers, and then the rest of The Internet, to catch up
>>> // to our data. So, sometime in the coming hour(s) or bit longer, it
>>> // will then be all set, and should be good to proceed with testing use
>>> // of that DNS on The Internet. I'll leave the follow-up on that as an
>>> // exercise to those that are a bit more interested in testing that
>>> // functionality.
>>>
>>> Meanwhile back at the ranch ;-) ...
>>> Time for the balug VM (and the BALUG and SF-LUG stuff it hosts), to stay
>>> home, while my laptop and I go out:
>>> http://berkeleylug.com/meetings/
>>> # SSH_AUTH_SOCK=/home/m/michael/.SSH_AUTH_SOCK time virsh migrate
>>> --live --persistent --copy-storage-all --verbose balug
>>> qemu+ssh://192.168.55.2/system &&
>>> SSH_AUTH_SOCK=/home/m/michael/.SSH_AUTH_SOCK ssh -ax -l root
>>> 192.168.55.2 'virsh autostart balug' && virsh autostart --disable
>>> balug
>>> Migration: [100 %]
>>> 0.16user 0.14system 6:34.09elapsed 0%CPU (0avgtext+0avgdata
>>> 9384maxresident)k
>>> 3394inputs+0outputs (18major+974minor)pagefaults 0swaps
>>> Domain balug marked as autostarted
>>>
>>> Domain balug unmarked as autostarted
>>>
>>> #
>>>
>>>
>>>> From: "Rick Moen" <rick at linuxmafia.com>
>>>> Subject: Re: [sf-lug] SF-LUG & MX records, etc.
>>>> (sf-lug at lists.sf-lug.org, or ... )
>>>> Date: Sat, 9 Jan 2016 23:25:28 -0800
>>>
>>>> Michael Paoli and Jim Stockford: We're ready to test, if you care to
>>>> point 'lists.svlug.org' at my IP address.
>>>>
>>>>
>>>>
>>>> I wrote:
>>>>
>>>>
>>>>> My upthread comment (that MX reference records shouldn't exist for
>>>>> domains that don't handle SMTP) was before Daniel reminded me of this
>>>>> idea y'all discused earlier. Obviously, in that case, the domain
>>>>> _would_ be handling SMTP.
>>>>
>>>> Mystery solved.
>>>>
>>>> Upthread, I said 'FWIW, I've grepped through exim4's conffiles, and it
>>>> looks like the MTA doesn't care what it's addressed as.' Specifically, I
>>>> did:
>>>>
>>>> grep -r linuxmafia.com /etc/exim4/
>>>> grep -r lists.linuxgazette.net /etc/exim4
>>>>
>>>> ...and both came up null. Which lead to my surmise 'it
>>>> looks like the MTA doesn't care what it's addressed as' -- because, if
>>>> it cared, then linuxmafia.com and lists.linuxgazette.net would be
>>>> mentioned in Exim4's conffiles, right?
>>>>
>>>> But, actually, turns out, no.
>>>>
>>>> 'lists.linuxgazette.net' is no longer present because I removed it some
>>>> years ago, and forgot having done so. Around 2010, the domain owner
>>>> decided to re-host _Linux Gazette's_ mailing lists on his own machine,
>>>> and changed the DNS. Some time after that, I apparently got around to
>>>> removing the FQDN from Exim4's 'accept mail for these' setting.
>>>>
>>>> 'linuxmafia.com' isn't mentioned inside the /etc/exim4/ tree because
>>>> it gets parsed from /etc/mailname.
>>>>
>>>> So, it turns out Exim4 _does_ care what it's addressed as. The list of
>>>> FQDNs _other_ than the one in /etc/mailname is in
>>>> /etc/exim4/update-exim4.conf.conf:
>>>>
>>>> ---<begin>---
>>>>
>>>> # /etc/exim4/update-exim4.conf.conf
>>>> #
>>>> # Edit this file and /etc/mailname by hand and execute update-exim4.conf
>>>> # yourself or use 'dpkg-reconfigure exim4-config'
>>>> #
>>>> # Please note that this is _not_ a dpkg-conffile and that
>>>> automatic changes
>>>> # to this file might happen. The code handling this will honor your local
>>>> # changes, so this is usually fine, but will break local schemes that mess
>>>> # around with multiple versions of the file.
>>>> #
>>>> # update-exim4.conf uses this file to determine variable values to replace
>>>> # the DEBCONFsomethingDEBCONF strings in the configuration template files.
>>>> #
>>>> # Most settings found in here do have corresponding questions in the
>>>> # Debconf configuration, but not all of them.
>>>> #
>>>> # This is a Debian specific file
>>>>
>>>> dc_eximconfig_configtype='internet'
>>>> dc_other_hostnames='unixmercenary.net:substancez.com:mail.substancez.com:sf-lug.org:lists.sf-lug.org:sf-lug.com:lists.sf-lug.com'
>>>> dc_local_interfaces='198.144.195.186:127.0.0.1'
>>>> dc_readhost=''
>>>> dc_relay_domains=''
>>>> dc_minimaldns='false'
>>>> dc_relay_nets='76.191.131.7'
>>>> dc_smarthost=''
>>>> CFILEMODE='644'
>>>> dc_use_split_config='true'
>>>> dc_hide_mailname=''
>>>> dc_mailname_in_oh='true'
>>>> dc_localdelivery='mail_spool'
>>>>
>>>> ---<begin>---
>>>>
>>>> As you will see, I've added these:
>>>>
>>>> sf-lug.org
>>>> lists.sf-lug.org
>>>> sf-lug.com
>>>> lists.sf-lug.com
>>>>
>>>> Daniel Gimpelevich (visiting this evening for the CABAL
>>>> meeting) also owns domain that we added to that list for
>>>> testing purposes (that is now no longer in that list).
>>>>
>>>> I re-ran /usr/sbin/update-exim4.conf, which parses the above information
>>>> from /etc/exim4/update-exim4.conf.conf and (following those
>>>> instructions) constructs Exim4's runtime configuration file,
>>>> /var/lib/exim4/config.autogenerated. Then, I restarted Exim4, and
>>>> Daniel sent a test message to mailbox 'danielg4@[hisdomain]' --
>>>> and we confirmed that it reaches his danielg4 account on linuxmafia.com.
>>>> Thus, adding the four domains above (as I've done) means my
>>>> server's MTA _will_ now accept mail from any of those FQDNs _if_ those
>>>> FQDNs are pointed to my server's IP in the public DNS.
>>>>
>>>> All _four_ of the FQDNs cited are now accepted so that y'all may
>>>> use any of them. E.g., at one point, Jim wanted it to be just
>>>> 'sf-lug.org', later discussion suggesting 'lists.sf-lug.org' (which
>>>> sounds better to me). But you may now use any.
>>>>
>>>>
>>>>
>>>> I have set up temporary mailing list 'test2' on my server. After your
>>>> DNS change (pointing your chosen FQDN to my IP), Daniel will see if he
>>>> can send mail to test2 at lists.sf-lug.org (or whichever FQDN you elect)
>>>> and have it send him his subscriber copy.
>>>>
>>>> If that works, I'll adjust this mailing list to list
>>>> 'sf-lug at lists.sf-lug.org' (r whichever FQDN you elect) in Mailman as the
>>>> mailing list's 'preferred address'. FYI, addressing it as
>>>> sf-lug at linuxmafia.com will continue to work, too.
>>>>
>>>> Pleaes let us-all know what you do with the DNS. Thanks.
More information about the sf-lug
mailing list