- Roundtable - muug.ca

Re: [RndTbl] RegEx help needed (sed?)
by Paul Sierks 29 Nov '16

29 Nov '16

.* Is greedy, sed "s/^.*\/$[^_(a)]*$.*$/\1/" Kevin McGregor <kevin.a.mcgregor(a)gmail.com> wrote: >_______________________________________________ >Roundtable mailing list >Roundtable(a)muug.ca >https://muug.ca/mailman/listinfo/roundtable

3 2

O'Reilly "Cyber Monday" sale 60% off
by Trevor Cordes 28 Nov '16

28 Nov '16

O'Reilly is doing a big discount again: 50% off all ebooks/vids; 60% off if you spend $100+ (US). That's their biggest discount of the year. Ends after today (at 5am PT Nov 29) http://post.oreilly.com/rd/9z1z2jm74uo2g7rga2s4lclg3fehsfsom3pnnm71m9g

1 0

procmail replacement?
by Kevin McGregor 26 Nov '16

26 Nov '16

I've read that procmail is somewhat deprecated. Is this true? Is anyone still using it regardless? What replacements are there that you recommend? Kevin

5 5

IPv6 tunnels, Netflix, and AAAA records (was help! dns zone delegation wonky for AAAA)
by Theodore Baschak 25 Nov '16

25 Nov '16

> On Nov 24, 2016, at 3:54 AM, Trevor Cordes <trevor(a)tecnopolis.ca> wrote: > > First I found this named option: > filter-aaaa-on-v4 (and -v6) > "It is intended to help the transition from IPv4 to IPv6 by not giving > IPv6 addresses to DNS clients unless they have connections to the IPv6 > Internet." > Super description and chart here: > https://kb.isc.org/article/AA-00576/0/Filter-AAAA-option-in-BIND-9-.html <https://kb.isc.org/article/AA-00576/0/Filter-AAAA-option-in-BIND-9-.html> This came up recently for me in another discussion. As an IPv6 pioneer, I'm fully IPv6 enabled and have been for the last 10 years or so. At some points that has been over HE.net IPv6 tunnels, and more recently that has been native IPv6 access. As I'm my own ISP, and I do my own BGP for myself, the address ranges I use for myself are properly registered and located in Winnipeg, Manitoba so I don't have any issues running Netflix with their latest "war on tunnels". However, for people who have a HE.net IPv6 tunnel (very very common), which has IPv6 space which is registered in the US, this causes issues with netflix when requests start cross countries of apparent origin. One of the solutions I found that worked quite nicely was to run a separate recursive DNS server for netflix users that had the filter-aaaa-on-* options enabled. Queries for netflix domains are then routed to this DNS server that strips out the AAAA records so that netflix runs only over the IPv4 connection, originating from a Canadian IP keeping netflix happy. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/

1 0

New O'Reilly Humble Bundle of books!
by Trevor Cordes 25 Nov '16

25 Nov '16

Just like they did with No Starch Press, Humble Bundle has just offerred a new O'Reilly bundle with (up to) 16 *NIX ebooks for as little as $15 US$. Not bad. None are their newest titles, but there's still a lot of good stuff in there. And we all know that with *NIX most things don't go obsolete. If my math is on target, you have until Dec 7-ish to act on this. As with the NSP bundle, MUUG will be purchasing one bundle for DP giveaways. (And I'll be buying a set for myself too, though like many of you I already have around half of them on paper!) Thanks to Adam for originally spotting this. ==== Humble Bundle Get a library of O'Reilly ebooks and support charity You're not a Unix, are you? + 15 more great reference books from our friends at O'Reilly! https://www.humblebundle.com/books/unix-book-bundle

1 0

mailing list error
by Trevor Cordes 25 Nov '16

25 Nov '16

