- Roundtable - muug.ca

Distributed/replicated home directories?
by Adam Thompson 21 Apr '15

21 Apr '15

I'm looking for the sweet spot between: - NFS-mounted home directories, which allow easy central management and are portable across every workstation, but are (typically, and in my case) IOPS-limited, and - local home directories, which are tied to the workstation but offer great performance At this point I'm seriously considering things like GlusterFS, Lustre, CephFS, etc., because the NFS performance sucks so badly for doing things like a) running Chrome, and b) running VirtualBox. Looking for ideas... [image: Avant logo] *Adam Thompson* Senior Systems Administrator *voice:* 204.789.9596 x24 | *email:* athompson(a)avant.ca | *web:* avant.ca

3 2

Re: [RndTbl] [Board] Units(1) for RTFM?
by Gilbert E. Detillieux 21 Apr '15

21 Apr '15

Here's a fun one to try... units -v lightyear "light year" Confused? Try "units -v" on each of the terms individually, and the results might be enlightening, albeit a bit time-consuming. (Sorry, I couldn't resist.) Astronomy geeks might want to browse the units.dat file (RTFM), to find out just how many ways you can define a year! :P And speaking of RTFM, +1 for units as a future RTFM topic. Gilbert On 21/04/2015 10:38 AM, Michael Doob wrote: > So you can also compute how many feet light travels in a nanosecond > (Try it; you can remember the answer with less than 2% error). RIP Grace Hopper! (Look it up if you're too young to remember.) > Cheers, > Michael > > > On 15-04-21 09:22 AM, Sean Walberg wrote: >> My favourite has always been: >> >> You have: 1 nanoacres >> You want: mm2 >> * 4.0468564 >> / 0.24710538 >> >> On Tue, Apr 21, 2015 at 8:41 AM, Bradford C. Vokey <brad(a)fsi.ca >> <mailto:brad@fsi.ca>> wrote: >> >> And once again, I learn something new from the master Adam. >> >> I'z immediately "yum install units" >> >> I think units(1) might make a good RTFM? Especially going over >> some of it's esoteric units (i.e. millilightseconds? really?). >> >> Or have we done units and I just can't remember? >> >> === >> Bradford C. Vokey >> >> Treasurer >> Manitoba Unix User Group >> === >> >> On 2015-04-21 6:53 AM, roundtable-request(a)muug.mb.ca >> <mailto:roundtable-request@muug.mb.ca> wrote: >>> Feeling slightly giddy, I typed into my shell: >>> >>> $ units >>> 1311 units, 63 prefixes >>> >>> You have: 3 millilightseconds >>> You want: miles >>> * 558.84719 >>> / 0.0017893979 >>> >>> "500 miles, or a little bit more." -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

Units(1) for RTFM?
by Bradford C. Vokey 21 Apr '15

21 Apr '15

And once again, I learn something new from the master Adam. I'z immediately "yum install units" I think units(1) might make a good RTFM? Especially going over some of it's esoteric units (i.e. millilightseconds? really?). Or have we done units and I just can't remember? === Bradford C. Vokey Treasurer Manitoba Unix User Group === On 2015-04-21 6:53 AM, roundtable-request(a)muug.mb.ca wrote: > Feeling slightly giddy, I typed into my shell: > > $ units > 1311 units, 63 prefixes > > You have: 3 millilightseconds > You want: miles > * 558.84719 > / 0.0017893979 > > "500 miles, or a little bit more."

3 2

Fwd: [Yucks] My e-mail only goes 500 miles...
by Adam Thompson 20 Apr '15

20 Apr '15

I just had to share this... At least it's UNIX-related :-) -Adam ---------- Forwarded message ---------- From: "'Elkhorn' via Yucks" <yucks(a)googlegroups.com> Date: Apr 20, 2015 14:48 Subject: [Yucks] My e-mail only goes 500 miles... To: Cc: From: Trey Harris <trey(a)sage.org> Here's a problem that *sounded* impossible... I almost regret posting the story to a wide audience, because it makes a great tale over drinks at a conference. :-) The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining. I was working in a job running the campus email system some years ago when I got a call from the chairman of the statistics department. "We're having a problem sending email out of the department." "What's the problem?" I asked. "We can't send mail more than 500 miles," the chairman explained. I choked on my latte. "Come again?" "We can't send mail farther than 500 miles from here," he repeated. "A little bit more, actually. Call it 520 miles. But no farther." "Um... Email really doesn't work that way, generally," I said, trying to keep panic out of my voice. One doesn't display panic when speaking to a department chairman, even of a relatively impoverished department like statistics. "What makes you think you can't send mail more than 500 miles?" "It's not what I *think*," the chairman replied testily. "You see, when we first noticed this happening, a few days ago--" "You waited a few DAYS?" I interrupted, a tremor tinging my voice. "And you couldn't send email this whole time?" "We could send email. Just not more than--" "--500 miles, yes," I finished for him, "I got that. But why didn't you call earlier?" "Well, we hadn't collected enough data to be sure of what was going on until just now." Right. This is the chairman of *statistics*. "Anyway, I asked one of the geostatisticians to look into it--" "Geostatisticians..." "--yes, and she's produced a map showing the radius within which we can send email to be slightly more than 500 miles. There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius." "I see," I said, and put my head in my hands. "When did this start? A few days ago, you said, but did anything change in your systems at that time?" "Well, the consultant came in and patched our server and rebooted it. But I called him, and he said he didn't touch the mail system." "Okay, let me take a look, and I'll call you back," I said, scarcely believing that I was playing along. It wasn't April Fool's Day. I tried to remember if someone owed me a practical joke. I logged into their department's server, and sent a few test mails. This was in the Research Triangle of North Carolina, and a test mail to my own account was delivered without a hitch. Ditto for one sent to Richmond, and Atlanta, and Washington. Another to Princeton (400 miles) worked. But then I tried to send an email to Memphis (600 miles). It failed. Boston, failed. Detroit, failed. I got out my address book and started trying to narrow this down. New York (420 miles) worked, but Providence (580 miles) failed. I was beginning to wonder if I had lost my sanity. I tried emailing a friend who lived in North Carolina, but whose ISP was in Seattle. Thankfully, it failed. If the problem had had to do with the geography of the human recipient and not his mail server, I think I would have broken down in tears. Having established that -- unbelievably -- the problem as reported was true, and repeatable, I took a look at the sendmail.cf file. It looked fairly normal. In fact, it looked familiar. I diffed it against the sendmail.cf in my home directory. It hadn't been altered -- it was a sendmail.cf I had written. And I was fairly certain I hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option. At a loss, I telnetted into the SMTP port. The server happily responded with a SunOS sendmail banner. Wait a minute... a SunOS sendmail banner? At the time, Sun was still shipping Sendmail 5 with its operating system, even though Sendmail 8 was fairly mature. Being a good system administrator, I had standardized on Sendmail 8. And also being a good system administrator, I had written a sendmail.cf that used the nice long self-documenting option and variable names available in Sendmail 8 rather than the cryptic punctuation-mark codes that had been used in Sendmail 5. The pieces fell into place, all at once, and I again choked on the dregs of my now-cold latte. When the consultant had "patched the server," he had apparently upgraded the version of SunOS, and in so doing *downgraded* Sendmail. The upgrade helpfully left the sendmail.cf alone, even though it was now the wrong version. It so happens that Sendmail 5 -- at least, the version that Sun shipped, which had some tweaks -- could deal with the Sendmail 8 sendmail.cf, as most of the rules had at that point remained unaltered. But the new long configuration options -- those it saw as junk, and skipped. And the sendmail binary had no defaults compiled in for most of these, so, finding no suitable settings in the sendmail.cf file, they were set to zero. One of the settings that was set to zero was the timeout to connect to the remote SMTP server. Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds. An odd feature of our campus network at the time was that it was 100% switched. An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side. So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays. Feeling slightly giddy, I typed into my shell: $ units 1311 units, 63 prefixes You have: 3 millilightseconds You want: miles * 558.84719 / 0.0017893979 "500 miles, or a little bit more." Trey Harris -- Cheers, Elkhorn => As of sending this e-mail, I have not received a National Security Letter <= Please - do not send me any material that you do not wish to share with the NSA, GCHQ, or other members of the "Five Eyes". Or various corporate entities. This communication may be unlawfully collected and stored by the National Security Agency (NSA), or other organizations, in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" — *Upton Sinclair* "Evolution is just a theory. Like, umm, gravity." -- You received this message because you are subscribed to the Google Groups "Yucks" group. To unsubscribe from this group and stop receiving emails from it, send an email to yucks+unsubscribe(a)googlegroups.com. To post to this group, send email to yucks(a)googlegroups.com. Visit this group at http://groups.google.com/group/yucks. For more options, visit https://groups.google.com/d/optout.

