- Roundtable - muug.ca

Using Shaw 150 mbps down / 15 mbps up / 1 TB data plan on 100 mpbs ports and hardware
by Hartmut W Sager 18 Aug '16

18 Aug '16

I'm sure everyone here is well aware of Shaw's heavily promoted new Internet plan that gives 150 mbps down / 15 mbps up / 1 TB data per month. My big question is, are there any hiccups/hangups when this plan is used on 100 mpbs ports and hardware? A couple of my computers have 100 mbps (not gigabit) ethernet ports, and so does a router or two here. Obviously my download speed will be limited to slightly under 100 mbps, but my big fear is that the requisite stop/start handshaking protocol (if I encounter a server that wants to send/stream at over 100 mbps) could hiccup and hangup things. I don't even know at which layer/level such a protocol would operate. I've definitely had such hangups with stop/start handshaking protocols in the distant past, like with RS-232 serial. Hartmut W Sager - Tel +1-204-339-8331

4 8

DNS search/resolv.conf help!
by Kevin McGregor 17 Aug '16

17 Aug '16

I'm running Ubuntu 14.04 on a particular server. In the /etc/resolv.conf there are two search lines: search domA.example.org domB.example.org # [NOTE I made these up, but the form is the same] search domA.example.org I want the search setting to be just: search domA.example.org I've deleted the top/offending line, but every time I restart dnsmasq or run resolvconf -u (for example), the offending line comes back. Where is it getting the domB.example.org from? I've looked in all the usual places (I think), and tried "grep -R domB *" in /etc, but nothing turns up! I'm at a loss. Any pointers on where I should look next? Thanks, Kevin

5 5

32 -> 64 offsite? just maybe?
by Trevor Cordes 13 Aug '16

13 Aug '16

