BALUG-Admin

balug-admin@lists.balug.org

2 participants
548 discussions

Re: [BALUG-Admin] BALUG list(s) unsubscribe
by Rick Moen 15 May '18

15 May '18

Michael, let me recap points I made in our offlist discussion involving trying to help the guy who insists unsubscribing 'doesn't work'. In the case of such a user: 1. It's useless merely asking the subscriber 'What steps you're following', because the subscriber doesn't remember. Comment: If you're serious, stress the need to _reproduce_ the problem and take accurate notes. 2. It's useless merely asking the subscriber 'The error diagnostic(s) (if any) you're getting', because the subscriber doesn't remember. Comment: As above. 3. It's useless merely asking the subscriber to provide 'FULL EMAIL HEADERS of an example message', because the subscriber has no idea how. (Shouting doesn't clarify.) Comment: The user may not even know what a 'header' is, at all. If he/she does, the current ones look pretty 'full'; what does 'full' mean? They've probably never seen full headers, and wouldn't know them from an anaconda. If you're serious, best solution would be to provide two image files, showing the same messaage with truncated vs. full headers, and say 'See how the full version has many your mailer normally hides for simplicity? Notice the ones starting with Received? Those and more are needed for diagnosis. Dig in your mailer for a means to reveal them that might be called "Show original" or "Show source", but might be called something else.' 4. It's pointless to admonish the subscriber to never furnish his/her subscription password to the listadmins, as the listadmins have full power to do mischief if they're Bad People, without such passwords. And telling 'I can't unsubscribe' people that is just a pointless distraction from their real problem. Comment: Seriously, users haplessly mailing their subscriptions around the Internet is very close to harmless to them. Them mailing those to listdmins is _totally_ harmless. Neither risk is worth dwelling on, especially in an instructional mail the user is already going to find both challenging and a little offputting. On points 1-3, I'm very, very much reminded of hard lessons learned from CABAL's long history running public installfests. When we started doing that in 1998, we brightly and optimistically hoped and expected attendees would download and fill out a simple hardware questionnaire, e.g., how much RAM, what CPU, how big hard drives. As other 1990s LUGs around the world also found out, this was a total, whopping flop. I think it flopped so hard that we deleted the questionnaire out of sheer disgust, though some other early CABAL materials survive here: http://linuxmafia.com/pub/linux/cabal/ Note in particular the CABAL FAQ that Don Marti and I co-wrote: Some of that excess optimism about attendees being able to pony up information about their computers survives in parts of the FAQ. The hard lesson was: They don't know. Which means, if you're serious about getting that information accurately out of them, you need to either teach them or furnish an automated software tool to gather it. The best answer we got (to the questionnaire) was no answer. But some attendees figured they needed to write down something to make the organisers happy, so they took wild guesses about, say, how much RAM their machines had, and tended to be hilariously wrong. (Needless to say, guesses were worse than lack of answers.) Why don't they know? Because they never bothered to figure out how to get those answers, and didn't know where to start. Even though, say, the POST RAM count whizzed by their eyes every time they booted (well, until OEMs started hiding the POST process behind pretty pictures), they lacked the curiosity to poke at the machine and investigate to answer obvious questions. But, the subtler problem: Sometimes they _once_ knew, but forgot what they used to know, and figured a retrospective attempt to guess from dim and fading memory was good enough. _You and I_ know that getting reliable information from a computer means producing it contemporaneously and capturing / writing it down _then_. But amateurs make the error of trying to just remember this stuff -- _all the time_. I had been co-author of 'How to Ask Questions the Smart Way' for untold years when the insight of people totally failing to capture contemporaneous diagnostic data hit me like a ton of bricks. I had kept on, for years, trying to convey the right message to readers through cute, clever word tricks like this 'Missouri' one in the essay: Describe the problem's symptoms, not your guesses [...] Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us. Describe your problem's symptoms in chronological order [...] Users, even people familiar with the essay, kept posting their guesses and not raw diagnostic data. Why? I figured it out: Because the raw data scrolled off the screen and into fading memory, and the user wasn't smart enough to go re-acquire it. If I'd been in the room with that user, I'd have said 'What? Wait, you _didn't_ go back and reproduce the symptom a second time so you can take accurate notes? What sort of crazy approach is that? Why the hell not?' But they don't know -- and, being remote from them across the Internet, we can't see them screwing it up, and are unaware of them flubbing the ground-level basics. My real epiphany involved the least competent poster to the OCLUG (Orange County LUG) mailing list, a guy who's always posting vague requests for help and supplies about 70% of the mailing list's traffic. At one point, he provided a supposed diagnostic message that was _obviously_ grossly inaccurate for reasons including misspellings, and, suddenly realising the key problem, I asked 'You typed that from memory, didn't you?' He was a little cagey, but the answer was yes. I patiently pointed out that helpers would be attempting to Web-search the diagnostics, so inaccurate transcription was fatal. 'Oh.' And _why_ did he type it from memory? Because it just never occurred to him to reproduce the problem (taking accurate notes, this time) _before_ asking for help. Remember: They don't 'get' these rock-bottom basics. Just not. If they did, they wouldn't be in endless trouble. And frankly, anyone who cannot figure out how to unsubscribe given help in every posting footer and bountiful help on the Web is self-selected in advance for exactly that kind of haplessness.

