Roundtable

roundtable@muug.ca

2555 discussions

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

MUUG Meeting, Nov 8, 7:30pm -- Powerland Technology Announcement
by Gilbert E. Detillieux 01 Nov '16

01 Nov '16

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, November 8. The meeting topic for this month is as follows: Powerland Technology Announcement The presentation this month will feature guest presenter Neil Thomson, from Powerland Computers. Neil is a senior solution architect at Powerland, and will be presenting some of the latest technology announced by HP and Intel. Daemon-Dash: nginx For this month's Daemon-Dash, Paul Sierks will present nginx, a high-performance web server using a modular event-driven architecture. AGM Plus, this month's meeting will be the MUUG annual general meeting, which includes the election of the MUUG board of directors for the 2016-2017 year (most likely by acclamation). The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ****************************************************************** Please note our *NEW* meeting location for this month: *Room 1M28* (1st floor) Manitoba Hall, University of Winnipeg, entrance on Ellice Ave. between Spence St. and Balmoral St. Parking is available on the surrounding streets and in the lots on nearby streets. Look for signage once you're at the building, or ask a security guard. ****************************************************************** For more information about MUUG, and its monthly meetings, check out their web server: http://www.muug.mb.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: http://www.muug.mb.ca/meetings/MUUGmeeting.pdf -- Manitoba UNIX User Group E-mail: <gedetil(a)muug.mb.ca> c/o Gilbert E. Detillieux Web: http://www.muug.mb.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609

1 0

Ubuntu Muug repo?
by Grigory Shamov 27 Oct '16

27 Oct '16

Hi All, Perhaps a strange question: I mostly use CentOS; and for it there is Muug repo, which is nice and fast and close. Now I am trying Ubuntu : is there a Muug Ubuntu repo, and if yes, what do I put into /etc/apt/sources.list to get it? -- Grigory Shamov Westgrid/ComputeCanada Site Lead University of Manitoba E2-588 EITC Building, (204) 474-9625

2 2

wacky NFS port problem
by Trevor Cordes 24 Oct '16

24 Oct '16

OK, this is a new one... Updated my kernel and rebooted tonight. Everything came up fine. Except dovecot (IMAP server). It complained: Error: service(imap-login): listen(*, 993) failed: Address already in use (993=imaps) OK. Except: #netstat -tulpn | grep 993 <nothing> #lsof -i:993 <nothing> #ss -t -l 'sport = 993' <nothing> A wasted hour later I did: netstat -n |grep 993 Sure enough I had a tcp connection between my workstation and my file server on 993 to 2049. grep 2049 /etc/services... eureka! 2049 is nfs. >From what I've figured out, nfs, which I have mount something on boot, randomly grabbed 993 before dovecot did, and was holding it as long as the nfs fs was mounted locally. And because nfs is in-kernel it didn't show up in lsof et al. I umounted it, waited for TIME_WAIT to expire and then I could start dovecot. *** This has never happened before on dozens of reboots... I guess it's pretty much luck / race condition what port nfs gets, especially with systemd possibly trying to do the mount and/or dovecot in parallel. I have no idea when it tries to do the mounts, but I'm guessing before dovecot. Note, I'm using NFSv4 which (unlike older NFS) uses TCP stateful in a persistent connection. Pretty much everything you know about v2/v3 throw away when it comes to using v4. I poked around nfs docs and google and found this option: resvport / noresvport Specifies whether the NFS client should use a privileged source port when communicating with an NFS server for this mount point. If this option is not specified, or the resvport option is specified, the NFS client uses a privileged source port. If the noresvport option is specified, the NFS client uses a non-privileged source port. This option is supported in kernels 2.6.28 and later. Refer to the SECURITY CONSIDERATIONS section for important details. OK, down there is a section: Using non-privileged source ports Which basically says using privileged ports is for security so normal users can't make/fake their own daemons and pretend to be any user they want. OK, so I know that's a bit hokey from a sec standpoint, but it's better than nothing, I guess. Regardless, having nfs client pick a random high port might hurt me also because I use some of them for my own purposes/daemons and I need them open also. The docs say this: "The exact range of privileged source ports that can be chosen is set by a pair of sysctls to avoid choosing a well-known port, such as the port used by ssh." Which would be perfect, except I can't find any further reference to these magic sysctls. I tried searching my box's /proc and /sys fs's for nfs & ports, nfs & priv, nfs & mount, etc. Couldn't find anything relevant. It would be really nice if I could specify the local source port, or at least specify the list of no-no ports using this elusive, promised, "sysctl". Anyone have any ideas? What a strange bug to run into. Chance of 1 in 1024 and it had to hit me.

