May 2012 - Roundtable

SpamAssassin false positives on DATE_IN_FUTURE_96_Q?
by Gilbert E. Detillieux 23 Feb '16

23 Feb '16

I mentioned this problem at the last round-table session, but didn't get a solution, so I thought I'd post it here, just in case anyone has any suggestions to offer. I'm still seeing a whole bunch of false positives in SpamAssassin, since an update was installed in mid-September on a CentOS 5.7 system, for a rule called DATE_IN_FUTURE_96_Q, which is only supposed to be triggered when the "Date:" header has a date that is 4 days to 4 month ahead of the date in the "Received" header that has the _smallest_ difference in date. Here are the headers from the latest e-mail I've received with this false-positive. (I've stripped out irrelevant headers, for the sake of clarity and simplicity.) From topfivestories(a)messagent.itworldcanada.com Mon Nov 14 07:50:13 2011 Received: from mail.messagent.itworldcanada.com (mail.messagent.itworldcanada.com [207.112.10.80]) by palladium.cs.umanitoba.ca (8.13.8/8.13.8) with SMTP id pAEDoAxV028594 for <gedetil(a)cs.umanitoba.ca>; Mon, 14 Nov 2011 07:50:12 -0600 Date: Mon, 14 Nov 2011 08:50:13 -0500 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_96_Q, HTML_MESSAGE,RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on palladium.cs.umanitoba.ca Note that I'm calling spamd via the spamass-milter on a system running sendmail. Note also, that in the above example, the only "Received" header was the one generated by my own server. (I've had other false positives, however, with multiple "Received" headers, all of which were within seconds of the time in the "Date" header.) Any ideas? -- 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

6 11

USB Ethernet
by Brock Wolfe 20 May '12

20 May '12

I need to connect a remote PC ( no local network jack in room) to a wireless access point and was looking at USB network dongles. Any experiences/recommendations on using these devices. I've looked and some have external antennas which might help get a little extra range / signal strength that would be big plus. Brock

2 1

Ubuntu Mirror WTF
by Robert Keizer 20 May '12

20 May '12

So I noticed that the default ca.archive.ubuntu.com mirrors were kind of slow.. so I did a quick little traceroute.. Anyone else notice a problem? I'm figuring that it is most likely also because of the time ( see last command ). -bash-4.1# traceroute 91.189.92.154 traceroute to 91.189.92.154 (91.189.92.154), 64 hops max, 40 byte packets 1 * * * 2 rc1nr-tge0-8-2-0-11.wp.shawcable.net (64.59.176.131) 12.396 ms 18.5 ms 11.419 ms 3 rc2ec-tge0-8-1-0.il.shawcable.net (66.163.77.129) 32.12 ms 31.157 ms 32.776 ms 4 xe-11-1-3.edge4.Chicago3.Level3.net (4.53.98.85) 29.527 ms 29.926 ms 34.68 ms 5 vlan51.ebr1.Chicago2.Level3.net (4.69.138.158) 30.685 ms 29.405 ms 27.352 ms 6 ae-6-6.ebr1.Chicago1.Level3.net (4.69.140.189) 29.658 ms 30.352 ms 39.874 ms 7 ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66) 49.903 ms 59.498 ms 54.857 ms 8 ae-1-100.ebr1.NewYork2.Level3.net (4.69.135.253) 51.586 ms 57.691 ms 56.904 ms 9 ae-4-4.ebr1.NewYork1.Level3.net (4.69.141.17) 56.484 ms 48.880 ms 51.475 ms 10 ae-42-42.ebr2.London1.Level3.net (4.69.137.69) 120.615 ms 116.879 ms ae-43- 43.ebr2.London1.Level3.net (4.69.137.73) 118.230 ms 11 ae-59-224.csw2.London1.Level3.net (4.69.153.142) 121.583 ms ae-58-223.csw2.London1.Level3.net (4.69.153.138) 122.215 ms ae-57-222.csw2.London1.Level3.net (4.69.153.134) 121.284 ms 12 * ae-2-52.edge4.London1.Level3.net (4.69.139.106) 117.938 ms 117.407 ms 13 MNET-INTERN.edge4.London1.Level3.net (212.113.14.198) 119.474 ms 121.152 ms 131.208 ms 14 haetae.canonical.com (91.189.92.154) 613.140 ms 529.832 ms 412.800 ms -bash-4.1# dig A ca.archive.ubuntu.com | grep 91.189.92.154 ca.archive.ubuntu.com. 471 IN A 91.189.92.154 -bash-4.1# date Sun May 20 11:31:50 CDT 2012 -bash-4.1#

2 2

weird md raid situation
by Trevor Cordes 14 May '12

14 May '12

I love linux software ("md") raid. I use md raid1 on a zillion systems. I never has issues. Until today... I get a call that a customer has lost all their emails for about a month and their apps' data appears to be old and/or missing. Strange. I login to the linux server and see: cat /proc/mdstat Personalities : [raid1] md122 : active raid1 sda1[0] 409536 blocks [2/1] [U_] md123 : active raid1 sda2[0] 5242816 blocks [2/1] [U_] md124 : active raid1 sda3[0] 1939865536 blocks [2/1] [U_] md125 : active raid1 sdb1[1] 409536 blocks [2/1] [_U] md126 : active raid1 sdb2[1] 5242816 blocks [2/1] [_U] md127 : active raid1 sdb3[1] 1939865536 blocks [2/1] [_U] That's not correct. These systems should have 3 partitions, not 6. Ah, md has done some really goofball things with this pathological case. It's separated the raid into duplicates and assembled each separately! Woah! They said they had a accidental reboot today (kid hitting reset button). And it booted/rooted off the wrong schizo set (sda). There appears to have been a drive failure/kick a month ago: Apr 4 10:10:32 firewall kernel: [1443781.218260] md/raid1:md127: Disk failure on sda3, disabling device. Apr 4 10:10:32 firewall kernel: [1443781.218262] <1>md/raid1:md127: Operation continuing on 1 devices. And it hadn't rebooted since then, before today. It gets stranger... I rebooted the system trying to test a few recovery ideas (offsite) out. On the next reboot it came up using the good/current sdb drive for boot/root! Huh? It's like it's picking which one to use at random! It still shows 6 md arrays, but it's using the properly 3 this time. So is all this a bug? 1. Shouldn't the system have marked the sda as failed/bad PERMANENTLY so on next reboot it would ignore it. OK, I can understand that if it thought the whole drive was bad, it wouldn't be able to write to the sda superblock to survive the reboot. But couldn't it have written the info to sdb's superblock? If a system can't remember what has failed, then I don't see how this behaviour can be avoided. 2. Why did linux md bring up both sets of arrays? It can see they are the same array. Why on earth would it ever split them? That seems majorly screwy to me. Still, thank God it didn't try to start syncing the stale set to the good set! We had backups, but it's a pain to recover. In the end, just rebooting until luck gives us the current set was all it took. I'll head on-site to replace the bad disk and do a proper resync. I have had hardware RAID systems (ARAID99) in this exact situation go into a schizo state where the disks were unsynched yet both were being used for writes! The problems always seem to revolve around a disk going "soft" bad and then coming alive after reboot.

2 1

And I thought *I* was a geek...
by Adam Thompson 13 May '12

13 May '12

https://schemaverse.com/ If you ever need material to rebut the accusation that you’re the world’s biggest geek, you can at least say that *you* didn’t create an entire spacewar-type game implemented in PostgreSQL! -Adam Thompson athompso(a)athompso.net

1 0

Load average under RHEL 6.x systems?
by Gilbert E. Detillieux 11 May '12

11 May '12

Howdy folks! I asked this at last night's meeting, as my "stumper of the month", but didn't get any solutions or leads. So, I thought I'd ask again here... After upgrading many of our systems, both workstations and servers, from CentOS 5.x to Scientific Linux 6.x, I'm seeing higher load averages on idle systems than I used to. Under EL5, loads would drop to zero and pretty much stay there most of the time for idles systems. Under EL6, the load might drop down to 0.1, but doesn't stay there for very long, and even on seemingly idle systems, I see loads at or near 1 (sometimes even higher than 1 on some of our servers). It's also intermittent, with load averages dropping and climbing on fairly short intervals (of a few minutes or so). Running top, iotop, ftop, iftop, etc. doesn't really point to any major culprits. I've even run PowerTop, and implemented some of its suggested improvements, but that didn't make a difference on load. Just wondering if anyone else has seen similar behaviour with hosts running Red Hat and/or Fedora distributions? Would moving to the "tickless" kernel have anything to do with it? (I.e. does it somehow affect the way load averages are calculated?) Or is it some system service that can be shut down? (If it is, it's not creating an obvious load on its own, that top or ftop would show, but it may be affecting something in the kernel...) Any suggestions? -- 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

2 5

Parallel man page
by Mike Pfaiffer 08 May '12

08 May '12

After tonights demo by Gilbert I decided to give parallel a try. I installed it on my Mint 10 (Linux) machine and my 10.6 Mac via Mac Ports. It works on the Mac and I haven't tried it under Linux yet. Anyhow I noticed the man pages are different. The Mac has a fuller man page than Linux. First impression... It does what I want but I need to tweak my scripts. Later Mike

1 0

Sun StorageTek software?
by Kevin McGregor 08 May '12

08 May '12

We keep getting these emails every 6 hours here at work. Does anyone recognize them? I think they are coming from the Sun StorageTek management software running on this server which is no longer connected to any StorageTek device. We'd like to disable or uninstall the software, or at the very least, somehow stop the emails. Does anyone know where to look for the configuration of this software? I don't really want to grep every file on the system looking for matching strings... You requested the following events be forwarded to you from <server_name> Site : <site_name> Agent : <server_name> Severity : Major Category : agent Device Id : <server_name> Topic : System Event Type : NotifierFailedEvent Event Code : 4.72.582 Event Date : 2012-05-03 10:00:01 Description: An attempt to contact the ASR server resulted in a Connection refused failure. Probable Cause: The ASR has indicated a problem processing the posted data. The cause may be due to an internal server failure, invalid settings locally, or due to the Recommended Action: Examine the reason indicated in the description. If the reason indicates a server failure, then back end support will need to be notified. If the connection was refused, verify the Sun Connection Configuration settings first, then verify with back end support that the server is operational.

2 1

Celebrate Day Against DRM - Save 50% on all Ebooks & Videos. Today only.
by Gilbert E. Detillieux 04 May '12

04 May '12

FYI... ------------------------------------ View in browser <http://post.oreilly.com/rd/9z1zh638brngfd1lclk6n4ejfaasgb8onl25nr81j00>. O'Reilly - Books and Videos In Celebration of *Day Against DRM* Save 50% on ALL Ebooks & Videos Having the ability to download files at your convenience, store them on all your devices, or share them with a friend or colleague as you would a print book, *is liberating, and is how it should be*. If you haven't tried a DRM-free ebook or video, we encourage you to do so now. And if you're already a fan, take advantage of our sale and add to your library. For one day only, you can save 50% on all O'Reilly, No Starch, and Rocky Nook ebooks and videos. *Use code: DRMFREE* View the Titles <http://post.oreilly.com/rd/9z1zkfkss3a9jv8u39eq9h3nualdufuov3siodb5vg0> Soldiers <http://post.oreilly.com/rd/9z1zdb4a1j9c9q7chnq56b924a0qp1rah5er1ff6gkg> Ebooks from oreilly.com <http://post.oreilly.com/rd/9z1zaohclbq0rl0barppp5s4ljpn2of695gf4715q5o> are *DRM-free*. You get *free lifetime access, multiple file formats, free updates.* Deal expires May 4, 2012 at 11:59pm PT and cannot be combined with other offers. Spreading the knowledge of innovators. oreilly.com <http://post.oreilly.com/rd/9z1z5d1g81buj14700a4ifdpssi52nobkdlv11k12pg> You are receiving this message because you purchased directly from O'Reilly or registered titles. Keep up on all things O'Reilly by signing up for our *email alerts and newsletters* <http://post.oreilly.com/rd/9z1z0r62s9avecf9buikgrjt2kqsg8hm9n2djhq2g68>. To ensure delivery to your inbox (not bulk or junk folders), please add *oreilly(a)post.oreilly.com* <mailto:oreilly@post.oreilly.com> to your address book. To unsubscribe from all email announcements from O'Reilly, click here <http://post.oreilly.com/rd/9z1zoq6vdbcnqlng9i4lk33vqefvmbq7hfa475opdl8>. O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 (707) 827-7000

1 0

MUUG Meeting, May 8, 7:30pm -- ZFS
by gedetil＠cs.umanitoba.ca 01 May '12

01 May '12

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, May 8. The meeting topic for this month is as follows: ZFS Edwin Amsler will talk about (and demonstrate, if all goes well) ZFS. ZFS is a filesystem originally developed at Sun Microsystems. It has numerous features and has a native port to Solaris, OpenSolaris, and FreeBSD; Non-official ports have been made to Linux and Mac OSX. Edwin will be focusing on the basic usage of the filesystem and the snapshotting features that come built in. May's RTFM will feature the parallel(1) command, presented by Gilbert Detillieux. 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 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