Jamie Neil's blog

The updated version of snmpd in Debian Etch doesn't seem to like our customised vif interfaces names that we're using for Xen hosting. I'm seeing the error "ioctl 35123 returned -1" in syslog every 5 minutes. Reverting to the standard "vifx.y" format fixes the problem.

I started using xen guest names for vif interfaces to allow our graphing system (Cacti) to keep track of which interface matched a particular guest. For example a guest called acme would have an interface called acme.eth0 in the xen host instead of a dynamically generated name like vif14.0. This seemed to be working fine with Sarge, but alas not with Etch. I tried some variations like acme-eth0 and acme.0, but nothing seems to get rid of the error except vifx.y.

We've used Best Practical's Request Tracker (RT) for several years now for managing both customer support queries and our own internal processes, and over that time I've always customised it by simply hacking the existing Mason pages and putting them in rt3/local/ to override the original versions. However this is always a huge pain when it comes to upgrades as I have to backport all my changes to the new version. So for my latest tweak I thought that I would have a go at using the Callback mechanism instead.

Callbacks are breakpoints in the RT code that allow you to add extensions or override some existing functionality. They are not quite as flexible as editing the original pages, but because the changes are kept separate they should be much easier to maintain. Unfortunately they are not as well documented as other parts of RT which is probably why I'd not really looked at them properly before.