2 4

Re: [RndTbl] Ubuntu desktop vs server - UNISON
by jd 21 Oct '16

21 Oct '16

NOT gui, but worth a squint: UPenn.edu 's UNISON USES rsync (dependency; also ssh) IT WORKS no matter which way you've installed your Linux host server. AS WITH rsync (good example, Trevor), BEWARE "direction" .. "who's the boss" .. TEST: definitely set up HERE://~/exampleDir/ _ and There://~exampleDir/ with files like, say: OrangeFile,BlueFile,GreenFile in SOURCEdir (Here) and YellowFile, RedFile in DESTINATIONdir (There) and LEARN that a) you've either config'd "direction" properly, .. or .. b) you've clobbered DESTINATION, 'coz it's pushing wrongway. Seeing is believing. "ALLOWING" unique items to survive sync, at destination, which do NOT exist at source, is tricky. Somewhat eased configs, telling Unison how to behave, after initial setup/test session. Then we can (sudo) edit its config file; /root/.unison/default.prf ADVANTAGE rsync: Cordes' example here, is just as strong a starting point (and rather more concise). Please note that files in your system with extended file attributes will come across better with rsync. ADVANTAGE Unison: it is platform independent. So, you can dodge dissimilar syntax/vagaries where rsync talks between dissimilar platforms. e.g: WinX .. to Linux .. Or .. OSX .. to WinX .. Or .. Linux to .. etc Here is a Unison tutorial: https://www.howtoforge.com/tutorial/unison-file-sync-between-two-servers-on… That tutorial establishes an ssh encrypted connection. If one of your hosts is anaemic (slow CPU) stay with rsync, and without ssh/encryption. Re: TEXT EDITING of config files - "vi" is always present on a unix system - you want to learn it, but not in a hurry. PRACTICE is NECESSARY "nano" (I believe) is present in default Ubuntu/Mint install - less cryptic, less landmine kbrd Note: Tutorial installs nano. IN EITHER CASE - practice text editing from Command Line Interface "CLI" REMEMBER the folder/path/folder/path delimiter is 'slash' .. NOT backslash ASIDE: One would vote we never again refer to 'slash' as 'forward slash', to avoid needling from the greybeards THESE UPenn people who set up Unison, I believe, did it for simplicity (not just xPlatform). YMMV. DISADVANTAGE UNISON: THESE OXFORD pointyheads are NO LONGER ENAMORED with Unison, and give very good examples for obscurities of rsync; e.g: using wildcard star/asterisk/"*" will miss .dotFiles https://www2.physics.ox.ac.uk/it-services/how-to-use-rsync John D

1 0

Ubuntu desktop vs server.
by Justin Richard 20 Oct '16

20 Oct '16

Hi. I'm honing to sound like a total noob here but please have patience I'm trying like hell to catch up. Lol. I'm about to setup Rsync to transfer files to a backup machine. So I'm looking around the internet for people's best practices and opinions. I'm noticing that many of the admins are doing things in a combo of GUI in desktop and cmd line opposed to strictly cmd line in server. I'm from the Windows world and I think that having a point and click environment would help me move quicker. Can you guys tell me why I wouldn't want to use Ubuntu desktop? Or is there a better desktop to use for admin tasks? Thanks in advance. Justin.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Roundtable