- Roundtable - muug.ca

"Let's Encrypt" by the Internet Security Research Group (ISRG)
by Hartmut W Sager 06 Feb '17

06 Feb '17

Does anyone here know anything about "Let's Encrypt" by the Internet Security Research Group (ISRG)? https://letsencrypt.org/ They don't seem to be part of the usual gang - FSF, GNU, GPL, Apache, Linux, etc., etc., yet they express similar philosophies. Who are they? How credible are they and their effort? And how does their effort compare to other free security certificates? A colleague of mine tipped me off onto this, and he especially is wondering. Hartmut W Sager - Tel +1-204-339-8331

6 7

Re: [RndTbl] new ECC computer options (jd)
by jd 30 Jan '17

30 Jan '17

Not much on ECC from intel, is there? Brace yourself for Xeon pricing; e.g: octa-processor E7-8890-v3 (12-core) .. usd$ 7,174 ! For intel, a coupla notes: - Skylake CPUs (Lga1151) all gots VT-d (virtualisation optim) in 100series - Haswell is still around - may find bargains - Broadwell is mainstream - mature? - looks like it's back & forth (&back&forth) between (say..) Broadwell CPUs and Chips, until you find the pairing you want, THEN go looking for mbrds based on that chipset, AND which implement your features. - - - - With AMD .. waayyy easier. Survey FX/Am3+ mbrds, and then .. pick a Bulldozer. Dunno much about Opteronions. ECC is clearly documented as supported by CPUs, so just make sure mbrd implements that. ..and.. at these upper classes, is DualChannel assumed? Make sure mbrd offers it. Your workstation's data-width ('swath') to/from RAM "don't need no steenkin' zipper-merge" Many but not all CPUs come with HeatSink/Fan kit. TDP (Thermal Design Props) are all encouraging. AMD is 32nm tech, but still needs serious cooling. AMD supplies cooling kit on (only?) three of their mid-upper 'dozers. intel's modern CPUs are 22nm (and 14nm!squint!), but again, gotta be cooled right. Many models will push that pesky 3gHz 'barrier' I would like to bet you a beer you will find worthy candidate mbrds in uATX, and worthy boxen in that format, w/ adequate space, therein, to warm up your sandwiches. jd Oh.Yes: Parity was an extra 9th-bit chip, in DIP days. On write, the 9th-bit would be made to agree' with the byte's being odd or even. If a read cycle showed any dis-'agree'-ment, we'd be better off .. half the time. IBM had some purdy schmaart dudes. If they want to save us half our Time, we should be grateful. Parity survived into SIM (&SIP) "module'/'panel'days. Later in that SIM aeon, around the time of [Nibble+Nibble+Parity] SMT DIPs on each SIM, it became ..uhm.. expedient to install a simple logic trick-chip (instead of a real bitwise chip), to calc the SIM's parity on any read, and present that to the eager, expectant mbrd parity guts. On write, of course, it was still told what to remembory but .. what were we talking about? Oh, Yes. I think them was days of "fast page" and EDO and paying a bit more for 70ns MT, man, but not for 70ns EDO .. long story, man. We were incensed when SDRAM/sdimm came along and it don't got no parity, man. Mere parity was a laugh to VAXmen. man. Macs no likey (any kinda) parity sims, I learnt. Yet them fruity 8bit sims were always more shekels. Go figure. _ _ _ _ _ _ _ _ _ _ _ _ _ 2017-01-29 12:00 PM, roundtable-request(a)muug.ca wrote: > Send Roundtable mailing list submissions to > roundtable(a)muug.ca > > To subscribe or unsubscribe via the World Wide Web, visit > https://muug.ca/mailman/listinfo/roundtable > or, via email, send a message with subject or body 'help' to > roundtable-request(a)muug.ca > > You can reach the person managing the list at > roundtable-owner(a)muug.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Roundtable digest..." > > > Today's Topics: > > 1. Re: new ECC computer options (Trevor Cordes) > 2. Re: new ECC computer options (Trevor Cordes) > 3. Re: new ECC computer options (Kevin McGregor) > 4. Re: new ECC computer options (Hartmut W Sager) > > > _______________________________________________ > Roundtable mailing list > Roundtable(a)muug.ca > https://muug.ca/mailman/listinfo/roundtable

1 0

Re: [RndTbl] new ECC computer options
by Brock Wolfe 28 Jan '17

