[sf-lug] *un*done*: SF-LUG & MX records ... @lists.sf-lug.org ...
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Tue Jan 12 01:09:43 PST 2016
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