Roundtable

roundtable@muug.ca

2555 discussions

MUUG Meeting, Nov 13, 7:30pm -- OpenRISC System on a Chip
by gedetil＠cs.umanitoba.ca 06 Nov '12

06 Nov '12

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, November 13. The meeting topic for this month is as follows: OpenRISC System on a Chip Robert Keizer will talk about OpenRISC and its applications: * Why run an FPGA device * What you can do with one * Running a linux kernel on an FPGA * In-lining custom instructions. Instead of the RTFM segment, we'll have a Gadget show-and-tell. Bring along any gadgets or hardware you have so everyone else can see what's out there. 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. ********************************************************************** Our November 13 meeting location: The IBM offices, at 400 Ellice Ave. (between Edmonton and Kennedy). When you arrive, you will have to sign in at the reception desk, and then wait for someone to take you (in groups) to the meeting room. Please try to arrive by about 7:15pm, so the meeting can start promptly at 7:30pm. Don't be late, or you may not get in. (But don't come too early either, since security may not be there to let you in before 7:15 or so.) Non-members may be required to show photo ID at the security desk. Limited parking is available for free on the street, either on Ellice Ave. or on some of the intersecting streets. Indoor parking is also available nearby, at Portage Place, for $5.00 for the evening. Bicycle parking is available in a bike rack under video surveillance located behind the building on Webb Place. ********************************************************************** 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

Setting up a virtual system with LXC
by Sean Walberg 05 Nov '12

05 Nov '12

Hey, I've been trying to give LXC a go. I want to be able to spin up a container that I can ssh into and run a few programs inside it. But it's just not working. I've been trying it on Fedora 17 and the documentation I can find is too old to be useful. I've been able to make some translations but I still can't get a container started. I have a rootfs created and tried a few combinations of fstab files, but when I start the container I get nothing on the console, and sometimes if I leave it it'll crash the box. My guess is that I haven't re-created the init process or startup scripts properly, but I can't find any logs to tell me one way or another. For step 1 I don't care much about the distribution so I'm trying Ubuntu next, but in the meantime, I thought I'd ask if anyone has any experience to share regarding LXC? Thanks, Sean -- Sean Walberg <sean(a)ertw.com> http://ertw.com/

1 0

How many other people are effected by the Amazon EBS Outage?
by Robert Keizer 22 Oct '12

22 Oct '12

Greetings, http://tech.slashdot.org/story/12/10/22/1941237/amazon-ebs-failure-brings-d… I've been effected - although we have geographical failover. Others? " AWS's massive computing footprint has been estimated to generate 1% of all Internet traffic, withnearly one-third of Internet users <http://www.computerworld.com/s/article/9226349/Amazon_cloud_accessed_daily_…>accessing sites that use AWS daily, according to a report from DeepField Networks, which provides cloud mapping capabilities."

3 2

Call for Papers: The 8th CISSE International Conference
by CISSE Conference 2012 20 Oct '12

20 Oct '12

1 0

Follow-up question re: MTA's
by Dan Keizer 19 Oct '12

19 Oct '12

A follow-up question of sorts -- I've been using gmail as my email provider of choice for years -- so I've become accustomed to their service. I have a "spam" folder on my mailboxes and they filter and route the emails into that folder if they detect it *may* be spam. I regularly go through that folder and pull out the odd false-positives that occur (yes, they occur all the time). For those of you who have local mail via one of the big providers (shaw/mts/etc) - if you use their email addresses (@shaw or @mts, /etc) do they provide some kind of spam filtering service? If so, what do they do with the spam that they detect? Do they file it somewhere, or just let it through to your mailbox or delete it or??? Is there any consistency between providers or do they all do their own thing? Thanks. Dan.

2 2

un-bust-a-cap night at Skullspace (LCD/motherboard/etc repair)
by Colin Stanners 13 Oct '12

13 Oct '12