28 Jan '17

I spent a considerable amount of time recently looking at Workstation grade setups to support a major 3D CAD package as well as support CGI rendering and transcoding. The major difference is whether you want to support multiple video cards X3 or X4 to support multi-GPU processing (ie.OpenCL). If not, then a mid-range board (ASUS etc.) that supports ECC (or not) processor is good enough. The more important question is how much money you want to put into the processor. If your workload to be mostly single threaded (CAD work), then a mainstream quad processor (with the highest clock speed) is the best. The motherboard can overclock dynamically to get the best performance. If your going to use software or application that can work mult-treaded (ie. rendering/transcoding) , then moving up to a server grade processor that supports 8+ cores (and the highest affordable clock speed) is going to make a REAL difference. When rendering a single CGI frame takes an hour and you need 300 frames for 10 seconds of video, the seconds/minutes saved add up quickly. Another approach is to see if your software supports (built-in) clustering capability. For example Blender can be configured to create (Master/Slave/Client) nodes that can create a rending cluster on to other available machines. The heavy lifting is off-loaded, saving your workstation to continue on content creation. On 1/28/2017 12:00 PM, roundtable-request(a)muug.ca wrote: > Message: 1 > Date: Sat, 28 Jan 2017 00:46:42 -0600 > From: Trevor Cordes<trevor(a)tecnopolis.ca> > To: MUUG RndTbl<roundtable(a)muug.ca> > Subject: [RndTbl] new ECC computer options > Message-ID:<20170128064642.GA5713(a)pog.tecnopolis.ca> > Content-Type: text/plain; charset=us-ascii > > I'm looking for input from anyone in the club who may be knowledgable, > eyeballing, or has purchased a "workstation" system recently with ECC > memory. (Note, ECC is imperative!) I don't need dual-socket, crazy > speed, just something like a mid-range modern i7 with modern RAM, slots, > etc. (i3 speeds won't cut it.) > > By "workstation" I mean it has to have at least one PCIe x16 (full 16 > electrical) slot so it can have a good video card installed (and handle > upgrades in the future). So some "servers" will qualify, although most do > not have a true x16 slot (they'll say x16 but the small print will say x8 > or x4 electrical), especially on the low end. I also need tower form > factor, as rackmount will (unless 4U) be a pain to fit cards in, etc. > Lastly, I really want a DIY setup where I buy the board, cpu, etc > individually, though if a perfect premade system (i.e. Lenovo) exists that > fits the bill I might consider it (must use no propreitary form factor > parts, including mobo & PS). > > It's basically impossible since the discontinuation of the Intel > D975 chipsets (nearly 10 years ago) to do Intel with ECC without buying a > Xeon CPU. So I'm probably stuck buying a Xeon CPU and getting slower than > i7 for double the price. Ugh. > > I'd really love to hear from the AMD nuts out there if there are any good > AMD options, especially ones that are more enthusiast/desktop oriented > rather than same-price-as-Xeon competitors. If I'm going to spend big > bucks, I'll buy Intel: AMD needs to offer a compelling price advantage to > pull me over. > > I still believe AMD could carve a niche for itself by offering desktop > enthusiast chips / mobos with ECC at desktop, rather than server, prices. > Maybe add $50 each to a mobo and cpu as the price premium. Not the 100% > premium Intel wants just to get ECC. (I miss the old days when getting > ECC was cheap/easy.) If AMD already has such a thing (I'm hoping!), > great! > > I know I'm not the only one in the club interested in these answers. P.S. > being a computer reseller, I don't need prices or store suggestions, I can > just buy it all wholesale:-) It's the "this chipset plus that CPU" that > I'm really looking for. > > Thanks! >

3 2

MUUG http down last 3 hours
by Theodore Baschak 27 Jan '17

27 Jan '17

MUUG.ca http has been down for the last 3 hours or so (but the host is pingable) I notice the HTTP service has been down more and more lately as well, wondering if thats actually apache being down, or if its a lack of server threads able to handle client requests at that particular time? Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/

5 6

weird mts latency issue?
by Trevor Cordes 22 Jan '17

22 Jan '17