1 0

Fwd: Friends and Family Event - Get Bulk Pricing without the Bulk, Use Code: FANDF
by Adam Thompson 16 Apr '15

16 Apr '15

1 0

ionice
by Trevor Cordes 16 Apr '15

16 Apr '15

It dawned on me that ionice might show more perceptible results with *random* I/O, not just sequential writes from dev/zero. I bet some mix of ioniced random I/O (try R and W separately) whilst W from /dev/zero with no ioniceness will show some results... If not, someone needs to make a bugzilla!

1 0

Converting CUPS PPD files for Windows clients
by Gilbert E. Detillieux 15 Apr '15

15 Apr '15

The question was asked at last night's round-table session: What was the command (that is part of CUPS) to convert PPD files for use by Windows clients? I believe it's part of the work that the "cupsaddsmb" command does, in addition to providing driver files for an appropriately configured Samba server. Check the man page for details. Note that this may be essentially obsolete these days, as I doubt it properly supports drivers for modern Windows versions, whether they're 32- or 64-bit. However, if you still need it just for the purpose of massaging PPD files (which you would then install, manually or by other means, on the Windows clients), it may still be up to the task. -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

(no subject)
by Steve Moffat 15 Apr '15

15 Apr '15

This presentation, next Monday afternoon, might be of interest to people who want to know more about IBM's Bluemix cloud based software development. http://bluemixd2dwpg.eventzilla.net/web/event?eventid=2139069038 Steve Moffat IBM Global Services sjm(a)ca.ibm.com (204)792-3245