In my unending quest to find an easy way to upgrade 32-bit Linux (Fedora) systems to 64-bit systems on headless boxes at remote sites (i.e. don't need to go onsite), I think I may have thought of a way. Can I get uber-genius approval? (Distro doesn't matter, same thought process should work on any distro/packagemgr.) 0. starting point is a working 32-bit userland and kernel install with ssh access only 1. install (force) 64b kernel on running 32b system, leave userland 32b, reboot. Though not supported by Fedora, this should work in theory, says the kernel guys. 2. trick dnf (nee yum; think apt-get) into thinking the system is 64 somehow (many ways to do this) 3. run dnf upgrade distsync (i.e. I'll go from F23 to F24 at the same time), all userland goes 64, manually delete any leftover 32's that aren't normally on a 64 system. 4. reboot, now kernel and ul are both 64 ... might work?? A completely offsite way to pull off this extremely tricky but urgently needed process? Potential gotchas? Maybe in step 3 the order of installs of libs vs bins goes wonky causing failure of forking / execing of new bg (think pre/postinstall) ps's? (Yes, I'll remember to ascii dump and stop any bitness-sensitive-data progs like mysql first, then restore from ascii.)

1 0

monster size 6502
by Trevor Cordes 31 Jul '16

31 Jul '16

This will bring a smile to some of us oldsters. http://monster6502.com/ (The picture halfway down the home page is cool)

1 0

help me test tcsh?
by Trevor Cordes 30 Jul '16

30 Jul '16

(If you want to help me, this will only take you 1 minute!) I've hit a bug in the new Fedora 23 version of tcsh. Can someone help me confirm this bug on another box? It *only* happens on 64-bit x86_64 so I need someone running 64-bit. Also, it only seems to happen if gcc5 is used to compile, so your distro has to be pretty new (Fedora 23 or newer for example). Preferably kernel 4+ too. You can tell if you're 64-bit using: uname -i If you see 64 in there, you're 64. Try: gcc --version If it's 5+ that's good. Lastly, see what kernel ver: uname -r If it's 4+ then we're in business... All I need from you if match the above is start tcsh: tcsh If it says command not found then you need to install it with your package manager, like "dnf install tcsh" or "apt-get ...whatever". Then start tcsh by typing tcsh. Here's the actual test, paste this in tcsh: complete find 'n/-user/u/' 'n/-exec/c/' then type: find . -user [TAB] (hit TAB key where I put tab above, don't type the brackets) Does it list the users on your system or does it list the files/dirs in the current directory? My bug is that it shows the files, not the users. Could also try: complete tcsh n/-c/c/ then type: tcsh -c [TAB] Should give the same results (showing files instead of commands). One last thing, please let me know your tcsh version: tcsh --version I've only gotten this bug to occur on 6.19. Aside: this is a first, the bug is ONLY on my x86_64 boxes and not my i686 PAE ones! Ha! Thanks all!

2 2

Looking for Web Developer
by Gerald Brandt 30 Jul '16

30 Jul '16

Hi, I'm looking for a web developer (preferably PHP) to convert an existing Access 97 application to the web. Any recommendations? Gerald

3 2

Looking for a PHP dev
by Gerald Brandt 18 Jul '16

18 Jul '16

Hi, We have an old app written in Access we'd like moved to a web interface with an SQL backend. The app is fairly straight forward, as is the DB. We're looking for a PHP dev to port from Access to the web for us. Any good recommendations? I'm a bit short on details, but can make an appointment to see the existing app and the DB structure. Gerald

1 0

Trevor's wacky slow 10MB/s disk I/O update
by Trevor Cordes 23 Jun '16

23 Jun '16

Thanks a ton for all the great suggestions at the meeting the other night about my slow disk I/O. (For those not at the meeting, this is the slow I/O issue I've been battling with for months and have asked about here on the mailing list numerous times.) I think Adam(?) suggested testing dd with an option to avoid the cache completely, after others thought it sounded like a cache issue. The option for that (after a quick RTFM) is oflag=direct. Here's the results of that on the system after being up a day (without my hourly test running): spinning rust: 5:15am ~#dd if=/dev/zero of=/dev/sda2 bs=1M count=200 conv=fdatasync 209715200 bytes (210 MB) copied, 9.07724 s, 23.1 MB/s 5:15am ~#dd if=/dev/zero of=/dev/sda2 bs=1M count=200 conv=fdatasync oflag=direct 209715200 bytes (210 MB) copied, 2.04618 s, 102 MB/s ssd: 5:18am ~#dd if=/dev/zero of=/dev/sdb2 bs=1M count=200 conv=fdatasync 209715200 bytes (210 MB) copied, 3.38177 s, 62.0 MB/s 5:16am ~#dd if=/dev/zero of=/dev/sdb2 bs=1M count=200 conv=fdatasync oflag=direct 209715200 bytes (210 MB) copied, 0.508799 s, 412 MB/s Whoa! Indeed we have a cache issue. Disks are near full speed when writing direct to disk, but slow when going through the cache. FYI, here's what top looks like after I ran the tests (for mem info): top - 05:21:49 up 1 day, 4:43, 1 user, load average: 0.00, 0.03, 0.07 Tasks: 212 total, 1 running, 211 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16522952 total, 4668792 free, 706636 used, 11147524 buff/cache KiB Swap: 0 total, 0 free, 0 used. 15709432 avail Mem So it looks like buff/cache is getting quite large after all (11GB). So we'll try the next suggestion: 5:23am ~#sync ; echo 1 >> /proc/sys/vm/drop_caches top KiB Mem : 16522952 total, 15508640 free, 706136 used, 308176 buff/cache 5:24am ~#dd if=/dev/zero of=/dev/sdb2 bs=1M count=200 conv=fdatasync 209715200 bytes (210 MB) copied, 4.39049 s, 47.8 MB/s So that doesn't help at all (that's the ssd and should be 400-500MB/s). Very strange indeed! At least I have some better search terms to google with in the next few days... maybe I'll get lucky.

1 1

muug.ca/mirror debian jessie issue
by Theodore Baschak 13 Jun '16

13 Jun '16

Good Morning: I got the following cron-apt error in my email overnight: CRON-APT RUN [/etc/cron-apt/config]: Mon Jun 13 04:00:01 CDT 2016 CRON-APT SLEEP: 3104, Mon Jun 13 04:51:45 CDT 2016 CRON-APT ACTION: 0-update CRON-APT LINE: /usr/bin/apt-get -o quiet=1 update -o quiet=2 E: Release file for http://muug.ca/mirror/debian/dists/jessie-updates/InRelease is expired (invalid since 12h 34min 34s). Updates for this repository will not be applied. I ran apt-get update again and its coming up with the same file being expired since 15 hours ago. I'll try again later this morning too, perhaps its just in the middle of pulling a new mirrored file down or something. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ https://theodorebaschak.com/ - http://mbix.ca/

1 0

very strange DNS errors
by Trevor Cordes 12 Jun '16

12 Jun '16

Some recurring email bounces have tipped me off to a really strange DNS issue on the boxes I admin. I really need help on this as it's impacting a real customer in a real way: delayed emails. Often, and somewhat randomly, DNS will fail to resolve a domain. Sometimes it will fail to resolve it for >4 hours and trigger a diagnostic bounce from my sendmail. When I run tests at the command line (dig) on the domains in question (the ones I've seen in email bounces) I will often very quickly get a resolve failure, but usually 5s later another dig to the same domain will resolve 100% ok! Every box I am testing on has a similar config with BIND named 9.10 (9.8 on one box) running as the local recursive resolver. /etc/resolv.conf on all is 127.0.0.1. So that means every lookup that isn't cached is going to the root NS's. When it fails to resolve, named.log logs an entry like: 20-Apr-2016 00:37:28.276 query-errors: debug 1: client 127.0.0.1#33971 (artscouncil.mb.ca): query failed (SERVFAIL) for artscouncil.mb.ca/IN/A at query.c:7769 20-Apr-2016 00:37:28.276 query-errors: debug 2: fetch completed at resolver.c:3658 for artscouncil.mb.ca/A in 0.215778: SERVFAIL/success [domain:artscouncil.mb.ca,referral:1,restart:3,qrysent:2,timeout:0,lame:0,neterr:2,badresp:0,adberr:0,findfail:0,valfail:0] For manual tests it only logs one, for the real-life sendmail problem ones, I'll see dozen/hundreds of the same thing trying hour after hour (usually around the sendmail queue retry times). One of my boxes is *extremely* well connected in the US, and while it seems to have errors slightly less often, it still has them. All the rest are on various levels of Shaw or MTS, res or business. This seems to have just started popping up maybe 6 months ago. It feels like it's getting worse. I've setup an easy test, on the actual domains with the most problems: rndc flush dig +short sportmanitoba.ca dig +short gymcan.org dig +short brandoneagles.ca dig +short interactivegym.org dig +short artscouncil.mb.ca rndc flush dig +trace sportmanitoba.ca dig +trace gymcan.org dig +trace brandoneagles.ca dig +trace interactivegym.org dig +trace artscouncil.mb.ca Maybe some others can run those tests on their boxes (but only if you're running BIND as caching resolver, which many/most people won't be). Here's where it gets interesting the +short tests I can get to fail at least 1 of the domains (at random) about 1/8 of the time! On at least 5 different boxes out there! But +trace has never failed once on any box or any domain. It's like +trace does something different, maybe slowing the process down or something, that allows it to always succeed. (Failure for the +short is a missing line in output, +trace you have to look at the domain/ip returned near the bottom.) So, is it just these particular domains?? Something wrong on their (DNS) side? Or is it more domains, not just these? Is there any way to diagnose what exactly is failing? I find it bizarre that *all* of these domains regularly go down for 4+ hours causing an email bounce!?! Or is there something horribly wrong on my BIND caching DNS servers? Perhaps they are slow, and I'm my BINDs are just not waiting long enough. Is there a way to tell BIND to be more patient waiting for DNS packets to come in? Maybe it's something regarding IPv6? (I'm doing this all in IPv4 and have no current interest in 6. And I'm only looking for A records.) I have packet traces of the above sample commands when the lookups fail, but I can't really figure out what it's doing, other than one boatload of traffic for a tiny dns query. I can provide a trace privately on demand if you think you can help. Even more odd, I never seem to have a problem with interactive things like web browsing. If this was a problem with all domains, I should see this in firefox all the time, but I don't. Maybe Firefox doesn't even obey resolv.conf and does its own thing, or retries heavily itself? I also checked to ensure my iptables aren't dropping packets related to this. Lastly, answers of "just use 8.8.8.8" aren't helpful because I also need to handle dynamic local, and in some cases, external DNS (often with multiple views), all in the same BIND/box (and I like uniformity across boxes for ease of admin). Sure, I could try another resolver, but I see no reason BIND can't be made to work, as it has for me for 20 years. And if this is a BIND bug, I want to submit it to help solve it. Thanks guys!

5 14