Just now on a box I manage I'm seeing weird ping times on a DSL (home) connection. It's wreaking havoc with things. Has anyone seen a pattern like this before? on the dsl box out to another IP: : icmp_seq=1 ttl=56 time=3073 ms : icmp_seq=2 ttl=56 time=2112 ms : icmp_seq=3 ttl=56 time=1154 ms : icmp_seq=4 ttl=56 time=192 ms : icmp_seq=5 ttl=56 time=3578 ms : icmp_seq=6 ttl=56 time=2616 ms : icmp_seq=7 ttl=56 time=1658 ms : icmp_seq=8 ttl=56 time=694 ms : icmp_seq=9 ttl=56 time=4125 ms : icmp_seq=10 ttl=56 time=3170 ms : icmp_seq=11 ttl=56 time=2202 ms : icmp_seq=12 ttl=56 time=1240 ms : icmp_seq=13 ttl=56 time=289 ms It's bursty, the above is 3 bursts, where I start the ping, wait 3s and it spits out 4 replies together, then again... sometimes the time is up to 10kms. If I ping from my box to that box I get even more weirdness: icmp_seq=1 ttl=57 time=60.8 ms icmp_seq=2 ttl=57 time=60.0 ms icmp_seq=3 ttl=57 time=61.4 ms icmp_seq=4 ttl=57 time=70.4 ms icmp_seq=1 ttl=57 time=3612 ms (DUP!) icmp_seq=2 ttl=57 time=2649 ms (DUP!) icmp_seq=3 ttl=57 time=1692 ms (DUP!) icmp_seq=4 ttl=57 time=726 ms (DUP!) icmp_seq=5 ttl=57 time=63.4 ms icmp_seq=6 ttl=57 time=59.3 ms icmp_seq=7 ttl=57 time=62.4 ms icmp_seq=8 ttl=57 time=68.3 ms icmp_seq=9 ttl=57 time=61.4 ms icmp_seq=5 ttl=57 time=4366 ms (DUP!) icmp_seq=6 ttl=57 time=3403 ms (DUP!) icmp_seq=7 ttl=57 time=2443 ms (DUP!) icmp_seq=8 ttl=57 time=1488 ms (DUP!) icmp_seq=9 ttl=57 time=518 ms (DUP!) I don't think I've ever seen DSL behave that strangely...

3 3

a weird DNS issue this morning
by Theodore Baschak 13 Jan '17

13 Jan '17

Inspired by some of Trevor's recent git bisecting to find issues I lay out the details of an issue I discovered recently. I had a super super weird DNS issue this morning I got notice that there was some new powerdns releases, both recursive and authoritative. These were also noted on debian security announced, so I installed all of them on my various servers without thinking too much. Almost immediately after upgrading the ones in Winnipeg I started getting bombarded with notifications, mostly about one particular zone check failing -- ciscodude.net. I started investigating my various local resolvers trying to nail down the problem, and I noticed a lot of records missing all over the place, and missing inconsistently too. An A record for something would be there but not its AAAA. NS records would be missing or incomplete. I used the handy `rec_control trace-regex <domain>` on the recursors. This started to show very weird things, like my closest nameserver returning different zone's NS records when queried for NS records. How could this even be possible I thought? I then started `dig`ing the same queries against the suspect nameserver, and YES indeed it was returning NS records from a whole different zone!!! So, of course when powerdns recursor checked with the 2nd, 3rd and 4th nameservers, they disagreed with what had been returned by the first one. This caused DNS for Ciscodude.net to fail, and some other scattered fallout for other domains that used ciscodude.net nameserver records (most of my domains) while the primary served random records. Investigating the issue on #powerdns IRC, it was quickly identified that the configuration of 2 backends on this one server (mysql + bind files) was likely causing the issue, and then I was quickly pointed to a commit, and then a second commit [1] for 4.x which likely introduced the bug. I was also pointed to the package archives where I was able to install the previous version for now on that one server to get things back up and running. Github was simultaneously having an HTTP issue of some sort and so I haven't been able to compile the sources minus that particular commit yet to confirm that the commit is indeed the problem. 1: https://github.com/PowerDNS/pdns/commit/b854d9fec6f7e5636ab4742d716c7d848e0… Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/

1 0

Fwd: Free video: Cory Doctorow on how you got here
by Gilbert E. Detillieux 12 Jan '17

12 Jan '17

