A recent announcement over at Adobe Labs delivered the deeply disappointing news that the team working on native 64-bit versions of the bloated, creaking memory-hog Flash Player had given up after literally several tries.
Apparently oblivious to the fact that the whole world is keen to shake off the shackles of 32-bit mediocrity, they’ve stopped all development of the 64-bit versions of their increasingly irrelevant resource consumer until some unspecified future date.
As if the world needed any further reminder of the overwhelming reasons for replacing this ageing monstrosity.
]]>Drawing up a list of criteria, and researching possible candidates, for a hardware purchase is an increasingly time-consuming process. Especially if the device in question is to be running Linux. Increasingly, reviewers trot out page after page of arbitrary statistics for things most of us will never attempt — instead of answering the important questions. Whilst it is pleasing to know that a reviewer has successfully installed the device to a point where it can be demonstrated in this way, sometimes it would be more useful to know exactly how this was done.
Take for example the subject of this article, the search for a replacement for an Intel D945GCLF motherboard that was struggling to fulfil some of the (possibly inappropriate) tasks thrust upon it.
The list of criteria wasn’t particularly onerous, but it was fairly specific:
Of this list the only point that could really be considered optional was number 6 — for convenience an IDE connector would be very useful, but an additional SATAII port would suffice (albeit with the additional cost of a replacement disk).
Unlike a year or two ago, there are a number of Mini-ITX motherboards on the market today to choose from, and even the luxury of a choice of manufacturers and multiple chipsets. Despite this it became apparent fairly quickly that the actual number of choices, given the above criteria, was slim.
The Mini-ITX boards seemed to fall into five main categories:
Of these, some could be discounted fairly quickly:
The first offered little gain over the current board — a dual-core 330 processor would be an improvement, gigabit Ethernet was available, but the package was always let down by limited storage connectivity (particularly SATAII) and poor graphics performance.
The fourth option, VIA EPIA systems, fell from grace a couple of years ago with the arrival of Intel Atom systems. Lacking in CPU performance in all but the very newest models and with graphics equally as poor as the Intel GMA950 systems, this option was starting to look unfavourable. Problems and lack of support with earlier VIA chipsets under Linux also contributed to ruling this one out.
Power requirements for the fifth option, even when designed with energy frugality in mind, always seemed to drift too high and heat dissipation presented a much greater problem....
]]>A few recent local changes included a restructuring of inbound mail delivery to include UCE (more frequently called spam) filtering using a combination of the venerable procmail and the increasingly impressive bogofilter.
Integration of bogofilter via procmail is covered in detail across the web, but it usually just a matter of adding a few lines to the top of your .procmailrc
similar to:
:0fw
| bogofilter -u -e -p
:0e
{ EXITCODE=75 HOST }
# file the mail to Trash/ maildir if it's spam.
# Use locking to prevent huge simultaneous delivery from causing DOS.
:0:
* ^X-Bogosity: Spam, tests=bogofilter
Trash/
Train the initial bogofilter database with some personal spam and ham corpus files and everything springs to life.
Now, out of choice, mutt is the default MUA here and it presents abundant possibilities for integration with bogofilter to allow correction and reclassification of any messages that produce unexpected results. In fact, the bogofilter man page even contains some macros that should allow this. Having tried these first, they do not seem to work in their current form. The local man page lists the following:
macro index d "<enter-command>unset wait_key0
<pipe-entry>bogofilter -n0
<enter-command>set wait_key0
<delete-message>" "delete message as non-spam"
macro index \ed "<enter-command>unset wait_key0
<pipe-entry>bogofilter -s0
<enter-command>set wait_key0
<delete-message>" "delete message as spam"
Even assuming that those terminating zeroes should probably be \n
these macros still have some fairly major problems:
-v
added to the bogofilter command-lines the result is always:
# 0 words, 0 messages
Clearly there is some tuning to be done. A more promising set of macros can be found in Busting Spam with Bogofilter, Procmail and Mutt, Revisited:
macro index s "<enter-command>unset wait_key\n
<tag-prefix><pipe-entry>bogofilter -MSn\n
<enter-command>set wait_key\n
<tag-prefix><save-entry>"
macro pager s "<enter-command>unset wait_key\n
<pipe-entry>bogofilter -MSn\n
<enter-command>set wait_key\n
<save-entry>"
macro index r "<enter-command>unset wait_key\n
<tag-prefix><pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<tag-prefix><reply>"
macro pager r "<enter-command>unset wait_key\n
<pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<reply>"
macro index g "<enter-command>unset wait_key\n
<tag-prefix><pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<tag-prefix><group-reply>"
macro pager g "<enter-command>unset wait_key\n
<pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<group-reply>"
macro index l "<enter-command>unset wait_key\n
<tag-prefix><pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<tag-prefix><list-reply>"
macro pager l "<enter-command>unset wait_key\n
<pipe-entry>bogofilter -Mn\n
<enter-command>set wait_key\n
<list-reply>"
macro index X "<enter-command>unset wait_key\n
<tag-prefix><pipe-entry>bogofilter -MNs\n
<enter-command>set wait_key\n
<tag-prefix><delete-message>"
macro pager X "<enter-command>unset wait_key\n
<pipe-entry>bogofilter -MNs\n
<enter-command>set wait_key\n
<delete-message>"
These are a huge improvement, macros defined for the index page are applied to all currently tagged messages, whilst those for the pager apply only to the current message. However, it soon became apparent that these were also not working as expected with bogofilter 1.2.1 — back to the debugging output. It transpired that there were several different problems with this particular setup.
Firstly, the LinuxJournal macros above use <pipe-entry>
to send the email text to bogofilter. It seems that in certain cases this does not send the entire...
Ever run snmpwalk
on an SNMP-enabled device and been disappointed by the available information? There may well be a very simple reason for that.
The Net-SNMP implementation of the SNMP stack has some default settings that may be far from optimal in many cases. Specifically, the snmpwalk
and snmpbulkwalk
applications poll only a specific subset of the full MIB tree.
SNMP variables are arranged in a tree structure, each layer of which becomes more and more specific. Each node of this tree is assigned an unique OID formed from the path to this node, which may be translated by a MIB entry to something more human-readable. For example, a standard OID found on most devices is:
.1.3.6.1.2.1.1.2.0
With the appropriate MIB files available, this will be translated to:
.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0
So far, so good. snmpwalk
should, as it’s name suggests, walk through the OID tree and report each node, translating the entries, as far as possible, from the available MIB library. However, if you run a default snmpwalk
against a device, forcing numeric OID output e.g.
snmpwalk -v2c -On -c <community> device
there is something a little strange about the returned list. The root node of the returned values is:
.iso.org.dod.internet.mgmt.mib-2```
By default, both `snmpwalk` and `snmpbulkwalk` only walk the OID tree below this node. The problem is most manufacturer-specific information is not below this node, but rather this one:
```.1.3.6.1.4.1
.iso.org.dod.internet.private.enterprises```
To give you an example of the amount of data skipped by a default `snmpwalk`, consider the following:
`snmpwalk -v2c -c <community> <cisco837>`
This default run against a local Cisco 837 router returns 4283 nodes and totals 256733 bytes.
`snmpwalk -v2c -c <community> <cisco837> .1.3.6.1`
Forcing the root node for the walk two levels higher in the tree returns 13553 nodes and totals 866504 bytes.
Next time you cannot find the information you require in an `snmpwalk`, double-check that you’re looking at the whole tree and not just a small subset.
]]>
After what seems like an age, Adobe has stopped pretending that the undeniable future of computing is 32-bit and built a native 64-bit Flash plugin for Linux. Although still an alpha release, it is at least the current version (10). If you’re using 64-bit Linux, and feel you’re missing out on a whole world of quality rich media, scoot along and grab it here.
For the hardcore masochists amongst you, there’s also a version for Solaris-x86 on the same page.
Update: In case anybody is wondering, the full dependencies for the plugin are listed below:
linux-vdso.so.1 => (0×00007fffaffff000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0×00007ffca3010000)
libpthread.so.0 => /lib/libpthread.so.0 (0×00007ffca2df5000)
libX11.so.6 => /usr/lib/libX11.so.6 (0×00007ffca2ae8000)
libXext.so.6 => /usr/lib/libXext.so.6 (0×00007ffca28d7000)
libXt.so.6 => /usr/lib/libXt.so.6 (0×00007ffca2777000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0×00007ffca24e1000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0×00007ffca22b0000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0×00007ffca1cd4000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0×00007ffca1a34000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0×00007ffca1813000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0×00007ffca15f5000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0×00007ffca13e9000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0×00007ffca119f000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0×00007ffca0f22000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0×00007ffca0cdd000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0×00007ffca0ada000)
libdl.so.2 => /lib/libdl.so.2 (0×00007ffca08d6000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0×00007ffca0612000)
libnss3.so => /usr/lib/libnss3.so (0×00007ffca02c6000)
libsmime3.so => /usr/lib/libsmime3.so (0×00007ffca009a000)
libssl3.so => /usr/lib/libssl3.so (0×00007ffc9fe68000)
libplds4.so => /usr/lib/libplds4.so (0×00007ffc9fc65000)
libplc4.so => /usr/lib/libplc4.so (0×00007ffc9fa61000)
libnspr4.so => /usr/lib/libnspr4.so (0×00007ffc9f823000)
libm.so.6 => /lib/libm.so.6 (0×00007ffc9f5a0000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0×00007ffc9f389000)
libc.so.6 => /lib/libc.so.6 (0×00007ffc9f034000)
/lib/ld-linux-x86-64.so.2 (0×00007ffca7f1a000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0×00007ffc9ee33000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0×00007ffc9ec17000)
libXau.so.6 => /usr/lib/libXau.so.6 (0×00007ffc9ea14000)
libSM.so.6 => /usr/lib/libSM.so.6 (0×00007ffc9e80c000)
libICE.so.6 => /usr/lib/libICE.so.6 (0×00007ffc9e5f1000)
libz.so.1 => /usr/lib/libz.so.1 (0×00007ffc9e3db000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0×00007ffc9e1b2000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0×00007ffc9dfb0000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0×00007ffc9ddad000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0×00007ffc9dca8000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0×00007ffc9da34000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0×00007ffc9d807000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0×00007ffc9d5df000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0×00007ffc9d3d6000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0×00007ffc9d1d3000)
libXi.so.6 => /usr/lib/libXi.so.6 (0×00007ffc9cfca000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0×00007ffc9cdc3000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0×00007ffc9cbb8000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0×00007ffc9c974000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0×00007ffc9c770000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0×00007ffc9c568000)
libpcre.so.0 => /lib/libpcre.so.0 (0×00007ffc9c339000)
libnssutil3.so => /usr/lib/libnssutil3.so (0×00007ffc9c11b000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0×00007ffc9c016000)
libuuid.so.1 => /lib/libuuid.so.1 (0×00007ffc9be11000)
Quite a collection!
]]>A recent upgrade to python 2.6 left a getmail cron job spewing warnings about a deprecated import of the sets
module:
DeprecationWarning: the sets module is deprecated
Since python 2.4 the functionality of this module has been duplicated by built-in functions; a quick conversion is all that is required to quieten the new warnings. The patch is available here for those with a similar problem:
diff -Naur getmail-4.8.4-orig/getmailcore/_retrieverbases.py getmail-4.8.4/getmailcore/_retrieverbases.py
--- getmail-4.8.4-orig/getmailcore/_retrieverbases.py 2008-08-02 17:25:43.000000000 +0100
+++ getmail-4.8.4/getmailcore/_retrieverbases.py 2008-11-02 15:50:35.000000000 +0000
@@ -42,7 +42,6 @@
import email
import poplib
import imaplib
-import sets
from getmailcore.exceptions import *
from getmailcore.constants import *
@@ -358,9 +357,9 @@
wrote = 0
try:
f = updatefile(self.oldmail_filename)
- msgids = sets.ImmutableSet(
+ msgids = frozenset(
self.__delivered.keys()
- ).union(sets.ImmutableSet(self.oldmail.keys()))
+ ).union(frozenset(self.oldmail.keys()))
for msgid in msgids:
self.log.debug('msgid %s ...' % msgid)
if forget_deleted and msgid in self.deleted:
diff -Naur getmail-4.8.4-orig/getmailcore/baseclasses.py getmail-4.8.4/getmailcore/baseclasses.py
--- getmail-4.8.4-orig/getmailcore/baseclasses.py 2008-03-26 13:45:51.000000000 +0000
+++ getmail-4.8.4/getmailcore/baseclasses.py 2008-11-02 15:49:34.000000000 +0000
@@ -24,7 +24,6 @@
import time
import signal
import types
-import sets
from getmailcore.exceptions import *
import getmailcore.logging
@@ -249,7 +248,7 @@
self.log = getmailcore.logging.Logger()
self.log.trace()
self.conf = {}
- allowed_params = sets.Set([item.name for item in self._confitems])
+ allowed_params = set([item.name for item in self._confitems])
for (name, value) in args.items():
if not name in allowed_params:
self.log.warning('Warning: ignoring unknown parameter "%s" '
@@ -272,8 +271,8 @@
# New class-based configuration item
self.log.trace('checking %s\n' % item.name)
self.conf[item.name] = item.validate(self.conf)
- unknown_params = sets.ImmutableSet(self.conf.keys()).difference(
- sets.ImmutableSet([item.name for item in self._confitems])
+ unknown_params = frozenset(self.conf.keys()).difference(
+ frozenset([item.name for item in self._confitems])
)
for param in sorted(list(unknown_params), key=str.lower):
self.log.warning('Warning: ignoring unknown parameter "%s" '
diff -Naur getmail-4.8.4-orig/getmailcore/filters.py getmail-4.8.4/getmailcore/filters.py
--- getmail-4.8.4-orig/getmailcore/filters.py 2008-02-17 17:10:40.000000000 +0000
+++ getmail-4.8.4/getmailcore/filters.py 2008-11-02 15:51:38.000000000 +0000
@@ -14,7 +14,6 @@
import os
import types
-import sets
from getmailcore.exceptions import *
from getmailcore.message import *
@@ -194,8 +193,8 @@
if 0 <= int(i) <= 255]
if not self.exitcodes_keep:
raise getmailConfigurationError('exitcodes_keep set empty')
- if sets.ImmutableSet(self.exitcodes_keep).intersection(
- sets.ImmutableSet(self.exitcodes_drop)
+ if frozenset(self.exitcodes_keep).intersection(
+ frozenset(self.exitcodes_drop)
):
raise getmailConfigurationError('exitcode sets intersect')
except ValueError, o:
getmail-4.8.4-python-2.6.patch
No problems with it here so far, please leave a comment if you use the patch and find any.
]]>After the changes of last week things were still not quite right. The WET would still periodically fail, usually only for a few seconds, but sometimes for much longer. I began to suspect that this was an external problem; something in the house was interfering with the signal.
After a few days of monitoring the link, I could find no correlation between the intermittent failures and changes in the local environment. Back to the proverbial drawing board.
I decided to go right back to the beginning and check the set-up from scratch. Whilst removing and reseating the external antenna from one of the routers, I remembered something I’d read previously. These Buffalo WHR-HP-G54 routers actually have not one, but two antenna — the obvious external rubber duckie and an internal plate providing some level of diversity reception. This can be clearly seen on the FCC certification report.
The drops I was seeing could potentially be explained by the routers switching the active path from one antenna to the other. If both ends of the connection were acting in a similar way this could explain the symptoms I’d seen. Fortunately, the Tomato Firmware allows very specific control over which antenna is used for both transmission and reception:
The default setting is Auto
which will attempt to use the antenna with the best signal for each task (which may be the same for both). However, in my particular set-up this seems to cause the router to periodically select the wrong antenna — causing the Wireless Pit Of Despair effect described previously.
A simple trial and error process revealed that the external antenna on a Buffalo WHR-HP-G54, when using Tomato Firmware at least, is antenna B. A simple change forced the use of the external antenna for both transmission and reception:
You may also notice a couple of other settings above that are different from the defaults. Firstly, on this particular router, I have Enhanced RX Sensitivity
disabled. The screen-shot is taken from the WET, which is located above a desk containing all manner of electronic devices. Enabling the Receive amplifier (controlled by the Enhanced RX Sensitivity
setting) on this router causes the signal quality to deteriorate due to the local electrical noise. On the access point that the bridge connects to I have this setting enabled — test and see which gives a better result for your own location.
Secondly, I have the Transmit Power
bumped up to 40 mW. I’m in the process of testing this, reducing it a few mW at a time to find what level is actually required.
So far, so good. No problems for a few days, and a stable, strong signal at all times.
]]>Following a recent rearrangement, I found a number of my computers on the wrong side of the lounge and a solid wall from the ADSL router. The layout of the room, and the solid floors and walls, ruled out running cables but with a wireless access point already in place, running the incomparable Tomato Firmware, the solution was obvious: Install a second wireless router (with Tomato naturally) and make the connection that way.
Originally I configured this using WDS using the information in the Tomato FAQ and the Tomato Wikibook. It’s a reasonably straightforward process so I won’t repeat it all here. When it doesn’t work the first few times, head on over to the Tomato Firmware Forum at LinksysInfo and read some of the many threads discussing the problems you’ve just run into.
My initial configuration used a WDS setup to bridge the two network segments.
Once I’d got it working I was very impressed. Latency was pretty good, less than 3ms from server to ADSL router over the wireless connection. Throughput wasn’t really an issue either as the only thing on the far side of the link was the, comparatively slow, internet connection. All in all, simple and effective.
Everything worked perfectly for a while, and then this happened:
Actually, this graph is the third or fourth time this has happened in the four weeks since I set this up. Nothing changes on the equipment, nothing changes in the local environment that I can see, but suddenly the link spirals into the Wireless Pit Of Despair. Just before it died completely there was a packet latency of 3.2 seconds! Recovery from this point requires a hard reboot of both wireless routers.
Further trawling through the magic of the internet showed that I wasn’t alone in this – unfortunately there was no obvious solution to be found. One thing that did crop up related to the choice between WDS and WET. There is some overlap between the functionality of these two Tomato operating modes, especially in my case. The most obvious point is that WDS is designed to extend the coverage area of a wireless network within a single network segment. WDS networks would generally have all devices in WDS+AP mode – connecting wirelessly to both clients and infrastructure. Seeing as I wasn’t using the second Tomato router as an Access Point (it was in WDS-only mode), WDS wasn’t really required at all.
A simpler solution for my network is to configure the second Tomato router as a Wireless Ethernet Bridge (a curiosity for acronym fans – this one is WET not WEB as you may expect). A subtle change:
I found that there are some gotchas waiting for those changing from WDS to WET mode:
After writing so confidently about finding a fix for the earlier kernel problems with an Intel D945GCLF board, it returned with a vengeance shortly afterwards. Frustration finally won the day and a completely fresh install followed.
Gentoo had been the Linux distribution of choice on the previous box, but as speed was of the essence here (downtime was almost five days), something else was in order. That something turned out to be Arch Linux — might as well start with something completely different.
One thing became immediately apparent though: No more crashes. Throughout the entire installation process not a single problem, even with the newest 2.6.25.4 kernel. So why the difference? 64 vs. 32 bit?
As a quick test out came the trusty x86_64 PLD-Linux Rescue disc — and back came the problems. Same kernel version, same architecture, different distribution. Or was it… Different from the working Arch64 install certainly, but not different from the equally problematical Gentoo install. Could it be the Gentoo patchset that was causing all the problems? A quick verification with a Gentoo LiveCD and again the same problems.
It wasn’t the fault of the Atom board at all, some part of the Gentoo distribution was causing the issues. Following this revelation, and a reboot back into Arch64, the system has been up and stable for over 40 hours with several long periods at load. There’s no sign of the earlier ACPI/APIC problems experienced under Gentoo and its derivatives, just fast, stable, Arch64 goodness.
ArchLinux — consider me an errant soul returned to the fold.
]]>To cut a long story short, acpi=ht
isn’t the magic solution. Although much more stable than before, stable enough to get X windows up and running, it still fell foul of the same runaway kacpid
problem eventually. It had to be another part of ACPI causing the problems. A quick look back through the dmesg output showed only very minimal portions of the ACPI code enabled. Immediately obvious was the output describing the LAPIC and IOAPIC setup. Both of these shared one very important feature: They could be individually disabled from the kernel command-line for testing.
Rebooting with noapic
appended to acpi=ht
appeared again to be successful. After eight hours of constant use under heavy load (recompiling more optimised packages) the system was stable. Could this be the solution? Was the IOAPIC to blame?
A final reboot would confirm my suspicion: Remove acpi=ht
entirely and leave only noapic
on the kernel command-line. Another twenty hours later and this is being typed on what is seemingly a stable system.
Hopefully this will save somebody some time.
[ACPI]: Advanced Configuration and Power Interface [LAPIC]: Local Advanced Programmable Interrupt Controller *[IOAPIC]: Input/Output Advanced Programmable Interrupt Controller
]]>