1 0

MUUG Meeting, Apr 14, 7:30pm -- Arch Linux
by Gilbert E. Detillieux 07 Apr '15

07 Apr '15

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, April 14. The meeting topic for this month is as follows: Arch Linux Paul Sierks will be presenting an overview of the Arch Linux operating system. From installing the base system and desktop environment, to updating and managing it. We'll cover some of the advantages in this distribution. Arch focuses on simplicity, minimalism, and stability. Users can create their own ideal environment, installing only what is needed or wanted. A rolling release model, Arch strives to be bleeding edge, providing the latest stable software. Paul will be performing a live demonstration of the Arch install process. This month's RTFM segment will be ionice(1), by Adam Thompson. ionice gets or sets the scheduling class and priority for a program. 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, 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 -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

Reminder to claim your Canadian DRAM Class Action before 2015-06-23!
by Bradford C. Vokey 29 Mar '15

29 Mar '15

There is a total of $79 million to be divided up amongst Canadians who purchased electronic devices containing DRAM between 1999-04-01 and 2002-06-30. All end users (including businesses) *and* their resellers (TREVOR!) can BOTH claim! Claims must be filed before June 23rd, 2015! Those that *don't* claim will receive $0. There is a simplified claim form (no receipts required) for households and businesses that bought at least 1 electronic device (containing DRAM) between 1999-04-01 and 2002-06-30. They guarantee a minimum $20 claim (not sure how the math works on that - must be an actuarial thing). However, if you have your receipts (or were a reseller during those times) you can submit a "standard" claim and potentially receive much more than the $20 allocated to each household. Full details and the claim forms can be found here: https://www.themoneyismine.ca/ This is like one of those share to win social media posts. The more households that claim - the smaller your payout per household will be. However, if anyone deserves the payout, it is MUUG members, so I feel it is in my duty as MUUG treasurer to remind everyone in MUUG to file a claim. -- Bradford C. Vokey Treasurer Manitoba Unix User Group (MUUG) PO Box 130 Winnipeg MB R2H 0H1 muug.mb.ca

2 1