A callback is created by simply placing a Mason page in the rt3/local/html/Callbacks/*/ path that corresponds to the page and callback point that you are trying to use. The * is simply any string that you might want to use to group your callbacks together (I've used "RunPCRun" in this example).

The feature I wanted to add was to replace the textbox for a custom field called "Account" with a dropdown that was populated from an SQL query to an external data source. The callback in question is located in html/Elements/EditCustomField, and is called "EditComponentName" (unlike most callbacks that are simply called "Default"). Here's the relevant part of the page:

my $EditComponent = "EditCustomField$Type";
$m->comp('/Elements/Callback',
_CallbackName => 'EditComponentName',
Name => \$EditComponent,
CustomField => $CustomField,
Object => $Object );
$EditComponent = "EditCustomField$Type" unless $m->comp_exists($EditComponent);

So I created file called "EditComponentName" in "rt3/local/html/Callbacks/RunPCRun/Elements/EditCustomField/" with the following contents:

<%INIT>
if ($CustomField->Name eq 'Account') {
$$Name = "EditCustomFieldAccount";
}
</%INIT>
<%ARGS>
$CustomField => undef
$Name => undef
</%ARGS>

Now whenever a custom field widget is displayed, the callback code checks to see if the field is called "Account" and if it is then it sets the EditComponent variable (using the Name reference) to "EditCustomFieldAccount". The EditComponent variable is used by RT to determine the name of the file containing the widget code. Normally this is set to "EditCustomField$Type" where type is the determined by the custom field type ("FreeForm" in this particular case), but by overriding it with the callback I can now create a file called "rt3/local/html/Elements/EditCustomFieldAccount" which contains my custom widget code:

<select name="<%$NamePrefix.$CustomField->Id.'-Value'%>">
<option value="NONE">NONE</option>
% my $currentvalue;
% for my $customer (@{$session{$cache_key}}) {
<option value="<% $customer->{Code} %>"
<% (($customer->{Code} eq $Default) ? 'selected="selected"' : '') |n %>>
<%$customer->{Name}%> (<%$customer->{Code}%>)
</option>
% }
</select>
<%INIT>
my $cache_key = "SelectAccount---" . $session{'CurrentUser'}->Id;
if (not defined $session{$cache_key}) {
# Get list of customers
my $Customers = new RT::Customers($session{'CurrentUser'});
$Customers->UnLimit;
while (my $customer = $Customers->Next) {
push @{$session{$cache_key}}, {
Id => $customer->Id,
Name => $customer->Name,
Code => $customer->Code,
};
}
}
</%INIT>
<%ARGS>
$CustomField => undef
$NamePrefix => undef
$Default => 0
</%ARGS> 

 

There seems to be some problem in the way the Thunderbird email client handles certain kinds of attachment which means the message "This body part will be downloaded on demand" is displayed when you try to view a message. We've seen this problem both with VCard attachments (.vcf) generated by Thunderbird when combined with other attachment types, and with certain attachments sent from Microsoft Outlook.

The only non Nokia phone that I've ever bought was a Handspring Treo 600. I got it because I wanted to be able to manage servers over the Internet from my phone using SSH without carrying around a laptop or other bulky device. The Treo looked perfect, querty keyboard, big colour (touch screen) display, and Palm OS, but once I'd used it for a bit I realised that it had some pretty big flaws: The screen was only 160x160 pixels which is too small for even a 40 column display let alone 80 cols; it had no Wifi or bluetooth so connecting to other devices was a pain; and finally, although it worked ok as a PDA, it was a terrible phone!

So when I saw the E61 announced around this time last year I couldn't wait until my current contract expired so that I could get one. It seemed to fix all the things that let the Treo down: Nokia design, Symbian OS, 3G, Bluetooth and a QVGA screen, plus it had two killer features: WiFi and SIP. So now that I've finally bought one, is it all that it promised?

Initial Impressions

I got my last phone (a Nokia 6630) on an 18 month contract with T-Mobile, and as I haven't had any real problems I decided to get the E61 from them as an upgrade (plus they do an unlimited data plan for £7.50/month). I've also found that T-Mobile don't muck around with the firmware quite as much as some operators (like 3 and Vodaphone).

The T-Mobile package is completely standard as far as I can see (apart from the silkscreened logos that they insist on putting on):

• The phone
• 64Mb Mini SD card
• BP-5L Li-ion Battery
• Mains charger
• Mono Pop-Port earpiece
• Installation CD
• Lots of docs

The phone looks and feels very solid with none of the annoying slidy bits that I've seen on some of Nokia's other recent phones (N70). Would have been nice it they had shipped a stereo headset like they did on the 6630, but that's not a big problem. The BP-5L battery has double the capacity (1500mAh) of the old BL-5C that I've got in my old phone, and I can see the necessity due to the additional drain from a big display and Wifi, but it's a pity because I've got about 5 BL-5Cs lying about and my bluetooth GPS (a Nokia LD-3W) uses them too. The charging socket is one of the new micro ones (same as my GPS), but they do provide an adapter that lets you use an old charger instead.

Ergonomics

The screen is bright and very clear - my photos don't do it justice at all! In fact it's got to be one of the best screens that I've seen on a phone. It's 320x240 landscape which is the same as a lot of (older) pocket PCs, with 16.7 Million colours, so photographs look fantastic. The keyboard (thumbboard?) is well laid out and the keys have a positive feel without being too clicky, but the dial/hang-up keys are a bit awkward and may take a bit of getting used to. The 5-way navigation button is now a joystick which for me is easier to use. The only criticism that I can make is that it's a bit too wide to hold comfortably, but I guess that's what you get if you want a big screen.

Connectivity

It's hard to fault the connectivity - it's got pretty much everything. GPRS, 3G, Bluetooth (with support for multiple connections), WLAN, USB (via Pop-Port), and even good old IR (which was sorely missed on the 6630).

Memory expansion is now via Mini SD which is a bit annoying because i'd only just got a 1Gb RS-DV SD card for my 6630, and the supplied 64Mb card is next to useless. But you can get a 1Gb card for less than £20 now so it's not the end of the world. You can change the memory card while the phone is switched on, but you have to take the back cover off to do it. At least it won't keep popping out in my pocket like the Treo used to do!

Applications

All the usual S60 applications are accounted for like the office stuff, calendar, contacts etc., but there's also some new ones. Highlights for me are:

• Adobe PDF viewer
• Hugely improved web browser
• SIP Internet Telephony
• Music Player
• Flash Player
• RealPlayer

The new web browser is better than the one that came with the old S60 2nd Edition OS in almost every way. It renders pages much more accurately, supports javascript, cookies, and flash, and when it's combined with the E61 display it works really well. The one thing that lets it down is the way than the navigation works. instead of tabbing between links and scrolling a page at a time, you have a "mouse pointer" which you have to move around using the 5-way navigation control. This is labourious to say the least, and I think I'll probably end up using Opera or Opera Mini instead which has a navigation system that is much better suited to a non touch screen display.

One of the main reasons I wanted this phone was that I could connect to a wireless LAN and make and recieve calls through our IP PBX (Asterisk). So far my attempts to get this working have produced mixed results. Firstly the WLAN adapter doesn't like my access point and seems to drop the connection after about 30 seconds. Secondly when I've actually got a call to connect, the sound quality is terrible.

Putty for Symbian has now been updated to support S60 3rd Edition phones (Beta version). Installation was complicated by the fact that the OS will now only install offically signed applications by default (Putty uses a self signed certificate). Luckily this "feature" can be disabled. With it's querty keyboard and 320 pixel display, the E61 actually makes SSH a viable option, and if you drop the font size down to 7x4 pixels you can even get 80 characters across! Obviously it's not much good for day to day admin, but for emergencies it's invaluable.

The other main application that I will be installing is TomTom Navigator 6 (finally available without the bundled bluetooth GPS) so I don't get lost.

Conclusions

I've only had my E61 for 3 days but I'm already pretty sure that I'm going to keep it. There are some problems, but most of the things I want seem to work. Maybe once I've lived with it for a bit I'll post an update. Here are my pros and cons:

Pros:

• Landscape bright QVGA (320x240) 16.7 million colour screen
• QUERTY keyboard
• WiFi (WLAN)
• 3G
• No camera (some of the companies that I visit don't allow camera phones)
• Built in VOIP (Voice Over IP) software supporting SIP
• Excellent speakerphone
  
• It's a Nokia

Cons:

• No camera ;)
• WiFi seems to be a bit fussy (could just be my old access point)
• It's a little on the wide side

Nokia released an updated version of the firmware (v2) a couple of weeks ago which I'm hoping might fix the WLAN and SIP problems. Unfortunately it doesn't seem to have been approved by T-Mobile yet because the updater says that there is "no updated software available".

One of Cyrus IMAP's more sophisticated features is the ability to create indexes of messages and mailboxes to allow fast searching of headers and message text.

The indexing is done using squatter, and is best achieved by launching it at regular intervals from cyrus.conf:

EVENTS {
...
# indexing of mailboxs for server side fulltext searches
# reindex changed mailboxes (fulltext) approximately every other hour
squatter_1 cmd="nice -n 19 squatter -s" period=120
# reindex all mailboxes (fulltext) daily
squatter_a cmd="squatter" at=0517
...
}

Once the indexes have been created, the improvement in search performance is dramatic.

There's a bug in the current SASL2 SQL library (libsasl2-modules-sql) which means it logs at debug level all the time, and there's no way of switching it off. This fills up auth.log with junk because the default syslog configuration on Debian logs all auth output including debug which makes logcheck unusable.

Until SASL2 is fixed, the only way I've found to work around this is to reduce the logging level for auth and authpriv to exclude debug messages. For syslog-ng this requires the following change to /etc/syslog-ng/syslog-ng.conf