1 0

Re: [BALUG-Admin] handling the spam to balug-speaker-coordinators
by Michael Paoli 24 Apr '18

24 Apr '18

[Bcc: balug-speaker-coordinators(a)balug.org] Well, taking this on-list because, ... well, why not, ... > From: "Grant Bowman" <grantbow(a)partimus.org> > Subject: handling the spam to balug-speaker-coordinators > Date: Mon, 23 Apr 2018 13:54:32 -0700 > What's the best way to handle the spam to balug-speaker-coordinators? Well, let's see, o one could volunteer, get an account on the relevant host, and at least make suggestions regarding configuration changes to reduce spam, ... but note too, that for most @balug.org addresses (notably aliases), one would want a quite low rate of false positives. But regardless I'm sure the anti-spam filtering could be well improved even with that constraint. Oooh, you already have an account - that makes much of that that much easier: $ hostname; fgrep -i bowman /etc/passwd balug-sf-lug-v2.balug.org grantbow:x:14589:14589:Grant Bowman,,,:/home/grantbow:/bin/sh $ o one could ask/recruit volunteers to assist ... but may be faster and more efficient (and frankly more likely to get done and/or sooner) if one is able to do more/much of it oneself. E.g. much more likely something gets done if one is able to do it oneself, or short of that, hand one with the access a well tested configuration to fix the issue along with evidence it's been well tested and addresses the issue - much more likely something like that gets done, than something more like "I have an issue, figure it out and fix it for me." ;-) And yes, there may well even be folks that would be interested in learning some of the relevant bits - so you might, e.g. ask on list - maybe could even be bit of team/cooperative effort. o If I'm not mistaken, most all of the MTA and anti-spam configuration on the host is world-readable - most notable exception being private key for TLS/SSL cert for STARTTLS MTA processing. If there's something one needs to read there but doesn't have access, let me know, and likely that can be addressed as relevant/appropriate. Wow, lookie, even have a fair bit of sudo access already (probably more than needed for looking at MTA/anti-spam configuration bits, but regardless): $ sudo sudo -l -U grantbow | sed -ne '/may run/,$p' User grantbow may run the following commands on balug-sf-lug-v2: (root) /bin/su - balugwm2 (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 $ Also, I've made mention on some list(s) ... don't recall which one(s) off-the-top-of-my-head (perhaps this one) ... a few items of note. May possibly consider changing MTA on the host - but it would need to well work with mailman (which covers the @lists.balug.org addresses). Most of the anti-spam uses Eximconfig - but though that was a good base start for anti-spam, it's apparently no longer maintained, so also quite possible the "best" anti-spam solution(s) for the needs (including fit for the OS and mailman, and also resources the VM does/doesn't have), may possibly involve a change in MTA. But given all the interdependencies (mailman, live production, lists, aliases, etc.), change of MTA would need be well tested somehow ... and any anti-spam configuration changes should also be sufficiently well tested - at least to the extent feasible. Also, a bunch of the current anti-spam is relatively Python based ... but that may mostly have to do with the current MTA and Eximconfig more than anything else. Anyway, certainly feel free to have a look around, etc. If you want me to implement some specific (reasonably well tested/vetted) configuration changes, just let me know the specifics (also probably not bad idea to put it on this list ... more eyeballs may better spot things we could do better, and public searchable is more opportunities for others to find and learn from same). Also, one can expect that the @balug.org email addresses ... notably especially publicly listed (and mandatory, etc.), such as balug-speaker-coordinators, postmaster, balug-webmaster, balug-contact, etc. do get spam, and given the need for low false-positive rate on filtering, there's likely to always be some moderate flow of spam that make it through. I'm sure I've made at least some mention of this before. List admins such as myself likewise deal with a lot of that for the @lists.balug.org ... but there it's mostly caught and held for processing as a non-list member post attempt, reviewed by listadmin(s), and discarded (or simply left to expire based on the generally obvious spam nature and the ease of doing nothing to have it disposed of).

1 0

BALUG & IPv6 - separate IPv6 addressed dedicated (mostly & primarily) for BALUG
by Michael Paoli 17 Dec '17

17 Dec '17

BALUG & IPv6, Did finally, yesterday, get around to updating, so BALUG is now using IPv6 address that also has "reverse" (PTR) data that indicates balug.org - most notably useful for SMTP and reducing probability of rejection as "spam". That was the principle motivation for the IPv6 address change. $ dig +short balug.org. AAAA 2001:470:1f05:19e::2 $ dig +short -x 2001:470:1f05:19e::2 balug.org. $ That IP address is also the default source IPv6 address for IPv6 traffic to The Internet from the Virtual Machine (VM). Many/most publicly accessible services are still (also) listening on IPv6 wildcard address, but may also change that in future. DNS NS data hasn't been changed yet (future). But that does remind me ... DNS IPv6 notify source address - yes, that, by default, had also changed ... so today I switch that back at least 'till DNS slaves have been suitably notified, etc. SF-LUG - at least that of it on same VM, has its own separate IPv6 address ... however since they're on one single host, for default outbound IPv6 address, they share the same common IPv6 - which is primarily for BALUG (it's a BALUG VM also hosting some SF-LUG services, not vice versa). > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: SF-LUG <sf-lug(a)linuxmafia.com> > Subject: SF-LUG & IPv6: Re: IPv6 ... all those addresses! ... > Mmmmmm... yummy! (+ free t-shirt!) > Date: Sat, 16 Dec 2017 12:40:45 -0800 > So ... most things SF-LUG, notwithstanding list (Thanks Rick!) > and DNS nameserver related record bits (future), > and possibly some DNS TTL bits (up to 4 hours for older cached > data to expire), > have mostly had SF-LUG's IPv6 moved to address "just" for > SF-LUG stuff: > $ dig +short www.sf-lug.org. AAAA > 2001:470:1f05:19e::3 > $ dig +short -x 2001:470:1f05:19e::3 > sf-lug.org. > $ > Well ... those non-list SF-LUG things, are hosted on > virtual machine which is primarily BALUG, so IPv6 > connections originated from that virtual machine will > still have a different IPv6 source address (notably that > of BALUG's), but mostly, other than that, SF-LUG has it's > "own" IPv6 address. The sf-lug.org domain is canonical, > and for web, it's www.sf-lug.org, but the IPv6 changes > likewise apply to the non-canonical domain sf-lug.com. > >> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> >> To: SF-LUG <sf-lug(a)linuxmafia.com> >> Subject: IPv6 ... all those addresses! ... Mmmmmm... yummy! (+ >> free t-shirt!) >> Date: Wed, 25 Oct 2017 07:19:59 -0700 > >> $ (for ipv6 in 2001:470:1f04:19e::2 2001:470:1f05:19e::2 >> 2001:470:1f05:19e::3; do echo "$ipv6" $(ssh -6 -aqx "$ipv6" >> 'hostname') $(dig -x "$ipv6" +short); done) >> 2001:470:1f04:19e::2 balug-sf-lug-v2.balug.org >> BALUG-1-pt.tunnel.tserv3.fmt2.ipv6.he.net. >> 2001:470:1f05:19e::2 balug-sf-lug-v2.balug.org balug.org. >> 2001:470:1f05:19e::3 balug-sf-lug-v2.balug.org sf-lug.org. >> $ >> >> So, yes, IPv6 ... *lots* of addresses! :-) And that's generally a *good* >> thing. We have been and are seeing with IPv4, where too few ends up. 8-O >> >> Anyway, a couple items ... >> >> Virtual Machine, SF-LUG, and BALUG. Should have gotten around to it >> much earlier, but ... >> So ... excepting SF-LUG list stuff (Thanks Rick!), DNS slaves (Thanks >> Rick & others) and some other trace bits, the SF-LUG and BALUG stuff >> essentially all runs on one virtual machine. Now, it would generally be >> good, if/as feasible, to have those reasonably well separated out ... >> most notably so they can/could be "peeled apart" easily if or whenever >> that might be desired or necessary. If I had an (over) abundance of >> resources (system resources, sysadmin resources, IPs, bandwidth, etc.), >> I'd probably have them (much) more fully separated out. Though there >> are also some efficiencies gained by *not* having them totally separated >> out (though many of those efficiencies could also be gained, even if >> separated out, through various configuration management and similar >> tools/infrastructure). Anyway, to the extent reasonable feasible within >> the one VM, SF-LUG and BALUG are *reasonably* separate. E.g., though >> running on a common webserver, their distinct configurations are well >> separated out, and for most intents and purposes - most notably to >> "outside" (seeing the Webserver from The Internet), they mostly look and >> act pretty separate and independent. E.g. they even have their own >> separate SSL/TLS CA certs - even though they share the same IPv4 >> address. And, ... IPv6? :-) Yeah, that's the part I should've gotten >> around to (much) earlier, but anyway ... no shortage of addresses, so >> ... just added some, so SF-LUG and BALUG can effectively have their own. >> And ... why might that matter? Email is a fairly good example. MTA >> should have "reverse" DNS entry. If one IP is used, there's one entry >> (or set of entries) for the IP ... which is less than optimal. But with >> separate IPs, each can have their own "reverse" DNS entry. E.g.: >> $ dig +short -x 2001:470:1f05:19e::2 >> balug.org. >> $ dig +short -x 2001:470:1f05:19e::3 >> sf-lug.org. >> With both of those IPs - in fact all 3 IPv6 IPs shown in the code >> snippet at the top of this post - on the same (virtual) host. >> For MTA, the "reverse" DNS should generally match the sending domain, or >> a parent domain (but not above registrant level). Such can also look >> more "clean" and proper for, e.g. Web site addresses. >> >> And ... Linux, and adding additional IPv6 IPs to a host? That's >> relatively easy. One could go quite hog wild 8-O with that ... but I >> don't want to be to excessive/messy with the VM, etc. So ... at present >> there are 3 Internet routable IPv6 addresses, 2 of which I very recently >> added. One of them is local host endpoint of IPv6 tunnel (alas, my ISP >> doesn't yet offer native IPv6 on the particular plan I'm on ... but they >> have at least started deploying native IPv6). The "reverse" DNS on that >> one ... uhm, yeah, I can't set/change that - it's set by the tunnel >> provider. However, from same tunnel provider, also get another routable >> /64 block where I get to fully control the "reverse" DNS ... and have >> done so. Hence two more addresses - one for SF-LUG, one for BALUG. >> >> Still lots more to do on that - like more DNS data updates, >> setting/changing (or not) which IP address is default source IP address, >> due attention to any transitions and possible race conditions, etc. All >> of which should be done carefully to avoid potential problems. Might >> even pick different IP addresses, for various reasons. In any case, >> very nice to have the flexibility and availability ... unlike IPv4 where >> it's more like ... ya'll just get one and you're gonna have to learn to >> share ... deal with it.