(I`m sending this to sksp, AW & a few wpg technology groups; please forward to anyone who may be interested) Due to the "bad capacitor plague", a number of electronic devices produced during the early to late 2000s have become unstable and unusable. In many cases, a few minutes and dollars spent to replace the capacitors will restore them to functionality. Come to Skullspace at 7pm on October 17th to learn the basics and try your hand at the process. If possible, let me know of your attendance in advance - CStanners(a)gmail.com .

1 0

spam filtering based on invalid DNS - local example
by Adam Thompson 11 Oct '12

11 Oct '12

Further to our discussion on Tuesday night: As a wonderful local example, I’ve just discovered that with postfix, enforcing valid HELO hostnames (which really isn’t all that stringent a check!) prevents the Winnipeg Free Press’ website from emailing me. It seems registering on the website causes the registration-confirmation email to be sent from “clickability.com” (aka Limelight’s “Dynamic Site Platform”). OK, fine. They even have reverse DNS set up correctly. But their outbound MX host identified itself as “la-mailout1.clickability.com”. No such A record exists, so postfix immediately rejects the message at the HELO stage. FWIW, the host connecting to me is “dv-mailout1.clickability.com”, which correctly resolves forward and reverse. For anyone who’s interested, my Postfix main.cf reads, in part: smtpd_helo_restrictions = permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, check_helo_access hash:/etc/postfix/client_access, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unauth_pipelining, reject_rhsbl_helo zen.spamhaus.org but adding: dv-mailout1.clickability.com OK la-mailout1.clickability.com OK 208.80.58.240 OK to /etc/postfix/client_access (and remembering to run postmap on it) eventually convinces Postfix to let this message in. (But typically not immediately, which I still don’t understand. Ideas?) Only one of those lines should be necessary, but I’ve never figured out which one :-). -Adam Thompson athompso(a)athompso.net

2 1

postfix discussion last night ...
by Dan Keizer 11 Oct '12

11 Oct '12

So, after our long(ish) discussion on mail/postfix/spamassasin/etc last night, I thought I'd run through a few things. ...OK -- I checked out a few things -- one of them to confirm I was *not* running an open relay ... Based upon my own checks and one I found on the net, it's not an open relay ... if you're interested, from the machine you want to test, goto: telnet rt.njabl.org 2500 that will initiate a number of checks - takes about a minute or so .. check your mail logs and the logs on the telnet screen for output. Dan.

1 1

LTSP demo
by Mike Pfaiffer 10 Oct '12

10 Oct '12

I mentioned this at last nights meeting. This is just a follow-up. Not necessarily a MUUG thing but a Linux thing none the less. At next months MWCS meeting on November 6'th (one week before the MUUG meeting) I will be giving a demo of a working LTSP system. I will spend 10 minutes describing the process I used to get it working and the rest of the evening will be an exploration of the system. If there is an expert reading this post who would like to contribute, feel free to drop by and take over after I do my bit. The address for the meeting will be 3390 Portage Avenue on the South side (between Westwood and Caviller - I think that's the general area). Land marks are the Safeway and McCardboard on the North side of Portage as well as the Princess Auto and Giant Tiger a block or so to the East on the South side. The time is 7:00 - 9:00 sharp. Parking is in the rear of the church. Enter through the back door and head down stairs. A bit about what to expect from the MWCS. The group is a generic computer club. We don't care what sort of computer people run. The ability level of the club is somewhat less than that of the MUUG. It is also substantially smaller than the MUUG with resources to match. We don't even have an internet connection available to us. The MWCS web page can be found at http://mwcs.mb.ca. For follow-up... Questions about the LTSP can (and logically should) be handled through the mailing list. Questions about the MWCS will be handled privately through e-mail. Later Mike

1 0

Re: [RndTbl] Screen in production
by Adam Thompson 10 Oct '12

10 Oct '12

IIRC, stderr doesn't buffer, stdout does. Both must block eventually once they hit the maximum buffer size the kernel and/or libc impose. Buffering != blocking. -Adam Robert Keizer <robert(a)keizer.ca> wrote: >On 12-10-10 10:33 AM, Gilbert E. Detillieux wrote: >> On 2012-10-10 09:50, Robert Keizer wrote: >>> I have a production service that prints some debug to stdout. I could >>> make it print to stderr, but it really doesn't matter in this case. >> >> Are you sure it doesn't matter? Read on... >> >>> I want to have some hope of if something goes wrong figuring out what >>> did. >>> Log files aren't really an option so I ran it in screen. Yes yes I could >>> have made it network log to somewhere else, but again, not really an >>> viable option in this case. Works great as the program dies and the >>> output stops, leaving the last debug messages in the buffer of screen. >> >> One of the classic C/UNIX lessons about stdout vs stderr is that the C >> library buffers stdout by default but not stderr, exactly for the >> reason that you want error messages to be flushed out right away, >> leaving nothing in the buffer. This is particularly important if the >> program dies in a way that prevents the usual exit processing, such as >> flushing buffers and closing file I/O. >> >> So, issues with "screen" aside, you probably should either send your >> debug output to stderr, or set your stdout to unbuffered mode while >> debugging (or both). >> > >Interesting! > >Thought I'd test out stdout vs stderr just to see if this was in fact >the case. It's not - stderr and stdout have the same effect in this case. > >Below is a script the listens for incoming data on a given port ( >example is 1337 ). When data is received it writes to either stdout or >stderr and then sends data on to another port ( in this case 1338 ). >This script also fills up the screen buffer by a simple loop ( tested >filling with both stderr and stdout ). > >Using telnet to feed the script data, and nc ( nc -lk 1338 ) to listen >on port 1338 for the output, one can test to confirm. > > >net = require "net" >server = net.createServer ( c ) -> > c.setEncoding "utf8" > c.on "data", ( data ) -> > _c = net.createConnection 1338, ( ) -> > process.stderr.write "Data: " + data + "\n" > _c.write data > _c.end( ) > >server.listen 1337, "127.0.0.1" >loops = ( ) -> > process.stderr.write "Loopies: " + Date( ) + "\n" > setTimeout loops, 100 >loops( ) > >Screenshot is attached - it shows this script in the top left running in >screen, with copy mode enabled. Right of it is the telnet session >feeding it, and on the bottom left is the nc or "output". Note that the >last two inputs did not make it to the output. Ergo, unless I'm totally >an idiot in my implementation: This is blocking on stderr as well. > >Thoughts? Because now I'm officially annoyed that this blocks on stderr >as well! > >Rob > > >_______________________________________________ >Roundtable mailing list >Roundtable(a)muug.mb.ca >http://www.muug.mb.ca/mailman/listinfo/roundtable

1 0

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