I thought this might be of interest to many of you... -------- Forwarded Message -------- Subject: Free video: Cory Doctorow on how you got here Date: Wed, 11 Jan 2017 10:55:58 -0800 From: Rachel Roumeliotis, O'Reilly Media <oreilly(a)post.oreilly.com> O'Reilly Media ... You may be passionate about open source software or FLOSS (Free/Libre and Open Source Software) or you may simply be focused on getting your work done. Either way, according to Cory Doctorow, novelist, activist, journalist, and blogger, when you use open source software the work you do today is giving shape to the open source software of the future. That's quite a responsibility—and a privilege. Cory explains what he means, and more important, what this means for the world at large. We invite you to listen to his thought-provoking keynote from the O'Reilly Open Source Convention last year, /How you got here/. You'll learn about the practical side of using open source as well as enduring benefits that you may not have imagined. And Cory's a brilliant speaker. Cheers! Rachel Roumeliotis Strategic Content Director, Programming P.S. In addition to fueling today's software and business systems, open source software is rich with exciting potential. Learn useful skills, languages, and best practices at the O'Reilly Open Source Convention <http://post.oreilly.com/rd/9z1zv70m8nrkcpqlkbltd24lk4aunijtc3cddjr34q0>, aka OSCON, happening May 8–11, 2017 in Austin, TX. Cory Doctorow <http://post.oreilly.com/rd/9z1zg6arcdm2cqgdpq3jd9k74dl9keblmfuk9pitpro> ... Did someone forward this to you? *Sign up here* <http://post.oreilly.com/rd/9z1zjmuv8ggaso35vqgnfqduqhjcmt8m878cbb7p408>. To ensure delivery to your inbox (not bulk or junk folders), please add *oreilly(a)post.oreilly.com* to your address book. O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 (707) 827-7000 -- Manitoba UNIX User Group E-mail: <gedetil(a)muug.ca> c/o Gilbert E. Detillieux Web: http://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609

2 1

Update: MUUG Meeting, Jan 10, 7:30pm -- Webmin, Room 1L11, Lockhart Hall
by Gilbert E. Detillieux 10 Jan '17

10 Jan '17

*** Please note the updated meeting location below *** The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, January 10. The meeting topic for this month is as follows: Webmin "Webmin is a web-based interface for system administration for Unix. Using any modern web browser, you can setup user accounts, Apache, DNS, file sharing and much more. Webmin removes the need to manually edit Unix configuration files like /etc/passwd, and lets you manage a system from the console or remotely." Adam Thompson will demonstrate the installation and use of Webmin as an alternative to editing config files and using the command line. RTFM: fio This month's RTFM will be presented by Wyatt Zacharias, who will talk about the fio(1) command. The "flexible I/O tester," fio is "a tool that will spawn a number of threads or processes doing a particular type of I/O action," usually "to write a job file matching the I/O load one wants to simulate." 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 1L11* Lockhart 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: https://muug.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: https://muug.ca/meetings/MUUGmeeting.pdf -- Manitoba UNIX User Group E-mail: <gedetil(a)muug.ca> c/o Gilbert E. Detillieux Web: https://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609

1 1

Winkler & Area Llinux User Group
by john＠reinland.ca 10 Jan '17

10 Jan '17

Sorry about the conflict with tonight's meeting. There is an introductory Linux User Group Meeting this evening at the Winkler Library. Start time is 7:15pm. Anyone with interest is welcome, you do not need to be an expert. Please forward to anyone who you think would be interested.

1 0

latest kernel needs setcap even as root??
by Trevor Cordes 05 Jan '17

05 Jan '17

Just upgraded a few boxes to kernel 4.8.8-100.fc23. It seems this latest kernel (or maybe 1 or 2 versions going back 1-2 months) changed something. I have a script that generates pings (using SOCK_RAW to make its own packets) that I run as root. Worked fine until now. In the new kernel I get "Operation not permitted" on the socket() call. Digging around the net, I found that I need to do: setcap cap_net_raw+p /foo/myscript Then when I run it, it works fine. Ok, great, but *** I'm running the script as root ***!!! Huh? Since when did root need to specify capabilities to run stuff as root? What is this, Windows? Is there some major paradigm change in the latest kernels where this is a "feature" and not a bug? Just wanted to do a sanity check before I file a bz. Oh ya, selinux is disabled, so that's not the problem. Lots of chatter on the net about this problem but everyone talking about it is talking about the non-root use case. It would appear my issue is something brand new. Aside: As for the script, I'm doing really wacky stuff on purpose, and I really needed direct control over the packet, so I can't just abandon SOCK_RAW.

4 12