1 0

balug.org - CAA DNS records added
by Michael Paoli 13 Dec '17

13 Dec '17

balug.org - CAA DNS records added https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://tools.ietf.org/html/rfc6844

1 0

Debian 9.2 Exim4 "vs." Eximconfig
by Michael Paoli 07 Dec '17

07 Dec '17

Debian 9.2 Exim4 "vs." Eximconfig Ah, drats, found (and thus far partially) corrected one other glitch. /etc/exim4/eximconfig/bin/spfd doesn't play very well - at least as provided with the spfd on Debian. I checked, found emails getting temporary rejections due to the Eximconfig configured to use spfd, but not managing to talk to it. Turns out there's syntax changes on invoking the Debian provided spfd (at least the one I've got installed) ... and compared to whatever I had before with Debian 8.9. And rather oddly also, for /etc/exim4/eximconfig/bin/spfd where does it have its configuration on how it invokes the operating system provided spfd? In /etc/exim4/eximconfig/bin/spfd itself! It also has some odd funkiness and really ought do with a more proper rewrite (e.g. it's status functionality is seriously flawed - thus it fails to detect that spfd is already running, fails to stop it, starts multiple instances of it). Anyway, have it "working" at the moment - at least up and functional. Need to make more adjustments to /etc/exim4/eximconfig/bin/spfd so it's more operationally functional ... notably so it's status and stop arguments work, and it's start argument will detect when spfd is actually already running. I get the sneaking suspicion I may end up replacing much or all of Eximconfig with something much more maintainable ... and reasonably current ... though it may still serve as reference on general approach, but seems hazardously outdated as to actual configuration, etc.