Apologies, but the MUUG mailing lists may have delayed/deferred (or even dropped) emails to a very small subset of members since the mailman migration in the last 2 weeks. If this applies to you you would not have received any muug mailing list emails during this time. Some of them may have just come through to you as I have now fixed the problem. Ones over 5 days (or so) probably got dropped. If you want to see the emails you may have missed, you can view them in the web interface: https://muug.ca/pipermail/roundtable/2016-November/date.html This problem only affected people who have mail servers that a) have STARTTLS enabled, *and* b) have their servers set to only allow obsolete encryption methods. If you can update your mail server to the latest version you will be less likely to have this problem in the future with other email senders. This problem will not occur on the muug lists again because I have disabled opportunistic muug-as-client smtp encryption. For those interested, the latest sendmail (which we may not be able to upgrade to for quite a long time) has an option to fallback to non-encrypted when the initial encrypted connection attempt fails. That would solve this problem more cleanly on the muug side. Not sure why this wasn't the default or available in sendmail the whole time, as the "encrypt or bust" paradigm we're stuck with in v8.14 is lame. No worries though, as 99% of the net still happily doesn't TLS smtp. It's more gravy than anything.

1 0

help! dns zone delegation wonky for AAAA
by Trevor Cordes 24 Nov '16

24 Nov '16

I'm seeing some weird behaviour related to AAAA and delegation I'd like to correct with a BIND DNS setup. I have no AAAA records anywhere. Some lookup tools/libraries insist on looking up AAAA, I want them to fail immediately. All servers/clients involved are run with the -4 option to run all traffic over IPv4. The problem is that I'm seeing occassional lookup delays for AAAA records on some boxes (the ones that delegate), but not other ones (every other box). On my box (BOX1) I'm authoritative for foo.com (only for my internal networks). On the same box, I delegate sub.foo.com to ns.com (BOX2). BOX2 is authoritative for foo.com and sub.foo.com. I do this so BOX1 can have local dynamic DNS for local Windows boxes, etc, on foo.com. Whereas the BOX2 view is for the whole world, to which I don't want to share the existence of windows.foo.com, etc. A bit messy, but this has worked for me for 15 years. The problem symptoms: I run "host bar.sub.foo.com " on the boxes: BOX1: bar.sub.foo.com has address 1.2.3.4 Host bar.sub.foo.com not found: 2(SERVFAIL) bar.sub.foo.com mail is handled by 5 bar.sub.foo.com. <often delays 5-10sec before giving the SERVFAIL BOX2 (and every other box in the world except BOX1!!): bar.sub.foo.com has address 1.2.3.4 bar.sub.foo.com mail is handled by 5 bar.sub.foo.com. I don't want the delay or the SERVFAIL on BOX1. The host command by default does a lookup of AA, AAAA and MX in that order. That's fine. But I want them all to run without delay, and the AAAA to be ignored like it is on BOX2. Again, there are no AAAA records in any of these zone files. I think I'm seeing the precise bug discussed here: https://tools.ietf.org/html/draft-ietf-dnsop-misbehavior-against-aaaa-00 search to: 4.4 Make Lame Delegation That document doesn't seem to provide any solutions. I think the issue is when BOX2 (or any box but BOX1) does a lookup, it checks only with BOX2, sees there's no AAAA and happily ignores AAAA. I think in essence it's like "I'm BOX2, I'm authoritative and I have no AAAA". host is happy with this. With BOX1, it does a lookup with BOX1's named which recurses out to the delegation on BOX2. BOX2 says the same as it did above, but this time it's talking to BOX1 named, not the host command. BOX1 named must be saying "I thought BOX2 was authoritative, but I find no AAAA so it's not authoritative after all, and I don't know anyone who is so I'm spewing this error SERVFAIL". I'm just guessing here. I want the host command on BOX1 to behave the same as BOX2. Can it be done? I actually was seeing the exact same problem with the nonexistent bar.sub.foo.com MX record and I solved it by adding an MX record for it on BOX2. However, I don't want any AAAA record on any box, as none of them have IPv6 addresses! Surely there must be a solution to this weird problem. Possibly relevant is how dig behaves with different usage: BOX1#dig -tAAAA @localhost bar.sub.foo.com ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2619 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;bar.sub.foo.com. IN AAAA BOX1#dig -tAAAA @ns.com bar.sub.foo.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5477 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;bar.sub.foo.com. IN AAAA ;; AUTHORITY SECTION: foo.com. 86400 IN SOA ns.com. 17 1800 300 604800 86400 BOX2#dig -tAAAA @localhost bar.sub.foo.com **pretty much the same output as above 2nd example, NOERROR** BOX2#dig -tAAAA @ns.com bar.sub.foo.com **pretty much the same output as above 2nd example, NOERROR** It's that SERVFAIL in example dig #1 above that I want to eliminate, and thus also the SERVFAIL with host. Thanks!