1 0

"all better now:" Re: outage: [www.]{sf-lug, balug}.org (ETR: eveningish)
by Michael Paoli 07 Dec '17

07 Dec '17

Had an outage earlier today (DSL modem issue ... it does that once in a while) ... "all better" now: ----- Forwarded message from Michael.Paoli(a)cal.berkeley.edu ----- Date: Wed, 06 Dec 2017 18:08:09 -0800 From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> Subject: "all better now:" Re: outage: [www.]{sf-lug,balug}.org (ETR: eveningish) To: SF-LUG <sf-lug(a)linuxmafia.com> And ... swift kick to the power switch on DSL modem to reset it, and "all better now". Looks like the outage started around: BALUG PING: ping6 2001:470:1f04:19e::2 FAILED 2017-12-06T20:53:56+00:00 GW PING: ping 198.144.194.233 FAILED 2017-12-06T20:54:09+00:00 and service restored a few minutes ago > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > Subject: outage: [www.]{sf-lug,balug}.org (ETR: eveningish) > Date: Wed, 06 Dec 2017 14:46:38 -0800 > So, > > They were up and on-line this morning, at least as late as about > mid-morning or later, but off-line now. > POTS line appears to be working, but not IP, > likely the DSL modem needs to be reset (powercycled) again ... > but don't have means to do that remotely. > > Presumably I'll have this resolved sometime this evening once I'm > on-site again. > > impacts all [*.]sf-lug.{org,com} & [*.]balug.org > SF-LUG lists remain up and on-line (at least as far as I'm aware). ----- End forwarded message -----

1 0

balug VM just got a performance/reliability boost
by Michael Paoli 05 Nov '17

05 Nov '17

The balug VM (which also hosts SF-LUG non-list content), just got a performance/reliability boost for at least its nominal hosting environment. It's virtual disk had been on ZFS (under fuse) with aggressive compression and deduplication, which optimized for space (atop SSD), but gave performance that was sometimes problematic (notably on a physical host not having an overabundance of RAM). Anyway, just moved that to SSD - with none of those space (but not performance) optimized ZFS layers ... much snappier and faster now. As for drive(s) on the alternate ("vicki") physical host, those are mirrored spinning rust ... but quite "fast enough" for balug VM purposes. On the nominal location, that SSD for the balug VM isn't (yet) mirrored ... but fairly likely I'll add that in near future (the VM not only gets relatively regular backups, but also each time a live migration is done, that also creates an inherent backup upon the physical host it moves from - and that's generally done at least 4 times per month). Both hosting environments do have LVM layers (negligible performance hit, substantially aids manageability), and the nominal host also has LUKS encryption layer (again negligible performance hit given the power of non-ancient CPU(s)/cores). before: # time dd if=balug-sda bs=512 of=/dev/null 33554432+0 records in 33554432+0 records out 17179869184 bytes (17 GB) copied, 288.979 s, 59.5 MB/s real 4m48.980s user 0m2.920s sys 0m20.852s # after: # time dd if=balug-sda bs=512 of=/dev/null 33554432+0 records in 33554432+0 records out 17179869184 bytes (17 GB) copied, 44.2483 s, 388 MB/s real 0m44.251s user 0m2.852s sys 0m29.280s # Or with a different block size (128 KiB is optimal for my ZFS configuration), and even with it no longer having any (notably RAM) contention of the VM running from the older storage: old: # time dd if=balug-sda.old bs=131072 of=/dev/null 131072+0 records in 131072+0 records out 17179869184 bytes (17 GB) copied, 75.5826 s, 227 MB/s real 1m15.589s user 0m0.096s sys 0m5.060s # new: # time dd if=balug-sda bs=131072 of=/dev/null 131072+0 records in 131072+0 records out 17179869184 bytes (17 GB) copied, 40.3681 s, 426 MB/s real 0m40.372s user 0m0.072s sys 0m19.776s # But it did have that space optimization (note physical vs. logical): # ls -hls balug-sda.old 5.2G -rw------- 1 root root 16G Nov 5 16:10 balug-sda.old # Within the VM itself, we see much more than 5.2G used: # df -h -t ext3; swapon -s Filesystem Size Used Avail Use% Mounted on /dev/dm-0 469M 237M 209M 54% / /dev/dm-1 1.7G 1.4G 178M 89% /usr /dev/sda1 244M 33M 201M 15% /boot /dev/mapper/balug-home 1.1G 635M 432M 60% /home /dev/mapper/balug-var 4.6G 3.9G 560M 88% /var Filename Type Size Used Priority /dev/dm-4 partition 131068 130944 -1 /dev/dm-9 partition 131068 130924 -2 /dev/dm-6 partition 131068 130816 -3 /dev/dm-7 partition 131068 94456 -4 /dev/dm-5 partition 131068 0 -5 /dev/dm-11 partition 131068 0 -6 /dev/dm-10 partition 131068 0 -7 /dev/dm-8 partition 131068 0 -8 # That's 16 GiB virtual drive, about 9.1 G of filesystem+swap space, in 5.2 of physical. The VM could certainly still use more RAM - that's its main performance bottleneck (given workloads & software and such). The constraints on that is the physical hosts upon which it runs. One of them ("vicki") only has 2 GiB of physical RAM total ... hence the VM is still at 1 GiB (the other physical host where it's nominally located, has 8 GiB, but that host also does lots of other stuff too, so also doesn't exactly have lots of RAM to spare). Anyway, may also come up with some more RAM resources in future (may shift the "alternate" physical host to one where more RAM is available). Ideally I'd like to bump the balug VM up to something in the 1.5 to 2 GiB range - possibly more ... but have to reasonably have that to spare from the physical hosting environments first. The balug VM does also have and use swap ... but that swap now also benefits from the improved virtual drive performance - at least on its nominal host.