3 7

home network hangs up when ISP diconnected
by c0l0nelFlagg 24 Nov '16

24 Nov '16

My apologies for the previous reply post to ask this new question. I have a home network that appears to stop working whenever the ISP connection to the outside world is dropped. I am not sure why or how to remedy it which is why I am posting here. I have 5 linux workstations on the internal network 3 MINT 18, 1 XUbuntu, and 1 UbuntuStudio all the latest versions. 3 of the workstations (all MINT ones dual boot to Win 7 Pro as well). I also have a dedicated Ubuntu server on the network (also the latest Ubuntu version). The ISP connection (being in a rural area) is a cellular voice/data hub. The data connection from the hub feeds the hot or RED NIC input to the dedicated firewall machine Smoothwall Express. The GREEN or LAN side output from the Smoothwall machine then feeds a couple of Gigabit Ethernet smartswitches connecting to the network workstations, server, and smart TV's and Canon MP620 networked printer. The Smoothwall dhcp server capabilities are set up to assign IPv4 addresses to each permanently connected LAN device with a reserved IPv4 address based on the device's MAC address. All network devices have the Smoothwall specified as the 1st dns address as well as gateway device. The second dns device is the IPv4 address assigned to the ISP voice data hub which is the gateway for the smoothwall machine. A third alt dns address is Google's public dns at 8.8.8.8. Under normal serviceable connections, all is well, however if I lose the ISP connection everything running linux appears to get bogged down as if it was waiting for long timeouts of some sort; and if win 7 Pro is running the IP address assigned to the NIC's in those machines get changed from the initially assigned class C address to the default windows 169 series and of course the networking quits working on them as well. What I am trying to find out is if the smoothwall is acting as a local dhcp server, a local dns caching server as well as the gateway why is everything grinding to a halt whenever the ISP connection goes down? and what I can do to prevent it from stopping functions in the future. All machines have full local network addresses specified in hosts, host.sam files and the order of precedence is to resolve using those files first then dns. When ISP connection is down the linux boxes are all able to see the NFS shares by using the host file info but samba and windows boxes just go south for some reason. Any tips or help is appreciated.

3 4

MUUG Mailing Lists Migrated
by Trevor Cordes 18 Nov '16

18 Nov '16

The MUUG e-mailing lists (of which you are a subscriber if you are reading this email!) have been migrated from the old server to the new one. With this change we are encouraging everyone to update their address books (and spam exception lists, etc.) to use @muug.ca instead of the old @muug.mb.ca. For the time being, both domains will function, but from this point on, muug.ca will be the preferred domain. In the distant future, muug.mb.ca will probably go away. For example, to send email to the roundtable mailing list, you'd now send it to roundtable(a)muug.ca In addition, with the migration of the mailman mailing list web archives, thus concludes our migration of the entire MUUG web and ftp trove, and you can update your browser bookmarks to the new domain as well. If you notice any glitches, please let the MUUG board know. Thanks! Additional: I'd like to say a word of thanks to lisa, our venerable AMD dual-core muug server, having served us well for 5 years. Thanks lisa. And thanks to the U of M for having hosted us all those years! https://muug.ca/mona5.html (for the complete history) (For comparison, MUUG's 1994 server was a SPARCstation 2 with 1G disk and 16MB RAM!)

3 4

muug test 0
by Trevor Cordes 15 Nov '16

15 Nov '16

please ignore this test (we're working on the servers)

1 0