1 0

(forw) [Bug 1707447] Re: Roster should not lowercase addresses
by Rick Moen 27 Oct '17

27 Oct '17

Hey, Michael P.! Remember when we noticed this one, I filed a bug report on July 29th, and upstream Mailman maintainer Mark Sapiro immediately furnished a patch? Here it is, closing the loop by being changing fix status from committed to released. ----- Forwarded message from Mark Sapiro <mark(a)msapiro.net> ----- Date: Thu, 26 Oct 2017 21:22:50 -0000 From: Mark Sapiro <mark(a)msapiro.net> To: rick(a)linuxmafia.com Subject: [Bug 1707447] Re: Roster should not lowercase addresses Reply-To: Bug 1707447 <1707447(a)bugs.launchpad.net> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1707447 Title: Roster should not lowercase addresses To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1707447/+subscriptions ----- End forwarded message -----

2 1

After compensating for flaky secondaries, one notes flaky primaries
by Rick Moen 16 Oct '17

16 Oct '17

Thought you'd be amused at this cautionary tale, Michael P. ----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Mon, 16 Oct 2017 10:05:29 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: Duncan MacKinnon <duncan1(a)gmail.com> Subject: Rest of that story about secondary DNS Organization: If you lived here, you'd be $HOME already. I _think_ I started to tell you a story about doing secondary DNS for people, and something I learned. Of course, the standard model is supposed to be: You do auth DNS for my domains; I do it for yours. Years ago, I started to see the flaw in that optimistic, we-help-each-other mental model. There was a user group in Santa Cruz, SMAUG, which owned domain 'scruz.net'. (Terrible naming and choice of domain; not my doing, not my call.) I ended up being primary/master DNS, and we were doing really well because we signed up five more individuals with auth nameservers to help out with secondary/slave DNS, for six auth nameservers total, widely dispersed geographically and with a lot of geographic diversity. That's fabulous redundancy. What could possibly go wrong? </deadpan> I relaxed about quality of service, because obviously we were way ahead of the game. (SMAUG had a mailing list on the SVLUG mailing list server. The mailing list still exists, derelict, the group having now fallen apart.) Roll forward to one day when my household uplink through Raw Bandwidth Communications was offline for about an hour because SBC/AT&T shot the company in the foot. When my aDSL came back, I found postings to SMAUG's mailing list bitching about the scruz.net nameservice having been totally offline. I noticed that some of the complaining came from the five individuals who were allegedly doing secondary/slave nameservice. Hmm? So, I checked on the five secondaries. Certainly, my aDSL being offline for an hour should not have taken all DNS offline. And what I found was: Over about a two-year period, some of the five had moved their nameservers to new IPs and failed to notify me as master nameserver admin. Some had ceased doing auth DNS entirely, and failed to notify me as master nameserver admin. Some still had the same nameserver running at the same IP as always, but had quietly ceased doing auth namservice for scruz.net, and failed to notify me as master nameserver admin. All of the nameserver IPs they'd provided me for their secondary nameservice were still listed in the whois (and as NS lines for the domain in the parent .net zone). But exactly one nameserver still existed and was actually _doing_ auth DNS for scruz.net -- mine. All five of the others had silently flaked out. Which made it extra galling that some of these guys complained about -my- nameservice being unreliable, since theirs was 100% unreliable, their having broken it in various ways, whereas mine worked great except once in a blue moon when my uplink went down. I thought: OK, obviously it turns out to be a mistake to just trust that secondaries will continue to exist and that their operators will do due-diligence communication with the primary when something important changes. They _should_, but it turns out they don't. So, I wrote a weekly cron script to check on all the secondaries for my two domains, linuxmafia.com and unixmercenary.net: It queries and reports the parent-zone NS "glue" records, queries and reports the nameservers declared authoritative in whois, and reports each auth nameserver's zonefile S/N so I can make sure they all respond and give the same value. This means I can detect and act on flaky secondaries. What I did _not_ do was bother writing a script to check on other people's master nameservers, on domains for which *I* do secondary nameservice. Failures in this case are almost entirely the domain owner's problem, not mine. As long as I keep _my_ word for quality of secondary DNS, I'm OK. Well, almost. I do secondary for five or six domains Ruben Safir owns, and recently double-checked those. For most of them, I advised Ruben _again_ that having only two auth nameserver isn't enough and is dangerously thin. I urged him to find a couple more, somewhere. For one of them, nylxs.com, I noticed and advised Ruben that _neither_ his nor my auth nameservers were authoritative any more. Instead of WWW2.MRBRKLYN.COM NS1.LINUXMAFIA.COM the records now listed the auth nameservers like so: $ whois nylxs.com | grep 'Name Server' Name Server: NS69.DOMAINCONTROL.COM Name Server: NS70.DOMAINCONTROL.COM $ I wrote Ruben: 'I find that you have _ceased_ using my secondary (slave) nameservice, but neglected to inform me. That's rude, Ruben. You need to friggin' tell your secondaries if/when you move auth nameservice somewhere else. Grr. Learn to do it right, already!' Turns out, that's not what happened, exactly. Ruben had failed to pay his domain renewal, so his registrar (GoDaddy) had repointed its DNS to 'parked domain' nameservice from its own domaincontrol.com nameservers, making those authoritative in place of Ruben's and mine. Luckily, because I (in effect) warned Ruben of his expired domain in time, he was able to renew it. So, lesson: When you find yourself annoyingly still doing futile secondary DNS for a domain whose owner _seems_ to have moved auth nameservice elsewhere without telling you, the explanation isn't always owner lack of diligence concerning communicating with secondaries: Sometimes, it's merely owner lack of diligence in paying the bill. ----- End forwarded message -----

1 0

DNSBL: lists.balug.org
by Rick Moen 12 Oct '17

12 Oct '17

Michael P.: I periodically check my mail server IP on http://multirbl.valli.org/ and/or http://www.dnsbl.info/ , to make sure it's not on any blocklist. (It was recently on one for cryptic reasons. When I politely inquired and stressed that I'd be glad to fix any problem but didn't understand the existing one, the listing was removed without comment.) $ host lists.balug.org lists.balug.org has address 198.144.194.238 lists.balug.org has IPv6 address 2001:470:1f04:19e::2 lists.balug.org mail is handled by 100 mx.lists.balug.org. $ http://multirbl.valli.org/lookup/198.144.194.238.html shows that one cluster of blocklists, the rfc-clueless.org one, doesn't like your IP. This is the successor to Derek Balling's rfc-ignorant.org DNSBL, which Derek eventually shut down, and has the same mission. The listing policy is here: http://rfc-clueless.org/pages/listing_policy Looks like they believe that 198.144.194.238 isn't accepting mail to postmaster. an RFC requirement for any FQDN that deals in SMTP (http://rfc-clueless.org/pages/listing_policy-postmaster). When I did a quick check telneting to 25/tcp, it seems to me that the system _was_ going to accept my manually composed mail to postmaster(a)lists.balug.org -- so I'm unclear on why that listing's there. Seems like they also have no-postmaster listings for FQDNs balug-sf-lug-v2.balug.org, balug.org, and temp.balug.org. Maybe you should actually cease accepting mail for those FQDNs.

2 7

← Newer
1
...
14
15
16
17
18
19
20
...
55
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

BALUG-Admin